谷歌的 Android Runtime（ART）团队在不牺牲代码质量、不增加峰值内存使用的情况下，成功将Android代码的编译时间减少了18%，这显著提升了即时编译（JIT，just-in-time）和提前编译（AOT，ahead-of-time）的性能。
正如谷歌软件工程师 Santiago Aboy Solanes 和 Vladimír Marko 所解释的那样，JIT 编译代码的编译时间缩短后，运行时优化能更早启动，从而直接提升设备的整体性能。对于 JIT 和 AOT 编译的代码而言，更快的构建过程可减轻设备的负担，改善电池续航和发热管理的性能，尤其在低端硬件上效果更为明显。
Aboy 和 Marko 强调，在不损害生成代码的性能或增加其内存需求的前提下减少编译时间至关重要。他们指出，通常让编译器运行得更快意味着必须在其他方面做出妥协，但这次的情况有所不同：
我们唯一愿意投入的资源，就是自己的开发时间，深入挖掘、仔细调研，并找到能够满足这些严格标准的巧妙解决方案。接下来，让我们更详细地看看我们是如何识别可改进之处，并为各种问题找到合适解决方案的。
他们的工作聚焦于三大关键举措。首先，使用pprof等工具对编译时间进行细致测量，建立变更前后的性能基线。然后，选取一组具有代表性的第一方和第三方应用，连同 Android 操作系统本身，用来分析典型工作负载并验证潜在的解决方案。
通过这套精心挑选的 APK，我们在本地手动触发编译，获取编译过程的性能剖析数据，并利用
pprof可视化时间的消耗分布。[…]pprof的功能很强大，支持对数据进行切片、过滤和排序，例如，清晰地展示哪些编译阶段或方法占用了最多时间。
在此基础上，ART 工程师通过多种手段减少了编译器内部各阶段的不必要工作，比如，跳过无实际效果的迭代、利用启发式算法和额外缓存避免昂贵的计算、延迟计算以消除冗余循环、简化抽象层等。
要事先判断哪些优化值得投入，这需要格外谨慎，以避免无效的劳动。
有时候，即便发现某个环节耗费大量的编译时间，并投入了开发精力尝试优化，但依然有可能找不到可行的解决方案，这也许根本无计可施，也可能实现成本过高，还可能会显著恶化其他指标，又或者会大幅增加代码库的复杂度。
为此，ART 团队力求快速评估每项指标在最小投入下可能获得的改进空间。这包括借助已收集的历史指标、依靠经验直觉、构建快速但粗糙的原型，最终再实现完善的解决方案。
Aboy 和 Marko 还列举了部分已实现的优化措施，例如，将FindReferenceInfoOf的查找复杂度从 O(n)降至 O(1)、借助引用来传递数据结构以避免不必要的创建与销毁、缓存已计算的值等，此外还有许多其他优化因篇幅所限无法一一详述。
其中部分提速优化已经在 2025 年 6 月的 Android 版本中发布，其余优化则包含在年底发布的版本中。此外，Android 12 及更高版本还可通过主线更新获得这些改进。
原文链接：
Google Boosts ART Compile Times by 18% Without Compromising Code Quality
