React Native在美团外卖客户端的实践，带你全面理解View的绘制流程

背景

---

美团外卖自2013年创建以来，一直处于高速发展期。美团外卖所承载的业务，也从单一的餐饮业务，发展到餐饮、超市、生鲜、果蔬、药品、鲜花、蛋糕、跑腿等十多个大品类业务。伴随着业务的快速发展，我们深切地感受到3个痛点：

（1）业务要求快速发版试错和原生迭代周期长

美团外卖业务长期使用H5+Native的技术栈。由于原生应用需要依托于应用市场进行更新，这样的话，每次产品的更新必须依赖用户的主动更新，使得版本的迭代周期变得很长，无法实现快速发版快速试错的诉求。H5虽然具备随时发布的能力，但受限于内核的影响，平台兼容性并不好，性能也较差，而且调用Native的能力也受限，往往只能满足一定范围内的产品需求。

（2）有限的客户端研发资源无法满足日益增长的业务

业务的快速发展对客户端的开发效率不断提出挑战。如何通过技术手段，在有限的客户端人力资源下，支持更多的业务需求，解决有限的研发资源跟不断变大的业务需求量之间的矛盾呢？试想，如果能逐渐地磨平Android和iOS开发技术栈带来的问题，支持一套代码在2个平台上线，理论上人效可以提升一倍，支持的业务需求也可以提升一倍。

（3）业务持续增长带来的安装包的大幅增长

业务的快速迭代，功能的持续增加，美团外卖客户端安装包也在持续增加，从2018年到2019年，已经累计增长140%。如果没有切实有效的技术手段，安装包将变得越发臃肿。 业务层面的这些痛点，也在不断地督促我们去反思：到底有没有一种框架可以解决这些问题。2015年，Facebook发布了非常具有颠覆性的React Native（简称RN）框架。从名字上就可以看出，这属于一种混合式开发的模式。RN使用Native来渲染，JS来编码，从而实现了跨平台开发、快速编译、快速发布、高效渲染和布局。作为一种跨平台的移动应用开发框架，RN的特性非常符合我们的诉求。我们也在一直积极地探索RN相关的技术，并且基于RN在脚手架、组件库、预加载、分包构建、发布运维等多个维度进行了全面的定制及优化，大幅提升了RN的开发及发布运维效率，还打造了更适应于美团的MRN技术体系。从2018年开始，美团外卖客户端团队开始尝试使用MRN框架来解决业务层面的一系列问题。经过一年多的实践，我们积累了一些经验和结论，希望相关的经验和结论能够帮助到更多的个人或技术团队。

外卖混合式架构

---

上图是外卖App引入MRN后的架构全景图，接下来我们会从下到上、从左到右逐步介绍：

• 最下层是Android/iOS系统服务层，因为MRN是跨端的，所以需要引入这一层。相对单一平台来说，由于MRN的引入，整个App的架构不可避免地需要考虑Android和iOS平台本身的差异性。

• 倒数第二层是平台服务层，这一层相对与单一平台来说，并没有太大区别。

• 再往上一层是MRN基建层，这一层的工作主要是：（1）尽可能地屏蔽Android和iOS系统的差异性；（2）打通已有的平台基建能力，让上层业务不能感知到差异。

• 再上一层是业务组件层，这一层相对于单一平台来说，区别不大，主要是增加了Android和iOS的RN容器，同时业务组件是可以被RN调用的。

• 继续往上是MRN接口层，该层的主要任务是尽可能地屏蔽Android和iOS组件之间的差异，让上层页面使用的RN接口保持一致。

• 最后是业务层，这一层是用户可直接接触到的页面，页面的实现可以是Android/iOS/RN。

• 左上角是研发支撑，主要包括代码规范、代码检查工具、Debug插件、准入规范、准入检查工具、代码模板插件等。这块相对于单一平台来说，主要的差异体现在：由于编译器和语言不同，使用的工具有所区别，但工具要做的事情基本是一致的。

• 左下角是测试支撑，主要包括UI自动化测试、自测覆盖率检查、AppMock工具、业务自测小助手、性能测试、云测平台等。这块相对于单一平台来说，基本也是一致的，主要的差异同研发支撑，主要是语言不同，使用的工具有所区别。

• 右上角是发布支撑，主要包括打包Bundle和APK、打包检查、发布检查、发布Bundle和APK等。这块相对于单一平台来说，保持了打包发布平台的一致性，区别在于：需在原有的基础上，增加MRN的打包发布环节。

• 右下角是运维支撑，主要包括基建成功率监控、业务成功率监控、线上问题追踪、网络降级等。这块相对于单一平台来说，保持了一致性，区别在于：需在原有的基础上，增加MRN的监控运维。

研发测试支撑

外卖业务MRN组件架构

RN官方对双端只提供了30多个常用组件，与成熟的Native开发相比，天壤之别。所以我们在开发的过程中面临的一个很重要问题就是组件的缺失。于是，MRN团队基于RN组件进行了丰富，引入了一些优秀的开源组件，但是源于外卖业务的特殊性，一方面需要业务定制，另一方面部分组件依然缺失。所以为了减少重复代码，提升外卖客户端MRN的研发效率，建设外卖组件库就变得非常有必要。

上图是我们外卖组件库的架构图，最底层依赖Android和iOS的原生服务；然后是MRN基建层，用于抹平Android和iOS系统之间的差异；再上一层则是外卖组件库及其依赖，如平台组件库和打包服务，组件库分为两类：纯JS组件和包含JS和Native的复合组件。再上一层则是Android和iOS的MRN容器，它提供了上层Bundle的运行环境。整个组件的架构思路，是利用中间层来屏蔽平台的差异，尽可能地使用JS组件，减少对原生组件的依赖。这样可以有效地减少上层业务开发时对平台的理解。接下来，我们主要讲一下WM-RN组件库：