摘要：什么是動態(tài)性今天在移動端，尤其是像手機(jī)淘寶這樣的中，動態(tài)性問題逐漸成為一個比較棘手的問題。在云端實現(xiàn)了天貓前端運營發(fā)布系統(tǒng)斑馬的對接，在前端開發(fā)實現(xiàn)了主會場的界面模塊和業(yè)務(wù)邏輯處理，同時在客戶端上對接了手機(jī)天貓手機(jī)淘寶。

今天在移動端，尤其是像手機(jī)淘寶這樣的 App 中，動態(tài)性問題逐漸成為一個比較棘手的問題。所謂動態(tài)性，就是把移動應(yīng)用本身的靈活性、迭代更新的周期和成本優(yōu)化到極致。比如手機(jī)淘寶的店鋪首頁，它允許商家實時裝修自己的店鋪，更新自家的商品、活動等信息；再比如淘寶、天貓每次大促的會場頁面，要求我們非常靈活的及時調(diào)整界面信息和狀態(tài)，確保在瞬息萬變的活動當(dāng)天緊跟促銷節(jié)奏，應(yīng)對各種突發(fā)情況。

動態(tài)性需求的出現(xiàn)有很多必然的因素：我們的移動應(yīng)用背后是一個平臺級甚至是生態(tài)級的電商系統(tǒng)，它需要有海納百川的能力和高速流通的特點，市場上很多移動應(yīng)用也有類似的客觀形態(tài)和訴求；同時整個行業(yè)迄今為止在移動端的積累都還不足以對產(chǎn)品形態(tài)、用戶體驗、交互方式等細(xì)節(jié)有完全的前期把握，一個移動應(yīng)用，客觀上需要更多的嘗試和探索，甚至是“試錯”，而這種動態(tài)化的程度和產(chǎn)品迭代演進(jìn)的速度有著強(qiáng)烈的正相關(guān)；第三，我們不必要為這些動態(tài)性在多個端投入重復(fù)的精力，更不應(yīng)該因此而頻繁的觸發(fā)新版本。所以動態(tài)性問題在今天的移動端顯得尤其重要。

動態(tài)性問題不只是移動端特有的，在互聯(lián)網(wǎng)技術(shù)發(fā)展的歷史長河中，桌面端也存在并經(jīng)歷著類似的事情。今天桌面端的結(jié)論似乎已經(jīng)形成，那就是W3C長期倡導(dǎo)的WebPlatform (或被稱為 Web App 或 HTML5 或瀏覽器)，然而這也經(jīng)歷了去平臺差異化、native插件支持 (flash player)、設(shè)備性能提升、渲染引擎優(yōu)化等過程。

而在移動端，阿里巴巴的無線事業(yè)部、兄弟團(tuán)隊、以及整個行業(yè)都在做著各種積極的嘗試和實踐：

Hybrid方案：以WebView為容器，以HTML5為基石，通過定義native特性的擴(kuò)展來支持的動態(tài)化產(chǎn)品研發(fā)，比如手機(jī)淘寶內(nèi)部的名為WindVane的容器，這類方案通常具有非常高的動態(tài)性，但存在的問題和動態(tài)性本身一樣明顯，那就是性能和展現(xiàn)效果上的不足，而且想把其優(yōu)勢在工程中充分發(fā)揮出來，對開發(fā)者在前端知識和經(jīng)驗上的積累也有較高的要求，篇幅有限不做過多的展開。

結(jié)構(gòu)化native view方案：以native view為容器進(jìn)行 native 級別的渲染，并定義一套描述視圖結(jié)構(gòu)的數(shù)據(jù)格式 (如 XML 或 JSON 等) ，然后通過動態(tài)改變或請求新的這樣的數(shù)據(jù)信息達(dá)到動態(tài)化的界面效果，比如阿里巴巴集團(tuán)內(nèi)出現(xiàn) (過) 的 WeApp、鳥巢、Dynative、PageKit 等，這類方案依賴一個結(jié)構(gòu)化的界面描述，并重點保障純展現(xiàn)輸出維度的動態(tài)性，各有千秋，但有一些共性的不足之處，比如對其它維度的動態(tài)性處理，比如邏輯的動態(tài)性，加載策略的動態(tài)性等。

