简介： 大促始终是技术和产品的练兵场，每到大促，各种丰盛的富媒体，如直播，视频，3D，游戏互动，AR 等竞相上线，在淘宝的大航母策略下，都集中在万千钟爱于一身的淘宝 App 上，在这样的大促场景下，开始触碰到端侧系统资源下限的天花板。在 17 年双 11 大促期间，端侧的内存问题尤为突显，OOM 的高居所有问题的榜首。内存问题成为了这几年大促端侧稳定性最大的挑战。

作者 | 邹迪飞（之羲）
编辑 | 橙子君
出品 | 阿里巴巴新批发淘系技术

大促始终是技术和产品的练兵场，每到大促，各种丰盛的富媒体，如直播，视频，3D，游戏互动，AR 等竞相上线，在淘宝的大航母策略下，都集中在万千钟爱于一身的淘宝 App 上，在这样的大促场景下，开始触碰到端侧系统资源下限的天花板。在 17 年双 11 大促期间，端侧的内存问题尤为突显，OOM 的高居所有问题的榜首。内存问题成为了这几年大促端侧稳定性最大的挑战。

17 年双 11 Crash 问题分类

17 年双 11 Crash 走势与业务上线关系

放飞业务

两年后的明天，通过咱们继续的技术开掘与治理，内存问题不再是影响大促稳定性的最次要的因素，本次 618 大促前所未有的反对了猜你喜爱有限坑位，反对了丰盛的直播和小视频玩法，反对了会场上百个经营坑位，反对了互动业务的不降级策略，各种业务花式上线的同时，咱们的端侧稳定性还进一步晋升，crash 率远好于去年同期。

618 期间往年与去年比照 crash 走势

迎难而上，各显神通

面对内存带来的挑战，咱们 2 年以来，始终在摸索中前行，积淀一套内存治理的教训。

面向大促，当呈现了问题后，咱们要去思考以后的机制与标准，于是咱们制订了内存规范与业务的上线验收。同时，提供了内存剖析的一套工具，不便很快很准找到问题。同时，咱们制订了三套内存优化策略：

**1. 精打细算，晋升内存的使用率

1. 兜底容灾，尽量让利用缩短生命
2. 晋升内存下限，冲破零碎的天花板 **

验收规范 —– 一夫当关

因为内存天花板的存在，从稳定性角度综合思考，引入了大促的验收规范。规范的制订过程中，咱们统计了产生 OOM 时的水位内位，剖析出了高危，危险，失常水位线，以此为内存规范的制订指引。

内存问题之所以简单，是因为内存是一个全局共享池子，当呈现溢出问题时，在没有显著问题时，很难去界定哪个业务存在问题，因而，在思考规范的时候，咱们定义了两种场景。单页面及链路。

单页面场景次要是为了缩小单个业务过多的占用内存引发的危险。后面提到内存池子是全局且无限的，当单页面占据内存过多，就会导致系统整体可用的内存大幅缩小，在浏览雷同页面次数的状况，减少整体内存危险。

链路场景是对常见浏览链路的内存检测，比方从首页 - 会场 - 互动 - 店铺 - 详情 - 下单这样的惯例玩法进行多页面叠加检测，判断用户失常场景下的内存危险。

同时，在制度内存规范时，也思考了不同技术栈之间的差别。比方 H5,weex,native，包含多 tab 的会场模式及直播，3D 等。

测试同学研发的 TMQ 自动化测试工具

内存优化三板斧

后面提到内存优化次要有三种策略，这里离开详述。

▐ 精打细算 - 晋升内存的利用率

在业务每每涉及内存天花板的状况下，每 1KB 的内存，都显得十分宝贵。

在理论对内存占用的剖析中，咱们偶然会发现有些场景加载的图片远大于视图的大小，造成内存的节约。或者在某些场景下，图片在内存中持有过久，比方在后盾或是压栈很久后，图片所持有的空间仍不能释放出来给以后界面应用，面对这样的场景，咱们在高可用体系中援用了对应的性能，可能检测出这些 case，以便把内存交给用户正在应用的组件，以此来晋升内存的利用率。

从图片库的数据流转以及 View 生命周期登程，来设计图片主动回收和复原的实现，即当 View 不可见的时候，主动开释图片到图片库缓存，只保留图片的 key 值；当 View 可见的时候，又通过 key 复原图片。图片片自带三级缓存策略，回收后的图片如果还在缓存，能立马复原，对体验简直无损。

同时，针对一些内存小户，也和各业务方约定一些实例数限度，比方详情页，有大图，还带视频，webview 等，内存应用绝对较大，这种状况下会对实例数做要求。目前有限度包含详情页，播放器实例等。

为了更好的体验，在降级策略上咱们也做了一些优化，不再一刀切，而是依据各设施本身的能力，有抉择的进行降级。要更好的达成指标，咱们首先对设施进行分级，依赖于创立的智能分级。

对立降级在设施评分的根底上，提供默认的高中低端机型的设施分级能力，减少了配置化能力，为每个外围业务调配一个 orange，反对业务对系统、品牌、机型、设施分、利用版本、失效工夫等多个维度进行配置化降级。

依赖于对立降级，能够做到精准的体验分级，高端机型，能够采纳各种特效和高清图片，能保障最优体验。中端机型，降级掉一部分特效，能够取得较好成果，低端机型，保障稳定性和根底体验。实现“高端设施最炫体验，低端设施晦涩优先，紧急问题疾速降级”

对立降级后的成果

