Android15车机冷启动源码链路全解析：从Bootloader到Launcher首帧

在车载系统项目上待久了，你会发现一个很神奇的现象：开会聊性能，十个议题里至少八个绕不开冷启动。手机开机慢几秒，顶多被用户吐槽一句，锁屏扔到桌上也就过去了；但 Android15 车机的冷启动一旦慢，客户会把“从点火到桌面可用”当成硬性的验收指标，每一百毫秒都要掰开揉碎地解释。

这篇整理主要围绕我实际项目里反复查过的源码链路，把车机从整机上电、Bootloader、Kernel、Init、Zygote 到 SystemServer、CarService、Launcher 首帧这一段完整走一遍。适合做车机系统开发、Framework 移植、性能优化的朋友参考，也适合刚接车机项目的同学快速建立一条“冷启动全景链路”的认知。毕竟在 Android 车机这个生态里，冷启动不是某一个服务的 bug，而是整条链路串行叠加后的结果，任何一层藏了水分，最终都会体现在“点火到桌面”的那一秒上。

1. 车机冷启动为什么比手机启动更让人焦虑——先谈粒度拆解

先说清楚一个概念上的边界：车机冷启动，不是按一下电源键点亮屏幕那么简单。手机上按电源键，整机硬件其实处于低功耗休眠状态，用户感受到的是“唤醒”而非真正意义上的“开机”，电源路径、内存训练、系统镜像校验基本都可以跳过。车机则不一样，大多数项目里的冷启动指的是整车完全掉电、或者从蓄电池断开后重新上电，整个 SoC 要从头开始完成上电时序、DDR 初始化、系统镜像加载，每一步都跑不了。

Android15 在车载平台上的启动框架和手机大体一致，但多了两样东西：一是车控相关的 CarService 链路，二是多屏显示场景。手机启动只需要把主屏拉起来就算完成，车机还得分中控、仪表、HUD，有的项目甚至要求倒车影像优先于桌面出现。这个差异会直接影响代码层面的优化顺序：同样的 SystemServer 耗时，手机上可能只影响用户多等 0.5 秒，车机上却可能阻塞仪表盘首帧，属于不可接受。

1.1 冷启动与热启动、睡眠唤醒的本质差异

实际车机项目里，启动模式大致分三种：

• 冷启动：整车 OFF 状态重新上电，SoC 完整走 Bootloader 和 Linux 引导，RAM 数据全部丢失。
• 热启动：用户态重启，通常由adb reboot或系统崩溃重启触发，跳过部分硬件初始化，但内核仍是重新引导的。
• 睡眠唤醒：整车进入低功耗休眠，SoC 处于 suspend 状态，网络、车辆服务保活，唤醒路径最快，不在本文讨论范围。

从源码层面看，冷启动与睡眠唤醒完全是两条代码路径。睡眠唤醒走的是 Linux 电源管理中的 suspend/resume，不重新跑 Zygote 和 SystemServer；冷启动才是真正意义上从init开始的引导。很多刚入行的同学拿着唤醒时间当冷启动时间汇报，这就是“起止点”没有和客户对齐的典型问题。所以做任何冷启动优化之前，第一件事不是看代码，而是先定义“从哪个电源事件作为 T0，到哪个界面事件作为 T1”。

1.2 车机冷启动计时起止点：T0到T1的定义决定工作量

我在某车型项目里见过最夸张的一次争论：客户要求冷启动从“IGN ON 信号有效”开始计，但研发手里的 trace 却是从 Bootloader 首条日志开始打，中间差了整整 300ms 的电源延迟。后来又发现 IGN ON 信号本身有软启动时序，真正给 SoC 供电还要再晚几十毫秒。这种差异在验收时会被放大，30% 的优化成绩可能只是换了计时起点。

业界比较常见的做法是定两个绝对节点：

• T0：SoC 上电完成，或者 Bootloader 第一条串口日志的时间，通常取实现时最可复现的点。
• T1：Launcher 首帧绘制完成，同时用户可操作，比如中控桌面出现并响应 touch。

