1. Background

1.1 About FlutterWeb

Back in 2018, Google released the FlutterWeb Beta version for the first time, revealing its vision to realize one code and multi-terminal operation. After more than two years of hard work by countless engineers, at the beginning of this year (March 2021), Flutter 2.0 was officially released. It incorporated the FlutterWeb function into the Stable Channel, which means that Google has strengthened its determination to reuse multiple terminals.

Figure 1 FlutterWeb history

Of course, Google's "ambition" is not without confidence. It is mainly reflected in its powerful cross-end capabilities. Let's take a look at how Flutter's cross-end capabilities are reflected on the web side:

Figure 2 Flutter cross-end capabilities

The above pictures are the architecture diagrams of FlutterNative and FlutterWeb respectively. It can be seen from the comparison that the application layer Framework is public, which means that in FlutterWeb we can also directly use components such as Widgets and Gestures to achieve logical cross-end. Regarding rendering cross-end, FlutterWeb provides two modes to align the rendering capabilities of the Engine layer: Canvaskit Render and HTML Render. The following table compares the differences between the two:

Figure 3 Mode comparison

Canvaskit Render mode : The bottom layer is based on Skia's WebAssembly version, and the upper layer uses WebGL for rendering, so it can better ensure consistency and scrolling performance, but poor compatibility (WebAssembly only supports from Chrome 57 version) is that we need to face The problem. In addition, Skia's WebAssembly file size has reached 2.5M, and Skia's self-drawing engine needs font library support, which means that it needs to rely on large Chinese font files, which has a great impact on page loading performance. Therefore, it is not recommended to use it directly in the Web. Canvaskit Render (officially also recommends Canvaskit Render mode for desktop applications).

HTML Render mode : The rendering capability of the Engine layer is aligned with HTML + Canvas, so the compatibility is excellent. In addition, MTFlutterWeb has explored and practiced scrolling performance, and can currently handle most business scenarios. As for the loading performance, the initial package in this mode is 1.2M, which is 1/2 of the product volume in Canvaskit Render mode, and we can intervene in the compilation process and control the output product, so there is a large space for optimization.

Based on the above reasons, the Meituan Takeaway technical team chose to optimize the performance of Flutter Web pages in HTML Render mode.

1.2 Business Status

Meituan's takeaway merchants provide merchants with a series of services such as order management, product maintenance, customer evaluation, and takeaway classrooms in various forms such as apps and PCs, and the business functions of both apps and PCs are basically aligned. In addition, we also provide a multi-store management function for chain merchants on PC. At the same time, in order to meet the demands of platform operation, some businesses have external investment H5 scenarios, such as the Meituan Food Delivery Merchant Classroom, which is a content platform that helps merchants learn food delivery operation knowledge, understand industry development and follow up on business strategies in the form of articles and videos. , has strong communication properties, so we provide the ability to share off-site.

Figure 4 Business Form

In order to achieve multi-terminal (App, PC, H5) reuse and improve R&D efficiency, we will start MTFlutterWeb in early 2021Construction of R&D system. At present, we have completed more than 9 efficiency-enhancing businesses based on MTFlutterWeb. In the App, we can provide high-performance services based on FlutterNative; on the PC and Mobile browsers, we use FlutterWeb to achieve low-cost adaptation, which improves production and research. overall efficiency.

