Shulou(Shulou.com)05/31 Report--

This article focuses on "WeChat Mini Programs rendering performance tuning methods", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn "WeChat Mini Programs rendering performance tuning method"!

Dual-threaded architecture of Mini Program

The biggest difference between Mini Program and traditional browser Web pages is that Mini Program is based on the dual-threaded model, in which the render layer of Mini Program uses WebView as the rendering carrier, while the logical layer runs JS scripts by independent JsCore threads, and the two sides do not have a channel for direct data sharing, so the communication between the render layer and the logical layer is mediated by the JSBrigde of Native.

The communication flow of Mini Program updating view data

Whenever the Mini Program view data needs to be updated, the logical layer will transfer the data from the logical layer to the view layer by calling the setData method provided by the Mini Program host environment, and complete the UI view update after a series of rendering steps. The complete communication process is as follows:

The Mini Program logic layer calls the setData method of the host environment.

The logical layer executes JSON.stringify to convert the data to be transferred into strings and concatenate it to a specific JS script, and transfers the data to the render layer through the evaluateJavascript execution script.

After the rendering layer receives it, the WebView JS thread compiles the script, gets the data to be updated, and enters the rendering queue for page rendering when the WebView thread is idle.

When the WebView thread starts rendering, the data to be updated is merged into the original data data retained by the view layer, and the new data is applied to the WXML fragment to get a new virtual node tree. After comparing the diff of the new virtual node tree with the current node tree, update the differences to the UI view. At the same time, replace the old node tree with the new node tree for the next re-rendering.

Some causes of rendering performance problems

In the above communication process, some inappropriate actions may affect the performance of page rendering:

SetData transmits a lot of new data

Data transmission will go through the process of cross-thread transmission and script compilation. When the amount of data is too large, it will increase the execution time of script compilation and occupy WebView JS threads.

The following figure shows a set of test statistics: the time it takes for each model to perform setData operations on data of 1KB, 2KB and 3KB in the same network environment.

As can be seen from the figure, the greater the amount of setData data transmission, the more time it takes to transfer data.

Perform setData operations frequently

Frequent setData execution keeps the WebView JS thread busy with script compilation, node tree comparison calculation, and page rendering. The result is:

There is a certain delay in the rendering of the page.

When the user triggers the page event, the feedback is delayed because the WebView JS thread is busy and the user event is not transmitted to the logical layer in time.

Too many page nodes

During the initial rendering of the page, the construction of the rendering tree, the calculation of node geometry and the time cost of drawing nodes to the screen are all positively related to the number of page nodes. The more the number of page nodes, the longer the rendering time.

Each time the setData updates the view, the WebView JS thread traverses the node tree to calculate the difference between the old and new nodes. The more the number of page nodes, the greater the time cost of computing. Reducing the number of node tree nodes can effectively reduce the time cost of re-rendering.

Rendering performance optimization

Based on the causes of rendering performance problems, we can develop some optimization strategies to avoid performance problems.

SetData optimization

As the medium of communication between logic layer and view layer, setData is the most likely to cause rendering performance bottleneck of API. We should follow some rules when using setData to avoid performance problems as much as possible:

Reduce the amount of setData data transmission

Only the data used by the view layer is transferred, and the data used by other JS environments is stored outside the data object.

Make rational use of local updates. SetData supports updating local fields of objects by using data paths. We may encounter such a scenario: the list list is the data obtained from the background and displayed on the page. When the src field of the first item of the list list needs to be updated, normally we will obtain a new list list from the background and execute setData to update the entire list list.

/ / the backend acquires the list data const list = requestSync (); / / updates the entire list this.setData ({list})

In fact, when only individual fields need to be updated, we can write this to avoid updating the entire list list:

/ / acquire list data const list = requestSync () at backend; / / locally update list this.setData ({'list [0] .src': list [0] .src})

Reduce the frequency of setData execution

Under the premise of not affecting the business process, multiple setData calls are merged to reduce the communication frequency between threads.

When you need to call setData in frequently triggered user events (such as PageScroll, Resize events), reasonable use of function anti-shake (debounce) and function throttling (throttle) can reduce the number of setData execution.

Function anti-shake (debounce): the function is executed only once after it is triggered for n seconds. If the function is triggered repeatedly within n seconds, the time is recalculated.

Function throttling (throttle): the function will only be triggered once per unit time. If the function is triggered multiple times in the same unit time, it will only take effect once.

In addition to allowing developers to consciously follow the rules to reduce the amount of setData data transmission and the frequency of execution, we can also design a diff algorithm to re-encapsulate setData, so that before setData execution, the data to be updated is compared with the original data data, the data difference patch object is calculated, and whether the patch object is empty is judged. If it is empty, skip the update, otherwise the patch object is setData. As a result, the amount of data transmission and the frequency of setData execution are reduced.

/ / setData is repackaged into a new method, so that the new and old data are compared by diff before data update, and then execute the setData method this.update = (data) = > {return new Promise ((resolve, reject) = > {const result = diff (data, this.data); if (! Object.keys (result) .length) {resolve (null); return;} this.setData (result, () = > {resolve (result);}) });}

Of course, you can directly refer to the ready-made high performance Mini Program setData diff algorithm here.

The specific process is shown in the following figure:

Make good use of custom components

The implementation of Mini Program custom components is supported by the Exparser framework officially designed by Mini Program. The component model of custom components implemented by the framework is similar to that of Shadow DOM in the Web Components standard:

After the page references the custom component, when the page is initialized, Exparser will instantiate the component according to the registration information of the custom component while creating the page instance, and then construct an independent Shadow Tree based on the data data and component WXML of the component, and append it to the page Composed Tree. The created Shadow Tree has its own independent logical space, data, style environment and setData calls:

Based on the Shadow DOM model design of custom components, we can encapsulate some functional modules in the page that need to perform setData updates frequently (such as countdown, progress bar, etc.) into custom components and embed them into the page. When these custom component views need to be updated, the component's own setData is executed. The comparison calculation of the new and old node tree and the update of the rendering tree are limited to a limited number of nodes in the component, which can effectively reduce the rendering time overhead.

The following figure shows how long it takes to update setData before and after the countdown module extracts the custom components in the Mini Program WeDrive homepage of the Mini Insurance:

As can be seen from the figure, after using custom components, the average rendering time of the countdown module setData has been significantly reduced, and the actual experience in the low-end Android machine will feel much more smooth.

Of course, it is not that the more custom components are used, the better. For each new custom component added to the page, Exparser needs to manage one more component instance, resulting in greater memory consumption. When the memory consumption rises to a certain extent, it may cause iOS to recycle part of the WKWebView, and the Android experience will become more stuttered. Therefore, it is necessary to make reasonable use of custom components, and at the same time, page design should also be careful not to abuse tags.

At this point, I believe that everyone on the "WeChat Mini Programs rendering performance tuning method" have a deeper understanding, might as well come to the actual operation! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.