background

With its advantages and characteristics of high exposure, low development cost and smoother operation, small program has been widely used as soon as it was launched. In the face of the popularity of small program, it is natural for many developers to switch to the field of small program. This article mainly takes you to understand the story behind the running environment of small program.

But for those who want to learn about the internals, tutorials on the market are more about how to develop a widget using existing rules than how the internals of a widget work. In this article I will share in detail how applets work.

In order to more convenient and friendly understanding of some of the content of this article, we first of the small program running environment for a general analysis, and then from the following three levels to deepen the understanding of the small program running principle

  • Developer tools for analysis and cracking

  • Core document interpretation and

  • Architecture Flow Diagram

Applets running environment

According to the wechat applets development document, we can know the running environment scenarios of applets in the three terminals:

  • IOS: The JavaScript code in the applet logic layer runs in JavaScriptCore (), and the view layer is rendered by WKWebView

  • Android: The JavaScript code for the applet logic layer runs in V8, and the view layer is rendered by our own XWeb engine based on the Mobile () Chrome() kernel

  • Development tools: The JavaScript code for the applet logic layer is run in nw. js and the view layer is rendered by Chromium() Webview

As can be seen from the running environment of the small program in the three ends, there is an interaction between the logic layer and the rendering layer. How is the interaction? The answer can be found in the communication model between the rendering layer and the logic layer:

From this figure, we can see that the applet adopts a more appropriate technical scheme, realizing that the rendering layer and the logic layer are managed by two threads respectively:

  • The render layer interface is rendered using a WebView

  • The logic layer uses JsCore thread to run JS script

When a small program has multiple interfaces, there will be multiple WebView threads in the rendering layer. The communication between the two threads will be transferred through the wechat client, and the network requests sent by the logic layer will also be forwarded through Native.

Why adopt this technical solution?

The main reason is the control restrictions of small programs, for example, they cannot directly operate DOM tree, page jump and other control measures, so as to better form their own ecological closed-loop.

Now we have some understanding of the basic composition of the running environment of small program, I will analyze cracking from the developer tools, document interpretation and architecture process diagram these three levels to tell the specific knowledge of the running environment of small program.

Developer tools for analysis and cracking

Let’s start with the analysis and cracking of wechat developer tools. First of all, we open the official small program Demo project from wechat developer tools:

From the edit bar and documentation, we can see that there are four file formats for the structure of a page

  • The.js suffix file represents the current page logic

  • The.wxml suffix file is a set of tag language designed by the framework, which can be combined with the basic components and event system to build the structure of the page

  • The.wxSS suffix file is used to represent a style language that describes the component styles of WXML

  • Json file extension is the configuration principle of the page

These are superficial things that most of us developers see or know. What, you may ask, is the deep stuff? Let’s analyze them one by one.

We mentioned that there are logic layers and rendering layers in applets, so how do you find them in developer tools?

Mouse operation wechat developer tools – debugging – debugging wechat developer tools

A page like this will pop up:

As you can see, I marked the first webView as the rendering layer, with each page SRC corresponding to an address, and the second webView as the logical layer.

There is no way to directly view the specific content in the WebView with a single page like this, and it requires some manipulation. You can find the corresponding TAB in the Console Console and view the corresponding WebView:

Use this command to view the contents of the webView:

If you open the corresponding DOM tree directly, the first WebView displays information about the render layer:

For example, from this image we can see some files and methods that the page rendering layer relies on, and use the result theory to deduce where these files come from and what they do.

For the webView of the service logic layer, you can directly enter the document in the Console at the bottom right of the developer tools.

As you can see from the above, some of the loaded local file resources are visible through the DOM tree and source resources. Next, I’ll show you how to find the source of these files, including references to the files themselves and the results returned by code execution.

We can see from the previous picture that Script introduces some files starting with WA. These files are the basic library files of the apet runtime core. If we type openVendor() on the console, the corresponding file box will pop up automatically:

These. WXVPKG suffix files are the version files of wechat basic library. You can see the file content format after decompressing the file with relevant tools:

In particular, there are two WCC and WCSC executables. What do they do?

WCC uses a set of WXML tag language designed by wechat small program to build the page structure and convert it into tags that can be understood by WebView. After all, the rendering layer still runs in WebView. We can see its compilation process through a picture.

Its compilation process is roughly the process

  • Start by loading the WXML file code in all pages of the applet

  • Convert them to a $GWX (pagePath) JS function and inject it into the WebView

  • When the applet runs, the current page path is known, and executing this function generates the page structure function, which takes the page data and outputs a virtual () DOM JSON object describing the page structure

  • Finally, the HTML tag corresponding to the page is generated by the internal components of the small program, and the page tag is converted into the familiar node through WCC compilation.

