React2X was launched in September 2019 by meituan Takeaway technology team in collaboration with multiple r&d departments, providing a complete and open multi-terminal Containerless development framework for all front-end developers, especially those teams divided by business domain. The React2X framework allows developers to quickly create, develop, build, and deploy projects to achieve relatively optimal performance experience on different terminals with minimal manpower consumption, significantly reduce the cost of replacement and transformation due to container upgrade, and maximize the reuse rate of code.
Terminal Containerless: Similar to the concept of Serverless, that is, the ability to upgrade and replace terminal containers compatibly at the bottom level without changing the business development language at the top level, so that users do not need to care about the operation and maintenance of terminal containers, as long as they focus on the technology of business logic.
One, foreword
React2X is a multi-terminal, cross-platform, container independent development framework. With the trend of standardization of the whole Meituan front-end technology stack, React technology stack becomes more and more important in our technical system. In advertising, marketing and other promotional businesses, there are more and more business demands to realize “simultaneous development and simultaneous launch” on various terminals (including Meituan App, Meituan Takeaway App, Dianping App, as well as other terminals such as wechat mini program, Baidu mini program, Toutiao & Douyin mini program). Against this background, we define the core scenarios for React2X applications:
- Faced with the rich and diverse technology container systems within Meituan (Mach, MRN, Titans, MTFlutter, MMP, etc.), how to ensure the consistency of cross-container development experience and build the ecological capacity of cross-container application development is a problem we need to solve.
- The rich terminal container technology in the company is booming, and the transformation cost caused by business upgrading is relatively large, so it is urgent to have a high-level framework with high scalability design as the technical starting point.
- Cross-container dynamic capability coverage has gradually become the basic capability that each business side pays more and more attention to. It can greatly shorten the cycle of demand delivery, improve the efficiency of on-line release, effectively solve the problem of package size, and improve the agility of business.
- Isomorphic appeal in multiple scenarios, such as in various promotion pages, modularity, games, and PC/App isomorphic scenarios with different lightweight layouts, can save manpower in multi-stage research and development.
Finally, our core pain point centers on the multiple development operation and maintenance of the same demand in meituan · Small program and Meituan ·App matrix. In order to solve the bottleneck of R&D manpower, we need a RESEARCH and development framework of “once research and development, multi-terminal container reuse” to improve the research and development efficiency.
After investigating the whole front-end field, we found some solutions in the industry, such as meituan’s earliest MPvue, Tencent’s Wepy, Didi’s Chameleon, Jingdong’s Taro and so on. After comparison and trial, based on the value judgment of input-output ratio, we finally choose to stand on the shoulders of giants to develop and customize a research and development framework — React2X (hereinafter referred to as R2X) that meets Meituan’s technology and business scenarios. Since the release of the first version of R2X, it has been tested by various businesses of the company for more than two years. So we hope this article will help you get a general idea of R2X.
Ii. Objectives and scenarios
2.1 Core Objectives
In order to solve the problem of repeated development of business requirements in multi-terminal containers and achieve development efficiency through code reuse, we identified the following goals:
- Solve the pain points of multi-terminal container development in the company: realize the isomorphic reuse of codes of Webview container, small program container, MRN container, Mach container, game container and PC container in some operation and promotion scenarios, unify development specifications, smooth out development differences, and provide the ability to expand other containers.
- Building cross-container dynamics: The lack of cross-container dynamics prevents products from rapidly iterating to validate requirements, a problem that severely limits business growth. The cross-container dynamic capability can solve the problems of version release and package body on Meituan takeout business, and help the business realize the capabilities of quick version release online, hot repair of online problems, and disaster recovery.
- Building a container-independent development ecosystem: R2X ultimately aims to solve container differences, build unified technical ecological capabilities, and improve production and operation efficiency in multi-terminal container development scenarios.
2.2 Application Scenarios
The R2X development framework is mainly intended to eventually be a terminal container for multi-terminal applications for scenario-based development:
That is:
- Business projects are based on the React syntax as a technical framework.
- The business side has the need to run on multiple terminals/containers (including MRN container, Webview container, MP container, Flutter container, Mach container, PC browser container).
- The business side has specific scene-oriented demands, including promotion pages, modularity, mini-games, PC/App isomorphism, etc.
Challenges and advantages
3.1 Industry Research
In view of the above core goals and application scenarios, we investigated the cross-container frameworks on the market. As The technical stack of Meituan Takeout is mainly unified by React, our necessary requirements are as follows: a reusable framework using React as DSL language, which can quickly integrate into the technical ecology of Meituan.
According to the comparison in the table below, if we use React as DSL language, only Taro can meet our business demands at that time, but its ecological environment is not suitable for use in Meituan system. Based on the consideration of many factors, we decided to combine the strengths of various mainstream frameworks, and then develop a cross-container reuse framework belonging to Meituan Takeout.
| Compare the item | mpvue | Taro 1.3 | Chameleon | WePY | UniApp |
|---|---|---|---|---|---|
| DSL | Vue | React (Nerv) | Class Vue | Vue | Vue |
| Whether React Native is supported | no | Yeah, but the support wasn’t very good | Weex | no | no |
| Compatible API | There is no | Yes (API support varies) | Self – developed polymorphic protocol | There is no | is |
| Cross-end component libraries | There is no | There are | There are | There is no | There is no |
| Meituan ecological | There are | There is no | There is no | There is no | There is no |
| Grammar check | There is no | ESLint | Since the research | There is no | There are |
| TypeScript | There are | There are | There is no | There are | There are |
| Custom extensions | There is no | But since the research of the Plugin | There is no | There is no | There are |
| Compile the extension | There is no | There is no | There is no | There is no | There are |
| Research conclusion | Don’t match | Part of the meet | Part of the meet | Don’t match | Don’t match |
Note: The preliminary survey period ends in May 2019, which may be different from the current data.
3.2 Technical Challenges
When we decided to create a cross-container reuse framework for Meituan Takeout, we mainly encountered the following challenges in the implementation process:
(1) Different adaptation costs between different containers
- Syntactic semantics: MRN/ applets/webviews have completely different syntactic semantics on DSLS.
- Terminal capability: The same container has many differences on different terminals. For example, THE MRN container in Take-out App and THE MRN container in Meituan App have customized Native modules and various bridge protocols respectively.
② Cost of service access
- First cost: how to get new business parties up and running quickly as a newly defined framework, how to migrate from existing lines of business.
- Marginal cost: How to integrate Meituan’s infrastructure ecosystem so that businesses can quickly reuse platform capabilities.
(3) Reasonable design of top-level architecture
- High maintainability and scalability: how to quickly upgrade, replace, and add a new underlying container.
Note: The above questions will be answered in the “Technical Overview” section below.
3.3 Project Advantages
3.3.1 Comparison of functions and Features
At present, there are many frameworks in the industry that use small programs as cross-end target platforms, but most of them use Web front-end technology stacks as the basis, but there are few technology stacks that also take into account React Native. The following table lists the frameworks that support React and React as DSLS.
| R2X | Taro 1.3 | Taro 3.0 | Rax | Remax | |
|---|---|---|---|---|---|
| The principle of | R2X 1.0 recompile time, R2X 2.0 rerun time | When the recompile | Heavy runtime | Heavy runtime | Heavy runtime |
| Container key | To MRN, small programs, WebView, while supporting MTFlutter, Mach, games, PC browser | React Native features small programs and Web, but not much support | React Native is supported by the 58 team | Applets, Web, Flutter | Applets, Web |
| API | Support KNB bridge & unify the multi-platform API | The multi-platform API has been unified | The multi-platform API has been unified | Multiple platforms are not unified | Multiple platforms are not unified |
| Cross-end component libraries | There are | There is TaroUI, but React Native is not supported | There is TaroUI, but React Native is not supported | There is no | There is no |
| Business component extension | Provide extension solutions | Reference TaroUI | Reference TaroUI | Provide extension solutions | Provide extension solutions |
| Meituan internal ecological support | Buried point monitoring is supported | There is no | There is no | There is no | There is no |
| Modularization capability | support | Does not support | Does not support | Does not support | Does not support |
| Compiling plug-in extensions | support | Does not support | support | support | Webpack configuration is supported |
To sum up, from the current business form, R2X is the best solution at this stage in terms of container matching and meituan ecological support. R2X has a more complete localization implementation for meituan delivery teams than any other framework in the industry.
3.3.2 Performance Data Comparison
Based on cross-platform frameworks in the industry and within Meituan, we also conduct Benchmark tests for performance, and the final comparison results are as follows.
Applet performance comparison
| The framework | create | update | add | 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: As you can see, r2X-MP is ahead of Remax and taro-MP in small program Benchmark test results.
Compare with React Native performance
| The framework | create | update | add | 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 |
Conclusions: In the Benchmark test results of React Native, R2X-MRN and MRN are basically equal, but both are lower than pure React Native performance.
3.3.3 Comparison of homogeneous scenarios
In addition to supporting the basic React Native, apet, and Webview container isomorphism scenarios, R2X also implements the extension of isomorphism capabilities on MTFlutter, Mach, mini games (Webview games, wechat mini games & Apet, Meituanmini games), PC browsers, and other containers. The ecosystem is also richer and more robust than other cross-container development frameworks in the industry.
| React Native | Small program | Webview | Flutter | Modular container | Small game container | PC Browser (PC/App isomorphism) | |
|---|---|---|---|---|---|---|---|
| R2X | support | support | support | support | support | support | support |
| Taro | support | support | support | Does not support | Does not support | Does not support | Does not support |
| Rax | support | support | support | Does not support | Does not support | Does not support | Does not support |
| Remax | support | support | support | Does not support | Does not support | Does not support | Does not support |
Iv. Technical Panorama
Above is a panoramic view of the ARCHITECTURE of R2X, which can be read from bottom to top and left to right:
- The lowest level is the ecological environment construction of R2X, which realizes the common SDK of the company’s ecology and various thematic capabilities of the business within R2X. And through the establishment of materials market/plug-in market, in the form of business co-construction to enrich the R2X ecosystem.
- The next layer is the foundation of R2XCore, which implements the evoking builder by parsing Command commands, and implements a plug-in system similar to Webpack, which organizes and drives the whole core construction process in a plug-in form for easy maintenance and extension.
- Then there is the cross-end container layer, which is the core of the overall cross-end capability, with the implementation of different container plug-ins to compile R2X code into end-to-end executable code and the runtime capability to align components/apis.
- The top layer is the App terminal. At present, there are many mobile App terminals such as Meituan Takeout, Dianping and Meituan.
- On the far right are some of the developments R2X has done in r&d, distribution, operations, and user documentation.
Because R2X covers most of the mainstream container scenarios in Meituan, the technical system is relatively complex and large, so people can selectively learn about the isomorphic solutions of the corresponding scenarios according to their own business forms.
4.1 Underlying Infrastructure Framework
4.1.1 R2X-CLI design
As the R2X project driver, the CLI not only contains command line startup, but more importantly, it is the core of each build.
In the early days of the CLI build command, we used –type to distinguish between different build containers to load different build logic. Implementing the same set of code by specifying the form of the build container can lead to different container artifacts. However, after a long period of business iteration, we found problems with this structure:
- The overall process is long and complex, and long iterations become increasingly difficult to maintain.
- The build process for each container is independent and the build logic is inconsistent, with multiple repetitive logic processes.
- The compilation process lacks a unified key node and cannot be customized by the business side during compilation.
In response to these problems, we considered a new REfactoring of the CLI to introduce plug-in capabilities (the implementation of plug-in capabilities is described in more detail below). The overall structure of the CLI is as follows:
The CLI module only needs to be concerned with parameter parsing and plug-in loading and execution, and does not need to implement specific compilation logic of each container. In the form of Hooks, each compilation time is exposed to the plug-in. The plug-in implements the compilation capability based on these Hooks, and finally outputs the output to the CLI module. This provides several benefits:
- The CLI structure becomes clear, and only configuration and plug-in resolution functions need to be maintained.
- Enhanced extensibility, can be added or deleted in the form of plug-in container/compilation capabilities, to ensure the single code independent maintenance function.
- The compilation process can be combed out. Regardless of the container, the compilation process is executed and cascaded based on the compiler exposure. The overall process is clear.
4.1.2 Design of components and API
The goal of R2X is to have one set of code that can run on multiple ends, but due to the diversity of multiple ends, we need to design a unified standard specification for alignment. At run time, this is divided into component/interface alignment.
Many differences
Before we start talking about the implementation, let’s look at exactly where the differences are.
Component (label) differences
- The Webview tag is written in XML and provides basic tags such as
- The small program uses WXML (WeiXin Markup Language) tag Language, also provides a complete set of basic tags, but there is a big difference with Webview.
- React Native uses the JSX (JS-XML) syntax. Although it is similar to XML, it has many differences. It also has its own set of basic components, which are completely different from WebViews and applets.
API differences
- Interface differences: In different end provides the same or similar functions, but its implementation is very big difference, and may call parameters such as data buffer Storage, small program with wx. SetStorage/wx setStorageSync, Webview uses localstorage. setItem, while MRN asyncstorage. setItem, almost every function point has a lot of differences.
- Container differences: The apis provided by each end are tailored to their own containers. For example, the business interface apis of the small program are completely tailored to the wechat environment where the small program is located. Such functions are not related to other ends.
- Capability differences: The differences between each end can be adapted by means of customization, but not all function points can be realized on each end. For example, small programs and React Native cannot provide many Native capabilities, such as file saving and reading, in Webview. Such differences are irresistible and irremediable in adaptation.
Style differences
Applet WXSS and Webview CSS are almost the same in terms of parameter attributes, but there is a big difference in the hierarchy. Applet is divided into global and local styles, and the styles of each component do not affect each other (in the default configuration). React Native StyleSheet, by contrast, uses Inline Style, does not support global Style, does not support tag Style, and has many restrictions on attributes, such as only using Flex layout and so on.
How to fit
We have learned from the above chapters that there are big differences between each end. How can we overcome these difficulties?
Since each side supports different components and apis, we choose one side as the base standard, define the properties and Interface parameters of each component, and implement them through TypeScript Interface. Then, function alignment is implemented on each end based on the above interfaces respectively, and certain trade-offs are made for functions limited by the end capacity, and adaptation of high quality functions is carried out at the bottom of SDK. Finally, we implemented a complete set of basic components @r2x/ Components and basic API@r2x/r2x based on the existing functionality package.
4.1.3 Open plug-in capability
With the increasing application of R2X in Meituan, people’s recognition of THE R2X model is also increasing. We often hear the following questions from the business side: “Can we add some function/container support”, “Our business architecture is special, can we make some adjustments”. There will be more demand for functionality/containers on the business side of R2X, and there will be more customization.
So we decided to implement a full set of open plug-in capabilities that would provide a relatively simple way for people to customize their own special needs. In the latest release, we have refactored the compile time of R2X, introducing a Tapable plug-in system in the new compile time architecture. Developers can add more features to R2X by writing plug-ins, or customize more features for their own lines of business.
The plug-in types fall into two categories:
- Container plug-in that encapsulates the core compilation capabilities of containers supported by R2X.
- Function plug-in, based on the existing container plug-in, on this basis for a specific function of the custom implementation.
The overall architecture of plug-in capabilities is as follows:
With the help of the open plug-in capability, we have previously written several platform container plug-ins that can be used by developers after installation:
- Small program container plug-in: @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 special plug-ins for custom functionality by inheriting existing container plug-ins.
1. Preprocess the code
With the open plug-in capability, we can make pre – and post-compile changes to code source files by modifying AST syntax, just like the Babel plug-in. For example: modifying file reference paths, inserting code snippets, manipulating local images, and so on.
2. Modify the file product
When compiling output is generated, we can modify the content of the compiled file, the file path, and the file structure. Combined with its own business customization, the CLI can combine R2X projects with existing native projects.
In addition to the above capabilities, the plug-in capability gives the user a great deal of freedom at compile time. If you want to experience, welcome to join meituan delivery technology team.
4.1.4 Characteristic capability – Polymorphic capability
Why do you need polymorphic capabilities?
Polymorphic capabilities are used to provide a unified solution for cross-end components and apis. Based on polymorphic capabilities, developers can customize their own cross-end components. R2X has complete cross-terminal capability, covering multiple terminals and containers, so why polymorphism?
Business development requires flexibility to meet the requirements of each scenario. At the same time, Webview/ applets /React Native containers have different ends, requiring developers to make artificial environmental judgments. It is not our intention that the logic will be complex and the number of cross-ends will make the code less readable and the maintenance cost will take off.
Against this background, R2X offers very scalable polymorphic capabilities.
R2X polymorphic capability introduction
Support for polymorphic capability falls into two categories:
- Polymorphic component /API, R2X separates compile target side by file suffix.
- Differentiated code, R2X provides the getEnv environment method to determine the type of the target side of the current statement compilation.
<View style={{color: R2X.getEnv() === "WEAPP" ? "green" : "blue" }} />
Copy the codeThrough differentiated code can easily meet the demands of end difference.
4.2 Application Scenario Isomorphism
4.2.1 Isomorphism of page-level container scenarios
We learned from the practice of excellent cross-end frameworks such as TARo1.x and Rax in the industry, combined with the characteristics of meituan’s internal containers and infrastructure, and made a lot of localization and customization. We preprocessed Webview, MRN and small program containers through different compile-time solutions, and introduced the React runtime. The integrity and code isomorphism rate of React DSL support are guaranteed. The compile time transformation process scheme and runtime structure are shown below:
R2x2.0 compared to r2x1.0, the runtime scheme can solve the syntax limitations of the compile-time scheme:
- You cannot use the if expression ✅ in a map loop that contains JSX elements
- JSX arrays cannot be manipulated using methods other than Array#map ✅
- You cannot use the anonymous function ✅ in JSX arguments
- Method definitions other than render() are not currently supported JSX ✅
- JSX elements ✅ are not allowed to be passed in JSX parameters (props)
- You cannot use the object expander ✅ in JSX arguments
It also supports most React third-party libraries, and supports the use of the original React – Redux. All the custom components of MRN, Flutter, applets, and Webview can be directly introduced as React components. Applets’ native custom components do not need to be configured with usingComponents.
4.2.2 Module level Container scenario isomorphism
For module-level isomorphism, we rely on Mach containers on App; In the small program container, we overcome the constraints of the Mach container rendering mechanism (the use of virtual DOM with runtime), and designed a Mach container rendering scheme on the small program alone, and achieved r2X-Module (R2X-Module) code isomorphism rate of more than 99% on the client and small program.
The overall plan
- Core driver package, the core of container driver, is implemented in four aspects of rendering ability, parsing ability, cache ability and performance monitoring to achieve dynamic driving effect.
- Business container customization. Based on the driver capability provided by SDK, the container customization function expansion configuration is carried out for different booth features, so that businesses can expand themselves according to actual business scenarios.
- The React syntax is compiled and parsed into bundles according to the construction platform.
- Automatic construction and deployment, the construction ability is connected to Talos (meituan internal self-developed construction and deployment tool), and then combined with low-code business tools to achieve one-click deployment, and the compilation products are uploaded to DD (Meituan internal self-developed mobile terminal dynamic delivery platform) according to configuration items.
Template-driven solution
At present, the isomorphism rate of R2X-Module in client and small program container is above 99.3%. In terms of performance, the TP50 time of first rendering time and template rendering time are 185ms and 144ms respectively, which are relatively excellent but still have 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 rendering process are shown below:
4.2.3 PC/App adaptation isomorphism
With the highly mature development of mobile Internet today, PV flow of mobile terminal accounts for the vast majority, while for example, PC terminal only accounts for a small proportion, among which PC traffic accounts for less than 5% in some of our businesses. Therefore, realizing the ISomorphic scheme of PC/App in some scenarios can liberate some manpower and is very necessary to improve the development efficiency. At present, the design and implementation of the PC/App isomer scheme has been completed for some lightweight pages with different layouts at the merchant end of takeaway advertising.
Style isomorphic fit
End capacity expansion
R2X’s basic capabilities support Webview/MRN/ applets, but lack support for PC micro front end sub-projects. To achieve PC/APP multi-terminal isomorphism, R2X’s terminal capabilities need to be extended. PC side also belongs to Web side in nature, so the end capability expansion of PC micro front end can reuse most of the end capability of Webview. The overall architecture diagram, technical design points and extended flow chart are as follows:
Platform code handling
In homogeneous project development, it is inevitable that platform-related codes or business logic will appear. For example, some apis call the underlying capabilities of the App and can only be used in React Native, which is definitely not supported on the Web side. Or because of product requirements, some interactions or presentations are different, etc. However, when the project is compiled and packaged for a certain end, other irrelevant end codes are useless and redundant. If retained, not only the code volume will be increased, but even compilation errors will occur. Therefore, we need to make use of the platform’s code processing ability to optimize. Platform code processing mainly includes three parts: module import, component display, business logic.
Comment keyword %%platform%%. For example, %%RN%% indicates that React Native is unique. %%MICRO%% indicates that PC MICRO front-end is unique. % % % % MICRO | Webview said PC MICRO front end and both ends of the Webview. Example code is as follows:
import A from '@r2x/r2x-a'; // %%RN%% is reserved only for React Native. import B from '@r2x/r2x-b'; // %%MICRO%% is reserved only on the MICRO end. import C from '@/utils/c'; // This is a public module for all endpoints. import D from '@r2x/r2x-d'; / / % % MICRO | Webview % % in MICRO, Webview multiterminal effective module.Copy the code4.2.4 Isomorphism of small game container scene
React2x-game isomorphism is mainly implemented in two aspects: compatibility of rendering layer and compatibility of business layer.
- Compatibility of rendering layer: to achieve compatibility of game engine rendering capability in multi-terminal environment (Canvas, WebGL).
- Compatibility of business layer: to achieve compatibility of basic API, project process and public module, and to develop customized specifications for game differences.
Render layer compatibility
As mentioned above, “Webview games, mini-programs, mini-games and Meituan mini-games all provide us with Canvas and WebGL controls”, which greatly reduces the complexity of our compatible rendering layer. The following table shows the support of each end for syntax and Canvas, WebGL, Document, Window and other basic functions:
| object | Webview | Wechat games | Wechat applets | Meituan small game |
|---|---|---|---|---|
| grammar | JavaScript | JavaScript | JavaScript | JavaScript |
| Canvas | support | support | support | support |
| Canvas (Off-screen) | support | support | Does not support | support |
| WebGL | support | support | > 2.11.0 | support |
| Ducument | support | Does not support | Does not support | Does not support |
| Window | support | Does not support | Does not support | Does not support |
As can be seen, JavaScript syntax is supported at all ends, but there are big differences in execution environment and basic functions. To sum up:
Execution environment: Small games and small programs do not have DOM and BOM capabilities (used heavily in rendering engines). Basic features: Applets do not support off-screen Canvas, WebGL was not supported until version 2.11.0.
In order to solve these problems, we design and develop the Adaptor layer, which is used to simulate the ability of Document and Window. Make the game engine can execute and call the basic function of BOM and DOM normally in non-WebView environment. At the same time, the adaptation scheme of off-screen canvas is developed to solve the problem that small programs cannot support off-screen canvas. In order to obtain effective off-screen canvas, we made “R2X-Add-wXML-loader”, which automatically injected additional controls in the loader stage of.wxml file and hid them outside the mobile phone screen for simulating off-screen canvas in the game engine.
Build multiterminal compatibility
At the construction level, we integrate various personalized plug-in tools to deal with the differences of multi-side code. Such as: environment variable injection, the mixing of various end adaptation code, specification detection, code parsing and transformation. In view of the particularity of small games, small program code and execution environment, wX-build-Plugin and LwXapp-build-Plugin are made to deal with the packaging work of small games and small programs. In combination with the different processing schemes mentioned above, add-WXML-loader, TransFrom -loader, wXSS-loader and other tools were made to assist in the construction of the project. As shown in Figure 14 below, the build begins by injecting the build’s environment variables, reading and analyzing the configuration files, and integrating and initializing the build tool set in preparation for the project build. Then, in the construction process, the difference processing is carried out according to the differences of each end, the analysis layer is analyzed for different files, and the transformation and construction are carried out in the transformation layer, and finally the final products needed by each end are generated.
4.3 Landing Scene and effect
Effect of yield
R2X has been widely used in Meituan takeaway business. By October 2021, R2X has been used by more than 20 departments in Meituan or in research, with a total of hundreds of projects and pages implemented. The framework has been downloaded millions of times, and the average code isometric rate of pages has reached over 90%. The R2X ecosystem saves meituan thousands of people per day in container code reuse and operation and maintenance, and improves the success rate of dynamic page conversion by 5%-8%.
V. Prospect and summary
To sum up, in the case of diversified business forms and container diversity of Meituan Takeout, cross-container reuse has become the only way to develop. After two years of iteration, R2X has also achieved phased results, covering all business scenarios in Meituan and making a lot of infrastructure construction for the company’s access to the ecological environment. We believe that cross-container code reuse is still an important part of reducing project lead times, reducing r&d costs and improving r&d efficiency. However, we are not perfect in many complex business scenarios, so there is still a lot of work to be done, such as:
- At present, more and more brother departments want to access or are accessing. How to reduce access costs, enrich infrastructure, optimize development experience, and help everyone quickly migrate to access will be an important topic in the next stage.
- Rendering performance optimization, in meituan takeout scene performance optimization has always been another important indicator for us to give consideration to efficient production. Especially in the scenario of small programs, the performance experience of low-end models has always been the bottleneck in the industry, and how to break through this difficulty will be the “stepping stone” for the comprehensive promotion of homogeneous programs.
Finally, we would like to thank all the r&d teams for their support during the R2X construction process. R2X cannot be developed without the dedication and contribution of all the participants. We will continue to explore more in the field of terminal containers based on R2X. If you think R2X is good, or are interested in Meituan’S R2X framework, welcome to talk with us.
Author’s brief introduction
Zheng Hao, Bao Shi and Peng Zhen are all r&d engineers of Meituan takeaway terminal team.
Recruitment information
Meituan takeout is looking for senior/senior engineers and technical experts in Android, iOS, FE and Java. Please send your resume to [email protected].
Read more technical articles from meituan’s technical team
Front end | | algorithm back-end | | | data security operations | iOS | Android | test
| in the public bar menu dialog reply goodies for [2020], [2019] special purchases, goodies for [2018], [2017] special purchases such as keywords, to view Meituan technology team calendar year essay collection.
| this paper Meituan produced by the technical team, the copyright ownership Meituan. You are welcome to reprint or use the content of this article for non-commercial purposes such as sharing and communication. Please mark “Content reprinted from Meituan Technical team”. This article shall not be reproduced or used commercially without permission. For any commercial activity, please send an email to [email protected] for authorization.