However, the loading performance problem is the biggest obstacle to the promotion of MTFlutter Web applications. Here we still take the classroom business of Meituan takeaway merchants as an example. At the beginning of the project, the TP90 line of the page fully loaded reached about 6s, which is far from the baseline value of our indicator (the TP90 line of the page fully loaded time is not higher than 3s, and the baseline value is mainly based on the US There are some gaps, and there is a lot of room for improvement in user access experience. Therefore, optimizing FlutterWeb page loading performance is an urgent problem we need to solve.

2. Challenges

However, to break through the performance bottleneck of FlutterWeb page loading, the challenges we face are also huge. This is mainly reflected in FlutterWeb's optimization strategy for missing static resources, as well as complex architecture design and compilation processes. The following figure shows the process of converting Flutter business code into a web platform product. Let's analyze it in detail:

Figure 5 FlutterWeb compilation process

1. Framework, Flutter_Web_SDK (Flutter_Web_SDK is based on HTML, Canvas, and carries the specific implementation of HTML Render mode) and other underlying SDKs can be directly introduced by business code, helping us to quickly develop cross-end applications;

2. flutter_tools is the compilation entry for each platform (Android, iOS, Web). It receives the flutter build web command and parameters and starts the compilation process, while waiting for the callback of the processing result. In the callback, we can perform secondary processing on the compiled product;

3. frontend_server is responsible for converting Dart into AST, generating the kernel intermediate product app.dill file (in fact, the compilation process of each platform will generate such an intermediate product), and handing it over to the Compiler of each platform for translation;

4. Dart2JS Compiler is the module responsible for translating JS in Dart-SDK. It reads and parses the above-mentioned intermediate product app.dill, injects JS tools such as Math, List, Map, etc., and finally produces JS that can be executed by the Web platform. document.

5. The compiled products are mainly static resources such as main.dart.js, index.html, images, etc. FlutterWeb lacks the optimization methods in conventional web projects for these static resources, such as file hashing, file segmentation, CDN support, etc.

It can be seen that to complete the optimization of the FlutterWeb compilation product, it is necessary to intervene in the many compilation modules of FlutterWeb. In order to improve the overall compilation efficiency, most modules are compiled into snapshot files in advance (a Dart compilation product that can be run by Dart VM to improve execution efficiency), such as: flutter_tools.snapshot, frontend_server.snapshot , dart2js.snapshot, etc., which makes it more difficult to intervene in the FlutterWeb compilation process.

3. Overall design

As mentioned above, in order to achieve cross-platform logic and rendering, Flutter's architecture design and compilation process have certain complexity. However, since the specific implementation of each platform (Android, iOS, Web) is decoupled, our idea is to locate the Web platform implementation of each module (Dart-SDK, Framework, Flutter_Web_SDK, flutter_tools) and seek optimization. The overall design diagram is as follows shown:

Figure 6 Overall Design

• SDK slimming : We slimmed down Dart-SDK, Framework, and Flutter_Web_SDK, which FlutterWeb relies on, respectively, and integrated these simplified SDKs into the CI/CD (continuous integration and deployment) system, laying a foundation for reducing the size of product packages ;

• Compilation optimization : In addition, we have intervened in the compilation process in flutter_tools, and carried out optimizations such as JS file fragmentation, static resource hashing, resource file uploading CDN, etc., so that these basic performance optimization methods in conventional web applications can be implemented in Landed in FlutterWeb. At the same time, the optimization of resources in special FlutterWeb scenarios has been strengthened, such as: font icon reduction, Runtime Manifest isolation, Mobile/PC sub-platform packaging, etc.;

• Loading optimization : After optimizing static resources in the compilation stage, we support resource preloading and on-demand loading during front-end operation. By setting a reasonable loading time, the initial code size can be reduced and the rendering speed of the first screen of the page can be improved. .

Below, we describe each optimization in detail.

4. Design and Practice

4.1 Streamlined SDK

4.1.1 Packet volume analysis

If you want to do a good job, you must first sharpen your tools. Before starting to do volume trimming, we need a set similar to webpack-bundle-analyzerThe package volume analysis tool is easy to visually compare the volume ratio of each module and help optimize performance.

Dart2JS officially provides --dump -infoCommand option to analyze JS products, but its performance is not satisfactory, it can not analyze the volume ratio of each module very well. Here it is more recommended to use source-map-explorer, its principle is to reverse the solution through the sourcemap file, which can clearly reflect the occupied size of each module, and provide guidance for the simplification of the SDK. The following figure shows the inverse solution information of the FlutterWeb JS product (the screenshot only includes Framework and Flutter_Web_SDK):

Figure 7 Inverse solution information

4.1.2 SDK tailoring

The SDKs that FlutterWeb depends on mainly include Dart-SDK, Framework and Flutter_Web_SDK. These SDKs have a huge impact on the package size, almost contributing to all the size of the initialization package. Although in the compilation process in Release mode, Dart Compiler will use Tree-ShakingTo eliminate those packages, classes, functions, etc. that are introduced but not used, the package size is greatly reduced. But there is still some code in these SDKs that can be further optimized.

Taking Flutter Framework as an example, since it is a common module for all platforms, there is inevitably compatible logic for each platform (usually in the form of conditional judgments such as if-else and switch), and this part of the code cannot be used by Tree-Shaking Eliminated, we observe the following code:

// FileName: flutter/lib/src/rendering/editable.dartvoid _handleKeyEvent(RawKeyEvent keyEvent) {  if (kIsWeb) {    // On web platform, we should ignore the key.
    return;
  }  // Other codes ...}

