Android 模拟器在 CI 中的价值

做移动端 CI 的同学，几乎都会面临一个问题：到底要不要在流水线里跑模拟器？

我刚接手团队 CI 时也犹豫过。模拟器启动慢、资源消耗大、偶尔还卡死……但后来我发现，只要配得好，模拟器在 CI 里带来的收益远超预期。今天我们就来拆解一下它最核心的四个价值。

一、加速测试：从「等半天」到「两轮茶」

没有模拟器的时候，很多团队只能在真机上跑测试。真机排队、烧录、重启，一套全量回归下来，上午提的 PR 下午才能拿到结果。我亲身经历过，一个包含 800 条 UI 测试的套件，在 5 台真机上跑了整整 4 小时。

换成模拟器后，启动时间从分钟级降到秒级。更重要的是，模拟器可以预置快照，每次测试直接恢复到一个干净状态，省去 app 安装、数据清理的耗时。同一个套件，在 4 核机器上用 2 个模拟器并行跑，半小时就出结果了。

为什么会差这么多？因为模拟器用宿主机的 CPU 和内存，没有物理连接瓶颈。你想想看，真机通过 USB 传输数据，速率撑死几十 MB/s；模拟器直接内存映射，I/O 速度快两个数量级。

二、并行执行：把「串行」变成「多车道」

CI 最怕的就是「排队等资源」。真机数量有限——你团队能有 20 台不同型号的设备吗？模拟器呢？只要宿主资源够，你想开几个开几个。

我自己做过一个极端测试：在一台 64 核、128G 的服务器上，同时启动 20 个 Android 模拟器实例。每个实例分配 2 核 4G 内存，跑不同的测试模块。结果 20 个任务同时完成，总耗时和跑一个任务差不多。

当然，并行不是无脑开多就行。我记得有一次给每个模拟器只分 1G 内存，结果 5 个实例全部 OOM，测试直接全挂。建议至少 2G 起步，UI 测试最好 4G。

三、环境一致性：告别「在我机器上能跑啊」

做 CI 最头大的问题之一：开发本地测试绿了，CI 上红了。原因往往是环境差异——开发用的是 Android 14 API 34，CI 上装着 Android 12 API 32；或者开发机器上装了某个系统字体，CI 上没有。

模拟器最大的好处就是 完全可复现。你可以把模拟器配置固化成代码，放进 Git 仓库。每次 CI 启动时，直接从镜像仓库拉一个预装好所有依赖的模拟器快照。

我曾经在项目里用一个 500M 的「黄金镜像」——里面预装了 app、测试框架、系统设置、中文字体。所有开发机、CI 节点都用同一个镜像。从那以后，因为环境不一致导致的失败几乎归零。

# ci-config.yaml 示例
emulator:
  system_image: "system-images;android-34;google_apis;x86_64"
  ram: 4096
  heap: 1024
  disk_size: 4096
  snapshot: "golden-2025-03-01"
  locale: "zh-CN"
  timezone: "Asia/Shanghai"

四、成本优势：用云服务器的零头，做十倍的事

算一笔账：一台高端 mac mini 或者云 GPU 服务器，月租差不多 1000~3000 元。而买一台旗舰真机要 8000+，而且 1~2 年就得换代。如果你需要覆盖 5 个 Android 版本、3 种分辨率……硬件成本很快变成团队不能承受之重。

模拟器呢？一台 8 核 32G 的云服务器，月费大约 2000 元，却能同时跑 8~12 个模拟器实例。你想想看，同样的预算，模拟器方案能提供 10 倍以上的并发能力。

不过，成本优势不是白捡的——你得为它付「配置成本」。比如要选对系统镜像、配置好 KVM 虚拟化、处理 AVD 的 crc 冲突。这些前期投入一般花 1~2 天就能搞定，之后每天都省钱。

SVG：模拟器在 CI 中的四大价值关系图

避坑指南：别让模拟器变成 CI 的瓶颈

价值虽好，坑也不少。我列几个我踩过的雷：

• KVM 权限没开——模拟器启动直接报错。检查 /dev/kvm 权限，把 CI 用户加到 kvm 组。
• 系统镜像太大——每次拉取 2~3G 镜像，CI 时间全浪费在网络下载上。建议预下载到 Docker 镜像里，或者用本地缓存。
• 快照过期——App 版本升级后，旧快照不兼容。我曾经忘了更新快照，导致连续 3 天所有 UI 测试失败……后来加了个自动化脚本：每周重建一次黄金快照。

好了，以上就是模拟器在 CI 里的四个核心价值。说白了，它帮你用更少的钱、更快的速度、更稳定的环境，跑更多的测试。下一回我们聊聊具体怎么搭这套环境——从镜像选择到配置参数，我会把踩过的坑都摊开来讲。