28、车载诊断与日志：Logcat使用、车载日志系统、诊断工具、故障排查
做车载开发，说白了就是跟各种奇奇怪怪的bug打交道。你想想看，车机不像手机，死机了重启一下就行。车机出问题，用户可能正在高速上导航，或者倒车看影像。所以，诊断和日志能力，是咱们Android Automotive OS工程师的看家本领。
我个人习惯，每天到工位第一件事，就是先看看昨天的日志有没有异常。别等用户投诉了才去翻日志，那时候就晚了。这一章，我就把我在车载项目里积累的日志和诊断经验，掰开了揉碎了讲给你听。
核心观点：车载日志系统是“第一现场”，诊断工具是“破案工具”。两者结合，才能快速定位问题。
28.1 Logcat：你每天都在用，但可能没用对
Logcat是Android最基础的日志工具。但车载场景下，日志量是手机的好几倍。系统服务、HAL层、应用层，全都在疯狂输出。你如果还用logcat -s慢慢看，效率太低了。
我建议你这样用：
- 按缓冲区过滤：车载系统里，
system、main、events、crash这几个缓冲区要重点关注。特别是crash，一旦有Native崩溃，第一时间看它。 - 按优先级过滤：别开
V级别，那是自找麻烦。我一般从W开始看，如果问题不明显，再降到I。 - 使用
grep组合拳：比如logcat -b all -v threadtime | grep -E "Error|Fatal|ANR"，一秒定位关键信息。
我的小技巧：我曾经遇到一个蓝牙音频卡顿的问题，日志里全是正常信息。后来我用logcat -b events | grep "bt_"，才发现蓝牙协议栈有个超时重试的event，频率异常高。这就是用对了缓冲区的好处。
28.2 车载日志系统：不止是logcat
车机里，除了Android原生的logcat，还有一套更底层的日志系统。为什么？因为很多问题发生在Linux内核层、硬件抽象层，甚至MCU（微控制单元）上。logcat根本抓不到。
常见的车载日志系统包括：
| 日志类型 | 来源 | 查看方式 | 典型问题 |
|---|---|---|---|
| Kernel Log (dmesg) | Linux内核 | dmesg 或 cat /proc/kmsg |
驱动加载失败、中断异常、内存不足 |
| HAL Log | 硬件抽象层 | logcat + 特定tag | Camera HAL死锁、Audio HAL延迟 |
| MCU Log | 微控制单元 | 串口工具或专用诊断通道 | CAN总线通信异常、电源管理状态错误 |
| Persist Log | 系统持久化存储 | logcat -L 或读取 /data/log |
偶现问题、死机后重启分析 |
嗯，这里要注意。Persist Log是车载系统里特别重要的一个设计。车机死机后，内存里的日志就丢了。所以系统会把关键日志实时写入到持久化分区。重启后，你还能看到死机前的最后几秒发生了什么。
避坑指南：我曾经在项目里，发现Persist Log总是被截断。查了半天，原来是日志分区太小，写满了就覆盖了最早的日志。后来我建议把分区从16MB改到64MB，问题解决。所以，量产前一定要评估好日志分区的容量。
28.3 诊断工具：不只是看日志，还要主动“问诊”
光看日志是被动的。有时候问题不出现，你永远不知道哪里有隐患。所以，我们需要主动诊断工具。
我常用的诊断工具和方法：
- dumpsys：这是Android自带的“体检报告”。比如
dumpsys carservice可以查看车载服务的状态，dumpsys audio可以看音频通路是否正常。 - proc文件系统：直接读
/proc下的文件。比如cat /proc/meminfo看内存，cat /proc/cpuinfo看CPU信息。车载系统里，我经常用cat /proc/interrupts来看中断分布，判断是否有硬件中断风暴。 - systrace / perfetto：性能问题的“核武器”。车载系统里，UI卡顿、启动慢，用这个一抓一个准。我建议你重点关注
SurfaceFlinger和InputReader这两个线程。 - 自定义诊断脚本：把上面这些工具组合起来，写成一个脚本。一键执行，输出一份“车机健康报告”。我在项目里就是这么干的，QA同事爱死我了。
举个例子：有一次，用户反馈倒车影像启动慢。我用perfetto抓了一次trace，发现从挂R挡到Camera HAL输出第一帧，中间有个500ms的空闲期。再细看，是CAN信号解析线程被其他任务阻塞了。优化线程优先级后，启动时间从1.8秒降到了1.2秒。
28.4 故障排查：一套标准流程
遇到问题别慌。我总结了一套排查流程，你可以直接套用：
- 复现问题：先确认是不是必现。如果是偶现，记录复现条件（温度、时间、操作步骤）。
- 收集日志：一次性收集所有日志：logcat、dmesg、persist log、tombstone。别漏了。
- 快速定位：用grep搜索关键词。比如搜“Fatal”、“panic”、“OOM”、“watchdog”。
- 深入分析：如果日志不够，用诊断工具主动探测。比如用dumpsys看服务状态，用perfetto看性能瓶颈。
- 验证修复：改完代码后，一定要在同样的条件下复测。特别是偶现问题，要跑至少100次。
我的经验：有一次，车机在高温下（65°C）频繁重启。日志里只看到“thermal shutdown”的提示。但为什么温度会飙升？我用dumpsys battery看了一下，发现电池温度正常，但CPU温度异常。再查，是某个后台服务死循环了，导致CPU满载发热。所以，别只看表面现象，要一层层往下挖。
28.5 知识体系总览
下面这张图，是我对车载诊断与日志体系的总结。你可以把它当作一个“地图”，遇到问题就知道该往哪个方向走。
这张图把日志系统、诊断工具和故障排查流程串在了一起。你从任何一个入口进去，都能找到对应的解决方案。说白了，车载诊断就是“日志+工具+流程”的组合拳。