Weex——關於移動端動態性的思考、實現和將來

什麼是動態性

今天在移動端，尤爲是像手機淘寶這樣的 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 可以逐步解決更廣泛的業務問題，儘量的保障工程質量和代碼質量，並發展成爲可以被社區接受、參與和信賴的技術方案。體現更大的價值，同時獲得更多的支持和更快的發展。這是咱們但願的，也但願是你們但願的：）

「手機淘寶技術團隊趙錦江（勾股）、黃金涌（伊耆）等專家參與本文創做」。 本文於InfoQ刊登。

關於阿里百川
阿里百川（baichuan.taobao.com)是阿里巴巴集團「雲」+「端」的核心戰略是阿里巴巴集團無線開放平臺，基於世界級的後端服務和成熟的商業組件，經過「技術、商業及大數據」的開放，爲移動創業者提供可快速搭建App、商業化APP並提高用戶體驗的解決方案；同時提供多元化的創業服務-物理空間、孵化運營、創業投資等，爲移動創業者提供全面保障。