Weex詳解：靈活的移動端高性能動態(tài)化方案

在2016年4月份的QCon上，阿里巴巴資深總監(jiān)，淘寶移動平臺及新業(yè)務(wù)事業(yè)部、阿里百川負(fù)責(zé)人莊卓然（花名南天）宣布阿里移動端跨平臺開發(fā)框架Weex開始內(nèi)測，并將于6月份開源。在QCon的第二天，阿里技術(shù)專家徐凱（花名鬼道）和阿里前端開發(fā)專家趙錦江（花名勾股）向參會者做了《Weex——靈活的移動端高性能動態(tài)化方案》的演講，對這一技術(shù)方案進(jìn)行了詳細(xì)的剖析。

以下為演講內(nèi)容的整理：

昨天南天宣布Weex啟動開源內(nèi)測，截至到今天中午，我們統(tǒng)計(jì)申請內(nèi)測用戶突破1400人，大家的熱烈程度遠(yuǎn)遠(yuǎn)超過我們的設(shè)想，非常感謝大家支持。

在我們對移動開發(fā)最佳實(shí)踐的思考中，我們認(rèn)為移動開發(fā)的未來是更平衡的方案，一定是性能和動態(tài)性兼得。第二個，它一定是開放互聯(lián)的，PC端一直也是這樣的，也是非常好的狀態(tài)。我們覺得移動互聯(lián)網(wǎng)將來肯定也是基于更大眾化的技術(shù)體系，沒有平臺之間的隔閡，簡單直接易用，這是我們最希望看到的?；谶@些設(shè)想，我們有了Weex方案。

Weex是從去年雙十一的時候第一次在我們正式產(chǎn)品中使用，承載了雙十一主會場的工作。有人會問，Weex是不是除了做主會場別的地方就比較吃力呢？從去年雙十一到現(xiàn)在，包括我們自己的嘗試和阿里內(nèi)網(wǎng)做開源內(nèi)測活動，大家也貢獻(xiàn)了很多內(nèi)容，包括昨天Keynote演示的僵尸動畫，掃雷、計(jì)算器都有，各種豐富場景的東西都可以通過Weex做出來，不僅僅是做主會場的技術(shù)方案。

對移動端開發(fā)模型的理解

我們談?wù)刉eex團(tuán)隊(duì)對移動端開發(fā)模型的理解。

今天絕大多數(shù)移動端APP是這樣一個最佳實(shí)踐，首先把移動端所有界面拆分成各個page，中間有一個路由的控制邏輯。同時我們需要移動端各種各樣豐富的能力，通過API的形式提供給開發(fā)者。這是我們認(rèn)為一個比較理想的開發(fā)模型。

從開發(fā)模型來講，我們比較傾向于通過標(biāo)準(zhǔn)化的一些東西，包括HTML、CSS、JS這些前端非?？焖僖子煤脤W(xué)的語法作為一個開發(fā)體驗(yàn)，提供給開發(fā)者。這里強(qiáng)調(diào)一下，我們語法設(shè)計(jì)尊重了Web標(biāo)準(zhǔn)，包括核心源代碼都是從Vue.js——一個非常優(yōu)秀的MVVM前端框架來的。我們的開源內(nèi)測同步在海外通過Vue.js的Twitter等途徑進(jìn)行宣傳，得到了非常熱烈的反響，短短一天時間內(nèi)，老外們的關(guān)注度和熱情也是出乎我們的意料。有些人非常興奮和激動，想知道什么時候看到源代碼，和我們聯(lián)系，我們覺得也是值得高興的一件事情。

Weex的組件化與DSL語法

Weex編寫的頁面天然的支持組件化，首先，我們的界面可以是一個組件化的，把一個復(fù)雜界面分成每個組件，剛才演示的都是簡單的組件，每個組件都可以看成是一段template，style，script，放到模型里，對應(yīng)到界面的結(jié)構(gòu)，樣式細(xì)節(jié)，行為定義。在view里面我們傾向于把數(shù)據(jù)和視圖當(dāng)中需要展示和需要有動態(tài)變化的部分做一個數(shù)據(jù)綁定，綁定之后我如果想更改界面的話，通過改變數(shù)據(jù)就可以做到。這是從model到view非常順暢的控制邏輯和代碼方式，這也算是Weex上層語法設(shè)計(jì)的基礎(chǔ)。如果大家做的界面比較復(fù)雜，可能有更多細(xì)節(jié)，或者做更多分解，我們需要從整體上對整個界面以模塊為單位作為拆解，對每個模塊做定義，如果界面足夠復(fù)雜，可以先拆成組件，再把每個組件具體內(nèi)容進(jìn)行定義。定義方式就是通過結(jié)構(gòu)、樣式和行為角度對它進(jìn)行定義，通過有機(jī)方式把這些組件結(jié)合起來，完成頁面開發(fā)。

