App Startup 库真的能优化启动吗，实测数据

App Startup 库真的能优化启动吗，实测数据

从一个真实的启动崩溃说起

去年下半年我在处理一个线上启动崩溃时，第一次认真审视了 App Startup 这个库。当时的问题是：我们在 Application.onCreate 里初始化了一个 SDK，这个 SDK 内部又依赖了另一个 SDK，而那个 SDK 在初始化时会读取 SharedPreferences。崩溃堆栈显示是 android.app.SharedPreferencesImpl.awaitLoadedLocked 超时，但根因其实是初始化时序被打乱了——某个热修复框架在更早的时机插了一脚，导致 SharedPreferences 的磁盘加载和主线程初始化发生了竞争。

这个 bug 的修复过程让我意识到，我们的启动初始化完全是一团乱麻。十几个第三方 SDK 的 init 调用散落在 Application.onCreate、第一个 Activity 的 onCreate、甚至某个懒加载的单例里，依赖关系全靠口头约定。也就是这个时候，我开始研究 App Startup，想看看它能不能把这种混乱理顺，同时真的带来性能收益。

App Startup 的设计初衷与我的误解

App Startup 是 AndroidX 在 2020 年推出的库，当前稳定版本是 1.1.1。官方文档的描述很清晰：它提供了一种在 app 启动时初始化组件的标准化方式，核心是两个接口——Initializer<T> 和 StartupLogger。但我最初对这个库有一个根本性的误解：我以为它的主要价值是"并行初始化"和"性能优化"。

这个误解很普遍。很多文章把 App Startup 包装成"启动优化神器"，配图往往是复杂的依赖图变成简洁的 DAG，暗示它能自动帮你并行跑初始化任务。实际用过之后才发现，App Startup 的默认实现是完全同步、单线程、阻塞主线程的。它解决的是"依赖管理"和"模块化初始化"的问题，性能优化不是它的默认行为，甚至不是它的设计目标。

关键代码在 AppInitializer 类里，路径是 androidx.startup.AppInitializer。当你调用 AppInitializer.getInstance(context).initializeComponent(MyInitializer::class.java) 时，它走的是这个逻辑：

fun <T> initializeComponent(component: Class<out Initializer<*>>): T {
    val result = doInitialize(component, mutableSetOf())
    return result as T
}

private fun doInitialize(
    component: Class<out Initializer<*>>,
    initializing: MutableSet<Class<*>>
): Any {
    // 检测循环依赖
    if (initializing.contains(component)) {
        throw IllegalStateException("Cannot initialize $component. Cycle detected.")
    }
    
    val initialized = mInitialized.getOrDefault(component, null)
    if (initialized != null) {
        return initialized
    }
    
    val instance = component.getDeclaredConstructor().newInstance()
    val dependencies = instance.dependencies()
    
    // 递归初始化所有依赖
    for (dependency in dependencies) {
        doInitialize(dependency, initializing)
    }
    
    val result = instance.create(context)
    mInitialized[component] = result
    return result
}

这段代码没有任何线程切换，没有任何异步逻辑。dependencies() 返回的依赖列表会被递归地、深度优先地、同步地执行。如果你的初始化链条是 A → B → C，那执行时间就是三者之和，加上递归调用的栈开销。

第一个实验：基准测试与"负优化"

为了验证这个结论，我在一个 demo 工程里做了对比测试。设备是 Pixel 6，Android 13，demo 本身只有一个空 Activity，尽量减少干扰因素。

我设计了三种初始化方式：

第一种，传统的 Application.onCreate 顺序执行：

override fun onCreate() {
    super.onCreate()
    val t1 = SystemClock.elapsedRealtime()
    InitA.init(this)
    InitB.init(this) // B 依赖 A 的结果
    InitC.init(this) // C 依赖 B 的结果
    val t2 = SystemClock.elapsedRealtime()
    Log.d("Startup", "Total: ${t2 - t1}ms")
}

第二种，用 App Startup 的 Initializer：

