深度解读：便利蜂 React Native 多版本共存的平滑升级实践

InfoQ：为什么要进行 React Native 的版本升级？

李国乾：便利蜂业务线上化、数字化的程度非常高，React Native 被广泛的使用在从 B 端到 C 端，从工厂、物流到门店消费者的各个环节。为了满足各个业务部门对功能、性能、稳定性等各方面的要求，基础组件团队对 React Native 框架进行了深度定制，而且在不断关注 React Native 新版本的动态。定期跟进官方新版本有两点最主要的好处：

• 第一点是开发提效赋能。随着 React Native 框架升级迭代、前端技术生态的演进，React Hook、Fast Refresh、Flipper、React 17 等技术、工具不断的涌现出来，带来了更先进的开发理念、更高效的开发工具、更丰富的能力；

• 第二点是拥抱开源社区。开源社区的框架、组件会优先支持新版本。新版本也有更多的最佳实践、issue 可以参考。

除此以外，新版本还具备更好的性能，更高的健壮性。因此，定期跟进官方新版本是十分有必要的。

InfoQ：为什么选择多版本共存的升级方案？

李国乾：我们在讨论一种多 Bundle 的场景时——一个 App 中包含多个 JS Bundle，分别由不同的业务线负责开发维护。常规的升级方式有三种：

• 第一种是单版本无感知升级，框架保证完全向下兼容，业务无需适配；

• 第二种是单版本有感知升级，需要推动各个业务线在一次 App 发布中，完成所有 JS Bundle 的升级；

• 第三种是多版本共存，JS Bundle 允许使用不同的 React Native 版本，业务线可以根据需要选择是否升级。

以上三个方案中，方案一的效果最好，但是却不适用于新老版本差距较大、有较多 Breaking Change 的情况。方案三和方案二相比，优点是升级方案更平滑，缺点是方案更复杂，且有代码量成倍增加、App 包增大的缺点。

最终便利蜂选择了多版本共存的方案，最主要的原因是我们观察到了一组非常有价值的数据：从需求管理平台中，取出三个月时间内和 React Native 有关的所有需求。其中 79% 的需求是在 22% 的 JS Bundle 上发布的，另外有 41.5% 的 JS Bundle 三个月内没有任何发布记录。

升级 React Native 的两点好处体现在开发提效赋能和拥抱开源社区，主要是提升开发阶段的体验和效率。对已经成型、迭代少的项目，升级 React Native 带来的提升十分有限，而对于公司内 78% 迭代不频繁的项目，升级的成本则远大于升级的收益。因此，我们认为多版本共存是最契合业务需求的方案选择。

实际上，多版本共存和近些年兴起的微前端十分相似。微前端中技术栈无关的设计，就是要解决既要拖着历史代码前进、又想使用新技术栈的问题。

InfoQ：多版本共存的升级方案是如何实现的？落地效果如何？

李国乾：通过修改包名、动态库，就可以把多个版本的 React Native 放置同一个 App 中。但是，App 内一般会存在大量自定义 Native Module、Native Component，且每多一种 React Native 版本，就需要复制一份代码，导致代码维护难度成倍增加，App 包大小难以控制。为了解决这个问题，我们精简掉了老版本大部分代码，并实现了自定义 Module、Component 的跨版本支持。老版本 React Native 只留存部分必要代码的情况下，保持了行为不变。这是整个技术方案中最核心的部分。

除了解决上述的问题，多版本共存还提供了很好的平滑升级体验，支持按照页面维度，部分场景下按照 Component 维度升级的能力。

目前，多版本共存方案已经在便利蜂内部研发完成并落地，两个版本共存的同时 App 包体积几乎没有增大。在业务接入方面，越来越多的 TOP 迭代项目已经迁移到了新版本；迭代较少的项目无需改动代码，也获得了部分新版本带来的性能提升。

InfoQ：现阶段项目主要是在B端还是在C端实现的落地？

李国乾：现阶段主要在 B 端落地。最初设计方案时，已经充分考虑了 C 端和 B 端不同的场景。仅限于 React Native 版本升级方案的范畴内，C 端更关注 App 包大小、更新率，对使用体验更敏感；B 端对包大小敏感程度较低，同时因为比较难回归到所有流程，升级过程对老版本特性不变的依赖更大。

InfoQ：在研发过程中有发生什么有意思的故事吗？