The above code is selected from the RenderEditable class in the Framework. When the kIsWeb variable is true, it means that the current application runs on the Web platform. Limited by the mechanism of Tree-Shaking, in the above code, the compatible logic of other platforms, that is, the part of commenting Other codes cannot be eliminated, but this part of the code is Dead Code for the Web platform (which can never be Executed code), can be further optimized.

Figure 8 Part of the functional structure

The above figure shows a part of the functional composition of the SDK. It can be seen from the figure that these SDKs that FlutterWeb relies on include some functions that are used less frequently, such as support for functions such as Bluetooth, USB, WebRTC, and gyroscope. To this end, we provide the ability to customize these long-tail functions (these functions are not enabled by default, but the business is configurable), and the functions that are not enabled for the long-tail are tailored.

Through the above analysis, our idea is to cull the Dead Code twice and cut these long-tail functions. Based on this idea, we went deep into Dart-SDK, Framework and Flutter_Web_SDK to break down each, and finally reduced the size of JS Bundle products from 1.2M to 0.7M, laying a solid foundation for FlutterWeb page performance optimization.

Figure 9 Streamlined Results

4.1.3 SDK integrated CI/CD

In order to improve the construction efficiency, we customize the environment that FlutterWeb depends on as a Docker image and integrate it into the CI/CD (continuous integration and deployment) system. After the SDK is trimmed, we need to update the Docker image, which is time-consuming and inflexible. Therefore, we package Dart-SDK, Framework, and Flutter_Web_SDK to the cloud by version, read the CI/CD environment variable: sdk_version (SDK version number) before compiling, pull the SDK package of the corresponding version remotely, and replace the current Docker The corresponding modules in the environment are based on this solution to realize the flexible release of the SDK. The specific flow chart is shown in the following figure:

Figure 10 Integrated CI/CD

4.2 JS Fragmentation

After FlutterWeb is compiled, the main.dart.js file will be generated by default, which includes the SDK code and business logic, which will cause the following problems:

1. The function cannot be updated in time : In order to optimize the cache of the browser, our project has enabled strong caching of static resources. If the main.dart.js product does not support Hash naming, the program code may not be updated in time;

2. Unable to use CDN : FlutterWeb only supports the resource loading method of relative domain name by default, and cannot use CDN domain names other than the current domain name, resulting in the inability to enjoy the advantages brought by CDN;

3. Poor rendering performance of the first screen : Although we have downsized the SDK, the main.dart.js file remains above 0.7M. The loading and parsing time of a single file is too long, which will inevitably affect the rendering time of the first screen.

For the support of file hashing and CDN loading, we perform secondary processing on static resources in the flutter_tools compilation process: traverse static resource products, add file hash (MD5 value of file content), and update resource references; at the same time, by customizing Dart- SDK, modified the loading logic of static resources such as main.dart.js and fonts to support CDN resource loading.

For more detailed scheme design, please refer to "The Practice of Flutter Web in Meituan Takeaway"one article. Below we focus on some optimization strategies related to main.dart.js sharding.

4.2.1 Lazy Loading

Flutter officially provides deferred askeywords to implement lazy loading of Widgets, and dart2js can package lazy-loaded Widgets on demand during the compilation process. Such an unpacking mechanism is called Lazy Loading. With Lazy Loading, we can use deferred to import each route (page) in the routing table, so as to achieve the purpose of business code separation. The specific usage and effects are as follows:

