Android应用的编译环境搭建通常比较繁琐，除了JDK之外，还需要安装Android SDK、平台工具、构建工具，并正确配置ANDROID_HOME和PATH变量。如果只在某一台开发机上配置一次，后续换机器或接入CI时很容易因为SDK组件版本不一致而出现编译失败。Docker提供了一种轻量级、可复制的系统级打包方案，可以把完整的Android构建依赖固化在镜像里，让构建任务在任何支持Docker的主机上都能稳定执行。
为什么要容器化Android构建环境
Android项目通常依赖Gradle Wrapper来固定Gradle版本，但Gradle运行本身需要正确的JDK版本，并且构建过程中还会调用Android SDK中的aapt2、d8、apksigner等工具。如果宿主机上已经有了一个旧版SDK，或者ANDROID_HOME指向了不完整的目录，Gradle可能在执行mergeDebugResources或processDebugResources阶段才报错，排查起来比较耗时。容器化之后，JDK和SDK都被封装在镜像内部，宿主机只需要负责提供Docker运行时，不再关心具体工具链的安装路径。
另一个痛点是CI节点的初始化成本。传统做法是在每台构建机上用脚本下载SDK并安装组件，这个过程可能持续十几分钟，而且网络波动会导致重复安装失败。使用Docker镜像后，CI流水线可以直接引用已经构建好的镜像，启动秒级即可开始编译。对于团队新成员，也无需再按照冗长文档手动配置开发环境，只需要拉取镜像即可复现与CI完全一致的构建条件。
此外，容器化还便于做版本管理和回滚。每一个镜像标签可以对应一个固定的JDK版本、SDK组件版本和构建工具版本。当项目需要升级compileSdk或buildToolsVersion时，可以新打一个镜像标签，旧项目继续使用旧标签，两者互不影响。
编写Android构建镜像的Dockerfile要点
选择基础镜像时，优先使用Ubuntu或Debian这类glibc发行版。Android SDK中的部分原生工具在Alpine的musl libc下可能出现兼容性问题，虽然Alpine镜像更小，但对Android构建来说稳定性不如Ubuntu。下面是一个最小可用的Dockerfile示例，它从Ubuntu 22.04开始，安装OpenJDK 17和Android命令行工具，再通过sdkmanager安装构建所需组件。
FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive \
ANDROID_HOME=/opt/android-sdk \
ANDROID_SDK_ROOT=/opt/android-sdk \
PATH=${PATH}:/opt/android-sdk/cmdline-tools/latest/bin:/opt/android-sdk/platform-tools
RUN apt-get update && apt-get install -y --no-install-recommends \
openjdk-17-jdk \
curl \
unzip \
ca-certificates \
&& rm -rf /var/lib/apt/lists/*
RUN mkdir -p ${ANDROID_HOME}/cmdline-tools \
&& curl -fsSL https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip -o /tmp/cmdline-tools.zip \
&& unzip /tmp/cmdline-tools.zip -d ${ANDROID_HOME}/cmdline-tools \
&& mv ${ANDROID_HOME}/cmdline-tools/cmdline-tools ${ANDROID_HOME}/cmdline-tools/latest \
&& rm /tmp/cmdline-tools.zip
RUN yes | ${ANDROID_HOME}/cmdline-tools/latest/bin/sdkmanager --licenses > /dev/null \
&& ${ANDROID_HOME}/cmdline-tools/latest/bin/sdkmanager \
"platform-tools" \
"platforms;android-34" \
"build-tools;34.0.0"
上面的Dockerfile中，ENV同时设置了ANDROID_HOME和ANDROID_SDK_ROOT，这是为了避免不同构建工具读取不同变量导致路径混乱。安装sdkmanager组件时建议明确写出platforms和build-tools的具体版本，而不是使用latest，因为latest会随时间变化，可能引入不可预期的API变更。许可证接受使用yes命令自动确认，实际企业环境中最好先本地执行同意并将licenses目录固化进镜像。
如果项目使用Gradle Wrapper，镜像中不需要单独安装Gradle，只需保证JDK存在即可。不过为了减少每次构建时下载Gradle发行包的时间，可以提前在镜像中运行一次./gradlew --version，把Gradle发行包预热到GRADLE_USER_HOME目录。该目录默认位于/root/.gradle，在后续容器启动时通过挂载卷持久化，可以显著缩短冷启动时间。
在CI流水线中使用Docker构建Android项目
镜像构建完成后，本地和CI中都可以通过docker run执行构建。一个基本的命令是把项目源码目录挂载到容器内的/app，把Gradle用户目录挂载到/root/.gradle，然后进入/app运行Gradle任务。示例如下。
docker run --rm \ -v "$(pwd)":/app \ -v gradle-cache:/root/.gradle \ -w /app \ android-build:latest \ ./gradlew assembleDebug
上面的命令使用了Docker命名卷gradle-cache来保存Gradle缓存，这样即使容器退出，依赖和构建缓存也不会丢失。如果不想使用命名卷，也可以挂载宿主机目录，但在CI集群中要注意并发写入同一个缓存目录可能导致锁冲突。命名卷由Docker管理，更适合单机或多副本场景。
对于GitLab CI，可以在.gitlab-ci.yml中配置image为提前推送的镜像地址，然后直接写script。例如：
build:
image: registry.ipipp.com/android-build:34
script:
- ./gradlew assembleDebug
artifacts:
paths:
- app/build/outputs/apk/debug/app-debug.apk
expire_in: 7 days
cache:
key: gradle-cache
paths:
- .gradle
- ~/.gradle/caches
这里需要注意，GitLab CI的cache路径是相对工作目录或者用户目录，使用~表示当前用户主目录，该用户由镜像内的USER决定。默认容器以root运行，因此~/.gradle等同于/root/.gradle。若镜像为了安全切换到了非root用户，要相应调整缓存路径。另外，在并发流水线中，同一个缓存key可能被多个任务同时读写，建议在Gradle配置中开启文件锁或使用远程缓存。
Jenkins用户可以采用类似方式，在Pipeline中调用docker.image().inside()，或者直接使用docker run命令。无论哪种CI系统，容器化构建的关键是保证源码以挂载方式进入容器，构建产物通过挂载卷或CI的artifact机制传出，不要试图把源码打进镜像，否则每次代码变更都要重新构建镜像。
镜像体积优化与构建加速
Android SDK本身包含多个平台版本和构建工具，全部安装后体积可能超过10GB。对于CI构建镜像，应该按需安装最小集合，例如只保留项目实际使用的platforms;android-34和build-tools;34.0.0。如果多个项目使用不同版本，可以构建多个标签镜像，而不是把所有版本塞进同一个镜像。Dockerfile中每执行一次sdkmanager都会产生新的一层，建议把SDK组件安装合并到一条RUN命令中，减少层数和中间文件残留。
多阶段构建是进一步压缩体积的有效手段。第一阶段可以安装完整的SDK和构建工具，执行一次项目构建来预热所有依赖和缓存；第二阶段只复制生成好的APK或者精简后的运行时环境。如果目标是构建环境本身，多阶段构建的收益不大，因为最终镜像仍然需要SDK和JDK。此时更值得做的是清理apt缓存、删除SDK临时下载文件，以及使用docker build --squash压缩历史层。
# syntax=docker/dockerfile:1.4
FROM ubuntu:22.04 AS builder
RUN apt-get update && apt-get install -y openjdk-17-jdk curl unzip \
&& curl -fsSL https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip -o /tmp/tools.zip \
&& unzip /tmp/tools.zip -d /opt/android-sdk/cmdline-tools \
&& mv /opt/android-sdk/cmdline-tools/cmdline-tools /opt/android-sdk/cmdline-tools/latest
ENV ANDROID_HOME=/opt/android-sdk
RUN yes | /opt/android-sdk/cmdline-tools/latest/bin/sdkmanager --licenses \
&& /opt/android-sdk/cmdline-tools/latest/bin/sdkmanager "platforms;android-34" "build-tools;34.0.0"
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y --no-install-recommends openjdk-17-jdk ca-certificates \
&& rm -rf /var/lib/apt/lists/*
ENV ANDROID_HOME=/opt/android-sdk \
ANDROID_SDK_ROOT=/opt/android-sdk \
PATH=${PATH}:/opt/android-sdk/platform-tools:/opt/android-sdk/cmdline-tools/latest/bin
COPY --from=builder /opt/android-sdk /opt/android-sdk
这个多阶段Dockerfile把SDK下载和安装放在builder阶段，最终镜像只从builder复制已经安装好的SDK目录，同时重新安装了JDK和证书。这样最终镜像不包含curl、unzip等临时工具，体积会有一定下降。注意Dockerfile第一行的syntax指令要求使用BuildKit，需要在构建命令中启用DOCKER_BUILDKIT=1。
构建加速方面，Gradle守护进程在容器内默认会为每个构建启动一个新的JVM，容器退出后守护进程也会终止，无法跨容器复用。可以通过挂载GRADLE_USER_HOME目录并配置org.gradle.daemon=false来避免无意义的守护进程启动，或者使用Gradle的构建缓存功能。在gradle.properties中加入org.gradle.caching=true后，Gradle会将任务输出缓存到本地目录，后续构建即使容器重建，只要缓存卷还在，就能跳过重复任务。如果团队有远程缓存服务器，还可以配置remote build cache，让不同机器的构建结果共享。