Weex詳解：靈活的移動端高性能動態化方案

在2016年4月份的QCon上，阿里巴巴資深總監，淘寶移動平臺及新業務事業部、阿里百川負責人莊卓然（花名南天）宣佈阿里移動端跨平臺開發框架Weex開始內測，並將於6月份開源。在QCon的次日，阿里技術專家徐凱（花名鬼道）和阿里前端開發專家趙錦江（花名勾股）向參會者作了《Weex——靈活的移動端高性能動態化方案》的演講，對這一技術方案進行了詳細的剖析。

如下爲演講內容的整理：

昨天南天宣佈Weex啓動開源內測，截至到今天中午，咱們統計申請內測用戶突破1400人，你們的熱烈程度遠遠超過咱們的設想，很是感謝你們支持。

在咱們對移動開發最佳實踐的思考中，咱們認爲移動開發的將來是更平衡的方案，必定是性能和動態性兼得。第二個，它必定是開放互聯的，PC端一直也是這樣的，也是很是好的狀態。咱們以爲移動互聯網未來確定也是基於更大衆化的技術體系，沒有平臺之間的隔閡，簡單直接易用，這是咱們最但願看到的。基於這些設想，咱們有了Weex方案。

Weex是從去年雙十一的時候第一次在咱們正式產品中使用，承載了雙十一主會場的工做。有人會問，Weex是否是除了作主會場別的地方就比較吃力呢？從去年雙十一到如今，包括咱們本身的嘗試和阿里內網作開源內測活動，你們也貢獻了不少內容，包括昨天Keynote演示的殭屍動畫，掃雷、計算器都有，各類豐富場景的東西均可以經過Weex作出來，不只僅是作主會場的技術方案。

對移動端開發模型的理解

咱們談談Weex團隊對移動端開發模型的理解。

今天絕大多數移動端APP是這樣一個最佳實踐，首先把移動端全部界面拆分紅各個page，中間有一個路由的控制邏輯。同時咱們須要移動端各類各樣豐富的能力，經過API的形式提供給開發者。這是咱們認爲一個比較理想的開發模型。

從開發模型來說，咱們比較傾向於經過標準化的一些東西，包括HTML、CSS、JS這些前端很是快速易用好學的語法做爲一個開發體驗，提供給開發者。這裏強調一下，咱們語法設計尊重了Web標準，包括核心源代碼都是從Vue.js——一個很是優秀的MVVM前端框架來的。咱們的開源內測同步在海外經過Vue.js的Twitter等途徑進行宣傳，獲得了很是熱烈的反響，短短一天時間內，老外們的關注度和熱情也是出乎咱們的意料。有些人很是興奮和激動，想知道何時看到源代碼，和咱們聯繫，咱們以爲也是值得高興的一件事情。

Weex的組件化與DSL語法

Weex編寫的頁面自然的支持組件化，首先，咱們的界面能夠是一個組件化的，把一個複雜界面分紅每一個組件，剛纔演示的都是簡單的組件，每一個組件均可以當作是一段template，style，script，放到模型裏，對應到界面的結構，樣式細節，行爲定義。在view裏面咱們傾向於把數據和視圖當中須要展現和須要有動態變化的部分作一個數據綁定，綁定以後我若是想更改界面的話，經過改變數據就能夠作到。這是從model到view很是順暢的控制邏輯和代碼方式，這也算是Weex上層語法設計的基礎。若是你們作的界面比較複雜，可能有更多細節，或者作更多分解，咱們須要從總體上對整個界面以模塊爲單位做爲拆解，對每一個模塊作定義，若是界面足夠複雜，能夠先拆成組件，再把每一個組件具體內容進行定義。定義方式就是經過結構、樣式和行爲角度對它進行定義，經過有機方式把這些組件結合起來，完成頁面開發。

關鍵語法簡述。首先看看template，大概有幾個元素。它首先是virtual DOM tree展現，包括事件綁定，組件跟組件之間還能夠嵌套，還能夠有子元素，這是總體template結構。再往下是style，一方面能夠把共用樣式抽樣出來，另外一方面可讓template結構更加清晰，不至於陷入到整個具體樣式描述當中去。咱們在這邊會作一些收斂，咱們只支持了單個class的selector寫法，主要從性能角度考慮。傳統的css能夠理解爲是一個N對N的數據庫，匹配過程很是複雜，性能也得不到很是好的保證，咱們爲了保證性能，咱們把selector約定在單個class，性能能夠保證。

