一文搞懂如何长期保持 APP 0.1%以下的崩溃率

2019-12-17 16:53:37 +08:00
 Riacya12

本文首发于 [ UC 研发效能] 公众号

引言

MTSC2019 中国移动互联网测试开发大会( Mobile Testing Summit China )由国内最大的测试开发技术社区之一 TesterHome 发起的行业会议,聚焦在软件测试及应用质量保障。在刚过去的 12 月 14 号,MTSC2019 深圳站也圆满结束。
在本次大会上,阿里巴巴无线开发专家黄健基为大家分享了《对 App 崩溃 Say No! 如何长期保持 1‰以下崩溃率》这一主题,揭秘了阿里 UC 是如何长期保持 APP 保持千分之一以下的崩溃率的。同时也为大家介绍了岳鹰全景监控平台的建设实践。本文将提取演讲精华分享给大家。


保持千分之一崩溃率的核心重点

打造千分之一崩溃率 APP 的核心手段,主要有下面 3 个:

  1. 问题的采集捕获能力:解决 Android 崩溃、C++崩溃捕获难题,破解系统高版本捕获 ANR 的限制,全方位监控 APP 的质量问题
  2. 快速发现问题的能力:解决设备侧、网络侧的复杂度,保证第一时间上报异常日志;结合智能预警功能,快速发现问题并减少用户影响范围
  3. 高效解决问题:崩溃日志提取能力,将混淆代码、内存地址等还原成可读的代码,结合算法进行问题智能聚类,一键定位原因,高效解决问题

下文将按照实时监控平台的日志采集上报、日志清洗提取、数据分析统计、数据展示,这 4 个核心阶段进行阐述。

全面的 SDK 采集上报能力

SDK 采集上报的核心是要完整暴露 APP 线上质量问题,所以相比一般的 CrashSDK,岳鹰的 CrashSDK具备更全面的应用异常监控能力
除了常见的应用崩溃、ANR、iOS 的卡死、业务逻辑异常、cocos 及 U3D 异常外,岳鹰 CrashSDK 在影响用户体验的异常上继续深挖,通过监控应用的生命周期,将下述异常也监控了起来:

  1. 设备重启,常见的原因是设备或者第三方 rom 的兼容性问题导致;
  2. 强制退出,一般是由于系统或者组件中调用了 exit()或者 Process.killProcess()函数导致
  3. 低内存导致应用被强杀
  4. 除上述外,其他原因导致的应用异常退出

在监控到上述异常产生时,从开发者角度来看,肯定采集到的信息是越丰富越好的。所以,岳鹰 CrashSDK 采集的信息除了常见的机型、rom 和崩溃堆栈外,还包含句柄持有情况、CPU、内存、磁盘 IO 等信息也采集了上来,提高了句柄泄露等场景下的异常问题解决。
不同业务都具备自身的特性,所以 SDK 也支持在异常时,业务将自己的特性信息采集上来。

通过上述全面的监控,岳鹰平台的数据能很好的呈现出用户真实的体验,帮助业务保证崩溃率在千分之一以下。

实时的数据处理链路

当应用更新后,它的覆盖速度也是非常快的,如果我们不能及时发现的话,将会很容易造成重大事故,所以阿里 UC 的岳鹰全景监控平台通过解决设备及网络上复杂的问题,保证 SDK 实时上报;解决代码还原的效率问题,同时通过下述的架构,具备了实时的大数据处理能力,帮助业务在 1 分钟内发现问题,及时控制故障影响面,保障崩溃率在千分之一下。

智能聚类

大家都知道,日志刚上来的时候都是非常分散的,对于研发来说,最直接的肯定就是将相同崩溃堆栈的问题聚合到一起,所以岳鹰全景监控平台也是这么做的,并且在这方面做了比较多的优化:

  1. 计算特征值的时候,需要把行号给剔除掉,避免由于代码迭代,行号变化导致问题离散
  2. 以业务代码作为崩溃点入口,方便业务快速识别是哪个模块的崩溃

除此之外,我们在分析问题的时候,是可以发现某些问题的共性的,根据这些共性,我们就可以在日志处理的时候识别出他们是启动崩溃、句柄泄露、内存泄露或者其他原因导致的异常并自动打标,帮助研发直接定位出原因,提高问题分析效率。
为了满足业务不同的需求,岳鹰全景监控平台也支持按照业务设置的维度进行聚合。