關(guān)鍵語法簡述。首先看看template，大概有幾個元素。它首先是virtual DOM tree展示，包括事件綁定，組件跟組件之間還可以嵌套，還可以有子元素，這是整體template結(jié)構(gòu)。再往下是style，一方面可以把共用樣式抽樣出來，另一方面可以讓template結(jié)構(gòu)更加清晰，不至于陷入到整個具體樣式描述當(dāng)中去。我們在這邊會做一些收斂，我們只支持了單個class的selector寫法，主要從性能角度考慮。傳統(tǒng)的css可以理解為是一個N對N的數(shù)據(jù)庫，匹配過程非常復(fù)雜，性能也得不到非常好的保證，我們?yōu)榱吮ＷC性能，我們把selector約定在單個class，性能可以保證。

另外，我們的樣式天然默認(rèn)的就是scoped，大家可以放心定義各種各樣的classname，不擔(dān)心和其他組件相沖突，全局沖突是CSS“七宗罪”中的一個，其實(shí)這也是我們非常重視的，所以在實(shí)踐上我們把它做到了scoped。

其他的，可以做一些展示的控制，比如if、repeat剛才演示中也提到了。剛才沒有演示到的這個很特殊，append，在性能不是那么好的Android下，界面加載過程用戶是可感知的，不是一瞬間做到的。我們加這個值可以讓你精細(xì)化展示界面的顆粒度，如果上層做了append等于tree的話，里面一系列東西會做一次性的加載，這是從性能優(yōu)化角度做的特殊設(shè)計(jì)。再是id，我們可以通過在這里面寫id拿到這個值，把它當(dāng)作參數(shù)傳給API做處理。

我們現(xiàn)在已經(jīng)支持的組件，除了剛才演示的div空白容器、圖片、文本之外，我們還支持slider：一個性能比較好的滑塊組件，還有l(wèi)ist，性能上自動做內(nèi)存管理和資源管理的組件，把性能和幀率各方面都做的比較好。還有input，輸入框我們是最近才做的，也是剛支持的，可能還有試驗(yàn)性階段的小東西。在這個范圍之外，業(yè)務(wù)方可在上層橫向擴(kuò)展，稍后會有具體介紹。這是template和style部分的介紹。

樣式部分我們支持flexbox，非常靈活通用便捷的布局方式，有了flexbox，只要你的界面可以拆分成豆腐塊的，都可以用flexbox來做，同時我們還做了fixed和sticky這兩個特殊的布局，sticky意思是如果有一個列表分類，比如聯(lián)系人ABC字母滾到屏幕外，會停在最上面，那個效果就是sticky，當(dāng)你劃走它就會跟著走，在各種手機(jī)應(yīng)用當(dāng)中是一個比較常見的東西。同樣，更多的樣式每個組件也可以自己定制，非常靈活。

從事件角度，click是基礎(chǔ)事件，change在表單的值改變和滑快的第幾幀改變時都會有，同時我們加入了appear和disappear，當(dāng)我通過任意操作進(jìn)入屏幕區(qū)域內(nèi)，會觸發(fā)appear事件，出來以后會觸發(fā)disappear事件，非常適合用在一些lazyload之類的邏輯場景。這些事件也可以在各自組件中做橫向擴(kuò)展。

Script部分剛才例子也提到了，主要是viewmodel設(shè)計(jì)，最主要的是data和methods，值修改之后相應(yīng)數(shù)據(jù)綁定的值也會發(fā)生改變。除此之外我們提供了生命周期的方法，創(chuàng)建的時候，數(shù)據(jù)監(jiān)聽完成的時候，渲染完成的時候，你只要把這三個方法同樣寫在data和methods下面。還有原生 API，剛才演示的時候也出現(xiàn)了，這里不多介紹。

