福建网站建设科技有限公司,食品包装设计的介绍,中国建设银行人力资源网站,做网页要钱吗简介#xff1a; 选择一款有超强捕获能力的专业产品#xff0c;对于开发者定位和修复稳定性问题至关重要。友盟U-APM SDK集成了UC 内核团队强大的技术及友盟超强的错误捕获能力#xff0c;通过数万次捕获实践中积累了丰富经验#xff0c;在产品、性能和研发能力上都极大保障… 简介 选择一款有超强捕获能力的专业产品对于开发者定位和修复稳定性问题至关重要。友盟U-APM SDK集成了UC 内核团队强大的技术及友盟超强的错误捕获能力通过数万次捕获实践中积累了丰富经验在产品、性能和研发能力上都极大保障了开发者定位和修复稳定性问题的超强效率。 1. ANR 产生原理
关于 ANR 的触发原因Android 官方开发者文档中 “What Triggers ANR?” 有介绍如下
Generally, the system displays an ANR if an application cannot respond to user input. For example, if an application blocks on some I/O operation (frequently a network access) on the UI thread so the system cant process incoming user input events. Or perhaps the app spends too much time building an elaborate in-memory structure or computing the next move in a game on the UI thread. Its always important to make sure these computations are efficient, but even the most efficient code still takes time to run......
即常见的有如下两种情况会产生 ANR
输入事件例如按键或屏幕轻触事件等在 5 秒内没有响应
BroadcastReceiver 在 10 秒内没有执行完成。
结合 Android 相关源码分析可知输入事件的 ANR 检测是基于输入事件本身驱动的系统要求在 App进程中处理完成每个输入事件后通知系统进程事件处理完毕以此判断 App是否无响应。
要产生 ANR至少得有两个输入事件场景如下
第一个输入事件产生系统将其发送给用户当前操作的 App
系统收到第二个事件发现当前距第一个输入事件发送时间超过 0.5s 仍未处理完毕则设置一个定时器5s 后触发
5s 之后若系统发现第一个输入事件仍然没有回应时则触发 ANR激活 App 中的 Signal Cather 线程生成 traces.txt然后弹出 ANR 对话框告知用户 App 无响应。
也就是说要产生 ANR第一个输入事件必需在 5.5s 以上没有被处理完成并反馈回系统并且要有第二个输入事件产生。如果没有第二个输入事件即便第一个输入事件执行了 60s 或更长时间也是不会产生 ANR 的。
2. ANR 日志生成原理
系统的 system_server 进程在检测到 App 出现 ANR 后会向出现 ANR 的进程发送 SIGQUIT (signal 3) 信号。正常情况下系统的 libart.so 会收到该信号并调用 Java 虚拟机的 dump 方法生成 traces。
以友盟的 U-APM 应用性能监控平台为例集成SDK 后SDK 会拦截 SIGQUIT。在出现 ANR 时libcrashsdk.so 会优先收到信号并生成 traces 和 ANR 日志。在 SDK 处理完信号后会将信号继续传递给系统的 libart.so让系统生成 ANR traces.txt。
如下图红色线为 U-APM SDK 处理 ANR 信号和生成 ANR 日志的流程紫色线为系统生成 ANR traces.txt 的流程。 U-APM SDK ANR 捕获原理
其中SDK 生成 traces 时使用的是 libart.so 中的 dump 方法生成的内容与系统原生的基本一致。并且U-APM SDK 在调用 dump 方法时进行了优化dump 速度较系统生成原生 traces 的速度显著提升有效地避免了可能因生成 traces 时间过长而被 system_server 使用 SIGKILL (signal 9) 再次强杀。
在获取所有线程的 traces 信息后生成完整的 ANR 日志还会提供获取触发 ANR 的原因、手机中 TOP 进程 CPU 使用率、ANR 进程中 TOP 线程 CPU 使用率、CPU 各核心处理时间分布情况、磁盘 IO 操作等待时长等重要信息。
目前SDK 生成的 ANR 日志信息基本包含系统生成的 ANR 日志的所有内容甚至还包含一些系统日志中没有的内容以及 App增加的自身的业务相关信息对分析、定位和解决 ANR 问题提供了更加强有力的支撑。
3、日志分析
如开发者接入了SDKANR 日志将自动启用出现 ANR 时会先于系统生成 ANR 日志。日志的主要内容介绍如下
1. ANR 日志结构
使用日志分析插件我们可以清晰地看到 生成的 ANR 日志包含的内容以及重点信息如下 ANR 日志结构
除了生成的日志以 Section 分为多个部分其中包含重要信息的 Section 会使用红色标出特别重要的信息还会加粗。另外每个 Section 有快捷键可直接跳转到相应位置。
2. ANR 概要
概要信息如下 ANR 概要信息
这部分内容主要从系统获取其包含了 ANR 的进程名、ANR 产生的时间、ANR 的原因、ANR 前后几秒内系统 TOP 进程的 CPU 使用率等。其中通过 ANR 原因可以得知是输入事件处理超时还是 BroadcastReceiver 等其它消息处理时间过长通过 CPU 使用率则可以得知是哪个进程占用 CPU 资源过多。
3. 系统资源使用情况
可记录在出现 ANR 前一段时间内CPU 平均使用率、CPU 各核心使用率及其耗时分布ANR 进程中 TOP 线程的执行耗时及比例、出现页错误的次数磁盘 IO 操作等待时长及次数等内容。如下 系统资源使用情况 当 IO 繁忙导致 ANR 时io wait time 和 CPU 时间分布中的 iowait 比例会比较突出通过 CPU 时间分布中的 user 和 system 占比则可以知道是用户态代码执行耗时过长还是 Linux 内核的系统调用耗时太久。4. ANR traces traces 信息是 ANR 日志中最关键的内容。如U-APM生成的 traces 信息包含了出现 ANR 时主线程的 native 调用栈和所有线程的 java 调用栈。通常死锁问题通过调用栈中的信息可以很容易发现。 ANR traces
U-APM SDK 的 traces 由 fork 的子进程生成不会因 Java 虚拟机出现 BUG 导致生成 traces 时又出现 native 崩溃也不会因 dump 时卡死阻塞整个 ANR 日志的生成。
5. Logcat
以U-APM为例会在 ANR 时抓取 Android logcat。APM SDK 能绕开部分 ROM 增加的权限控制拿到当前 App ANR 前相关的 log 信息。当前进程以及当前错误线程输出的 log 会被重点标出error 和 warning 也会以显目的颜色标出。 logcat
6. 内存等其它信息
通过ANR日志可以分析出一系列的内存信息如
系统的 RAM 总内存、剩余可用内存
当前进程占用的虚拟内存、物理内存
Java 占用的总内存和可用内存
Native 占用的内存和可用内存等。
另外ANR 日志同 Java 和 Native 崩溃日志一样支持业务自定义日志内容扩展如
崩溃前增加简短的自定义头信息
崩溃前注册外部文件崩溃时其内容将被带入日志
崩溃前缓存业务相关的最近若干条操作或信息
崩溃时通过回调返回业务最新内容等。
4、ANR监控工具
选择一款有超强捕获能力的专业产品对于开发者定位和修复稳定性问题至关重要。友盟U-APM SDK集成了UC 内核团队强大的技术及友盟超强的错误捕获能力通过数万次捕获实践中积累了丰富经验在产品、性能和研发能力上都极大保障了开发者定位和修复稳定性问题的超强效率。
作者友盟全域数据
原文链接
本文为阿里云原创内容未经允许不得转载
