3、测试环境搭建：Android模拟器与真机集群管理、iOS模拟器与云真机平台选型
做动态化交付的兼容测试，环境搭建是第一步，也是最容易踩坑的一步。我这些年折腾过不少测试环境，从最开始搬几台真机手搓，到后来搭集群、上云平台，每个阶段都有不同的教训。说白了，环境选不好，后面的测试全是白搭。这一节我把自己的经验梳理一下，帮你少走弯路。
3.1 Android模拟器选型与配置
Android模拟器这东西，市面上选择很多。但你要搞清楚一件事：没有完美的模拟器，只有最适合你场景的模拟器。
我个人习惯把模拟器分成三类：官方AVD、Genymotion、以及第三方游戏模拟器。它们在性能、兼容性和功能上各有侧重。
| 类型 | 代表产品 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 官方AVD | Android Studio自带 | 系统版本全、Google API完整、官方维护 | 启动慢、资源占用高 | 基础兼容测试、API功能验证 |
| 第三方专业模拟器 | Genymotion | 启动快、GPU性能强、云集成好 | 免费版功能受限、部分系统版本缺失 | 性能测试、自动化脚本调试 |
| 游戏模拟器 | 夜神、MuMu、蓝叠 | 兼容性好、低配机器也能跑 | 系统版本滞后、预装应用多 | UI适配测试、游戏类兼容验证 |
这里有个坑我想提醒你——不同模拟器的渲染引擎差异很大。我之前在AVD上跑UI自动化，脚本全部通过，换到真机上布局全乱了。后来才发现，AVD默认的GPU渲染模式跟真机不一样。所以我的建议是：模拟器只用来做快速验证，最终结论一定要上真机。
• AVD搭配Intel HAXM或Windows Hyper-V加速，RAM给2-4GB，存储8GB起步。
• Genymotion推荐用VirtualBox后端，开启3D加速。
• 游戏模拟器建议关闭root权限，避免测试环境与用户环境偏差太大。
3.2 Android真机集群管理
做动态化交付的兼容测试，真机集群是绕不开的硬骨头。你想想看，几十个机型、不同系统版本、不同屏幕比例，靠人工一台台插拔调试，效率太低了。
我在项目中用过两套方案：STF（Smartphone Test Farm）和自建ADB多路复用。
STF是目前业界最成熟的开源方案。它通过Web页面管理所有设备，支持远程操作、截图、安装应用、logcat查看。部署也不复杂，Docker一键启动：
# 部署STF核心服务
docker run -d --name rethinkdb -p 28015:28015 rethinkdb
docker run -d --name adbd \
--privileged \
-v /dev/bus/usb:/dev/bus/usb \
-p 5037:5037 \
sorccu/adb:latest
docker run -d --name stf \
--net host \
openstf/stf:latest \
stf local --public-ip your-server-ip部署完成后，把测试机通过USB连接到服务器，STF会自动识别并添加到设备池。你可以直接在浏览器里操作每台设备，甚至并行跑自动化脚本。
除了STF，还有一种轻量方案——用adb connect通过TCP/IP连接设备。这种方式适合设备分散在不同工位的情况：
# 设备端开启TCP模式
adb tcpip 5555
adb connect 192.168.1.100:5555
# 批量检查设备状态
adb devices -l但说实话，这种方案稳定性一般，设备重启后需要重新连接。我个人更推荐STF做集中管理，尤其当设备数超过10台时，优势非常明显。
3.3 iOS模拟器选型与配置
iOS的生态封闭，模拟器选项远没有Android丰富。说白了，你基本只有一条路——Xcode自带的iOS Simulator。
iOS Simulator的优势是跟Xcode深度集成，可以模拟几乎所有iOS版本和设备类型。但它有几个硬伤：
- 无法模拟相机、传感器、陀螺仪——涉及这些硬件的功能模拟器上测不了。
- 性能与真机差异大——模拟器跑在Mac上，CPU和内存都远强于真机，流畅度不能作为参考。
- 只能跑在macOS上——如果你用的是Windows或Linux，iOS模拟器就没法用了。
我建议你注意Xcode版本的管理。不同Xcode版本支持不同的iOS SDK，而动态化交付经常需要覆盖多个iOS版本。可以用xcode-select快速切换：
# 列出所有Xcode路径
xcode-select --print-path
# 切换Xcode版本
sudo xcode-select -switch /Applications/Xcode_14.3.appxcode-select动态切换。这样同一个自动化流程可以覆盖iOS 15、16、17三个主要版本，省去了手动切换的麻烦。
3.4 iOS云真机平台选型
因为iOS模拟器限制太多，真机测试就变得格外重要。但iOS真机成本高、管理复杂，所以大多数团队会选择云真机平台。
我对比过几个主流平台，简单说说我的感受：
| 平台 | 机型覆盖 | 并发能力 | 自动化支持 | 价格（参考） |
|---|---|---|---|---|
| 阿里MQC | 中高端机型为主，覆盖全 | 支持高并发 | 兼容Appium、Macaca | 按分钟计费，偏贵 |
| Testin | 机型最多，包括低端机 | 中等并发 | 支持Appium、RobotFramework | 包月套餐较划算 |
| Firebase Test Lab | Google亲儿子，Pixel系列为主 | 并发较高 | 支持GTM、Espresso、XCTest | 按测试矩阵计费 |
| AWS Device Farm | 中高端机型，覆盖一般 | 中等并发 | 支持Appium、Espresso、XCTest | 按分钟计费 |
选云真机平台，我建议你关注三个点：机型覆盖是否匹配你的用户画像、并发数能否支撑你的测试周期、以及自动化脚本的兼容度。我曾经在一个平台上跑动归脚本，发现它对Appium的XCTest模式支持不完整，浪费了整整两天排查问题。所以，选之前一定要先拿你的脚本做POC验证。
3.5 混合架构：模拟器+真机的最佳实践
讲到这里，你可能会问：「那我到底该用模拟器还是真机？」
我的答案是：用混合架构，各取所长。
在动态化交付的场景里，测试环境需要兼顾效率和覆盖度。下面是我在实践中总结的一套组合拳：
- 日常回归用模拟器——AVD或Genymotion跑自动化脚本，快速验证核心功能，10分钟内出结果。
- 关键兼容点上真机集群——STF管理的真机池，覆盖Top 10机型、不同屏幕比例和系统版本。
- 长尾机型走云真机——对iOS全覆盖、Android的长尾机型，按需调用云平台资源，避免自建成本过高。
- 硬件相关功能必须真机——相机、NFC、传感器、性能指标，这些模拟器搞不定，老老实实上真机。
• Android：AVD（快速验证）+ STF真机集群（核心覆盖）+ 阿里MQC（长尾补充）
• iOS：Xcode Simulator（版本覆盖）+ Firebase Test Lab（真机验证）
• 调度层：统一Jenkins Pipeline，根据测试标签自动路由到不同环境。
这套架构跑下来，单次兼容测试的成本降低了大约60%，而问题发现率反而提升了。原因很简单——让合适的工具做合适的事，而不是一把抓。
这张图展示的正是我前面讲的分层架构。从顶层的调度管理，到中间Android和iOS两大环境的分工，再到底层的设备资源池和监控报告，每一层各司其职。你搭建环境时，可以按照这个结构逐步落地，不需要一步到位，但方向要清晰。