Some Suggestions on Small Program Optimization of Summary

2021-10-13 06:28:52
OfStack

setData

setData is the most frequently used interface in applet development, and it is also the interface that is most likely to cause performance problems. Before introducing common wrong usage, let's briefly introduce the working principle behind setData under 1.

Working principle

The view layer of the applet currently uses WebView as the rendering carrier, while the logic layer is run by a separate JavascriptCore. Architecturally, WebView and JavascriptCore are independent modules, and do not have a channel for direct data sharing. Currently, the data transfer between the view layer and the logic layer is actually realized through evaluateJavascript provided on both sides. That is to say, the data transmitted by users needs to be converted into string form and transmitted. At the same time, the converted data content is spliced into an JS script, and then transmitted to independent environments on both sides by executing JS script.

However, the execution of evaluateJavascript will be affected by many aspects, and the data arriving at the view layer is not real-time.

Common setData Operation Errors

1. Go to setData frequently

In one of the cases we analyzed, some small programs will go to setData very frequently (in milliseconds), which leads to two consequences:

Under Android, users will feel stuck when sliding, and the operation feedback delay is serious, because JS thread 1 is compiling and performing rendering directly, which fails to transfer user operation events to the logical layer in time, and the logical layer cannot transfer operation processing results to the view layer in time; There is a delay in rendering. Because JS thread 1 of WebView is in a busy state, the communication time from logical layer to page layer increases. When the view layer receives the data message, it has passed hundreds of milliseconds away from the sending time, and the rendering result is not real-time;

2. Each setData delivers a lot of new data

From the bottom 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 WebView JS threads.

3. setData is performed on the background page

When the page enters the background state (invisible to the user), it should not continue to carry out setData. The rendering of the background page cannot be felt by the user. In addition, going to setData of the background page will preempt the execution of the foreground page.

Picture resource

At present, the main performance problem of picture resources lies in large pictures and long list pictures, both of which may lead to an increase in memory usage of iOS client, thus triggering the system to recycle applet pages.

Influence of pictures on memory

Influence of pictures on page switching

In addition to memory problems, large pictures can also cause page switching to jam. In the case we analyzed, one part of the small program will reference the big picture in the page, and the frame will drop and get stuck in the page backward switching.

At present, we suggest that developers minimize the use of large picture resources.

Optimization of code package size

Applet 1 started with a code package limit of 1MB, but we received a lot of feedback that the code package size was not enough. After evaluation, we let go of this limit and increased it to 2MB. The increase of code package upper limit can realize richer functions for developers, but it also increases download traffic and local space occupation for users.

It is necessary for developers to minimize the size of code packages while implementing business logic, because the size of code packages directly affects the download speed, thus 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 these two aspects:

Control the picture resources in the code package

After compiling, the applet code package will be placed on CDN of WeChat for users to download. CDN starts GZIP compression, so users download the compressed GZIP package, which is smaller than the original size of the code package. However, when we analyze the data, we find that the compression ratio of code packages between different applets is quite different, some of which can reach 30%, while the other is only 80%. One reason for this difference is the use of picture resources. GZIP works best for text-based resource compression, often up to 70%-80% when compressing larger files, but has little effect on already compressed resources (such as most picture formats).

Clean up unused code and resources in time

In our day-to-day development, we may have introduced a new library file, and after a period of time, due to various reasons, we no longer use this library. We often just remove the references in the code and forget to delete this kind of library file. At present, small program packaging will put all files under the project into the code package, that is to say, these library files and resources that are not actually used will also be put into the code package, thus affecting the size of the overall code package.

WXS Module

Each wxs module has one built-in module object.
Directly introduced in wxml, it can write the data that needs to be converted, so as to prevent the burden on setData

Excessive number of WXML nodes used

One too large WXML node tree will increase memory usage, and the style rearrangement time will be longer. It is recommended to use less than 1000 WXML nodes per page, with a node tree depth of less than 30 layers and no more than 60 child nodes

Applets have concurrency restrictions

The maximum concurrency limit for wx. request, wx. uploadFile, wx. downloadFile is 10.

To be on the safe side, adopt common methods and components

Writing common methods and components can avoid repeated wheel building.
1. Common burial point method
2. Various methods of treating js (https, throttle, formatTime, etc.)
3. Common components (iphonex compatible components, countdown components, etc.)

You need to write a request queue, and if the concurrency is greater than 10, you will wait for the request.

Buried pit

Embedding points using common methods, page exposure pv embedding points into the onshow life cycle more accurately.

setData Note

1. Frequent removal of setData
There are variables that will not be bound to WXML that need not be passed into setData.

2. Each setData transmits a large amount of new data, which can be updated locally


this.setData({
  list[index] = newList[index]

})

3. setData is performed on the background page