Android中处理崩溃异常和分析日志的两种思路

最新推荐文章于 2024-07-03 16:40:03 发布

码农突围

最新推荐文章于 2024-07-03 16:40:03 发布

阅读量666

点赞数

本文链接：https://blog.csdn.net/hejjunlin/article/details/103771100

版权

前言：在Android开发app中，想要及时了解线上app的运行情况，须要采集样本日志，也就是常说的log,今天由“懂你行云”授权本公众号独家发布，分享他的《处理崩溃异常和分析日志的两种思路》，懂你行云的blog链接为：http://blog.csdn.net/zhangteng22。下方阅读原文可看他的原文。正文如下：

我们写程序的时候都希望能写出一个没有任何Bug的程序，期望在任何情况下都不会发生程序崩溃。不过理想是丰满的，现实是骨感的。没有一个程序员能保证自己写的程序绝对不会出现异常崩溃。特别是针对用户数达到几十万几百万的程序，当你用户数达到一定数量级后，就算你的程序出现个别异常崩溃情况也不用惊讶。此时及时收集用户的日志成了解决问题的关键。本文从两种方式分析查看日志的方式：

1、在自测阶段或者交给测试部测试阶段出现了：

1，程序异常退出， uncaused exception
2，程序强制关闭，Force Closed (简称FC)
3，程序无响应， Application No Response （简称ANR) ，顺便，一般主线程超过5秒么有处理就会ANR

将终端的/data/anr/traces.txt文件取出（命令如：adb pull /data/anr/traces.txt C:\）拿到日志文件打开后一看"哇"好长，但是不要害怕log日志虽长，但其实它由三大块儿组成：

1、系统基本信息，包括内存，CPU ，进程队列，虚拟内存，垃圾回收等信息。
Heap: 4% free, 66MB/69MB; 164920 objects
Dumping cumulative Gc timings
Total number of allocations 617049
Total bytes allocated 86MB
Free memory 3MB
Free memory until GC 3MB
Free memory until OOME 189MB
Total memory 69MB
Max memory 256MB
Total mutator paused time: 0
Total time waiting for GC to complete: 598.247us

2、时间信息，也是我们主要分析的信息。
----- pid 17845 at 2016-10-19 10:59:32 -----

3、虚拟机信息，包括进程的，线程的跟踪信息，这是用来跟踪进程和线程具体点的好地方。

----- pid 17845 at 2016-10-19 10:59:32 -----
Cmd line: com.XX.XX

从这么多大堆栈里如何分析出关键问题呢：

1，如果是ANR问题，则搜索“ANR”关键词。快速定位到关键事件信息。
2，如果是ForceClosed 和其它异常退出信息，则搜索"Fatal" 关键词，快速定位到关键事件信息。
3，定位到关键事件信息后，如果信息不够明确的，再去搜索应用程序包的虚拟机信息，查看具体的进程和线程跟踪的日志，来定位到代码

该方式适合能够及时拿到终端的情况下进行日志分析，那如果是用户的终端该如何及时分析bug日志呢，采用第二种方法如下

2、应用程序出现问题时采用HTTP的方式将日志及时上报到后台进行分析：

看了网上大部分是采用日志收集的第三方jar包来完成的，还有一种是自定义一个自己的CrashHandler实现UncaughtExceptionHandler接口来捕获闪退信息然后上传到自己的服务器。这样的实现方式总觉得如果用户误删了闪退的日志文件那么就会导致无法及时上报闪退日志，也就无从分析隐藏的Bug了，于是采用另一种实现思路，即：在程序发生异常时提醒用户发生了什么样的异常，同时把本次捕获的Exception的字段写入到自己定义的log文件中，然后上报异常字段到自己的异常服务器上，从手机端或者后台都可以看到发生的异常堆栈。日志记录系统不借助与任何第三方jar包。说干就干，

项目目录如下：