你的 Android App 可能白白损失了 35% 的性能——R8 全模式配置详解

字节跳动的工程师优化启动速度时，可能花了数周分析 trace、改代码；Monzo 的团队却只改了一行配置，性能指标全线提升了 35%。这不是段子，是 Google 官方 blog 2026 年 3 月底发出来的案例。

问题来了：你的项目，是不是也开着 R8，但根本没用对？

R8 到底做了什么——大多数人理解是错的

很多人对 R8 的理解停留在「代码混淆 + 压缩」。打开 minifyEnabled true，觉得任务完成了。

但 R8 实际上分两种工作模式：

• 兼容模式（Compatibility Mode）：行为对齐旧版 ProGuard，默认使用这个。它保留了很多 ProGuard 时代的限制，很多优化是关闭的。

• 全模式（Full Mode）：R8 自有的激进优化，包括更深的内联、死代码消除、类合并、接口去虚化等，是真正意义上的编译期性能优化。

类比一下：就像买了一辆运动型轿车，却一直挂在 ECO 省油模式跑——发动机在，推背感全没了。你打开了 minifyEnabled true，但没有显式开启全模式，跑的是兼容模式，相当于只用了 R8 一半的能力。

Monzo 的案例正好验证了这一点。他们的 Android 应用已经在用 R8，但切换到全模式之后，不需要改一行业务代码，冷启动、ANR 率、帧率全线改善，部分指标提升幅度达到 35%。

怎么开启 R8 全模式

只需要在 gradle.properties 里加一行：

# gradle.properties
android.enableR8.fullMode=true

就这一行。完整的配置参考如下：

# gradle.properties

# 开启 R8 全模式
android.enableR8.fullMode=true

# build.gradle (app module)
android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                         'proguard-rules.pro'
        }
    }
}

注意这里用的是 proguard-android-optimize.txt 而不是 proguard-android.txt，前者已经包含了一些推荐的优化规则。

全模式具体做了哪些优化

说"一行配置提升 35%"，听起来很玄，但背后都是有具体机制的。全模式打开了哪些优化？

1. 更激进的内联（Inlining）

R8 全模式会把小方法直接内联到调用点，消除方法调用开销。尤其是大量使用 Kotlin 扩展函数、Lambda 的代码库，内联效果明显。

// 原始代码
fun Context.isNetworkAvailable(): Boolean {
    val cm = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    return cm.activeNetworkInfo?.isConnected == true
}

// R8 全模式会将这类小函数在调用点直接展开
// 消除了函数调用的虚方法分派开销

2. 类合并（Class Merging）

将继承链上的单一子类与父类合并，减少类的数量，降低 dex 体积，提升类加载速度。这在使用了大量抽象层的架构代码中效果显著。

3. 接口去虚化（Interface Devirtualization）

原来每次调用接口方法，ART 都要查一遍"谁实现了这个接口"——类似派件时要翻全市快递员花名册。R8 全模式发现某接口只有一个实现时，直接把调用打给那个实现类，省掉查表的时间，后续还能进一步内联。

4. 更彻底的死代码消除

全模式对"无法到达的代码"判断更保守，能消除更多在兼容模式下被保留的代码路径。

5. 字段和参数优化

未使用的字段、不需要的方法参数会被消除，减少对象大小和方法签名复杂度。

这些优化叠加在一起，对启动速度的影响路径很直接：

升级到全模式的风险：别被这几个坑踩到

全模式优化更激进，意味着对 ProGuard 规则的要求也更严格。不写对规则，会出现运行时崩溃。以下几类是高频问题：

反射调用的类会被消除

全模式对"是否真正使用"的判断更严，通过反射访问的类、字段、方法如果没有显式保留，可能被消除。

# proguard-rules.pro

# 保留通过反射访问的 model 类
-keep class com.example.app.model.** { *; }

# 保留 Gson 序列化相关
-keepattributes Signature
-keepattributes *Annotation*
-keep class com.google.gson.** { *; }

# 保留通过字符串名称动态调用的方法
-keepclassmembers class * {
    @com.example.annotation.Keep *;
}

接口单一实现被合并后，某些框架会失效

如果你用了 DI 框架（Hilt、Koin 等），框架内部依赖接口实现类型识别，类合并可能破坏这个机制。遇到奇怪的 DI 注入错误，先检查这一点。

# 保留 DI 相关接口和实现
-keep interface com.example.app.di.** { *; }
-keep class * implements com.example.app.di.** { *; }

@SerializedName 注解被删除

全模式下注解的保留要更显式地声明。Gson/Moshi 等序列化库依赖字段注解，必须加：

-keepattributes *Annotation*
-keepclassmembers,allowobfuscation class * {
    @com.google.gson.annotations.SerializedName ;
}