class InitC : Initializer<InitC.Result> {
    override fun create(context: Context): Result {
        // C 的初始化逻辑
        return Result()
    }
    
    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf(InitB::class.java)
    }
}

然后在 AndroidManifest 里注册 provider：

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="com.example.InitC"
        android:value="androidx.startup" />
</provider>

第三种，手动并行：用 Kotlin 的 async/await 把无依赖的任务丢到线程池。

每个 Initializer 的 create() 方法里我加了 100ms 的 Thread.sleep 模拟耗时操作。A、B、C 形成线性依赖链。

测试结果（100 次取中位数）：

App Startup 比传统方式还慢了约 5%。这个差距来自 InitializationProvider 的 ContentProvider 初始化开销，以及 AppInitializer 内部的 Map 查找和递归调用。虽然 16ms 的绝对差距不大，但它明确说明了一个事实：如果你只是简单地把现有代码搬到 App Startup 的 Initializer 里，性能不会变好，可能还会略微变差。

这个实验我重复了多次，也换过设备（一加 9 Pro、小米 12），结论一致。ContentProvider 的启动时机确实比 Application.onCreate 更早，但"更早"不等于"更快"，尤其是当多个库的 Initializer 都通过 manifest 合并进来时，每个库都多了一层 provider 的间接调用。

踩坑：manifest 合并的暗战

说到 manifest 合并，这是我用 App Startup 时遇到最头疼的问题。

我们的项目依赖了 Firebase、Bugly、某推送 SDK、某统计 SDK，其中 Firebase Crashlytics 和 Bugly 都用了 App Startup。它们的 AndroidManifest 里都有 InitializationProvider 的注册，通过 tools:node="merge" 合并到最终 manifest 里。

问题出在"自动发现"机制。App Startup 的 InitializationProvider 默认会扫描 manifest 中所有带有 android:value="androidx.startup" 的 meta-data，自动初始化对应的 Initializer。这本来是个方便的设计，但当你想禁用某个库的自动初始化时，事情变得复杂。

比如 Firebase Crashlytics 的 Initializer 会在启动时读取大量配置，我们想延后到用户同意隐私协议后再初始化。按照文档，你需要在 manifest 里写：

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="com.google.firebase.crashlytics.startup.CrashlyticsInitializer"
        android:value="androidx.startup"
        tools:node="remove" />
</provider>

但这里有个版本相关的坑：在 App Startup 1.0.0 中，tools:node="remove" 对 meta-data 的支持有问题，某些构建工具版本下会被忽略。这个 bug 在 1.1.0 中修复，但 Firebase 的某个版本仍然内嵌了 1.0.0 的 App Startup，导致依赖冲突。

我当时的解决方式是强制统一版本：

implementation("androidx.startup:startup-runtime:1.1.1") {
    force = true
}

然后在代码里手动控制初始化时机，而不是依赖 manifest 的自动发现。这意味着我实际上放弃了 App Startup 最"自动化"的那部分特性，只保留了它的依赖管理核心。

真正的性能优化：需要自己动手

回到最初的问题：App Startup 本身不做并行，那怎么用它做启动优化？

我的方案是结合 Kotlin 协程，在 Initializer 内部做异步化，但这里有一个关键约束：Initializer.create() 的返回值会被缓存，且 create() 本身必须是同步调用的。你不能在 create() 里挂起协程，因为 AppInitializer 的调用栈在主线程。

我的做法是把 Initializer 设计成"触发异步任务 + 返回可等待的句柄"：

class AnalyticsInitializer : Initializer<AnalyticsHandle> {
    override fun create(context: Context): AnalyticsHandle {
        val deferred = GlobalScope.async(Dispatchers.IO) {
            // 实际的初始化在 IO 线程执行
            AnalyticsSDK.init(context)
        }
        return AnalyticsHandle(deferred)
    }
    
    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf(ConfigInitializer::class.java)
    }
}

