接下来，我们主要讲一下WM-RN组件库：

　　如上图所示，WM-RN组件库主要包含三部分：RN interface、RN Native组件、外卖RN JS组件。RN Interface主要包括Native组件的Bridge部分和Native组件在JS侧的封装，封装一层的好处是方便调用Native暴露出的接口，也可以用来抹平Android和iOS系统间的差异；RN Native组件分为Android和iOS两端，依赖各自的业务模块，为RN提供外卖Native的业务能力，如购物车服务、广告服务；外卖RN JS组件则是纯JS实现，内部兼容外卖App与美团外卖频道间的差异、Android和iOS平台间的差异，依赖现有的MRN组件库和外卖开源Beeshell组件库，减少组件的开发成本；从工程的物理结构来看，建议将Native组件、RN Interface放在一个仓库进行管理，主要是因为Native与JS侧的很多通信都是通过字符串来匹配的，放在一起方便双端与JS侧的接口统一对齐，发布时也会更加方便。目前，外卖组件库已经扩展了几十个业务组件，支持了线上近百个MRN页面。

　　Native/MRN/H5选型标准

　　目前，美团外卖App存在三种技术栈：Native、MRN、H5，面对业务持续增长和安装包不断变大的压力，选择合适的技术栈显得尤为重要。H5在性能和用户体验方面相比Native和基于Native渲染的RN相对弱一些，所以目前大部分H5页面只是用来承载需求变更频繁、需要即时上线的活动页面。那么MRN和Native的界限是什么呢？当有一个新的页面产生时，我们应该如何做取舍？通过实践，我们逐渐摸索了一套选型规则，如下：

　　Native选型规则，强交互（同时存在2种及以上手势操作），无法用二元函数描述的复杂动效，对用户体验要求的页面，类似首页、点菜页、提单页等。

　　对于强交互或强动画，MRN技术栈支持效果不理想，不建议使用。其他情况下，建议使用MRN。

　　H5适用于需要外链展示的轻展示页面，比如向外投放活动的运营页面等等。

　　具体选型细节可参考下表：

　　发布运维支撑

　　发布运维是一个成熟的软件项目中非常核心的部分，它保证了整个项目能够高效且稳定地运转。建立一个稳定可靠的发布运维体系是我们建设整个外卖MRN技术体系的重要目标。但发布运维的建设上下游牵扯了众多基建：拥有一个合理的工程结构对发布运维来说至关重要。如果工程结构臃肿且混乱，将会引起的一系列的权限问题、管理维护问题，这样会严重制约整个发布运维体系的效率。所以MRN的工程架构演进优化也是发布运维体系建设的重要组成部分。

　　MRN分库 & 工程结构演进

　　业务分库

　　任何一个大型、长期的前端技术项目，良好的工程结构都是研发发布支撑中非常核心的部分。从2018年10月份，外卖正式启动MRN项目以来，面临涉及近百个MRN和几十人参与的大规模MRN应用计划。从项目初期，我们就开始寻找一个非常适合开发维护的工程结构。

　　在*开始的时候，我们的目标是快速验证及落地，使用了一个Git库与一个Talos项目（美团自研发布系统）去承接所有页面的开发及发布工作，同时对权限进行了收缩，保证初期阶段的安全发布。然而随着页面的增多，每个版本的发布压力逐渐增大。发布SOP上的三大关键节点权限：Git库操作权限、Talos的发布权限、美团自研的线上降级系统Horn权限，互不相关，负责人也各异，导致发布时常因各个节点的权限审批问题，严重阻塞效率。