ANR分析及解决方案
首先，什么是ANR？
ANR(Application Not responding)：是指应用程序未响应，Android系统对于一些事件需要在一定的时间范围内完成，如果超过预定时间仍未能得到有效响应或者响应时间过长，都会造成ANR。
在 Android 里，应用程序的响应性是由 ActivityManager 和 WindowManager 系统服务监视的。当它监测到以下情况中的一个时，Android 就会针对特定的应用程序显示 ANR。
那么，为什么会发生ANR？
- 主线程被 IO 操作（从 4.0 之后网络 IO 不允许在主线程中）阻塞；
- 主线程中存在耗时的计算；
- 主线程中错误的操作，比如 Thread.wait 或者 Thread.sleep 等等…
哪些场景会造成ANR？
- Service Timeout：比如前台服务在20s内未执行完成；
- BroadcastQueue Timeout：比如前台广播在10s内未执行完成；
- ContentProvider Timeout：内容提供者,在publish过超时10s；
- InputDispatching Timeout：输入事件分发超时5s，包括按键和触摸事件等等…
ANR触发机制
- service超时机制：超过一定时间没有执行完相应操作来触发移除延时消息，则会触发anr;
- BroadcastReceiver超时机制：有序广播的总执行时间超过 2* receiver个数 * timeout时长，则会触发anr；有序广播的某一个receiver执行过程超过 timeout时长，则会触发anr；
- input超时机制：input的超时机制并非时间到了就会触发anr，而是处理后续上报事件的过程才会去检测是否触发anr；
- provider超时机制：provider的超时是在provider进程首次启动的时候才会检测，当provider进程已启动的场景，再次请求provider并不会触发provider超时；
如何避免ANR？
- 避免在主线程执行耗时操作
- 使用异步处理：对于网络请求、数据库操作、复杂计算、大文件读写等耗时操作，应该在子线程或使用异步任务（如AsyncTask，尽管官方已不推荐使用，建议使用Thread、HandlerThread、ExecutorService或Kotlin Coroutines等）中执行，避免在主线程中进行耗时操作，从而避免主线程被阻塞；
- 使用LiveData、Flow（Kotlin）或RxJava这些库在主线程安全地处理异步数据更新；
- 优化UI更新和绘制
- 减少布局层次：简化布局，减少嵌套，提高渲染效率；
- 使用ViewHolder模式：在列表滚动等场景中，利用ViewHolder减少视图的重复创建；
- 避免过度绘制：减少视图重叠，使用工具检测并优化；
- 使用Handler和Looper：在需要进行UI更新的时候，确保在UI线程中进行，可以使用Handler或者Looper来进行UI更新；
- 响应系统事件及时
- BroadcastReceiver、Service：在BroadcastReceiver的onReceive()方法或Service的回调中尽快完成操作，或者启动新线程处理耗时操作；
- ContentProvider：查询数据时尽量快速返回，复杂查询应异步处理；
- 监控和处理后台任务
- 使用JobScheduler或WorkManager：安排后台任务，特别是那些需要网络连接的任务，以避免在不适合执行时阻塞UI线程；
- 超时处理：对于所有异步操作，设定合理的超时机制，避免无限等待；
- 优化数据库查询
- 索引优化：对频繁查询的字段建立索引，加快查询速度；
- 分批查询：避免一次性查询大量数据，考虑分批次加载；
- 异步查询：在进行大量的数据库操作时，尽量避免在主线程中直接进行，可以考虑使用异步机制或者数据库事务来优化数据库操作
- 处理主线程阻塞
- 使用StrictMode进行性能监测：Android提供了StrictMode来检测应用的性能问题，可以通过StrictMode来发现一些可能引起ANR的问题；
- 监控主线程：使用Choreographer或第三方工具监控主线程的执行情况，及时发现阻塞源；
- 合理使用轮询和超时机制：在进行一些IO操作时要避免直接使用阻塞式方法，可以使用轮询或者设置超时时间来避免线程被阻塞；
- 适配硬件差异
- 考虑设备性能：针对低端设备优化应用，减少资源消耗，提高流畅度；
- 用户交互反馈
- 显示进度条或加载提示：在执行耗时操作时，给用户明确的视觉反馈，让用户知道应用正在工作而不是卡死。
总结：将所有耗时操作，比如访问网络，Socket 通信，查询大量 SQL 语句，复杂逻辑计算等都放在子线程中去，然后通过 handler.sendMessage、runonUIThread、 AsyncTask、RxJava 等方式更新 UI。无论如何都要确保用户界面的流畅度。如果耗时操作需要让用户等待，那么可以在界面上显示进度条。
发生ANR异常怎么处理?
- 收集ANR日志
- 查看设备日志：连接设备到电脑，使用adb logcat命令收集日志，重点关注带有ANR关键字的信息，它会包含ANR发生的时间、涉及的线程、堆栈跟踪等详细信息；
- 应用专有日志：如果应用内实现了Crash上报机制，检查是否有相关的ANR报告或日志记录；
- 分析ANR日志
- 识别阻塞线程：日志中会指出哪个线程发生了阻塞（通常是主线程），并提供该线程的堆栈跟踪；
- 分析堆栈跟踪：通过堆栈跟踪，确定导致阻塞的具体操作或函数调用。重点关注主线程中执行的耗时操作；
- 定位问题代码
- 根据堆栈信息，回到代码中定位到问题所在的具体位置；
- 检查该位置是否有网络请求、数据库操作、大量数据处理、UI布局复杂度过高、锁的竞争等问题；
- 优化代码
- 异步处理：将耗时操作移至子线程或使用异步任务执行；
- 优化操作：优化数据库查询、减少布局复杂度、使用轻量级数据结构等；
- 合理使用缓存：预加载或缓存数据，减少实时计算和加载时间；
- 数据库操作的优化：索引优化、分批查询、异步查询；
- 优化IO操作：在进行一些IO操作时，避免使用阻塞式方法，可以考虑使用轮询或者设置超时时间来避免线程被阻塞；
- 增加超时和错误处理
- 为网络请求、数据库操作等添加超时处理，防止无限等待；
- 实现重试机制和错误回调，提高应用的健壮性；
- 测试与监控
- 单元测试和压力测试：编写测试用例，模拟高负载情况，确保优化有效；
- 持续监控：集成ANR监控工具或服务，如Firebase Performance Monitoring，及时发现并解决新出现的ANR问题；
- 用户反馈
- 如果ANR发生在用户设备上，考虑提供一种机制让用户可以轻松反馈问题详情，这有助于快速定位问题；
- 避免未来ANR
- 遵循最佳实践：持续学习和应用Android开发的最佳实践，特别是关于线程管理和资源优化的指南；
- 代码审查：团队内部实施严格的代码审查流程，确保代码质量，避免引入可能导致ANR的代码；
- 使用StrictMode进行性能监测：Android提供了StrictMode来检测应用的性能问题，可以通过StrictMode来发现潜在的引起ANR的问题。
原文地址：https://blog.csdn.net/Mr_Gaojinchao/article/details/140676741
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！