Abstract: WEEX still adopts the traditional Web development stack for development, while the running experience of APP in the terminal is not lost to native APP. It also solves three core problems of development efficiency, release speed and user experience. So how does WEEX work? WEEX is now fully open source and donated to the Apache Foundation. We can find out by analyzing its source code.


Click here to view the original: click.aliyun.com/m/43048/


Author: Ali – Mobile Cloud – Big Front-end team


In traditional mobile terminal development, a complete business needs to maintain three copies of terminal code: Android, iOS and H5, which brings great development and maintenance costs. This is especially true for early-stage businesses that need quick trial and error and businesses that need to support regular operations. Therefore, the industry has been exploring cross-platform solutions, aiming to complete the business logic of each terminal through a set of code. Related schemes have evolved continuously, from H5 and Hybrid in the early stage to Cloud Native now, which are approaching the initial idea in terms of development efficiency and user experience.
The core of early H5 and Hybrid solutions is to use the built-in browser (Webview) function of terminals to develop Web applications to meet cross-platform requirements. This scheme can solve the cross-platform problem and improve the efficiency of the release. However, its biggest disadvantage is that there is a big gap in user experience compared with native developed apps, which often causes problems such as page lag and slow loading.


Then the industry began to explore the use of web technology stack to develop comparable to the native experience app, so WEEX as the representative of cloud native development framework began to emerge. Cloud Native refers to a solution that allows rapid delivery through the Cloud (similar to the process of remote Web App delivery) while still providing a comparable experience to Native apps. WEEX still adopts the traditional Web development stack for development, and provides the same running experience as native apps. It also solves three core problems of development efficiency, release speed and user experience. So how does WEEX work? WEEX is now fully open source and donated to the Apache Foundation. We can find out by analyzing its source code.


The WEEX framework is divided into two parts:
1. Front-end JavaScript framework
2.Native SDK
In our last blog post, we introduced the principles of the Native SDK. This article focuses on the principles of its front-end JavaScript framework.


1 Overall Architecture


First of all, let’s look at the overall architecture of WEEX development:
It can be seen that before the JS-Native Bridge sends the rendering instruction to the Android or iOS rendering engine, our business code runs in the JSCore/ V8 execution engine, which not only executes the business JSBundle but also runs the JS Framework. The JS Framework not only provides the necessary runtime environment for JsBundle, but also provides an interface to communicate with Native.
This JS Framework is the focus of today’s presentation.
This is the main architecture of the front-end framework:
FRONTEND FRAMEWORK/DSL: This is the WEEX development FRAMEWORK. WEEX is mainly developed using vue.js
Weex-vue-loader: front-end compiler that compiles VUE files into ES5 code
Weex-vue-framwork: WEEX core framework, mainly responsible for converting virtual DOM into WEEX native DOM API
Weex-runtime: Interconnects with native rendering engine, converts Native DOM API into platform API of corresponding platform (Android and iOS), and then transfers it to Native rendering engine, which is responsible for rendering work.


2 Vue.js


Vue.js is one of the most popular front-end development frameworks with React and Angular. Vue.js features componentalization, Virtual DOM, and MVVM. Vuex, a status management module, is introduced. Meanwhile, React is clearer, simpler and faster than the development mode based on JSX and vue. js. .vue files can usually be divided into three parts:



3 WEEX-VUE-LOADER


Since.vue files are not standard JavaScript code and cannot be recognized directly by the JS execution engine, they need to be converted to standard ES5 code during compilation. The weex-VUe-loader is responsible for this operation.


4 WEEX-VUE-FRAMEWORK&WEEX-RUNTIME


Once compiled, the bundle.js output is recognized by the JS execution engine and ready to execute its logic. So let’s look at how bundle.js is executed.


4.1 the initialization


Let’s start with the initialization process.
The figure shows part of the Weex SDK. Weex-vue-framework and vue.js are equivalent, with the same syntax and internal mechanism, except that vue.js ultimately creates DOM elements, while Weex-Vue-framework sends render instructions to the native end, which ultimately generates native components. The Weex Runtime interconnects with the upper-layer front-end framework (vue.js) and communicates with the native end. Render Engine is a native renderer developed for each end, including Weex built-in components and modules implementation, extensible.