如果项目里加了仪表，T1 还可能拆成主屏可用、副屏可用、倒车可用三个里程碑。这不是小题大做，而是因为多屏的场景里，主屏 Launcher 和仪表 Cluster 的渲染管线是并行又互相抢资源的。Timer 定义不清晰，后面所有的优化报告都会变成无效沟通。

1.3 启动链路各阶段的大致耗时印象

下面这张表是我做过的一个典型车机项目冷启动耗时的粗略印象，不代表所有平台，但能帮大家建立一个量级概念：

工程上，车机冷启动总耗时普遍落在 8s 到 15s 之间。超过 10s 用户感知就很明显了，超过 12s 基本会被立项重点治理。看这张表就能感觉到，真正的大头在 SystemServer 和 Zygote，Bootloader 也有不少可以挤的水分。下面按时间顺序逐个环节拆源码。

2. 从整机上电到内核跑起来：Bootloader 阶段的隐藏水分

很多人觉得 Bootloader 是 BSP 的活，Framework 工程师插不上手，这个观点在车机项目里很吃亏。Bootloader 阶段占掉 1.5s 到 3s 是完全正常的，而其中相当一部分时间花在可以优化但经常被忽略的地方。

2.1 Bootloader 到底在做什么

车机上常见的 Bootloader 方案不外乎两大类：一类是传统 U-Boot 为主体，厂商在上面加各种私有命令；另一类是遵循 Android Bootloader 规范的实现，负责加载 boot、vendor_boot、dtbo 等分区镜像。无论哪种，主要工作都包括这么几块：

• 初始化 DDR，需要做内存 training，有一套参数要反复读写。
• 初始化存储控制器，为读取 boot 镜像做准备。
• 初始化显示控制器，决定开机 logo 能不能尽早点亮。
• 校验镜像签名，Android15 上 AVB 校验链路更严格，Bootloader 要验证 boot、vendor_boot、dtbo 的 hash 和签名。
• 跳转 Kernel，传入kernel cmdline、设备树、ramdisk。

源码层面对应的大文件是system/core/init/first_stage_init.cpp和bootloader侧实现，但 Framework 工程师重点关注的其实是时间戳。实际项目里，Bootloader 段的优化大多由 BSP 完成，我们更应关注的是 AVB 校验和显示时序这两个水比较深的地方。

2.2 AVB 校验在冷启动里的代价

Android 从很早的版本就引入 Verified Boot，Android15 在 AVB 方面的变化主要是格式校验、回滚保护、以及镜像 metadata 的完整性要求更严。每增加一层校验，Bootloader 就要多读一块镜像并计算 hash。镜像越大、存储介质读取带宽越有限，校验耗时越长。

有的车机项目为了安全会把 boot、vendor_boot、dtbo、system、vendor、甚至 oem 分区全部纳入 AVB 校验链，这会让冷启动多出几百毫秒的纯读取时间。优化思路通常是：

• 只对必须防篡改的分区做完整校验，对性能敏感且改动频繁的分区缩短签名摘要校验。
• 在 Bootloader 里开启 DMA 和 burst read，提高连续读吞吐。
• 把 Bootloader 自己的 hash feed 缓存到安全存储里，避免每次冷启动重新计算整块镜像。

这里想特别提醒一点：不要为了追求速度去关闭回滚保护。遇到过某供应商基线为了调试方便把 rollback index 写成了固定值，结果后续 OTA 固件全部被 Bootloader 拒绝，车辆在产线上趴窝，排查了两个通宵。冷启动优化是在安全策略允许的边界内做调整，不是把安全机制关掉。

2.3 Kernel 引导阶段的“等待感”从哪来

Kernel 启动到 init 接管之间，主要时间是花在设备驱动 probe 上。车机平台的外设比手机多得多：多路显示、以太网、CAN、USB、各种传感器，每个驱动都可能在probe阶段做耗时操作。

从源码角度看，Linux 内核的initcall分多个层级，fs_initcall、device_initcall等按序执行。很多车机厂商把驱动改成异步 probe，好处是启动时间缩短，坏处是可能出现设备时序错乱，路径规划不好反而会引入概率性 crash。我见过一个项目，把某个显示屏驱动改成异步 probe 后启动快了 300ms，但副屏 10 次冷启动有 1 次黑屏，最后又改回同步 probe，只保留其他几个安全驱动的异步化。

