关于美团:美团外卖终端容器无关化研发框架

2019年9月，美团外卖技术团队联结多个研发部门正式推出了React2X，面向所有的前端研发人员，特地是按业务畛域划分的团队，为大家提供一个残缺的、凋谢的多终端容器无关化（Containerless）研发框架。研发同学能够通过React2X框架疾速创立、开发、构建、部署我的项目，在人力耗费最小的前提下，以期在不同终端上达到绝对最佳的性能体验，并且能大幅升高因容器降级带来的替换和革新老本，让代码同构的复用率最大化。

终端容器无关化（Containerless）：与服务无关化（Serverless）的概念相似，即在放弃顶层业务研发语言不变更的状况下，在上层能够兼容性地降级、替换终端容器的能力，让用户无需关怀终端容器的运维，只有将精力聚焦到业务逻辑上的技术。

一、前言

React2X是一款面向多终端、跨平台、容器无关化研发框架。在整个美团前端技术栈日益标准的趋势下，React技术栈在咱们技术体系环节中的位置变得越来越重要。在广告、营销这些推广属性的业务上，在各个终端（包含美团App、美团外卖App、公众点评App，以及站外的微信小程序、百度小程序、头条&抖音小程序等其余终端）实现“一次开发，同步需要上线”的业务诉求也变得越来越多。在这样的背景下，咱们定义了React2X利用的外围场景：

• 面对美团外部丰盛多样的技术容器体系（Mach、MRN、Titans、MTFlutter、MMP等），如何保障跨容器开发体验的一致性，以及建设跨容器利用开发的生态能力，是咱们须要解决的问题。
• 公司内丰盛的终端容器化技术蓬勃发展，而因业务降级带来的革新老本也比拟大，亟待一款高扩展性设计的顶层框架作为技术抓手。
• 跨容器动态化能力笼罩，逐渐成为各个业务方越来越器重的根底能力，能够大幅缩短需要交付的周期，进步上线发版的效率，并能无效地解决包体积大小的问题，晋升业务的敏捷性。
• 多场景下的同构诉求，例如在各种推广页、模块化、游戏、轻量布局差别的PC/App同构场景下，能够节俭多端研发的人力。

最终咱们的外围痛点围绕在了美团系·小程序和美团系·App矩阵上的同一个需要的屡次开发运维上，为了解决研发人力瓶颈问题，咱们须要一款“一次研发，多终端容器复用”的研发框架来晋升研发效率。

调研整个前端畛域，咱们找到了一些业界的解决方案，像是美团最早的mpvue、腾讯的Wepy、滴滴的Chameleon、京东的Taro等等。在通过比拟与试用之后，咱们最终基于投入产出比的价值判断，抉择站在伟人的肩膀上研发定制一款满足美团技术、业务场景的研发框架——React2X（前面简称R2X）。从R2X第一个版本公布到当初，曾经承受了来自于公司各个业务两年多的考验。所以咱们心愿通过本文帮忙大家对R2X有一个大抵的理解。

二、指标与场景

2.1 外围指标

为了解决业务需要在多端容器须要反复开发的难题，通过代码复用实现开发提效，咱们确定了以下的指标：

• 解决公司外部多终端容器开发痛点：实现Webview容器、小程序容器、MRN容器、Mach容器、游戏容器、局部经营推广场景PC容器的代码同构复用，对立开发标准，抹平开发差别，并提供对其余容器的扩大能力。
• 建设跨容器动态化能力：跨容器动态化能力的缺失，导致产品不可能通过疾速迭代来验证需要的成果，这个问题重大限度了业务的倒退。跨容器动态化能力能够解决美团外卖业务端上发版和包体的问题，帮忙业务实现疾速发版上线、线上问题热修复、以及容灾的能力。
• 建设容器无关的开发生态体系：R2X最终要解决的是容器差异性，进行对立的技术生态能力建设，为多终端容器开发场景晋升生产和运维效率。

2.2 利用场景

R2X开发框架次要冀望能最终面向多终端利用的终端容器，用于场景化研发：

即：

