第2章：类加载顺序对启动性能的影响

2.1 类加载耗时分布

Zygote 进程在启动过程中需要预加载 Android 框架的核心类。根据实际测量，类加载的耗时并非均匀分布——约 30% 的类消耗了 70% 的加载时间。这些“热点类”通常包含大量静态初始化块、复杂父类层级或 JNI 绑定操作。

2.2 顺序依赖导致的死锁或延迟

类加载顺序一旦形成环形依赖或单向长链阻塞，会引发两种典型问题：

• 初始化死锁：当类 A 的 <clinit> 在锁范围内等待类 B，而类 B 的 <clinit> 又在另一个线程中等待类 A，触发 Thread.join 或 synchronized 死锁。Zygote 是单线程预加载，但部分类的静态初始化会 spawn 辅助线程。
• 级联延迟放大：一个父类的静态初始化耗时 50ms，其子类 10 个累积等待可达 500ms，而如果子类之间没有依赖，完全可以通过重排并行化。

// 死锁模拟（仅演示依赖关系）
Class A {
    static { init(B.class); }   // 等待 B 的静态字段
}
Class B {
    static { init(A.class); }   // 等待 A 的静态字段 → 死锁
}

2.3 重排优化目标

基于上述分析，对 Zygote 预加载类进行顺序重排应达成三个核心目标：

1. 消除显/隐式反向依赖：保证父类先于子类，被依赖的工具类先于业务类。
2. 将热点类前移：使最耗时的类尽早开始加载，避免轻量类抢在热点类之前占用 I/O 或锁资源。
3. 减少级联等待：如果类 C 同时依赖 A 和 B，则将 A 和 B 集中排在 C 之前，避免中间插入大量无关类增加等待时间。

2.4 重排实践的输入输出

重排方案的执行需要两个输入：类加载依赖图（通过静态分析字节码获取）和 每个类的实际加载耗时（通过 instrumentation 埋点测量）。输出为 preloaded-classes 文件的新排序。

# 原始 preloaded-classes 片段（乱序）
android.app.ActivityThread
android.content.res.Resources
android.util.Log
android.view.View
android.app.Instrumentation

# 重排后（按依赖 + 耗时排序）
android.util.Log          # 轻量无依赖，靠前
android.content.res.Resources  # 被广泛依赖
android.app.Instrumentation
android.app.ActivityThread   # 热点，尽早开始
android.view.View            # 依赖 Resources 等