▐ 兜底容灾 – 尽量缩短生命周期

在利用内存最危险的时候，兴许下一次的内存申请即面临解体，在这最危险的时候，咱们是否有能力缓解一下，让用户多下一单呢，为此咱们设计了内存容灾 SDK。

具体原理是基于 gc 和 lowmemorykiller 原理实现（Android 的 OOM 要辨别 jvm heap 内存不足和 native 的内存不足），通过监听系统的 gc 和 lowmemorykiller，去计算零碎以后所处的内存状态，当内存不足的时候，销毁掉优先级较低的 Activity，从而保障用户可见面 Activity 能尽可能多的应用内存而不呈现稳定性问题。

内存容灾基本原理

▐ 裁减下限 - 冲破零碎天花板

手淘的策略始终是航母策略，后面的打法只能缓解以后的稳定性问题，只能治本，不能治标。业务技术对内存的需要有增无减，有限坑位，会场上的直播视频等，都带来进一步的压力。只有晋升端内的内存容量，才是解决内存问题的最终解法。

多过程

多过程的应用是冲破零碎天花板的办法之一。因为大促态的变动新增以 H5 的页面居多，所以咱们重点心愿在 webview 上能有一些冲破。这时苹果的 WKWebivew 被纳入到钻研范畴，对于 WKWebview 在内存的劣势，通过咱们的剖析论断如下：

WKWebView 的内存并不计算在主利用的内存中，而是作为独立过程独自进行计算，因而对于利用来说应用 WKWebView 相比 UIWebView，利用整体能够应用更多的内存，因为 Web 的内存都在 WKWewbView 的 Web 过程中，并不影响主利用的内存下限。

对于 Android 来说，平台自身则反对的多过程形式，因而，咱们最后的设计中，是依赖于 Activity 的独立过程形式，即便 BrowserActivity 独立进去。

在 99 大促的 AB 试验中，比照对照组，在拜访过淘金币 / 互动的用户中，主过程 native crash 率降落 15%-18%，Crash 计数(主 + 子) 降落 1 万次以上。在所有用户中，降落 3%-5%，对内存的优化成果还是比拟显著。

然而思考到很多根底 SDK 在设计之初并没有思考到多过程的形式，且多过程下利用的生命周期也有一些变动，整体计划不确认的危险较大。最终采纳的是 UC 内核的多过程计划，它将整个 H5 页面的解析、排版、js 执行等实现抽离封装到一个独立的过程中，分担了主过程一部分内存压力，从而实现冲破单过程内存容量天花板的指标。

UC 多过程示意图

uc 多过程对 crash 率的影响

依据严格 AB 试验的后果评估，手淘开启 UC 多过程之后，Crash 率能有 30-40% 的降落收益。

64 位降级

一般说来，当初应用的程序，都是在 32 位的指令集下编译进去的后果，在 32 位子零碎下，内存地址的大小只有 4 个字节，实践上的最大寻址空间只有 4G。后面提到，在以后手淘的业务容量下，4G 的内存地址曾经不能满足，在往年开始力推手淘 andorid 架构从 32 位降级到 64 位。

说到 64 位，在硬件上，arm v8 及当前的 cpu 都降级到了 64 位的架构，在软件上，android 5.0 当前的零碎开始反对了 64 位子零碎。咱们做过比拟精确统计埋点，在市面上的手机，约有 95% 是反对 64 位运算的，也就是说 64 位降级带来的收益能够笼罩到绝大多数的用户。另一方面，咱们也要看到 64 位降级带来的危险，所有的 C /C++ 代码都须要从新编译到 64 位指令集，可能的危险点包含：

• 指针长度是从 32 位升到 64 位，对一些 HardCode 的写法可能计算出错，产生稳定性问题。
• 自定义 so 的加载逻辑（如服务端近程下载）可能没有思考多 cpu abi 的状况，加载谬误 so，产生稳定性问题。
• 贮存的数据，看看有没有因为 64 位和 32 位不同导致不兼容，特地是一些二进制数据，导致笼罩装置或降级后原数据不可用

为了应答这些危险，自 3 月份起就开始针对手淘中的 120 多个 so 进行回归，包含看 32 位与 64 位互相笼罩的降级场景，另一方面，针对 so 的加载逻辑，进行全手淘代码扫描，剖析和查看自定义加载 so 的场景确认是否反对多 cpuabi。通过几个月的灰度和迭代，最终在 618 版本前，实现了 64 位的上线。

在本次的 618 大促中，能够显著看到，以往大促中，OOM 的占比，最高的时候，能够占到近 40%，通过 64 位降级与多过程伎俩叠加后，能够看到看大促态的 OOM 占比，曾经降到了 10% 左右。这外面还包含了 5% 的 32 位用户，对 OOM 的治理成果十分显著。

瞻望

新技术状态的挑战
内存问题始终是大促端侧稳定性最大的挑战，在明天曾经失去比拟好的解决，当然，系统资源终归是无限的，咱们依然须要无效正当的应用系统资源。更重要的是，面向未来，新的技术状态像 flutter 等入淘，多个虚似机的并存，对系统资源依然会有较大的挑战。

从稳定性到晦涩体验
对用户来说，稳定性只是最根底要求，后续咱们会在体验上继续优化，带给手淘用户真正的如丝般顺滑的体验。

手淘客户端团队

一年一度的应届生秋招正式开始，岗位丰盛，欢送扫描上面二维码理解详情。同时大量挪动端社招岗位 opening
简历投放地址????：difei.zdf@alibaba-inc.com