// 使用方式import 'pages/index/index.dart' deferred as IndexPageDefer;
{  '/index': (context) => FutureBuilder(
    future: IndexPageDefer.loadLibrary(),
    builder: (context, snapshot) => IndexPageDefer.Demo(),
  )
  ... ...
}

Figure 11 Effect demonstration

After using Lazy Loading, the code of the business page will be split into multiple PartJS (corresponding to the xxx.part.js file in the figure). This seems to solve the problem of coupling between business code and SDK, but in the actual operation process, we found that every change of business code will still cause the compiled main.dart.js to change (the file Hash value changes) . After locating and tracking, we found that the changed part is the loading logic and mapping relationship of PartJS, which we call Runtime Manifest. Therefore, it is necessary to design a scheme to extract the Runtime Manifest to ensure that the modification of the business code has the lowest impact on main.dart.js.

4.2.2 Runtime Manifest extraction

Through the separation of business code, the main.dart.js file consists of SDK and Runtime Manifest:

Figure 12 main.dart.js composition

So how can the Runtime Manifest be extracted? Compared with conventional web projects, our approach is to extract basic dependencies such as SDK, Utils, and tripartite packages, and use packaging tools such as Webpack and Rollup to extract and assign a stable Hash value. At the same time, the Runtime Manifest (loading logic and mapping relationship of fragmented files) is injected into the HTML file, which ensures that changes in business code will not affect the public package. With the help of the compilation ideas of conventional web projects, we deeply analyzed the generation logic of Runtime Manifest and the loading logic of PartJS in FlutterWeb, and customized the following solutions:

Figure 13 Runtime Manifest extraction

In the above figure, the generation logic of the Runtime Manifest is located in the Dart2JS Compiler module. In this generation logic, we mark the Runtime Manifest code block, and then extract the marked Runtime Manifest code block in flutter_tools and write it into the HTML file (exists as JS constants). In the loading process of PartJS, we changed the way of reading the manifest information to the acquisition of JS constants. According to this split method, changes to the business code will only change the Runtime Manifest information, but will not affect the main.dart.js public package.

4.2.3 main.dart.js slice

After the introduction of Lazy Loading and Runtime Manifest extraction above, the size of the main.dart.js file is stable at about 0.7M, and the browser will have a heavy network load when loading a large-volume single file, so we designed a slicing scheme. Make full use of the browser's feature of parallel loading of multiple files to improve the loading efficiency of files.

The specific implementation plan is: split main.dart.js into multiple plain text files during the flutter_tools compilation process, load the front-end in parallel through XHR, and splicing them into JavaScript code in order and place them in the <script> tag, thereby realizing slicing files parallel loading.

Figure 14 Parallel loading

4.3 Preloading scheme

As mentioned in the previous section, although we have done a lot of work to stabilize the content of main.dart.js, under the operating mechanism of Flutter Tree-Shaking, each project references different Framework Widgets, which will lead to the main generated by each project. .dart.js content is inconsistent. As more and more projects are connected to FlutterWeb, the probability of mutual visits between pages of each business is getting higher and higher. Our expectation is that when accessing business A, the main.dart.js referenced by business B can be cached in advance, so that When the user actually enters the B business, the time for loading resources can be saved. The following is the detailed technical solution.

4.3.1 Technical solutions

We divide the overall technical solution into three stages: compiling, monitoring, and running.

1. In the compilation stage, according to the matching rules customized in the early stage, the qualified resource file paths are screened out on the release pipeline, and the cloud JSON is generated and uploaded;

2. In the monitoring phase, after DOMContentLoaded, monitor network resources, events, and DOM changes, and analyze and weight the monitoring results according to specific rules to obtain a status indicator that the first screen is loaded;

3. In the running phase, after the first screen is loaded, the cloud JSON file issued by the configuration platform is parsed, and HTTP XHR preloads the resources that meet the configuration rules, so as to realize the pre-cache function of the file.

The following figure shows the overall solution design of pre-cache:

Figure 15 Pre-cache scheme design

compile phase