Framework 这边能做的主要是尽早接管串口和日志系统。我们在项目里会在 Kernel cmdline 里提前开好earlycon或bootlogd，确保init的第一条日志不会丢掉。否则后面做时间归因时，中间缺了一段，根本说不清是 Kernel 慢还是 Init 慢。

3. Init 进程：车机系统的“第一把火”怎么点

Kernel 完成引导后，第一个用户态进程就是/init。Android15 的 Init 进程主要代码在system/core/init/，核心入口是init.cpp和first_stage_init.cpp。这一阶段是整个用户态世界的最早起点，也是车机项目里最容易做“服务拆分”优化的地方。

3.1 First Stage 与 Second Stage 的职责划分

Init 分成两个阶段。

First Stage 做的事情非常底层：挂载基础文件系统、加载 SELinux 策略、设置/dev、/proc、/sys等关键目录。具体是在first_stage_init.cpp里完成，主要流程可以理解为：

1. 挂载 tmpfs、devpts、proc、sysfs。
2. 初始化 SELinux，并把 policy 加载到内核。
3. 在/dev下创建关键设备节点，为第二阶段做准备。
4. 把存储分区通过fs_mgr挂载到/system、/vendor等挂载点。

到了 Second Stage，Init 才开始真正解析.rc文件，执行各个 trigger 阶段的动作，最终拉起 Zygote。车机在 Second Stage 里会多出一堆厂商私有服务，比如车辆状态监控、OTA 守护、日志上传等。如果这些服务全部挂在on boot或on property:sys.boot_completed=1之后，其实对冷启动主路径的影响不大；但如果有人图省事把它们挂在on init阶段串行执行，冷启动立马就被拖慢。

3.2 车机 rc 文件改造：类与触发器的拆分

Android 的 init 服务都有class属性，常见的有core、main、late_start。默认情况下，同一 class 内的服务会按声明顺序启动，即使底层已经支持并行拉起，但竞态处理不好会让效果打折扣。

在车机项目里，我更推荐的做法是：把不影响主链路的服务拆到late_start，把必须早期就绪的服务在on early-init阶段用start命令单独触发。例如，车辆网关注册、系统看门狗、日志快照服务，只要不阻塞 Zygote，都可以延迟启动。代码结构上可以维护一个vendor_init.rc，里面按业务模块拆分：

on early-init start vendor_watchdog on property:vendor.boot.car_ready=1 start vendor_car_network

关键点在于一个“解耦”思路：不是所有服务都需要等到 Zygote 起来再去启动，也不是越早越好。我们项目曾经把一个网络监控服务提前到on init，结果它比网络驱动 probe 还早启动，一直误报离线，反而造成系统反复重启。合理的时间点要基于内核设备就绪信号来决定，而不是拍脑袋提前。

3.3 SELinux 与 restorecon：车机上经常被忽略的“隐形几秒”

Init 阶段最容易藏时间的操作之一是restorecon。它会把分区里的文件标签重新刷一遍，确保与 SELinux policy 一致。车机上/vendor、/oem、/data分区里预装了大量 APK 和厂商库，文件数量动辄几万个。如果每次冷启动都递归 restorecon，耗时可能高达数百毫秒甚至超过一秒。

Android 的默认设计是用file_contexts.bin和seapp_contexts来管理，并且在编译期就完成大部分标签设置。车机项目经常因为手写 rc 文件时把某些目录顺序搞乱，导致扫描路径重复，这个坑我们踩过：在某个项目里/data下有一个厂商创建的日志目录，没有写进file_contexts，每次开机 init 都会对整棵/data递归打标签，冷启动硬生生多出 800ms。后来把目录加入上下文并清理一次标签，问题立刻消失。

所以遇到 init 阶段耗时异常，先抓logcat -b events看有没有大量restorecon_recursive调用，或者直接看dmesg里的avc日志。这是很多工程团队会跳过的一步，但往往是性价比最高的修复点。

4. Zygote 与 SystemServer：车机“大脑”的冷启动主战场

到了 Zygote 和 SystemServer，才是 Framework 工程师最有话语权的阶段。冷启动总耗时里，Zygote 和 SystemServer 通常合起来能占到 4s 到 7s，几乎所有肉眼可见的优化都发生在这条链路。