React Native方案：大家習(xí)慣簡稱其為RN，以native為渲染引擎，通過腳本引擎支持界面Virtual DOM的轉(zhuǎn)換和邏輯控制，來實現(xiàn)界面的動態(tài)性。RN 前半年在阿里很多團(tuán)隊都得到了實踐，包括我所在的無線事業(yè)部，但效果并不令人滿意，首先是RN量級非常重，在請求、加載、渲染、交互、穩(wěn)定性等層面都不夠理想，而整個技術(shù)方案在社區(qū)的迭代和演進(jìn)過程也一直充滿著不確定性，這給團(tuán)隊產(chǎn)品級別的運用和后期跟進(jìn)帶來了很大的困惑。

實際上，我們覺得 RN 更像是一個全新的移動開發(fā)框架，而不是為了增強(qiáng)現(xiàn)有移動應(yīng)用的動態(tài)性而生。大家希望通過 RN 解決動態(tài)性問題，是因為它在客戶端引入了 JavaScript 引擎而已。

關(guān)于移動端動態(tài)化方案的再思考：Weex

綜上所述，我們能夠看到很多中動態(tài)性問題的解法，但也都各有所限。團(tuán)隊經(jīng)過不斷的觀察和討論，決定拿出一套更好的更針對移動端動態(tài)性問題的技術(shù)方案——這就是今天的 Weex！

Weex 在我們看來已經(jīng)具有非常多的特點，比如：

致力于移動端，充分調(diào)度 native 的能力
充分解決或回避性能瓶頸
靈活擴(kuò)展，多端統(tǒng)一，優(yōu)雅“降級”到 HTML5
保持較低的開發(fā)成本和學(xué)習(xí)成本
快速迭代，輕量實時發(fā)布
融入現(xiàn)有的 native 技術(shù)體系
工程化管理和監(jiān)控等
……

但是 Weex 其實最核心的訴求就是解決移動端動態(tài)性問題，它有自己非常鮮明的三大特點：

輕量：體積小巧，語法簡單，方便接入和上手

可擴(kuò)展：業(yè)務(wù)方可去中心化橫向定制組件和功能模塊

高性能：高速加載、高速渲染、體驗流暢

Weex 為移動端動態(tài)性問題而生，這些優(yōu)勢都是天然的，追求極致的。團(tuán)隊基于這三方面設(shè)計并實現(xiàn)了整套技術(shù)方案。

團(tuán)隊在 Weex 的設(shè)計和實踐中，還有一個很深刻的感悟，就是：找到性能與動態(tài)性之間的平衡點。

放眼這么多動態(tài)性技術(shù)方案，有這么幾個必經(jīng)之路：

動態(tài)內(nèi)容的開發(fā)/配置
動態(tài)內(nèi)容的云端部署
客戶端請求動態(tài)內(nèi)容
客戶端把動態(tài)內(nèi)容現(xiàn)成最終的效果

如果我們不只是處理純展現(xiàn)性質(zhì)的動態(tài)性內(nèi)容，那么要再加上一個必經(jīng)環(huán)節(jié)

動態(tài)內(nèi)容的開發(fā)/配置
動態(tài)內(nèi)容的云端部署
客戶端請求動態(tài)內(nèi)容
客戶端把動態(tài)內(nèi)容和邏輯解析成視圖
客戶端把視圖展現(xiàn)成最終的效果并處理用戶交互

這里面哪些環(huán)節(jié)值得擴(kuò)展、哪些環(huán)節(jié)需要更多的動態(tài)性、哪些環(huán)節(jié)是性能的瓶頸，是整個解法的關(guān)鍵。通過思考和討論，我們不難發(fā)現(xiàn)：

