4. 性能评估指标体系

启动时间，是用户上车后的第一印象。你想想看，坐进车里，屏幕黑着，等个十几秒才亮起来——这体验，搁谁谁都不舒服。我这些年经手的座舱项目，几乎每一个客户都把启动时间列为硬指标。今天我们就来聊聊这块到底怎么优化。

4.1 冷启动 vs 热启动：先搞清楚定义

很多人把冷启动和热启动混为一谈，其实差别很大。我习惯这么区分：

启动类型	定义	典型场景	目标时间
冷启动	系统从完全断电状态（如电瓶断开）开始，BootROM → Bootloader → Kernel → 用户空间 → 应用，完整走一遍	车辆长时间停放后首次上电、维修后重新通电	< 8s（行业标杆 < 5s）
热启动	系统从休眠/挂起状态恢复，内存或部分外设保持供电，跳过部分初始化流程	短时间停车（如加油、等人）、ACC off/on 切换	< 2s（理想 < 1s）
温启动	介于两者之间，系统复位但内存数据可能部分保留，需要重新加载驱动和部分服务	系统异常重启、OTA 升级后重启	< 5s

4.2 启动链路分析：每一毫秒都要算清楚

我接手过一个项目，客户说冷启动要 12 秒，要求砍到 6 秒以内。第一件事不是动手改代码，而是——把启动链路拆开，逐段计时。

典型的座舱冷启动链路长这样：

上电 → BootROM(0.3s) → SPL(0.2s) → U-Boot(0.8s) → Kernel(1.5s) → init(0.5s) → 服务启动(2.0s) → 应用启动(3.0s) → 首帧显示(0.5s)
                                                                                                    ↓
                                                                                            总耗时 ≈ 9.3s

你看，每个环节都有优化空间。我习惯用 bootchart 或 perf 工具抓一份完整的启动时序图，然后盯着耗时最长的几个阶段下手。

4.2.1 BootROM 与 Bootloader 阶段

这个阶段通常由芯片原厂提供，我们能改的不多。但有个坑——有些板子的 BootROM 会等待外部存储稳定后才开始执行。我曾经遇到过一块板子，eMMC 上电后需要 200ms 才能准备好，BootROM 就这么干等着。解决方案是调整电源时序，让 eMMC 先上电。

• 优化点 1：检查 BootROM 是否在等待某个外设就绪，能提前上电的就提前
• 优化点 2：U-Boot 里关掉不必要的驱动初始化（比如网络、USB 等）
• 优化点 3：使用 CONFIG_BOOTDELAY=0，跳过按键等待

4.2.2 Kernel 阶段

Kernel 启动时间主要花在驱动初始化和设备枚举上。我常用的手段：

• 裁剪内核：去掉用不到的驱动和模块，编译成单内核（非模块化）
• 异步 probe：让不关键的驱动异步加载，不阻塞主线
• deferred initcall：把耗时的 initcall 推迟到后期执行

4.2.3 用户空间与应用启动阶段

这个阶段是优化空间最大的地方。从 init 进程开始，到 SurfaceFlinger/WindowManager 启动，再到 Launcher 显示首帧，每一步都可能成为瓶颈。

我习惯把应用启动拆成三步：

1. 进程创建：fork + exec，耗时约 50-100ms
2. 类加载与初始化：Java 虚拟机加载类、执行静态初始化块，耗时 200-500ms
3. 首帧渲染：布局解析、资源加载、第一次 measure/layout/draw，耗时 300-800ms

4.3 预加载策略：把时间花在看不见的地方

说白了，预加载就是「用空间换时间」。既然用户等不了，那就在用户看不到的时候提前把活干了。

4.3.1 应用预加载

我做过一个方案：系统启动后，先加载 Launcher 和常驻应用（如空调、音量），其他应用按优先级排队加载。具体做法：

• 白名单机制：定义一份预加载应用列表，系统启动后立即 fork 进程
• 延迟加载：非关键应用在首帧显示后再加载，不抢占 CPU 资源
• 保活策略：常驻应用通过 start-sticky 服务或 persistent 属性保持存活

4.3.2 资源预加载

应用启动慢，很多时候不是代码逻辑慢，而是资源加载慢。比如一张 4K 的启动背景图，解码就要 200ms。我的做法：

• 资源预热：在系统启动阶段，把常用图片、字体、布局文件提前解码到内存缓存
• 共享内存：多个应用共用同一份资源，避免重复加载
• 异步加载：首帧只加载关键资源，次要资源用 post 或 Handler 延迟加载

4.3.3 服务预启动

有些系统服务（如音频服务、蓝牙服务）启动很慢。我建议在 init.rc 里调整启动顺序：

# 将关键服务提前
on boot
    start core_service      # 核心服务（如 hwservicemanager）
    start display_service   # 显示服务
    start audio_service     # 音频服务（非关键，可延迟）
    start bluetooth_service # 蓝牙服务（非关键，可延迟）

4.4 Fastboot 技术：从硬件层面加速

Fastboot 不是 Google 那个 fastboot 工具，而是指一系列从硬件和底层软件层面加速启动的技术。我把它分为三类：

技术	原理	效果	代价
快速存储初始化	跳过 eMMC/UFS 的完整初始化流程，使用快速模式	节省 200-500ms	可能降低存储稳定性
快速 DDR 训练	使用预存的内存训练参数，跳过完整训练	节省 300-800ms	需要提前校准并保存参数
快速显示初始化	在 Kernel 启动前由 Bootloader 直接初始化显示控制器并显示 Logo	首帧提前 1-2s	需要 Bootloader 支持显示驱动
休眠到内存（S2R）	系统进入深度睡眠，内存保持供电，恢复时跳过大部分初始化	热启动 < 1s	需要硬件支持，待机功耗约 5-10mA

4.5 启动优化流程图

下面这张图是我自己总结的启动优化决策流程，每次做新项目都会拿出来对照一遍：

4.6 避坑指南

做启动优化这些年，踩过的坑不少。挑几个典型的说说：

• 别盲目追求「首帧时间」：首帧显示快不代表系统可用。我见过一个项目，首帧 1.5s 就出来了，但用户点任何按钮都没反应——因为后台服务还没启动完。首帧时间要和「可用时间」一起看。
• 热启动别忽略外设恢复：有些外设（如摄像头、蓝牙芯片）从休眠恢复时需要重新初始化。我遇到过蓝牙芯片恢复要 800ms，直接把热启动时间拖到了 2s 以上。解决方案是让蓝牙芯片保持浅睡眠，不进入深度休眠。
• 预加载要控制内存水位：预加载的应用越多，内存占用越高。当内存不足时，系统会触发 LMK（Low Memory Killer）杀掉进程，反而更慢。我一般把预加载的内存上限控制在总内存的 30% 以内。