組件化搭建很復(fù)雜，通過定義子組件，比如我上面有一個foo組件，通過foo標(biāo)簽就可以把foo嵌入到別的組件中來，數(shù)據(jù)傳遞的話就可以在foo組件中寫a和b，foo元素就可以通過這種方式傳遞給子元素，然后進(jìn)行處理。再是組件中間的通信，也是事件機(jī)制，每個組件可以通過和off，對自定義事件進(jìn)行監(jiān)聽和解綁定，想觸發(fā)事件也有三個方法：只傳給自己、dispatch向上冒泡給所有父組件、$broadcast廣播給所有子組件，這些設(shè)計(jì)和Vue非常相近的，做到組件之間的通信。

除了剛才介紹的這些特性，我們未來還會提供更豐富的、相信也是開發(fā)者需要的、平時開發(fā)中會碰到的場景，更豐富的表單，還有更好的動畫展示，包括復(fù)雜手勢場景。在這方面，無論是性能還是開發(fā)體驗(yàn)、最終效果都能夠非常好，這是團(tuán)隊(duì)正在努力在未來提供給大家的。同時我們希望收集和分享更多相關(guān)素材，做出更多工具，提供更好的開發(fā)者體驗(yàn)給大家。

更多的內(nèi)容，包括剛才演示的Playground App都可以通過我們的官網(wǎng)找到，現(xiàn)在處在開源內(nèi)測階段，大家提交申請，通過以后可以訪問倉庫，了解更具體的內(nèi)容。

Weex的工作原理

這張圖大家都不陌生，前面也提到了，勾股說的主要是DSL這層。再往下到了Virtual DOM和Render層；H5，我刻意把它用不一樣的顏色標(biāo)出來，想讓大家知道我們設(shè)計(jì)之初就考慮到希望在三端上能夠展現(xiàn)，所以這個地方稍微加亮一些。

我們把剛才這張圖再稍微展開一下，最上面是我們的DSL，我們一般叫Weex文件，通過transformer這層，部署到Server，服務(wù)端就完成了。大家不用擔(dān)心我們的轉(zhuǎn)換是不是有性能問題，因?yàn)檫@在服務(wù)端就已經(jīng)完成。到了客戶端，第一層是我們的JS-Framework，最后到RenderRengine，再往下看，左邊是我們的DSL文件，右邊是轉(zhuǎn)換出來的jsbundle，在DSL中的template會將我們的類型和子節(jié)點(diǎn)都表示出來，將classList轉(zhuǎn)化成基本語法約定，包括自變量的轉(zhuǎn)換。最后是腳本，腳本基本上是直譯過來。輸入是Virtual DOM輸出是native或者H5 view，還原成內(nèi)存中的樹型數(shù)據(jù)結(jié)構(gòu)，再創(chuàng)建view，把事件綁定在view上，把view基本屬性設(shè)上去。虛線是在native上經(jīng)歷一個過程，在H5上相當(dāng)于把這個事情交給webkit LayoutEngine去做，把所有元素尺寸和位置重新調(diào)整。整個這張圖基本上講清楚了Weex Render流程，我們會分三個線程，不同的線程負(fù)責(zé)不同的事情，讓JS線程優(yōu)先保障我們的流暢性，未來我們會有更多的技術(shù)文檔，比較細(xì)節(jié)的放出來。

Weex的性能、擴(kuò)展以及可用性

下面是在整個Weex架構(gòu)上比較關(guān)鍵的點(diǎn)，這些可能是我們目前關(guān)注度最高的，包括性能、擴(kuò)展以及可用性。

首先是性能，我們內(nèi)部有這樣一個壓測頁面，我們同學(xué)把benchmark放在Playground，大家如果下載是能夠看到的。在我們內(nèi)部做壓測的時候調(diào)到三千個節(jié)點(diǎn)，大概10屏，一屏有三個卡片，一個卡片有100個節(jié)點(diǎn)左右。我們看一下數(shù)據(jù)，第一個性能對比是我們的加載時間，同樣一個頁面1300、1600，也不算特別大，20%左右，幀率大概差開一幀，scroller差不多，內(nèi)存這塊會好一點(diǎn)，因?yàn)槲覀冞@邊用了recycle view，會好一些。再往下是CPU，靜默CPU消耗，還有運(yùn)行過程中CPU的峰值。靜默CPU接近0點(diǎn)幾，我們不做16毫秒的輪循，如果做16毫秒輪循CPU會更高一些。

