Analysis of the principle implementation from the source code of the mini-program developer tool

How to view the source code of Mini Program developer tools

Next, we will use the source code of the WeChat Mini Program developer tool to explain the underlying implementation principles of the Mini Program. Use the source code of the developer tool version number State v1.02.1904090 to peek into the implementation ideas of the mini program. How to view WeChat source code? For Mac users, view the package content of WeChat Mini Program Developer Tools, then go to Contents/Resources/app.nw/js/core/index.js, and comment out the following code to view the code rendered by the developer tools.

// Open the inspect window if (nw.App.argv.indexOf('inspect') !== -1) {
    tools.openInspectWin()
}

Then restart the mini program developer tool, and the following page on the left will appear. Click one of the pages to see the DOM structure of the view layer, as shown on the right side of the figure below.

Mini Program Architecture Design

1. Is the mini program rendering in the same thread? Dual thread mechanism

Anyone who has developed a mini program knows that the mini program is a dual-threaded design, that is, the view rendering and business logic run in different threads respectively. This design is mainly to solve a pain point in web technology:

The rendering thread and script thread of web page development are mutually exclusive. Long-term script running may cause the page to become unresponsive or display a white screen, resulting in a poor experience.

In order to provide a better experience, the Mini Program separates the page rendering thread and the script thread and executes them in different threads. The specific implementation is:

• The view layer is rendered in the webview, and one page corresponds to one webview
• The business logic Appservice layer runs in the same JSCore thread, specifically JavaScriptCore for iOS and X5 JSCore for Android, and the developer tools are in the webview;

This solves the problem of scripts blocking page rendering for a long time, but it also brings some new problems:

• Inherent delays, threads need to communicate
• The business logic layer cannot access DOM and BOM APIs because it runs in JSCore;

The developer tool uses webview to load the code of the business logic layer. Although the dependent environment has DOM and BOM APIs, in order to maintain consistency; the mini program localizes all modules so that they cannot access these APIs. In this way, the two threads pass through native, and the developer tool acts as a message transfer medium between the two through the background websocket service, and provides some basic functions. For details, please refer to the official website map:

2. Is the mini program web rendering? Interface rendering mechanism

There are three main ways to render a page:

• Pure web rendering
• Pure native rendering
• Hybrid rendering, which is a combination of web and native rendering

Because the host environment of the mini program is WeChat, it is unlikely to use pure native rendering, otherwise all mini programs need to be coded and released together with WeChat. It seems feasible to use pure web rendering, which supports fast online updates and can be rendered by installing the latest resources locally. However, pure web rendering may face some performance issues on some pages with complex interactions. This is because in web technology, UI rendering and JavaScript script execution are both executed in a single thread, which easily causes some logical tasks to occupy UI rendering resources. Therefore, the applet is rendered in Hybrid mode, as described on the official website:

The interface is mainly rendered by mature Web technology, supplemented by a large number of interfaces to provide rich client native capabilities.

At the same time, each mini program page is rendered using a different WebView, which can provide a better interactive experience, closer to the native experience, and avoid the task of a single WebView being too heavy.

Since Hybrid rendering is used, the page may be rendered using native rendering. Under what circumstances will native rendering be used?

The answer is to use components such as map, video, canvas, textarea, etc. provided by the mini program. The rendering principle of native rendering in the page can refer to the native components of the official website. However, in the mini program developer tools, native components are simulated using HTML tags. For details, see the map component rendering results in the next section.

3. Is the mini program rendered using web HTML tags? Exparser component framework

As mentioned above, mini programs are mainly rendered by mature web technologies. Can we directly use the tags provided by HTML, such as div, table, etc. to organize pages? The answer is no. Main considerations:

• Control and security: Web technology can obtain and modify sensitive content of pages or jump to other pages at will through scripts
• Limited capabilities will limit the presentation of mini programs
• There are many tags, which increases the cost of understanding.

Therefore, the mini program cannot directly use HTML tags to render pages. It provides more than 10 built-in components to converge web tags and provides a JavaScript sandbox environment to prevent js from accessing any browser API.

Since the mini program cannot directly use HTML tags to render pages, does it mean that the built-in components it provides, such as view and cover-view, will eventually be converted into built-in tags provided by HTML for rendering? The answer is no. Let's look at the following code:

<view class="map-container">
  <map latitude='39.9088230000' style="height: 100%; width:100%;" longitude='116.3974700000' scale='16' id="id" bindregionchange="onRegionChange"></map>
  <view catchtap="onTap">test</view>
</view>

The above code finally renders the elements in the developer tools as shown below:

It can be seen that the components provided by the mini program are not ultimately converted into corresponding HTML tags for rendering, but are rendered using custom elements. These built-in components are all managed by the Exparser framework, which is built into the mini-program basic library and provides basic support for various components of the mini-program.

