2017年1月12日，由阿里巴巴集團主辦的WeexConf 2017在杭州西溪天堂藝術中心舉辦。阿里資深總監莊卓然（南天），阿里資深技術專家吳志華（天施）及Weex團隊其他成員現場與開發者就移動技術的發展趨勢展開探討，并致力于推動Weex和社區共同打造迎接未來的移動技術開放標準。對此大會現場Weex團隊給開發者帶來了三大重磅發布：和Vue團隊的合作成果、基于React標準的DSL框架Rax正式開源、全新組件市場Weex Market。

開場南天介紹說，“2016年6月份Weex正式開源，成為了阿里巴巴開源大軍中的一員，我們從開源社區中不斷的去完善Weex，完善創新的工作，是在整個2016年發展中最讓人興奮的一點。這也是在Apache基金會下阿里巴巴捐獻的第三個項目，包括原有的Jstorm和Rocket MQ，這也代表我們希望Weex以一個更中立、嚴謹、更認真的態度跟社區接軌”。

對于互聯網的每次一進步和發展，都代表著通過一種更開放和更統一、標準的架構去連接未來變化的可能。如果說React的出現，是建立一個在整個移動客戶端領域并行研發的新秩序，那么全新的Weex可能會在2017年和未來的日子里面，能夠建立一個組件生態新技術。對如今HTML5前端所有的應用范圍而言，過去Web時代我們面對的能力更多是瀏覽器提供，作為程序運行的一個容器，不同的瀏覽器給予的API作為標簽去調用。在今天這個智能的時代，硬件不斷的升級，瀏覽器作為API主要提供對象已經無法滿足應用場景的需求，硬件能力已經遠遠超出瀏覽器的范疇。所以，未來移動領域隨著硬件能力的提升都意味著專業共能的組件。

那么，開源Weex到底是一個什么樣的移動前段跨平臺項目呢？借助Weex最近公測的v0.9.5版本，我們來聊聊Weex對移動開發人員具備的核心創新能力。

Weex打通Web->Native

可以說近幾年移動端的發展趨勢就是向 Web 端靠，以 React Native 為代表的 JS-Native 已經很大程度上模糊了 Web 和 Native 應用的界限。Weex的出現真正把Web工程體系跟Native內部打通，提供了更多的能力擴展，將進程推進了一大步。

Weex為了能夠更加標準、透明的為上層業務調用，延續HTML5、JS、CSS這樣的方式來實現未來也是開發者值得關注的移動跨平臺解決方案。

通過上面一張簡單的Weex頁面，包含著Weex的描述，一張圖片有兩個文本。其實在整個頁面中分成幾層，***：最上面的是DSL，包含了JS、CSS、JS，這讓圖片變得更加有互動的能力。第二層是 Virtual DOM，能夠讓 IOS 安卓 H5保持三端一致，所以必須在架構層面去保證，同時在特殊架構層面把H5看成獨立的渲染端。

這也是Weex跨平臺構建UI的一套Framework，需要具備四個特征：

1） 輕量：學習成本輕，整個SDK的量級也相對更輕量。

2） 擴展性：支持將Native的組件接入到Weex中，同時2有一個URL的攔截工作，將模塊擴展注冊到系統中，完全自定義模塊擴展，同時提供一些Module，以及***的dom、Steam都有支持，一個JS Service，類似JS Service***的依賴管理機制。業務方可去中心化橫向定制組件和功能模塊。

3） 性能：對于移動端比較直觀的是渲染，所以在幀率、內存上做到高速加載、高速渲染、體驗流程。

4） CPU：跟耗電量和運行效率有直接關聯，保證了幀率不降的情況下減少了內容的消耗。

所以，首屏的渲染速度一定是決定用戶體驗的好壞。作者記得，在雙11的主會場頁面中，整個頁面分為兩部分，***個分會場框架完全用Weex JS寫，在加載的過程中，肉眼是無法分辨出來，據作者統計本地性能大概在100毫秒以內，肉眼完全無法分辨出這到底是Weex還是H5還是Native。

Weex自定義組件

在整個Weex項目中總共分為5層：***層為業務層，主要是接入業務，以客戶端的形式來承載。第二層是中間件層，整個發布平臺、預加載、組件以及一些API都放在上面。后面是工具組層，DSL，以及Engine。

接下來我們看看整體架構有哪些變化：

Weex增加了一個Market層，其中包含了組件庫，也就是DysAPI，也涵蓋了一些業務相關的API和Cookie機制、Shema攔截機制、前臺商店、API支持、工具支持等整個站點的支持。

而研發支撐層在業務急劇擴張的情況下，提供了發布、灰度以及線上監控的包裝。下面作者重點分析一下Market層能夠解決哪些核心問題。

