Meituan takeaway terminal container-independent R&D framework

In September 2019, the Meituan takeaway technical team and several R&D departments officially launched React2X, which is aimed at all front-end R&D personnel, especially teams divided by business fields, to provide you with a complete and open multi-terminal container-independent (Containerless) R&D framework. R&D students can quickly create, develop, build, and deploy projects through the React2X framework, in order to achieve the best performance experience on different terminals under the premise of minimal labor consumption, and can greatly reduce the replacement and transformation caused by container upgrades. cost to maximize the reuse rate of code isomorphism.

| Containerless : Similar to the concept of serverless, that is, while keeping the top-level business R&D language unchanged, the ability to upgrade and replace terminal containers in the lower layer can be compatible, so that users do not need to Care about the operation and maintenance of terminal containers, as long as you focus on the technology of business logic.

I. Introduction

React2X is a multi-terminal, cross-platform, container-independent R&D framework. Under the trend that the entire Meituan front-end technology stack is becoming more and more standardized, the position of the React technology stack in our technical system is becoming more and more important. In terms of advertising, marketing and other promotional attributes, various terminals (including Meituan App, Meituan Takeaway App, Dianping App, as well as WeChat mini-programs, Baidu mini-programs, Toutiao & Douyin mini-programs and other terminals outside the station ) to achieve "one development, synchronous demand online" business demands have become more and more. In this context, we define the core scenarios of React2X applications:

• In the face of the rich and diverse technical container systems (Mach, MRN, Titans, MTFlutter, MMP, etc.) within Meituan, how to ensure the consistency of cross-container development experience and build the ecological capability of cross-container application development are the problems we need to solve .
• The rich terminal containerization technology in the company is booming, and the transformation cost caused by business upgrade is relatively large. A top-level framework with high scalability design is urgently needed as a technical starting point.
• Cross-container dynamic capability coverage has gradually become a basic capability that various business parties pay more and more attention to. It can greatly shorten the demand delivery cycle, improve the efficiency of online release, and can effectively solve the problem of package size and improve business agility sex .
• Isomorphic demands in multiple scenarios, such as PC/App isomorphic scenarios with various promotion pages, modularization, games, and lightweight layout differences, can save manpower for multi-end R&D.

In the end, our core pain points revolved around the multiple development and operation of the same requirement on the Meituan Department·Mini Programs and the Meituan Department·App matrix. Terminal container reuse " R&D framework to improve R&D efficiency .

Investigating the entire front-end field, we found some industry solutions, such as Meituan's earliest mpvue, Tencent-wepy, Didi-Chameleon, Jingdong-Taro and so on. After comparison and trial, we finally chose to stand on the shoulders of giants to develop and customize a R&D framework - React2X (hereinafter referred to as R2X ) that satisfies Meituan's technology and business scenarios based on the value judgment of the input-output ratio. From the release of the first version of R2X to the present, it has been tested by various businesses of the company for more than two years. So we hope to help you have a general understanding of R2X through this article.

2. Goals and Scenarios

2.1 Core Objectives

In order to solve the problem that business requirements need to be repeatedly developed in multi-terminal containers, and to improve development efficiency through code reuse, we have determined the following goals:

• Solve the pain points of multi-terminal container development within the company : realize the code isomorphic reuse of Webview container, applet container, MRN container, Mach container, game container, and PC container in some operation and promotion scenarios, unify development specifications, smooth development differences, and provide Extensibility to other containers.
• Build cross-container dynamic capabilities : The lack of cross-container dynamic capabilities results in the inability of products to verify the effect of requirements through rapid iteration. This problem severely limits business development. The cross-container dynamization capability can solve the problem of version restrictions and excessive package size on the Meituan food delivery business side, and help the business to achieve rapid version release, hot repair of online problems, and disaster recovery capabilities.
• Build a container-independent development ecosystem : R2X ultimately needs to resolve container differences, build unified technical ecological capabilities, and improve production and operation and maintenance efficiency for multi-terminal container development scenarios.

2.2 Application scenarios

