Mini Program Optimization Suggestions

Currently, the mini program optimization suggestions provide two performance analysis tools, an experience rating plug-in, and several performance optimization suggestions, which Hangzhou mini program developers can refer to for use.

setData

setData is the most frequently used interface in mini-program development, and it is also the interface that is most likely to cause performance issues. Before introducing common incorrect usage, let's briefly introduce the working principle behind setData.

How it works

The view layer of the mini program currently uses WebView as the rendering carrier, while the logic layer uses an independent JavascriptCore as the running environment. Architecturally, WebView and JavascriptCore are independent modules and do not have channels for direct data sharing. Currently, data transmission between the view layer and the logic layer is actually implemented through the evaluateJavascript provided by both sides. That is, the data transmitted by the user needs to be converted into a string and transmitted. At the same time, the converted data content is spliced ​​into a JS script, and then transmitted to the two independent environments by executing the JS script.

The execution of evaluateJavascript is affected by many factors, and the data does not reach the view layer in real time.

Common setData operation errors

1. Frequently setData

In some cases we have analyzed, some mini programs setData very frequently (in milliseconds), which leads to two consequences:

On Android, users will feel lag when sliding, and the operation feedback is seriously delayed because the JS thread is always compiling and rendering, and fails to pass the user operation events to the logic layer in time, and the logic layer is also unable to pass the operation processing results to the view layer in time;
There is a delay in rendering. Since the JS thread of WebView is always busy, the communication time from the logic layer to the page layer increases. When the view layer receives the data message, hundreds of milliseconds have passed since it was sent, and the rendering result is not real-time.

2. Each setData pass a large amount of new data

From the underlying implementation of setData, we can see that our data transmission is actually an evaluateJavascript script process. When the amount of data is too large, it will increase the compilation and execution time of the script and occupy the WebView JS thread.

3. SetData on the background page

When the page enters the background state (invisible to the user), you should not continue to setData. The user cannot feel the rendering of the background state page. In addition, settingData on the background state page will also preempt the execution of the foreground page.

Image Resources

Currently, the main performance issues of image resources are large images and long list images. Both of these situations may cause the memory usage of the iOS client to increase, thereby triggering the system to recycle the mini program page.

The impact of images on memory

On iOS, the pages of mini programs are composed of multiple WKWebViews. When the system memory is tight, some WKWebViews will be recycled. From the cases we analyzed in the past, the use of large images and long list images will cause WKWebView to be recycled.

The impact of images on page switching

In addition to memory issues, large images can also cause page switching lags. In the cases we have analyzed, some mini-programs reference large images in the page, which will cause frame drops and freezes when switching back and forth on the page.

We currently recommend that developers minimize the use of large image resources.

Optimizing code package size

At the beginning, the code package of the mini program was limited to 1MB, but we received a lot of feedback that the code package size was not enough. After evaluation, we relaxed this limit and increased it to 2MB. The increase in the code package limit will enable developers to achieve richer functions, but for users, it will also increase download traffic and local space usage.

When implementing business logic, developers must also minimize the size of the code package, because the size of the code package directly affects the download speed, thereby affecting the user's first opening experience. In addition to the refactoring optimization of the code itself, you can also optimize the code size from the following two aspects:

Controlling image resources in code packages

After the mini program code package is compiled, it will be placed on WeChat's CDN for users to download. CDN has GZIP compression enabled, so users download the compressed GZIP package, which is smaller than the original size of the code package. However, when we analyzed the data, we found that the code package compression ratios between different mini-programs vary greatly, with some reaching 30% and others only 80%. One reason for this difference is the use of image resources. GZIP works best on text-based resources, often achieving compression rates of 70%-80% on larger files, but has little effect on already compressed resources (such as most image formats).

Clean up unused code and resources in a timely manner

During daily development, we may introduce some new library files, and after a period of time, we no longer use this library for various reasons. We often just remove the references in the code and forget to delete such library files. Currently, when packaging a mini program, all files under the project will be included in the code package. In other words, those library files and resources that are not actually used will also be included in the code package, thus affecting the size of the overall code package.