深度揭秘阿里移動(dòng)端高性能動(dòng)態(tài)化方案Weex
作者：佚名
2016年Qcon大會(huì)首日，阿里巴巴資深總監(jiān)、淘寶移動(dòng)平臺(tái)、阿里百川負(fù)責(zé)人莊卓然宣布移動(dòng)端高性能動(dòng)態(tài)化方案Weex即時(shí)內(nèi)測(cè)，并將于6月開源。此消息一出，群情洶涌，在座的程序猿、攻城獅們紛紛拿起手機(jī)掃碼，以期第一時(shí)間感受Weex的神奇之力。
在第二天的主題分享會(huì)上，阿里巴巴前端開發(fā)專家趙錦江和技術(shù)專家徐凱對(duì)Weex進(jìn)行了深入的解析。以下為演講速記整理后的成文。
阿里怎么看待移動(dòng)開發(fā)？
目前的移動(dòng)開發(fā)者面臨的***痛點(diǎn)就是面對(duì)極其復(fù)雜的環(huán)境，對(duì)此，莊卓然給出一個(gè)公式，移動(dòng)開發(fā)的復(fù)雜度=應(yīng)用數(shù)量×平臺(tái)數(shù)量×要適配的各種各樣的機(jī)型。
如何解決這個(gè)問題呢？在解決問題之前，首先要對(duì)移動(dòng)開發(fā)的未來(lái)有著精準(zhǔn)的研判。
阿里認(rèn)為，移動(dòng)開發(fā)的未來(lái)必定更加平衡，也就是說(shuō)必須是性能與動(dòng)態(tài)兼得，如此，才能夠滿足未來(lái)用戶的需求。另外，移動(dòng)開發(fā)在未來(lái)也必定是開放互聯(lián)的狀態(tài)，移動(dòng)互聯(lián)網(wǎng)將來(lái)肯定是基于更加大眾化的技術(shù)體系，沒有平臺(tái)之間的隔閡，而且簡(jiǎn)單易用。
所以，阿里結(jié)合移動(dòng)開發(fā)的現(xiàn)狀并圍繞其愿景推出了Weex解決方案。
事實(shí)上，在去年的雙11活動(dòng)中，Weex就得到了實(shí)戰(zhàn)的驗(yàn)證，且表現(xiàn)不俗。時(shí)至今日，Weex已經(jīng)被阿里技術(shù)團(tuán)隊(duì)多次運(yùn)用，并“創(chuàng)造”出各種豐富的場(chǎng)景，整體的表現(xiàn)非常優(yōu)異。
把移動(dòng)端所有界面拆分成各個(gè)page，然后中間設(shè)置有路由的控制邏輯，同時(shí)，將移動(dòng)端各種各樣的能力通過(guò)各種API提供給開發(fā)者。這是阿里對(duì)移動(dòng)開發(fā)模型的理解。
Weex通過(guò)標(biāo)準(zhǔn)化的東西，包括HTML、CSS和JS這些前端非?？焖僖子煤脤W(xué)的語(yǔ)法作為開發(fā)體驗(yàn)，提供給開發(fā)者。另外，Weex的語(yǔ)法設(shè)計(jì)尊重還Web的標(biāo)準(zhǔn)。
Weex的工作原理
Weex設(shè)計(jì)之初就考慮到在三端（iOS、安卓和H5）上能夠得到展現(xiàn)。在最上面的DSL，阿里一般稱之為Weex文件（.we），通過(guò)Transformer轉(zhuǎn)換成js-bundle，再部署到服務(wù)器，這樣服務(wù)端就完成了。在客戶端，***層是JS-Framework，***到RenderRengine。
輸入是Virtual DOM輸出是native或者H5 view，還原成內(nèi)存中的樹型數(shù)據(jù)結(jié)構(gòu)，再創(chuàng)建view，把事件綁定在view上，把view基本屬性設(shè)上去。Weex Render會(huì)分三個(gè)線程，不同的線程負(fù)責(zé)不同的事情，讓JS線程優(yōu)先保障流暢性。
Weex的性能、擴(kuò)展性以及可用性究竟怎樣呢？
性能方面，阿里對(duì)Weex做了多次壓測(cè)。在加載時(shí)間、幀率、內(nèi)存消耗、CPU占用（包括靜默和峰值）等多個(gè)方面，Weex都表現(xiàn)得非常出色。
在談及性能之時(shí)，幀率和加載時(shí)間幾乎都會(huì)被提及，但是往往忽略了一個(gè)事實(shí)，那就是Native UI開發(fā)中通常沒有JS資源在服務(wù)器端加載。Weex會(huì)把JS內(nèi)置到客戶端里，以免除下載的問題，從而更為有效地提升性能。
兼容性是Weex非常重視的問題，對(duì)此，阿里是這樣來(lái)解決的。
首先是單測(cè)保證，包括JS和H5的單測(cè)，保證最基礎(chǔ)的UT（Unit Test）本身所帶來(lái)的含義。
其次是UI的自動(dòng)化，分為兩個(gè)部分，一是截圖對(duì)比，將最終產(chǎn)生的結(jié)果和意料中的結(jié)果進(jìn)行圖形對(duì)比；二是Layout Results，包括Model以及其他的布局類的，通過(guò)基本的信息完成測(cè)試的過(guò)程。
在擴(kuò)展性方面，Weex可以寫很多頁(yè)面，而且通過(guò)路由機(jī)制幫助開發(fā)者將頁(yè)面進(jìn)行串聯(lián)。
Weex已開放內(nèi)測(cè)，可用性方面正在逐步完善。包括Playground、調(diào)試工具、腳手架、AppHub、編輯器等多個(gè)方面，一些工作已經(jīng)完成就緒，絕大部分工作將在5、6月份完成。
***，是Weex的三種工作模式。
1. 全頁(yè)模式
目前支持單頁(yè)使用或整個(gè)App使用Weex開發(fā)（還不完善，需要開發(fā)Router和生命周期管理），這是主推的模式，可以類比RN。
2. Native Component模式
把Weex當(dāng)作一個(gè)iOS/Android組件來(lái)使用，類比ImageView。這類需求遍布手淘主鏈路，如首頁(yè)、主搜結(jié)果、交易組件化等，這類Native頁(yè)面主體已經(jīng)很穩(wěn)定，但是局部動(dòng)態(tài)化需求旺盛導(dǎo)致頻繁發(fā)版，解決這類問題也是Weex的重點(diǎn)。
3. H5 Component模式
在H5種使用Weex，類比WVC。一些較復(fù)雜或特殊的H5頁(yè)面短期內(nèi)無(wú)法完全轉(zhuǎn)為Weex全頁(yè)模式（或RN），比如互動(dòng)類頁(yè)面、一些復(fù)雜頻道頁(yè)等。這個(gè)痛點(diǎn)的解決辦法是：在現(xiàn)有的H5頁(yè)面上做微調(diào)，引入Native解決長(zhǎng)列表內(nèi)存暴增、滾動(dòng)不流暢、動(dòng)畫/手勢(shì)體驗(yàn)差等問題。
另外，WVC將會(huì)融入到Weex中，成為Weex的H5 Components模式。
責(zé)任編輯：xiejuan
來(lái)源：
51CTO
