Android开发中如何解决典型场景缺通用日志的问题

下面针对一些典型场景缺通用日志（android/kernel）的问题，一一列举如下，希望可以让大家关注到缺日志的真实原因。如下问题也提醒各位工程师：谨慎添加日志，不要随意添加，否则即容易造成自己的日志缺失也会导致其他业务模块丢失日志。

通用日志丢失目前有如下情况会出现：

（1）liblog通过socket传输日志时失败，此时在event日志中会记录类似上图中tag=liblog的埋点。具体见4.1、4.2节内容。

（2）其它进程通过socket读取logd的日志时，此时由于日志打印速度过快，读取速度跟不上写入速度，造成了部分历史日志被丢弃的情况，此时在event日志中会记录tag=chatty的埋点。此种情况遇到较少。

（3） logd buffer中日志内存超过buffer大小了，则会按照每次裁剪日志的行数等于日志总行数的10%，并且会大于等于4行，小于256行。环形buffer大小超过了，会不断循环裁剪。

（4） 文件存储问题，导致日志内容无法落盘至日志文件。具体见4.3节内容。

（5） 低内存查杀日志进程，导致日志内容无法落盘。具体见4.4节内容。

日志丢失的问题可能不止以上原因，基本分析思路是首先了解问题发生场景及时间点，然后通过日志抓取和落盘场景进行分析，参考业务日志打印频率、logd的状态（logd的cpu负载、运行状态）、系统的异常状态（严重低内存、整机CPU负载高、文件系统异常、温度过高限频限核）等综合原因，得出问题分析结论。往往日志缺失和系统状态联系较为紧密，所以分析此类问题，就要具备开阔的视野，能够及时联想到有关整机各个状态，推测和佐证自己的分析原因和得出的结论。具体分析过程，也可以参考思维导图。

下面针对以上内容，列举如下几个典型案例，仅供大家参考。

4.1 业务日志输出频率太高

（1） events日志出现大量丢弃日志打印

（2） 查看android日志，发现sensor日志打印量非常大，基本达到刷屏的程度

（3） android日志输出频率达4229条/秒，日志输出频率非常大，sensor日志打印处于top1，达到2418条/s。

总结：sensor日志打印频率太高，超过了socket的处理能力，不能及时处理只能先行丢掉。故导致部分日志丢失。

4.2 整机负载高

（1） 输出的日志出现大量的日志丢失内容

（2） 查看日志打印频率，发现日志输出频率较低

（3） 查看systrace发现整机负载高达90%以上，logd一直处于runanble状态，整机温度也较高导致触发了限频限核。

总结：logd一直处于runnable状态，导致logd无法获得cpu时间片执行日志操作，容易出现socket通信失败，故导致部分日志丢失。

4.3 存储异常导致

（1） 查看日志发现mmap异常

（2） 由于没有过多日志打印，故本地使用adb logcat抓取日志分析

总结：文件存储出现问题，日志无法输出到对应的文件中，日志信息无法得到落盘，故出现日志内容大量丢失。

4.4 低内存导致

（1） 日志文件为空

（2） kernel日志中发现打印日志进程被杀

（3） 查看内存，已经处于低内存状态

总结：低内存导致日志进程被杀，出现日志文件无对应的日志信息落盘，故出现日志内容丢失。