4.1 Zygote 的 preload 机制：车机能用但别乱砍

Zygote 的入口是frameworks/base/core/java/com/android/internal/os/ZygoteInit.java。它启动后第一件事就是preload()，逻辑里主要做两件事：

• preloadClasses()：加载frameworks/base/config/preloaded-classes里列出的类。这个文件里的类通常比较多，目的是让 SystemServer 和常见 App 启动时不用重复从磁盘加载。
• preloadResources()：预加载公共主题资源、drawable 等。

对于车机项目，这两个预加载既可以是加速器，也可以是累赘。车机不像手机那样有大量第三方应用轮流启动，预加载的类里很多是面向通用 Android 的，在车机平台上派不上用场却有加载成本。裁剪preloaded-classes是真实可行的优化手段，但它极容易翻车：删掉一个 SystemServer 启动时会用到的类，直接表现为系统起不来或者启动到一半崩掉。

我的建议是，先用trace拉一条完整启动的类加载记录，找出实际加载的前 200 个类占掉的时间，再对比 class list 里哪些类是“从未被使用”的。这个优化通常只能挣到一两百毫秒，但它发生在 Zygote 早期，会波及后面所有 App 的启动手感，值得做但不是主线。

frameworks/base/config/preloaded-classes

上面这个文件在 AOSP 源码里是编译期生成的，但车机 vendor 完全可以通过修改编译脚本生成适合自己的裁剪版本。这个操作需要在项目初期就规划，否则后面加需求很容易把删除的类又引回来。

4.2 SystemServer 的启动顺序：为什么锁屏前要等这么久

Zygote 准备好后，会通过 fork 出一个独立进程来运行 SystemServer。SystemServer 的入口是frameworks/base/services/java/com/android/server/SystemServer.java。它的main()很简单，创建SystemServer实例，调用run()。

run()里有一句很关键的注释和逻辑：先创建SystemServiceManager，然后依次执行：

1. startBootstrapServices()：启动 Installer、ActivityManagerService、PowerManagerService、DisplayManagerService、PackageManagerService 等基础服务。
2. startCoreServices()：启动 BatteryService、UsageStatsService、WebViewUpdateService 等。
3. startOtherServices()：启动 WindowManagerService、InputManagerService、CameraService 以及系统 UI 相关的服务。

每个服务启动时都会向SystemServiceManager注册，并且有onBootPhase回调。Android15 的启动阶段包括PHASE_WAIT_FOR_DEFAULT_DISPLAY、PHASE_LOCKED_BOOT_COMPLETED、PHASE_BOOT_COMPLETED等。车机的 CarService 就是依赖这些 phase 来决定何时开始绑定 VHAL。

从源码层面来看，SystemServer 慢的根因通常不是单个服务初始化代码有多慢，而是服务之间的同步 binder 调用排队。举个例子，WMS 初始化时需要读取 DisplayManagerService 创建的 Display 信息，而 DMS 又要等 SurfaceFlinger 准备好；此时如果一个线程卡在别家服务的锁上，整个链条都会停顿。

4.3 AMS 与 PMS：车机项目里排队最严重的一对组合

ActivityManagerService 和 PackageManagerService 是 SystemServer 阶段最重量的两个服务。PMS 在冷启动时要扫描/system、/vendor、/data下的 APK，解析 manifest，建立包信息缓存。手机平台上这个量级已经很可观，车机上因为预装了大量车控、地图、音效等服务，包数量只多不少。

源码里 PMS 有自己的线程和 Handler，扫描不是全部阻塞在 SystemServer 主线程上，但后续 AMS 要依赖 PMS 查询结果来做进程管理，所以两个服务之间形成了天然依赖。车机项目里常见的问题是：/data分区在 OTA 之后没有及时生成扫描缓存，冷启动 PMS 不得不重新解析大量 APK，时间暴涨到 3s 以上。

我在某个项目里通过对比dumpsys package的缓存命中情况，发现很多车控 APK 的.apk文件用的仍是 Debug 签名和未对齐的 zip 结构，导致 PMS 解析时走的路径比 release 包慢不少。后来强制供应商重新出包，统一做zipalign和 AOT 编译，SystemServer 阶段直接少了将近 1s。这个属于编译链问题，不在源码逻辑里，但对冷启动的影响非常巨大。

