打破重重阻碍，手淘如何突破native crash提升稳定性？

作者|潘文超(开风) 

出品|阿里巴巴新零售淘系技术部

导读：本文是作者在 「Top100全球软件案例研究峰会」上分享的——手淘Native治理，结合分享后的反馈焦点，从 native 问题线下发现和快速定位、新so集成标准、线上历史native问题治理等几个方面为大家介绍，特产此文。

扫描下方二维码，关注「淘系技术」微信公众号，回复“native”即可获取本次分享完整版 PPT 资料！

背景

---

无线客户端 crash 一般分为 java crash 和 native crash ，无线应用往往为了追求更好的性能，把一些复杂的计算放到 native 层去实现，java 层通过 jni 调用 native 层实现，满足功能场景；在 native 层产生的崩溃就产生了 native crash ；无线客户端衡量稳定性的最重要的指标就是 crash 率，稳定性一直是各系统治理的重中之重，也是一直绕不开的话题，而 native 是目前业界认为治理最有难度，也是要重点突破的方向。接下来分析一下为什么 native 治理值得去做以及如何做好。

▐  目前手淘Android的crash现状——找方向

从图中我们可以看出，java crash 正常可以维持在较好的水平，手淘 native crash 一般比 java crash 要高，大促期间，由于手淘内存瓶颈，  native crash 率会涨到日常水准的2-3倍。

从数据可见，native crash 是 java crash 的6倍之多，如果要想进一步突破，native 是有很大空间的，但 native 问题一般都很难定位， 堆栈不全，或者堆栈都集中在系统 so 上，无法直接定位问题，所以想要突破难度很大。手淘稳定性再上升一个台阶，native crash是瓶颈，需要突破。

▐  native crash 治理挑战——难

（1）难点一：crash堆栈目前绝大部分只有系统so，缺乏问题关联的业务模块so，定位问题难度大，可以看一下如下的一个native crash堆栈，堆栈中的so都是系统的，无法直接定位业务问题。

（2）难点二：线上so都是去符号化的，即使堆栈中有业务so，也需要记录该APP版本对应的符号化so做反解才能拿到能看得懂的堆栈。这点已经通过第一阶段的native工程标准化解决，打出来的SDK包里面必须要有对应的符号化so才可以集成。

（3）难点三：目前线下有效提前发现native问题的手段缺乏，想要提前发现，需要平台工具和有效手段。

▐  native crash 治理核心问题是什么？——找抓手

要治理、要解决问题，首先得理清目前导致 native crash 的问题，在做之前，做了一下 crash 数据分析，于是手动捞取了当时近5个版本的 top native crash 数据，占比最多的就是sig 6和sig 11。

那能说明什么问题呢？signal 6这种崩溃信号要看具体场景，但根据具体数据分析，手淘里面一般都是堆栈溢出、OOM 等导致的。signal 11 这种崩溃基本就锁定为内存问题了。

根据实际数据，大部分 crash 原因是因为内存，可以初步下的结论是，目前手淘 native crash 治理的关键是内存，解决手淘native内存相关的问题即可解决掉不部分问题。

Native问题治理平台工具调研

---

对集团内及业界的一些产品做了一些调研，详细如下：

分别从使用成本、功能支撑、是否有堆栈能力，性能如何等维度进行了比较，其实我们的诉求是希望不需要 root 就能 run 起来，因为我们要持续集成、线上能灰度验证，线下可以大规模任务执行、并且可以做手淘 native 问题沉淀，能把问题沉淀做成检查项，可以涵盖解决主要的内存问题，不止是内存泄漏。因此开发了Native Finder，希望能彻底治理好手淘 Native 问题。

Native治理——Native Finder整体技术方案

---

Native Finder是利用elf hook的原理，对malloc、free、realloc、alloc、mmap、munmap 等操作进行 hook，在自己的 hook 函数中，做一些智能分析和统计，并最后会调用系统内存操作函数，不破坏 so 原本发起的 malloc 等操作。

这个方案的缺点是会有一定的性能损耗，毕竟在 malloc 等操作中增加了一些分析和统计操作，但性能影响还好，在开了堆栈能力之后，APP性能会受影响，这个也是后面要优化的地方。整体技术方案如下：

native crash治理过程

---

首先在前期，花了比较多时间去研究历史数据及问题，认真分析 crash 的关键问题和痛点是什么，才找准了方向，分析出来内存问题是最痛的点。治理过程总结如上图，分为5个阶段。接一下讲详细介绍结合Native Finder工具平台的治理过程和心得。

▐  native工程标准化

治理总结如下：

总结起来这个阶段我们做了3件事情：

• 第一，库迁移，为什么要做库迁移呢？我们把老的gnu C++基础库迁移成libc++_ shared库，所有so都做统一，归一化，方便归一native层问题；

• 第二，我们还做了重复so治理，因为不同so可能依赖了相同的so基础库，举个例子，例如A so依赖了libopenSsl基础so，B so也依赖了libopenSsl库，但他们依赖的版本不同，这样带来的坏处是，首先会增加包大小，其次会有相同so的不同版本存在应用中，这给定位问题带来了麻烦，所以需要对基础so去重。