動態(tài)內(nèi)容的開發(fā)/配置需要快速實現(xiàn)
云端部署需要盡量去中心化，橫向可擴(kuò)展
客戶端請求需要盡量小的傳輸數(shù)據(jù)，需要盡量快的加載過程
客戶端內(nèi)容解析需要動態(tài)性
客戶端交互響應(yīng)需要動態(tài)性，需要盡量去中心化，橫向可擴(kuò)展
客戶端界面渲染需要高性能，需要盡量去中心化，橫向可擴(kuò)展

所以我們的解決方案中有幾個關(guān)鍵決策：

在內(nèi)容開發(fā)/配置和云端部署之間需要有 transformer 的轉(zhuǎn)換和處理能力，平衡開發(fā)體驗和客戶端請求的數(shù)據(jù)量

客戶端需要有 JavaScript 引擎，處理動態(tài)邏輯，提供動態(tài)加載策略，同時需要將復(fù)雜的端上的解析工作盡量提前

動態(tài)內(nèi)容的描述需要有結(jié)構(gòu)、樣式、數(shù)據(jù)、行為的分離，保障復(fù)雜的內(nèi)容可分解

客戶端界面渲染需要 native 的渲染能力，保障性能

Native 渲染和 JavaScript 引擎之間的邊界放在了 Virtual DOM，兩者通過約定 Virtual DOM 來進(jìn)行通信，而不是 template + data 或是別的邊界，確保渲染性能和靈活度的平衡

動態(tài)內(nèi)容發(fā)布、客戶端接入、組件、JS API 全部需要橫向擴(kuò)展性，保障 Weex 的核心足夠輕，足夠?qū)Ｗ?，同時竟可以支持更多的業(yè)務(wù)場景

Weex 核心設(shè)計理念是三端一體化的動態(tài)化解決方案，云端同學(xué)實現(xiàn)實時發(fā)布和動態(tài)部署、模版預(yù)解析處理，前端同學(xué)在 JS Framework 實現(xiàn)動態(tài)內(nèi)容解析并處理成 Virtual DOM，客戶端同學(xué)提供渲染實現(xiàn)和 native 特性的支持，接下來業(yè)務(wù)同學(xué)根據(jù) DSL 實現(xiàn)動態(tài)內(nèi)容的開發(fā)或配置即可。

Weex 在 DSL 設(shè)計上大量借鑒了 Web 標(biāo)準(zhǔn)的規(guī)范，并且通過主流且成熟的 MVVM 模式書寫 template、style、script，我們在學(xué)習(xí)成本、開發(fā)習(xí)慣方面為業(yè)務(wù)同學(xué)考慮了很多，這樣的話業(yè)務(wù)同學(xué)可以很快的學(xué)習(xí)和上手，并且保證代碼的規(guī)范性和可讀性 (這里要特別鳴謝一下 Vue.js 及其作者尤雨溪，我們在上層 DSL 的設(shè)計和 JS Framework 的實現(xiàn)上都做了深度的使用和借鑒，也在和作者的交流過程中受益匪淺)。

其次為了提升性能，減少客戶端的性能損耗，Weex 在服務(wù)器端實現(xiàn)了 DSL Transformer 的工作，可以在模版發(fā)布的同時，將 XML + CSS + JavaScript 代碼轉(zhuǎn)換為可以小數(shù)據(jù)量執(zhí)行效率高的 JS Bundle，并同步存儲至云端：如 Web Server、CDN 等。

再次為了保證業(yè)務(wù)邏輯的動態(tài)性，Weex 在客戶端的 JavaScript 引擎中預(yù)運行起了一套 JS Framework，來負(fù)責(zé)解析整個 JS Bundle，而 native 端則只負(fù)責(zé) Virtual DOM 的解析和布局、UI 渲染的實現(xiàn)、以及基礎(chǔ)網(wǎng)絡(luò)通訊、文件讀寫以及手勢處理等基礎(chǔ) API 的實現(xiàn)。

