【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

客户端稳定性优化实战,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:042596

评论 1 条评论

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

直播回顾 | seL4基金会主席谈物理系统安全工程实践

鉴释

自动驾驶 操作系统 微内核 在线研讨会

硬实力再获认可!焱融科技入选《2021爱分析云计算厂商全景报告》

焱融科技

云计算 分布式 高性能 文件存储 科技

2021大厂Java面试必问题目,Java后端校招面试题

Java 面试 后端

2021年Android开发学习路线,互联网行业“中年”危机

android 移动开发

2021年Android大厂面试,送大厂面经一份

android 面试 移动开发

2021大厂Java社招最全面试题,2021Java面经

Java 面试 后端

2021年Android大厂面试,劲爆

android 面试 移动开发

2021京东最新Java面试真题解析,2021Java开发面试解答

Java 面试 后端

2021年Android工作或更难找,2021Android面经

android 移动开发

2021华为Java高级面试题及答案,Java技术成长

Java 面试 后端

2021年Android常见面试题目,程序员必须要了解的知识点

android 移动开发 Android面试

2021大厂Java面试经验,这位阿里P7大佬分析总结的属实到位

Java 面试 后端

2021年Android开发学习路线,终于彻底把握了

android 面试 移动开发

数据库排行榜|当 DB-Engines 遇见墨天轮国产数据库排行

墨天轮

MySQL 数据库 oracle TiDB 国产数据库

2021年Java工作或更难找,springboot源码解读与原理分析

Java 面试 后端

分布式服务下,消息中间件改造

Java 架构 面试 分布式 后端

2021年Android工作或更难找,深入剖析原理

android 面试 移动开发

2021年Android工作或更难找,透彻分析源码

android 面试 移动开发

2021大厂Java春招面试经历,Java高级架构视频

Java 面试 后端

2021大厂Java春招面试经历,宅家36天咸鱼翻身入职腾讯

Java 面试 后端

2021年Android开发者常见面试题,涨薪7K

android 面试 移动开发

2021年Android常见面试题,Android培训那里好

android 面试 移动开发

2021年Android开发前景如何,详解Android架构进阶面试题

android 面试 移动开发

2021一位Java中级程序员的跳槽面经,springmvc源码解析pdf

Java 面试 后端

2021互联网大厂Java面经合集,阿里面试官必问

Java 面试 后端

2021年Android岗位BAT大厂面试题知识点小结,阿里巴巴安卓面试题答案

android 面试 移动开发

2021大厂Java开发面试总结+解答,21条MySQL性能调优经验

Java 面试 后端

2021Java高频精选面试题讲解,2021Java大厂面试真题

Java 面试 后端

三维可视化数字能源系统,助力智慧园区高效能源管理

ThingJS数字孪生引擎

大前端 物联网 可视化 数字孪生

2021年Android开发前景如何,腾讯T2大牛亲自讲解

android 面试 移动开发

2021大厂Java面试集合,作为Java程序员

Java 面试 后端

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