class AnalyticsHandle(val deferred: Deferred<AnalyticsSDK>) {
    suspend fun awaitReady(): AnalyticsSDK = deferred.await()
}

然后在真正需要用到 AnalyticsSDK 的地方（比如第一个 Activity 的某个按钮点击），调用 handle.awaitReady()。如果到那个时候初始化还没完成，才会挂起等待；如果已经完成，直接返回结果。

这个模式我称之为"延迟兑现的异步初始化"。它解决了两个问题：一是启动时主线程不被阻塞，二是依赖关系仍然被 App Startup 的 DAG 管理。

但这里有个细节需要注意：GlobalScope 的生命周期。在 App Startup 的语境下，Initializer 的 create() 可能在 Application 的 attachBaseContext 之后、onCreate 之前就被调用，这时候进程还没有完整的生命周期管理。我后来改成了自定义的 CoroutineScope，绑定到 ProcessLifecycleOwner：

val appScope = ProcessLifecycleOwner.get().lifecycleScope

class AnalyticsInitializer : Initializer<AnalyticsHandle> {
    override fun create(context: Context): AnalyticsHandle {
        val deferred = appScope.async(Dispatchers.IO) {
            AnalyticsSDK.init(context)
        }
        return AnalyticsHandle(deferred)
    }
}

这样当进程被杀死时，未完成的初始化会被取消，避免资源泄漏。

数据说话：优化前后的对比

我把这个方案应用到了实际项目中，做了完整的启动耗时监控。监控方式是自定义的 ContentProvider 插桩，记录从 attachBaseContext 到第一个 Activity 的 onWindowFocusChanged 的时间。

测试条件：release 包，R8 全量压缩，关闭 debug gable，冷启动（杀掉进程后点击图标），每个方案 200 次，去掉前后 10% 的极端值。

原始方案（所有初始化在 Application.onCreate 顺序执行，含三个 IO 密集型 SDK）：

App Startup 直接迁移（同步 Initializer，无并行）：

App Startup + 协程异步（上述方案）：

手动并行（不用 App Startup，自己管理依赖和线程）：

几个观察：

第一，App Startup 的同步迁移确实带来了轻微的负优化，和之前的 demo 结论一致。

第二，异步化之后收益明显，P50 降低了 32%。但这个收益主要来自"不把 IO 放在主线程"，而不是 App Startup 本身。用不用 App Startup，只要做了异步化，差距不大（1.24s vs 1.18s）。

第三，App Startup 的价值体现在依赖管理的可维护性上。在我们的实际代码里，有 7 个 SDK 存在直接或间接的依赖关系，手动维护一个并行调度图很容易出错。App Startup 的 DAG 验证（循环依赖检测）在编译期就能发现问题，这是纯手动方案做不到的。

第四，P99 的优化幅度比 P50 更大（从 3.15s 到 2.31s，降低了 27%），说明异步化对低端设备和恶劣环境（后台进程多、IO 竞争大）的收益更明显。

另一个坑：初始化时序与 ContentProvider 的陷阱

在测试过程中，我发现了一个很隐蔽的时序问题，和 App Startup 的实现机制有关。

App Startup 的入口是 InitializationProvider，它是一个 ContentProvider。Android 系统在 app 启动时，会在 Application.onCreate 之前 初始化所有注册的 ContentProvider。这意味着如果你的某个初始化逻辑依赖了 Application 的某些状态（比如在 onCreate 里设置的自定义 UncaughtExceptionHandler），用 App Startup 就会时机不对。

我们遇到的具体 case 是：某个 SDK 的 Initializer 在 create() 里调用了 Thread.setDefaultUncaughtExceptionHandler，但我们的自定义 handler 是在 Application.onCreate 里设置的。结果 App Startup 先执行，把我们的 handler 覆盖了。

修复方案有两种：要么把 handler 的设置也搬到 App Startup 的 Initializer 里，并声明为那个 SDK 的依赖；要么放弃 App Startup，回到 onCreate 的顺序执行。

