Runtime performance

setData

setData is 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 how 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 provided on 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 execution of evaluateJavascript is affected in many ways, and data reaching the view layer is not real-time.

Common setData operation errors

1. Frequent go to setData

In some of the cases we analyzed, some of the small programs went to setData very frequently (milliseconds), with two consequences:

• Android users will feel Caton when sliding, operation feedback delay is serious, because the JS thread has been compiling to perform rendering, failed to pass user action events to the logical layer in a timely manner, the logical layer can not timely transfer the results of the operation processing to the view layer in a timely manner;
• 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

It is known from the bottom layer of SETDATA. Our data transfer is actually an evAlateJavascript script process. When the amount of data is too large, the compilation execution time of the script will be added, and the WebView JS thread is occupied.

3. Backstand page for setData

When the page enters the background state (user is not visible), you should not continue to perform SetData. The rendering user of the background state page is unparent, and the rear top page will go to SetData 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 made up of multiple WKWebViews, which are recycled when the system is running out of memory. From the cases we've analyzed in the past, the use of large and long-list images can lead to the recycling of WKWebView.

The effect of the picture on page switching

In addition to memory problems, large pictures can also cause the page to switch between Catons. In some of the cases we analyzed, some of the small programs referenced large pictures on the page, and in the page back switch, the case of falling frames of Caton appears.

Currently, we recommend that developers minimize the use of large picture resources.