2016年qcon大會首日，阿裡巴巴資深總監、淘寶移動平台、阿裡百川負責人莊卓然宣布移動端高性能動态化方案weex即時内測，并将于6月開源。此消息一出，群情洶湧，在座的程式猿、攻城獅們紛紛拿起手機掃碼，以期第一時間感受weex的神奇之力。
在第二天的主題分享會上，阿裡巴巴前端開發專家趙錦江和技術專家徐凱對weex進行了深入的解析。以下為演講速記整理後的成文。
<b></b>
<b>阿裡怎麼看待移動開發？</b>
目前的移動開發者面臨的最大痛點就是面對極其複雜的環境，對此，莊卓然給出一個公式，移動開發的複雜度=應用數量×平台數量×要适配的各種各樣的機型。
如何解決這個問題呢？在解決問題之前，首先要對移動開發的未來有着精準的研判。
阿裡認為，移動開發的未來必定更加平衡，也就是說必須是性能與動态兼得，如此，才能夠滿足未來使用者的需求。另外，移動開發在未來也必定是開放互聯的狀态，移動網際網路将來肯定是基于更加大衆化的技術體系，沒有平台之間的隔閡，而且簡單易用。
是以，阿裡結合移動開發的現狀并圍繞其願景推出了weex解決方案。
事實上，在去年的雙11活動中，weex就得到了實戰的驗證，且表現不俗。時至今日，weex已經被阿裡技術團隊多次運用，并“創造”出各種豐富的場景，整體的表現非常優異。
把移動端所有界面拆分成各個page，然後中間設定有路由的控制邏輯，同時，将移動端各種各樣的能力通過各種api提供給開發者。這是阿裡對移動開發模型的了解。
weex通過标準化的東西，包括html、css和js這些前端非常快速易用好學的文法作為開發體驗，提供給開發者。另外，weex的文法設計尊重還web的标準。
<b>weex的工作原理</b>
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的重點。
3.h5 component模式
在h5種使用weex，類比wvc。一些較複雜或特殊的h5頁面短期内無法完全轉為weex全頁模式（或rn），比如互動類頁面、一些複雜頻道頁等。這個痛點的解決辦法是：在現有的h5頁面上做微調，引入native解決長清單記憶體暴增、滾動不流暢、動畫/手勢體驗差等問題。
另外，wvc将會融入到weex中，成為weex的h5 components模式。
歡迎掃碼關注，更多技術分享。