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

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 申请受权。