The R2X development framework mainly expects terminal containers that can eventually be oriented to multi-terminal applications for scenario-based research and development:

which is:

• The business project is based on the React syntax as the technical framework foundation.
• The business side needs to run in multiple terminals/containers (including MRN container, Webview container, MP container, Flutter container, Mach container, PC browser container).
• The business side has specific scenario demands, including promotion pages, modularization, mini-games, PC/App isomorphism, etc.

3. Challenges and advantages

3.1 Industry research

In view of the above core goals and application scenarios, we conducted a survey on the cross-container frameworks on the market. Since the unification of Meituan's technology stack is based on React, our essential requirements are: a reuse framework with React as a DSL language that can quickly integrate into Meituan's technology ecosystem.

According to the comparison in the table below, if we started with React as the DSL language, only the Taro family could meet our business demands at that time, but its ecological environment was not suitable for use in the Meituan system. Based on various factors, we decided to combine the strengths of major mainstream frameworks, and then develop a cross-container reuse framework that belongs to Meituan Takeaway.

Contrast	mpvue	Taro 1.3	Chameleon	WePY	UniApp
DSL	vue	class React (Nerv)	class Vue	vue	vue
Whether to support React Native	no	Yes, but poor support	Weex	no	no
Compatible API	none	Yes (API support varies)	Self-developed polymorphic protocol	none	Yes
Cross-end component library	none	Have	Have	none	none
Meituan Ecology	Have	none	none	none	none
syntax check	none	ESLint	Self-study	none	Have
TypeScript	Have	Have	none	Have	Have
custom extension	none	Self-developed Plugin	none	none	Have
Compile the extension	none	none	none	none	Have
Research conclusion	Mismatch	Partially satisfied	Partially satisfied	Mismatch	Mismatch

Note: The preliminary research time is as of May 2019, and there may be some discrepancies with the current data.

3.2 Technical challenges

When we decided to build a cross-container reuse framework belonging to Meituan, we encountered the following challenges in the implementation process:

① Differential adaptation costs between containers

• Syntax and semantics: MRN/Applet/Webview has completely different syntax and semantics on DSL.
• End-to-end capabilities: There are also many differences in the performance of the same container on different ends. For example, the MRN container in the takeaway app and the MRN container in the Meituan app have customized Native modules and various bridge protocols.

② The use cost of service access

• First cost: As a newly defined framework, how can new business parties get started quickly and how to migrate from existing business lines.
• Marginal cost: How to integrate Meituan's infrastructure ecosystem to allow business parties to quickly reuse platform capabilities.

③ Reasonable design of top-level architecture

• High maintainability and scalability: how to quickly upgrade, replace, and add an underlying container.

Note: We will answer the above questions in the introduction to the technical panorama chapter.

3.3 Project Advantages

3.3.1 Comparison of functional characteristics

At present, there are many frameworks in the industry that use small programs as cross-end target platforms, but most of them use the web front-end technology stack as the foundation, but there are fewer technology stacks that take into account React Native. The following table lists the related frameworks that support React and React-like DSLs for comparison.

	R2X	Taro 1.3	Taro 3.0	Rax	Remax
principle	R2X 1.0 recompile, R2X 2.0 rerun	When recompiling	rerun time	rerun time	rerun time
container focus	Mainly MRN, applet, WebView, and support MTFlutter, Mach, games, PC browsers	Mainly focus on small programs and Web, React Native does not support much	Focusing on small programs and web, React Native is handed over to the 58 team for support	Applets, Web, Flutter	applet, web
API	Support KNB bridge & unify multi-platform API	Unified multi-platform API	Unified multi-platform API	Not unified across multiple platforms	Not unified across multiple platforms
Cross-end component library	Have	Has TaroUI, but doesn't support React Native	Has TaroUI, but doesn't support React Native	none	none
business component extension	Provide expansion options	Refer to TaroUI	Refer to TaroUI	Provide expansion options	Provide expansion options
Meituan internal ecological support	Buried point monitoring, etc. have been supported	none	none	none	none
Modularity	support	not support	not support	not support	not support
Compile plugin extension	support	not support	support	support	Support webpack configuration

