第1章：Android模拟器简介与作用
聊到CI中的Android测试，你第一个想到的肯定是模拟器。模拟器这东西，说白了就是一个跑在你电脑或CI服务器上的虚拟Android设备。它能模拟出真实手机的行为——启动App、加载页面、触发点击、响应网络请求，基本上真机能干的事它都能干。
我早期做移动端CI的时候，团队里很多人觉得“反正有真机测试机柜，还要模拟器干嘛？”结果呢？真机池不够用，跑一次集成测试要排队半小时，而且每台机器还得手动刷机、恢复出厂设置，别提多折腾了。后来我把模拟器引入CI流水线，测试时间直接砍掉了70%。嗯，这里要注意：模拟器不是万能的，但在CI场景下，它的价值被严重低估了。
1.1 什么是Android模拟器？
Android模拟器（Emulator）是Google官方提供的虚拟设备镜像。它基于QEMU虚拟机，能模拟不同品牌、不同API级别、不同屏幕尺寸的Android设备。
举个例子：你可以同时启动一个Pixel 5（API 33、英文）和一个Galaxy Tab（API 30、中文）的模拟器实例，在同一台机器上并行跑测试。这在真机上是几乎做不到的——你不会有那么多物理设备。
我个人习惯把模拟器理解为“可编程的手机”。它支持快照（Snapshot）、远程控制（adb）、GPU加速（用宿主机显卡渲染）。配合CI，你甚至能做到“零人工干预”的自动化测试。
1.2 为什么CI中需要模拟器？
你想想看，如果没有模拟器，CI里要怎么做自动化UI测试？
- 成本问题： 一台真机动辄几千块，CI机柜里放20台就是十多万。模拟器免费，一台机器可以同时起4~6个实例。
- 效率问题： 真机需要USB连接、充电、清理缓存。模拟器秒级创建，用完即毁（临时实例）。
- 版本覆盖： 新产品发布前，你需要测试老Android版本（如API 24、26）。真机很难买到老版本设备，模拟器一键切换。
- 并行能力： CI中多个测试任务可以各自占用一个模拟器实例，互不干扰。真机则要排队。
我在一个大型电商项目里就遇到过：上线前发现某些低端机（Android 7.0）上列表滑动卡顿。真机房根本没有这类设备，全靠模拟器（Android 7.0镜像）复现了问题并修复。所以，模拟器不仅仅是“可选项”，而是CI测试覆盖的“必需品”。
1.3 模拟器 vs 真机：怎么选？
这个问题经常被问。我的答案是：CI里优先用模拟器，回归前加真机验证。
| 对比维度 | 模拟器 | 真机 |
|---|---|---|
| 成本 | 免费，可无限创建 | 每台2000元+，维护成本高 |
| 启动速度 | 快照启动<10秒 | 开机+adb连接 >30秒 |
| 版本覆盖 | 全面（API 15~35） | 有限（需购买老旧机型） |
| 硬件差异 | 无法模拟传感器、NFC | 真实体验 |
| 并行能力 | 单机4~8实例 | 单机1~2台（依赖USB集线器） |
| CI集成 | 完全可编程，支持Docker化 | 需要手动维护机柜 |
看到这个对比你可能会想：既然模拟器便宜又好用，那是不是可以完全取代真机？别急。我曾经踩过一个坑：某个页面依赖设备的物理返回键（硬件按键）处理，模拟器按键事件和真机有细微差别，导致CI测试全绿，上线后崩溃。所以我的建议是：日常CI用模拟器跑功能性测试，但每个版本的回归前，一定在真机上做一次冒烟。
1.4 模拟器在CI中的典型工作流程
下面是模拟器在CI流水线中的位置图，看完你就能理解整个协作关系。
你看，整个流程就是：代码提交 → 构建APK → 创建模拟器实例 → 安装启动App → 跑测试 → 生成报告。其中模拟器实例可以复用（通过快照），也可以每次销毁重建（保证环境纯净）。我个人偏向后者：在CI中每次都用干净的模拟器，避免缓存污染。
1.5 常见问题与避坑
- 模拟器启动超时？ 我遇到过CI环境中CPU资源不足导致模拟器启动失败。建议给模拟器分配2个vCPU、2GB内存，同时启用KVM加速（Linux下）。
- 模拟器无法联网？ 检查CI网络的DNS配置，或者使用模拟器的“模拟网络”功能（延迟、丢包等）。
- 截图对比差异大？ 模拟器的渲染引擎和真机略有差距，尤其是字体和硬件加速效果。我一般会在测试断言里留5%的像素容忍度。