美团做 React Native 性能优化的三个关键点
Posted 前端之巅
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了美团做 React Native 性能优化的三个关键点相关的知识,希望对你有一定的参考价值。
在移动开发领域,React Native 无疑是一个非常热门的开发框架,其相比 Native 开发最大的差距体现在性能上,尤其在打开页面时会明显感到加载速度变慢。搭载 React Native 框架就不得不面对性能调优的问题,这也是令大多数开发者头疼的地方。
React Native 页面加载性能优化的最佳路径有哪些?有哪些“坑点”需要注意?跨平台开发流行的当下,技术框架选型上有哪些注意事项?带着这些问题,InfoQ 采访到美团移动端技术专家吴卓,他将分享团队在 React Native 性能优化实践层面的一些经验,以及对于技术框架选型的一些建议。此外,在 5 月 29-31 日 QCon 全球软件开发大会(北京站)2021 会议上,他也将分享相关的实践案例,为使用 React Native 的开发人员,提供相关的经验做参考。
以下为正文:
吴卓: 相比原生开发性能,React Native 最直观的差距体现在页面加载速度上,这也是我们一直在研究的重点。性能优化一般包括以下 3 个阶段:
建立衡量指标
提供优化手段
运营推动治理
在加载性能指标方面,我们重点关注秒开率、页面加载时长两个指标,其中秒开率是用户视角下的结果指标,而页面加载时长是框架层面优化下的重要过程指标。在优化手段方面,我们侧重于从 Native 侧进行优化,提供优化的手段多达二十余种,在业务层、框架层、React Native 层、引擎层均有优化工作。在运营推动方面,因为框架团队和业务团队分属不同部门,框架团队不可能直接给业务团队下指标去完成任务,这时候更多靠运营手段进行推动,包括建立标准值、跨业务横向对比,以此敦促业务去做性能优化。
吴卓: 我们在技术层面和非技术层面都遇到了不少挑战,下面从这两个角度出发列举两条:
技术层面的挑战: 最开始我们从框架层以操作前置为主要思路进行优化,将很多耗时的操作放在进入页面前执行,但是最终呈现出来的效果却有限。后来我们不断深入进行 React Native 及 JS 引擎底层研发,由此研究出了一些帮助业务进一步提升页面加载性能的“黑科技”,这部分我将会在 【QCon 全球软件开发大会(北京站)2021- 移动新生态趋势下的应用实践】 专场上给大家分享。
非技术层面的挑战: 除了技术上的难点,业务间的协同和管控也是个令人头疼的问题。美团 App 上有很多业务都在使用 React Native,但我们可提供的一些优化方案需要占用额外资源,比如:启动时下载、引擎保活池等,所以我们设计了很多规范标准,根据页面流量、效果收益去分配这些公共资源;同时,我们还通过架构设计、检测工具去感知业务的使用情况,避免业务不合理地使用某些优化手段。
吴卓: 印象最深刻的还是我们第一次进行 React Native 大版本升级——横跨了 6 个 React Native 的大版本。因为美团上有大量业务在使用 React Native,所以我们需要推动所有业务共计几百个 React Native 的页面配合做升级适配,其中难度可想而知。现在回想起来,确实做了件轰动全公司的事情,当时心里还是很慌的,团队都做好了低绩效的准备。不过,皇天不负有心人,最终推动完成了升级,取得了一个胜利。后来我们也研究出了兼容升级的方案,让业务能够平滑升级。
吴卓:我们一直在关注 React Native 大重构的进展,包括 TurboModules 和 Fabric,相信等到 React Native 完成重构后性能可以再上一个台阶。到时候,React Native 的大版本升级又是个难题,这需要提前布局做准备。
如果其他团队也想实践,首先可以给大家一些信心,App、流程、页面级别的 React Native 化,我们已经有稳定的实践,可放心使用;再者,使用优化手段的技术实现,是很容易复制的。但是对于大型项目而言,还是需要根据各自的业务场景、以及公司环境状况制定合适的落地推进计划。
吴卓:框架的技术选型源于业务背景。 回到 2018 年立项之初,美团 App 包大小治理已经迫在眉睫,由于业务不断增长,从客户端层面出发的传统优化手段(如:资源压缩、重复代码清理等)已经赶不上业务增加的代码速度,必须采用动态化的方案进行解决。
React Native 的开源社区最为广泛,且业内已经有较多成熟的实践,在需要大规模使用的前提下我们预判使用 React Native 的成功性最大,当然数年之后的结果确实印证了当时选择的正确性。
而 Flutter 在 2018 年刚推出,在 ios 侧还并不具备动态化能力,并且业内大规模使用的验证较少,所以不会贸然去选择 Flutter。当然,目前 Flutter 框架在公司内也有团队在使用,我们也在密切关注 Flutter 的发展。
吴卓: 这些对比抽象来看,更多从开发者的角度出发对框架的易用性进行的对比。不得不承认,Flutter 作为后进者很多方面做的不错,但我认为这些优劣还不足以决定技术选型。
我们在使用这些开源框架时,一定是对应去解决业务上遇到的问题和挑战。当这些开源框架进入公司里应用并落地时,还需要根据业务的实际情况,基于开源的工具做进一步的建设和调整。一个选型方法论就是,在公司应用落地时,优先考虑的应是框架能否解决实际问题,其次才是框架的成熟度、应用情况、技术天花板是否值得长期押注在这个框架上。
吴卓: 开发框架的选型最终还是要回归到业务场景上。跨平台开发框架的常见收益点包括:动态化能力、跨平台复用提效、技术栈统一等方面。我列举两个例子:
为了协调不同业务的开发,美团 App 划定了发版窗口,对业务而言发布效率成了业务的痛点,因此就有了动态化的诉求;倘若是一个自行掌控的 App,能够随时提审随时发布,动态化的诉求可能没那么高。
再比如公司内有些手持 PDA 设备,属于特别低端的 android 机器。有的团队不考虑跨平台框架,一是没有 iOS 端的需求,二是设备性能较差,三是设备自带的更新机制比现有 React Native 基建的动态化效果更好。但有的团队仍然选择了跨平台框架,原因是短期内技术栈储备不够,只能先用团队最熟悉的 JS 进行需求开发,等人力补充到位后再视情况调整。
所以,在做技术选型时,还是从业务场景的现状决定,没有绝对好或者不好的框架。
吴卓: 我认为不会。因为技术有最佳实践,但是没有银弹。从原理上跨平台做得好,一定是在其他方面有取舍,比如性能、动态化能力、开发语言难度等等。从业务场景出发,都会有各自最适合的框架。我并没有期待大一统的局面,更希望的是各个框架在各自场景下都能发展到极致。
吴卓:React Native 框架在业内使用较为频繁,下面列举几条必做的事情:
第一,虽然 React Native 使用前端语言开发,但是如果想让 React Native 发挥出更好的效用,则 需要客户端的同学一并参与维护。先前我们遇到的很多问题连调,光从前端 JS 层入手无法解决,需要深入到 Native 层进行排查。
第二,React Native 在 Android 侧健壮性稍差,直接使用 Crash 率会比较高,需要自行修改源码,增加异常处理、特殊系统适配等操作。
第三,Android 侧 JSC 引擎性能不太好,改善方法是 尽可能升级到新的 React Native 版本(0.60+),然后将默认的引擎替换掉。
吴卓: 我想这个问题每个人都有各自的见解,下面仅谈点个人经验。技术上的学习其实是个“T”型,中间的竖线代表深度,横线代表广度。我们需要优先专注于一个方向深入学习,比如:iOS、Android、FE 等等;当一个事情研究到足够深入的过程中,你会发现还有更多不知道的东西,需要你不断学习新的知识、拓宽看问题的广度。在前端、客户端领域,变化非常快,新框架层出不穷,个人建议是专注于某个方向做到足够深入,同时也需要保持对其他方向的持续学习和关注。
嘉宾介绍: 吴卓,美团移动端技术专家。2014 年加入美团,负责过酒店、机票、火⻋票业务客户端团队;目前是美团 React Native 项目负责人,负责美团内基于 React Native 的基础建设。
5 月 29-31 日,QCon 全球软件开发大会(北京站)2021——【移动新生态趋势下的应用实践】专题下的《美团 React Native 页面加载性能优化实践》将进一步解读 React Native 性能优化的更多实践内容。此外,本专题下还有快手 OOM 治理实践,网易有道、58 本地服务的 Flutter 落地实践探索跨端技术带来的新的可能性,以及便利蜂 React Native 多版本共存的平滑升级实践,更多移动端的精彩演讲可以点击 【阅读原文】查看。
以上是关于美团做 React Native 性能优化的三个关键点的主要内容,如果未能解决你的问题,请参考以下文章
React Native FlatList 原理解析与性能优化
记录React性能优化之“虚拟滚动”技术——react-window