什麼是動态性
今天在移動端，尤其是像手機淘寶這樣的 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的核心工作鍊細節
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在天貓雙十一的項目實踐
weex 在雙十一項目中，參與并支撐了的移動端主會場界面展示和動态處理。在雲端實作了天貓前端營運釋出系統“斑馬”的對接，在前端開發實作了主會場的界面子產品和業務邏輯處理，同時在用戶端上對接了手機天貓、手機淘寶。
去年雙十一主會場的挑戰
在每次雙十一中，主會場都是非常關鍵的一個環節。大量的流量把使用者、店鋪、商品從各路而來彙聚在這裡作為着陸的起點。在内容的複雜度、靈活性、體驗等方面都有着極高的要求。根據我們往年的經驗，會場的分流能力強化、分會場的層級扁平化、營運工作量合理化、體驗和性能的優化，是非常重要的幾個細節，同時也推演出了今年主會場的三大改進目标：
體驗 app 化
層級扁平化
内容個性化
體驗 app 化意味着我們需要有超越傳統 html5 的性能和體驗；層級扁平化意味着每一層的内容會更加豐富和複雜，主會場當然也不例外；内容個性化則需要我們在前期内容的産生、算法、投放、用戶端内容加載和界面呈現等每個環節進行全面更新。
weex在主會場中發揮的作用
想做到這些，光憑一個好的創意和想法、或憑借員工超強的執行力、或靠砸錢砸機器，都是沒有辦法做到的，這個問題需要技術驅動力來解決！需要精密的設計和實作。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 能夠逐漸解決更普遍的業務問題，盡可能的保障工程品質和代碼品質，并發展成為能夠被社群接受、參與和信賴的技術方案。展現更大的價值，同時得到更多的支援和更快的發展。這是我們希望的，也希望是大家希望的：）