4.4 CarService 在 SystemServer 链路里的位置

车机相比手机，最大的特色就是 CarService。CarService 相关源码主要在packages/services/Car/service/src/com/android/car/下，它负责与车辆硬件抽象层 VHAL 通信，对外提供车辆属性、音频、定位、座舱控制等服务。

CarService 的启动依赖 SystemServer 的辅助服务，通常是在 SystemServer 准备到一定程度后才拉起。它自身也要初始化一批子服务，包括 CarPropertyService、CarAudioService、CarLocationService 等。冷启动优化里最怕的是 CarService 初始化时同步读取大量车辆属性，比如油量、车门状态、空调温度，如果 VHAL 某个属性的读取回调实现很慢，CarService 就会卡在 Binder 调用上。

从源码规约的角度，车控属性的读取本来就该异步化。但很多供应商的 VHAL 实现里，getProperty方法会等待 CAN 总线数据返回，一旦总线调度没起来，冷启动就会多等几百毫秒。这个问题的排查链路很有意思，后面我会专门提。

5. 从 SystemServer 到 Launcher：桌面首帧的关键路径

SystemServer 启动到一定阶段后，AMS 会调用systemReady()，系统开始拉起 home 应用。这一步之后，用户感知的“开机完成”才正式开始倒数。

5.1 桌面启动器等待的是什么

拉的 home 应用不一定是 Launcher，而是所有声明了CATEGORY_HOME的 Activity。车机项目通常会把桌面 Launcher 做成 persistent 进程，或者至少在开机时被高优先级拉起，目的是保证它常驻内存，切换任务时不需要重新冷启。但即便是 persistent 进程，系统刚开机时它也还没创建，第一次启动依然走完整进程创建流程。

从源码角度，ActivityTaskManagerService.startHomeActivityLocked会获取 HOME intent 的解析结果，如果解析不到或暂时处于锁屏状态，会延迟启动。在车机上，还要考虑用户是否处于驾驶安全模式，有些桌面启动器在“驾驶模式”下会切换成极简界面，这个逻辑如果放在onCreate里做同步判断，首帧也会被拖慢。

5.2 从 Activity 冷启动到首帧：waiting for first frame

Launcher 进程创建后，要走的标准链路是：Application.attach->Activity.onCreate->onResume-> 第一帧绘制。这个过程在 Android 源码里对应的是ActivityThread的handleLaunchActivity逻辑。

首帧需要经过 View 的 measure、layout、draw，然后通过RenderThread发给 SurfaceFlinger 合成。用户看到的“桌面出现了”，其实可能只是 Window 被画出来了，真正的数据请求可能还在后台。车机桌面经常会在onCreate里启动一堆车辆数据的订阅，比如 GPS、来车预警、空调状态，这些监听注册少则几百毫秒，多则几秒。如果桌面把首帧绘制排在所有订阅完成之后，那用户就得盯着品牌 logo 发呆。

正确做法是让首帧立即绘制，车辆数据通过异步回调刷新 UI。这个改动不涉及 Framework，只涉及桌面 APK 自身，但对可感知启动时间的影响非常直接。在 Android15 车机上还有一个注意点：启动画面的 SplashScreen 机制。桌面如果禁用了 SplashScreen，冷启动会短暂白屏，看起来反而比有 SplashScreen 更慢；如果保留 SplashScreen，又可能因为主题资源加载拖慢首帧。取舍要看具体方案，但无论如何，首帧时间必须以reportFullyDrawn或onFirstFrame回传为准，而不是桌面 onCreate 的时刻。

5.3 主屏首帧与副屏首帧的优先级拉扯

车机多屏场景是我这几年处理过最麻烦的部分。SystemServer 刚把主屏 Launcher 拉起来，副屏的 Cluster 很可能也同时启动。两路渲染都要 GPU 合成，硬件资源有限，互相抢带宽，最终结果是两边都不快。