这个 case 让我意识到，App Startup 的"更早执行"既是特性也是风险。它适合那些真正需要在 Application 之前完成的初始化，比如 MultiDex.install、某些系统 hook。但对于一般业务 SDK，过早初始化可能带来意想不到的副作用。

关于 StartupLogger 和调试

App Startup 1.1.0 引入了一个不太起眼的功能：StartupLogger 的自动启用。当你在 debug 构建中调用 AppInitializer.getInstance(context).initializeComponent(...) 时，它会通过 Log.isLoggable("StartupLogger", Log.DEBUG) 判断是否打印详细日志。

但这个日志在 release 构建中默认关闭，而且关闭的方式是通过 R8 的 assumeNoSideEffects 规则把 StartupLogger.debug 内联为空。这意味着如果你用某些激进的混淆配置，可能会意外破坏这个机制。

我在调试一个线上问题时，想在 release 包开启 StartupLogger，发现没有公开的 API 控制。最后是通过反射设置了 StartupLogger.mLoggingEnabled：

if (BuildConfig.DEBUG     try {
        val clazz = Class.forName("androidx.startup.StartupLogger")
        val field = clazz.getDeclaredField("mLoggingEnabled")
        field.isAccessible = true
        field.setBoolean(null, true)
    } catch (ignored: Exception) {}
}

这个反射在 App Startup 1.1.1 中仍然有效，但显然不是官方支持的方式。我更希望未来版本能提供一个显式的 API 控制日志，而不是依赖 R8 的优化规则。

与 Jetpack 其他库的联动

App Startup 和 Jetpack 生态的其他库有一些有趣的交互。

和 Hilt 的联动：Hilt 的 HiltInitializer 也实现了 Initializer<GeneratedComponentManager<?>>，它通过 App Startup 在 Application 阶段初始化依赖图。这意味着如果你在自己的 Initializer 里需要注入依赖，必须声明 HiltInitializer 为依赖：

class MyRepositoryInitializer : Initializer<MyRepository> {
    override fun create(context: Context): MyRepository {
        // 这里 context 已经是 Hilt 装配过的 Application
        return EntryPoints.get(context, MyEntryPoint::class.java).getRepository()
    }
    
    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf(HiltInitializer::class.java)
    }
}

但这里有个版本限制：Hilt 2.44 之前使用的是自己的初始化机制，2.44 之后才迁移到 App Startup。如果你的项目有 Hilt 版本锁定，需要确认兼容性。

和 ProfileInstaller 的联动：Android 13 引入的 Baseline Profile 需要 ProfileInstaller 在启动时执行安装。ProfileInstaller 也用了 App Startup，它的 Initializer 优先级很高。我在测试中发现，如果自定义的 Initializer 也声明了 ProfileInstallerInitializer 的依赖，会导致双重初始化——因为系统可能先触发了 ProfileInstaller，然后你的依赖又触发了一次。App Startup 的缓存机制会避免重复执行，但依赖解析的递归调用仍然会发生，带来微小的开销。

我的最终判断

经过这些实测和踩坑，我对 App Startup 的结论很明确：

它不是一个性能优化工具，而是一个依赖管理框架。如果你的启动优化目标是"减少主线程阻塞时间"，核心手段应该是异步化、延迟化、按需加载，App Startup 只是帮你把这些手段组织得更规整。

在以下场景，我会推荐用 App Startup：

在以下场景，App Startup 帮不上忙，甚至可能添乱：

我个人现在的实践是：核心业务初始化（必须启动完成、有复杂依赖）用 App Startup 管理；性能敏感但非关键的初始化（如某些预加载、缓存预热）用协程 + 自定义 Scope 管理，不接入 App Startup；完全可延迟的初始化（如用户未触发的功能）放到第一次使用时按需加载。

启动优化没有银弹。App Startup 解决的是"乱"的问题，不是"慢"的问题。把它当成 DAG 调度器来用，而不是性能魔法，预期就会合理很多。