• 业务我的项目基于React语法为技术框架根底。
• 业务方有在多终端/多容器（包含MRN容器、Webview容器、MP容器、Flutter容器、Mach容器、PC浏览器容器）运行的需要。
• 业务方有特定的场景化诉求，包含推广页、模块化、小游戏、PC/App同构等等。

三、挑战与劣势

3.1 业界调研

针对上述外围指标和利用场景，咱们对市面上的跨容器框架进行了调研。因为美团外卖的技术栈对立是React为主，所以咱们的必备要求是：一款以React为DSL语言的复用框架，能疾速融入美团的技术生态。

依据下表的比照，如果以React为DSL语言登程，过后就只有Taro一家能满足咱们的业务诉求，但它的生态环境并不适宜在美团体系内应用。基于多方面因素的思考，咱们决定联合各大支流框架之所长，而后开发出一款属于美团外卖的跨容器复用框架。

注：后期调研工夫截止到2019年05月，可能与以后数据存在肯定的出入。

3.2 技术挑战

当咱们决定要打造一款属于美团外卖的跨容器复用框架之后，在实现的过程中次要遇到了以下挑战：

① 各个容器之间差异性适配老本

• 语法语义：MRN/小程序/Webview在DSL上就有着齐全不同的语法语义。
• 端能力：同一容器在不同端上体现也存在不少差别，比方外卖App中MRN容器和美团App中MRN容器别离有定制的Native模块以及各类桥协定等。

② 业务接入的应用老本

• 首次老本：作为一个新定义的框架如何让新业务方疾速上手，如何从存量业务线进行迁徙。
• 边际老本：如何交融美团的基建生态，让业务方疾速复用平台能力。

③ 顶层架构的正当设计

• 高可维护性、高度扩展性：如何疾速降级、替换、新增一款底层容器。

注：以上问题咱们会在下文“技术全景”章节中给予解答。

3.3 我的项目劣势

3.3.1 性能特点比照

目前，业界以小程序作为跨端指标平台的框架较多，但大多都是应用Web前端技术栈作为根底，但同时兼顾React Native的技术栈就比拟少。下表中列出的是反对以React、类React作为DSL的相干框架进行比照。

综上所述，从目前的业务状态来看，R2X在容器的匹配水平以及美团生态反对水平上看，是现阶段的最佳计划。R2X相较于业界其余框架来说，领有更加欠缺的实用于美团外卖团队的本地化实现。

3.3.2 性能数据比照

基于业界跨平台框架和美团外部的跨平台框架，咱们针对性能也进行了Benchmark测试，最终比照后果如下。

小程序性能比照

论断：能够看到，在小程序Benchmark测试后果中，R2X-MP是当先于Remax和Taro-MP。

与React Native性能比照

论断：在React Native的Benchmark测试后果中，R2X-MRN和MRN根本持平，但都低于纯React Native的性能体现。

3.3.3 同构场景比照

除了反对了根本的React Native、小程序和Webview容器同构场景之外，R2X还实现了在MTFlutter、Mach、小游戏（Webview游戏、微信小游戏&小程序、美团小游戏）、PC浏览器等容器上的同构能力扩大，相比于业内的其余跨容器开发框架的生态也更加丰盛和健全。

四、技术全景

上图为R2X的架构全景图，整体架构能够依照从下到上，从左到右的视角进行解读：

• 最上层是R2X的生态环境建设，在R2X外部去实现公司生态的罕用SDK以及业务中的各项专题能力；并通过搭建物料市场/插件市场，以业务共建的模式丰盛R2X生态。
• 再下层是R2XCore的根基，通过解析Command命令来执行唤起构建器，并实现了相似Webpack的插件零碎，以插件化的模式组织驱动整个外围构建流程，便于保护以及扩大。
• 再往上是跨端容器层，它是整个跨端能力的外围，通过实现了不同的容器插件来将R2X代码编译成各端可执行代码，并通过运行时能力对组件/API进行对齐。
• 最上层是承载的App端，目前有美团外卖、公众点评、美团等多款挪动App终端。
• 最左边是R2X在研发、公布、运维以及用户文档上做的一些建设。

因为R2X笼罩了美团外部大部分的支流容器场景，所以技术体系较为简单和宏大，大家能够依据本身的业务状态，选择性地去理解对应场景的同构计划。

