车机 Android 开机优化复盘：我怎么和 AI 一起把问题定位到 SystemUI

背景

车机Android系统定制，客户合同要求冷启动速度在20s以内，现在版本刚好卡在了多一丢丢的21.5+，没办法只能想办法优化，这个过程十分无聊，所以用ai协助，我只负责输出想法。

先说结论

这次排查的是一个很具体的问题：车机上电后，到肉眼看到首页，大概需要 21-22s。全局对比工具使用log+bootchart做参数对比和数据展示；

一开始我也和很多人一样，先怀疑 Home。首页一般会连车控、空调、媒体，还可能初始化一堆插件。后来一轮轮测下来，结论变了：

Home 不是最大瓶颈，自定义车机 SystemUI 才是这次影响开机动画退出和首页可见时间的主线。

切换到更轻的 CarSystemUI 后，肉眼看到首页从约 21s 降到约 18s。日志里的 sf_stop_bootanim也从 18.277s 降到 15.547s，差不多提前 2.7s。

几个核心数据放在前面：

|--------------------------------|-----------|--------------------|-----------|
| 指标 | 旧系统参考 | 切换轻量 CarSystemUI 后 | 变化 |
| 肉眼首页可见 | 约21s | 约18s | 约3s |
| sf_stop_bootanim | 18.277s | 15.547s | 约2.73s |
| TotalBootTime | 10.584s | 7.954s | 约2.63s |
| SystemUI StartServices | 2346ms+ | 1043ms | 约1.3s+ |
| CarSystemBar | 1255ms+ | 787ms | 约0.47s+ |
| SystemUIOverlayWindowManager | 674ms+ | 69ms | 约0.60s+ |

这个结论不是拍脑袋来的。中间我用极简 Home、极简副屏 Home、移除升级服务、移除 HVAC 等方式做了多轮 A/B。每一轮都只动一个变量，然后看 sf_stop_bootanim、Home 首帧、SystemUI timing 和 Bootchart。

最后发现一个很容易被忽略的点：

Home 画完，不代表用户已经能看到 Home。

如果 WindowManager 还没有放行、SystemUI 还在同步初始化、SurfaceFlinger 还没有停掉 boot animation，首页就算已经绘制完成，也只是被挡在开机动画后面。

分析过程

先别急着删 APK，先把尺子拿出来

我最开始只有一个肉眼结论：大概 21-22s 能看到首页。

这个结论太粗了。Android 开机中间有很多阶段，任何一个阶段慢，都可能被误认为"首页慢"：

• init 启 native service
• zygote 和 system_server 启动
• SystemUI 启动
• Home 启动
• WindowManager enable screen
• SurfaceFlinger 停 boot animation
• 用户看到首页

所以第一步不是优化，而是把观测方式固定下来。

我让 AI 帮我把需要看的指标列出来。后面每轮测试基本都看这一组：

adb shell getprop sys.boot_completed
adb shell getprop dev.bootcomplete
adb shell getprop init.svc.bootanim
adb logcat -b events -d | grep -E 'boot_progress_enable_screen|sf_stop_bootanim|am_proc_start|wm_activity_launch_time'

同时打开 Bootchart：

adb shell 'mkdir -p /data/bootchart; echo 120 > /data/bootchart/enabled; sync'

手动重启后再拉数据：

adb pull /data/bootchart ./bootchart-current

这一步挺重要。没有 Bootchart 和 events log，我大概率会一直围着 Home 和开机自启应用转。

第一个假设：是不是 Home 太重

车机 Home 复杂是常态。它可能要连车控服务、拿空调状态、订阅媒体、初始化语音入口、加载各种卡片。怀疑 Home 很合理。

但合理不代表正确。

我做了一个极简单页 Home 来验证。包名、Activity 和签名都保持一致，只保留一个静态界面，不连车控，不做复杂初始化。相当于问系统一个问题：如果 Home 什么都不干，启动能不能明显变快？

结果如下：

|------------------------|-----------|-----------|
| 指标 | 原 Home | 极简 Home |
| TotalBootTime | 12.343s | 11.458s |
| sf_stop_bootanim | 20.260s | 19.147s |
| Home 首帧 | 未埋点 | 15.122s |
| HomereportFullyDrawn | 未埋点 | 15.298s |
| Home focus | 约20s | 19.162s |

