[Android 从零到一] Android 冷启动治理：用 Macrobenchmark 与 Baseline Profile 建立性能闭环

Android 冷启动治理：用 Macrobenchmark 与 Baseline Profile 建立性能闭环

启动优化最容易陷入两个误区：凭体感判断快慢，或者看到 Application.onCreate() 耗时下降就宣布完成。真实用户感受到的启动过程更长，它从点击图标开始，直到首帧可见、页面能够交互才结束。设备性能、安装状态、系统缓存和测试方式都会影响结果。

本文从指标定义开始，逐步搭建可重复的 Macrobenchmark 测试，再用系统 Trace 定位主线程阻塞，最后通过 Baseline Profile 优化关键代码路径，并把性能门槛接入持续集成。目标不是得到一次漂亮的数字，而是建立能够长期发现回退的工程闭环。

先说清楚测量对象

Android 启动通常分为三种状态：

• 冷启动：应用进程不存在，系统需要创建进程、加载代码并创建首个页面。
• 温启动：进程仍在，但 Activity 需要重新创建。
• 热启动：进程和 Activity 都存在，页面主要从后台回到前台。

线上最值得重点治理的是冷启动，因为它包含的工作最多，也最容易暴露类加载、磁盘读取、依赖初始化和首屏渲染问题。测试时必须明确使用哪种启动模式，否则不同构建之间的数据没有可比性。

还要区分两个常见指标：

• timeToInitialDisplayMs：应用首帧显示所需时间，更接近“用户看到页面”的时刻。
• timeToFullDisplayMs：应用主动报告内容已完整可用所需时间，适合首屏还要等待关键数据的场景。

首帧很快但只显示空壳，并不代表体验好；所有数据都加载完成后才绘制首帧，也会让用户长时间面对启动窗口。更合理的策略是尽快提供稳定、可理解的首帧，再逐步填充非关键内容。

为什么不能只看日志时间

在 Application 和 Activity 中记录时间戳可以帮助定位局部代码，却不适合作为最终启动指标。它看不到进程创建之前的系统工作，也容易受日志、调试器和手工操作影响。

可靠的性能测试至少要满足这些条件：

• 使用可发布构建，避免调试功能和未优化字节码干扰结果；
• 在同一设备、相近温度和电量状态下执行；
• 多次迭代并观察中位数与高分位，而不是挑选最好结果；
• 明确是否清理进程、编译状态和应用数据；
• 自动完成启动动作，减少人工操作误差。

Jetpack Macrobenchmark 正是为这种跨进程、接近真实环境的测量设计的。它把测试代码放在独立模块中，通过系统接口启动目标应用，并输出启动指标与可分析的 Trace。

创建 Macrobenchmark 模块

可以通过 Android Studio 的模块模板创建 Benchmark Module。典型项目结构如下：

app/
benchmark/
  src/main/AndroidManifest.xml
  src/main/java/.../StartupBenchmark.kt

基准模块依赖 Macrobenchmark 和测试运行器：

plugins {
    id("com.android.test")
    id("org.jetbrains.kotlin.android")
}

android {
    namespace = "com.example.app.benchmark"
    targetProjectPath = ":app"

    defaultConfig {
        minSdk = 23
        testInstrumentationRunner =
            "androidx.test.runner.AndroidJUnitRunner"
    }
}

dependencies {
    implementation("androidx.test.ext:junit:1.2.1")
    implementation("androidx.test.uiautomator:uiautomator:2.3.0")
    implementation("androidx.benchmark:benchmark-macro-junit4:1.3.4")
}

版本应跟随项目的依赖管理统一维护。目标应用需要提供 profileable 能力，Benchmark 模板通常会通过专用构建类型完成配置，不要为了跑测试把正式包改成可调试。

编写可重复的冷启动测试

一个最小的冷启动基准如下：

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun coldStartup() = benchmarkRule.measureRepeated(
        packageName = "com.example.app",
        metrics = listOf(StartupTimingMetric()),
        compilationMode = CompilationMode.Partial(
            baselineProfileMode = BaselineProfileMode.Require
        ),
        startupMode = StartupMode.COLD,
        iterations = 10,
        setupBlock = {
            pressHome()
        }
    ) {
        startActivityAndWait()
    }
}