4.1 底层根底框架

4.1.1 R2X-CLI的设计

CLI作为R2X我的项目驱动器，它不仅蕴含了命令行的启动，更重要的，它是各个编译构建的外围。

在晚期，CLI执行build命令时，咱们通过--type来辨别不同的构建容器，从而加载不同的编译逻辑。通过指定构建容器的模式来实现同一套代码可能构建出不同的容器产物。但通过长时间的业务迭代，咱们发现了这种构造存在的问题：

• 整体流程简短且简单，长时间迭代会变得越来越难以保护。
• 每个容器的构建流程互相独立，且构建逻辑各不统一，有多处反复的逻辑解决。
• 编译流程短少对立的要害节点，编译时无奈进行业务方的定制扩大。

针对以上问题，咱们思考对CLI进行了一次全新的重构，引入插件化能力（对于插件化能力的具体实现会在下文详细描述）。CLI整体构造变成如下图所示：

整个CLI模块只须要关怀参数的解析以及插件的加载执行，不须要再实现各个容器的具体编译逻辑。通过Hooks的模式，将编译的各个机会裸露给插件，插件基于这些Hook进行编译能力的实现，最终输入产物给CLI模块。这种模式带来了以下几个益处：

• CLI构造变得清晰，只须要保护配置解析、插件解析等性能。
• 扩展性加强，可通过插件化的模式新增或删减容器/编译能力，保障代码独立保护性能的单一性。
• 编译流程可梳理，无论什么容器的编译流程都基于编译器裸露的机会执行并串联，整体流程清晰明了。

4.1.2 组件及API的设计

R2X的目标是心愿通过一套代码可能在多端上运行，然而因为多端差别的存在，咱们须要设计一套对立的标准规范来进行对齐。在运行时局部，次要分为组件/接口的对齐。

多端差别

在开始讲述实现之前，咱们先来看看各端之间的差别到底在哪些地方。

组件（标签）差别

• Webview标签采纳的是XML写法，所提供的根底标签有\<div/\>\<a/\>等等。
• 小程序采纳的是WXML（WeiXin Markup Language）标签语言，也提供了一套残缺的根底标签，然而和Webview有着较大的差别。
• React Native则是采纳的JSX（JS-XML）语法，尽管和XML很靠近，然而又有着很多的不同点，同时它也有本人的一套根底组件，和Webview、小程序又截然不同。

API差别

• 接口差别：在不同端中都提供了雷同或近似的性能，然而其实现形式以及调用参数可能存在着很大的差别，比方数据缓存Storage，小程序中用wx.setStorage/wx.setStorageSync，Webview则用localStorage.setItem，而MRN中AsyncStorage.setItem，简直每一个性能点都有着多多少少的差别。
• 容器差别：各个端所提供的API都是各自的容器量身打造的，比方小程序的各业务接口类 API，齐全是针对小程序所处的微信环境打造的，这类性能与其余端并不相干。
• 能力差异：各个端之间的差别咱们能够通过定制的伎俩来适配，然而并不是所有的性能点在各个端上都可能实现。比方在Webview中就无奈做到像小程序、React Native中提供很多原生能力，像是文件保留读取等等，这一类差异性在适配过程中都属于不可抗拒、不可抹平的差别。

款式差别

小程序的WXSS和Webview的CSS在参数属性上其实是简直统一的，然而在层级关系上有着很大的差异，小程序分为全局款式与部分款式，各个组件之间的款式也是不会相互影响（默认配置下）。而比照React Native采纳的StyleSheet，是用Inline Style的形式，不反对全局款式，不反对标签款式，并且属性有诸多限度，如只能应用Flex布局等等。

如何适配

从以上章节咱们曾经理解到了各个端之间有着十分大的差别点，那咱们应该如何克服这些艰难呢？

因为各端对组件和API的反对水平不同，咱们选定了一端为根底规范，定义好各个组件的属性以及接口参数，通过TypeScript的Interface进行实现。而后在各个端别离基于以上的接口进行性能对齐实现，对于端能力限度的性能进行了肯定取舍，对高优性能进行了SDK底层实现适配。最终，咱们基于已有的性能封装实现了一套残缺的根底组件@r2x/components和根底API@r2x/r2x。