极简 Home 有收益，但不大，sf_stop_bootanim 大约提前 1.1s。

真正让我改变判断的是这个时间差：

Home 在 15.3s 左右已经 reportFullyDrawn，但 boot animation 到 19.1s 左右才停。

也就是说，Home 已经画好了，用户还是看不到。这个时候继续把 Home 从 200ms 优化到 100ms，意义就没那么大了。挡在前面的更像是 WindowManager、SystemUI、CarService 这一段。

副屏 Home 缺失，确实有影响

接着我看到了另一个问题：系统日志里反复出现副屏 Home 解析失败。

类似这种：

No home screen found for SECONDARY_HOME

车机多屏环境下，副屏 Home 缺失会让 WindowManager 走失败路径。这个问题不一定是最大瓶颈，但它肯定不干净。

我做了一个极简 SECONDARY_HOME，只满足系统解析，不做业务。

结果：

|--------------------|-----------|-----------------------------|
| 指标 | 极简 Home | 极简 Home + 极简 SECONDARY_HOME |
| TotalBootTime | 11.458s | 10.139s |
| sf_stop_bootanim | 19.147s | 17.785s |
| 主屏 Home 首帧 | 15.122s | 15.728s |
| 副屏 Home 首帧 | 无 | 15.395s |
| 主屏 Home focus | 19.162s | 17.855s |

这轮有效，sf_stop_bootanim 提前了约 1.36s。

但修完副屏 Home 后，启动仍在 18s 左右。这个收益有价值，却还不是最后的大头。

那些看起来可疑的系统应用，并没有决定首页时间

Bootchart 里能看到很多应用在开机阶段启动。第一眼看过去，每个都像嫌疑人。

我和 AI 一起把它们分成几类，然后逐个做 A/B。这里我挑两个典型例子。

systemupdater

我先试了 pm disable-user，结果发现它是 system uid / persistent 类型，禁用后进程仍会被拉起。

后来改成临时移走 APK 来验证。

|----------------------|-----------|-----------|
| 指标 | 移除前参考 | 移除 APK 后 |
| systemupdater 进程启动 | 16.101s | 无 |
| Home focus | 待补充 | 18.415s |
| sf_stop_bootanim | 18.351s | 18.365s |
| TotalBootTime | 待补充 | 10.574s |

结果很干脆：进程没了，sf_stop_bootanim 没变。

它不是主瓶颈。

HVAC

HVAC 看上去也可疑，因为它和车机首页关系很近。我也做了移除 APK 的 A/B。

|--------------------------------|--------------------|---------------------------|
| 指标 | 移除 systemupdater 后 | 移除 systemupdater + HVAC 后 |
| com.tyw.hvac 进程启动 | 16.143s | 无 |
| Home focus | 18.415s | 18.333s |
| sf_stop_bootanim | 18.365s | 18.277s |
| TotalBootTime | 10.574s | 10.584s |
| SystemUI StartServices | 2701ms | 2346ms |
| CarSystemBar | 1414ms | 1255ms |
| SystemUIOverlayWindowManager | 908ms | 674ms |

这轮有个细节：SystemUI 内部 timing 确实下降了一点，但最终 sf_stop_bootanim 只改善了约 0.09s。这个量级基本可以当作波动。

所以我把 HVAC 从"最大嫌疑"里拿掉了。

有些服务不能靠删除来验证

我也试过移除更底层的车控服务，比如 tywos、vehicle 这类基础服务。

结果很直接：设备无法正常进首页。

这类服务不能按普通业务 APK 处理。它们可能参与 CarService、Vehicle、SystemUI 或 Home 的基础链路。要优化它们，应该保留服务壳，延后重逻辑，或者给首屏前的同步调用加超时降级。

这个坑让我更确定一件事：开机优化不是删得越多越好。删到基础依赖，系统就起不来了。

问题开始指向 SystemUI

到这一步，几个方向基本排掉了：

• Home 不是最大瓶颈。
• 副屏 Home 缺失有影响，但不是最终大头。
• systemupdater 不是主瓶颈。
• HVAC 不是主瓶颈。
• 底层车控服务不能直接删。

剩下最扎眼的是 SystemUI。

旧系统里几个 SystemUI 指标偏高：

|--------------------------------|-----------|
| 项目 | 旧系统参考 |
| SystemUI StartServices | 2346ms+ |
| CarSystemBar | 1255ms+ |
| SystemUIOverlayWindowManager | 674ms+ |

