This is the 22nd day of my participation in the August More Text Challenge

preface

Front-end engineers have been exploring writing a set of code that can run on H5, Android and IOS.

In the early stage, Hybrid was adopted for the mixed development of H5. In this mode, APP was just like a browser, exposing some native capabilities of H5 for communication. The development efficiency of this mode is fast, but there is a certain bottleneck in performance.

Weex

Later, front-end frameworks like Vue and React became popular, and an important concept promoted cross-end development: the virtual DOM. This is a DSL description of screen rendering through the rendering apis of different platforms. For example, in the browser through Document, in native through the native API rendering.

Later, Weex was born. Weex is a cross-end implementation of Vue. Weex still adopts the front-end H5 page for development, and the running experience of APPS on terminals is similar to that of native apps. This ensures fast response to demand and user experience.

The working process

Let’s take a look at the Weex workflow:

  1. Developers write Vue files, which are packaged into multiple JS files by packaging tools;
  2. Request JS file at APP end, run JS file through JS execution engine (JSCore);
  3. Execute output VNode, call WXBridge (Weex rendering engine)
  4. WXBridge continues to call the native rendering API to complete the final rendering

After looking at the workflow, we can draw the following conclusions:

  • The high-performance rendering is handed over to Native, and the logic is performed by JSCore parsing

Build the render instruction tree

They all use a consistent DOM API to convert the Virtual DOM into a real HTMLElement on the browser. The logic in Weex is similar, except that in the last step of generating real elements, we do not use the native DOM API. Instead, we use a set of Weex DOM API defined in the JS Framework to convert the operation into rendering instructions and send them to the client.

The FUNCTIONS of the Weex DOM API provided by the JS Framework are basically the same as those provided by the browser. These interfaces are adapted in Vue and Rax. Cross-platform rendering can be achieved by invoking different interfaces for Weex and browser platforms.

JS – Native communication

In the process of page development, in addition to node rendering, there are native module call, event binding, callback and other functions, these functions are dependent on the communication between JS and native to achieve.

First, the JS code for the page runs on the JS thread, whereas the drawing of native components and capturing of events all happen on the UI thread. The communication between these two threads is the callNative and callJS underlying interfaces (now extended to many), both of which are asynchronous by default and are wrapped around these two methods within the JS Framework and native renderer.

CallNative is an interface injected into the JS execution environment by the client and provided to the JS Framework for invocation. Nodes of the interface (rendering instruction tree mentioned above), methods and parameters of module invocation are sent to the client through this interface. In order to reduce the overhead of calling the interface, more direct communication interfaces have been opened, some of which also support synchronous calls (support return values), which are in principle the same as callNative.

CallJS is implemented by the JS Framework and is injected into the execution environment to make client calls. Event dispatches and module callbacks are notified to the JS Framework through this interface and then passed to the upper-level front-end Framework.

JS Service

Weex is a multi-page framework. The JS bundle of each page runs in an independent environment. Different Weex pages correspond to different “TAB pages” in the browser.

The function of JS Service is realized in THE JS Framework, which is mainly used to solve the problem of cross-page reuse and state sharing. For example, BroadcastChannel is realized based on JS Service, which can communicate between multiple Weex pages.

summary

Weex is also a run-time rendering, not compile-time. This is somewhat similar to the WebView container, but Weex is ultimately implemented in Native, so its performance is comparable to that of native apps.