远程真机测试平台对比：Firebase、AWS、BrowserStack

「远程真机测试平台对比：Firebase、AWS、BrowserStack」

把 targetSdk 升到 34 之后，我们的应用在 Samsung Galaxy S24 Ultra 上收到一个 Native 崩溃，堆栈指向一段 OpenGL ES 纹理上传逻辑，错误码是 0x502（GL_INVALID_OPERATION）。手边的 Pixel 8 复现不了，Android Emulator 的 API 34 系统镜像跑的是 SwiftShader 软渲染，连 GPU 驱动都不沾边。要抓这个问题，只能把 debug APK 丢到远程真机平台上去跑。过去两年，我几乎把 Firebase Test Lab、AWS Device Farm 和 BrowserStack 的 Android 设备池都用了个遍，这篇文章把三家平台的真实账单、设备底层差异和 CI 集成里的暗坑摊开聊。

本地模拟器的盲区：为什么 x86_64 转译掩盖了半数崩溃

很多团队直到线上崩溃报告砸过来才意识到，Android Emulator 和物理真机已经是两个世界。Emulator 的 API 34 镜像基于 AOSP，Google APIs 版本里连 GMS 都是精简过的；而国内用户手里的机器跑的是 Samsung One UI、Xiaomi HyperOS 或者 OPPO ColorOS，权限模型、后台限制策略和 OpenGL 驱动分支完全不同。更隐蔽的是 ABI 差异： Emulator 在 x86_64 主机上默认启用 ARM 转译，很多 so 库其实跑在 libhoudini 或 libndk_translation 上，指令序列和真机 ARMv9 并不一致。我们曾遇到一个 Room 数据库的 SIGILL 崩溃，只发生在联发科天玑 9300 设备上，根源是特定版本的 SQLite 编译时启用了 ARMv8.3 的指针认证指令，而 Emulator 的转译层直接抹掉了这些特性。

传感器和外设也是盲区。摄像头 HAL 层、指纹回调时序、物理键盘热插拔，这些在 Emulator 上要么不存在，要么行为过于理想化。当业务涉及到 CameraX 的 HDR 连拍或者 BiometricPrompt 的特定厂商适配时，远程真机测试就不再是"可选项"，而是发布前的硬性卡点。

Firebase Test Lab：GSI 陷阱与 Spark/Blaze 计费边界

Firebase Test Lab 最直接的优势是定价。物理设备按 $5/设备小时计费，虚拟设备 $1/设备小时，gcloud firebase test android run 命令可以直接从 CI 流水线触发。Spark 计划（免费档）每天提供有限额的物理和虚拟设备测试时长，个人项目或者预发环境做冒烟测试基本够用；一旦接入 Blaze 按量付费，账单随用随结，没有月租门槛。对于纯 Android 技术栈的团队，这是最顺手的方案，因为它和 Google Play 控制台、Crashlytics、Cloud Storage 的 artifact 归档是打通的。

但 Firebase Test Lab 有一个长期被忽视的坑：部分标称为 Physical device 的机器，底层跑的是 GSI（Generic System Image）。GSI 是 AOSP 的通用系统镜像，剔除了大量厂商定制层。你在 Firebase Test Lab 的 Samsung Galaxy S22 上测出来的结果，可能和真实用户手里的 One UI 5.1 相去甚远。Google 官方文档里会标注哪些设备是"Standard"物理机，哪些是 GSI，但设备列表经常变动。我们曾在 2024 年初发现，一台标称为 Samsung S23 的设备实际上跑的是 Android 14 GSI，结果 BiometricPrompt 的 UI 弹窗样式和线上用户上报的截图完全不同，导致我们误以为一个 UI 偏移问题已经修复。

另一个深坑是 Robo test 对 Jetpack Compose 的支持。Robo test 依赖无障碍树做 UI 遍历，而 Compose 的语义节点默认只对开启了 semantics 的组件暴露。如果你的可组合项没有用 modifier = Modifier.semantics { } 显式标注，Robo 会像无头苍蝇一样乱点，最后卡在某个深层页面超时。Firebase Test Lab 的 Instrumentation test（Espresso/UI Automator）倒是稳定得多，但需要你自己写测试用例。此外，测试产出的 logcat、视频和截图默认保留 90 天，超过后自动清理，如果你需要长期归档崩溃现场，得在 CI 里额外写脚本把 artifact 拖到自己的存储桶。

计费上也要小心"超时陷阱"。Firebase Test Lab 的单次测试矩阵有 45 分钟的硬时限，单个测试用例默认超时是 300 秒。如果你的冷启动链路里塞了太多初始化任务，或者测试设备卡在 Google 账号验证页面，整个 matrix 会被直接杀掉，但这段时间仍然计入账单。我遇到过一次测试矩阵排队 20 分钟，真正跑只跑了 3 分钟，账单按分钟粒度结算倒是没亏，但排队的挫败感很强。

AWS Device Farm：VPC 穿透成本与设备帧率限制

AWS Device Farm 的定价模型和 Firebase 完全不同。它没有免费档，按需计费是 $0.17/分钟，换算下来约 $10.2/设备小时，比 Firebase 的物理设备贵一倍还多。如果你需要独占设备（Private devices），月租 $200/台起。对于已经 all-in AWS 的团队，Device Farm 的吸引力在于它能通过 VPC Endpoint 把测试流量直接路由到内网 Staging 环境，不用像其他平台那样开公网白名单或者搭反向代理。这个特性在金融或者企业级应用里几乎是刚需。

Device Farm 支持 App