[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 改善新安装和升级后的关键代码执行，而持续集成与线上指标负责守住长期效果。
先统一指标，再定位关键路径；先减少不必要工作，再优化剩余代码。只有测量、分析、修改和回归验证形成闭环，启动速度才会从一次专项优化变成可持续维护的工程能力。
浙公网安备 33010602011771号