The compilation phase will expand the existing release pipeline, and add the prefetch build job after the flutter build, so that after the build, the product directory can be traversed and filtered to obtain the resources we need and then generate the cloud JSON, which provides the data foundation for the running phase. The following flowchart is a detailed scheme design for the compilation phase:

Figure 16 Pre-cache compilation phase

The compilation phase is divided into three parts:

1. The first part: According to different publishing environments, initialize the online/offline configuration platform to prepare for the reading and writing of configuration files;

2. The second part: download and parse the resource group JSON issued by the configuration platform, filter out the resource paths that meet the configuration rules, update the JSON file and publish it to the configuration platform;

3. The third part: inject PROJECT_ID and the publishing environment into the HTML file through the API provided by the publishing pipeline, and provide global variables for the running phase to read.

Through the integration of the pipeline compilation period, we can generate a new cloud JSON and upload it to the cloud, providing a data basis for the distribution in the running phase.

listening phase

We know that the number of concurrent file requests by the browser is limited. In order to ensure that the browser's rendering of the current page is at a high priority and can complete the pre-cache function, we have designed a set of caching files. Loading strategy , to implement the loading operation of the cached file without affecting the current page loading. The following are the detailed technical solutions:

Figure 17 Pre-cache listening phase

After the page DOMContentLoaded, we will monitor the changes of the three parts.

1. The first part is listening for DOM changes. This part is mainly after the Ajax request occurs on the page, with the change of the MV mode, the DOM will also change. We use the MutationObserver API provided by the browser to collect DOM changes, filter valid nodes for depth-first traversal, and calculate the recursive weight value of each DOM. If the value is lower than the threshold, we consider the first screen to be loaded.

2. The second part is to monitor resource changes. We use the PerformanceObserver API provided by browsing to filter out the resources of the img/script type. When the resources collected within 3 seconds do not increase, we consider that the first screen has been loaded.

3. The third part is to listen to the Event event. When the user interacts with click, wheel, touchmove, etc., we think that the current page is in an interactive state, that is, the first screen loading has been completed, which will pre-cache resources in the future.

Through the above steps, we can get a timing when the first screen rendering is completed, and then we can implement the pre-cache function. The following is the implementation of the pre-cache function.

run phase

The overall process of pre-cache is: download the cloud JSON generated in the compilation phase, parse out the CDN path that needs to be pre-cached resources, and finally request the cache resources through HTTP XHR, and use the browser's own caching strategy to store other business resource files write. When a user visits a page that has hit the cache, the resource has been loaded in advance, which can effectively reduce the loading time above the fold. The following figure shows the detailed scheme design of the operation phase:

Figure 18 Pre-cache run phase

In the listening phase, we can get the time when the first screen rendering of the page is completed, and we will get the cloud JSON. First, we can judge whether the cache of the project is enabled. When the project is available, the resource array will be matched according to the global variable PROJECT_ID, and then pre-visited by HTTP XHR, and the cached file will be written into the browser cache pool. So far, resource pre-cache has been executed.

4.3.2 Effect display and data comparison

When the mutual access between pages hits the pre-cache, the browser will return data in the form of 200 (Disk Cache), which saves a lot of resource loading time. The following figure shows the resource loading after hitting the cache:

Figure 19 Pre-cache effect display

At present, 10+ pages of Meituan’s takeaway business have been connected to the pre-cache function. The average value of 90 lines of resource loading has dropped from 400ms to 350ms, a decrease of 12.5%; the average of 50 lines has dropped from 114ms to 100ms, a decrease of 100ms. 12%. As more and more projects are accessed, the effect of pre-cache will become more and more obvious.

Figure 20 Pre-cached data display

4.4 Packaging by platform

As mentioned above, most of Meituan's food delivery businesses are double-ended. In order to maximize efficiency, we have strengthened the multi-platform adaptation capability of FlutterWeb to realize the reuse of FlutterWeb on the PC side.

In the process of PC adaptation, we inevitably need to write compatible code on both ends, such as: in order to realize the reuse of card components in the list page. To this end, we have developed an adaptation tool, ResponsiveSystem, which is passed to each end of the PC and App respectively, and the internal platform will be differentiated to complete the adaptation:

