Android 应用启动性能优化方法

应用启动是用户对产品性能的第一印象。启动慢并不一定是首页代码复杂，更常见的原因是 Application 中同步初始化过多、首屏布局测量成本高、主线程磁盘读写，或者多个组件在进程创建时争抢资源。优化启动前，首先要区分启动类型并建立可重复测量方法。

一、区分冷启动、温启动和热启动

冷启动需要创建进程、初始化运行环境、创建 Application 和首个页面，耗时最长。温启动通常保留进程，但页面需要重新创建。热启动则大部分状态仍在内存中，只需把已有页面带回前台。

三种路径的瓶颈不同。只测量热启动，无法代表用户首次进入应用的体验；只关注冷启动，也可能遗漏从后台返回时的状态恢复问题。

二、先确定首屏完成标准

“启动完成”不能简单等同于 Activity.onCreate 返回。对用户而言，至少要看到稳定的主要内容，并能够响应点击。可以把启动过程拆为：

1. 进程和应用对象创建。
2. 首个页面创建与布局。
3. 首帧绘制。
4. 首屏关键数据可见。
5. 页面具备正常交互能力。

技术指标与业务标准结合后，才知道优化的是空白等待、骨架屏等待，还是数据渲染等待。

三、保持 Application 轻量

Application.onCreate 位于冷启动关键路径，里面的同步工作会直接推迟首帧。初始化项可以按必要性分类：

• 首帧前必须完成：影响基础路由、主题或安全校验的能力。
• 首屏展示后完成：统计、非关键缓存整理等能力。
• 首次使用时完成：低频业务组件。
• 独立进程不需要：只服务主进程的功能。

可以使用项目现有的初始化调度器明确依赖关系，不要简单把所有任务同时扔进线程池。并发过多会增加线程切换和磁盘竞争，反而拖慢启动。

interface AppInitializer {
    val name: String
    val dependencies: Set<String>
    suspend fun initialize()
}

class AccountInitializer(
    private val accountStore: AccountStore
) : AppInitializer {
    override val name: String = "account"
    override val dependencies: Set<String> = emptySet()

    override suspend fun initialize() {
        accountStore.prepare()
    }
}

只有确实存在先后依赖时才声明依赖，避免为了形式建立复杂任务图。

四、消除主线程磁盘读写

配置文件、数据库和大对象反序列化都可能阻塞主线程。首先确认首屏是否真的需要完整数据，如果只需要用户名或主题标识，就不应在启动阶段加载整个账户对象。

对必须读取的数据，可以在合适的调度器中执行，再回到主线程更新界面：

viewModelScope.launch {
    val snapshot = withContext(Dispatchers.IO) {
        launchRepository.readSnapshot()
    }
    _uiState.value = LaunchUiState.Ready(snapshot)
}

线程切换不是万能优化。很小的读取如果被拆成大量任务，也会产生额外调度成本，应以测量结果为准。

五、简化首屏布局

首屏布局的测量、布局和绘制发生在主线程。嵌套过深、重复背景、复杂矢量图以及首次绘制前频繁修改布局参数，都会延迟首帧。

优化时可以检查：

• 删除没有视觉或布局作用的容器。
• 复用项目已有的扁平布局组件。
• 文本控件宽高优先使用 wrap_content，通过约束限定可用范围。
• 文本字号使用 dp，与项目适配规则保持一致。
• 首帧前避免多次切换同一区域的显隐状态。
• 不在首屏同步创建暂时不可见的重型视图。

骨架屏本身也有绘制成本。它应该尽量接近真实结构并保持简单，而不是叠加大量独立动画。

六、谨慎延迟初始化

延迟初始化只是把成本移动到以后。如果用户首次点击某功能时出现明显卡顿，整体体验并没有改善。被延迟的组件需要满足两个条件：首屏不依赖，首次使用前有合适的空闲窗口或异步准备时机。

对于线程安全的单例，可以使用语言提供的延迟机制，但初始化过程仍要避免在调用线程执行重活。

class ServiceRegistry(
    private val factory: ServiceFactory
) {
    val reportService: ReportService by lazy(
        LazyThreadSafetyMode.SYNCHRONIZED
    ) {
        factory.createReportService()
    }
}

七、处理启动页与首屏数据

启动页的作用是衔接系统启动窗口与真实页面，不应通过固定等待时间延长展示。首屏数据可以采用明确策略：

• 本地已有可信快照时先展示，再按业务规则刷新。
• 没有可用数据时展示结构稳定的加载状态。
• 关键校验未完成时，只阻塞真正依赖校验的入口。

不要为了追求视觉上的“完整”而等所有接口返回后才绘制首屏。不同模块可以根据依赖关系分阶段展示。

八、建立回归机制

启动耗时容易随着组件增加逐步恶化。建议记录关键阶段耗时，并在固定设备、固定构建类型下持续比较。调试包受日志和调试能力影响，最终结论应以接近正式环境的构建为准。

一次有效验证应包含多轮冷启动，排除偶然的系统缓存和后台负载影响。同时观察首帧、可交互时间、主线程长任务和内存峰值，避免只优化单一数字。

总结

Android 启动优化的核心是缩短首屏关键路径。保持 Application 轻量，减少主线程读写，简化首屏布局，并根据真实依赖延迟非关键初始化。所有调整都应通过稳定场景重复测量，防止把耗时简单转移到用户下一次操作中。