记一次adb查找安卓App崩溃报错记录
首先先说结论,是因为内存不足的时候会出现这种问题
在小米手机上有这么一个设置
可以很方面的模拟出这个异常
然后我们再设置一下logcat日志的大小
如果你的操作真的很多,最好设置一下,如果你的操作很短就可以复现,那就没必要调整,256k足矣
然后就是手机连接电脑
然后打开命令行工具清空logcat日志
adb logcat -c
然后查看日志
#需要打印时间和级别是Error的信息
adb logcat -v time *:E
这里只是在cmd上打印日志,很快,你可能来不及,那就下载日志,不是已经清理了之前的日志么,我们再执行命令
adb logcat -v time >C:/Users/EDY/Desktop/work/logcat.txt
这个时候就会把logcat日志传输到本地,但是注意,等你操作完了,就可以关闭adb窗口了,要不然他会一直往windows本地的文件里写入日志,关闭后就不写入了
然后搜索“FATAL”关键字
就可以定位到错误信息了,至于真正的错误原因,就得让开发看了
如果你遇到了ANR
那还得看trace日志
以小米手机为例子
可能遇到两个问题
一个是大家都说adb pull /data/anr/traces.txt
但是自己去pull的时候报错
那是因为不同的手机厂商他的文件命名可能不同
但是我们也不清楚哪个是我们要的文件,那我们就尝试先pull一个,发现了第二个问题,权限不足,那就可以使用
adb bugreport
他会告诉你把文件放到哪里了
然后解压,再解压后的文件里就有anr目录下所有的东西了
怎么确定哪个文件是我们需要的,我们可以根据日志的时间来看,看哪个是你操作的时间附近
打开之后,看看是不是你的包报的错误
怎么确定报错信息在哪里
下面的内容是我抄的
首先,我们可以根据发生ANR的app包名和时间能确定ANR日志的地方,通常是再traces内容的最上面。
然后ANR必然是主线程异常,我们可以找到"main"线程部分,查看main线程相关状态。
可以很明确的看到主线程sleeping了,通常在多线程开发中,比较容易遇到的是blocked状态导致的ANR
其次我们可以继续找到下面的线程调用栈信息
这块我们就比较熟悉,和查看普通的异常一样,可以很明确的知道ANR 发生在MainActivity 28行处,原因是Thread.sleep(),此时我们再回到上面自己的代码层面,结果已经很明确。
当然,实际开发中的ANR通常不会这么简单,有些也没那么容易分析,这个就需要大家通过此篇文章的借鉴,结合实际开发多分析,多优化来增长自己的能力。
线程状态
对于上述线程状态,相对于java线程状态,Linux细化了很多状态,这样更便于分析当前的状态。
java中的线程和操作系统内核中的线程并不是等价关系。他们之间存在着映射关系,对Android来说,java中的线程和内核的线程是一对一关系。
新解决方案
今天测试的时候学习到了开发老师的一招
adb logcat >> 本地路径
会将设备中的logcat日志全部导出到本地,相比bugreport,更轻量级一些