23、车载性能优化：启动时间优化、内存优化、渲染性能优化、功耗优化
各位同学，今天我们来聊聊车载系统里最让人头疼，也最有成就感的话题——性能优化。
说实话，车载系统和手机不一样。手机卡了，用户顶多骂一句。车载系统卡了，那可是要出大事的。启动慢、界面掉帧、内存泄漏导致黑屏……这些坑我基本都踩过。今天我把压箱底的经验掏出来，咱们一个一个说清楚。
核心观点：车载性能优化的本质，是在有限的硬件资源下，保证系统的实时性、稳定性和流畅度。说白了，就是让车机在启动、运行、休眠的每个环节都“快、稳、省”。
一、启动时间优化：让车机“秒醒”
车载系统的启动时间，是用户对这台车的第一印象。我见过有些项目，冷启动要20多秒，用户都挂上D挡了，导航还没出来。这绝对不行。
Android Automotive的启动流程，核心瓶颈其实在Zygote进程。Zygote是Android的“孵化器”，所有应用进程都由它fork出来。如果Zygote里预加载的类和资源太多，启动自然就慢。
1.1 Zygote预加载优化
Zygote在启动时会预加载一些常用类和资源。但车载场景下，很多预加载的东西根本用不上。比如手机上的联系人、短信相关类，车机上完全不需要。
怎么做？ 修改 zygote.java 中的预加载列表，只保留车载核心组件需要的类。我建议你重点关注这几个方向：
- 剔除无用类：去掉Telephony、Bluetooth（如果非必须）等模块的预加载
- 延迟加载：把非关键类放到首次使用时再加载
- 共享库优化：将多个应用共用的so库提前加载到Zygote中
我的经验：曾经有个项目，启动时间从18秒优化到9秒，核心就是砍掉了Zygote里30%的预加载类。但要注意，别砍过头了——有些类虽然启动不用，但后续频繁使用，如果延迟加载反而会卡顿。需要做profiling分析。
1.2 类预加载（Class Preloading）
除了Zygote层面的预加载，应用自身的类加载也是大头。车载应用通常比较重，比如地图、音乐、设置等，每个应用启动时都要加载一堆类。
我个人习惯用 Baseline Profile 技术。简单说，就是收集用户最常用的代码路径，提前编译成机器码。这样启动时就不用边解释边执行了。
// 在build.gradle中配置Baseline Profile
android {
...
buildTypes {
release {
...
// 指定baseline profile文件
baselineProfile = file("src/main/baseline-prof.txt")
}
}
}baseline-prof.txt 里写什么？举个例子：
HSPLcom/example/car/LauncherActivity;->onCreate(Landroid/os/Bundle;)V
HSPLcom/example/car/NavigationFragment;->onCreateView(...)V
HSPLcom/example/car/MediaPlayerService;->start()V这些是启动时最关键的路径。提前编译好，启动速度能提升30%以上。
注意：Baseline Profile 需要配合 Android 12+ 的 Profile Installer 使用。如果目标平台是 Android 11 及以下，可以考虑用 DexLayout 优化，效果类似但配置更复杂。
二、内存优化：别让车机“失忆”
车载系统的内存通常比手机小，而且不能像手机那样随意杀后台。一旦内存泄漏，轻则卡顿，重则黑屏重启。我在项目中遇到过最严重的一次，是地图应用泄漏了200多MB，导致整个系统OOM。
2.1 内存泄漏检测
检测内存泄漏，工具很重要。我推荐三个：
| 工具 | 适用场景 | 我的评价 |
|---|---|---|
| LeakCanary | 开发阶段快速定位 | 简单好用，但车载上需要关闭自动dump，否则影响性能 |
| Android Studio Profiler | 深度分析堆转储 | 功能最全，但需要手动操作 |
| MAT (Memory Analyzer Tool) | 离线分析大堆文件 | 适合排查疑难杂症 |
常见的泄漏场景：
- 静态变量持有Activity引用：比如单例里存了Context
- 内部类/匿名类：Handler、Runnable没及时移除
- 资源未关闭：Cursor、FileInputStream、BroadcastReceiver
- WebView：这玩意儿是泄漏大户，建议单独进程
避坑指南：我曾经在车载项目里用LeakCanary，结果发现它本身也会占用内存。后来我改成只在debug版本启用，release版本完全移除。另外，车载系统建议用 android:largeHeap="true" 吗？不建议。这会让系统以为你的应用很能吃内存，反而容易触发LMK（Low Memory Killer）。
2.2 Bitmap优化
Bitmap是内存消耗的“头号杀手”。一张1920x1080的图片，加载到内存里就是1920*1080*4字节 ≈ 8MB。车机上动不动就是全屏壁纸、地图瓦片，稍不注意就爆了。
我的优化三板斧：
- 使用inSampleSize采样：不需要原图分辨率时，直接缩小加载
- 使用RGB_565格式：如果不需要透明度，用RGB_565代替ARGB_8888，内存减半
- 复用Bitmap内存：用BitmapFactory.Options.inBitmap，避免频繁GC
// 采样加载示例
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.drawable.big_image, options);
// 计算采样率
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
int inSampleSize = 1;
if (imageHeight > reqHeight || imageWidth > reqWidth) {
int halfHeight = imageHeight / 2;
int halfWidth = imageWidth / 2;
while ((halfHeight / inSampleSize) >= reqHeight
&& (halfWidth / inSampleSize) >= reqWidth) {
inSampleSize *= 2;
}
}
options.inSampleSize = inSampleSize;
options.inJustDecodeBounds = false;
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.big_image, options);小技巧：车载地图的瓦片图片，建议统一用WebP格式。同样质量下，WebP比PNG小30%左右，解码速度也更快。我实测过，地图加载速度提升了15%。
三、渲染性能优化：告别“幻灯片”
车载屏幕越来越大，分辨率越来越高，但GPU性能往往跟不上。渲染性能不好，最直观的表现就是掉帧、卡顿。你想想看，导航画面一卡一卡的，用户能不慌吗？
3.1 GPU过度绘制
过度绘制（Overdraw）就是同一个像素被画了多次。车载系统里，最常见的是背景层层叠加。比如：Activity背景是白色，Fragment背景也是白色，里面还有个白色卡片。结果一个像素被画了3次。
怎么查？打开开发者选项里的“调试GPU过度绘制”，颜色越红越严重。
优化方法：
- 去掉不必要的背景：父布局和子布局背景重复时，只保留一个
- 使用merge标签：减少布局层级
- 自定义View时用clipRect：只绘制可见区域
// 自定义View中裁剪绘制区域
@Override
protected void onDraw(Canvas canvas) {
// 只绘制需要更新的区域
canvas.clipRect(mDirtyRect);
// ... 绘制逻辑
}3.2 布局优化
布局层级越深，measure和layout的时间就越长。车载系统里，我见过最夸张的布局有12层嵌套，一个页面渲染要80ms，远超16ms的黄金标准。
我的建议：
- 使用ConstraintLayout：扁平化布局，减少嵌套
- 避免使用RelativeLayout嵌套：RelativeLayout需要两次measure
- 使用ViewStub延迟加载：不常用的布局，等需要时再inflate
- 使用include标签复用：公共布局统一管理
我的经验：有一次优化车载设置页面，原来用LinearLayout嵌套了5层，改成ConstraintLayout后，层级降到2层，渲染时间从35ms降到8ms。效果立竿见影。
四、功耗优化：让车机“省着点”
车载系统的功耗和手机不一样。手机没电了可以充电，车机没电了……车都启动不了。而且车机功耗会直接影响整车续航（尤其是电动车）。
4.1 Doze模式
Android 6.0引入的Doze模式，在车载上需要特殊处理。手机是屏幕关闭后进入Doze，车机是熄火后进入Doze。但车机有些应用需要保持后台运行，比如远程控制、防盗监控。
怎么做？
- 使用高优先级FCM：但车载网络不稳定，FCM不一定可靠
- 申请部分唤醒锁：但要注意别滥用，否则功耗飙升
- 使用JobScheduler：把非紧急任务合并执行
// 使用JobScheduler合并后台任务
JobInfo jobInfo = new JobInfo.Builder(JOB_ID, serviceComponent)
.setMinimumLatency(5 * 60 * 1000) // 至少5分钟后执行
.setOverrideDeadline(15 * 60 * 1000) // 最多15分钟后执行
.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY)
.build();
JobScheduler jobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);
jobScheduler.schedule(jobInfo);4.2 Alarm对齐
AlarmManager是功耗杀手。每个应用都设置自己的闹钟，系统就得频繁唤醒。车载上尤其严重——地图要定时刷新路况、音乐要检查更新、天气要同步数据……
优化核心：Alarm对齐。把多个闹钟的触发时间尽量对齐到同一个时间窗口。
Android 12+ 提供了 setAlarmClock() 和 setExactAndAllowWhileIdle() 的优化接口。但更推荐的做法是：
- 使用WorkManager：它内部已经做了对齐和合并
- 自定义对齐策略：比如所有非紧急任务都对齐到整点或半点
- 减少精确闹钟：能用
setInexactRepeating就别用setExact
注意：车载系统里，有些闹钟是必须精确的，比如倒车影像的唤醒、碰撞预警的触发。这些不能对齐，否则会出安全问题。一定要区分“安全关键”和“非安全关键”任务。
好了，以上就是车载性能优化的四个核心方向。每个方向都有很多细节，但记住一个原则：优化不是炫技，而是为了用户体验和安全。我在项目中见过太多为了优化而优化的案例，最后反而引入了新问题。稳扎稳打，用数据说话，才是正道。