另外，咱們的樣式自然默認的就是scoped，你們能夠放心定義各類各樣的classname，不擔憂和其餘組件相沖突，全局衝突是CSS「七宗罪」中的一個，其實這也是咱們很是重視的，因此在實踐上咱們把它作到了scoped。

其餘的，能夠作一些展現的控制，好比if、repeat剛纔演示中也提到了。剛纔沒有演示到的這個很特殊，append，在性能不是那麼好的Android下，界面加載過程用戶是可感知的，不是一瞬間作到的。咱們加這個值可讓你精細化展現界面的顆粒度，若是上層作了append等於tree的話，裏面一系列東西會作一次性的加載，這是從性能優化角度作的特殊設計。再是id，咱們能夠經過在這裏面寫id拿到這個值，把它看成參數傳給API作處理。

咱們如今已經支持的組件，除了剛纔演示的div空白容器、圖片、文本以外，咱們還支持slider：一個性能比較好的滑塊組件，還有list，性能上自動作內存管理和資源管理的組件，把性能和幀率各方面都作的比較好。還有input，輸入框咱們是最近才作的，也是剛支持的，可能還有試驗性階段的小東西。在這個範圍以外，業務方可在上層橫向擴展，稍後會有具體介紹。這是template和style部分的介紹。

樣式部分咱們支持flexbox，很是靈活通用便捷的佈局方式，有了flexbox，只要你的界面能夠拆分紅豆腐塊的，均可以用flexbox來作，同時咱們還作了fixed和sticky這兩個特殊的佈局，sticky意思是若是有一個列表分類，好比聯繫人ABC字母滾到屏幕外，會停在最上面，那個效果就是sticky，當你划走它就會跟着走，在各類手機應用當中是一個比較常見的東西。一樣，更多的樣式每一個組件也能夠本身定製，很是靈活。

從事件角度，click是基礎事件，change在表單的值改變和滑快的第幾幀改變時都會有，同時咱們加入了appear和disappear，當我經過任意操做進入屏幕區域內，會觸發appear事件，出來之後會觸發disappear事件，很是適合用在一些lazyload之類的邏輯場景。這些事件也能夠在各自組件中作橫向擴展。

Script部分剛纔例子也提到了，主要是viewmodel設計，最主要的是data和methods，值修改以後相應數據綁定的值也會發生改變。除此以外咱們提供了生命週期的方法，建立的時候，數據監聽完成的時候，渲染完成的時候，你只要把這三個方法一樣寫在data和methods下面。還有原生 API，剛纔演示的時候也出現了，這裏很少介紹。

組件化搭建很複雜，經過定義子組件，好比我上面有一個foo組件，經過foo標籤就能夠把foo嵌入到別的組件中來，數據傳遞的話就能夠在foo組件中寫a和b，foo元素就能夠經過這種方式傳遞給子元素，而後進行處理。再是組件中間的通訊，也是事件機制，每一個組件能夠經過$on和$off，對自定義事件進行監聽和解綁定，想觸發事件也有三個方法：只傳給本身、dispatch向上冒泡給全部父組件、$broadcast廣播給全部子組件，這些設計和Vue很是相近的，作到組件之間的通訊。

除了剛纔介紹的這些特性，咱們將來還會提供更豐富的、相信也是開發者須要的、平時開發中會碰到的場景，更豐富的表單，還有更好的動畫展現，包括複雜手勢場景。在這方面，不管是性能仍是開發體驗、最終效果都可以很是好，這是團隊正在努力在將來提供給你們的。同時咱們但願收集和分享更多相關素材，作出更多工具，提供更好的開發者體驗給你們。

更多的內容，包括剛纔演示的Playground App均可以經過咱們的官網找到，如今處在開源內測階段，你們提交申請，經過之後能夠訪問倉庫，瞭解更具體的內容。

Weex的工做原理

這張圖你們都不陌生，前面也提到了，勾股說的主要是DSL這層。再往下到了Virtual DOM和Render層；H5，我刻意把它用不同的顏色標出來，想讓你們知道咱們設計之初就考慮到但願在三端上可以展示，因此這個地方稍微加亮一些。