To sum up, from the perspective of the current business form, R2X is the best solution at this stage in terms of the matching degree of containers and the degree of ecological support of Meituan. Compared with other frameworks in the industry, R2X has a more complete localization implementation suitable for Meituan food delivery teams.

3.3.2 Comparison of performance data

Based on the industry cross-platform framework and Meituan's internal cross-platform framework, we also conducted benchmark tests for performance, and the final comparison results are as follows.

applet performance comparison

frame	create	renew	Add to	exchange	delete
R2X-MP	947.6	586.8	1467.2	1355.2	82.2
Remax	2798.2	1872.6	5162.2	4818.2	86.4
Taro-MP	1653.4	976.4	2483.2	2256.6	65.2

Conclusion : It can be seen that in the Benchmark test results of the applet, R2X-MP is ahead of Remax and Taro-MP.

Performance comparison with React Native

frame	create	renew	Add to	exchange	delete
R2X-MRN	309.875	83.75	384	191.875	82.125
MRN	297.625	105.25	400.125	231.625	65.875
Taro-RN	209.5	77.5	246.25	85.125	17.125

Conclusion : In the Benchmark test results of React Native, R2X-MRN and MRN are basically the same, but both are lower than the performance of pure React Native.

3.3.3 Comparison of isomorphic scenarios

In addition to supporting the basic React Native, applet and Webview container isomorphic scenarios, R2X also implements functions in MTFlutter, Mach, mini games (Webview games, WeChat mini games & mini programs, Meituan mini games), PC browsers Compared with other cross-container development frameworks in the industry, the ecosystem of other cross-container development frameworks is also richer and more robust.

	React Native	Applets	Webview	Flutter	module-level container	small game container	PC browser (PC/App isomorphism)
R2X	support	support	support	support	support	support	support
Taro	support	support	support	not support	not support	not support	not support
Rax	support	support	support	not support	not support	not support	not support
Remax	support	support	support	not support	not support	not support	not support

4. Technical Panorama

The above picture is the architecture panorama of R2X. The overall architecture can be interpreted from bottom to top and left to right:

• The bottom layer is R2X's ecological environment construction. R2X is used to realize common SDKs of the company's ecology and various thematic capabilities in the business; and by building a material market/plug-in market, the R2X ecosystem is enriched in the form of business co-construction.
• The upper layer is the foundation of R2XCore, which executes the evoked builder by parsing the Command command, and implements a plug-in system similar to Webpack, which organizes and drives the entire core construction process in a plug-in form, which is convenient for maintenance and expansion.
• Further up is the cross-end container layer, which is the core of the entire cross-end capability. It implements different container plug-ins to compile R2X code into executable code on each end, and aligns components/APIs through runtime capabilities.
• The top layer is the app terminal that is carried. Currently, there are a variety of mobile app terminals such as Meituan Takeaway, Dianping, and Meituan.
• On the far right are some constructions that R2X has done in R&D, release, operation and maintenance, and user documentation.

Because R2X covers most of the mainstream container scenarios within Meituan, the technical system is relatively complex and huge. You can selectively understand the isomorphic solutions for the corresponding scenarios according to your own business form.

4.1 The underlying basic framework

4.1.1 Design of R2X-CLI

As the R2X project driver, CLI not only includes command line startup, but more importantly, it is the core of each compilation and build.

In the early days, when the CLI executed the build command, we used --type to distinguish different build containers, thereby loading different compilation logic. By specifying the form of the build container to achieve the same set of code can build different container products. But after a long period of business iteration, we found problems with this structure:

• The overall process is long and complex, and long iterations will become increasingly difficult to maintain.
• The construction process of each container is independent of each other, and the construction logic is inconsistent, and there are many repeated logic processing.
• The compilation process lacks a unified key node, and customization and expansion of the business side cannot be performed during compilation.