多维的分析定位能力

前面提到的能力让岳鹰平台具备了多维的数据,为了能够高效定位问题原因,岳鹰全景监控平台将平时的分析经验沉淀到了平台上,让这些数据仿佛会说话一般直接告诉研发问题的原因。

实时大盘,第一时间发现问题

岳鹰有一个实时大盘,大盘提供分钟、小时和天级别的数据,图中是我们分钟级别的实时数据,通过这个大盘,我们可以第一时间发现问题。

快速定位 TOP 问题

在发现问题之后,接下来要做的就是找到原因,是什么崩溃导致指标波动。
这里岳鹰提供的 Top 问题列表是按照影响用户进行 TOP 问题排序,可以最直观一目了然找到严重问题,逐个解决。而且也在 TOP 问题列表附上近 7 天趋势,便于观察。

代码分析,直切要害

确定问题之后,接下来就是分析原因了,看代码就是最直接的办法了。这里主要分享一点,岳鹰我们对 C++场景的崩溃日志做了优化,支持 C++行号的展示,以及 inline 函数的符号化。

趋势分析,找准问题

前面讲的是一些需要快速或者紧急解决的问题,而实际上有些问题是比较长尾的。这些问题通过分析趋势,可以找到变化的时间点,并且通过对比,找到影响因素,例如某次发版新功能引入崩溃,厂商发布新 ROM 带来兼容性问题等。

多维钻取,分析共性问题

平台还支持多维度钻取,分析共性问题。这个主要是考虑,有些崩溃问题是在指定机型、系统版本下面才会出现的,所以维度统计也是一个常用的分析手段。另外,还可以逐个选中维度,层层分析。

岩鼠云真机,一键复现问题

前面讲到,找到共性的机型、ROM 等,那么下一步就是在对应的设备上重现,通过 logcat,debug 获取更详细的错误信息。而 Android 机型非常多,iOS 本地调试效率很低,通过 [岩鼠云设备平台] ,可以快速找到机器。包括修复问题之后的回归验证,也可以通过云真机进行。

远程日志

在我们的实践过程中还发现,有些线上问题是比较难一次性解决的。一个是单点用户反馈问题,另外是线上反复的问题。对于这种场景,我们提供「远程日志」,帮助开发者获取更详细的日志和用户操作,解决缺少排查线索的痛点。

极速智能预警

前面讲的分析过程,基本都是靠人工的方式去发现问题的。岳鹰平台将分析问题的经验沉淀了下来,提供了智能预警功能,目前支持「自动通知新崩溃」、「波动提醒」,默认这些预警功能一键即可开启。
为了满足业务不同的述求,岳鹰也提供了丰富的配置,满足不同业务个性化的需求。

海外集群

发展海外市场是大趋势,包括 UC 在内也有比较多的海外业务,这个时候如果把日志从国外直接国内,是会存在以下问题的:
第一、会遇到比较多网络因素导致的稳定性和效率问题
第二、国际政策对数据管控这块是比较严格的,像印度,他是不允许我们直接把数据回流到国内的;

所以岳鹰平台提供了了海外集群,包括日志上传及我们平时的查看都是到这个海外集群里面查看;通过这个方式保证了整个海外业务的日志采集的稳定性和上报的实时性,同时解决了数据回流带来的风险;


结束语

除了岳鹰平台之外,UC 无线效能团队也带来了岩鼠云设备平台,就两个平台的建设过程以及在阿里内部的经验实践,在现场与广大开发者进行了深入的交流分享,受到广大开发者的热烈反响。
现场交流

目前研发效能的岳鹰全景监控平台和岩鼠云设备平台已经对外开放,目前提供限时免费试用,欢迎大家体验:
岩鼠: https://yanshu.effirst.com/
岳鹰: https://yueying.effirst.com/


关于 UC 研发效能

研测领域资深专家团队,依托 UC 十余年移动技术沉淀,全力打造专业的研发效能平台。服务于阿里巴巴 100+产品,为团队降低研测成本、提升交付效率,助力产品提升用户体验,让产品交付更好更快更安心。

1467 次点击
所在节点    推广
1 条回复
Livid
2019-12-18 09:13:02 +08:00
你之前所发布的所有主题已经被移动到 /go/promotions

推广软文只能发布到这个节点。

具体规则请看这里:

https://www.v2ex.com/help/node

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/629870

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX