借款App崩溃率优化实战

App的性能稳定是良好用户体验中至关重要的一环，而现实情况却是应用崩溃、卡顿、慢加载、页面白屏等问题，频频出现在用户的真实体验之中，成为影响业务转化的直接杀手。其中，客户端最为关注的应用性能体验指标是崩溃率和卡顿率。借款App在过去相当长一段时间内崩溃率都处在业界优秀的行列，但随着系统版本以及应用版本的不断迭代，崩溃率也逐渐出现了恶化。本文主要介绍下借款App团队在崩溃率攻坚战上所做的努力以及取得的成果，如何将原本恶化的App崩溃率拉回正轨重回优秀行列的。

借款App崩溃率现状

业内一般使用崩溃率来衡量一款App的稳定性，崩溃率的定义为：

崩溃给用户带来的体验极差，很可能导致用户流失。假设一个用户获客成本是100元，如果是0.1%的崩溃率，按照每天100w日活计算，则每天可能因App崩溃而流失1000人，折合成市场推广费用就是10w元。更不用说挽回用户的成本，以及用户潜在成交的可能。前面说到借款App双端在相当长的一段时间内，崩溃率都处于优秀行列，但随着业务的飞速迭代，它们终于不堪重负，身体逐渐出现了隐患，崩溃率双双跌至0.1%附近，到了不得不重视并解决的地步。

导致 App 崩溃的原因有很多，诸如错误地使用线程、系统函数、编程范式、数据结构等，亦或是系统版本或者机型之间的差异导致的兼容性问题，除了应用本身还有引入的第三方SDK也时有发生崩溃进而影响App本身的情况。大部分崩溃都会在App灰度发布阶段被发现定位并解决。因此解决App崩溃问题的关键是在于能不能尽早地发现和定位这些“坑”。理论上只要定位并填平所有的“坑”，就能避免所有的崩溃，但在实际开发过程中需要对现有代码逻辑和业务影响情况做详细评估再做修复计划，如果当前版本修改的风险比崩溃本身带来的风险还要高，通常会延迟修复计划。还有一些崩溃是偶现的，缺少堆栈信息的，或者特定机型上的，通常比较难以定位。借款App双端都出现的崩溃率恶化现象，也正是因为这种崩溃所导致的。

Android平台案例分析

其中Android端自2021年开始出现了一个Handler相关的崩溃。

Handler : 一套 Android 消息传递机制，主要用于线程间通信

由于听云报上来的崩溃日志缺少完整的堆栈信息无法精准定位 BUG，线下测试也未能复现，且该崩溃均出现在华为鸿蒙系统上。

通过查看官方论坛，发现遭遇同类型问题的开发者众多，彼时鸿蒙系统刚发布不久，所以一度评估认为是鸿蒙系统兼容性的问题。之后随着鸿蒙系统的不断迭代以及市占率的逐渐提高，该崩溃占总崩溃的占比越来越高，期间借款App团队曾数次尝试解决但均未见成效。随着借款App 华为鸿蒙系统市占率达到了25%，Android平台整体崩溃率已经逼近0.1%,我们发起了崩溃率治理专项行动，誓要修复此问题。

通过官方渠道寻求帮助。在掌握的崩溃堆栈信息中唯一有用的排查方向就是Handler，在持续的地毯式排查和修复未果后，我们转换思路联系了鸿蒙官方此类崩溃出现的可能路径，得到的答复是：“关注一下App中是否有子线程绘制UI的情况”。道理我都懂 —— 对于借款App这种超级App来说，一行行的看代码来排查不太现实，此路不通。

通过自动化的方式尝试复现问题。首先，我们在听云中找到一批崩溃的用户，然后去逐个分析用户的操作路径，通过一段时间的分析，大致可以还原出用户崩溃的几个场景：1. 点击关闭弹窗崩溃；2. 启动即崩溃；3. 切换首页Tab崩溃。接下来我们通过在自动化测试平台上编写脚本模拟上述3个场景的操作路径，不断地重复上述步骤希望可以复现崩溃，如果能成功复现bug，那么bug的修复工作基本就完成一半了。

经过数十个小时的自动化测试终于在听云上成功捕捉到了这一崩溃，但是听云有没有可能误报？用户的操作现象是什么？为了进一步坐实复现场景，我们采用了最朴素的技术手段，直接对着测试机开启视频录制，并通过 adb 命令导出日志。最终视频成功监控到了崩溃现象，同时我们也获取到了崩溃详细日志，定位到对应的代码块。随后的修复工作就水到渠成了，修复代码编写完之后我们仍然用这个思路去测试修复成果，自动化脚本跑了近一周都没能复现崩溃，基本可以确定已修复完成。

以上述的场景3为例，最终定位到 WebUI SDK 里在子线程里去设置了下拉刷新背景图，这也佐证了鸿蒙官方给的修复意见。

可以看到修复代码于1月30日跟随Android V10.2版本上线后，崩溃率显著下降到0.02%左右。

iOS 平台案例分析

iOS端占比比较高的崩溃主要有两个：SIGABRT和SIGKILL。其中SIGABRT也是缺少崩溃堆栈，排查修复方案和Android鸿蒙崩溃类似，都是找到崩溃用户，通过分析操作路径，推测崩溃场景进而复现修复。SIGKILL崩溃是在2023年初升级了听云悟空平台后大量出的，其实该类型崩溃一直存在，只是老的听云平台并没有捕获统计到。SIGKILL表示操作系统从上层强制终止了应用的进程，该崩溃占比一度达到40%。在iOS 13之前，SIGKILL是无法被捕获的。随着苹果在iOS 13系统推出MetricKit框架，该框架汇总和分析异常、崩溃诊断、电源和性能指标，并在iOS 14系统进一步提供了崩溃日志统计功能。通过Metrickit，可以收集SIGKILL信号量，帮助开发者更好地了解崩溃情况。使用新技术也暴露了之前未发现的问题，主要集中在内存管理方面。通过Xcode的内存图调试器（Memory Graph Debugger），可以方便地查找项目中的内存泄漏问题，并有针对性地进行修复和优化。

下图为iOS崩溃修复上线后，崩溃率显著下降的趋势图。

总结

稳定性治理是一场持久战。通过上述的修复治理，借款App双端的崩溃率都重回0.02%左右，在行业中属于比较优秀的存在。在过去相当长的一段时间里，我们积累了一套自己的解决思路，包括但不限于：日志分析、自动化测试、性能优化、用户反馈以及监控预警等综合性的崩溃发现、定位和修复方法。从0.1%到0.02%，数量级降低的背后是上述的种种努力，将问题归纳总结整理，形成技术沉淀、适合团队工作方式、匹配产品业务的一套方法论，并将这套方法论贯彻到日常工作中，实现技术服务产品，技术赋能业务，技术创造价值。

App稳定性治理是一场长期的持续战役，无法一蹴而就。但我们对这场战役充满信心，我们相信，在借款App团队成员的共同努力下，我们将打造出更加优秀的产品和服务，为用户创造更加极致的使用体验，为业务的发展注入新的动力。我们将持续进行App的稳定性治理，通过提升技术、改进流程和优化策略，以确保借款App始终保持稳定可靠。

作者简介

Star 信也科技移动应用研发专家，专注于App稳定性及用户体验

Kang 信也科技移动应用研发专家，专注于App基础组件研发