1. 课程导入

Android 启动性能与开机优化，是系统工程师、性能工程师、BSP 工程师和系统应用开发者都会长期面对的一类工程问题。它既涉及从按下电源键到用户看到桌面的完整链路，也涉及应用冷启动、温启动、热启动等不同场景。很多团队在优化时容易陷入“只看某个阶段耗时”的局部视角，结果改了一个点，整体体验却没有明显提升。本课程的目标，是帮助学习者建立从 BootROM → Bootloader → Kernel → Init → Zygote → SystemServer → Launcher/App 的完整启动链路认知，并掌握可测量、可定位、可验证、可回归的工程方法。

一、学习目标：从“知道慢”到“知道为什么慢、怎么改、如何证明改好了”

本课程不是单纯罗列优化技巧，而是围绕一条可落地的能力主线展开。完成学习后，应达到以下目标：

  • 建立全链路视角：能说清 Android 开机启动各阶段的关键任务、依赖关系和典型耗时区间。
  • 掌握测量方法：会使用 bootchart、dmesg、logcat、ftrace、systrace/Perfetto、atrace、simpleperf 等工具采集启动数据。
  • 具备定位能力：能根据日志、时间戳、线程状态和系统调用，判断瓶颈位于内核、init、Zygote、SystemServer 还是应用层。
  • 形成优化闭环：能提出假设、设计实验、对比数据、评估收益，并防止优化引入稳定性或兼容性问题。
  • 理解工程约束：在性能、功耗、内存、安全、启动稳定性之间做权衡，而不是盲目追求单一指标。
核心判断标准：启动优化不是“让某个函数更快”，而是“让用户更早进入可交互状态，同时不破坏系统稳定性与后续运行性能”。

二、核心概念：启动阶段、关键路径与性能指标

Android 启动可以粗略分为三个大阶段：硬件与引导阶段、系统服务启动阶段、用户可见阶段。每个阶段都有不同的主导者和观测手段。硬件与引导阶段主要由 BootROM、Bootloader、Kernel 控制；系统服务启动阶段由 init、Zygote、SystemServer 主导；用户可见阶段则与 Launcher、SystemUI、应用进程启动密切相关。

在性能指标上，常见的有：Boot Time（开机总耗时）、Kernel Boot Time（内核启动耗时）、Init Time（init 阶段耗时）、Zygote Fork Time（Zygote 孵化耗时）、SystemServer Ready Time（系统服务就绪耗时）、Display Time（首帧显示耗时）、App Cold Start Time（应用冷启动耗时）。这些指标不是孤立的，它们之间存在依赖关系：例如 SystemServer 未就绪时，Launcher 无法正常启动；应用冷启动又依赖 Zygote 和系统服务。

阶段 关键对象 典型观测手段 常见瓶颈
BootROM/Bootloader SoC、DDR、存储 串口日志、示波器 DDR 训练、镜像校验、存储读取
Kernel 驱动、文件系统、调度 dmesg、bootchart 驱动 probe 慢、I/O 等待、CPU 调频
Init init.rc、服务、属性 logcat、init 日志 服务串行启动、属性等待、SELinux
Zygote/SystemServer 虚拟机、系统服务 systrace、Perfetto 类加载、Binder 调用、服务初始化
Launcher/App 应用进程、UI 渲染 atrace、simpleperf 主线程阻塞、布局复杂、I/O 密集

三、整体知识框架：从系统启动到应用启动的分层视图

为了便于学习和排查，本课程将知识框架分为四层：硬件与内核层、系统服务层、框架与运行时层、应用与交互层。每一层都有对应的优化手段和观测工具。下图展示了从电源键到应用可交互的完整信号与数据流关系，也标出了关键观测点和典型优化切入点。

Android 启动性能全链路：分层、信号流与观测点 硬件与内核层 BootROM → Bootloader → Kernel → 驱动 probe → 文件系统挂载 观测：串口日志、dmesg、bootchart ｜ 优化：DDR 训练、驱动异步 probe、I/O 调度 系统服务层 init → 属性服务 → 服务启动 → Zygote → SystemServer 观测：logcat、init 日志、systrace ｜ 优化：并行启动、延迟服务、减少 Binder 等待 框架与运行时层 ART 类加载 → Binder 通信 → 系统服务就绪 → 首帧合成 观测：Perfetto、atrace、simpleperf ｜ 优化：类预加载、线程调度、渲染管线 应用与交互层 Launcher 启动 → 应用进程 fork → Activity 创建 → 首帧上屏 观测：logcat、atrace、FrameTimeline ｜ 优化：冷启动、布局、I/O、启动器预加载 关键观测点 ① 电源键按下 ② Kernel 启动完成 ③ init 第一阶段结束 ④ Zygote 就绪 ⑤ SystemServer 就绪 ⑥ Launcher 首帧 ⑦ 应用冷启动开始 ⑧ 应用首帧上屏 ⑨ 可交互状态 工具： dmesg / logcat bootchart / systrace Perfetto / simpleperf atrace / FrameTimeline

四、工程实践路线：从采集、定位到验证的闭环

启动优化最忌讳“凭感觉改代码”。正确的工程路线应当是一个闭环：基线采集 → 瓶颈定位 → 假设与实验 → 优化实施 → 数据验证 → 回归监控。在基线采集阶段，要固定硬件、系统版本、温度、电量、后台负载等条件，避免数据漂移。在瓶颈定位阶段，要结合时间线和调用栈，判断是 CPU 竞争、I/O 等待、锁竞争还是 Binder 阻塞。在优化实施阶段，优先选择收益明确、风险可控的手段，例如并行化初始化、延迟非关键服务、减少主线程 I/O。在验证阶段，要用同一套指标对比优化前后，并观察是否引入新的卡顿、崩溃或功耗问题。

# 典型启动数据采集命令示例
adb shell dmesg > dmesg.log
adb logcat -b all -d > logcat_all.log
adb shell atrace -t 10 -b 32768 gfx input view wm am sm hal res dalvik \\
  > atrace_boot.log
adb shell perfetto -c /data/misc/perfetto-configs/boot.cfg -o /data/misc/perfetto-traces/boot.pftrace
建议在项目初期就建立“启动性能基线表”，记录每个版本的关键时间戳和指标。没有基线的优化，很难判断收益是否真实。

五、常见误区与复盘思路

第一个误区是只优化应用冷启动，忽略系统启动。如果 SystemServer 或 Launcher 本身启动慢，应用再快也会被拖累。第二个误区是只看平均值，不看分位数。启动性能更应关注 P90、P95 甚至最差情况，因为用户对慢一次的感知远强于快十次。第三个误区是把并行化当成万能药。过度并行会加剧 CPU 竞争和 I/O 抖动，反而拉长关键路径。第四个误区是忽略回归监控。一次优化可能让某个场景变快，却让另一个场景变慢，必须持续跟踪。

启动优化必须与稳定性、功耗、内存、安全一起评估。任何以牺牲系统稳定性为代价的“提速”，都不应进入量产版本。

本课程后续将沿着上述框架逐步展开：先讲清启动链路和测量方法，再深入 Kernel、init、Zygote、SystemServer、Launcher 和应用冷启动等关键环节，最后通过综合案例和排障复盘，把零散知识串成可复用的工程能力。学习时建议始终带着三个问题：当前处于哪个阶段？关键路径是什么？我用的数据能否证明优化有效？

← 上一章 📖 返回目录 下一章 →