外卖混合式架构

　　上图是外卖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组件，减少对原生组件的依赖。这样可以有效地减少上层业务开发时对平台的理解。