setData

setData the most frequently used interface in small program development and the most prone to performance problems. Before introducing common error usage, let's briefly describe setData works.

How it works

The view layer of the small program currently uses WebView as the rendering vector, while the logical layer is run by the independent JavascriptCore. A rchitecturally, WebView and JavascriptCore are separate modules and do not have channels for direct data sharing. C urrently, data transfer from the view and logical layers is actually done through evaluateJavascript both sides. That is, the data transferred by the user needs to be passed as a string, and the converted data content is stitched together into a JS script, which is then passed to both sides of the stand-alone environment by executing the JS script.

The evaluateJavascript is affected in many ways, and data reaching the view layer is not real-time. WebView within the same process actually shares a JS VM, and if the JS thread within the WebView is performing rendering or other logic, it affects the actual execution time of the evaluateJavascript script, and multiple WebViews preempt the execution rights of the JS VM;

Common setData operation errors

Frequent to setData

In some cases we have analyzed, some small procedures will be very frequent (milliseconds) setData It caused two consequences:

• Under Android slides, the user feels in the sliding, and the operation feedback is delayed, because the JS thread has been compiling to perform rendering, failed to transfer user operating events to the logic layer, the logical layer can also pass the operation processing results in time to time.View layer;
• The rendering has a delay, since the WebView's JS thread has been busy, the logical layer to the page layer has risen, and the data message received by the view layer has passed a few hundred milliseconds, the result of rendering is notreal time;

2. Each SETDATA passes a large number of new data

Depend on setData The underlying implementation is known, our data transfer is actually once evaluateJavascript The script process, when the amount of data is too large, the script is increased, and the WebView JS thread is occupied.

3. Backstand page for setData

When the page enters the background state (user is not visible), should not continue setData The rendering user of the background state page is unparent, and the rear top page is going. setData It will also seize the execution of the front page.

Picture resource

The main performance problem of current picture resources is on large pictures and long list pictures, both of which may cause the iOS client memory to rise, thus triggering the system recycling applet.

Image on memory

On iOS, the page of the applet is composed of multiple WkWebView. When the system memory is tight, a part of WKWebView is recovered.From the previous case, the use of large pictures and long lists can cause the WkwebView recycling.

Image on page switching

In addition to memory problems, large pictures will also cause the tattone of the page.In the case, some small programs will reference the big picture in the page, and the frames will appear in the page.

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

Code package size optimization

The small program started with a 1MB code pack limit, but we received a lot of feedback that the code pack was not large enough, and after evaluation we let go of this limit and increased it to 2MB. The increase in the code pack cap provides richer functionality for developers, but also increases download traffic and local space usage for users.

While implementing business logic, it is also necessary for developers to minimize the size of the code pack, which directly affects the download speed and thus the user's first opening experience. In addition to the refactoring optimization of the code itself, you can also start by optimizing the code size in two ways:

Control the picture resources within the code pack

After the small package is compiled, it will be placed on WeChat's CDN for the user to download, the CDN turned on GZIP compression, so the user downloads the compressed GZIP package, its size will be smaller than the original size of the code package. B ut our analysis of the data found that the code package compression ratio between different small programs is also quite different, some can reach 30%, and some only 80%, and one reason for this difference is the use of picture resources. GZIP is best compressed against text resources, often by up to 70%-80% when compressing larger files, but with little effect on already compressed resources, such as most picture formats.

Clean up unavailable code and resources in a timely manner

In day-to-day development, we may have introduced some new library files, and after a while, for various reasons, we no longer use the library, we often just remove the references in the code, and forget to delete such library files. At present, small program packaging is to put all the files under the project into the code package, that is, these library files and resources that are not actually used are also into the code package, which affects the size of the overall code package.