In response to the above problems, we consider a new refactoring of the CLI to introduce plug-in capabilities (the specific implementation of plug-in capabilities will be described in detail below). The overall structure of the CLI becomes as shown in the following figure:

The entire CLI module only needs to care about the parsing of parameters and the loading and execution of plugins, and does not need to implement the specific compilation logic of each container. In the form of Hooks, each time of compilation is exposed to the plug-in. The plug-in implements the compilation ability based on these Hooks, and finally outputs the product to the CLI module. This format brings several benefits:

• The CLI structure becomes clear, and only functions such as configuration parsing and plugin parsing need to be maintained.
• The scalability is enhanced, and container/compilation capabilities can be added or deleted in the form of plug-ins to ensure the unity of independent code maintenance functions.
• The compilation process can be sorted out. The compilation process of any container is executed and connected in series based on the timing exposed by the compiler. The overall process is clear and clear.

4.1.2 Component and API Design

The purpose of R2X is to use a set of codes to run on multiple terminals, but due to the existence of differences between multiple terminals, we need to design a unified standard specification for alignment. In the runtime part, it is mainly divided into the alignment of components/interfaces.

multi-terminal difference

Before we start talking about the implementation, let's take a look at where the differences between the ends are.

Component (label) differences

• The Webview tag is written in XML, and the basic tags provided are \<div/\>\<a/\> and so on.
• The applet uses the WXML (WeiXin Markup Language) tag language, and also provides a complete set of basic tags, but it is quite different from Webview.
• React Native uses the JSX (JS-XML) syntax. Although it is very close to XML, it has many differences. At the same time, it also has its own set of basic components, which are completely different from Webview and small programs.

API differences

• Interface differences : The same or similar functions are provided in different terminals, but their implementation methods and calling parameters may be very different, such as data cache Storage, wx.setStorage/wx.setStorageSync in small programs, and Webview. Using localStorage.setItem and AsyncStorage.setItem in MRN, almost every function point has more or less differences.
• Container differences : The APIs provided by each terminal are tailored for their own containers. For example, the business interface APIs of Mini Programs are completely created for the WeChat environment in which the Mini Program is located. This type of function is different from other terminals. related.
• Capability differences : We can adapt to the differences between each end by means of customization, but not all function points can be implemented on each end. For example, in Webview, it is impossible to provide many native capabilities like applets and React Native, such as file saving and reading, etc. This type of difference is irresistible and irreversible in the adaptation process.

style differences

The WXSS of the applet and the CSS of the Webview are almost the same in terms of parameter properties, but there is a big difference in the hierarchical relationship. The applet is divided into global styles and local styles, and the styles of each component will not affect each other. (under default configuration). In contrast, the StyleSheet adopted by React Native uses the Inline Style method, which does not support global styles, does not support label styles, and has many restrictions on properties, such as only Flex layouts can be used.

How to adapt

From the above chapters, we have learned that there are very big differences between the various ends, so how should we overcome these difficulties?

Due to the different levels of support for components and APIs at each end, we selected one end as the basic standard, defined the properties and interface parameters of each component, and implemented it through TypeScript's Interface. Then, based on the above interfaces, the functions are aligned and implemented at each end. The functions limited by the end capabilities are selected, and the high-quality functions are adapted to the bottom layer of the SDK. Finally, we implemented a complete set of basic components @r2x/components and basic API @r2x/r2x based on the existing functional package.

4.1.3 Open Plug-in Capability

With more and more applications of R2X in Meituan, everyone's recognition of the R2X model is also increasing. We often hear the following questions from business parties: "Can we add support for a certain function/container?" , "Our business structure is quite special, can we make some adjustments". Business parties will have more functions/containers requirements for R2X, and there will also be more customized requirements.

Therefore, we decided to implement a complete set of open plug-in capabilities to provide a relatively simple way for everyone to customize these special needs. In the latest version, we refactored R2X's compile-time, and introduced a Tapable -based plugin system in the new compile-time architecture. Developers can expand more functions for R2X by writing plug-ins, or customize more personalized functions for their own business lines.

The plugin types are divided into two categories:

