The small program chooses the rendering mode of Hybrid, and divides UI rendering and JavaScript script execution into two threads.

Two-thread model

The rendering layer and logic layer of the applet are managed by two threads:

  • Render layer: all tasks related to interface rendering are inWebViewExecute in thread. A small program has more than one interface, so there are more than one rendering layerWebViewThreads.
  • Logical layer: adoptedJsCoreThreads run JS scripts, which execute code about the business logic of applets in this environment.

Communication between two threads

We all know that applets avoid DOM manipulation and instead use data-driven rendering, so how does it update the DOM by changing the data?

The communication between the logic layer and the rendering layer will be transferred by Native (wechat client), and the network request sent by the logic layer will also be forwarded by Native. The interaction and communication between logic layer and rendering layer can be realized by converting WXML into data and forwarding through Native.

  1. In the rendering layer, WNML is converted into Js objects, which simulate the DOM tree
  2. When the logical layer updates data, the setData method is used to forward data from the logical layer to Native, and then Native to the rendering layer
  3. At this point, the differences between the two virtual DOM trees are compared, and finally the differences are applied to the real DOM tree to update the page.

Virtual DOM is believed to have been understood by everyone, which is probably the process: using JS objects to simulate the DOM tree -> compare the differences between two Virtual DOM trees -> apply the differences to the real DOM tree.

The life cycle of a small program

The life cycle of applets borrows from the Android life cycle, and if you know anything about Android APP development, it’s easy to understand.

Interface threads have four states:

  • Initialization state: initialization interface thread needs to work, including the working mechanism, basically has nothing to do with us developers, such as the completion of initialization to the “service thread” to send the initialization signal, and then enter the state waiting for the return of initialization data.

  • First render state: After receiving initialization data from the “server thread” (i.e., json and JS data), the applet interface is rendered. After rendering, the “first render complete signal” is sent to the server thread and the page is displayed to the user.

  • Continuous rendering state: The interface thread continues to wait for the interface data sent by the “server thread” via this.setData () and re-renders the interface as soon as it receives it, so the interface updates automatically as soon as the data is updated and signals are sent.

  • End state: End render.

Five states of service threads:

  • Initialization state: there is no need to communicate with other modules and it is not related to applets development. This stage is the basic function needed to start the service thread, such as the signal sending module. After system initialization is complete, call custom onload and onshow, and wait for the interface thread “interface thread initialization is complete” signal.

Onload is executed only once on the first rendering, onshow is executed every interface switch, simple to understand, that’s the only difference.

  • Waiting for activation: After receiving the “interface thread initialization completed” signal, the initialization data is sent to the “interface thread”, waiting for the interface thread to complete the initial rendering.

  • Active state: After receiving the “first render complete” signal from the interface thread, it enters the active state, i.e. the normal running state of the program, and calls the custom onReady() function.

In this state, the user can use the this.setData function to send interface data to the interface thread for local rendering, updating the page.

  • Background running state: if the interface enters the background, the service thread enters the background running state. From the current official interpretation, this state is very strange, and the active state is the same, and the interface can also be updated by setData function. After all, the framework of the small program has just been launched, should be very different afterwards.

Operation mechanism

Start the

  • Hot start: if the user has opened a small program, and then in a certain period of time to open the small program again, at this time do not need to restart, just switch the background state of the small program to the foreground, this process is hot start;
  • Cold start: the user opens it for the first time or opens it again after the mini program is actively destroyed by wechat. In this case, the mini program needs to be reloaded and started, that is, cold start.

The destruction

Only when the small program into the background for a certain amount of time, or system resources too high, will be truly destroyed.

Update mechanism

After the developer releases a new version in the background, it cannot immediately affect all users of the live network, but in the worst case, it can send the new version information to users within 24 hours after the release.

Each time a small program is cold started, the system checks whether there is an updated version. If a new version is found, the system asynchronously downloads the code package of the new version and starts the program with the local package of the client. That is, the small program of the new version will be applied only after the next cold start.

So if you want to let users use the latest version of the small program, you can use wx.getUpdateManager to do a check for updates