蜂信物联FastBee平台https://gitee.com/beecue/fastbee
阿里资料开源项目https://gitee.com/vip204888
百度低代码前端框架https://gitee.com/baidu/amis
OpenHarmony开源项目https://gitcode.com/openharmony
仓颉编程语言开放项目https://gitcode.com/Cangjie
2.4 具体分析
分析CPU usage以后，如若还是无法找出问题原因，则需要进一步分析trace文件。traces文件中详细记录了发生ANR前后该进程的各个线程的Stack，一般从主线程的stack入手分析，查看分析ANR问题发生前，应用是否有异常。
其中不同场景下的ANR问题情况不大相同，需要具体情况具体分析，此处就不展开详细描述。
3、ANR问题难点及破题思路
3.1 ANR难点
用户在应用内的绝大部分操作，比如按钮点击，加载资源，页面跳转等操作，都需要有App的主动反馈，但ANR发生时，在用户等待数秒后，仅会弹出一个“应用无响应”的弹窗给用户，这会给用户带来“应用难用”的感觉，极其影响用户体验。
但是，现网中的ANR问题又很难处理，问题包括但不限于：
平时的测试难以覆盖，毕竟ANR经常出现在老设备、弱网络环境的场景下，测试难以做到全场景覆盖。
对于现网应用的ANR问题，如果问题非必现，则定位难度较高，需要有可以复现问题的实际设备在身边，才能获取到具体日志trace等信息。
ANR问题定位复杂，影响因素多，一些新负责定位ANR问题的同学，上手困难，问题解决比较依赖经验。
3.2 ANR处理新方案
除了依赖现有传统的ANR问题定位经验，配合第三方应用监控平台、进行ANR问题的处理，也是方便快捷的ANR处理手段。
提升用户体验迫在眉睫，但ANR问题对用户体验影响大， 定位解决ANR问题老大难，针对这个需求痛点，越来愈多的第三方开始研究并对外提供应用性能监控工具。
**性能管理（App Performance Management，简称APM）**是华为AppGallery Connect质量系列服务中的其中一项，提供分钟级应用性能监控能力，其ANR分析功能，更是解决ANR问题定位与处理的最佳搭档。使用AGC性能管理服务监控应用ANR，能够为您带来以下好处：
1.实时监控现网应用ANR，现网应用ANR趋势全掌握。
2.ANR现场信息自动采集和展示，大部分情况无需复现，在线定位问题。
3.通过APM页面，定位思路系统化，快速上手ANR问题定位，及时解决问题。
4、ANR问题解决案例整理
接下来以华为AGC性能管理服务为例，介绍配合AGC性能管理服务，如何快速定位典型的ANR问题。
4.1 案例（一）：死锁导致的ANR问题定位
4.1.1 发现问题 在华为AGC控制台的我的项目-质量-性能管理页面，在“ANR分析”页签下，发现排在第一位的“用户ANR率”高达16.67%，决定优先解决该类ANR问题。
4.1.2 定位问题 点开TOP排行榜中该类问题卡片，进入了该类“ANR问题详情”页面，进一步查看分析该ANR 问题的数据报告。
在这个“ANR问题详情”页面中，分析用户数分布饼图，发现该类ANR问题在“应用版本2.0”、“手机型号HUAWEI VOG-AL10”、“系统版本10”这三个条件下，ANR影响的用户数最多。
在报告下方的“发生记录”中，找到满足这三个条件的发生记录，点击“查看详情”准备针对具体的问题进行分析。
(1) 分析系统资源状态 首先，通过报告，发现该问题发生时，CPU占用是20%、IO占用是0%、未发生过低内存、应用被分配堆是26.50MB、应用已用堆是8.69MB，线程数是61，从系统资源来看，未出现明显的异常，如下图所示：
因为ANR问题原因可以分为两大类，一是系统资源不足导致，二是自身代码逻辑导致，综合以上系统资源信息，该ANR问题不是由于系统资源不足导致，那么分析该ANR问题思路转变为：该ANR问题由自身代码逻辑导致，接下来，我们顺着该思路分析这次的ANR问题。 (2) 查看主线程状态：发现ANR代码片段 自身代码逻辑导致ANR问题，其主要分析思路是查看主线程堆栈及线程状态，我们在性能管理页面上“主线程堆栈”页签中能够找到问题堆栈，发现该问题发生时，主线程处于获取锁状态，到此我们能够得出结论：该ANR问题是因为主线程一直在等待锁资源，而被阻塞，导致了后续输入事件未被响应，从而触发了应用的“Input dispatching timed out”类型的ANR。
查看具体的堆栈信息，我们找到了ANR问题代码片段，发现死锁是发生在“com.aiops.hiperformance.MainActivity.dispatchActivityDestroyed”调用中。查看代码发现，死锁发生在“mLock.readLock().lock()”函数中。
通过在代码中搜索mLock加锁代码的调用，发现了仅在MainActivity文件中，才会存在“mLock.readLock.lock()”代码， 由此判断，异常代码仅存在于MainActivity中，因此我们缩小了问题代码范围。 在正在的代码编写过程中，锁的申请与释放已经成为一种编码习惯，如果锁未释放，可能是在释放锁之前，出现了某种我们编码未考虑的异常，导致锁未释放或释放失败。 由此分析，我们接下来尝试使用“找到ANR问题发生之前，应用是否有异常发生”的思路，继续分析。
我们先找到申请锁动作开始时间点，由阻塞动作开始时间点往前分析，寻找异常信息。我们切换到“ANR信息”页签， 发现主执行队列首元素在5.5s前已经存在，ANR发生时间是“2020-09-27 09:48:27”, 因此我们可计算出获取锁动作大概是在“2020-09-27 09:48:21”发生。
(3) 查看应用日志 接下来，我们把页签切到“系统日志”中，我们目前知道锁获取动作在“2020-09-27 09:48:21”左右发生。我们接下来仅需要在日志中，从该时间点往前分析，看是否由相关异常，是导致该锁未被释放的关键因素。
我们发现在“09:48:18.365”时系统抛出了“OutofBoundsException”异常，并且打印了异常堆栈，我们发现，该异常就出现在MainActivity，也就是我们之前的问题代码范围中，我们通过该堆栈，找到了异常代码。
发现在“getShareDataInterceptor”调用时，抛出了“越界异常”，导致了“mLock.readLock”未被释放，由此我们已经知道导致该ANR问题的具体原因：异常场景导致锁资源未被释放，从而造成了主线程出现死锁。
4.1.3 解决问题 为了修复了该问题，我们做了以下措施，解决该问题的同时，预防同类问题发生：
分析异常具体原因并修改代码，防止越界异常再次出现。
捕获该异常，保护代码在资源释放前被异常抛出。
排查其他代码，在资源释放前，加上保护，保证资源及时释放。
4.2 案例（二）：IO资源不足导致ANR问题定位
4.2.1 定位问题 直奔问题核心，直接进入“单次ANR问题” 页面，去分析问题，强化我们借助性能管理服务定位ANR问题思路。
(1)分析系统资源状态. 首先，通过报告，发现该问题发生时，CPU占用是100%、IO占用是84%、未发生过低内存、应用被分配堆是26.50MB、应用已用堆是8.69MB，从系统资源来看，CPU占用和IO占用出现明显异常，如下图所示：
由定位大部分ANR问题经验可知，该ANR问题是由于系统资源不足导致，那么分析该ANR问题思路为：找到自身应用程序ANR代码片段，分析否能够优化代码，在高IO情况下，不触发ANR。
(2)查看主线程状态：发现问题原因 我们切换到“主线程堆栈”页签，观察主线程代码。
通过观察主线程堆栈，我们发现了一个存在问题的地方，主线程里面直接在做数据库操作，在系统IO高的情况，此操作必定会导致主线程被阻塞。我们通过堆栈找到对应的代码。
由此我们确认，在代码中存在访问SQLite的操作。这时候有经验的开发者已经知道，问题能够通过优化解决，仅需要将该IO操作放在线程中执行即可。
(3) 查看应用日志 已经在上一环节分析出ANR原因，无需此步骤。
4.2.2 解决问题 我们做了以下措施，优化了该问题代码，预防ANR问题发生。
4.3 案例（三）：主线程死循环导致ANR问题定位 4.3.1 定位问题 话不多说，直接到“单次ANR问题”，固化问题定位思路。
(1)首先，通过报告，发现该问题发生时，CPU占用是25%、IO占用是0%、未发生过低内存、应用被分配堆是18.01MB、应用已用堆是8.08MB，线程数是43，从系统资源来看，均未出现明显异常，如下图所示：
由定位大部分ANR问题经验可知，该ANR问题大概率不是由于系统资源不足导致，那么分析该ANR问题思路转变为：该ANR问题由自身代码逻辑导致，接下来，我们顺着该思路分析这次的ANR问题。
(2)查看主线程状态：发现问题原因 自身代码逻辑导致ANR问题，其主要分析思路是查看主线程堆栈及线程状态，我们在性能管理页面上“主线程堆栈”页签中能够找到问题堆栈。
发现该问题发生时，发现主线程堆栈在getActivity中被阻塞，主线程处于“SUSPENDED”状态。这时我们通过堆栈，找到问题代码。
通过代码分析，怀疑主线程在该处出现死循环。我们知道如果应用程序出现死循环会导致应用程序的CPU用户态时间占用异常升高，我们知道“ANR信息”页签中记录了ANR发生时的各进程的CPU占用信息，于是我们在页面上切换到“ANR信息”页签。
我们在“ANR信息”页签中发现，自身应用程序CPU用户态的资源占用达到了94%，因此验证了我们之前的猜想：主线程出现了死循环，导致了ANR问题。
(3)查看应用日志 已经在上一环节分析出ANR原因，无需此步骤。
4.3.2 解决问题 我们做了以下措施，优化了该问题代码，预防ANR问题发生。
5、案例总结
以上ANR问题的解决与处理，都是配合华为AppGallery Connect性能管理管理服务完成的，其中的ANR问题分析报告，ANR问题发生时的问题记录，都由AGC性能管理服务界面所提供。
通过AGC性能服务里的 ANR分析详情 可以查看发生某类ANR问题时的趋势及分布信息，其中包括按应用版本版本分布，按手机型号分布，按系统版本分布和问题发生的实时走势。帮助分析这一类ANR问题对用户的影响趋势，以及问题复现条件。
另外开发者可以通过详细的问题发生记录，获取到该问题发生时更加详细的设备信息，系统信息，应用信息和堆栈日志，帮助开发者快速定位该问题。
6、相关链接
AGC性能管理服务的超简单集成，可以参考该文章：developer.huawei.com/consumer/cn…AGC性能管理服务官方文档，可参考：developer.huawei.com/consumer/cn…
如何做好面试突击，规划学习方向？
面试题集可以帮助你查漏补缺，有方向有针对性的学习，为之后进大厂做准备。但是如果你仅仅是看一遍，而不去学习和深究。那么这份面试题对你的帮助会很有限。最终还是要靠资深技术水平说话。
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。建议先制定学习计划，根据学习计划把知识点关联起来，形成一个系统化的知识体系。
学习方向很容易规划，但是如果只通过碎片化的学习，对自己的提升是很慢的。
我搜集整理过这几年字节跳动，以及腾讯，阿里，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。
在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多。
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
相关文章
赣公网安备36020002000448号