今天在移動端，尤其是像手機淘寶這樣的 app 中，動態性問題逐漸成爲一個比較棘手的問題。所謂動態性，就是把移動應用本身的靈活性、迭代更新的週期和成本優化到極致。比如手機淘寶的店鋪首頁，它允許商家實時裝修自己的店鋪，更新自家的商品、活動等信息；再比如淘寶、天貓每次大促的會場頁面，要求我們非常靈活的及時調整界面信息和狀態，確保在瞬息萬變的活動當天緊跟促銷節奏，應對各種突發情況。
爲什麼要解決動態化的問題動態性需求的出現有很多必然的因素：我們的移動應用背後是一個平臺級甚至是生態級的電商系統，它需要有海納百川的能力和高速流通的特點，市場上很多移動應用也有類似的客觀形態和訴求；同時整個行業迄今爲止在移動端的積累都還不足以對產品形態、用戶體驗、交互方式等細節有完全的前期把握，一個移動應用，客觀上需要更多的嘗試和探索，甚至是“試錯”，而這種動態化的程度和產品迭代演進的速度有着強烈的正相關；第三，我們不必要爲這些動態性在多個端投入重複的精力，更不應該因此而頻繁的觸發新版本。所以動態性問題在今天的移動端顯得尤其重要。
動態性問題的歷史動態性問題不只是移動端特有的，在互聯網技術發展的歷史長河中，桌面端也存在並經歷着類似的事情。今天桌面端的結論似乎已經形成，那就是W3C長期倡導的WebPlatform (或被稱爲 Web App 或 HTML5 或瀏覽器)，然而這也經歷了去平臺差異化、native插件支持 (flash player)、設備性能提升、渲染引擎優化等過程。
而在移動端，阿里巴巴的無線事業部、兄弟團隊、以及整個行業都在做着各種積極的嘗試和實踐：
-
Hybrid方案：以WebView爲容器，以HTML5爲基石，通過定義native特性的擴展來支持的動態化產品研發，比如手機淘寶內部的名爲WindVane的容器，這類方案通常具有非常高的動態性，但存在的問題和動態性本身一樣明顯，那就是性能和展現效果上的不足，而且想把其優勢在工程中充分發揮出來，對開發者在前端知識和經驗上的積累也有較高的要求，篇幅有限不做過多的展開。
-
結構化native view方案：以native view爲容器進行 native 級別的渲染，並定義一套描述視圖結構的數據格式 (如 XML 或 JSON 等) ，然後通過動態改變或請求新的這樣的數據信息達到動態化的界面效果，比如阿里巴巴集團內出現 (過) 的 WeApp、鳥巢、Dynative、PageKit 等，這類方案依賴一個結構化的界面描述，並重點保障純展現輸出維度的動態性，各有千秋，但有一些共性的不足之處，比如對其它維度的動態性處理，比如邏輯的動態性，加載策略的動態性等。
-
React Native方案：大家習慣簡稱其爲RN，以native爲渲染引擎，通過腳本引擎支持界面Virtual DOM的轉換和邏輯控制，來實現界面的動態性。RN 前半年在阿里很多團隊都得到了實踐，包括我所在的無線事業部，但效果並不令人滿意，首先是RN量級非常重，在請求、加載、渲染、交互、穩定性等層面都不夠理想，而整個技術方案在社區的迭代和演進過程也一直充滿着不確定性，這給團隊產品級別的運用和後期跟進帶來了很大的困惑。
實際上，我們覺得 RN 更像是一個全新的移動開發框架，而不是爲了增強現有移動應用的動態性而生。大家希望通過 RN 解決動態性問題，是因爲它在客戶端引入了 JavaScript 引擎而已。
關於移動端動態化方案的再思考：Weex
綜上所述，我們能夠看到很多中動態性問題的解法，但也都各有所限。團隊經過不斷的觀察和討論，決定拿出一套更好的更針對移動端動態性問題的技術方案——這就是今天的 Weex！
Weex的設計理念和思考過程Weex 在我們看來已經具有非常多的特點，比如：
-
致力於移動端，充分調度 native 的能力
-
充分解決或迴避性能瓶頸
-
靈活擴展，多端統一，優雅“降級”到 HTML5
-
保持較低的開發成本和學習成本
-
快速迭代，輕量實時發佈
-
融入現有的 native 技術體系
-
工程化管理和監控等
-
……
但是 Weex 其實最核心的訴求就是解決移動端動態性問題，它有自己非常鮮明的三大特點：
-
輕量：體積小巧，語法簡單，方便接入和上手
-
可擴展：業務方可去中心化橫向定製組件和功能模塊
-
高性能：高速加載、高速渲染、體驗流暢
Weex 爲移動端動態性問題而生，這些優勢都是天然的，追求極致的。團隊基於這三方面設計並實現了整套技術方案。
團隊在 Weex 的設計和實踐中，還有一個很深刻的感悟，就是：找到性能與動態性之間的平衡點。
放眼這麼多動態性技術方案，有這麼幾個必經之路：
-
動態內容的開發/配置
-
動態內容的雲端部署
-
客戶端請求動態內容
-
客戶端把動態內容現成最終的效果
如果我們不只是處理純展現性質的動態性內容，那麼要再加上一個必經環節
-
動態內容的開發/配置
-
動態內容的雲端部署
-
客戶端請求動態內容
-
客戶端把動態內容和邏輯解析成視圖
-
客戶端把視圖展現成最終的效果並處理用戶交互
這裏面哪些環節值得擴展、哪些環節需要更多的動態性、哪些環節是性能的瓶頸，是整個解法的關鍵。通過思考和討論，我們不難發現：
-
動態內容的開發/配置需要快速實現
-
雲端部署需要儘量去中心化，橫向可擴展
-
客戶端請求需要儘量小的傳輸數據，需要儘量快的加載過程
-
客戶端內容解析需要動態性
-
客戶端交互響應需要動態性，需要儘量去中心化，橫向可擴展
-
客戶端界面渲染需要高性能，需要儘量去中心化，橫向可擴展
所以我們的解決方案中有幾個關鍵決策：
-
在內容開發/配置和雲端部署之間需要有 transformer 的轉換和處理能力，平衡開發體驗和客戶端請求的數據量
-
客戶端需要有 JavaScript 引擎，處理動態邏輯，提供動態加載策略，同時需要將複雜的端上的解析工作儘量提前
-
動態內容的描述需要有結構、樣式、數據、行爲的分離，保障複雜的內容可分解
-
客戶端界面渲染需要 native 的渲染能力，保障性能
-
Native 渲染和 JavaScript 引擎之間的邊界放在了 Virtual DOM，兩者通過約定 Virtual DOM 來進行通信，而不是 template + data 或是別的邊界，確保渲染性能和靈活度的平衡
-
動態內容發佈、客戶端接入、組件、JS API 全部需要橫向擴展性，保障 Weex 的核心足夠輕，足夠專注，同時竟可以支持更多的業務場景
Weex 核心設計理念是三端一體化的動態化解決方案，雲端同學實現實時發佈和動態部署、模版預解析處理，前端同學在 JS Framework 實現動態內容解析並處理成 Virtual DOM，客戶端同學提供渲染實現和 native 特性的支持，接下來業務同學根據 DSL 實現動態內容的開發或配置即可。
Weex 在 DSL 設計上大量借鑑了 Web 標準的規範，並且通過主流且成熟的 MVVM 模式書寫 template、style、script，我們在學習成本、開發習慣方面爲業務同學考慮了很多，這樣的話業務同學可以很快的學習和上手，並且保證代碼的規範性和可讀性 (這裏要特別鳴謝一下 Vue.js 及其作者尤雨溪，我們在上層 DSL 的設計和 JS Framework 的實現上都做了深度的使用和借鑑，也在和作者的交流過程中受益匪淺)。
其次爲了提升性能，減少客戶端的性能損耗，Weex 在服務器端實現了 DSL Transformer 的工作，可以在模版發佈的同時，將 XML + CSS + JavaScript 代碼轉換爲可以小數據量執行效率高的 JS Bundle，並同步存儲至雲端：如 Web Server、CDN 等。
再次爲了保證業務邏輯的動態性，Weex 在客戶端的 JavaScript 引擎中預運行起了一套 JS Framework，來負責解析整個 JS Bundle，而 native 端則只負責 Virtual DOM 的解析和佈局、UI 渲染的實現、以及基礎網絡通訊、文件讀寫以及手勢處理等基礎 API 的實現。
還有爲了有效的提升工作效率，Weex 的 JS Bundle 可以實現三端跨平臺渲染展示，業務同學可以通過開發一份 Weex JS Bundle，來實現 iOS/Android/HTML5 三端的正常展示。
所有的 native 組件和 JS API 全部都是模塊化的，業務同學可以通過註冊新的模塊和方法達到去中心化的能力擴展。
關於 Weex 的性能優化還有以下幾個細節：
-
JS Framework 通過對數據的依賴收集，實現響應式的視圖層，再加上一層 diff 算法的優化，可以有效的過濾冗餘的操作和複雜的計算。
-
Native 端對通信，Virtual DOM 解析以及佈局實現等進行異步線程的處理，防止 UI 線程的阻塞。
-
對 UI 組件節點實現了複用處理，並對圖片資源進行監控和回收，有效的減少內存的佔用。
-
對於實時性要求較高的處理，Weex 允許第三方實現 native 的定製需求來保證體驗的流暢性。
圖：Weex 關鍵性能測試和同類方案對比
> 注：數據取自實驗室測試結果，測試界面爲 60 個左右“坑位”的商品列表，測試機型爲：
> - iOS：iPhone5 - iOS 9.1
> - Android：三星SM-N9006 - Android 5.0
Weex 在雙十一項目中，參與並支撐了的移動端主會場界面展示和動態處理。在雲端實現了天貓前端運營發佈系統“斑馬”的對接，在前端開發實現了主會場的界面模塊和業務邏輯處理，同時在客戶端上對接了手機天貓、手機淘寶。
在每次雙十一中，主會場都是非常關鍵的一個環節。大量的流量把用戶、店鋪、商品從各路而來匯聚在這裏作爲着陸的起點。在內容的複雜度、靈活性、體驗等方面都有着極高的要求。根據我們往年的經驗，會場的分流能力強化、分會場的層級扁平化、運營工作量合理化、體驗和性能的優化，是非常重要的幾個細節，同時也推演出了今年主會場的三大改進目標：
-
體驗 app 化
-
層級扁平化
-
內容個性化
體驗 app 化意味着我們需要有超越傳統 HTML5 的性能和體驗；層級扁平化意味着每一層的內容會更加豐富和複雜，主會場當然也不例外；內容個性化則需要我們在前期內容的產生、算法、投放、客戶端內容加載和界面呈現等每個環節進行全面升級。
想做到這些，光憑一個好的創意和想法、或憑藉員工超強的執行力、或靠砸錢砸機器，都是沒有辦法做到的，這個問題需要技術驅動力來解決！需要精密的設計和實現。Weex 團隊在整個雙十一的籌備過程中和需求方就上述問題進行了深入的溝通和交流，並拿出了切實有效的技術方案，很好的解決了其中的很多關鍵環節問題，並且 Weex 作爲一個新的技術方案很好的經受住瞭如此重要的“考驗”！
首先，我們通過 Weex 實現了在雙十一主會場的 iOS/Android/HTML5 的一次開發，多端同步展示能力，並且展現效果和各方面的體驗都是 native 級別的。
第二，我們配合算法團隊實現了今年的雙十一主會場的個性化需求，即所謂的“千人千面”，並實現了雙十一主會場商家的運營配置的靜態數據和個性化推薦算法的動態數據在端側的拼合展示。並且優化了整個客戶端內容加載、界面初始化、交互時的性能
第三，Weex 保有了接近 HTML5 的靈活調整發布機制，實現了在客戶端側的渲染動態性，運營人員可以通過配置實時調整主會場樓層位置，以及“坑位”的排布，以及界面的佈局展示和樣式調整。
第四，基於優異的性能表現，在內容呈現的數量上，我們也突破了傳統的 120 “坑位”的性能極限，本次雙十一最後實際的最大“坑位”數接近了 180 個，依然表現非常完美——要知道團隊在前期都是拿 300 個“坑位”進行“暴力極限測試”的。爲會場的扁平化進一步提供了保障。
更多的Weex項目實踐分享與總結目前 Weex 已經在阿里巴巴集團內和更多的業務方展開合作，包括淘寶雙十二等項目 (筆者撰稿時恰逢雙十二當天，Weex 正在接受新一輪的業務洗禮！)，我們希望後續會有更多的實踐經驗和心得持續分享出來。
爲了Weex的目標和規劃未來 Weex 除了繼續服務於會場這樣的需求 (如雙十二、年貨節等) 之外，更希望可以支持到更多的動態化場景，並圍繞 Weex 的核心優勢不斷解決更多的問題，甚至不僅解決動態性這個歷史難題，還可以進一步解決跨端重複開發、用戶體驗一致性、容器通用技術規範等問題；甚至不僅解決手機淘寶、手機天貓的問題，還可以解決阿里巴巴兄弟團隊、國內甚至行業內的普遍問題；體現出更大的價值！當然這一切看起來天馬行空的夢想需要我們腳踏實地的一步一步走出來，始終保持清醒的頭腦，圍繞 Weex 的核心價值，聚焦在覈心的問題上，也非常希望可以藉助整個大團隊、整個集團乃至整個技術社區的力量。
Weex 團隊會緊抓移動端動態性這個關鍵命題，圍繞 Weex 的三大特點：輕量、高性能、易擴展，進行週期性的迭代和完善。我們會在更簡單直接的實踐方式、更高的加載/啓動/渲染/交互性能、更強的去中心化定製性和橫向擴展性方面不斷突破和創新。並定期在集團內開放最新的版本和文檔、配套工具、周邊生態等。
隨着 Weex 新版本的不斷迭代，我們同時也會面向集團範圍內的業務方，採取更開放的溝通和服務策略，深入到業務中，瞭解大家在實踐中的真實訴求和痛點，同時提供 Weex 的技術支持。在保障 Weex 的實踐效果和產出的同時也會汲取更多信息和靈感作爲後續 Weex 努力和完善的重要參考。
團隊在長期的迭代和業務支持上會逐步找到一個穩定的節奏，並且做好打持久戰的準備。隨着工作的進展和不斷深入，我們相信 Weex 可以走出一個“扇形”，並一步步的實現大家期待種的宏偉藍圖和遠大設想。
關於開源：團隊始終認同一個觀點——開源並非一個簡單的行爲，而是一個過程和最終的結果構成的整體。團隊希望 Weex 能夠逐步解決更普遍的業務問題，儘可能的保障工程質量和代碼質量，並發展成爲能夠被社區接受、參與和信賴的技術方案。體現更大的價值，同時得到更多的支持和更快的發展。這是我們希望的，也希望是大家希望的：）
“手機淘寶技術團隊趙錦江（勾股）、黃金湧（伊耆）等專家參與本文創作。”本文系InfoQ原創首發，轉載或節選內容前需獲授權。同時，也歡迎更多企業、組織與InfoQ展開內容合作，更歡迎個人原創投稿。請加小Q微信：infoqzone，並備註「轉載+微信號」or「合作/投稿+名字」。