共享Android算力：打破固定设备实验室的局限

在本系列的第一篇文章中，我们探讨了如何通过可编程Android环境替代繁琐的手动设备准备流程，实现可重复的迭代周期。整个工作流程包括：请求一个预定义配置的环境、执行目标任务、收集运行结果，并在完成后释放相关资源。

自动化让团队能够可靠地创建单个Android环境。而接下来的关键在于扩展性：如何让同样的运营模式支撑每一位开发者、每一项测试任务、每一个交互会话？

在云端运行单一Android环境固然有用，但真正改变运营模式的，是按需大规模提供Android算力。

固定硬件 vs 动态需求

物理设备实验室的增长方式十分笨拙——一次添置一台设备。每增加一部手机、一块开发板、一台显示器或一套硬件测试台，都需要采购、配置、连接、维护、共享，并最终面临更换。

当需求规模小且可预测时，这种模式尚能运作。然而工程领域的实际需求往往难以捉摸。常见的挑战场景包括：

• CI流水线在代码变更提交后可能需要大量临时环境；
• QA团队在发布前夕需要临时扩容；
• 流媒体服务可能遭遇活跃会话数的激增；
• 汽车团队可能需要并行验证多种Android Automotive OS配置。

传统做法往往迫使团队做出妥协：要么按平均需求配置硬件，接受高峰期排队等待；要么按峰值需求配置，导致低峰期设备闲置浪费。

这造成了一种明显的错配：专用Android设备提供的容量是固定的，而开发、测试和流媒体负载产生的需求却是动态变化的。

目标硬件（包含传感器、外设和GPU等真实组件）对于验证最终产品特性仍然不可或缺。但手机、开发板或硬件测试台的数量，不应成为制约所有软件活动推进速度的瓶颈。

从设备清单到按需容量请求

云基础设施通过资源整合池的方式应对动态需求，在需要时将算力分配给对应的工作负载。这些工作负载根据技术需求以容器或虚拟机的形式运行在共享主机上。

借助Anbox Cloud，Android也可以采用相同的模式。工作流程不再需要预定某台特定的手机或开发板，而是直接请求一个具有指定镜像、配置和资源规格的Android环境。Anbox Cloud会将其作为受管理的容器或虚拟机部署在可用主机基础设施上。

任务完成后，Android实例可以被销毁，其CPU、内存、存储和图形资源将归还至共享池，供其他开发者、测试任务或会话使用。

Android算力从此变成一种”被请求”的资源，而非需要人工预留的资产。当需求上升时，团队可以灵活提供更多环境，无需为每项任务分配专属设备。

按工作负载扩展，而非盲目堆实例

讨论扩展性时，人们常问的第一个问题是：一台服务器能跑多少个Android实例？

这个问题没有标准答案。

• 一个被串流的Android游戏与自动化测试的所需资源截然不同；
• 交互式开发环境产生的负载模式不同于夜间批量验证流水线；
• 完整的Android Automotive OS镜像与纯应用级工作负载所需的资源差异巨大。

有些环境主要受限于CPU和内存，而另一些则取决于GPU能力、存储性能、网络带宽、启动时间或帧率稳定性。这些差异远比单纯的实例数量更重要。

更有价值的提问方式是：这个工作负载需要多少容量才能保证稳定可预期的结果？

团队需要在贴近真实场景的条件下对代表性应用和Android镜像进行基准测试，理解平均并发量、峰值需求、会话时长以及哪种基础设施资源会成为首要瓶颈。密度固然重要，但可预测性更为关键。

为匹配不同的执行模式，Anbox Cloud同时支持容器化和虚拟化两种Android运行方式：

• 容器适合以应用为核心的工作负载，如测试、串流、自动化和 gaming，在这些场景中密度、启动速度和资源利用率至关重要；
• 虚拟机则适用于需要完整Android系统及其内核边界的场景，如定制Android系统开发和系统级验证。

两种执行模型并无绝对优劣之分，选择取决于具体工作负载。而运营目标始终如一：以可预期的方式提供所需的Android算力。

扩展的不仅是实例，更是团队协作能力

共享Android算力还能消除组织层面的瓶颈，因为环境由中心化管理并可远程访问。

开发板可能存放在某个办公室，而需要使用它的工程师却身在海外。某套硬件测试台可能被分配给一个团队，却在大部分时间处于闲置状态。一台设备可能需要跨多个团队轮换使用……

---

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://ubuntu.com//blog/scaling-android-development-without-scaling-hardware

---

请支持IMCN发展！

谁在捐赠

微信捐赠	支付宝捐赠

扫码关注公众号：智享开源