网站建设软件kan,邵阳网页制作,北京做网站推广,抖音网红代运营简介#xff1a; 我们不应该为了掩盖代码质量问题#xff0c;通过手动try catch去规避某些问题#xff0c;这样有可能会打断用户的正常使用#xff0c;并造成感知性的阻断反馈#xff0c;应该从用户使用APP时的真实感知出发#xff0c;当出现问题时及时捕获和处理问题。 … 简介 我们不应该为了掩盖代码质量问题通过手动try catch去规避某些问题这样有可能会打断用户的正常使用并造成感知性的阻断反馈应该从用户使用APP时的真实感知出发当出现问题时及时捕获和处理问题。 App的稳定性时一个长期不断迭代的过程在这个过程中U-APM是一个很好的提升效率降低成本的工具他提供了收集、解析、聚合、分析的能力下一期我们会从如何通过U-APM解决和处理崩溃、ANR等问题进行讲解尽情期待。 「崩溃」与「卡顿」、「异常退出」等一样是影响App稳定性常见的三种情况。相关数据显示当iOS的崩溃率超过0.8%Android的崩溃率超过0.4%的时候活跃用户有明显下降态势。它不仅会造成关键业务中断、用户留存率下降、品牌口碑变差等负面影响而且会直接带来卸载和流失。也同时给开发者带来不可小觑的资本损失。
那么崩溃率低的App质量就高么是否可以通过崩溃率直接判断App的稳定性
首先衡量一个App质量好坏时我们需要定义一个统一的口径即哪些指标可以作为稳定性的评估口径以友盟的U-APM定义的稳定率这个概念为例评价一个App的稳定性和质量一般从以下三点综合考虑
发生了崩溃如java崩溃和Native崩溃即用崩溃率这个指标来评估计算
发生了ANR即用ANR率这个指标来评估计算
异常退出如low memory killer、任务列表中划掉、系统异常、断电、用户触发关机/重启等即用异常率这个指标来评估计算。
崩溃也就是程序出现异常导致程序退出。包括
Java崩溃也就是在Java代码中出现了未捕获异常导致程序异常退出。如空指针异常、数组越界异常等。
Native异常也就是在Native代码中出现错误产生相应的signal信号导致程序异常退出。如访问非法地址、地址对其问题等。
Java崩溃的捕获相对会简单一些Native崩溃的捕获可能要求我们对系统底层知识要有一定的掌握。我们知道Android是基于Linux系统的系统中的崩溃大多是由于编码错误或硬件错误导致的。当系统遇到不可恢复的错误时会通过异常中断的方式触发异常处理流程这些中断的处理被统一为了信号量。当应用程序接收到某个信号量时会按照内核默认的动作处理如Term、lgn、Core、Stop、Cont。同时我们也可以通过sigaction注册接收信号来指定处理动作比如捕获崩溃信息等。当然捕获过程中也会有一些困难点尤其在极端环境中比如栈溢出时由于栈空间已经被用完造成我们的信号处理函数没法被调用以至于无法捕获到崩溃信息这时我们需要考虑使用signalstack使我们的信号处理函数可以在堆里面分配到一块内存空间作为“可替换信号栈”来处理崩溃信息。 当然除了稳定、安全的捕获能力外还需要丰富崩溃现场的上下文信息比如Logcat信息、调用栈信息、设备信息、环境信息等等为我们后续定位和解决问题提供全面的参考。
对于发生崩溃的情况我们使用崩溃率作为数据指标。包括
UV崩溃率也就是发生崩溃错误的去重用户/去重活跃总用户
PV崩溃率也就是发生崩溃错误的次数/启动次数
启动崩溃率也就是应用启动过程中发生的崩溃很容易被忽略但又非常重要的崩溃指标因为启动是APP生命周期中非常重要的一个阶段很多广告、闪屏、活动等内容都在这个过程中透出同时启动时又需要加载各种初始化并且如果启动出现错误往往热修复、降级融灾策略都无法弥补。
ANR也就是Application Not Responding当应用程序一段时间无法及时响应则会弹出ANR对话框让用户选择继续等待还是强制关闭。从用户体验的角度看有时候ANR可能要比崩溃会带来更糟糕的体验所以开发者重视崩溃的同时也要非常重视ANR。
ANR捕获的准确性一直是不断升级打怪、不断完善的过程。早期我们通过FileObserver 监听/data/anr/traces.txt文件的变化进行捕获和上报但很遗憾随着版本升级系统和厂商开始收紧系统文件但权限此方案的覆盖设备情况越来越低造成ANR捕获的准确性也一直降低。
随后我们改进为监控消息队列的运行时间的方式捕获ANR也就是向主线程Looper中放入一个空消息监听该空消息在5秒后是否被执行但该方案无法真实的捕获ANR情况存在漏报和误报情况并且也无法得到完整的ANR内容。后续我们参考Android ANR的实现原理实现了一套实时、准确的ANR捕获方案并且可以兼容所有系统版本。我们知道系统的system_server 进程在检测到 APP 出现 ANR 后会向出现ANR 的进程发送 SIGQUIT (signal 3) 信号。默认情况系统的 libart.so 会收到该信号并调用 Java 虚拟机的 dump 方法生成 traces。
我们通过拦截SIGQUT在出现ANR时优先接收到信号并生成traces和ANR日志在处理完信号后将信号继续传递给系统让系统生成traces文件生成traces文件时在保证内容与系统原生的一致性的同时还对生成traces文件的速度进行了明显的提升有效地避免了可能因生成 traces 时间过长而被 system_server 使用 SIGKILL (signal 9) 再次强杀同时我们对捕获到的内容进行了丰富包括触发 ANR 的原因、手机中 TOP 进程CPU 使用率、ANR 进程中 TOP 线程 CPU 使用率、CPU 各核心处理时间分布情况、磁盘 IO 操作等待时长等重要信息对分析、定位和解决 ANR 问题提供了更加强有力的支撑 同样对于发生ANR的情况我们也分为UV ANR率和PV ANR率算法可参考如上崩溃率的计算。
当然除了崩溃和ANR我们往往忽略了异常退出这种场景但往往通过异常退出我们可以发现如low memory killer、系统重启等无法正常捕获到的问题。比如兼容性问题导致的闪退、设备重启、三方库主动调用exit函数导致应用闪退次数增加等难以发现的问题所以通过异常退出率我们可以比较全面的了解和衡量应用的稳定性。
综上对于文章开始的那个问题我想大家都应该有答案了吧。当然我们不应该为了掩盖代码质量问题通过手动try catch去规避某些问题这样有可能会打断用户的正常使用并造成感知性的阻断反馈应该从用户使用APP时的真实感知出发当出现问题时及时捕获和处理问题。
App的稳定性时一个长期不断迭代的过程在这个过程中U-APM是一个很好的提升效率降低成本的工具他提供了收集、解析、聚合、分析的能力下一期我们会从如何通过U-APM解决和处理崩溃、ANR等问题进行讲解尽情期待。
作者友盟移动开发专家 张文
原文链接
本文为阿里云原创内容未经允许不得转载
