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

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

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

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

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

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

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

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

實(shí)際上，我們覺得 RN 更像是一個(gè)全新的移動(dòng)開發(fā)框架，而不是為了增強(qiáng)現(xiàn)有移動(dòng)應(yīng)用的動(dòng)態(tài)性而生。大家希望通過 RN 解決動(dòng)態(tài)性問題，是因?yàn)樗诳蛻舳艘肓?JavaScript 引擎而已。

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

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

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

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

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

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

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

高性能：高速加載、高速渲染、體驗(yàn)流暢

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iOS：iPhone5 - iOS 9.1

Android：三星SM-N9006 - Android 5.0

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

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

體驗(yàn) app 化

層級(jí)扁平化

內(nèi)容個(gè)性化

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

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

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

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

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

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

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

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

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

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

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