hen多团队在面对启动慢的投诉时会直接把 SDK 挂起、把图片加载改成懒加载，却往往只收获几毫秒的提升。真正想让用户感受到“瞬间打开”，必须先把问题拆得细致、再用数据说话。本文会手把手演示，利用 Perfetto 捕捉全链路事件，用 Macrobenchmark 把测量变成可重复、可比对的实验，并辅以自定义 Trace 与 Baseline Profile，让每一次优化dou有据可依。

Perfetto Neng告诉你“发生了什么”，但一次 trace 只是瞬间快照。Ru果你在手机闲置时跑了一次它可Neng显得hen快；在后台跑着大量任务时又可Neng显得异常慢。要判断改动是否真正带来收益，需要在相同环境下多次运行，这正是 Macrobenchmark 的价值所在。

COLD 启动进程从未存在需要完整的加载和初始化。

WARM 启动进程Yi在内存，只是 Activity 被销毁后 创建。

Baseline Profile一份列举启动阶段必需类/方法的清单，交给系统提前 AOT 编译，以削减 JIT 开销。

下面的步骤既适用于本地调试，也Ke以直接搬到 CI 环境：

plugins {
    id
    id
}
android {
    namespace = "com.example.benchmark"
    compileSdk = 34
    defaultConfig {
        minSdk = 21
        targetSdk = 34
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }
    // 基于 release，保持真实用户体验
    targetProjectPath = ":app"
    experimentalProperties = true
}
dependencies {
    implementation
    implementation
    implementation
}

android {
    buildTypes {
        create {
            initWith)
            signingConfig = signingConfigs.getByName
            isDebuggable = false          // 避免泄露调试信息
            // 必须打开 profileable，才Neng让宏基准测试采集到内部 slice
            manifestPlaceholders = true
        }
    }
}

我们关心的主要 data source 包括：

linux.ftrace

android.atrace

linux.process_stats

# perfetto_startup.cfg
duration_ms: 12000   # 大多数冷启动足够覆盖
data_sources {
  config {
    name: "linux.ftrace"
    ftrace_config {
      ftrace_events: "sched/sched_switch"
      ftrace_events: "sched/sched_wakeup"
      atrace_categories: "am"
      atrace_categories: "wm"
      atrace_categories: "view"
      atrace_categories: "dalvik"
      atrace_apps: "com.example.myapp"
    }
  }
}
data_sources {
  config {
    name: "linux.process_stats"
  }
}

Android 自带的 slice 粒度有时太粗，想要追踪某个 SDK 的初始化时间，只Neng自己埋点。下面提供一个 Kotlin 函数，把代码块包装成 Perfetto 可识别的区段：

inline fun  traceBlock->T): T {
    Trace.beginSection
    return try { block } finally { Trace.endSection }
}
// 示例：把网络 SDK 初始化包装起来
traceBlock { NetworkSDK.init }

使用这种方式，你在宏基准测试里添加对应的 TraceSectionMetric 即可直接得到每段代码的耗时。

@LargeTest
@RunWith
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule
    @Test
    fun coldStart = benchmarkRule.measureRepeated(
        packageName = "com.example.myapp",
        metrics = listOf(
            StartupTimingMetric,
            TraceSectionMetric,
            TraceSectionMetric,
            TraceSectionMetric,
            TraceSectionMetric
        ),
        iterations = 10,
        startupMode = StartupMode.COLD,
        setupBlock = {
            pressHome
            // 确保是真正的冷启动，可选清除缓存：
            // device.executeShellCommand
        }
) {
        startActivityAndWait
        // 若有 splash → 主页面等待特定 View 出现：
        // device.wait), 10_000)
}
   @Test
   fun warmStart = benchmarkRule.measureRepeated(
       packageName = "com.example.myapp",
       metrics = listOf),
       iterations = 10,
       startupMode = StartupMode.WARM,
       setupBlock = { pressHome }
   ) { startActivityAndWait }
}

关键点提醒：

Atraces 中必须填入正确的包名，否则自定义 slice 会被过滤掉。

iterations 越多统计意义越强，一般不少于八次。

COLD 与 WARM 两种模式帮助我们分辨是进程加载还是 UI 渲染导致卡顿。

Bare‑metal 的 AOT 编译成本高，而 Baseline Profile 则只针对启动期间真正需要的方法Zuo预编译，体积增长微乎其微，却Neng把“解释执行”时间压缩到几百毫秒以下。

@ExperimentalBaselineProfilesApi
@RunWith
class BaselineProfileGenerator {
   @get:Rule val rule = BaselineProfileRule
   @Test
   fun generate = rule.collect {
       pressHome
       startActivityAndWait
       // 模拟用户常走的几个页面提高覆盖率
       device.wait), 10_000)
       device.findObject)?.click
       device.waitForIdle
       device.findObject)?.click
   }
}

The generated file should be committed under /app/src/main/.... 每次构建 Release APK 时AGP 会自动把它打包进去，让系统在安装阶段就完成对应类的方法编译。

Pefretto 提供了强大的 TraceProcessor，你Ke以将抓到的 pbtx 文件丢进命令行或 UI 界面用类似下面的 SQL 找出Zui长耗时块：

SELECT s.name,
       s.dur/1e6 AS dur_ms,
       p.name AS process_name,
       t.name AS thread_name
FROM slice s
JOIN thread_track tt ON s.track_id=tt.id
JOIN thread t ON tt.utid=t.utid
JOIN process p ON t.upid=p.upid
WHERE p.name='com.example.myapp'
  AND t.is_main_thread=1
ORDER BY s.dur DESC LIMIT 20;

常见的大块包括：

`bindApplication` → `ContentProvider#onCreate` : 第三方 SDK 常在这里偷偷Zuo网络请求或磁盘 I/O。

`dexopt` / `jit_compile`**：未使用 Baseline Profile 时会出现明显峰值。

name                         dur_ms   process_name     thread_name
ContentProvider:onCreate   312      com.example.myapp main  
ContentProvider:onCreate   198      com.example.myapp main  
...