李国乾：我们升级的第一个 JS 项目，是有着几年历史，现在依然在频繁维护的一个 B 端项目。项目历经几个团队开发、转手，内部有很多历史遗留代码，甚至一个 library 的源码也缺失了。我们花费了两周的时间，完成了对所有页面的梳理和 React Native 版本的升级，删除了不再使用的十万行代码，而常规下对所有历史项目的梳理和升级，会耗费非常多的时间。这次升级经历也让我们确信对于 B 端系统，选择多版本共存、平滑升级的方案是十分必要的。

InfoQ：React Native 性能问题是业界讨论较多的话题，便利蜂是如何解决性能提升瓶颈问题的？

李国乾：React Native 存在几类主要的性能问题，比如启动速度较慢、白屏，动画卡顿问题，长列表渲染。

• 对于启动速度较慢，我们通过一系列手段进行了优化，比如引入 V8 Engine 相关能力、预加载、inline require 等方式；

• 对于动画卡顿问题，官方和社区都提供了在 Native 测执行动画减缓卡顿的方案。最极端的场景下，也可以考虑使用定制 Native Component 的方式解决。总之，React Native 可以满足绝大部分场景下业务的要求。

另外，我认为高性能并不是评判一个跨平台框架非常核心的指标。受性能瓶颈限制的页面，只占整体的一小部分。以便利蜂 C 端为例，多数页面的节点数小于 300 个，框架性能拉不开差距。

再举一个例子，微信小程序和 React Native 有着类似的通信架构。一般情况下，两者的逻辑运行和视图渲染分别运行在两个不同的环境中，通过异步队列进行数据传输。底层设计类似，所以两者在性能上相比原生都有一定的差距，但这并不妨碍微信小程序产生了大量高质量的应用。

InfoQ：跨端成为当下潮流，跨端技术选型要如何做？

李国乾：我认为跨平台框架核心是解决“多端生态中相同的内容需要多次开发”的低效问题。因此，跨平台框架既要求对相同的 UI、逻辑部分复用尽可能多的代码，又要对差异的 UI、逻辑有比较好的工程化处理方案。React Native 和 Flutter 在框架理念、底层设计上不同，虽然在细节上各有胜负，比如 Flutter 的性能上限更好、React Native 使用 JavaScript 受众更广，但是不存在一方完全优于另一方的情况。

除了跨端能力、工程化程度两个比较重要的考量因素以外，社区的活跃度也非常重要。当前两个框架的社区活跃度都很高，选择任何一个框架，都能满足大部分场景下的业务诉求。更多的是根据公司对不同开发语言的接受程度、性能、技术人员构成等方面进行选择。

InfoQ：未来跨平台开发会出现大一统的局面吗？

李国乾：Web、App、小程序，大前端生态在向着多端碎片化的方向发展。对于一个跨平台方案，除了我认为最重要的跨端能力、工程化程度、社区生态三个方面以外，还有上手难度、性能、稳定性等诸多指标可以衡量。除非出现一种跨平台开发的技术，在大部分重要指标上不弱于其他跨端技术，比如社区生态追赶上 Web，平台能力、性能上比肩原生，可能才能完成大一统。

在完成大一统可能性比较小的情况下，我认为根据业务的实际情况，组合多种跨端方案会是最主流和长期存在的方案。另外，就算未来出现了大一统的框架，业务代码的复杂度是不会随着统一而降低的，因为每个端生态、API 的不同都对前端的工程能力提出更高的要求。

InfoQ：对年轻化的前端、客户端开发人员有哪些建议么？

李国乾：大前端发展到今天，广度上概念、技术类别越来越多；深度上每个细分领域也有深入的研究，衍生出了很多细分的岗位。我认为 T 字型知识结构是比较适合大前端同学的发展结构，能够向下钻研，对工作中投入时间长的细分领域做到足够的深度；同时能够向上抽象，尝试解决一类通用的问题，或者触类旁通了解其他领域的知识点。

嘉宾简介：李国乾，便利蜂移动端技术专家。2016 年加入便利蜂，参与了公司整套移动端研发体系的搭建，负责跨端方案、基础组件的建设。

▌ 会议推荐  ▌

5月29-31日，QCon 全球软件大会 2021 ·北京站——【移动新生态趋势下的应用实践】专题下的《便利蜂 React Native 多版本共存的平滑升级实践》将进一步解读 React Native 多版本共存的实践。

此外，本专题下还有快手 OOM 治理实践，网易有道、58 本地服务的 Flutter 落地实践探索跨端技术带来的新的可能性，以及美团在 React Native 实践上如何实现优秀性能加载体验，更多移动端的精彩演讲可以【扫码】或点击【阅读原文】查看。

☞ 目前会议 8 折购票中，现在购票立减 1760 元，团购还有更多优惠！

☞ 有任何问题欢迎联系票务小姐姐Doris：17310043226（同微信）