Market具有能夠快速發布組件，更新、維護，可以簡單理解為開發者可以自己去做組件，然后通過Market可以對組件進行增刪秒查，這樣比較符合大家技術上的思維。

根據下圖的工具大圖展現出來，可以圍繞著SDK，Devtools，還有Playground這些能力幫助開發者快速調試試錯，通過WeexPack創建完整的Weex應用，添加開發者自己寫好的組件，從Market上尋找到比較有用的組件，***通過Weex CLi可以完成所有和Weex相關的操作。

與Vue的結合

說道Vue，作者不得不重點介紹一下。從去年開始發展迅猛，越來越多的重點項目已經在使用，在這些項目里面包含餓了么、稀土掘金、蘇寧易購、神馬搜索、長亭科技、荔枝FM、手淘、房多多等優秀項目。就作者個人理解，有桌面端、移動端、面向用戶以及后臺等等，整個vue開發體驗非常愉快，每個頁面都有對應的Vue文件，另外比較適合做組件化開發，當遇到比較復雜的、父子組件間需要頻繁通信的場景，可以用vuex搞定。總的來說是一個非常優秀的項目。

Vuejs是一個漸進式的框架，用作者尤雨溪的話說，“把高大上的東西做得平易近人”，既語法簡單的同時又解決復雜的問題，并且解決的非常好。

我們回過頭來說說Weex，選擇與Vue.js這么優秀的項目合作碰撞出不少的火花。首先是流式渲染，Weex可以控制整個***次渲染之后加載的顆粒度，這個特性讓Weex達到了Vuejs的級別；第二個在Vuejs里面有一個非常經典、且開發者非常喜歡的雙向數據綁定，從Vuejs達到了Weex。第三則是Weex的管理內容，避免內存泄露，保障應用長效穩定。在整個合作中，Weex基本整合了Vuejs的優勢，目前開發的所有問題也基本解決。而在基于Vue2.0中，建立更快更好的HTML5渲染引擎，支持Transition過渡動畫編寫，這也是Weex和Vue合作帶來的五個特性。

下面筆者簡單的整理一下Vue 2.0 in Weex的特性增強列表：

• 流式渲染邏輯控制，優化首屏渲染時間
• 雙向數據綁定，方便表單空間邏輯撰寫
• 安全管理多實例內存，避免內存泄露，保證應用長效穩定
• 直接基于Vue 2.0建立更快更好的HTML5渲染引擎
• 支持<transitiion>過渡動畫編寫

同時，Weex在周邊工具上也和Vue2.0做了全面的適配，包括開發人員熟悉的Loader，Cli，router等等，而對于Hacker News，Weex暫時還不能做到服務端渲染，但是除此之外所有的功能都覆蓋了Hacker News所有版本。下圖：

Weex生態演進

對于Weex這樣的一個開源項目，我們如何去理解他，以及后面的的一個生態演進過程？作者在與淘寶FED負責人圓心交流中，其實他是這么認為的。

今天的Weex可以這么去理解，大致分為兩層。一層是引擎層，另外一層是框架層。用前端的話來解釋就是瀏覽器的渲染引擎，比如V8，或者webK9，一個是上層框架。

Weex其實不僅應該是一個框架，應該說是兩者的一個組合。對于一個引擎來講，它不停的演進，不會隨著時間的消移而消移，對于框架，可以是React，也可以是Vue，但是未來使用什么還是未知，所以整個前端框架層的發展更新非常之快，基本上兩三年一個周期。在圓心認為，Weex應該是一個包含引擎層以及今天的框架層整個的解決方案。

其實今天的React，把它看作一種標準，就像W3C一樣，但是API的實現是由各個瀏覽器廠商來決定。如果我們把React看作是一個標準，然后跟Weex的引擎做曲線對接，作者認為，完全可以在React的語言上開發所有的API。就像與Vue合作一樣，優勢整合，完全滿足開發者需求。

那么基于React標準額渲染引擎，我們來看看整個實現圖：

在這張實現圖中，我們看到它一個分3層，***層是上面React的原件，然后是虛擬DOM，再到驅動層（可以理解成一個適配層），這里可以適配到不同的容器中，包含Natvie容器，HTML5容器，整個PC的Web容器，可以讓所有的東西在整個后端的整個引擎里面產出。下面我們來看看整合后RAX 3大特點：

• ***個是跨容器，通過中間的驅動層來實現Native以及Web；
• 第二個是輕量，把它看作一個標準層，然后可以自我實現，在實現過程中，彌補本身時間冗余的過程，體積只有原來的四分之一；
• 第三個是標準，基于W3C標準，保持所有開發者的習慣以及開發體驗。

所以，合作的碰撞能夠塑造Weex的生態，慢慢給予它的生命力。在這個過程中，團隊可以去沉淀DSL的標準，更夠讓前端無數的框架、解決方案接入進來，深入到體系中，開放給開源社區更多的開發者。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】