4.1.3 开放式插件能力

随着R2X的在美团外部的利用越来越多，大家对于R2X模式的认可度也在一直进步，咱们从业务方中常常听到以下这些问题：“是否能够减少反对某某性能/容器”，“咱们业务架构比拟非凡，是否做出一些调整”。业务方对R2X会有更多功能/容器的诉求，也会有更多定制化的需要呈现。

所以，咱们决定实现一套残缺的开放式插件能力，提供一种绝对比较简单的形式，让大家可能本人来定制这些非凡需要。在最新的版本中，咱们将R2X的编译时进行了重构，在新的编译时架构中引入了基于Tapable的插件零碎。开发者能够通过编写插件的形式为R2X拓展更多功能，或者为本身业务线定制更多的个性化性能。

在插件类型分为两类：

• 容器插件，用于封装R2X所反对的容器的外围编译能力。
• 性能插件，基于已有的容器插件，在此基础上进行某种特定性能的自定义实现。

插件能力的整体架构如下：

借助开发式插件能力，咱们将之前编写了若干个平台容器插件，开发者装置后即可应用：

• 小程序容器插件：@r2x/plugin-container-wxapp。
• MRN容器插件：@r2x/plugin-container-mrn。
• Titans容器插件：@r2x/plugin-container-h5。

除了扩大新的容器平台，咱们还能够通过继承现有的容器插件，来编写一些非凡的定制化性能插件。

1. 对代码进行预处理

基于开放式插件能力，咱们能够像Babel插件一样，通过对AST语法的批改对代码源文件进行编译前后的批改。比方：批改文件援用门路、插入代码片段、解决本地图片等等。

2. 对文件产物进行批改

在编译产出生成时，咱们能够对编译文件的内容、文件门路、文件构造进行批改。联合本身业务的定制化，CLI能够将R2X我的项目和现有的原生我的项目进行联合革新。

除了以上性能，插件化能力为用户在编译时提供了极大的自由度。如果你想体验的话，欢送退出美团外卖技术团队。

4.1.4 个性能力-多态能力

为什么须要多态能力？

多态能力是用于提供跨端时各端组件及API的对立解决方案。基于多态能力，开发者能够定制本人的跨端组件。而R2X具备了欠缺的跨端能力，可能笼罩多终端和容器，为什么还须要多态？

业务研发为了满足各自场景的要求须要肯定的灵活性。同时，Webview/小程序/React Native容器存在端上的差别，须要开发者人为进行环境判断。逻辑一简单、跨端数量一多，代码可读性变低、保护老本腾飞，这不是咱们的本意。

基于这样的背景，R2X提供了扩展性良好的多态能力。

R2X多态能力介绍

对于多态能力的反对，咱们分为两类：

• 多态组件/API，R2X依据文件后缀辨别编译指标端。

• 差异化代码，R2X提供getEnv环境办法用于判断以后语句编译指标端类型。

<View style={{color: R2X.getEnv() === "WEAPP" ? "green" : "blue" }} />

通过差异化代码可轻松满足端差别诉求。

4.2 利用场景同构

4.2.1 页面级容器场景同构

页面级容器场景同构咱们借鉴了业内Taro1.x、Rax等优良跨端框架的做法，联合美团外部容器、基建特点做了很多本地化实现和定制，在Webview、MRN、小程序三种容器上通过不同的编译时计划进行预处理，并且引入了React运行时，保障了对React DSL反对的残缺水平和代码同构率，编译时转化流程计划和运行时构造如下图所示：

R2X2.0相比于R2X1.0，运行时计划可能解决编译时计划带来的语法限度问题：

1. 不能在蕴含JSX元素的map循环中应用if表达式 ✅
2. 不能应用Array#map之外的办法操作JSX数组 ✅
3. 不能在JSX参数中应用匿名函数 ✅
4. 暂不反对在render()之外的办法定义JSX ✅
5. 不容许在JSX 参数(props)中传入JSX元素 ✅
6. 不能在JSX参数中应用对象开展符 ✅