• 第三，每个版本包包括灰度版本都需要存储下对应的符号化so，便于在crash发生后，我们对堆栈做符号化处理，这样堆栈我们就能看懂了，加快和精准定位问题。这个阶段是后面做的所有事情的基础，非常重要。接下来我们看看下一个阶段治理

▐  Native Finder开发完成，线下monkey跑native问题

此阶段发现了几个堆破坏的问题，但是经过好几天反复线下执行 monkey，并未有任何进展。

后续调整思路，开始逐个分析线上存在的 native crash，并根据这些 crash 特征和根因开始沉淀经典问题，并把这些问题做成检查项，跟同学交流和对焦后。

通过进一步的数据，发现内存 OOM 是目前优先级较高，且比较严重的问题，所以开始做这方面的技术建设，跟 crashSDK 打通，Native Finder 中统计和分析 so 维度占用内存未释放的数据，在 crash 的时候做内存信息 dump，并输出辅助信息，例如 malloc、mmap 次数、大内存（大于2M，属于大内存申请，可配置，可动态调整）的申请等信息。接下来看一下线下monkey 驱动阶段

▐  线上灰度，结合用户真实操作场景crash

线下 monkey 并不能都能复现问题，借助工具平台拿到关键信息去做问题解决和定位，我们希望场景更加丰富和多样，所以我们把 Native Finder 放到线上，做了线上灰度。

随即把 Native Finder 放到线上做外灰，在用户真实操作场景下的 crash，拿到 crash 时的内存 dump，但是经过一段时间的线上 crash 内存信息采集，然后分析之后，没发现明显问题，从现在回头看这个阶段，其实当时的数据是能够体现出问题的，只是当时的想法不对。

▐  虚拟内存不足，是目前OOM主要原因

我们对线上crash做了分析，同时也在线下做了可疑场景的尝试复现，复现过程中，我们也做了大量数据的对比分析；

分析发现：正常 crash 跟 native oom crash，在内存详细数据上做对比，发现OOM crash 在 native vmsize 上有较大差异，又看了很多手淘 OOM crash，发现都是这个原因，vmsize 暴涨。

大家都知道，32 位系统下，系统 vmszie 只有4G，还要抛去一些系统内核占用、以及共享内存占用，vmsize比较有限，手淘又是一个体量很大的航空母舰，各个业务都想有最佳的业务体验，都想用空间换时间，每个业务泄漏那么一点，那手淘就被撑爆了，是累加泄漏的结果。

 所以手淘 Android OOM 要一个一个解决，逐个挖出来，才能根治。我们整个过程沉淀了如下检查项：一共沉淀了8项内存检查，内存检查项已经能覆盖 80% 以上的内存问题了；fd 文件句柄检查项一共沉淀了6项，fd 的检查项已经能覆盖几乎95%以上的 fd 问题了。

我们同时也研发了本地调试模式，方便开发和测试同学，能快速在本地复现和定位问题，具体的技术方案如下：

▐  开始陆续发现各种 native 问题

朝着这个方向，对 Native Finder 做了逐步优化，开始陆续发现各种问题，治理初步阶段，我们通过 Native Finder 工具平台一共治理发现 20+ 问题，其中包括了多种问题类型，例如内存堆破坏、内存泄漏、OOM、内存操作越界、多次free、内存操作错误等。

同时手淘日常的 native crash 率也有明显降低。到这里，我们 native crash 已经初见成效。虽然通过治理，陆续发现了不少问题，但是还远远不够，手淘内存问题依然严峻，特别是双十一场景下，互动、活动以及各种场景链路互拉的场景，内存问题还是很严峻，后续还需更加努力。

展望

---

接下来我们希望还能做的更多，现在才刚刚开始；手淘内存问题依然严峻，要彻底治理，需要建立卡口，发现问题自动加入必改问题池，形成良性循环，旧问题不断发现解决的同时，还需要杜绝新问题的引入。

除了 native so 导致的内存问题，当前 H5 场景的内存问题也比较严峻，去手淘随便拿几个 H5 页面，看一下内存增量，都超过内存标准，H5缺乏管控，下半年需要对H5内存做卡口严控；目前针对前端的内存泄漏，还没有有效的手段去检测发现，从native层看，都体现在内核上，内核应该是没有问题的，如果有效发现前端代码导致的内存泄漏，也是一个值得研究的点，不过先做卡口再做进一步突破。

今日吐槽

大家都在 native 治理上遇到哪些坑？

欢迎评论区留言，和小橙子分享哦～

We are hiring

淘系技术质量团队负责保障整个淘宝和天猫主站的业务质量，在这里有丰富多样的业务场景和技术挑战，以及很多优秀的合作伙伴。在这里你不仅能够了解世界级双十一是如何保障的，最关键的是有对技术极致追求，对生活的充满热爱的一群俊男美女们。还等什么，赶紧加入我们一起共同打造淘系的技术质量。请投递简历至邮箱：[e-mail]

END

干货文章

点击下方图片即可阅读