咱們把剛纔這張圖再稍微展開一下，最上面是咱們的DSL，咱們通常叫Weex文件，經過transformer這層，部署到Server，服務端就完成了。你們不用擔憂咱們的轉換是否是有性能問題，由於這在服務端就已經完成。到了客戶端，第一層是咱們的JS-Framework，最後到RenderRengine，再往下看，左邊是咱們的DSL文件，右邊是轉換出來的jsbundle，在DSL中的template會將咱們的類型和子節點都表示出來，將classList轉化成基本語法約定，包括自變量的轉換。最後是腳本，腳本基本上是直譯過來。輸入是Virtual DOM輸出是native或者H5 view，還原成內存中的樹型數據結構，再建立view，把事件綁定在view上，把view基本屬性設上去。虛線是在native上經歷一個過程，在H5上至關於把這個事情交給webkit LayoutEngine去作，把全部元素尺寸和位置從新調整。整個這張圖基本上講清楚了Weex Render流程，咱們會分三個線程，不一樣的線程負責不一樣的事情，讓JS線程優先保障咱們的流暢性，將來咱們會有更多的技術文檔，比較細節的放出來。

Weex的性能、擴展以及可用性

下面是在整個Weex架構上比較關鍵的點，這些多是咱們目前關注度最高的，包括性能、擴展以及可用性。

首先是性能，咱們內部有這樣一個壓測頁面，咱們同窗把benchmark放在Playground，你們若是下載是可以看到的。在咱們內部作壓測的時候調到三千個節點，大概10屏，一屏有三個卡片，一個卡片有100個節點左右。咱們看一下數據，第一個性能對比是咱們的加載時間，一樣一個頁面1300、1600，也不算特別大，20%左右，幀率大概差開一幀，scroller差很少，內存這塊會好一點，由於咱們這邊用了recycle view，會好一些。再往下是CPU，靜默CPU消耗，還有運行過程當中CPU的峯值。靜默CPU接近0點幾，咱們不作16毫秒的輪循，若是作16毫秒輪循CPU會更高一些。

這是一個真實業務數據，3月份頁面上線以後咱們看了一下，這張頁面是一個活動，3月份新風尚的活動，這個活動頁面沒有用List，沒有特別作內存對比，這兩個設備定義爲低端機，幀率差壓比較明顯，不管是數據仍是實際中的體驗，流暢性大概是這樣的差距。咱們說性能每每都會提到幀率、加載時間，但每每會忽略一個事情，Native UI開發中一般沒有JS資源在服務端加載，Weex以及相似動態化方案有一個反作用，咱們有一個JS必須從服務端下載，咱們把JS內置到客戶端裏，免除下載的問題，這裏涉及到一整套的策略。咱們內部有一套機制，以後會把這套機制做爲獨立的技術產品開放出來。

下一個是咱們的兼容性。兼容性不僅是對Weex，對偏內核型項目都會有這個問題，舉一個Weex例子，第一排是咱們的業務代碼，再往下看，上面兩次變遷，一直到客戶端，整個場景會變成N的立方。舉一個具體數字，個人業務代碼改了三個版本，（英文）三個版本，最後會有三的立方27個場景。兼容性是咱們一直重視的問題。咱們作了幾件事情，首先單測保證，包括JS和H5的單測，保證最最基礎的UT自己帶來的含義。第二個是JS單測環境，咱們通常會將（英文）跑在（英文環境下，但和JS安全仍是有差別。再往下是自動化工做，這塊工做細分也能夠分紅兩塊：一塊是咱們針對截圖比對，好比咱們同窗會說咱們設置了不少各類各樣細節屬性，怎麼說你渲染出來的就是你實際想要的，經過API級別的效果不是很好。因此這種咱們會經過截圖，將最終產生的結果和咱們意料中的結果進行圖形比對，比較老的成熟的內核上面作的比較成熟，也會有一些借鑑。另外是layout results，至關一部分，包括model，包括其餘的佈局類的，其實咱們徹底能夠經過一個元素，最終它的寬高，左上角的點，經過基本的信息，讓它完成測試的過程。因此咱們通過這兩塊工做，一旦成熟，咱們會盡快放到上面。