• Container plugin , used to encapsulate the core compilation capabilities of containers supported by R2X.
• The function plug- in is based on the existing container plug-in, and on this basis, a custom implementation of a specific function is carried out.

The overall architecture of the plug-in capability is as follows:

With the development plug-in capability, we have written several platform container plug-ins before, which can be used by developers after installation:

• Mini Program Container Plugin: @r2x/plugin-container-wxapp.
• MRN container plugin: @r2x/plugin-container-mrn.
• Titans container plugin: @r2x/plugin-container-h5.
  In addition to extending the new container platform, we can also write some special custom function plug-ins by inheriting the existing container plug-ins.

1. Preprocess the code

Based on the open plug-in capability, we can modify the code source files before and after compilation by modifying the AST syntax, just like the Babel plug-in. For example: modify the file reference path, insert code snippets, process local pictures, etc.

2. Modify the file product

When compiling the output, we can modify the content, file path, and file structure of the compiled file. Combined with the customization of its own business, CLI can combine and transform R2X projects and existing native projects.

In addition to the above features, the plug-in capability provides users with a great deal of freedom when compiling. If you want to experience it, welcome to join the Meituan food delivery technical team.

4.1.4 Feature Capability - Polymorphism Capability

Why Polymorphism is Needed

Polymorphism is a unified solution for providing components and APIs at each end when cross-end. Based on polymorphism, developers can customize their own cross-end components. R2X has complete cross-end capabilities and can cover multiple terminals and containers. Why do we need polymorphism?

Business R&D requires a certain degree of flexibility in order to meet the requirements of each scenario. At the same time, there are end-to-end differences in Webview/Applet/React Native containers, which require developers to make environmental judgments. When the logic is complex, the number of cross-ends is large, the code readability becomes lower, and the maintenance cost takes off. This is not our intention.

Based on this background, R2X provides polymorphic capabilities with good scalability.

Introduction to R2X Polymorphism Capability

For polymorphic capability support, we divide it into two categories:

• For polymorphic components/APIs, R2X distinguishes compilation targets based on file suffixes.

• Differentiated code, R2X provides the getEnv environment method to determine the target type of the current statement compilation.

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

End-to-end differences can be easily met through differentiated code.

4.2 Application Scenario Isomorphism

4.2.1 Page-level container scene isomorphism

For page-level container scene isomorphism, we have learned from the excellent cross-end frameworks such as Taro1.x and Rax in the industry, combined with the characteristics of internal containers and infrastructure of Meituan, and made a lot of localization and customization. It is preprocessed through different compile-time schemes, and the React runtime is introduced to ensure the completeness of React DSL support and the code isomorphism rate. The compile-time conversion process scheme and runtime structure are shown in the following figure:

Compared with R2X1.0, the runtime solution of R2X2.0 can solve the syntax limitation caused by the compile-time solution:

1. You cannot use if expressions in map loops containing JSX elements✅
2. JSX arrays cannot be manipulated using methods other than Array#map✅
3. Anonymous functions cannot be used in JSX parameters ✅
4. JSX is not supported for methods other than render() ✅
5. Passing in JSX elements in JSX parameters (props) is not allowed ✅
6. Object expanders cannot be used in JSX parameters ✅

It also supports most of the React third-party ecological libraries, and currently supports the use of native react-redux. Completely smooth out the differences at all ends, whether it is MRN, Flutter, applet, Webview custom components can be directly introduced as React components, and the applet native custom components do not need to configure usingComponents.

4.2.2 Module-level container scene isomorphism

In the module-level isomorphism scheme, we rely on the Mach container on the App; in the applet container, we overcome the constraints of the Mach container rendering mechanism (the limitations of the runtime and the use of virtual DOM), and design Mach on the applet alone. The container rendering solution realizes more than 99% code isomorphism rate of R2X -Module on the client and applet.

Overall program

