择要： WEEX照旧采用传统的web开辟手艺栈举行开辟，同时app在终端的运转体验不输native app。其同时处理了开辟效力、发版速率以及用户体验三个中心题目。那末WEEX是怎样完成的？现在WEEX已完全开源，并捐给Apache基金会，我们能够经由历程剖析其源码来一探终究。

点此检察原文：http://click.aliyun.com/m/43048/

作者：阿里-挪动云-大前端团队

传统的挪动端开辟，一个完全的营业须要保护三份终端代码：Android、iOS、H5，这带来了极大的开辟本钱以及保护本钱。尤其是对处于营业始创期须要疾速试错的营业以及须要支撑按期运营运动的营业。所以业界也一直在探究跨平台计划，旨在经由历程一套代码完成各个终端的营业逻辑。相干计划经由不停演变，从初期的H5、Hybrid到现在的Cloud Native(云原生)，在开辟效力和用户体验上都在一点点迫近最初的想象。

初期H5和Hybrid计划的中心是运用终端的内置浏览器（webview）功用，经由历程开辟web运用满足跨平台需求。该计划能够处理跨平台题目，同时能够提拔发版效力。但其最大的弊病在于用户体验相较于native开辟的app存在较大差别，经常涌现页面卡顿，加载慢等题目。

因而厥后业界最先探究照旧运用web手艺栈开辟出媲美原生体验app的计划，因而以WEEX为代表云原生开辟框架最先涌现。所谓云原生(Cloud Native)指能够经由历程云端疾速宣布（与长途web运用宣布流程相似），同时还能够到达媲美原生App体验的计划。WEEX照旧采用传统的web开辟手艺栈举行开辟，同时app在终端的运转体验不输native app。其同时处理了开辟效力、发版速率以及用户体验三个中心题目。那末WEEX是怎样完成的？现在WEEX已完全开源，并捐给Apache基金会，我们能够经由历程剖析其源码来一探终究。

WEEX框架重要分为两部份：

1.前端JavaScript框架
2.Native SDK

在上一篇博客中，我们引见了Native SDK的道理，本文重要引见其前端JavaScript框架道理。

1 团体架构
起首照样再来看下WEEX开辟的团体架构：

能够看到在JS-Native Bridge将衬着指令发送给Android或许iOS衬着引擎之前，我们的营业代码运转在JSCore/v8的实行引擎当中，而在该实行引擎当中除了实行营业JSBundle，还运转着JS Framework，JS Framework不仅供应了jsbundle必要的运转时环境，同时还供应了与native通讯的接口。

而这个JS Framework就是我们本日引见的重点。

这是前端框架的重要架构：

FRONTEND FRAMEWORK/DSL:这是WEEX的开辟框架，现在WEEX重假如运用Vue.js举行开辟
WEEX-VUE-LOADER：前端编译器，将vue文件编译成es5代码
WEEX-VUE-FRAMWORK：WEEX中心框架，重要担任将virtual dom转换成weex的native dom api
WEEX-RUNTIME:担任与native衬着引擎对接，将native dom api转换成对应平台（Android、iOS）的platform api,然后传递给native衬着引擎，由后者担任衬着事情。

2 Vue.js

起首来看下前端开辟框架Vue.js,Vue.js现在与React 、 Angular构成了三大最盛行的前端开辟框架，Vue.js具有组件化、virtual dom以及MVVM三大特征，还进修React的Redux，引入了状况治理模块Vuex。同时相比起React重要基于JSX，Vue.js的开辟形式越发清晰，简朴，上手速率更快。.vue 文件一般能够分为三部份：<template> 、<style> 和 <script>，<template> 是必需要有的，其他可选。个中 <script>中的代码会保存或许被转换成 ES5 的语法；<style> 中的 CSS 在 Weex 平台上会被转换成 JSON 花样的款式声明，放到组件的定义中去；<template> 会被编译天生组件定义中 render 函数，能够理解为 render 函数的语法糖。下文是一个简朴的.vue文件：

3 WEEX-VUE-LOADER

因为.vue文件并非规范的JavaScript代码，该代码不能直接被JS实行引擎辨认，所以在编译历程当中须要将.vue文件转化成规范的es5代码。而担任完成这一操纵的就是WEEX-VUE-LOADER。

4 WEEX-VUE-FRAMEWORK&WEEX-RUNTIME

完成编译后，输出的bundle.js即可被JS实行引擎所辨认，能够实行其逻辑了。那末接下来就来看下bundle.js的实行历程。