再就是擴展性，咱們先回顧一下這張圖，前面也有提到，目前Weex給你們直觀的感受是能夠用Weex寫不少頁面，有一個路由機制，內部叫導航，幫助你將頁面進行串連，咱們提供不少features，由這樣的形式構成Weex你們所看到的一個結構。細分來看，若是你擴展一個component，特定的一些方法，使用anotation標識輸入輸出參數。這是一個module，在DSL上看到的是API，底層就是module。若是擴展module也是同樣的，這是很簡單的跳轉，基本信息帶上去，實現業務功能，一個module就完成了，很簡單。

這是路由，整個路由在APP Framework中只是一個環節，因此接下來的規劃仍是有許多東西須要作的，單獨看components這塊，包括前面兩個，再往下是lifecycle考慮，再是動畫跟手勢，這塊咱們以爲都是最基礎的東西。再往下是全局的多個Weex容器之間通訊機制，數據存儲、網絡，包括下面涉及到的一堆傳感器，包括基礎的FS，還有偏業務類的東西，整個東西都有同步在作，但如今的工做集中是在這塊。回到剛纔的老問題，若是咱們開放一個module，上層提供API，中間提供adapter，若是提供自由實現就將默認的覆蓋掉，好比手淘裏面（TBxxx），把默認頁面覆蓋掉（WXxxx），對你們來講在已有能力加強，或者是增長新的組件，或者是新的module上，目前已經達到這個狀態。

最後是咱們的可用性，前面說的比較多，這塊秀幾張圖就行了。這是咱們的工具鏈，紅色表明完成的，黃色是五月份、六月份就會完成，在六月正式開源以前。剩下一些東西是咱們內部正在討論以及會安排時間逐步完成的東西，這些都是工具。咱們首先給你們提供一個playground，能夠掃碼，也有自帶的examples。第二個是調試工具，chrome dev tools常見的功能裏面都有。再是腳手架，你們若是隻是玩玩的話用playground就能夠了，若是本身作一個獨立的APP，你要用Weex作的話咱們也會給你提供腳手架。咱們的規劃中獨立項目，不是最終的名字，最終會有一個相似APPHub的工具。包括信息察看，在界面上展現結構。這是剛纔提到的例子，這個是playground裏面的，雖然截圖是iphone效果和android是徹底同樣的，已經用Weex現有功能作出比較好玩的組件庫。而後是咱們的文檔，包括項目guide、reference、toolchain，細節我很少說了，你們能夠去看看。

Weex的集成方式

目前Weex有三種集成方式：

全頁模式

o 目前支持單頁使用或整個app使用weex開發（還不完善，須要開發router和生命週期管理）這是主推的模式，能夠類比RN。

Native Component模式

o 把weex看成一個iOS/Android組件來使用，類比ImageView。這類需求遍及手淘主鏈路，如首頁、主搜結果、交易組件化等，和業務同窗溝通下來這類Native頁面主體已經很穩定，可是局部動態化需求旺盛致使頻繁發版，解決這類問題也是Weex的重點。

o 這也涉及到如何讓Native同窗快速上手「準Web」開發，有意思的話題，你們多給些建議。

H5 Component模式

o 在H5種使用Weex，類比WVC。一些較複雜或特殊的H5頁面短時間內沒法徹底轉爲Weex全頁模式（或RN），好比貓超、互動類頁面、一些複雜頻道頁等。針對這個痛點我發起過WVC項目，並在實際業務中驗證了這樣的想法：在現有的H5頁面上作微調，引入Native解決長列表內存暴增、滾動不流暢、動畫/手勢體驗差等問題。

o WVC將會融入到Weex中，成爲Weex的H5 Components模式。
這3種模式幾乎涵蓋了淘系業務上的動態化需求（針對Native）或體驗提高需求（針對H5）。更有趣的是這3種模式的技術基礎是一致的，這很是重要，意味着：業務方可使用Native或H5 Component模式 解決實際的業務痛點，同時平滑過渡到Weex全頁模式。期待Weex成長壯大到AppFramework的那天。

最後是咱們過去雙十一到如今大概五個多月時間作的一些事情。首先咱們作了原型版本，再將原型版本獨立出獨立客戶端可以使用的SDK，擴展樣式和佈局，將基礎的component作了擴展，這兩個月集中在工具，還有open source上的工做，最後是六月底就會開放出來。

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