// ResponsiveSystem 使用举例Container(
  child: ResponsiveSystem(
    app: AppWidget(),
    pc: PCWidget(),
  ),
)

The above code can easily realize the adaptation of PC and App, but AppWidget or PCWidget will not be removed by Tree-Shaking during the compilation process, so it will affect the package size. In this regard, we will optimize the compilation process and design a sub-platform packaging scheme:

Figure 21 Packaging by platform

1. Modify flutter-cli to support the --responsiveSystem command line parameter;

2. We have added additional processing in the AST analysis phase in flutter_tools: matching the ResponsiveSystem keyword, and rewriting AST nodes in combination with the compilation platform (PC or Mobile);

3. After removing useless AST nodes, generate code snapshots for each platform (each snapshot only contains code for a single platform);

4. According to the code snapshot compilation, two sets of JS products, PC and App, are generated, and resources are isolated. For public resources such as images and fonts, we put them into the common directory.

In this way, we remove the useless codes of the respective platforms and avoid the package size problem caused by the PC adaptation process. Still taking the classroom business (6 pages) of Meituan takeaway merchants as an example, after accessing the sub-platform and packaging, the code size of a single platform is reduced by about 100KB.

Figure 22 Effect display

4.5 Simplified icon fonts

When visiting a FlutterWeb page, even if the Icon icon is not used in the business code, a 920KB icon font file is loaded: MaterialIcons-Regular.woff. Through exploration, we found that some system UI components in the Flutter Framework (such as: CalendarDatePicker, PaginatedDataTable, PopupMenuButton, etc.) use the Icon icon, and Flutter provides a full amount of Icon icon font files for the convenience of developers.

The --tree-shake-iconscommand is to merge the Icon used by the business with a reduced font file (about 690KB) maintained internally by Flutter, which can reduce the size of the font file to a certain extent. What we need is the Icon that is only used by the packaging business, so we tree-shake-iconsoptimized and designed an on-demand packaging solution for Icon:

Figure 23 The icon font is simplified

1. Scan all business codes and dependent Plugins, Packages, Flutter Framework, and analyze all icons used;

2. Compare all scanned Icons with material/icons.dart (this file contains the unicode encoding collection of Flutter Icons), and get a simplified icon encoding list: iconStrList;

3. Use the FontTools tool to generate the iconStrList font file .woff, the font file at this time only contains the really used Icon.

Through the above solutions, we solved the package size problem caused by too large font files. Taking the Meituan takeaway classroom business (5 Icons are used in the business code) as an example, the font file was reduced from 920KB to 11.6kB.

Figure 24 Effect display

V. Summary and Outlook

To sum up, we have explored and practiced FlutterWeb performance optimization based on HTML Render mode, mainly including the streamlining of SDK (Dart-SDK, Framework, Flutter_Web_SDK), and optimization of static resource products (for example: JS fragmentation, file hash, fonts) Icon files are simplified, packaged by platform, etc.) and front-end resource loading optimization (preloading and on-demand request). In the end, the JS product was reduced from 1.2M to 0.7M (non-business code), and the page full load time TP90 line was reduced from 6s to 3s . This result has been able to meet most of the business requirements of Meituan takeaway merchants. The future planning will focus on the following three directions:

1. Reduce the cost of adaptation on the web side : Currently, 9+ businesses have used MTFlutterWeb to achieve multi-terminal multiplexing, but there is still room for optimization in the adaptation efficiency on the web side (especially the PC side), and the goal is to reduce the adaptation cost to 10% Below (currently around 20%);

2. Build a FlutterWeb disaster recovery system : Flutter dynamic packages have a certain probability of loading failure, and FlutterWeb, as a bottom-up solution, can improve the loading success rate of the overall business. In addition, FlutterWeb can provide the ability to "install-free update", reducing the maintenance cost of the old historical version of FlutterNative;

3. Continuous advancement of performance optimization: The phased results of performance optimization have consolidated the foundation for the application promotion of MTFlutterWeb, but there is still room for further optimization. The package also affects the hit rate of the browser cache to a certain extent. Extracting this part of the code can further improve the page loading performance.