“This is the second day of my participation in the First Challenge 2022, for more details: First Challenge 2022”.

The front-end frame is too much dazzling, many similar places, excellent places we will learn from, but also have some of their own characteristics. Whether it’s small programs or other frameworks, you can learn a lot from understanding why they’re designed and how they work.

It all starts with two threads

Technology selection

In the previous section, “The Birth of a Small program,” we also talked about the dual-threaded design of a small program.

Currently, there are three main ways to render a page:

  1. Web rendering.
  2. Native rendering.
  3. Web and Native, also known as Hybrid rendering.

As mentioned earlier, the final presentation form of small programs is WebView + native components, Hybrid mode. Let’s combine our previous expectations for applets with:

  • Barriers to development: The Web is low, but Native also has support for frameworks like RN
  • Experience: Native experience is not much better than Web experience, Hybrid is closer to Native experience than Web experience to some extent
  • Version update: Web supports online update, while Native needs to be packaged to wechat for review and release
  • Control and security: The Web page can be redirected or changed, resulting in uncontrollable factors and security risks

Because the host of small program is wechat, if you use pure client native technology to write small program, the small program code needs to be packaged with wechat code, follow the wechat version, this way with the development pace is necessarily wrong. Therefore, the direction should be like the Web technology, with a resource package that can be updated at any time in the cloud, downloaded to the local, dynamic execution can render the interface.

If you render applets using pure Web techniques, you may face performance issues on pages with complex interactions. This is because in Web technology, BOTH UI rendering and JavaScript scripting are executed in a single thread, which can easily lead to some logical tasks preempting the RESOURCES of UI rendering.

In general, the applet chooses Hybrid rendering, can be developed in a similar way to the Web, and can also be updated online code. At the same time, introducing native components has the following benefits:

  • Extend the power of the Web. Components like input (textarea) have better control over the keyboard
  • The experience is better and the rendering of the WebView is reduced
  • Bypassing setData, data communication, and re-rendering processes for better rendering performance

Now, we are left with a very important issue: control and security. Thus, the two-threaded design was proposed.

Two – threaded small program

I don’t know who came up with this model, but I admire 666.

What is dual threading? Let’s start with the 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 to render, and the logic layer uses JsCore thread to run JS script.

Why do they do that? In order to address the aforementioned issues of control and security, we need to prevent developers from using open interfaces provided by browsers such as jumping to pages, manipulating the DOM, and executing scripts dynamically.

We can use the JavaScript engine of the client system, the JavaScriptCore framework under iOS, and the JsCore environment provided by Tencent X5 kernel under Android. Solve this problem by providing a sandbox environment to run the developer’s JavaScript code. This sandbox environment only provides a pure JavaScript interpretation execution environment without any browser-specific interfaces.

This is where the two-threaded model of applets comes in:

  • Logic layer: Create a separate thread to execute JavaScript, which executes code related to the business logic of the applet
  • Render layer: The tasks related to interface rendering are all performed in the WebView thread, with logic layer code controlling which interfaces are rendered. A small program has multiple interfaces, so the render layer has multiple WebView threads

Two thread communication

Put the developer’s JS logic code in a separate thread to run, but in the Webview thread, the developer can not directly manipulate the DOM. So how do you implement dynamic change interfaces?

As we know above, the communication between ** logic layer and rendering layer is transferred by Native (wechat client), and the network request sent by logic layer is also forwarded by Native. ** Does this mean we can update the DOM through simple data communication?

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.

Here we can use it, as shown below:

  1. Convert WXML into the corresponding JS object at the render layer.
  2. When data changes occur in the logical layer, the setData method provided by the host environment is used to transfer data from the logical layer to Native and then forward to the rendering layer.
  3. After comparing the differences before and after, the differences are applied to the original DOM tree and the interface is updated.

We realized 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 framework, basically are through the basic library of small procedures to complete.

Basic library of small programs

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

  • In the rendering layer, various components are provided to form the elements of the interface
  • At the logic layer, apis are provided to handle the logic
  • Handle data binding, component systems, event systems, communication systems, and a range of framework logic

Since the rendering layer and logic layer of the applet are managed by two threads, both threads inject the base library separately. ** The basic library of the small program will not be packaged in a small program code package, it will be built into the wechat client in advance. ** This will do:

  • Reduce the code package size of business applets
  • Bugs in the base library can be fixed individually without modifications to the business applets code package

Exparser framework

Exparser is the component organization framework of wechat small program, which is built into the basic library of small program and provides basic support for various components of small program. All components within the applets, both built-in and custom, are managed by the Exparser organization. Exparser features include:

  1. ShadowDOM model: The model is highly similar to WebComponents’ ShadowDOM, but it does not rely on browser’s native support, nor does it have other dependent libraries; When implemented, additional apis were added specifically to support applets component programming.
  2. Runs in a pure JS environment: this means that the logical layer also has some component tree organization capability.
  3. High efficiency and light weight: High performance, especially in environments with a large number of component instances, and small code size.

For more information about the base library and the Exparser framework, see the Small Program Development Guide.

conclusion

This section is about a relatively important model in small program design — double threads, about the emergence of double threads, design, data communication, to the basic library, Exparser framework, are all related and mutual influence of choice. About the basic framework design of small program, in fact, there are more and more we can not master the content of the moment, custom components, native components, and they have done a lot of performance optimization work, are not a word can be finished. All we can do is think more.