這是一個真實(shí)業(yè)務(wù)數(shù)據(jù)，3月份頁面上線之后我們看了一下，這張頁面是一個活動，3月份新風(fēng)尚的活動，這個活動頁面沒有用List，沒有特別做內(nèi)存對比，這兩個設(shè)備定義為低端機(jī)，幀率差壓比較明顯，無論是數(shù)據(jù)還是實(shí)際中的體驗(yàn)，流暢性大概是這樣的差距。我們說性能往往都會提到幀率、加載時間，但往往會忽略一個事情，Native UI開發(fā)中通常沒有JS資源在服務(wù)端加載，Weex以及類似動態(tài)化方案有一個副作用，我們有一個JS必須從服務(wù)端下載，我們把JS內(nèi)置到客戶端里，免除下載的問題，這里涉及到一整套的策略。我們內(nèi)部有一套機(jī)制，之后會把這套機(jī)制作為獨(dú)立的技術(shù)產(chǎn)品開放出來。

下一個是我們的兼容性。兼容性不只是對Weex，對偏內(nèi)核型項(xiàng)目都會有這個問題，舉一個Weex例子，第一排是我們的業(yè)務(wù)代碼，再往下看，上面兩次變遷，一直到客戶端，整個場景會變成N的立方。舉一個具體數(shù)字，我的業(yè)務(wù)代碼改了三個版本，（英文）三個版本，最后會有三的立方27個場景。兼容性是我們一直重視的問題。我們做了幾件事情，首先單測保證，包括JS和H5的單測，保證最最基礎(chǔ)的UT本身帶來的含義。第二個是JS單測環(huán)境，我們一般會將（英文）跑在（英文環(huán)境下，但和JS安全還是有差異。再往下是自動化工作，這塊工作細(xì)分也可以分成兩塊：一塊是我們針對截圖比對，比如我們同學(xué)會說我們設(shè)置了很多各種各樣細(xì)節(jié)屬性，怎么說你渲染出來的就是你實(shí)際想要的，通過API級別的效果不是很好。所以這種我們會通過截圖，將最終產(chǎn)生的結(jié)果和我們意料中的結(jié)果進(jìn)行圖形比對，比較老的成熟的內(nèi)核上面做的比較成熟，也會有一些借鑒。另外是layout results，相當(dāng)一部分，包括model，包括其他的布局類的，其實(shí)我們完全可以通過一個元素，最終它的寬高，左上角的點(diǎn)，通過基本的信息，讓它完成測試的過程。所以我們經(jīng)過這兩塊工作，一旦成熟，我們會盡快放到上面。

再就是擴(kuò)展性，我們先回顧一下這張圖，前面也有提到，目前Weex給大家直觀的感覺是可以用Weex寫很多頁面，有一個路由機(jī)制，內(nèi)部叫導(dǎo)航，幫助你將頁面進(jìn)行串連，我們提供很多features，由這樣的形式構(gòu)成Weex大家所看到的一個結(jié)構(gòu)。細(xì)分來看，如果你擴(kuò)展一個component，特定的一些方法，使用anotation標(biāo)識輸入輸出參數(shù)。這是一個module，在DSL上看到的是API，底層就是module。如果擴(kuò)展module也是一樣的，這是很簡單的跳轉(zhuǎn)，基本信息帶上去，實(shí)現(xiàn)業(yè)務(wù)功能，一個module就完成了，很簡單。

這是路由，整個路由在APP Framework中只是一個環(huán)節(jié)，所以接下來的規(guī)劃還是有許多東西需要做的，單獨(dú)看components這塊，包括前面兩個，再往下是lifecycle考慮，再是動畫跟手勢，這塊我們覺得都是最基礎(chǔ)的東西。再往下是全局的多個Weex容器之間通信機(jī)制，數(shù)據(jù)存儲、網(wǎng)絡(luò)，包括下面涉及到的一堆傳感器，包括基礎(chǔ)的FS，還有偏業(yè)務(wù)類的東西，整個東西都有同步在做，但現(xiàn)在的工作集中是在這塊。回到剛才的老問題，如果我們開放一個module，上層提供API，中間提供adapter，如果提供自由實(shí)現(xiàn)就將默認(rèn)的覆蓋掉，比如手淘里面（TBxxx），把默認(rèn)頁面覆蓋掉（WXxxx），對大家來說在已有能力增強(qiáng)，或者是增加新的組件，或者是新的module上，目前已經(jīng)達(dá)到這個狀態(tài)。