源码层面，WindowManagerService 管理多个 Display 的窗口层级，SurfaceFlinger 负责合成。优化的一个常用手段是让较不重要的副屏延迟创建 Display，或者给主屏窗口设置更高的z-order和合成优先级。这个调整在DeviceConfig或 WMS 的窗口策略里都有参数，但需要结合具体平台验证。我们项目里最终采用了“先主屏后副屏”的策略，主屏 Launcher 首帧提前了约 400ms，副屏最多慢 200ms，整体用户感知更合理。

6. 基于源码的 Android15 冷启动优化手段汇总

这一节把我实际验证过、或者看过源码确认有收益的优化方向列一下。优先讲能从 AOSP 源码层面直接落地的，少讲那些依赖供应商外部 hack 的方案。

6.1 调整 Zygote 类预加载与资源预加载

前面提到过preloaded-classes可以裁剪。实际操作时，我会先确认两个问题：项目里是否大量复用手机基线？SystemServer 和常见 App 是否真的需要所有预加载类？如果答案是“大量复用”，裁剪收益就会很明显，但要建立专项测试机制，防止某个类被间接加载后导致行为异常。

资源预加载也有类似空间。车机平台的主题资源比手机少，但厂商会把大量车控图标塞进 framework res 里，导致preloadResources变慢。可以在frameworks/base/core/res/res下做资源瘦身，或者将常用资源改为异步加载。这个优化比类加载更敏感，因为资源 ID 的改动会牵连大量 APK 编译，必须在项目初期就冻结方案。

6.2 SystemServer 里线程模型与 Binder 池的调优

SystemServer 启动期特别容易出现 Binder 线程排队。默认系统进程的 Binder 线程数有限制，当 PMS、AMS、WMS、CarService 同时发起大量跨进程调用时，调用方线程会在 Binder 驱动里排队，表现就是启动速度变慢。

在源码层面可以调整ProcessState里的线程池上限，增加binder线程数，让早期同步调用不必等空闲线程。也可以优化服务启动顺序，把没有依赖的初始化放到后台线程。Android15 的 SystemServer 里很多服务其实已经用了独立线程池，但车机项目会增加额外服务，线程模型很可能不够用。

我见过一个典型问题：某车机在启动阶段有 6 个服务同时回调 CarService 查询车辆属性，而 CarService 只有一个工作线程，结果所有回调在锁上排队，启动耗时多了 700ms。后来给 CarService 引入独立的 HandlerThread，并把属性查询改为批量合并，问题解决。

6.3 Package 扫描缓存与 dexopt 策略

PMS 冷启动扫描是 SystemServer 耗时的重要组成部分。Android 在编译期会用dex2oat生成 AOT 缓存，但 APK 如果过于老旧或未对齐，扫描路径会明显变长。

车机项目应当从发行端强制要求所有 APK 使用 release 签名、zip 对齐，并预生成 odex/vdex 缓存。OTA 之后首次冷启动通常会重建部分缓存，这个现象虽然难以完全消除，但可以通过分区预构建缓存来规避。Android15 对art的缓存路径和格式也有一些变化，厂商需要对应升级编译脚本，否则冷启动时会发现 dexopt 状态异常，静默走解释执行，启动时间直接翻倍。

6.4 启动阶段 CarService 与 VHAL 的异步化

CarService 的启动依赖 VHAL，但 VHAL 本身是一个独立的 HAL 进程，通过 HIDL/AIDL 和 CarService 通信。如果 CarService 在onCreate阶段就同步绑定 VHAL，并等待所有属性就绪，冷启动就会被底层车辆总线拖累。

优化思路是分两层：

• CarService 先完成自身服务注册，立即让 SystemServer 进入后续阶段。
• 车辆属性的批量获取放到后台线程，使用回调把结果推给上层。

我在某个项目中就是靠这个改动把 CarService 相关耗时从 1.4s 压到 0.6s。VHAL 里的 CAN 数据读取没法变快，但我们不再阻塞主链路等待它，效果立竿见影。

6.5 开机动画与 SystemUI 的取舍

开机动画在车机上是一个两极分化的问题。很多项目为了“高级感”使用高分辨率视频动画，结果动画本身解码耗电又耗时。从源码层面看，开机动画线程会占用主屏 SurfaceControl，和 SystemUI 启动存在资源竞争。

