在程序调试的过程中，第一要务是定位问题。只要问题找到，解决起来就比较容易了。
程序日志在定位问题的过程中起到了关键的作用，因此有必要构建自己的日志系统。
Android 日志系统需求
Android系统自身提供了Log类，可以打印简单的日志，但是只能在调试程序的时候才能看到，如果没有连接电脑，或者手机根本不在身边，这个时候应用出现问题想要依靠日志来定位问题就行不通了。
上述两个场景可以通过手机本地保存日志信息，以及上传日志信息到服务器解决。很自然的就引出Android日志系统的主要需求：
- 日志的本地留存
- 日志本机展示
- 日志上传
日志系统实现
日志的本地留存
日志的本地留存主要解决收集方式、缓存策略。收集方式主要是指本地留存的日志以什么形式存储，可能是文件、SP或者数据库。缓存策略主要是确定日志的留存大小限制以及时效性的问题，即需要留存日志的大小，以及留存什么指定时间范围内的日志。
日志数据会因为使用的不同，产生不同的日志数据，大小和格式也可能不确定，同时大小也有很大的随机性。由于这些原因，我们觉得采用本地文件保存日志是比较可取的方式，操作起来简单明了同时也能很好的适应我们的需求。为了方便管理，推荐将在应用文件根目录下创建一个log文件夹用于保存日志数据。一个简单的想法，日志的保存可以按天划分，每天的日志数据全部保存在同一个文件中，最好直接拿时间戳（精确到天即可）作为文件名，这样在后续管理文件的时候比较方便。
日志文件也不用一直保留下去，这样会造成存储空间的浪费，因此需要有个定期删除的策略。删除策略需要保证本地留存的日志大小控制在合理的范围内。但是应用单日生成的日志随机性很大，如果仅仅设定总的空间上限，有可能一天的日志就直接超过上限，这样所保存的日志仅仅是一天的。最终我们认为在限制日志留存时间的基础上，在单独限制单日日志的上限，单日日志超过上限之后将今日最早生成的日志删除，这样保证全部日志所占空间可控。
日志本机展示
日志本机展示仅仅作为调试人员在使用的过程中自行查看日志来寻找问题的情况下，主要保证信息能够清晰明了的展示出来即可，可以对日志进行编号这样方便查看。如果不是以文件形式查看，而是在应用内设定相应的展示界面的话，还可以根据信息的不同进行 简单的着色处理，例如：错误信息标红等。
日志上传
日志上传的主要目的是将远程的应用的日志上传到后台，这样可以通过查看上传的日志来帮助定位远程应用出现的问题。上传需要重点考虑两个问题：上传时机和日志上传方式。
- 上传时机，需要确定什么时候需要上传本地日志，首先想到的就是程序崩溃的时候最好能够拿到最近的运行日志。程序出现问题的时候，用户想要反馈问题，这个时候如果能够同时将最近的运行日志一并上传肯定会对我们解决问题有较大的帮助。
- 上传方式，日志上传可以直接通过应用的接口上传到服务器后台，也可以引导用户通过邮件的方式进行上传。同时如果应用使用了Fabric监控工具，那么可以利用Fabric自带的日志上传接口，需要注意的事Fabric的日志最多只能保存64K。
