为什么以日志开篇？
因为无论是Android，还是Linux或QNX我们都只是系统的使用者和维护者，即便是二次开发，我们能够重构的架构也很有限；因此系统本身的日志埋点对我们快速定位和解决问题有很大的帮助。
在工作中我曾经提出第一现场原则，这个原则指的是复现问题的可见即可达，可达即第一责任人。无论是我们的质量工程师，或者beta用户，当发现问题时，问题现场的所见场景owner即第一责任人，听起来这个有点绝对，但是在日常工作中能减少80%的问题流转成本。当第一责任人确认非领域问题，或各个领域共性的问题，才会一步步流转到系统领域进行拆解和分析；无论是第一责任人还是问题流转经手的各个owner，不一定能能够从现象上确定问题根因，即便是能穿透问题，但要以理服人还是需要进一步的论证。那么每个问题的定位都需要数据的支撑，也就是完整的分析证据链，这个证据链就是日志。
没有日志，寸步难行。
是不是有了日志就万事大吉了？
质量工程师最头疼的就是日志不完整（worksforme），因为极有可能一个问题面临多个owner，而每个owner对分析问题的日志需求不一定一致；还有就是偶现场景。
接下来我们聊下，在Q+LA的SOC智能座舱方案上，系统稳定性问题的分析都需要哪些日志？
| 连接端口 |