同时也反对大部分React第三方生态库，目前已反对应用原生react-redux。彻底抹平各端的差别，无论是MRN、Flutter、小程序、Webview的自定义组件都能够间接当成React组件引入，小程序原生自定义组件也无需配置usingComponents。

4.2.2 模块级容器场景同构

在模块级同构计划上，咱们在App上依赖Mach容器；在小程序容器中，咱们克服了Mach容器渲染机制的束缚（运行时与虚构DOM的应用限度），独自在小程序上设计了Mach容器渲染计划，实现了R2X-模块化（R2X-Module）在客户端和小程序上99%以上的代码同构率。

整体计划

1. 外围驱动包，容器驱动的外围，针对渲染能力、解析能力、缓存能力、性能监控四个方面进行了实现，达到动态化驱动成果。
2. 业务容器自定义，基于SDK提供的驱动能力，针对不同展位个性进行了容器自定义性能扩大配置，让业务方可依据理论业务场景自行扩大。
3. 分环境构建，次要实现了将类React语法进行AST编译解析，依据构建平台别离编译成对应的Bundle产物。
4. 自动化构建部署，将构建能力接入Talos（美团外部自研的构建部署工具），再联合低代码业务工具实现一键部署，将编译产物依据配置项上传至DD（美团外部自研挪动端动静下发平台）。

模板驱动计划

目前，R2X-Module在客户端和小程序容器的同构率在99.3%以上，在性能方面首次渲染时长和模板渲染时长的TP50工夫别离是185ms和144ms，比拟优良但还存在优化空间。同时提供R2X-Module SDK供业务方抉择。R2X-Module SDK初始化以及模板加载渲染流程如下图所示：

4.2.3 PC/App适配同构

在挪动互联网倒退曾经高度成熟的明天，挪动端的PV流量占比绝大数，以外卖广告商家端为例，PC端仅仅占有很少比例，其中PC流量占比在咱们局部业务上曾经不迭5%。因而在某些场景下实现PC/App的同构计划可能解放一部分人力，对进步开发效率来说是十分必要的。目前，外卖广告商家端的一些轻量布局差别的页面，曾经实现了PC/App同构的方案设计和落地。

款式同构适配

端能力扩大

R2X的根底能力反对Webview/MRN/小程序三端，短少对PC微前端子项目的反对。要实现PC/APP多端同构须要对R2X的端能力进行扩大。PC端实质上也属于Web端，因而PC微前端的端能力扩大能够复用大部分的Webview的端能力。整体架构图、技术设计要点、扩大流程图如下所示：

平台代码解决

在我的项目同构开发中，不可避免地会呈现跟平台强相干的代码或者业务逻辑，比方某些API调用的是App的底层能力，只能在React Native中应用，在Web端必定是不反对的。或者因为产品需要的起因，某些交互或者展现差别较大等等。而我的项目针对某一端进行编译、打包时，其余不相干的端代码是无用、多余的，如果保留的话，不仅会减少代码体积，甚至会呈现编译报错，因而咱们须要借助平台代码解决的能力来进行优化。平台代码的解决次要蕴含三局部：模块导入、组件展现、业务逻辑。

次要思路是应用正文和指定平台的形式，让特定的平台代码只在特定平台失效，正文关键字%%platform%%，比方%%RN%%示意React Native端独有，%%MICRO%%示意PC微前端独有，%%MICRO|Webview%%示意PC微前端、Webview 两端失效。示例代码如下：

import A from '@r2x/r2x-a'; // %%RN%%只在React Native端保留。import B from '@r2x/r2x-b'; // %%MICRO%% 只在MICRO端保留。import C from  '@/utils/c'; // 这是所有端失效的公共模块。import D from '@r2x/r2x-d'; // %%MICRO|Webview%%在MICRO、Webview多端失效的模块。

4.2.4 小游戏容器场景同构

实现react2x-game同构计划次要做的两点：渲染层的兼容、业务层的兼容。

1. 渲染层的兼容：实现游戏引擎在多端环境下渲染能力的兼容（Canvas、WebGL）。
2. 业务层的兼容：实现根底API、我的项目流程、公共模块的兼容，制订游戏差别的个性化定制标准。

渲染层兼容