4.2 Creating Components


When weex receives bundle.js, it checks the validity of the bundle.js. If the Vue version is used (earlier weex versions use the. We syntax), it calls createInstance provided in weex-VuE-framework to create an instance. One bundle.js corresponds to one instance of WEEx, and each instance has a unique instanceId that corresponds to it. Instances are isolated from each other and do not interfere with each other.
During instance creation, bundle.js executes new Vue () to create a Vue component and uses its render function to create a VNode, a virtual DOM node. The example code in Section 2 will eventually generate a vNode similar to the following:
{ tag: ‘div’, data: { staticStyle: { justifyContent: ‘center’ } }, children: [{ tag: ‘text’, data: { staticClass: ‘freestyle’ }, context: { $options: { style: { freestyle: { textAlign: ‘center’, fontSize: 200 } } } }, children: [{ tag: ”, text: ‘Hello World!’ }] }] }


4.3 patch


Once a VNode is generated, the next step is to synchronize the VNode to the real Dom. This process is called patch in vue.js, and patch compares the differences between the old and new VNodes to minimize the set of operations. Finally, update the Virual Dom as a whole to the real Dom. The process before patch execution is common to the Web and Weex, so the file format, packaging and compilation process, template instructions, component life cycle, data binding and other upper-level syntax are consistent.


However, due to the different target execution environments (browsers and Weex containers), the interface is called differently when rendering the actual UI.
In vue.js, the patch methods of weeX platform and Web platform are different. Simply speaking, patch needs to update the Virtual Dom to the real Dom using the standard Dom API on the Web platform. The rest of the UI updates are up to the browser.


However, in weeX platform, the final UI rendering is performed by the Native rendering engine, which cannot recognize Dom API. Therefore, in WEEX platform, the Virtual Dom needs to be converted into the Native Dom API that can be recognized by the Native rendering engine.


4.3 Sending render instructions


After the front-end framework calls the Native DOM API provided by the Weex platform, the Weex Runtime builds a tree of nodes for rendering and translates the operations into rendering instructions to the client.


As we recall, the framework calls createBody, createElement, and appendChild in Weex Runtime to create a tree of nodes for rendering, resulting in two render instructions.


Platform apis refer to apis provided by native modules in the Weex SDK. These apis are not methods in JS or interfaces in browsers, but conventions between different modules in Weex.


Currently, rendering instructions are described based on JSON, and the specific format is roughly as follows:
{ module: ‘dom’, method: ‘createBody’, args: [{ ref: ‘_root’, type: ‘div’, style: { justifyContent: ‘center’ } }] }


{ module: ‘dom’, method: ‘addElement’, args: [‘_root’, { ref: ‘2’, type: ‘text’, attr: { value: ‘Hello World!’ }, style: { textAlign: ‘center’, fontSize: 200 } }] }


4.4 Render native components


The next step is to work on the WEEX NATIVE SDK. The logic was explained in detail in the last blog post, so here is a brief explanation.
The native renderer receives render instructions from above and gradually renders them into native components.


There are many classes of render instructions. The two mentioned in this article are used to create nodes, along with moveElement, updateAttrs, addEvent, and many more. The native renderer parses the description of the render instruction and then distributes it to different modules. All the instructions about UI drawing belong to the “DOM” module, and there are components in the SDK. Other functional modules without interfaces, such as Stream and Navigator modules, can also be called by sending instructions.


In this example, the first createBody directive creates a

native component and applies the styling to the reshuffled. The second addElement directive adds a

component to the

and also declares the component’s style and property values.

The above process is not performed in stages, but rather “streaming” rendering. It is possible that the first

native component has not yet been rendered, and the

render instructions are sent again. When a page is very large, you can see the process of gradually rendering the content piece by piece.



5 concludes


Through this article and the last article: WEEX NATIVE SDK principle in detail, finally is the general principle of WEEX introduced clearly, of course, there are a lot of implementation details are not launched, interested friends can leave a message we discuss, in addition, there are mistakes in the article also please point out!


Identify the qr code below to read more about dry goods