后面我通过刷机方式去掉原来的自定义车机 SystemUI，换成更轻的 CarSystemUI。这轮变化非常明显：

|--------------------------------|-----------|-----------|
| 指标 | 切换前参考 | 切换后 |
| boot_progress_enable_screen | 15.812s | 13.595s |
| 主屏 Home 启动 | 15.913s | 13.702s |
| 副屏 Home 启动 | 16.014s | 13.765s |
| sf_stop_bootanim | 18.277s | 15.720s |
| TotalBootTime | 10.584s | 8.073s |
| SystemUI StartServices | 2346ms | 1437ms |
| SystemUIOverlayWindowManager | 674ms | 82ms |

之后我又重新采了一轮 Bootchart，结果稳定在同一水平：

|--------------------------------|-----------|
| 指标 | 新系统复采 |
| TotalBootTime | 7.954s |
| boot_progress_enable_screen | 13.416s |
| sf_stop_bootanim | 15.547s |
| SystemUI StartServices | 1043ms |
| CarSystemBar | 787ms |
| SystemUIOverlayWindowManager | 69ms |

这时我基本可以下结论：

自定义车机 SystemUI 是这次影响首页可见时间的主要原因。

我没有把全部 2.7s-3s 都算到 SystemUI 头上。因为刷机后 Home 和车机包集合也发生了变化。但从前面几轮 A/B 看，SystemUI 是证据最强的一条线。

AI 在这里具体帮了什么

这次我没有让 AI 直接给"优化方案大全"。那种回答看起来热闹，落地时经常没法判断收益。

我主要让 AI 做四件事。

第一，把日志拆成假设。

比如 Home 是否太重，副屏 Home 是否缺失，SystemUI 是否挡住交屏，boot animation 是否因为 WindowManager 没放行才迟迟不退出。

第二，帮我设计 A/B 顺序。

每轮只动一个变量。极简 Home、极简副屏 Home、移除 systemupdater、移除 HVAC、切换 SystemUI，一轮一轮做。这样即使某一轮没收益，也能排除一个方向。

第三，把肉眼感受翻译成指标。我后来主要看：

• sf_stop_bootanim
• boot_progress_enable_screen
• SystemUI StartServices
• CarSystemBar
• SystemUIOverlayWindowManager
• Home 首帧
• Home focus
• Bootchart 采样窗口

第四，每轮测试后及时写结论。

这一步很普通，但很有用。启动优化很容易越查越散，如果不及时记录，很快就会忘记上一轮到底排除了什么。

后面还可以怎么做

后续如果继续做源码侧优化，我会从 SystemUI 开始，而不是继续删 APK。

优先看这几个点：

1. 拆 CarSystemBar，只保留首屏必须的最小系统栏。
2. 对比旧 SystemUI 和当前 CarSystemUI 的 SystemUIOverlayWindowManager 初始化路径。
3. 检查 TopNotificationPanelViewMediator、HVAC panel、vendor SystemUI 插件有没有在首屏前同步初始化。
4. 检查 SystemUI 是否同步等待 CarService / Vehicle / HVAC / Display 状态。
5. 把非首屏必须逻辑延后到首页可见后再加载。

大致收益预估：

|----------------------------------------|--------------|
| 优化范围 | 预计收益 |
| 只优化旧 SystemUI 中最重的同步初始化项 | 1.5-2.5s |
| 优化到接近当前CarSystemUI 水平 | 2.5-3.0s |
| 在当前CarSystemUI 基础上继续拆 CarSystemBar | 额外0.5-1.0s |

结尾

启动慢不一定慢在你第一眼看到的地方。

Home 很复杂，但它不是这次的最大瓶颈。很多应用启动得早，但移除后并不影响 sf_stop_bootanim。真正影响用户什么时候看到首页的，是 WindowManager 什么时候放行、SurfaceFlinger 什么时候停掉 boot animation，以及 SystemUI 在这之前做了多少同步工作。

如果只记一条经验，我会记这条： 先用指标证明谁挡住了交屏，再谈优化。

AI 在这次排查里最大的价值，不是替我下结论，而是帮我把混乱的日志变成一轮轮可验证的实验。最后拍板的，还是设备上的 Bootchart 和 events log。