在上文，咱们提到过“无论是Webview游戏、小程序、小游戏、美团小游戏都为咱们提供了Canvas、WebGL控件”，很大水平地升高了咱们兼容渲染层的复杂度。上面表单，是各端对于语法以及Canvas、WebGL、Document、Window等根底性能的反对状况：

能够看出，在语法层面各端都反对了JavaScript语法，然而在执行环境以及根底性能上的差别比拟大，总结来说：

执行环境：小游戏、小程序不具备DOM、BOM的能力（渲染引擎中会大量应用）。
根底性能：小程序不反对离屏Canvas，在2.11.0版本当前才开始反对WebGL。

为了解决这些问题，咱们设计开发了adaptor层，用来模仿document、window的能力。使游戏引擎能够在非Webview的环境下失常的执行和调用BOM、DOM的根底性能。同时，制订离屏canvas的适配计划，用来解决小程序无奈反对离屏canvas的问题。为了获取到无效离屏canvas，咱们制作了 “r2x-add-wxml-loader” ，在.wxml文件的loader阶段主动注入额定的<canvas/>控件，并暗藏于手机屏幕之外，用于模拟游戏引擎中的离屏canvas。

多端兼容构建

在构建层面，咱们通过集成的多种个性化插件工具，对多端代码进行差别解决。如：环境变量注入、各端适配代码的混入、标准检测、代码解析和转化等。针对小游戏、小程序代码和执行环境的特殊性，制作wx-build-plugin、lwxapp-build-plugin等用于解决小游戏和小程序的打包工作。联合上文中提到的各类差别的解决计划，制作add-wxml-loader、transfrom-loader、wxss-loader等工具帮助实现我的项目构建。如下图14所示，构建之初会注入本次构建的环境变量，读取和剖析配置文件，集成和初始化构建工具汇合，为我的项目构建做筹备。而后在构建环节，针对各端的差别进行差异解决，剖析层针对不同文件进行解析，并在转换层进行转换和构建，最终生成各端须要的最终产物。

4.3 落地场景与成果

成果收益

R2X在美团外卖业务中失去了宽泛的利用。截止2021年10月，R2X累计在美团外部已有二十多个部门在应用或者在调研中，总计落地了上百个工程、页面，框架下载量达百万次，页面均匀代码同构率达90%以上。R2X生态体系在容器代码复用与运维层面，累计为美团节省成本上千人/日，并晋升动态化页面转化5%-8%的成功率。

五、瞻望与总结

综上所述，在美团外卖多元化业务状态和容器多样性的状况下，跨容器复用成为了倒退的必经之路。而R2X在经验了两年的迭代下也获得了阶段性的成绩，在美团各个业务场景都实现了业务的落地笼罩，针对公司的生态环境接入也做出了不少的根底建设。咱们置信跨容器多端代码复用仍旧是以后缩减我的项目交付周期，缩小研发老本，晋升研发效率的重要一环。但目前咱们在很多简单的业务场景下做的不够完满，因而还有许多工作待欠缺，例如：

• 开发体验优化，目前想接入或正在接入的兄弟部门曾经越来越多，如何缩小接入老本，丰盛根底建设，优化开发体验，帮忙大家疾速迁徙接入，将是下一阶段的重要课题。
• 渲染性能优化，在美团外卖场景下性能优化始终是咱们在兼顾高效生产的另一个重要指标。特地在小程序场景下，低端机型的性能体验始终是业界瓶颈，如何冲破这一难关将会是同构计划全面推广的“敲门砖”。

最初，感激各个相干研发团队对R2X建设过程中的鼎力支持，R2X的倒退离不开所有参与者日以继夜的投入和奉献，咱们会继续基于R2X在终端容器畛域进行更多摸索。如果大家感觉R2X还不错，或者对美团的R2X框架比拟感兴趣，欢送跟咱们一起交换探讨。

作者简介

正浩、宝石、彭震，均为美团外卖终端团队研发工程师。

招聘信息

美团外卖长期招聘Android、iOS、FE、Java高级/资深工程师和技术专家，欢送有趣味的同学投递简历到lizhenghao@meituan.com。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至tech@meituan.com申请受权。