写点什么

客户端稳定性优化实战,Crash 率最高下降 40%

  • 2020-08-10
  • 本文字数:3729 字

    阅读完需:约 12 分钟

客户端稳定性优化实战,Crash率最高下降40%

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



17 年双 11 Crash 问题分类



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

放飞业务

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



618 期间今年与去年对比 crash 走势

迎难而上,各显神通

面对内存带来的挑战,我们 2 年以来,一直在摸索中前行,沉淀一套内存治理的经验。



面向大促,当出现了问题后,我们要去思考当前的机制与规范,于是我们制定了内存标准与业务的上线验收。同时,提供了内存分析的一套工具,方便很快很准找到问题。同时,我们制定了三套内存优化策略:


  1. 精打细算,提升内存的使用率

  2. 兜底容灾,尽量让应用延长生命

  3. 提升内存上限,突破系统的天花板

验收标准-----一夫当关

由于内存天花板的存在,从稳定性角度综合考虑,引入了大促的验收标准。标准的制定过程中,我们统计了发生 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 等入淘,多个虚似机的并存,对系统资源仍然会有较大的挑战。

  • 从稳定性到流畅体验

  • 对用户来说,稳定性只是最基础要求,后续我们会在体验上持续优化,带给手淘用户真正的如丝般顺滑的体验。


本文转载自公众号淘系技术(ID:AlibabaMTT)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650409401&idx=1&sn=7eaff7213e397c24cea658173c0a45c8&chksm=8396c1a1b4e148b765c1a82503b4c713a58a93fe673371efd8d38f68952c21c154c54c2126d6&scene=27#wechat_redirect


2020-08-10 14:042831

评论 1 条评论

发布
用户头像
谢谢分享场景。
2020-08-11 13:07
回复
没有更多了
发现更多内容

哪家好用?四款国内外远程桌面软件横测:ToDesk、向日葵、TeamViewer、AnyDesk

热爱编程的小白白

聊聊Excel解析:如何处理百万行EXCEL文件? | 京东云技术团队

京东科技开发者

POI 内存优化 企业号 7 月 PK 榜 excel解析

NFTScan | 06.26~07.02 NFT 市场热点汇总

NFT Research

热点 NFT\

单色和彩色LED显示屏

Dylan

场景 使用技巧 显示器 LED显示屏 全彩LED显示屏

微服务架构中的单一职责原则:构建高内聚、低耦合的服务

2756

微服务 微服务架构 单一职责

前端常见的十种布局

EquatorCoco

前端 前端前端框架

给新手产品经理的技术接口文档入门指南

Liam

产品 程序员 接口 API接口文档

与 TDengine 性能直接相关——3.0 的落盘机制优化及使用原则

爱倒腾的程序员

涛思数据 tdengine 时序数据库

Jmeter压测实战:Jmeter二次开发之自定义函数 | 京东云技术团队

京东科技开发者

测试 Jmeter 压测 企业号 7 月 PK 榜 插件化机制

关于序列化与反序列化MessagePack的实践 | 京东云技术团队

京东科技开发者

序列化 反序列化 企业号 7 月 PK 榜 MessagePack 字节序列

一文了解AppSec,以及如何通过Perforce工具保障应用程序防护

龙智—DevSecOps解决方案

APP开发 应用程序安全 AppSec

云会议成为企业高频服务,华为云会议为何成为众多企业的选择?

轶天下事

从头学Java17-Lambda表达式

烧霞

Lambda java17

怎么样可以算一名云原生工程师?

高端章鱼哥

云原生

从头学Java17-Modules模块

烧霞

modules java17

​阻抗计算,真的没有那么难!

华秋PCB

工具 电路 阻抗 PCB PCB设计

稳定性和高可用如何兼顾,华为云网站高可用解决方案满足多方案需求

轶天下事

迭代失败的4个迹象,团队中了几个?快来看看如何解决!

敏捷开发

项目管理 Scrum 迭代 开发人员

互联网高可用架构探讨 | 京东云技术团队

京东科技开发者

高可用 架构设计 硬件架构 网络架构 企业号 7 月 PK 榜

云原生实力再获认可!腾讯云云原生拿下重量级奖项

Geek_2d6073

【直播预告】HarmonyOS极客松赋能直播第四期:HarmonyOS开发经验分享

HarmonyOS开发者

HarmonyOS

《golong入门教程📚》,从零开始入门❤️(建议收藏⭐️)

不在线第一只蜗牛

教程 Go 语言

数据库中用户删除不掉总是报错,依赖如何处理干净?

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 7 月 PK 榜

如何设计一个最简化的推荐系统

快乐非自愿限量之名

框架开发 系统框架

华为云桌面正协助企业快速进入云上数字化办公时代

轶天下事

数字化办公需求激增,华为云桌面解锁全新云办公模式

轶天下事

完全兼容DynamoDB协议!GaussDB(for Cassandra)为NoSQL注入新活力

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 7 月 PK 榜

客户端稳定性优化实战,Crash率最高下降40%_软件工程_邹迪飞(之羲)_InfoQ精选文章