AI 辅助编程已经不只是“帮我补全一段代码”这么简单。越来越多开发者开始让大模型阅读项目、定位问题、修改代码、运行测试,甚至完成接近真实 Pull Request 的修复任务。
问题也随之出现:我们该如何判断一个模型是否真的适合 Android 开发?
Android Bench 就是 Google 面向这个问题推出的基准测试。它不是泛泛地测试模型会不会写代码,而是把重点放在真实 Android 工程任务上,评估大语言模型在 Android 项目中解决实际问题的能力。

Android Bench 是什么
Android Bench 是 Android Developers 官方推出的 AI 编程能力排行榜和评测体系。它面向大语言模型,评估模型在真实 Android 开发任务中的表现。
和普通代码基准不同,Android Bench 关注的是 Android 开发者每天会遇到的问题,例如:
- 修改 Kotlin 或 Java 代码
- 处理 Jetpack Compose UI
- 迁移 Navigation 或构建配置
- 修复 Room、Hilt、Coroutine、Flow 相关问题
- 处理系统 UI、相机、媒体等平台能力
- 适配折叠屏、大屏、配置变化和运行时权限
它的目标并不是证明某个模型“会写代码”,而是回答一个更具体的问题:这个模型能不能在 Android 项目里完成真实、可验证、符合工程实践的修复?
为什么需要专门的 Android Benchmark
通用软件工程基准已经很多,但 Android 开发有自己的复杂性。
Android 项目通常同时包含 UI、生命周期、构建系统、依赖注入、异步任务、数据库、权限、设备形态适配等问题。一个模型即使在普通算法题或 Python 项目中表现很好,也不一定能理解 Android 的工程约束。
比如,一个 Android 修复任务可能同时涉及:
- Activity 或 Fragment 生命周期
- Compose 状态管理
- Gradle 插件和依赖版本
- Room 数据库迁移
- 协程取消和线程调度
- 多模块项目结构
- 单元测试和仪器测试
- 不同设备尺寸和系统版本
这些问题很难被普通代码题覆盖。Android Bench 的价值,就在于把评测焦点拉回 Android 开发的真实场景。
Android Bench 想达成什么目标
根据官方方法论,Android Bench 的发布主要有三个目标。
第一,推动大模型在 Android 开发方向继续改进。只有评测足够贴近真实工作,模型厂商和研究者才知道应该优化什么。
第二,帮助 Android 开发者选择更适合自己的 AI 编程助手。排行榜不仅给出成功率,也提供成本和延迟指标,方便开发者从准确性、速度和费用之间做权衡。
第三,提升 Android 生态中的应用质量。如果 AI 工具能更好地理解 Android 最佳实践,就有机会帮助更多开发者写出更可靠、更现代的应用。
它如何构造测试任务
Android Bench 使用真实开源项目中的 Issue 和 Pull Request 作为任务基础。模型会收到类似真实开发场景中的问题描述,然后需要修改代码,让项目通过对应测试。
官方从大量 GitHub Pull Request 中筛选任务。最终评测集包含 100 个任务,来自一个更大的候选池。候选 Pull Request 需要满足一些基本条件:
- 来自较受欢迎的 Android 项目
- 已经合并
- 修复了明确的问题
- 包含单元测试或仪器测试等验证方式
- 改动来自近几年的真实项目
在自动筛选之后,任务还会经过人工审核。审核者会确认项目能正常编译、问题描述足够清楚、补丁和描述匹配,并评估任务难度。之后还会有 Android 专家检查任务是否确实具备 Android 开发代表性。
这让 Android Bench 更接近真实工程,而不是简单的代码填空题。
任务覆盖哪些 Android 技术栈
Android Bench 刻意覆盖了现代 Android 开发中的关键技术方向。
在语言层面,任务以 Kotlin 和 Java 为主,反映当前 Android 生态从 Java 向 Kotlin 迁移的现实。
在 UI 层面,它同时覆盖 Jetpack Compose 和传统 View。Compose 是现代 Android UI 的重点方向,但大量历史项目仍然使用 View,因此评测不能只看新技术,也必须反映现有代码库的真实状态。
在工程实践层面,评测任务关注:
- Jetpack Compose
- Coroutine 和 Flow
- Room
- Hilt
- Gradle 和构建配置
- Navigation 迁移
- SDK 升级导致的破坏性变化
- 系统 UI、Camera、Media 等核心体验
- 配置变化、折叠屏适配和细粒度权限
这些内容组合起来,形成了一个更贴近 Android 工程能力的测试场。
排行榜怎么看
Android Bench 排行榜通常展示几个关键指标:
- Score:模型在 100 个任务中成功解决的平均比例
- CI range:置信区间,用来表示结果的统计可靠性
- Avg latency:完成一次完整评测运行的平均耗时
- Avg cost:完成一次完整评测运行的平均成本
其中最核心的是 Score,也就是成功率。它反映模型在 Android 修复任务中的总体能力。
但只看分数还不够。一个模型可能分数很高,但成本也很高;另一个模型分数略低,但速度更快、费用更低。对于真实团队来说,选择模型时应该综合考虑:
- 任务是否复杂
- 是否需要高成功率
- 是否能接受更长等待时间
- 单次调用成本是否可控
- 是否适合接入现有开发流程
排行榜不是简单的“第一名最好”,而是帮助开发者理解不同模型的能力边界。
成本和延迟指标要谨慎解读
Android Bench 的方法论特别提醒:成本和延迟不能脱离成功率单独比较。
原因很简单。一个模型如果很快失败,可能看起来耗时短、成本低,但这并不代表它更高效。它只是没有完成足够多的有效工作。
所以,更合理的比较方式是:先选择成功率接近的一组模型,再比较它们的成本和延迟。
另外,延迟指标包含网络传输时间,不完全等于模型自身推理速度。成本也会随着模型供应商定价变化而变化。因此,这些指标适合做参考,而不是绝对结论。
为什么引入 Harbor 框架
Android Bench 已经开始标准化到 Harbor 框架。Harbor 的作用是让基准测试更容易复现、运行和共享结果。
对于开发者和研究者来说,这意味着:
- 可以更透明地查看数据集
- 可以复现实验环境
- 可以评估自己关心的模型或 Agent 架构
- 可以把结果分享到社区
这对 AI 编程评测很重要。因为只公布排行榜并不够,真正有价值的基准测试应该让别人能够理解它怎么跑、任务从哪里来、结果如何计算。
mini-swe-agent v2 和工具调用
Android Bench 的执行系统也在随着模型能力演进。
早期一些 Agent 会让模型把命令写在 Markdown 代码块里,再由系统用规则提取命令执行。这种方式容易出错:模型可能写出看似合理的命令文本,但系统并不会真正执行。
新的执行方式更强调原生工具调用。模型需要通过明确的工具接口调用命令,而不是只输出一段文本。这更接近现代 Agent 系统的实际工作方式,也能更准确地评估模型是否真的会使用工具完成任务。
同时,Android Bench 在系统提示中保留了 Android 工程相关指导,让评测既符合通用软件工程 Agent 的标准,又能体现 Android 开发的领域特点。
数据污染和评测可信度
使用开源仓库构造基准有一个天然风险:模型可能在训练阶段见过相关代码或补丁。
Android Bench 为此加入了一些防护措施,例如在任务文件中加入基准测试常用的 canary 字符串,降低任务被纳入训练语料的可能性。官方也会人工审查 Agent 的执行轨迹,判断成功是否来自真实修复,而不是利用测试漏洞或问题描述不足进行“投机”。
这类防护无法让基准测试完美无缺,但它体现了一个重要原则:AI 编程评测不仅要看最后是否通过测试,也要看通过测试的过程是否合理。
Android 开发者能从中得到什么
对普通 Android 开发者来说,Android Bench 有几个实际意义。
第一,它可以帮助我们选择 AI 编程工具。不同模型在 Android 项目中的表现差异很大,通用聊天能力强,不等于 Android 工程能力强。
第二,它提示我们如何设计自己的团队评测。如果公司内部想引入 AI Code Review 或 AI 修复工具,可以参考 Android Bench 的思路,用真实 Issue、真实测试和人工审核来构造内部基准。
第三,它让我们看到 AI 编程能力的短板。即使顶尖模型,也不代表能稳定解决所有 Android 问题。复杂项目、隐含业务规则、多模块依赖和平台行为变化,仍然需要工程师判断。
第四,它强调测试的重要性。没有可运行的测试,模型就很难知道自己的修改是否正确,人也很难判断 AI 输出是否可靠。
对团队落地 AI 编程的启发
如果团队想把 AI 引入 Android 开发流程,可以从 Android Bench 中借鉴几条经验。
首先,任务要真实。不要只用算法题或玩具项目评估模型,而要用团队真实遇到的问题。
其次,验证要自动化。模型生成代码后,必须通过测试、构建、静态检查等机制验证。
再次,提示词要包含足够上下文。Android Bench 会给模型明确的问题描述和项目环境,团队内部使用 AI 时也应该给出清晰任务、约束和验收标准。
最后,人工审核仍然不可省。AI 可以加速修复和排查,但最终是否合并代码,仍然要看代码质量、架构影响和业务语义。
小结
Android Bench 是一个面向 Android 开发真实问题的 AI 编程评测体系。它用开源项目中的真实 Issue 和 Pull Request 构造任务,要求模型修改代码并通过测试,从而评估模型是否具备实际 Android 工程能力。
它最值得关注的地方,不只是排行榜数字,而是背后的评测思想:
- 用真实任务衡量模型
- 用测试验证结果
- 用人工审核保证任务质量
- 用成功率、成本和延迟综合评价
- 用开放数据和框架提升透明度
对 Android 开发者来说,Android Bench 是选择 AI 编程工具的参考,也是设计团队内部 AI 评测流程的样板。未来 AI Agent 越深入软件开发,这类贴近真实工程的基准测试就越重要。