Android平台日志收集系统
在产品开发测试中以及产品投放到终端客户后，我们经常会遇到各种各样的问题，产品出异常，比较严重的就是使用过程中死机，用户无法操作。对于这种情况，将问题反馈给研发，问题能够快速重现的研发还比较好解决，有些问题不常见，研发短时间内也很难找到问题根源。为了提高研发的效率，那么每次出异常的时候我们都最好有系统的打印系统，通过系统打印异常的蛛丝马迹去查找问题的元凶。但是有时出问题的时候，系统都已经死机或者无法操作了，也就不能通过操作去抓系统打印了，因此引入日志收集系统就变得很有必要。日志收集系统每次系统启动后后台自动运行，直至关机或系统崩溃，因此可以全程守护监控系统打印，对产品的快速稳定有着非常重要的意义。
日志，在Android系统中我们需要抓取的主要有两部分，一部分是驱动内核
打印出来的，一部分就是android部分打印出来的。
驱动内核打印的信息查看方法：cat /proc/kmsg
Android部分打印信息查看方法：logcat -v time
日志系统运行逻辑
1、日志系统需要自动运行，无需人工干预；
2、如果用户通过系统持续抓取打印信息功能，需视日志系统是否已经启动，如果日志系统已经启动，那么可以提示用户日志系统已经启动；如果未启动，那么可以手动启动系统持续抓取系统打印功能；
3、什么时候自动启动日志系统？
从实际使用情况来说可以分一下几种情况：
A、 如果用户已经手动启动了持续抓取系统打印信息功能，此次开机无需再启动日志系统；
B、 卫星未定位，在收到系统BOOT_COMPLETED消息后30秒，启动日志收集系统。
4、日志系统空间大小限制；
鉴于每次系统启动后的正常打印，按照每次开机后运行的打印信息在3MB左右，按照平均每天用户开关机5次的使用频率，那么正常情况下一天就需要15MB空间，按照运行7天的收集限制，把存放日志系统文件的目录大小限制为100MB，在每次启动日志系统前，判断该目录是否已经达到100M，如果已经达到，那么可以启动删除程序删除日期最早存入的日志文件，一次删除达到30MB为宜，周而复始，循环操作，日志系统文件存储在系统内部，也就是/sdcard目录下，目录定在/sdcard/savelog。
当savelog目录文件大小超过100MB的情况下，我们需要判断一下里面是否有异常文件，在此暂且认为单次存入文件大小超过20MB的打印信息文件为系统异常的主要参考；那么怎么处理呢？按以下步骤处理：
第一步、压缩该异常文件，可以使用tar工具，压缩后的包可以存放到/sdcard/tarlog目录，该目录最多存6份异常信息，达到6份时，一次性删除前三次异常；
第二步、异常信息的压缩包通过网络传回服务器；这里分两种情况，一种在不带4G模块的机器，将通过用户在打开车智享的时候，通过车智享的程序与机器日志系统通讯判断是否有异常信息需要上报，如果有，一次最多从异常信息目录传递3个压缩包，然后车智享程序判断用户网络环境为WIFI的情况下，跟服务器通讯，把异常信息压缩包传递到服务器。另外一种就是带4G通讯模块的，那么就无需车智享中转，直接从机器端上传到服务器。
第三步、服务器开发维护人员将收集到的异常信息包拷贝出来给研发工程师分析。
5、人工参与提取系统日志系统打印：
由于日志系统是存储在系统内部存储里面，因此我们在使用的时候需要把需要的日志文件拷贝到DVR卡，再反馈到研发。
开发、测试人员：可以直接通过文件管理器去到/sdcard/savelog目录去拷贝需要的日志文件到DVR卡或者U盘，这个比较便利，平时使用较多，相关人员稍作培训即可。
但是对于终端客户：可能不知道怎么找对应的日志文件，因此我们需要傻瓜式一点。初步方案云服务程序里增加【用户体验反馈】按钮，点击该按钮后弹出让用户选择异常出现的大概时间段，是一个相对模糊一点的，可供选择的时间将是最1天、最近3天、最近5天，那么系统将会把对应时段收集到的系统打印信息打成压缩包后通过云服务上传到服务器，然后再把压缩包提交给研发工程师分析，该压缩包名称：电子条码+系统版本号组成，跟进电子条码可以找到对应终端用户，必要的时候可以电话沟通获取更详细的使用场景，系统版本号可以直观的帮助我们定位软件发布的时段，对跟进解决问题都有很大的帮助。
6、当文件序列号达到9999时，全部删除保存的log，重新从0000开始计数。假如一套开机十次，序列号运行到9999需要1000天。
一套有效的后台log系统对研发的帮助还是蛮大的，在嵌入式产品中也要尽量支持这种功能，可以加快研发进度，提高研发质量。