startActivityAndWait() 会等待目标页面完成初始绘制。StartupMode.COLD 保证每轮从无应用进程的状态开始。迭代次数需要在执行时间和数据稳定性之间权衡，本地排查可以少一些，发布基线应保留足够样本。

如果首页受登录态、隐私弹窗或新手引导影响，测试必须先构造稳定状态。不要在测量代码块中通过网络登录，这会把外部服务波动混进启动耗时。更合适的方式是使用测试账号、预置数据或专用的可控入口，并保证它们不会进入生产行为。

正确标记完整显示

首屏关键内容来自异步数据时，可以在数据已经展示且页面可交互后调用：

reportFullyDrawn()

对于 Compose 页面，可以使用 Activity 的 reportFullyDrawn()，也可以结合 ReportDrawn 相关 API，让报告时机与必要条件绑定。关键是先定义“完整”的产品语义，例如：

• 首页骨架已经替换为真实内容；
• 首屏列表至少有可操作条目；
• 关键本地数据已读取完成；
• 网络失败时，明确的错误页已经可操作。

不要等待埋点、推荐预取或次要角标等非关键任务。完整显示指标应该代表用户可以开始主要操作，而不是后台工作全部结束。

从 Trace 找到真正的阻塞点

Macrobenchmark 结果会附带系统 Trace。使用 Android Studio Profiler 或 Perfetto 打开后，重点观察主线程从进程启动到首帧之间的切片：

• bindApplication：应用绑定和 Application 创建；
• activityStart 与生命周期回调：首个 Activity 创建过程；
• Choreographer#doFrame：首帧调度与绘制；
• inflate、measure、layout：传统 View 的布局成本；
• Compose 组合、布局和绘制相关切片；
• 锁等待、磁盘 I/O、类加载与 GC。

对于业务代码，可以用 androidx.tracing 增加语义明确的切片：

trace("HomeRepository#warmLocalCache") {
    repository.warmLocalCache()
}

Trace 名称应描述业务动作，避免只写 init 或 load。标记范围也不要过大，否则只能确认“启动慢”，无法定位具体责任。

排查时先找关键路径上的长任务，再判断它是否必须在首帧之前完成。启动优化的核心通常不是让每个任务都快一点，而是减少首帧关键路径上的工作。

把初始化分成不同优先级

可以把启动任务划分为三类：

• 首帧必需：主题、首屏布局、最小导航状态、首屏所需本地数据；
• 可延后：埋点上传、远程配置刷新、非首屏数据库预热；
• 按需执行：仅在某项功能首次使用时初始化的 SDK 或组件。

常见问题是所有 SDK 都在 Application.onCreate() 中同步初始化。即使单项只占几十毫秒，叠加后也会形成明显阻塞。治理时可以使用 App Startup 声明依赖关系，但它不会自动让初始化变快。真正重要的是删除无用初始化、延后非关键任务，并避免主线程磁盘访问。

例如，把不影响首帧的初始化放到页面稳定后执行：

class DeferredInitializer(
    private val analytics: Analytics,
    private val remoteConfig: RemoteConfig
) {
    suspend fun initialize() = withContext(Dispatchers.Default) {
        analytics.initialize()
        remoteConfig.refreshIfNeeded()
    }
}

“放到协程”不等于没有成本。任务仍会竞争 CPU、触发类加载和 I/O，过早并发还可能拖慢主线程。应根据 Trace 验证调度时机，而不是机械地把同步调用改成 launch。

Baseline Profile 解决什么问题

Android Runtime 会根据使用情况对代码进行即时编译和配置文件引导优化。刚安装或升级后的应用缺少运行历史，关键启动路径可能需要解释执行或即时编译，导致启动与页面切换变慢。

Baseline Profile 提前描述常用代码路径。应用安装时，系统可以据此编译关键方法，让新安装用户也获得更稳定的性能。它特别适合优化：

• 应用启动；
• 首页渲染；
• 高频导航；
• 典型列表滚动和详情打开流程。

Baseline Profile 不是手写的方法名单，而应由真实交互自动生成。Profile 越大并不一定越好，纳入低价值路径会增加安装期编译成本和包内元数据。

生成贴近真实用户的 Profile

使用 Baseline Profile Gradle 插件与 BaselineProfileRule，把稳定的核心路径写成自动化场景：

