preface

It is said that some people spend money to buy star, I don’t know whether it is true. I thought it was just a joke. This morning reading article was contributed by Baidu EUX@ Tian Guangyu.

The text starts here ~~

Wechat applets

Wechat applets contain the following four files:

  • js

  • Json configuration file

  • WXML applets special XML file

  • WXSS applet specific CSS file

<view>
    <text class="window">{{ text }}</text>
</view>Copy the code
Page({data:{text:" this is a Page "}, onLoad:function(options){// Page initialization options for the Page}, //........ })Copy the code

Wechat applet can only dynamically change pages through its TEMPLATE syntax of MVVM, and its OWN JS does not support BOM and DOM operations.

View the micro channel applets architecture from the development tools

Unzip the application directly on the MAC side to find the app.nw folder, that is, the source of the development tool. You can see that the project was written by Nw.js; Go to the package.json file and find the app entry: app/ HTML /index.html. The entry js is dist/app.js and we can see the general logic of the entire editor.

However, what we care about is the build process. The build.js file exists in the “add” folder. No useful information found, only see the Upload module, including the size limit, upload package name.

For this reason, wechat mini program itself is similar to RN. Is packaged as a native language on the server side. However, through the Android border test, it was found that wechat applet is not native content at all. In addition, we write wechat grammar in the development tool, can be directly preview. There must be something wrong.

It grows like this

The build process

Continue to find the build template in the trans folder.

  • TransWxmlToJs WXML js

  • TransWxssToCss WXSS CSS

  • TransConfigToPf Template page configuration

  • TransWxmlToHtml WXML HTML

  • TransManager manager

Content used:

  • Found with the help of a template: app. Nw/app/dist/weapp/TPL/pageFrameTpl js, app. Mw/app. Dist. Weapp/TPL/appserviceTpl js

  • WCC executable program, WCC used to rotate WXML custom tag for Virtual_DOM

  • WCSC executable program, used to convert WXSS into CSS code used by the VIEW module, using WCSC XXX.wxSS

In the template, we found that we used the waWebView.js file, WAService. In transWxmlToJs we found a function for the generateFuncReady event. Compare the function that registers the event in wawebView.js.

We tried compiling the input.xml file using WCC.

wcc -d input.xml

A script is generated:

Window.__wcc_version__ = 'v0.6VV_20161230_fbi' var $GWXC var $gaic = $GWX = function (path, global) {function _(a, b) { b && a.children.push(b); }...Copy the code

The code shows that calling the $GWX function regenerates a function that returns a value (provided path is specified correctly). So we execute the following code:

$gwx("input.xml")("test")Copy the code

The following content is obtained:

{ "tag": "wx-page", "children": [ { "tag": "wx-view", "attr": { "class": "section" }, "children": [ { "tag": "Wx-input ", "attr": {"autoFocus": true, "placeholder":" this is an autoFocus input"}, "children": []}]}Copy the code

This should be a Virtual DOM-like object that is rendered by wawebivew.js with a label named wX-view, wX-input.

WAWebview.js

  1. The code initially provides a compatibility tool, with a WeixinJSBridge introduced.

  2. Next up is a Reporter object that sends error and performance statistics to the background.

  1. Wx core object, which contains apis under WX objects. But the number of apis here is far less than the official API documentation.

As you can see in the code, the API registered under WX will eventually call WeixinJSBridge method, this method. It should have been injected at packaging time. However, we can also find the definition of this method in waserveice.js.


So we conclude that WAService. Js is the code the editor uses to accept the wX method callback.

  1. The wxParser object provides mapping operations between DOM and WX Element objects, element operation management and event management.

  2. The next is the exParser object processing, including WeixinJSBridge global event registration, Virtual DOM algorithm implementation, style injection, etc. This section describes several important components

Exparser. RegisterBehavior register components based behavior for component inheritance.

Exparser. registerElement registers various built-in components, templates, behaviors, attributes, listeners, etc

Here, we observe that components such as WX-Video, WX-Canvas, WX-contact-button, WX-Map, and WX-Textarea all have “WX-native” properties. Does this mean that such components are native implementations? We open the border and check to see that such components are indeed native components.

To sum up, some components of the interface of wechat applet are realized in the Native way, and the Native component layer is above the WebView layer. Most of the front-end implementation, so explained the micro channel small program a bug.


Because the scrollView is a front-end implementation and uses native components in it, there is no way to listen for scrolling.

WeixinJSBridge

The component needs data to render. Look at the documentation and we know that the API for sending requests is wx.request; From the above analysis, we know that wx.request actually calls WeixinJSBridge. Now let’s look at WeixinJSBridge


WeixinJSBridge actually sends the code that handles the data request; If the current environment is ios, then call WKWebview window. Its. MessageHandlers. InvokeHandler. PostMessage. If the environment is called android WeixinJSCore invokeHandler (called, the default will take current webviewID).

WAService.js

In the weixinjsbridge-js analysis we looked at, we did not find the front-end communication implementation, routing capability, data binding hierarchy. A closer look turned up a waservice.js file. WAService. Js

  • At the beginning of the code, the same WeixinjsBridge-compatible module as wawebView.js

  • Then there is the Reporter module like wawebView.js.

  • Wx interface module is richer than WX in WaWebView.js. (The rest of the WX API is here.)

  • AppServiceEngine module, provides Page, App, GetApp interface

  • Add AMD interface Require define for the window object

To sum up, WAService. Js mainly realizes the following functions:

  • App() applets entry; Page() entry to the Page

  • wx API;

  • Pages have scopes that provide modularity capabilities

  • Data binding, event distribution, lifecycle management, route management

Here we conclude that the architecture of applets is:


The whole small program consists of two WebView, the code is divided into UI layer and logical layer. The UI layer runs in the first WebView, performing DOM operations and responses to interactive events, and contains the waWebView.js code and compiled content. The logical layer executes (in the second WebView) in a separate JS engine (iOS: JavaScriptCore, Android: X5 JS parser; Collectively JSCore; Development tools, NWJS Chrome kernel), WAService. Js code and business logic.

After the event operation on the View layer, the data will be transmitted to the Native system layer through WeixinJSBridge. The Native system layer decides whether to use Native processing and then passes it on to the logic layer for the user’s logical code processing. After the logical layer finishes processing, the data will be returned to the View layer through WeixinJSBridge. View Render updates the View.

Discussion of architecture

This architecture of wechat is completely isolated from logic and UI, and the small program logic and UI are completely processed by running in two independent WebViews. So what’s the benefit of that? It always feels like more trouble. Is this architecture used by anyone other than applets?

A search on the Internet showed that there is one project currently using this architecture: Where is the latest YIS framework

YIS takes a applets architecture, divided into a logical layer and a UI layer. The UI layer runs in a WebView, while the logic layer runs in a separate JS engine. Accordingly, the entire application code is divided into two large parts, one part runs in the WebView, one part runs in the JS engine. The JS engine computes the DOM structure and outputs it to the WebView, which forwards the user’s click events to the JS engine.

The approach of this project is very similar to that of a small town, the only thing missing is the lack of native components. However, there is no explanation in the official documentation as to why this was done, only that it is more fluid.

Some views

Traditional Web page display goes through several steps:

  • The webview initialization

  • Load HTML, CSS, JS

  • Compile the JS

  • Render calculation

  • DOM Path

By using the applets architecture, we can split the above process into two parts and execute them in parallel: webView part:

  • The webview initialization

  • Load HTML, CSS, JS (greatly reduced in size after splitting)

  • Compile the JS

  • Wait for the data the page needs

  • Deserialize data

  • Perform Patch

  • To render the page

  • Waiting for more news

Jscore parts:

  • Initialize the

  • Load the framework JS code

  • Compile the js

  • Load the business logic JS code

  • Compile the js

  • Calculate the virtual DOM structure of the front screen

  • Serialize data, transfer

  • Wait for webView messages, or Native messages

In this way, the rendering process and the logical process are separated and processed in parallel: the first screen rendering speed is accelerated; In the single-thread model, the JS operation time is too long and the UI is stuck. Completely data-driven, you can’t manipulate the DOM directly, avoiding low-quality code. Webview and JScore are available

Of course, this architecture scheme also has certain disadvantages:

  • Unable to operate DOM flexibly, unable to achieve the more complex love warm effect

  • Some nA-related views are restricted in use. For example, wechat scrollView cannot contain textarea.

  • Page size and the number of open pages are limited

  • Adaptation needs to be developed separately and existing code resources cannot be reused.

The resources

  • What is the realization principle of micro channel small program

  • Analysis of wechat applets architecture and working principle

  • Analysis of micro channel applets architecture

About the author: @ guang-yu tian original: http://eux.baidu.com//blog/fe/ WeChat small application architecture principle

Finally, EUX shared:

[Issue 1078] Front end cut cut cut diagram

Recommend:

[Issue 1382] Quietly lifting the veil of secrecy around WebAssembly

How to Think like a programmer — lessons in problem solving