建议是：开机动画尽量在 init 早期全局停止，或者使用低分辨率短动画；SystemUI 的初始化不要依赖开机动画播完。有一个很容易忽略的细节是，Android15 的 SystemUI 里 car 模式会有独立的CarSystemUI服务，它启动时如果去同步获取大量图标资源，也会拖慢整体。这里同样能用异步化解决。

7. 冷启动指标埋点与一次真实的链路瓶颈排查

优化不是拍脑袋，而是要有完整的时间戳数据。冷启动链路很长，每一层都要埋好打点，否则出了问题根本定位不到是哪一段。

7.1 常用埋点与观测手段

Android 系统本身提供了大量 boot 事件，在logcat -b events里可以直接看到：

adb shell logcat -b events -d | grep -E "boot_progress|am_proc_start|am_activity_launch_time"

常用的关键事件包括：

• boot_progress_start：启动开始。
• boot_progress_system_run：SystemServer 开始运行。
• boot_progress_enable_screen：屏幕点亮。
• am_proc_start：进程启动记录。
• am_activity_launch_time：Activity 启动耗时。

Framework 内部也可以用systrace抓取启动期间的 CPU、Binder、Surface 事件：

adb shell atrace --async_start --timeout 20 -b 16384 cpu freq idle disk binder_driver # 冷启动完成后执行 adb shell atrace --async_stop -z -o /data/local/tmp/trace.txt

车机项目最好在 SystemServer 各阶段自己加自定义打点，统一上报到云端。我们项目里维护了一张内部表，字段包括 T0 时间、bootloader 日志时间、kernel 时间、init 完成时间、SystemServer 完成时间、CarService ready 时间、Launcher drawn 时间。只有拆到这个粒度，才谈得上定位瓶颈。

7.2 一次真实的冷启动数据复盘

下面是一组脱敏后的实际数据，不是虚构，但做过模糊处理：

这个项目起初客户觉得“就是慢”，但没人说得清慢在哪。埋点之后发现，Bootloader 到 Kernel 的 2.1s 里 AVB 校验占了 1.4s，于是推动 BSP 把vbmeta和 boot 分区的校验策略优化了一下，降了 0.5s。SystemServer 到 CarService ready 的 1.4s 里，一半时间卡在 VHAL 的属性同步读取上，按前面说的方法异步化后降了 0.6s。Launcher drawn 的 1.6s 里，桌面 APK 首帧前等待了 GPS 回调，改为异步刷新后降了 0.4s。三轮优化下来，总耗时从 10s 降到 7.5s，客户可感知提升非常明显。

7.3 定位“卡在某个 Binder 调用”的完整排查链路

有一次，我们的 SystemServer ready 时间比上一个大版本多了 800ms。只看总耗时基础日志看不出端倪，但systrace显示system_server主线程上有一个很长的 Binder 等待段，等待的目标是car_service。

排查过程是这样的：

1. 抓systrace，定位system_server线程里最长的 cut slice，发现是CarServiceHelperService在调用某个car_service接口。
2. 再抓dumpsys activity service CarService，确认请求线程是否卡在锁上。
3. 在 CarService 内部增加临时 log，看到它确实在等待一个属性读取回调。
4. 追到 VHAL 实现，发现该属性的读取需要 CAN 总线应答，而 CAN 总线的调度被设定为等待另一个模块初始化完成。
5. 最终把属性读取改为异步非阻塞，并增加 100ms 超时保护，冷启动 SystemServer 阶段恢复原状。

这个排查让我养成了一个习惯：任何冷启动时间回退，先看是不是新增了某个同步调用，再去分析服务本身。百分之八十的“启动时间莫名其妙的慢”，都是有人在主链路上塞了一段不在计划内的 Binder 同步等待。

回到主题上，Android15 车机冷启动的源码链路其实不算复杂，但每一层都有可以被“无意识”拖慢的点。我个人的项目经理是：先把埋点体系建起来，再按 Bootloader、Init、SystemServer、CarService、桌面这一条主链路做多次切片，不要一上来就动大手术。车机项目的时间优化，本质上是把每一小段无意义的等待都删掉，用户不会记得某个服务有多优雅，只会记得点火之后中控屏什么时候能摸。