## Android 启动优化先把慢在哪里说清楚

Android 启动优化 最容易被做成一堆零散技巧：压缩图片、删日志、延迟初始化、上基线配置，看起来都对，但最后首帧还是慢。原因通常不是没有技巧，而是没有把启动阶段拆成可验证的链路。真正该先回答的问题是：时间到底花在 zygote fork 之后的哪一段，是 Application 初始化、ContentProvider 提前执行、首屏布局 inflate，还是某个 SDK 在主线程做了你根本没注意到的 IO。

我做 Android 启动优化 时，第一步永远不是改代码，而是把启动拆成冷启动路径图。你先知道有哪些初始化一定要在首帧前完成，哪些可以延后到首帧后、空闲时、用户触发后，再决定怎么拆。很多项目之所以越优化越乱，就是因为没有先定义“什么叫必须现在做”。

## Android 启动优化先用这套拆法

如果 Application 里已经塞满初始化，我会先按四类拆：首帧必须、登录态必须、会话内延迟、完全按需。Android 启动优化 不怕拆得细，怕的是所有模块都说自己必须首帧完成。你必须反过来问：如果这个模块晚 3 秒初始化，用户第一屏会不会坏？如果不会，它就不该挡在首帧前。

一个实用的顺序是：先删无意义串行，再把依赖不强的模块并行化，最后把可感知度低的模块移到首帧后。这样做的好处是每一步都能测，出了问题也容易回滚。别一上来就同时改线程模型、SDK 初始化顺序和页面渲染逻辑，副作用太大。

## Android 启动优化关键代码

1. 先给初始化打点

inline fun  traceCost(section: String, block: () -> T): T {
    Trace.beginSection(section)
    val start = SystemClock.elapsedRealtime()
    return try {
        block()
    } finally {
        val cost = SystemClock.elapsedRealtime() - start
        Log.d("StartupTrace", " cost=ms")
        Trace.endSection()
    }
}

2. 把初始化按优先级拆开

class App : Application() {
    override fun onCreate() {
        super.onCreate()

        traceCost("init-core") {
            initCrashReporter()
            initRouting()
        }

        ProcessLifecycleOwner.get().lifecycleScope.launch {
            delay(500)
            traceCost("init-deferred") {
                initAnalytics()
                initRemoteConfig()
            }
        }
    }

    private fun initCrashReporter() = Unit
    private fun initRouting() = Unit
    private fun initAnalytics() = Unit
    private fun initRemoteConfig() = Unit
}

3. 用 Jetpack Startup 管理依赖关系

class CoreInitializer : Initializer {
    override fun create(context: Context) {
        traceCost("CoreInitializer") {
            // init core components
        }
    }

    override fun dependencies(): List>> {
        return emptyList()
    }
}

## Android 启动优化常见坑

第一个坑是把三方 SDK 都当成不可动的黑盒。很多 SDK 默认初始化方式只是“最方便接入”，不代表最适合你的启动阶段。有的可以延后，有的可以只在登录后初始化，有的可以在子进程禁用。

第二个坑是把并行化当成万能答案。并行确实能缩短总时长，但如果主线程仍然在等结果、锁竞争更严重、线程池被挤爆，那只是换一种方式慢。Android 启动优化 的目标不是把任务分散出去，而是把首帧前的阻塞工作真正变少。

## Android 启动优化报错与排查

1. 首帧已经出来但仍感觉卡

adb shell am start -W com.example.app/.MainActivity
adb shell atrace --async_start am wm gfx view sched freq idle binder_driver
adb shell atrace --async_stop am wm gfx view sched freq idle binder_driver > startup_trace.txt

2. 启动优化后出现功能偶发失效

class InitGate {
    private val ready = AtomicBoolean(false)

    fun markReady() {
        ready.set(true)
    }

    fun isReady(): Boolean = ready.get()
}

## Android 启动优化工具与验证

我自己会优先用这几样：m start -W 看总耗时，Trace/Perfetto 看阶段分布，Macrobenchmark 看持续回归，Baseline Profile 看热路径优化。只要这几个工具搭起来，Android 启动优化 的改动就能从一次性救火变成可持续治理。

@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
    @get:Rule
    val rule = BaselineProfileRule()

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

## Android 启动优化结论与下一步

Android 启动优化 真正有效的做法，从来不是收集更多技巧，而是先定义启动阶段，再量化每段耗时，再把首帧前必须执行的代码压到最少。下一步建议很清楚：先把现有初始化按四类重标，再对首帧前 Top 5 耗时点逐个拆分，最后把 Macrobenchmark + Baseline Profile 接进回归链。

## Android 启动优化可运行片段

data class StartupMetric(
    val section: String,
    val costMs: Long,
    val critical: Boolean
)

fun reportStartupMetric(section: String, costMs: Long, critical: Boolean): StartupMetric {
    return StartupMetric(section, costMs, critical)
}