So what does a WXSS file do? It converts WXSS content into viewable CSS content, analyzes references between files, adds dimension unit RPX conversion, ADAPTS to screen width, and imports styles. Finally, it generates an eval() () function to process the RPX and outputs an array of style information.

Small program core basic library file interpretation

Just now we saw the basic library files of the core of the small program runtime, among which WAservice. Js, waWebView.js, AppService.js and other files are the most core files bearing the running environment of the small program, so it is necessary to focus on these files.

The WAservice. Js file is a mixed-up package with about 60,000 lines:

To be more intuitive and readable, we can use JS-Beautify and function scaling in VS Code to make the Code much more readable. Images: uploader. Shimo. Im/f/sDqXRZ5fv…

This is actually very clear, we can see some commonly heard wechat objects, such as:

  • WeixinJSBridge: used for message communication encapsulation and call, mainly for communication between wechat environment and native, development environment and developer tools background services

  • AppServiceEngine :() is used to define global Page methods such as define, require, App, Page, Component, getApp, etc

  • VirtualDOM: Similar to the virtualDOM implementation in Vue and React, but mainly emulates the element() object on the DOM interface

  • Expraser: This is a method definition for framework components, meaning that the logical layer also has some component tree organization capabilities.

Some other objects and content are not described, but you can download them yourself if you are interested.

Function (e,t,n) files correspond to each exposed method. The next step is to manually decompile the method code back into the normal readable source file.

Applets architecture diagram and operation flow

Through the understanding of the small program running environment and core files, you may have a scattered understanding of the running principle of the small program, know some characteristics and elements of the running principle of the small program, the following we systematically understand the running principle of the small program through the overall architecture hierarchy diagram and the running process.

From this diagram, you can see a rough hierarchy from the top down:

  • Display layer: This is the page display of the applet, including the menu, title and other display content

  • Control layer: including UI control, central control

  • Message processing layer: it contains communication message distribution processing and cache

  • The service layer is the network, storage, file services and you can see the infrastructure layer is log files, data storage

  • The basic local layer is access to the camera communication functions of the device itself

  • The operating system layer is the carrier platform, such as ios and Android

After understanding the architecture diagram of the applet, we will analyze the relationship between controller WebView and communication at startup from the level of running environment process.

  • The applets system configuration file, which contains app.json files and scenarios, will be loaded first.

  • Then create a service webView to automatically connect to the Socket server for network information.

  • Then create a Page WebView based on the configuration to resolve the home page path to create a home page Webview.

  • Then notify the Socket Server of the routing information and send the onAppRoute message before the PageWebView is created.

  • After creation, send onAppRouteDone message notification, and Socket Server forward control layer message to appService,

  • Finally APPSERVICE notifies PAGEFRAME of the render, and PAGEFRAME informs APPSERVICE of the render status.

You may be a little confused after listening to this content. There is no message notification mentioned above, but in fact, in wechat developer tools, there is a message center underlying module that maintains a WebSocket server.

The WebView of the applet logic layer and the WebView of the rendering layer establish a long connection with the developer tool base through WebSocket, and use the Protocol field of WebSocket to distinguish the source of the Socket.

So, specifically, what about the types of message processing send and receive?

Different message types are used to process messages. The common message types are as follows:

  1. The APPSERVICE_ON_EVENT message is sent by the control layer and received by the APPSERVICE and WEBVIEW layer without processing the direct callback

  2. The APPSERVICE_INVOKE message is emitted by the APPSERVICE layer, and the APPSERVICE and WEBVIEW layers receive it and process the corresponding API method implementation, and then callback as needed

  3. The APPSERVICE_PUBLISH message is issued by APPSERVICE, and the WEBVIEW layer receives it without processing the callback directly

  4. The WEBVIEW_ON_INVOKE message is sent by the WEBVIEW layer, which processes the corresponding API method implementation after receiving it, and then callback as needed

  5. The WEBVIEW_PUBLISH message is issued by the WEBVIEW and received by the APPSERVICE layer without direct callback

The above is the small program tool side to achieve some message types and transmission mode, of course, in the client will not directly use socket link, because on the client to deal with efficiency performance and stability is not the most appropriate solution,

conclusion

This article mainly from the developer tools crack, small program core basic library file interpretation and small program architecture of these three levels to tell the operating principle of the environment. Need to pay attention to the key content is that we need to know the small program and ordinary web page difference using a rendering layer and logic layer, but also know how to compile custom tags and styles into webView can identify nodes and styles, in addition, message communication and processing also need to focus on learning.

If you want to know more information and problems related to the running environment of small programs, you can pay attention to the wechat xiaofeng North public number and contact me. For how to complete the compilation and packaging of small program code and the concrete realization of multi-terminal operating environment platform, you can pay attention to the open source project together (github.com/wetools/wep…

That’s it!

I’m a programmer north of little Wind who doesn’t just yank code, and I’ll see you next time.