@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {

    @get:Rule
    val rule = BaselineProfileRule()

    @Test
    fun generate() = rule.collect(
        packageName = "com.example.app",
        includeInStartupProfile = true
    ) {
        pressHome()
        startActivityAndWait()

        device.findObject(By.text("推荐")).click()
        device.waitForIdle()

        device.findObject(By.res("com.example.app", "feed_list"))
            .setGestureMargin(device.displayWidth / 5)
            .fling(Direction.DOWN)
    }
}

生成场景应稳定、短小，并覆盖真实高频路径。依赖文案定位控件容易因国际化或产品改版失效，优先使用稳定的资源 ID 或语义标识。涉及网络的页面需要提供可预测的数据，否则 Profile 会随着环境变化而漂移。

生成后，应确认 Profile 已合并到应用产物，并检查 release 构建中的相关报告。仅仅让生成测试通过，不代表最终 APK 或 App Bundle 已携带 Profile。

用对照实验验证收益

验证 Baseline Profile 时需要控制编译模式。可以分别执行无预编译和使用 Profile 的测试：

CompilationMode.None()

CompilationMode.Partial(
    baselineProfileMode = BaselineProfileMode.Require
)

关注中位数是否稳定改善，同时检查高分位是否出现异常。若结果没有变化，常见原因包括：

• Profile 没有打进目标构建；
• 自动化场景没有覆盖启动关键路径；
• 瓶颈主要是主线程 I/O、锁等待或网络，而不是代码执行；
• 测试设备状态不稳定；
• 启动工作被移动到首帧之后，但完整显示反而更慢。

性能优化必须通过对照数据证明。某项代码改动看起来更合理，不代表用户指标一定改善。

在持续集成中防止回退

模拟器适合做功能检查，但性能数据更容易受到宿主机负载影响。稳定的性能门禁最好运行在固定型号的实体设备上，并控制温度、后台进程和系统版本。

CI 可以保存这些产物：

• Macrobenchmark 的 JSON 结果；
• 对应构建版本与提交信息；
• 失败或异常样本的 Trace；
• 历史中位数和高分位趋势。

门槛不要只写成一个永远不变的绝对毫秒值。不同设备差异很大，更实用的方式是固定测试设备，并结合相对回退比例和最小变化量。例如，只有当中位数明显变慢且超过噪声区间时才阻止合并。

还应把实验室指标与线上 Android Vitals 或自建启动埋点结合。实验室测试负责快速定位回归，线上数据负责确认不同设备、系统版本和用户状态下的真实影响。

常见失败方式

使用 debug 包做结论

debug 构建包含调试开销，代码压缩和编译行为也不同。它适合定位功能，不适合代表生产启动性能。

只优化 Application.onCreate

首屏 Activity、Compose 首次组合、资源加载和首屏数据读取同样位于关键路径。必须从系统启动到可交互状态整体观察。

把任务全部异步化

大量并发任务会争抢 CPU 和 I/O，还可能引入初始化时序问题。先判断任务是否必要，再决定延后、按需或并行。

只看最好的一次结果

最好结果通常代表理想缓存和调度状态，无法反映普通用户。应保留多次样本并查看中位数、高分位和离散程度。

生成 Profile 后不验证产物

插件配置、变体匹配或构建流程错误都可能让 Profile 没有进入发布包。必须用目标 release 变体做对照测试。

一套可执行的治理顺序

面对启动慢问题，可以按以下顺序推进：

• 定义首帧和完整可用的业务边界；
• 建立可重复的冷启动 Macrobenchmark；
• 固定设备和构建变体，采集初始基线；
• 用 Trace 找出首帧关键路径上的长任务；
• 删除、延后或按需初始化非关键工作；
• 生成覆盖启动和高频路径的 Baseline Profile；
• 使用不同编译模式做对照实验；
• 保存结果与 Trace，在持续集成中监控回退；
• 结合线上数据验证真实用户收益。

总结

启动性能治理不是在生命周期方法里散落几个时间戳，也不是一次性移动初始化代码。Macrobenchmark 提供可重复、接近真实环境的测量，系统 Trace 解释时间花在哪里，Baseline Profile 改善新安装和升级后的关键代码执行，而持续集成与线上指标负责守住长期效果。

先统一指标，再定位关键路径；先减少不必要工作，再优化剩余代码。只有测量、分析、修改和回归验证形成闭环，启动速度才会从一次专项优化变成可持续维护的工程能力。