還有為了有效的提升工作效率，Weex 的 JS Bundle 可以實現(xiàn)三端跨平臺渲染展示，業(yè)務(wù)同學(xué)可以通過開發(fā)一份 Weex JS Bundle，來實現(xiàn) iOS/Android/HTML5 三端的正常展示。

所有的 native 組件和 JS API 全部都是模塊化的，業(yè)務(wù)同學(xué)可以通過注冊新的模塊和方法達(dá)到去中心化的能力擴(kuò)展。

關(guān)于 Weex 的性能優(yōu)化還有以下幾個細(xì)節(jié)：

1、JS Framework 通過對數(shù)據(jù)的依賴收集，實現(xiàn)響應(yīng)式的視圖層，再加上一層 diff 算法的優(yōu)化，可以有效的過濾冗余的操作和復(fù)雜的計算。

2、Native 端對通信，Virtual DOM 解析以及布局實現(xiàn)等進(jìn)行異步線程的處理，防止 UI 線程的阻塞。

3、對 UI 組件節(jié)點實現(xiàn)了復(fù)用處理，并對圖片資源進(jìn)行監(jiān)控和回收，有效的減少內(nèi)存的占用。

4、對于實時性要求較高的處理，Weex 允許第三方實現(xiàn) native 的定制需求來保證體驗的流暢性。

圖：Weex 關(guān)鍵性能測試和同類方案對比

注：數(shù)據(jù)取自實驗室測試結(jié)果，測試界面為 60 個左右“坑位”的商品列表，測試機(jī)型為：

iOS：iPhone5 - iOS 9.1

Android：三星SM-N9006 - Android 5.0

Weex 在雙十一項目中，參與并支撐了的移動端主會場界面展示和動態(tài)處理。在云端實現(xiàn)了天貓前端運營發(fā)布系統(tǒng)“斑馬”的對接，在前端開發(fā)實現(xiàn)了主會場的界面模塊和業(yè)務(wù)邏輯處理，同時在客戶端上對接了手機(jī)天貓、手機(jī)淘寶。

在每次雙十一中，主會場都是非常關(guān)鍵的一個環(huán)節(jié)。大量的流量把用戶、店鋪、商品從各路而來匯聚在這里作為著陸的起點。在內(nèi)容的復(fù)雜度、靈活性、體驗等方面都有著極高的要求。根據(jù)我們往年的經(jīng)驗，會場的分流能力強(qiáng)化、分會場的層級扁平化、運營工作量合理化、體驗和性能的優(yōu)化，是非常重要的幾個細(xì)節(jié)，同時也推演出了今年主會場的三大改進(jìn)目標(biāo)：

體驗 app 化

層級扁平化

內(nèi)容個性化

體驗 app 化意味著我們需要有超越傳統(tǒng) HTML5 的性能和體驗；層級扁平化意味著每一層的內(nèi)容會更加豐富和復(fù)雜，主會場當(dāng)然也不例外；內(nèi)容個性化則需要我們在前期內(nèi)容的產(chǎn)生、算法、投放、客戶端內(nèi)容加載和界面呈現(xiàn)等每個環(huán)節(jié)進(jìn)行全面升級。

想做到這些，光憑一個好的創(chuàng)意和想法、或憑借員工超強(qiáng)的執(zhí)行力、或靠砸錢砸機(jī)器，都是沒有辦法做到的，這個問題需要技術(shù)驅(qū)動力來解決！需要精密的設(shè)計和實現(xiàn)。Weex 團(tuán)隊在整個雙十一的籌備過程中和需求方就上述問題進(jìn)行了深入的溝通和交流，并拿出了切實有效的技術(shù)方案，很好的解決了其中的很多關(guān)鍵環(huán)節(jié)問題，并且 Weex 作為一個新的技術(shù)方案很好的經(jīng)受住了如此重要的“考驗”！