1. The core driver package , the core of the container driver, is implemented in four aspects: rendering capability, parsing capability, caching capability, and performance monitoring to achieve a dynamic drive effect.
2. Business container customization , based on the driving capabilities provided by the SDK, the container customization function expansion configuration is carried out for different booth characteristics, so that business parties can expand themselves according to actual business scenarios.
3. The sub-environment construction mainly realizes the AST compilation and analysis of React-like grammar, and compiles them into corresponding Bundle products according to the construction platform.
4. Automate construction and deployment , connect the construction capabilities to Talos (the self-developed construction and deployment tool in Meituan), and then combine with low-code business tools to achieve one-click deployment, and upload the compiled products to DD (the mobile terminal self-developed in Meituan) according to the configuration items. dynamic distribution platform).

Template-driven scheme

At present, the isomorphism rate of R2X-Module in the client and the applet container is above 99.3%. In terms of performance, the TP50 time of the first rendering time and the template rendering time are 185ms and 144ms respectively, which are excellent but there is still room for optimization. At the same time, R2X-Module SDK is provided for business parties to choose. The R2X-Module SDK initialization and template loading and rendering process are shown in the following figure:

4.2.3 PC/App adaptation isomorphism

Today, when the development of the mobile Internet is highly mature, the PV traffic on the mobile terminal accounts for the vast majority. For example, on the takeaway advertisement merchant side, the PC side only accounts for a small proportion, and the PC traffic accounts for less than 5% of some of our businesses. . Therefore, in some scenarios, realizing the isomorphic solution of PC/App can liberate some manpower, which is very necessary to improve the development efficiency. At present, some pages with different lightweight layouts on the takeaway advertisement merchant side have completed the design and implementation of the PC/App isomorphism.

Style Isomorphic Adaptation

terminal capability expansion

The basic capabilities of R2X support the three terminals of Webview/MRN/mini program, but it lacks the support for the PC micro-front terminal project. To achieve PC/APP multi-terminal isomorphism, it is necessary to expand the terminal capabilities of R2X. The PC side is also essentially a web side, so the end-capability extension of the PC micro-frontend can reuse most of the webview's end-capacity. The overall architecture diagram, technical design points, and expansion flow chart are as follows:

3. Platform code processing

In the project isomorphic development, there will inevitably be code or business logic that is strongly related to the platform. For example, some APIs call the underlying capabilities of the App, which can only be used in React Native and are definitely not supported on the Web side. . Or due to product requirements, some interactions or presentations are quite different, and so on. When the project is compiled and packaged for a certain end, other unrelated end codes are useless and redundant. If retained, it will not only increase the code size, but even cause compilation errors. Therefore, we need to use the platform code processing capabilities to carry out optimization. The processing of platform code mainly includes three parts: module import, component display, and business logic.

The main idea is to use the method of commenting and specifying the platform, so that the specific platform code only takes effect on the specific platform. The comment keyword %%platform%% , such as %%RN%% means that the React Native side is unique, %%MICRO%% indicates that the PC micro-frontend is unique, %%MICRO|Webview%% indicates that both ends of the PC micro-frontend and Webview are valid. The sample code is as follows:

 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 Small game container scene isomorphism

There are two main points to achieve the react2x-game isomorphism solution: the compatibility of the rendering layer and the compatibility of the business layer.

1. Compatibility of the rendering layer: Compatible with the rendering capabilities of the game engine in a multi-terminal environment (Canvas, WebGL).
2. Compatibility of the business layer: realize the compatibility of basic APIs, project processes, and public modules, and formulate personalized customization specifications for game differences.

1. Render layer compatibility

Above, we mentioned that "Whether it is Webview games, small programs, small games, and Meituan small games, we provide Canvas and WebGL controls", which greatly reduces the complexity of our compatible rendering layer. The following form shows the support of syntax and basic functions such as Canvas, WebGL, Document, and Window on each side:

object	Webview	WeChat Mini Games	WeChat applet	Meituan Mini Games
grammar	JavaScript	JavaScript	JavaScript	JavaScript
Canvas	support	support	support	support
Canvas (off-screen)	support	support	not support	support
WebGL	support	support	>2.11.0	support
Ducument	support	not support	not support	not support
Window	support	not support	not support	not support

