2016年Qcon大會首日，阿裡巴巴資深總監、淘寶移動平台、阿裡百川負責人莊卓然宣布移動端高性能動态化方案Weex即時内測，并将于6月開源。此消息一出，群情洶湧，在座的程式猿、攻城獅們紛紛拿起手機掃碼，以期第一時間感受Weex的神奇之力。
在第二天的主題分享會上，阿裡巴巴前端開發專家趙錦江和技術專家徐凱對Weex進行了深入的解析。以下為演講速記整理後的成文。
阿裡怎麼看待移動開發？
目前的移動開發者面臨的最大痛點就是面對極其複雜的環境，對此，莊卓然給出一個公式，移動開發的複雜度=應用數量×平台數量×要适配的各種各樣的機型。
如何解決這個問題呢？在解決問題之前，首先要對移動開發的未來有着精準的研判。
阿裡認為，移動開發的未來必定更加平衡，也就是說必須是性能與動态兼得，如此，才能夠滿足未來使用者的需求。另外，移動開發在未來也必定是開放互聯的狀态，移動網際網路将來肯定是基于更加大衆化的技術體系，沒有平台之間的隔閡，而且簡單易用。
是以，阿裡結合移動開發的現狀并圍繞其願景推出了Weex解決方案。
事實上，在去年的雙11活動中，Weex就得到了實戰的驗證，且表現不俗。時至今日，Weex已經被阿裡技術團隊多次運用，并“創造”出各種豐富的場景，整體的表現非常優異。
把移動端所有界面拆分成各個page，然後中間設定有路由的控制邏輯，同時，将移動端各種各樣的能力通過各種API提供給開發者。這是阿裡對移動開發模型的了解。
Weex通過标準化的東西，包括HTML、CSS和JS這些前端非常快速易用好學的文法作為開發體驗，提供給開發者。另外，Weex的文法設計尊重還Web的标準。
Weex的工作原理
Weex設計之初就考慮到在三端（iOS、安卓和H5）上能夠得到展現。在最上面的DSL，阿裡一般稱之為Weex檔案（.we），通過Transformer轉換成js-bundle，再部署到伺服器，這樣服務端就完成了。在用戶端，第一層是JS-Framework，最後到RenderRengine。
輸入是Virtual DOM輸出是native或者H5 view，還原成記憶體中的樹型資料結構，再建立view，把事件綁定在view上，把view基本屬性設上去。Weex Render會分三個線程，不同的線程負責不同的事情，讓JS線程優先保障流暢性。
Weex的性能、擴充性以及可用性究竟怎樣呢？
性能方面，阿裡對Weex做了多次壓測。在加載時間、幀率、記憶體消耗、CPU占用（包括靜默和峰值）等多個方面，Weex都表現得非常出色。
在談及性能之時，幀率和加載時間幾乎都會被提及，但是往往忽略了一個事實，那就是Native UI開發中通常沒有JS資源在伺服器端加載。Weex會把JS内置到用戶端裡，以免除下載下傳的問題，進而更為有效地提升性能。
相容性是Weex非常重視的問題，對此，阿裡是這樣來解決的。
首先是單測保證，包括JS和H5的單測，保證最基礎的UT（Unit Test）本身所帶來的含義。
其次是UI的自動化，分為兩個部分，一是截圖對比，将最終産生的結果和意料中的結果進行圖形對比；二是Layout Results，包括Model以及其他的布局類的，通過基本的資訊完成測試的過程。
在擴充性方面，Weex可以寫很多頁面，而且通過路由機制幫助開發者将頁面進行串聯。
Weex已開放内測，可用性方面正在逐漸完善。包括Playground、調試工具、腳手架、AppHub、編輯器等多個方面，一些工作已經完成就緒，絕大部分工作将在5、6月份完成。
最後，是Weex的三種工作模式。
1.全頁模式
目前支援單頁使用或整個App使用Weex開發（還不完善，需要開發Router和生命周期管理），這是主推的模式，可以類比RN。
2.Native Component模式
把Weex當作一個iOS/Android元件來使用，類比ImageView。這類需求遍布手淘主鍊路，如首頁、主搜結果、交易元件化等，這類Native頁面主體已經很穩定，但是局部動态化需求旺盛導緻頻繁發版，解決這類問題也是Weex的重點。