Android Developers Blog 于2026年8月18日报道，Tinder使用新的 R8 Configuration Analyzer 移除了 Android 优化中的隐藏阻碍。根据这篇文章，结果是遭遇慢冷启动的用户减少47%，下载体积变小，用户感知的 ANR 减少，DEX 布局也更简单。
这件事有价值，因为它并不是一个新功能开关或营销式基准测试。它具体说明了构建配置也会变成运行时债务。Tinder 已经启用了 R8，但 Google 表示，由于过宽的 keep 规则阻止了过多代码的压缩、优化和混淆，应用中仍有很大一部分无法被优化。
Tinder 的 Android 构建发生了什么变化
根据 Android Developers 的文章，Tinder 的 Android 应用复杂度已经增长到约70%的应用代码没有得到优化。该应用有17个 DEX 文件，其中3个与启动有关。团队使用 R8 Configuration Analyzer 检查 keep 规则的影响，并发现一个内部库中的规则范围过宽。
在细化这条规则后，Google 称 Tinder 的 R8 优化分数从28%提升到50%。文章报告的用户侧效果包括：遭遇慢冷启动的用户减少47%，应用下载体积从86.6 MB降至61.5 MB，用户感知的 ANR 从0.35%降至0.28%，总 DEX 文件数从17个降至11个。
这些数字来自公开案例研究，而不是独立基准测试。不过，对 Android 团队来说，其机制是可信的：过于防御性的 keep 规则可能阻止 R8 删除未使用代码、内联方法、合并类、重命名符号，以及以减少应用体积和启动工作量的方式重塑代码。
为什么 keep 规则重要
R8 keep 规则通常用于避免反射、生成代码、依赖注入、序列化或第三方 SDK 带来的运行时故障。实际问题在于，范围过宽的规则可能保护远超预期的代码。它可能避免一种崩溃，同时悄悄阻止无关包的优化。
Android 的官方 R8 Configuration Analyzer 文档称，该工具跟踪压缩、优化和混淆分数，并帮助团队发现范围过宽、冗余、过时、重复或被包含的规则。它可以在 AGP 9.3.0 或更高版本中作为独立 Gradle 任务运行，也可以与 R8 9.3.7-dev 或更高版本配合使用，因此比每次配置实验都构建完整 APK 或 app bundle 具有更短的反馈循环。
这才是关键工程经验。分析器不会神奇地让应用变快。它提供一份报告，让团队提出更好的问题：哪条 keep 规则阻止了最多代码，哪一个库引入了这条规则，反射是否真的需要这么大范围，以及更窄的规则能否在保持正确性的同时恢复优化空间。
冷启动为什么是重点
Android 的应用启动文档解释说，冷启动是成本最高的启动状态，因为系统必须创建应用进程，而应用随后还要初始化对象、创建主 Activity、初始化界面并绘制第一帧。Android 建议以冷启动为假设进行优化，因为这类改进也可能帮助温启动和热启动。
因此，Tinder 的案例不只是一个减小体积的故事。更少的启动 DEX 文件和更多经过优化的代码，可以减少第一块可用界面出现之前所需的工作。Google 还把启动质量与 Android vitals 联系起来，包括 time to initial display 和 time to full display 等指标，这些指标帮助团队判断一次启动只是可见，还是已经真正可用。
开发者应该吸取什么
谨慎的结论不是每个 Android 应用都能获得 Tinder 这样的提升。Tinder 的起点、代码库形态、内部库、测量方法和用户群都具有自身特点。可迁移的经验是流程：审计 keep 规则，测量其优化影响，缩小不必要的宽规则，并把分析器接入 CI，让回归在进入生产环境之前就可见。
对大型 Android 团队来说，最大的风险是把旧配置视为无害。keep 规则容易累积，因为删除一条规则看起来比保留它成本更高。Tinder 的案例展示了相反的风险：未经审查的规则可能变成每个用户打开应用时都要支付的性能税。
对小团队来说，实际做法是把分析器当作诊断工具，而不是重写触发器。先处理影响最大的 keep 规则，确认每条规则为什么存在，测试更窄的替代规则，并在发布前验证行为。目标不是为了激进压缩而压缩，而是让 R8 安全地优化能够优化的代码，同时只保护真正需要保护的代码。