将所有耗时操作,比如访问网络,Socket通信,查询大量sql 语句,复杂逻辑计算等都放在子线程中去,然后通过handler.sendMessage、runonUIThread、AsyncTask、RxJava等方式更新UI。
五、发生了ANR的情况,如何解决:
如果在已经尽量避免的情况下,还是发生了ANR的情况,我们可以根据以下的步骤进行问题定位与分析:
1.问题分析
-
导出ANR日志信息,根据日志信息,判断确认发生ANR的包名类名,进程号,发生时间,导致ANR原因类型等。
-
关注系统资源信息,包括ANR发生前后的CPU,内存,IO等系统资源的使用情况。
-
查看主线程状态,关注主线程是否存在耗时、死锁、等锁等问题,判断该ANR是App导致还是系统导致的。
-
结合应用日志,代码或源码等,分析ANR问题发生前,应用是否有异常,其中具体问题具体分析。
2.导出ANR日志
NR问题发生时,系统会收集ANR相关的日志信息,CPU使用情况,trace日志也就是各线程执行情况等信息,生成一个traces.txt的文件并且放在**/data/anr/**路径下。
注意:每一次新的ANR问题的发生,会把之前的ANR信息覆盖掉。
我们可以通过adb命令将traces文件导出到本地。
adb root
adb shell ls /data/anr
adb pull /data/anr/
- 读取关键日志信息
- 在log中找到ANR发生信息:
Traces文件中的关键字,例如:
09-24 15:20:20.211 1001 1543 1570 XXXXXXX: ANR in xxxxxx 09-24 15:20:20.211 1001 1543 1570 XXXXXXX: PID: xxxxx 09-24 15:20:20.211 1001 1543 1570 XXXXXXX: Reason: xxxxxx
其中:
- ANR in中,包括导致ANR的包名,类名
- PID 中,为发生ANR的进程PID
- Reason 中,为导致ANR的原因,例如:keyDispatchingTimedOut
- 找到CPU Usage信息
09-24 15:20:20.211 1001 1543 1570 XXXXXX: CPUusage from xxx to xxx ago xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 09-24 15:20:20.211 1001 1543 1570 XXXXXX: CPUusage from xxx to xxx later xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
其中:
- ago表示ANR发生前的CPU的使用情况
- later表示ANR发生后的CPU的使用情况
- 重点关注xxx%TOTAL: xxx% user + xxx% kernel + xxx% iowait,可通过这几项了解到CPU的占用情况。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级安卓工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Android)
加下面V无偿领取!(备注Android)**
[外链图片转存中…(img-6ktRXjrk-1710914179477)]