It can be seen that JavaScript syntax is supported at all ends at the syntax level, but the differences in execution environment and basic functions are relatively large. To sum up:

Execution environment : Mini games and mini programs do not have the capabilities of DOM and BOM (which will be widely used in rendering engines).
Basic functions : The applet does not support off-screen Canvas, and WebGL is only supported after version 2.11.0.

In order to solve these problems, we designed and developed the adapter layer to simulate the capabilities of document and window. It enables the game engine to execute and call the basic functions of BOM and DOM normally in a non-Webview environment. At the same time, an adaptation scheme for off-screen canvas is developed to solve the problem that small programs cannot support off-screen canvas. In order to obtain an effective off-screen canvas, we made "r2x-add-wxml-loader", which automatically injects additional <canvas/> controls in the loader stage of the .wxml file and hides them from the phone screen to simulate games Offscreen canvas in the engine.

2. Multi-terminal compatible build

At the construction level, we differentially process multi-terminal code through the integrated multiple personalized plug-in tools. Such as: environment variable injection, mixing of adaptation code at each end, specification detection, code analysis and transformation, etc. According to the particularity of mini-games, mini-program codes and execution environments, wx-build-plugin, lwxapp-build-plugin, etc. are produced to handle the packaging of mini-games and mini-programs. Combined with the different processing solutions mentioned above, tools such as add-wxml-loader, transfrom-loader, and wxss-loader are made to assist in completing the project construction. As shown in Figure 17 below, at the beginning of the build, the environment variables of this build will be injected, the configuration file will be read and analyzed, and the build tool set will be integrated and initialized to prepare for the project build. Then, in the construction process, the differences at each end are processed differently. The analysis layer parses different files, and performs conversion and construction at the conversion layer, and finally generates the final product required by each end.

4.3 Landing scene and effect

4.3.1 Landing scene

4.3.2 Effect Benefit

R2X has been widely used in Meituan's food delivery business. As of October 2021, R2X has been in use by more than 20 departments within Meituan or under investigation. A total of hundreds of projects and pages have been landed, and the number of framework downloads has reached one million times. The average code isomorphism rate of pages more than 90%. At the level of container code reuse and operation and maintenance, the R2X ecosystem has saved Meituan thousands of people per day, and improved the success rate of dynamic page conversion by 5%-8%.

V. Outlook and conclusion

To sum up, in the context of the diversified business forms and container diversity of Meituan Takeaway, cross-container reuse has become the only way for development. After two years of iteration, R2X has also achieved phased results. It has completed business coverage in various business scenarios of Meituan, and has also made a lot of infrastructure construction for the company's ecological environment access. We believe that cross-container and multi-terminal code reuse is still an important part of reducing project delivery cycle, reducing R&D costs, and improving R&D efficiency. But at present, we are not perfect in many complex business scenarios, so there is still a lot of work to be improved, such as:

• To optimize the development experience , there are more and more brother departments that want to access or are accessing. How to reduce access costs, enrich infrastructure, optimize development experience, and help everyone quickly migrate and access will be an important topic in the next stage.
• Rendering performance optimization , performance optimization in the Meituan takeout scene has always been another important indicator for us to take into account efficient production. Especially in the small program scenario, the performance experience of low-end models has always been the bottleneck in the industry. How to break through this difficulty will be the stepping stone to the comprehensive promotion of the isomorphic solution.

Finally, I would like to thank all relevant R&D teams for their strong support in the construction of R2X. The development of R2X is inseparable from the round-the-clock investment and contribution of all participants. We will continue to explore more in the field of terminal containers based on R2X. If you think R2X is not bad, or are more interested in Meituan's R2X framework, welcome to discuss with us.

About the Author

Zhenghao, Baoshi, and Peng Zhen are all R&D engineers of Meituan's food delivery terminal team.

Job Offers

Meituan Waimai has been recruiting Android, iOS, FE, Java senior/senior engineers and technical experts for a long time. Interested students are welcome to submit their resumes to [e-mail] .