首先，我們通過 Weex 實現(xiàn)了在雙十一主會場的 iOS/Android/HTML5 的一次開發(fā)，多端同步展示能力，并且展現(xiàn)效果和各方面的體驗都是 native 級別的。

第二，我們配合算法團(tuán)隊實現(xiàn)了今年的雙十一主會場的個性化需求，即所謂的“千人千面”，并實現(xiàn)了雙十一主會場商家的運營配置的靜態(tài)數(shù)據(jù)和個性化推薦算法的動態(tài)數(shù)據(jù)在端側(cè)的拼合展示。并且優(yōu)化了整個客戶端內(nèi)容加載、界面初始化、交互時的性能

第三，Weex 保有了接近 HTML5 的靈活調(diào)整發(fā)布機(jī)制，實現(xiàn)了在客戶端側(cè)的渲染動態(tài)性，運營人員可以通過配置實時調(diào)整主會場樓層位置，以及“坑位”的排布，以及界面的布局展示和樣式調(diào)整。

第四，基于優(yōu)異的性能表現(xiàn)，在內(nèi)容呈現(xiàn)的數(shù)量上，我們也突破了傳統(tǒng)的 120 “坑位”的性能極限，本次雙十一最后實際的最大“坑位”數(shù)接近了 180 個，依然表現(xiàn)非常完美——要知道團(tuán)隊在前期都是拿 300 個“坑位”進(jìn)行“暴力極限測試”的。為會場的扁平化進(jìn)一步提供了保障。

目前 Weex 已經(jīng)在阿里巴巴集團(tuán)內(nèi)和更多的業(yè)務(wù)方展開合作，包括淘寶雙十二等項目 (筆者撰稿時恰逢雙十二當(dāng)天，Weex 正在接受新一輪的業(yè)務(wù)洗禮！)，我們希望后續(xù)會有更多的實踐經(jīng)驗和心得持續(xù)分享出來。

Weex 團(tuán)隊會緊抓移動端動態(tài)性這個關(guān)鍵命題，圍繞 Weex 的三大特點：輕量、高性能、易擴(kuò)展，進(jìn)行周期性的迭代和完善。我們會在更簡單直接的實踐方式、更高的加載/啟動/渲染/交互性能、更強(qiáng)的去中心化定制性和橫向擴(kuò)展性方面不斷突破和創(chuàng)新。并定期在集團(tuán)內(nèi)開放最新的版本和文檔、配套工具、周邊生態(tài)等。

關(guān)于開源：團(tuán)隊始終認(rèn)同一個觀點——開源并非一個簡單的行為，而是一個過程和最終的結(jié)果構(gòu)成的整體。團(tuán)隊希望 Weex 能夠逐步解決更普遍的業(yè)務(wù)問題，盡可能的保障工程質(zhì)量和代碼質(zhì)量，并發(fā)展成為能夠被社區(qū)接受、參與和信賴的技術(shù)方案。體現(xiàn)更大的價值，同時得到更多的支持和更快的發(fā)展。這是我們希望的，也希望是大家希望的：）

“手機(jī)淘寶技術(shù)團(tuán)隊趙錦江（勾股）、黃金涌（伊耆）等專家參與本文創(chuàng)作”。 本文于InfoQ刊登。

關(guān)于阿里百川
阿里百川（baichuan.taobao.com)是阿里巴巴集團(tuán)“云”+“端”的核心戰(zhàn)略是阿里巴巴集團(tuán)無線開放平臺，基于世界級的后端服務(wù)和成熟的商業(yè)組件，通過“技術(shù)、商業(yè)及大數(shù)據(jù)”的開放，為移動創(chuàng)業(yè)者提供可快速搭建App、商業(yè)化APP并提升用戶體驗的解決方案；同時提供多元化的創(chuàng)業(yè)服務(wù)-物理空間、孵化運營、創(chuàng)業(yè)投資等，為移動創(chuàng)業(yè)者提供全面保障。