最后是我們的可用性，前面說的比較多，這塊秀幾張圖就好了。這是我們的工具鏈，紅色代表完成的，×××是五月份、六月份就會完成，在六月正式開源之前。剩下一些東西是我們內(nèi)部正在討論以及會安排時間逐步完成的東西，這些都是工具。我們首先給大家提供一個playground，可以掃碼，也有自帶的examples。第二個是調(diào)試工具，chrome dev tools常見的功能里面都有。再是腳手架，大家如果只是玩玩的話用playground就可以了，如果自己做一個獨(dú)立的APP，你要用Weex做的話我們也會給你提供腳手架。我們的規(guī)劃中獨(dú)立項(xiàng)目，不是最終的名字，最終會有一個類似APPHub的工具。包括信息察看，在界面上展示結(jié)構(gòu)。這是剛才提到的例子，這個是playground里面的，雖然截圖是iphone效果和android是完全一樣的，已經(jīng)用Weex現(xiàn)有功能做出比較好玩的組件庫。然后是我們的文檔，包括項(xiàng)目guide、reference、toolchain，細(xì)節(jié)我不多說了，大家可以去看看。

Weex的集成方式

目前Weex有三種集成方式：

1. 全頁模式 
   o 目前支持單頁使用或整個app使用weex開發(fā)（還不完善，需要開發(fā)router和生命周期管理）這是主推的模式，可以類比RN。

   
   

2. Native Component模式 

   
   o 把weex當(dāng)作一個iOS/Android組件來使用，類比ImageView。這類需求遍布手淘主鏈路，如首頁、主搜結(jié)果、交易組件化等，和業(yè)務(wù)同學(xué)溝通下來這類Native頁面主體已經(jīng)很穩(wěn)定，但是局部動態(tài)化需求旺盛導(dǎo)致頻繁發(fā)版，解決這類問題也是Weex的重點(diǎn)。 

   
   o 這也涉及到如何讓Native同學(xué)快速上手“準(zhǔn)Web”開發(fā)，有意思的話題，大家多給些建議。

   
   

3. H5 Component模式 

   
   o 在H5種使用Weex，類比WVC。一些較復(fù)雜或特殊的H5頁面短期內(nèi)無法完全轉(zhuǎn)為Weex全頁模式（或RN），比如貓超、互動類頁面、一些復(fù)雜頻道頁等。針對這個痛點(diǎn)我發(fā)起過WVC項(xiàng)目，并在實(shí)際業(yè)務(wù)中驗(yàn)證了這樣的想法：在現(xiàn)有的H5頁面上做微調(diào)，引入Native解決長列表內(nèi)存暴增、滾動不流暢、動畫/手勢體驗(yàn)差等問題。 

   
   o WVC將會融入到Weex中，成為Weex的H5 Components模式。 
   這3種模式幾乎涵蓋了淘系業(yè)務(wù)上的動態(tài)化需求（針對Native）或體驗(yàn)提升需求（針對H5）。更有趣的是這3種模式的技術(shù)基礎(chǔ)是一致的，這非常重要，意味著：業(yè)務(wù)方可以使用Native或H5 Component模式 解決實(shí)際的業(yè)務(wù)痛點(diǎn)，同時平滑過渡到Weex全頁模式。期待Weex成長壯大到AppFramework的那天。

   
   

最后是我們過去雙十一到現(xiàn)在大概五個多月時間做的一些事情。首先我們做了原型版本，再將原型版本獨(dú)立出獨(dú)立客戶端可使用的SDK，擴(kuò)展樣式和布局，將基礎(chǔ)的component做了擴(kuò)展，這兩個月集中在工具，還有open source上的工作，最后是六月底就會開放出來。

阿里百川（baichuan.taobao.com）是阿里巴巴集團(tuán)無線開放平臺，通過“技術(shù)、商業(yè)及大數(shù)據(jù)”的開放，提供移動場景下的高內(nèi)聚、開放式、行業(yè)領(lǐng)先的技術(shù)產(chǎn)品矩陣、成熟的商業(yè)組件和完善的服務(wù)體系，幫助移動開發(fā)者快速搭建APP、加速APP商業(yè)化進(jìn)程，全方位賦能移動開發(fā)者及移動創(chuàng)業(yè)者。