验证策略：先在 QA/Staging 跑一轮，再上 Release

R8 全模式最好的验证方式是：开启 minifyEnabled true 并在 debug 构建类型里也启用，然后跑完整的 UI 自动化测试。一旦有崩溃，立刻能看到 stacktrace。

Baseline Profiles：R8 之外的启动加速利器

如果 R8 全模式是编译期的优化，Baseline Profiles 就是运行期的先手——告诉 ART "这些代码我启动时肯定会跑，提前给我编译好"。

两者叠加，是目前 Android 启动优化性价比最高的组合。

// build.gradle
plugins {
    id 'androidx.baselineprofile'
}

dependencies {
    baselineProfile project(':baselineprofile')
}

// baselineprofile/src/main/java/.../BaselineProfileGenerator.kt
@ExperimentalBaselineProfilesApi
class BaselineProfileGenerator {
    @get:Rule
    val baselineProfileRule = BaselineProfileRule()

    @Test
    fun startup() = baselineProfileRule.collect(
        packageName = "com.example.app"
    ) {
        // 覆盖启动路径
        pressHome()
        startActivityAndWait()
        // 覆盖关键用户旅程
        device.findObject(By.text("首页")).click()
    }
}

生成 Baseline Profile 之后，R8 在编译时会根据这份 profile 决定哪些类需要 AOT 编译。R8 全模式 + Baseline Profiles 的组合，在 Google 的内部数据里，冷启动提升通常在 30%~50% 区间。

Monzo 案例完整拆解

回到 Monzo 案例。他们的操作步骤其实很清晰：

• 原本已有 R8 但跑兼容模式

• 先在 QA 环境开启全模式，跑自动化测试找问题

• 发现部分反射相关代码崩溃，补充 keep 规则

• 修复完上 Beta 灰度，用 Firebase Performance 监控关键指标

• 全量发布后，冷启动时间、ANR 率、渲染帧率全线改善

他们报告的具体数据：

这个案例的价值在于：大型工程往往有很多"改起来成本很高"的优化点，而 R8 全模式是真正的低垂果实——改动小，收益大，风险可控。

TikTok 的另一个视角：Compose 重构带来的渲染性能提升

同期还有另一个值得关注的案例。TikTok 在将部分页面从传统 View 体系迁移到 Jetpack Compose 之后，代码体积减少了 58%，同时也解决了 View 层级过深带来的渲染卡顿问题。

两个案例放在一起，其实说明同一件事：Android 性能优化的第一步，是消除架构层的浪费，而不是堆监控和手动调参。

View 层级深导致 measure/layout/draw 多次传递，和 R8 没有用全模式导致 dex 体积虚胖、方法调用链过深，本质都是同一类问题——系统在做大量本可以避免的工作。

一个你现在就能做的 Checklist

如果你的项目还没有做这些，现在就能开始：

• 检查 gradle.properties 是否有 android.enableR8.fullMode=true，没有就加上

• 确认 release 构建用的是 proguard-android-optimize.txt 而非 proguard-android.txt

• 用 ./gradlew app:printSeedsR8（AGP 8.x）检查哪些类被保留，确认没有不必要的 keep

• 在 CI 的 QA 构建中加入 R8 全模式，先用 Monkey 或 UI 自动化跑一遍

• 上线后用 Firebase Performance 或 Android Vitals 对比冷启动 P90 数据

• 接下来再看 Baseline Profiles——两者叠加效果更好

不需要一次性做完，把这个 Checklist 作为 Sprint 里的一个小 ticket，两天内能完成前四步。

值得继续探索的方向

R8 全模式只是编译器优化的入门。往下走还有几个方向：

• 自定义 R8 规则 DSL：AGP 8.x 开始支持更细粒度的规则配置，可以精确控制哪些类允许合并、哪些接口允许去虚化

• R8 的 -whyareyoukeeping 诊断：搞清楚为什么某个类没被消除，是 keep 规则太宽了还是有真实引用

• 结合 Baseline Profiles 的分层优化：先用 Baseline Profiles 覆盖启动路径，再用全模式做全局 dex 优化，两者作用层不同，不冲突

• 观察 Android 17 的新性能 API：Beta 3 已达到 Platform Stability，新的 Profiling API 和内存管理改进值得关注

性能优化最容易犯的错误，是把精力全放在业务代码层，忽视工具链和编译器能帮你做的事。R8 全模式就是一个典型的例子——一行配置，35% 的提升，但很多团队根本不知道这个开关的存在。

参考资料：Monzo boosts performance metrics by up to 35% with a simple R8 update（Android Developers Blog）/ TikTok reduces code size by 58% with Jetpack Compose（Android Developers Blog）/ R8 Compatibility FAQ（developer.android.com）