解读

车载场景对地图 App 的“稳”与“省”要求远高于手机：

1. 车机 SoC 性能普遍落后同期旗舰手机 1-2 代，GPU 浮点与带宽只有手机 60 % 左右；
2. 7×24 常驻，系统可用内存常年 <1.5 GB，且随时被导航、语音、多媒体抢占；
3. 60 fps 是车厂硬性验收红线，掉帧即视为安全类 Bug；
4. 高温、颠簸、电源不稳，GC 抖动或 GPU 瞬时峰值会直接触发车机守护进程杀进程。
   因此面试官想听到的是：能否把车机当成“低端嵌入式设备”来做内存与 GPU 的联合治理，而不是简单罗列手机端常规套路。

知识点

• 车载硬件画像：AArch64 低功耗大核 + Mali-G52 级别 GPU + LPDDR4 25 GB/s 带宽
• Android Automotive OS：系统级权限、无 GMS、可源码级定制，SELinux 严格、不可随意访问 sdcard
• 地图渲染管线：矢量瓦片 → 解析 → 三角化 → VBO/IBO → OpenGL ES 3.1 / Vulkan → GPU
• 内存大户：瓦片缓存、路网索引、POI 图标纹理、字体 atlas、离线语音包
• GPU 瓶颈：OverDraw、复杂 Clip、实时阴影、矢量道路反走样、每帧 Upload 新纹理
• 工具链：Perfetto GPU 计数器、Mali Graphics Debugger、Android Studio Memory Profiler、定制 SystemTracing atrace 标签
• 车规级优化：ZRAM+lmkd 调优、Ashmem 匿名共享、GraphicBuffer 零拷贝、HardwareBuffer 跨进程复用、GPU 频率锁、热降频监听

答案

“我会把优化拆成‘内存’与‘GPU’两条线，每条线按‘度量 → 归因 → 治理 → 验证’四步闭环，并针对车机做专项适配。”

一、内存治理

1. 度量

   • 车机无 root 权限，用 adb shell perfetto -c gpu.cfg -o /data/misc/perfetto/trace 抓取 30 s 全系统 trace，重点关注 GFX 与 memory.ion 曲线；
   • 在代码中插桩 Atrace.beginAsyncSection("MapTileCache")，精确到瓦片级。

2. 归因

   • 离线回放 trace，发现地图进程高峰 PSS 1.4 GB，其中 ashmem 占 580 MB，主要为 512×512 矢量瓦片纹理缓存；
   • 用 dumpheap 发现 Kotlin 对象里 LinkedHashMap$Entry 占 210 MB，为 POI 聚合索引泄漏。

3. 治理
   a) 缓存分层：

   • 内存层只保留当前城市 L15 级以内矢量数据，LRU 阈值设为 80 MB；
   • 磁盘层采用 SQLite+Blob，按城市分库，页大小 16 KB，对齐 eMMC 擦除块；
   • 预研 Android 12 新 API android.hardware.HardwareBuffer，把 30 MB 以上的路网索引直接放 DEVICE_LOCAL + CPU_READ_RARELY，GPU 侧零拷贝。
     b) 对象池：
   • 对 LatLng、PointF 等频繁创建的小对象使用 ObjectPool + SynchronizedPool，单例化后 GC 次数从 18 次/min 降到 3 次/min；
   • 对 Kotlin 协程使用 Dispatchers.IO.limitedParallelism(2)，防止线程爆炸导致 4 MB 栈内存叠加。
     c) 资源压缩：
   • POI 图标 256 色足够，全部转 ETC2_RGBA8，平均 28 KB→12 KB；
   • 字体 atlas 采用 msdf 有向距离场，一张 512×512 可覆盖 2 万汉字，内存从 12 MB 降到 1.5 MB。

4. 验证

   • 连续 4 h monkey 测试，PSS 峰值 ≤ 850 MB，lmk 0 次；
   • 冷启动到首帧地图 ≤ 1.8 s，满足车厂冷启动规范。

二、GPU 渲染

1. 度量

   • Mali-G52 提供 gpu_cycles, tex_cycles, overdraw_count 三组计数器，用 mali_gputrace 抓取 60 s；
   • 发现每帧 OverDraw 4.8×，复杂路口三角面 12 万，帧时间 22 ms。

2. 归因

   • 矢量道路反走样采用 4×MSAA，带宽直接翻倍；
   • 实时楼影每帧重新生成 ShadowMap，纹理上传 16 MB；
   • 透明 POI 标签未排序，GPU 反复 AlphaBlend。

3. 治理
   a) 渲染降级：

   • 车机屏幕 dpi 普遍 160-200，关闭 MSAA，改用 1 px 几何外扩 + 边缘着色器做 fxaa 近似，三角面减少 35 %，帧时间 22 ms→14 ms；
   • 楼影改为 2 s 一次离线烘焙，ShadowMap 512→256，上传量 16 MB→2 MB。
     b) 批处理：
   • 同材质道路合并为单 glMultiDrawElementsIndirect，DC 从 180→22；
   • 图标纹理打包到 2048×2048 大 Atlas，GPU 采样缓存命中率提升 40 %。
     c) 频率与温控：
   • 监听 /sys/class/thermal/thermal_zone0/temp，>85 ℃ 时动态降低地图 LOD 到 L13，GPU 频率从 850 MHz 锁 600 MHz，保证不掉帧。

4. 验证

   • 60 fps 稳帧率 ≥ 98 %，连续 2 h 车载路测无 GPU 降频；
   • GPU 利用率均值 62 %，峰值 78 %，留 20 % 余量给语音助手突发动画。

三、车规级兜底

• 集成 android.car.CarWatchdogManager，当系统可用内存 <200 MB 时主动释放非关键缓存；
• 采用 android.app.Service.startForeground() + CAR_NOTIFICATION_PRIORITY_HIGH，防止后台被 lmkd 误杀；
• 发版前通过车厂 200 小时高低温循环测试，内存泄漏 ≤ 2 MB/24 h。

拓展思考

1. 如果车机升级到 Vulkan 1.1，可把矢量三角化后顶点放 DEVICE_LOCAL 显存，CPU 侧零拷贝，但需重写 vkCmdBindVertexBuffers 管线，如何权衡移植成本与收益？
2. 当车辆进入隧道 GPS 信号丢失，地图会瞬间从矢量模式切换为缓存位图，位图大小 8 MB，此时 GPU 上传造成 2 帧卡顿，能否提前用 HardwareBuffer 做双缓冲+异步上传，把卡顿降到 0 帧？
3. 国内项目常砍 GMS，无法使用 Google Play 动态分发，APK 体积 1.2 GB，车厂要求 OTA 差分 ≤ 150 MB，如何把地图数据按城市模块做 split apk + 二进制差分，同时保证版本回滚安全？