第

Shopee在React?Native?架构方面的探索及发展历程

目录1.背景2.发展历程2.1第一阶段：单bundle集中开发模式2.2第二阶段：单bundle多业务组开发模式2.3第三阶段：多bundle中心化架构模式3.去中心的RN架构模型3.1独立JS运行时3.2开发流程3.3构建流程3.4发布流程4.系统设计4.2bundle生命周期管理4.2.1客户端版本控制4.2.2灰度和回滚4.3系统效能提升4.3.1差分增量4.3.2多场景入口体积优化4.3.3一站式多环境融合5.旧业务的迁移方案5.1逻辑耦合5.2组件耦合5.3渐进式迁移6.总结

1.背景

ReactNative（下文简称RN）是混合应用领域流行的跨端开发框架。RN非常适合灵活多变的电商领域业务，由于RN是基于客户端渲染的技术，所以相较于H5页面，它在用户体验方面有一定优势。

伴随着Shopee业务的飞速发展，我们App中的RN代码量增长得非常快，出现了构建产物体积过大、部署时间太长、不同团队依赖冲突等问题。为了应对这些痛点，我们探索了去中心化的RN架构，并结合该模型自研了系统（CodePushPlatform，简称CPP）和客户端SDK，覆盖了多团队的开发、构建、发布、运行等一系列RN研发周期。经过近三年的迭代，现已接入多款公司级核心App。

Shopee商家服务前端团队打造了多款商家端应用，大部分用户是商家服务人员，他们对业务系统高可用和问题及时反馈有着很高的要求，从而也推动我们对ReactNative的架构有了更高的要求。

本文会从发展历史、架构模型、系统设计、迁移方案四个方向逐一介绍我们如何一步步地满足多团队在复杂业务中的开发需求。

2.发展历程

随着业务高速发展，我们的RNbundle个数飞速增加，App个数也达到近十个。整个RN项目在开发模型、部署模型和架构模型三个维度都发生了变化，从单团队发展成多团队，从一个bundle发展成多个bundle，从中心化架构发展成为去中心化，最终发展成为每个团队的业务代码可以独立地开发、部署、运行。

整个发展历史分为4个阶段，分别是单bundle集中开发模式、单bundle多业务组开发模式、多bundle中心化发布模式、多bundle去中心化发布模式。

2.1第一阶段：单bundle集中开发模式

最初的RN整体技术架构相对简单。由于当时业务形态不算复杂，为了满足独立团队在同一个代码仓库当中的开发流程，整个发布流程是基于CDN的更新发布，并且使用配置文件记录RNbundle文件的版本以及下载地址，以此进行资源管理。整个发布的产物有两个，一个是RN资源包，一个是用于资源版本管理的JSON配置文件。

每次RN资源在完成构建后，这两种构建产物会被放置在静态资源目录下。App在特定的时间节点（例如App重启等）会自动拉取配置文件检查资源更新状态，然后再从CDN拉取RN静态资源。在下一次打开页面的时候，App会加载最新的页面内容。

随着业务发展，越来越多业务团队期望使用RN技术栈开发业务，这种情况让已有架构发生改变，我们自然地产生了多个业务组多个代码仓库的想法。

2.2第二阶段：单bundle多业务组开发模式

针对上述问题，多业务组的研发解决方案是host-plugin这种模式。

host用于管理公共依赖和通用逻辑，它将React、ReactNative、ShopeeRNSDK等通过一个独立的仓库管理起来，保证了特殊RN依赖的singleton（单例模式）条件，避免了部分客户端组件的重叠依赖，而这种重叠依赖是RN官方不允许的。

一个host对应着多个plugin仓库，业务代码仓库则是被看作为一个插件（plugin），以插件的形式接入主应用当中。业务团队可以按自己的编码规范来管理这个仓库。每个插件仓库会被视为host项目的npm依赖，它的构建是一个集中发布的流程。所有代码都会集成在host项目当中执行构建脚本。这种模式满足超级App的要求。

与此同时，host-plugin的模式也带来了一个难题，业务发展使得RN产物体积逐渐变大，过大的产物会影响客户端的解压效率和RN容器加载JS时长。

2.3第三阶段：多bundle中心化架构模式

针对RN产物体