關于跨平臺開發框架Weex你需要知道的一切

摘要：QCon第一天，GMTC全球移動技術大會聯席主席、手淘技術老大莊卓然（花名南天）在Keynote上宣布跨平臺開發框架Weex開始內測，并將于6月份開源，同時他們也放出官網：http://alibaba.github.io/weex ，可以在上面申請內測資格，以及下載Android版Demo把玩。

在大會后我對莊卓然做了一個采訪，對一些大家關心的問題得到官方的回復，整理在這里。

Weex基本信息

• 官方支持iOS、Android、HTML5.

• Write Once, Run Everywhere。一次編寫可生成三平臺代碼。

• DSL模板學習超簡單，直接寫HTML、CSS、JS。這意味著可以直接用現有編輯器和IDE的代碼補全、提示、檢查等功能。

• 輕量級、可擴展、高性能。

• 集成花樣多，可在HTML5頁面嵌入，也可嵌在原生UI中。

Weex的由來

Weex的前身是WeApp，一個用JSON配置原生UI組件來實現動態化的框架，關于類似這個的思想，可以在天貓這篇《手機天貓在配置動態化上的心路歷程》中看到，已經很牛了，Weex是WeApp的進化版本，加上ex去掉App，就成了現在這個名字。他們還編了個段子：

You give us a few weeks, so we bring you a weex.

這個段子要表達的意思，你get到了嗎？

與Vue.js的關系

如果對前端有所涉獵的同學會發現，Weex的DSL風格與一個前端的MVVM框架Vue.js比較像，那么它們的關系是什么呢？

Weex由多個關鍵模塊組成，分別是DSL transformer、JS Framework、HTML5/iOS/Android Renderer和工具鏈 ， 其中JS Framework就直接使用了部分來自Vue.JS的代碼。不過這種使用也是遵守開源協議的（Vue使用MIT協議，Weex使用Apache協議），Weex團隊在源碼的說明文件中記錄了來自Vue.JS和其他開源項目的貢獻。

為什么不用React Native

手淘和天貓曾經嘗試過React Native，然后放棄了。但是把它的思想吸收過來，結合Web Component和Vue.js，然后就成了Weex.

關于這個問題，莊卓然列舉了一些原因：

• 因為手淘之前有WeApp，從WeApp進化到Weex是很自然的選擇，拋棄自己的解決方案去用別人的反而很奇怪。

• React Native的JSX、CSS in JS寫法都很別扭，淘寶有很多ISV（即各種店鋪），他們之前只會Web技術，寫這個有門檻。另外，HTML標準在過去二十年內經受了檢驗，HMTL/CSS/JS對應的結構、樣式和行為，天然分離，代碼的可維護性會更好。拋棄標準自己發明DSL也不明智。

• React Native重視平臺獨立性，不能做到100%代碼共用，實際上還是要學習各平臺的特性，Weex希望做到100%共用，即一次編寫到處運行，進一步降低開發門檻。

• React Native在一些地方的性能上還有問題，手淘希望能自己主導優化的進程，否則會很被動。

關于KPI項目

去年在手淘向外界宣布有這個項目的時候，引起大家的關注，有人在知乎提了個問題，有人回答說是KPI項目云云。所謂KPI項目，就是為了完成KPI而做的項目，但實際之后不維護等等。

手淘在這個問題下面并沒有正式回應，據莊卓然表示，其實KPI項目看從什么維度去理解，任何一家公司去做一個創新都會有目標，有目標的話都可以被理解為是一個KPI項目。在他的角度來看，是不是KPI項目不重要，重要的是目標定得對不對，想解決的問題是不是核心問題。

關于維護，涉及到阿里現在的開源策略，我們看下一個問題。

為什么還要內測，不直接開源？

其原因是，阿里調整了開源策略。在過去，阿里集團開源了不少項目，但其中很多沒有后續維護，這也是被詬病為KPI項目的原因之一。其實阿里自己也想改變這種情況。

現在，手淘做開源，希望真正為社區創造價值，而不是把公司的一坨代碼處理一下往外一丟，別人在使用的時候還要花很多功夫處理，這樣的開源項目意義并不大。阿里希望發布出去的開源項目都是有生命的，能好好的維護起來。

在Weex去年雙十一在線上驗證之后，其實就準備開源，但有很多準備工作要做，比如文檔、配套的工具等等，過去的四個多月一直在做這些事情。在集團內部也進行過測試，集團BU、UC包括高德、天貓等都有很多同學參與進去貢獻DEMO和代碼，到了4月份覺得適合放出來了，所以宣布內測。

內測這個是類似產品運營的思路，希望能像打造產品一樣打造開源項目，和一般的開源項目的快速迭代不太一樣，目前來看也并不能說哪個更好。

來源：SDK.CN