Mini Program Operation Mechanism

It all starts with two threads

-Technical selection
At present, there are three main ways of page rendering :

1. Web rendering
2. Native native rendering
3. Both Web and Native are mixed, which is what we often call Hybrid rendering

Let's take a look at the previous expectations of the mini program:

• Development threshold: Web threshold is low, but Native also has framework support like RN
• Experience: Native experience is not much better than Web, Hybrid is closer to native experience than Web to a certain extent
• Version update: Web supports online updates, while Native needs to be packaged into WeChat for review and release
• Control and security: the web can jump or change the content of the page, there are some uncontrollable factors and security risks

Since the host of the applet is WeChat, if you use pure client-side native technology to write the applet, the applet code needs to be packaged together with the WeChat code, and the version is released following WeChat. This method is bound to be wrong with the development rhythm.
So the direction should be like Web technology, there is a resource package that can be updated at any time on the cloud, by downloading it to the local, the interface can be rendered after dynamic execution.

If you use pure Web technology to render small programs, you may face some performance problems on some pages with complex interactions.
This is because in Web technology, UI rendering and JavaScript script execution are executed in a single thread, which easily leads to some logical tasks preempting UI rendering resources.

In general, the Mini Program has chosen the Hybrid rendering method, which can be developed in a similar way to the Web, and it can also be used to update the code online. At the same time, the introduction of native components has the following benefits:

Extend the capabilities of the Web. For example, input box components (input, textarea) have the ability
to better control the keyboard, and the experience is better, while also reducing the rendering work of the WebView.
Bypassing the setData, data communication and re-rendering process, making the rendering performance better.
Now, we have left The next very important issue: control and safety. Thus, the dual-threaded design was proposed.

-Two-threaded applet

I don't know which big guy can come up with a dual-threaded model. Anyway, I admire 666.

What is dual thread? Let's first look at an official picture:

The rendering layer and logic layer of the applet are managed by two threads respectively: the interface of the rendering layer uses WebView for rendering, and the logic layer uses JsCore threads to run JS scripts.

Why is it designed like this? The aforementioned control and security, in order to solve these problems, we need to prevent developers from using some open interfaces provided by browsers, such as jumping pages, manipulating DOM, and dynamically executing scripts.

We can use the JavaScript engine of the client system, the JavaScriptCore framework under iOS, and the JsCore environment provided by Tencent's x5 kernel under Android. It is solved by providing a sandbox environment to run the developer's JavaScript code. This sandbox environment only provides a pure JavaScript interpretation and execution environment, without any browser-related interfaces.

This is the origin of the dual-thread model of small programs:

• Logic layer: Create a separate thread to execute JavaScript. In this environment, code related to the business logic of the applet is executed.

• Rendering layer: All tasks related to interface rendering are executed in the WebView thread, and the logic layer code is used to control which interfaces are rendered. There are multiple interfaces in a small program, so there are multiple WebView threads in the rendering layer

• Two-threaded communication

Put the developer's JS logic code in a separate thread to run, but in the Webview thread, the developer cannot directly manipulate the DOM. How to implement dynamic interface changes?

As we know before, 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. Does this mean that we can update the DOM through simple data communication?

I believe everyone already knows about Virtual DOM. It is about this process: simulate the DOM tree with JS objects -> compare the differences between two virtual DOM trees -> apply the differences to the real DOM tree.

Here we can use it, as shown in the figure:

1. Convert WXML into the corresponding JS object in the rendering layer.
2. When data changes occur in the logic layer, the data is passed from the logic layer to the Native through the setData method provided by the host environment, and then forwarded to the rendering layer.
3. After comparing the differences before and after, apply the differences to the original DOM tree and update the interface.

We realize the interaction and communication between the logic layer and the rendering layer by converting WXML into data and forwarding it through Native. And such a complete set of frameworks are basically completed through the basic library of small programs.

• Basic library for applets

The basic library of the applet is written in JavaScript, which can be injected into the rendering layer and logic layer to run. Mainly used:

• In the rendering layer, various components are provided to form the elements of the interface
• At the logic layer, various APIs are provided to handle various logics
• Handle a series of framework logic such as data binding, component system, event system, communication system, etc.

Since the rendering layer and the logic layer of the applet are managed by two threads, the two threads are each injected into the basic library. ***The basic library of the applet will not be packaged in the code package of a certain applet, it will be built into the WeChat client in advance. ***this is okay:

• Reduce the code package size of business applets
• Bugs in the basic library can be fixed separately, without modifying the code package of the business applet

Exparser framework

Exparser is the component organization framework of WeChat Mini Programs. It is built into the Mini Program Basic Library and provides basic support for various components of the Mini Program. All components in the applet, including built-in components and custom components, are organized and managed by Exparser. Features of Exparser include:

1. Based on the Shadow DOM model: the model is
   highly similar to the ShadowDOM of WebComponents , but it does not rely on the native support of the browser, nor does it have other dependent libraries; during implementation, other APIs are specifically added to support small program component programming.
2. Can run in a pure JS environment: This means that the logic layer also has a certain ability to organize the component tree.
3. Efficient and lightweight: good performance, especially excellent in an environment with a lot of component instances, and the code size is also small.

For more information about the basic library and Exparser framework, you can also refer to: "Mini Program Development Guide"

Reprinted from: Front-end Encyclopedia, if there is any infringement, please contact the author to delete.