The Exparser framework is based on the Shadow DOM model, which is highly similar to the ShadowDOM of WebComponents. For details, please refer to the official website component system.
The naming conventions of built-in components all start with wx-. External references to built-in components such as view will eventually call the underlying wx-view component; the view component of Exparser is created as follows:

4. Can mini programs operate DOM? Data-driven

For the sake of control and security, the mini program provides a JavaScript sandbox environment to run JavaScript code. The js code cannot access any browser-related interfaces, which means that js cannot operate dom and bom, otherwise it may report an error. How to implement sandbox environment for mini programs? That is, by encapsulating the business logic into a local environment, the local environment modifies the relevant API pointers of DOM and BOM. The specific packaging forms are as follows:

So the question is, how does the mini program add the above encapsulation to the business code? In fact, it is very simple. There is a background service in the mini program developer tool. When accessing the path of each module of the mini program, the background service will call the wrapSourceCodeInDefine method to wrap the content of the requested JS file in the define field. The code of the method is shown in the figure below:

The define method here is one of the methods to implement modularization at the bottom level of the mini program. Another one is the require method. Define is used to define a module, and require is used to reference a module defined by define. From the above applet's encapsulation of the business module code, we can see that:

The module defined by define passes APIs with the same names as browser-related interfaces, such as window, document, localStroage, etc. Some people may say that the global scope window object can be accessed through Function('return this')(), but the applet blocks this path, rewrites Function, and eval is reset to undefined. For example, the following figure:

When requiring a module, only require, module, and exports are passed. The values ​​of other parameters are undefined, and these interfaces cannot be accessed in business code.

You can look at the source code defined by require:

In the actual WeChat environment, the business logic layer runs in JSCore, which has no browser-related information and cannot access DOM. However, the mini-program developer tool uses webview to run business logic code, which has DOM-related interfaces. Therefore, the sandbox environment above is used to uniformly prevent JS from operating DOM.

If the business code cannot access the DOM, how can we dynamically update the page?

The answer is to adopt the data-driven idea of ​​MVVM framework like Vue, that is, to bind the view state and the view together. When the state changes, the view can also change automatically, so there is no need to directly operate the DOM.

The dynamic update of the view is implemented by virtual DOM technology. I believe everyone has already understood virtual DOM. The process is as follows:

The actual processing can be briefly described as follows:

Use JS objects to simulate the DOM tree -> compare the differences between the two virtual DOM trees -> apply the differences to the real DOM tree.

Among them, virtual dom can convert wxml into js object form through built-in wcc to represent the DOM tree structure.

The following is a picture from the official website to illustrate the process of dynamic view update:

// wxml
 <view>{{msg}}</view>

// js
data: {
   msg: 'Hello World'
} 

The above explains how the view is updated. In fact, in the process of data response, there is another most important link, that is, how the business logic layer synchronizes the changed data to the view layer. This involves dual-threaded communication.

5. What is the function of the mini program basic library?

When we develop mini programs in developer tools, we usually select a basic library, such as the mini program developer tool selection interface:

The mini program basic library is written in JavaScript, but we don’t directly reference it in our mini program. So how do we use the functions provided by the basic library? The answer is:

The WeChat host environment will have built-in basic libraries in advance. When you open a mini program, the basic libraries will be automatically injected into the view layer and business logic layer of the mini program. The mini program developer tools are injected by the underlying HTTP service.

The following figure shows the relevant code injected by the underlying HTTP service of the applet through the script:

The basic library functions of the mini program include WAWebview.js for the two partial view layers and WAService.js for the business logic layer. Here is a brief description of the corresponding functions:

WAService provides basic functions for the business logic layer

Let's take a look at the thumbnail of the WAService.js source code content:

From the source code, we can see that the WAService.js provided by the basic library has many functions, mainly including the following parts

• WeixinJSBridge: Unified encapsulation of message communication, easy to call, mainly for the communication between WeChat environment and native, and between the development environment and the developer tool backend service.
• wx: API method encapsulation under wx object
• appServiceEngine: defines global methods such as define, require, App, Page, Component, getApp, getCurrentPages, etc.
• virtualDOM: VirtualDOM, Diff and Render UI implementation
• expraser: Method definition of the expraser framework component, which means that the logic layer also has certain component tree organization capabilities.
• Reporter: Mini Program Log Component

WAWebview provides basic functions for the view layer

Some of the basic functions provided by the Mini Program Basic Library for the view layer are the same as those of WAService. The main functions are as follows:

• Message communication encapsulation is WeixinJSBridge
• Log component Reporter encapsulation
• The API under the wx object is different from that in WAService in that most of them are methods related to processing UI display.
• Implementation of the Mini Program Expraser component framework and registration of built-in components
• VirtualDOM, Diff and Render UI implementation
• Define page-related event triggers

The above is the detailed content of analyzing the principle implementation from the source code of the mini-program developer tool. For more information about the principle implementation from the source code of the mini-program developer tool, please pay attention to other related articles on 123WORDPRESS.COM!