24、性能优化：启动时间优化、内存优化、GPU 渲染优化、ANR 分析
性能优化这件事，说白了就是让车机系统「快、稳、省」。我在车载项目里摸爬滚打了好几年，最深的体会是：性能问题不是靠最后集中修复解决的，而是从架构设计那天起就要盯紧。今天咱们就聊聊 Android Automotive OS 里最核心的四个性能维度——启动时间、内存、GPU 渲染和 ANR。
核心观点：车机性能优化的本质是「资源博弈」。屏幕更大、功能更多，但硬件资源（CPU/GPU/内存）是有限的。你必须在用户体验和系统开销之间找到平衡点。
24.1 启动时间优化
车机启动慢，用户第一印象就崩了。我见过一个项目，冷启动花了 12 秒，测试团队直接打回重做。启动时间优化的目标很简单：让用户从按下启动键到看到可用界面，控制在 3 秒以内。
24.1.1 启动流程拆解
先搞清楚系统启动到底干了什么。Android Automotive 的启动大致分三个阶段：
- Bootloader + Kernel 加载：硬件初始化、驱动加载。这部分通常由芯片厂商负责，我们能干预的不多。
- System Server 启动：AMS、WMS、PMS 等核心服务启动。这里有个坑——服务越多，启动越慢。
- Launcher 和关键应用启动：用户看到的主界面、导航、音乐等。
我个人习惯用 bootchart 工具抓取启动时序图，一眼就能看出哪个阶段最耗时。命令很简单：
# 抓取启动日志
adb shell 'cat /proc/bootchart_log' > bootchart.tgz
# 生成时序图
python /path/to/bootchart/bootchart.py bootchart.tgz24.1.2 实战优化手段
嗯，这里要注意，不是所有优化都值得做。我建议按投入产出比排序：
| 优化手段 | 效果 | 风险 |
|---|---|---|
| 减少 System Server 中非必要服务 | 节省 500ms-1s | 低，需确认功能依赖 |
| Launcher 预加载 + 懒加载 | 节省 300ms-800ms | 中，注意内存占用 |
| 使用 Profile Guided Optimization (PGO) | 节省 200ms-500ms | 低，需编译时配置 |
| 减少 ContentProvider 初始化 | 节省 100ms-300ms | 中，可能影响数据访问 |
我曾经在一个项目中，发现 Launcher 启动时加载了 20 多个第三方 widget，每个 widget 都要做网络请求。你想想看，车机刚启动，网络还没连上，这些请求全超时了，白白浪费了 2 秒。后来改成「先显示骨架屏，再异步加载 widget」，启动时间直接砍掉 40%。
小技巧：在 AndroidManifest 中给 Launcher Activity 设置 android:windowBackground，用一张和主界面风格一致的图片作为启动背景。这样用户感觉「瞬间就打开了」，实际上系统还在加载。
24.2 内存优化
车机内存通常只有 4GB-8GB，还要跑导航、音乐、语音助手、仪表盘……内存一吃紧，系统就开始杀后台进程，用户切个应用发现要重新加载，体验极差。
24.2.1 内存泄漏排查
内存泄漏是车机开发的头号杀手。我常用的工具是 adb shell dumpsys meminfo 和 Android Studio 的 Memory Profiler。但说实话，最有效的还是「代码审查 + 压力测试」。
常见的泄漏场景：
- 静态变量持有 Activity 引用：比如在 Service 里用 static 变量存了 Context。
- Handler 未移除：Activity 销毁了，Handler 还在处理消息。
- 注册监听未反注册：比如 LocationManager、SensorManager 的监听器。
我曾经踩过一个坑：地图应用里注册了 LocationListener，但退出导航页面时忘了反注册。结果用户开了 2 小时车，内存涨了 300MB，最后系统直接把地图进程杀了。嗯，从那以后我写了个基类，在 onDestroy() 里统一清理所有注册。
24.2.2 内存优化策略
说白了，内存优化就两件事：减少占用 和 及时释放。
// 示例：使用 LruCache 管理图片缓存，避免 OOM
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
int cacheSize = maxMemory / 8; // 分配 1/8 的总内存
LruCache<String, Bitmap> imageCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getByteCount() / 1024;
}
};注意：车机上的 Bitmap 加载一定要用 inSampleSize 做降采样。别直接加载 4K 壁纸到内存里，一张图就吃掉 50MB，太奢侈了。
24.3 GPU 渲染优化
车机屏幕分辨率越来越高（1920x1080 甚至 4K），GPU 压力很大。渲染优化不好，就会出现掉帧、卡顿，用户滑动列表时感觉「黏黏的」。
24.3.1 渲染性能指标
Android 系统用「帧率」和「掉帧率」来衡量渲染性能。我建议关注两个指标：
- 16ms 原则：每帧必须在 16ms 内完成渲染，否则就会掉帧。
- Jank 率：掉帧帧数占总帧数的比例，车机要求 < 5%。
用 adb shell dumpsys gfxinfo 可以查看每帧的渲染耗时：
adb shell dumpsys gfxinfo <package_name> framestats24.3.2 常见渲染瓶颈
我总结了几种最常见的「渲染杀手」：
- 过度绘制（Overdraw）：同一像素被绘制多次。用开发者选项里的「显示过度绘制区域」一看便知。
- 复杂布局嵌套：RelativeLayout 套 LinearLayout 再套 FrameLayout……GPU 要计算很多层。
- 动画性能差：用属性动画代替 View 动画，减少 onDraw 调用。
为什么会这样？说白了，很多开发者习惯「先实现功能，再优化性能」。但渲染优化恰恰相反——布局结构一旦定下来，后期很难改。我建议在写 XML 布局时就打开「GPU 呈现模式分析」，边写边看。
个人经验：车机上的列表（比如音乐列表、设置菜单）尽量用 RecyclerView + DiffUtil，不要用 ListView。DiffUtil 能减少不必要的 item 刷新，GPU 渲染压力小很多。
24.4 ANR 分析
ANR（Application Not Responding）是车机开发中最让人头疼的问题。用户正开着导航，突然弹个「应用无响应」对话框——这要是发生在高速上，后果不堪设想。
24.4.1 ANR 的触发条件
Android 系统会在以下情况触发 ANR：
| 场景 | 超时时间 | 常见原因 |
|---|---|---|
| 主线程 5 秒内未处理输入事件 | 5s | 主线程做了网络请求、数据库操作 |
| BroadcastReceiver 10 秒内未返回 | 10s | onReceive 里执行了耗时操作 |
| Service 20 秒内未执行完 | 20s | Service 里做了大文件读写 |
24.4.2 定位 ANR 根源
ANR 发生时，系统会在 /data/anr/traces.txt 中保存堆栈信息。我习惯用以下步骤排查：
- 抓取 traces 文件：
adb pull /data/anr/traces.txt - 搜索
"main"线程的堆栈，看它卡在哪个方法上。 - 如果是锁竞争，看其他线程持有了什么锁。
我曾经遇到一个经典案例：音乐应用在播放时，主线程调用了 MediaPlayer.getCurrentPosition()，但这个方法的内部实现会持有锁，而另一个线程正在做网络请求也持有了同一把锁。结果两个线程死锁了，主线程卡死，ANR 弹出。解决方案很简单——把 getCurrentPosition() 放到子线程里调用。
避坑指南：我曾经在车载蓝牙模块里，用主线程去连接蓝牙设备。蓝牙扫描本身就要 3-5 秒，再加上配对、服务发现，妥妥超过 5 秒。后来改成用 BluetoothAdapter.startDiscovery() 异步扫描，再通过广播回调结果，ANR 再也没出现过。
24.5 知识体系总览
下面这张图总结了本章的核心知识点，方便你对照复习：
性能优化没有银弹。你想想看，每个项目都有自己的瓶颈——有的卡在启动，有的崩在内存，有的掉帧严重。关键是要学会用工具去「测量」，而不是靠感觉去「猜」。我见过太多团队，花了两周优化启动时间，结果用户反馈说「滑动卡顿」，这就是典型的「优化方向错了」。
最后送大家一句话：先测量，再优化；先解决主要矛盾，再处理次要问题。车机性能优化是一场持久战，但只要你掌握了本章的四个维度，就能做到心中有数、手中有招。