4.1 初始化

起首来看下初始化历程。

图中画出了 Weex SDK 的部份内容。个中 weex-vue-framework 和 Vue.js 是对等的，语法和内部机制都是一样的，只不过 Vue.js终究建立的是 DOM 元素，而 weex-vue-framework 则是向原生端发送衬着指令，终究衬着天生的是原生组件。Weex Runtime 用来对接上层前端框架（ Vue.js ）而且担任和原生端之间的通讯。Render Engine 就是针对各个端开辟的原生衬着器，包含了 Weex 内置组件和模块的完成，可扩大。

4.2 建立组件

weex吸收到bundle.js以后，起首搜检其合法性，假如发现用的是Vue版本（weex初期版本运用.we语法），就会挪用weex-vue-framework中供应的createInstance建立实例。一个bundle.js对应一个weex实例，且每个实例都有唯一的instanceId，与之对应。实例与实例之间互相断绝，互不滋扰。

在建立实例的历程当中，bundle.js会实行new Vue（）建立一个vue组件，并经由历程其render函数建立VNode节点，即virtual dom节点。第二节中的示例代码会终究天生相似以下的vnode节点：

4.3 patch

天生了VNode以后，接下来须要将VNode同步到实在的Dom之上，该历程在Vue.js中被称为patch，patch会比较新旧VNode之间的差别，最小化操纵集。末了再将Virual Dom团体更新到实在Dom之上。在实行 patch 之前的历程都是 Web 和 Weex 通用的，所以文件花样、打包编译历程、模板指令、组件的生命周期、数据绑定等上层语法都是一致的。

然则因为目的实行环境差别（浏览器和 Weex 容器），在衬着实在 UI 的时刻挪用的接口也差别。

在vue.js内部，weex平台和web平台的patch要领有所差别。简朴来讲，在web平台，patch须要将Virtual Dom运用规范Dom API更新到实在Dom即可。接下来的UI更新就交给浏览器即可。

然则因为在weex平台下，终究的UI衬着是由native衬着引擎实行的，native衬着引擎不能辨认Dom API，所以在weex平台下，须要将Virtual DOM转化成native 衬着引擎能够辨认的Native DOM API。

4.3 发送衬着指令

在上层前端框架挪用了 Weex 平台供应的 Native DOM API 以后，Weex Runtime 会构建一个用于衬着的节点树，并将操纵转换成衬着指令发送给客户端。

回忆文中提到的 例子，上层框架挪用了 Weex Runtime 中 createBody 、createElement 、appendChild 这三个接口，简朴构建了一个用于衬着的节点树，终究天生了两条衬着指令。

Platform API 指的是原生环境供应的 API，这些 API 是 Weex SDK 中原生模块供应的，不是 js 中要领，也不是浏览器中的接口，是 Weex 内部差别模块之间的商定。

现在来讲衬着指令是基于 JSON 形貌的，细致花样大抵以下所示：

4.4 衬着原生组件

接下来就是WEEX NATIVE SDK的事情了，细致逻辑在上一篇博客已细致说清晰明了，此处仅简朴申明。

原生衬着器吸收上层传来的衬着指令，而且逐步将其衬着成原生组件。

衬着指令分许多类，文章中提到的两个都是用来建立节点的，其他另有 moveElement 、updateAttrs 、addEvent 等种种指令。原生衬着器先是剖析衬着指令的形貌，然后分发给差别的模块。关于 UI 绘制的指令都属于 “dom” 模块中，在 SDK 内部有组件的完成，其他另有一些无界面的功用模块，如 stream 、navigator 等模块，也能够经由历程发送指令的体式格局挪用。

这个例子里，第一个 createBody 的指令就建立了一个 <div> 的原生组件，同时也将款式运用到了改组件上。第二个 addElement指令向 <div> 中增加一个 <text> 组件，同时也声清晰明了组件的款式和属性值。

上述历程不是分阶段一个一个实行的，而是能够完成“流式”衬着的，有能够第一个 <div> 的原生组件还没衬着好，<text> 的衬着指令又发过来了。当一个页面迥殊大时，能看到一块一块的内容逐步衬着出来的历程。

5 总结

经由历程本文以及上一篇：WEEX NATIVE SDK道理详解,总算是将weex的大抵道理引见清晰了，固然另有许多完成细节文中并未睁开，有兴致的朋侪能够留言人人一同议论下，别的文章中有毛病的处所也请人人斧正！</style></template>