面向大型社交 App 的「Android 启动速度优化全项清单」

冷启动、热启动、依赖优化、Dex 优化、初始化排序、资源加载、UI 布局、工具链、Jetpack App Startup、Baseline Profile 等全栈指标。

Android 启动速度优化清单（冷启动 + 热启动）

一、启动全流程拆解（先明确优化点）

Android 冷启动路径可拆为：

Zygote Start → Fork App → Runtime Init
→ 启动 Application → attachBaseContext()
→ ContentProvider 初始化（ClassLoader 加载）
→ Application.onCreate()
→ 首屏 Activity.onCreate()
→ setContentView / inflate
→ 数据加载（IO/网络）
→ 首帧渲染 (Time to First Draw)
→ 首屏可交互 (TTI)

优化目标是：
减少 ClassLoader 压力、减少 IO、减少初始化、减少主线程负载、减少 Dex 冻结、前置 JIT 预热、减少布局复杂度。

下面按模块详细拆解

1. 启动类加载 & Dex 优化（极高收益）

1.1 Dex 重编排（Profile Guided / 人工编排）

  • 使用 baseline-profile（R8 + ART Runtime）
  • 引导热点方法提前 AOT
  • 将首屏所需类编入主 Dex
  • 把非首屏模块（直播、动态、美颜、支付）放到次 Dex
  • 减少“隐藏反射 keep 规则”导致 Dex 体积爆炸

1.2 使用 Baseline Profile（极高 ROI）

为启动路径录制实际 Profile：

./gradlew :app:generateBaselineProfile

让系统预编译 Activity/Fragment/UI 层关键类
⇒ TTFD 大幅减少 20%~40%。

1.3 使用 Startup Profile（Android Gradle 8+）

把类加载顺序明确规定
减少 ClassLoader 在多 Dex 中盲目查找。

2. Application 初始化拆分（重中之重）

2.1 禁止「大而全的 Application」

  • 任何不是首屏必须的逻辑，一律禁止放 application.onCreate
  • 首屏的定义通常是：“进入消息页/首页所需能力”

2.2 App Startup Framework（Jetpack）

让所有三方库 / 自研模块 声明每个初始化的依赖关系 & 线程策略

AppInitializer.getInstance(context)
    .initializeComponent(XXXInitializer::class.java)

并设置：

  • 后台线程初始化
  • 必要时懒加载
  • 依赖自动排序
  • 多模块初始化依赖检测

2.3 典型应该延迟的初始化（延后到后台）

  • IM 长连接
  • 日志系统（Crash、埋点上传）
  • 广告 SDK
  • 直播 SDK、短视频 SDK
  • 美颜 / 人脸检测 SO 库
  • Push SDK
  • 大型 JSON 库（Gson/Moshi 转换器）
  • WebView 初始化（预热也应异步）

可以推迟到：

  • IdleHandler
  • WorkManager
  • SplashActivity onStop
  • 首屏 Activity 可见后

2.4 使用 ContentProvider 延迟替换为 App Startup

很多三方库默认通过 provider 在 Application 之前初始化
→ 必须关闭：

tools:node="remove"

然后改为 App Startup 的初始化器。

3. 冷启动路径中 ContentProvider 优化

3.1 禁掉所有非必要 Provider（极高收益）

大量 SDK 滥用 provider 导致 class loading 过早：

  • Glide
  • Bugly
  • MultiDex
  • Room
  • WebView provider
  • 活动统计 provider

如果不移除，看一下 manifest：

<provider
    android:name="com.xxx.xxxInitProvider"
    android:authorities="${applicationId}.xxxInitProvider"
    tools:node="remove" />

3.2 自研 Provider → App Startup

Provider 的初始化永远在 Application 前执行
→ 必须迁移为 Startup Initializer。

4. UI / 布局优化（对首帧渲染非常重要）

4.1 减少 Layout 层级（使用 ConstraintLayout）

  • 避免嵌套 Relative + Linear 的组合
  • 使用 merge/include
  • 异步 inflate（ViewStub / AsyncLayoutInflater）

4.2 减少首屏资源加载

  • 首屏图片使用 tiny preload（10K 内）占位
  • 不加载大图 / 动画

4.3 减少首帧计算

  • 减少自定义 View 的 heavy onMeasure/onLayout
  • 避免在 Activity.onCreate 做 too much IO

5. 资源与 IO 优化

5.1 首屏不访问磁盘（强制要求）

典型违规：

  • MMKV 初始化
  • 读取 JNI 资源文件
  • 读取 assets json
  • 大量 SharedPreference
    → 强制推迟到后台线程

5.2 避免 SO 在主线程加载

5.3 避免首次启动解压资源

  • 减少 Assets 文件
  • assets/resources.zip 分模块
  • 首屏绝不解压 zip

6. 三方库优化（往往是大户）

6.1 SDK 禁用自动初始化

要求每个 SDK 配置 “manual init mode”。

6.2 选择轻量库

  • Coil/Fresco → Coil/Kotlin
  • Replace Gson → Kotlinx Serialization
  • OkHttp 日志拦截器禁用

6.3 精简 SDK 模块

  • IM 去掉群资料、拉黑列表、关系链拓展
  • RTC 去掉录制、主播混流、屏幕分享
  • Bugly 去掉性能模块

7. WebView 优化

  • 使用独立进程预热 WebView
  • 不在主进程初始化 WebView
  • 首屏如无 WebView，禁止任何 WebView 初始化逻辑

8. 多进程拆分（避免主进程膨胀）

典型拆分：

  • WebView 进程
  • Push 通知进程
  • 音视频处理进程
  • 文件扫描进程

主进程必须越轻越好。

9. 进阶优化：ART / Runtime 层

9.1 启用 Cloud Profile（Android 自带）

Google Play 会推送 cloud profile，让系统预编译热点类。
如果你使用国内发行渠道，可依赖 Baseline Profile 替代。

9.2 禁止多 Dex 查找压力（Dex 切分恰当）

  • 主 Dex 保持 < 4,000 classes
  • 不要在主 Dex 引入过多工具类（单例工具类放次 dex）

10. 启动监控体系

必须做可观测性，否则专项只能拍脑袋。

要监控的指标

  • Application 启动时长
  • Provider 初始化耗时
  • 每个 SDK 初始化耗时
  • Activity.onCreate → 首帧渲染耗时
  • 首帧掉帧数
  • CPU 时间片占用
  • IO 次数与大小

方法

  • Android Startup Tracing
  • Traceview / Perfetto
  • Systrace
  • 自研启动耗时埋点（推荐）

整体方案

P0（必须立即做）

  • 移除所有三方 Provider → App Startup
  • Application 初始化全面梳理（首屏只留 3~5 个必要组件）
  • Baseline Profile + Startup Profile
  • 主 Dex 重编排：首屏类进入主 dex
  • 所有 SDK 改为延迟初始化、后台初始化

P1（尽快落地）

  • UI inflate 优化（ConstraintLayout、ViewStub）
  • 首屏资源极简化
  • SO 按需加载
  • IO 零访问首屏

P2（中长期）

  • WebView 进程隔离
  • 大模块插件化（直播、短视频）
  • SDK 轻量化改造
  • 启动数据监控 Dashboard 推广