引子
這篇文章是筆者近期關(guān)于Weex在iOS端的一些研究和實(shí)踐心得悯蝉，和大家一起分享分享泉粉，也算是對(duì)學(xué)習(xí)成果的總結(jié)嗡靡。文章里面提到的做法也許不是最佳實(shí)踐，也許里面的方法稱不算是一份標(biāo)準(zhǔn)的指南手冊(cè)歉井，所以標(biāo)題就只好叫“偽最佳實(shí)踐指北”了哩至。有更好的方法歡迎大家一起留言討論蜜自，一起學(xué)習(xí)重荠。
由于筆者不太了解Android戈鲁，所以以下的文章不會(huì)涉及到Android。
一. React Native 和 Weex
自從Weex出生的那一天起诈乒，就無(wú)法擺脫和React Native相互比較的命運(yùn)怕磨。React Native宣稱“Learn once, write anywhere”癌压，而Weex宣稱“Write Once, Run Everywhere”荆陆。Weex從出生那天起被啼，就被給予了一統(tǒng)三端的厚望浓体。React Native可以支持iOS、Android娄猫，而Weex可以支持iOS媳溺、Android碍讯、HTML5捉兴。
在Native端倍啥，兩者的最大的區(qū)別可能就是在對(duì)JSBundle是否分包。React Native官方只允許將React Native基礎(chǔ)JS庫(kù)和業(yè)務(wù)JS一起打成一個(gè)JS bundle始藕，沒(méi)有提供分包的功能鳄虱，所以如果想節(jié)約流量就必須制作分包打包工具凭峡。而Weex默認(rèn)打的JS bundle只包含業(yè)務(wù)JS代碼摧冀，體積小很多索昂，基礎(chǔ)JS庫(kù)包含在Weex SDK中椒惨，這一點(diǎn)Weex與Facebook的React Native和微軟的Cordova相比，Weex更加輕量领斥，體積小巧月洛。
在JS端，Weex又被人稱為Vue Native细层，所以 React Native 和 Weex 的區(qū)別就在 React 和 Vue 兩者上了疫赎。
筆者沒(méi)有寫(xiě)過(guò)React Native虚缎，所以也沒(méi)法客觀的去比較兩者实牡。不過(guò)知乎上有一個(gè)關(guān)于Weex 和 React Native很好的對(duì)比文章《weex&React Native對(duì)比》轴合，推薦大家閱讀受葛。
前兩天@Allen 許帥也在Glow 技術(shù)團(tuán)隊(duì)博客上面發(fā)布了一篇《React Native 在 Glow 的實(shí)踐》這篇文章里面也談了很多關(guān)于React Native實(shí)踐相關(guān)的點(diǎn)总滩，也強(qiáng)烈推薦大家去閱讀闰渔。
二. 入門(mén)基礎(chǔ)
關(guān)于小白想入門(mén)Weex冈涧，當(dāng)然最基礎(chǔ)的還是要通讀文檔，文檔是官方最好的學(xué)習(xí)資料营曼。官方的基礎(chǔ)文檔有兩份：
在文檔手冊(cè)里面包含了Weex所有目前有的組件蒂阱，模塊蒜危，每個(gè)組件和模塊的用法和屬性。遇到問(wèn)題可以先過(guò)來(lái)翻翻。很有可能有些組件和模塊沒(méi)有那些屬性响委。
1. Weex全家桶和腳手架
看完官方文檔以后赘风，就可以開(kāi)始上手構(gòu)建工程項(xiàng)目了纵刘。
我司在知乎上面寫(xiě)了4篇關(guān)于《Weex入坑指南的》假哎。這四篇文章還是很值得看的舵抹。
Weex也和前端項(xiàng)目一樣惧蛹，擁有它自己的腳手架全家桶。weex-toolkit + weexpack + playground + code snippets + weex-devtool迅腔。
weex-toolkit是用來(lái)初始化項(xiàng)目沧烈，編譯掺出，運(yùn)行汤锨，debug所有工具百框。
weexpack是用來(lái)打包JSBundle的柬泽，實(shí)際也是對(duì)Webpack的封裝。
playground是一個(gè)上架的App露该，這個(gè)可以用來(lái)通過(guò)掃碼實(shí)時(shí)在手機(jī)上顯示出實(shí)際的頁(yè)面解幼。
code snippets這個(gè)是一個(gè)在線的playground撵摆。
我相信大家應(yīng)該都有Native的App特铝，如果真的App都沒(méi)有鲫剿，那就用weexpack命令初始化一個(gè)新的項(xiàng)目牵素。如果已經(jīng)有App項(xiàng)目了澄者，那么weex命令就只是用來(lái)運(yùn)行和調(diào)試的。
已經(jīng)有iOS項(xiàng)目的粱挡，可以通過(guò)cocospod直接安裝Weex的SDK赠幕，初始化SDK以后，Native就可以使用Weex了询筏。加載的JS的地址改成自己公司服務(wù)器的IP榕堰。
#define CURRENT_IP @"your computer device ip"
// ...
// 修改端口號(hào)到你的端口號(hào)
#define DEMO_URL(path) [NSString stringWithFormat:@"http://%@:8080/%s", DEMO_HOST, #path]
// 修改 JS 文件路徑
#define HOME_URL [NSString stringWithFormat:@"http://%@:8080/app.weex.js", DEMO_HOST]
這樣整個(gè)項(xiàng)目就可以跑起來(lái)了。
這里還有一點(diǎn)需要說(shuō)明的是嫌套，項(xiàng)目雖然跑起來(lái)了，但是每次運(yùn)行都需要啟動(dòng)npm踱讨，打開(kāi)Weex的前端環(huán)境魏蔗。這里有兩個(gè)做法。
第一種做法是直接Hook Xcode的run命令痹筛，在Xcode配置里面加入啟動(dòng)npm的腳本莺治。比如下面這樣：
第二種做法就是每次運(yùn)行之前廓鞠，自己手動(dòng)npm run dev。我個(gè)人還是喜歡這種方式谣旁，因?yàn)樵赬code運(yùn)行完成之前床佳，一定可以在命令行上面打完這些命令。
再說(shuō)說(shuō)如何Debug榄审，這塊使用的是weex-devtool砌们。
這個(gè)工具和前端在Chrome里面調(diào)試的體驗(yàn)基本相同。
具體使用方法看這兩篇文章即可瘟判，這里不再贅述：
《Weex 入坑指南：Debug 調(diào)試是一門(mén)手藝活》
《Weex調(diào)試神器——Weex Devtools使用手冊(cè)》
2. Weex Market插件
在日常開(kāi)發(fā)中怨绣，我們可以全部自己開(kāi)發(fā)完所有的Weex界面，當(dāng)然還可以用一些已有的優(yōu)秀的輪子拷获。Weex的所有優(yōu)秀的輪子都在Weex Market里面。
在這個(gè)Market里面有很多已經(jīng)寫(xiě)好的輪子减细，直接拿來(lái)用匆瓜，可以節(jié)約很多時(shí)間。
比如這里很火的weex-chart未蝌。weex-chart圖表插件是通過(guò)g2-mobile依賴gcanvas插件實(shí)現(xiàn)的
如果你想使用Weex Market的Plugin插件驮吱，你可以使用weex plugin 命令：
$ weex plugin add plugin_name
你只需要輸入插件的名稱就可以從遠(yuǎn)程添加插件到你本地的項(xiàng)目，比如添加 weex-chart萧吠，我們可以輸入命令：
$ weex plugin add weex-chart
我們可以使用plugin remove移除插件左冬，比如移除安裝好的 weex-cahrt：
$ weex plugin remove weex-chart
這個(gè)插件庫(kù)里面我用過(guò)weex-router，還不錯(cuò)纸型，用它來(lái)做weex的路由管理拇砰。推薦使用。
3. iOS打包和發(fā)布
weex官方提供了weexpack命令狰腌。我覺(jué)得這個(gè)命令是提供給不懂iOS的前端的人用的除破。如果是Native來(lái)打包，依舊使用的Xcode的Archive打包琼腔。
完全不懂iOS的前端開(kāi)發(fā)者可以使用weexpack build ios 打包瑰枫，中間會(huì)要求輸入證書(shū)，開(kāi)發(fā)者賬號(hào)等信息丹莲。都輸入正確以后就可以打出ipa文件了光坝。全程傻瓜操作。如果不清楚的可以查看官方手冊(cè)：
weexpack 官方手冊(cè) 《 如何用weexpack創(chuàng)建weex項(xiàng)目并構(gòu)建app 》
如果是iOS開(kāi)發(fā)者甥材，原來(lái)怎么打包現(xiàn)在還是怎么打包盯另。只不多JS這塊要單獨(dú)進(jìn)行打包。建議是把Weex這塊單獨(dú)用一個(gè)git分支進(jìn)行管理擂达，專門(mén)針對(duì)這個(gè)分支進(jìn)行weexpack或者Webpack進(jìn)行打包土铺。webpack的具體配置由每個(gè)公司自己配置胶滋。
這里額外說(shuō)一點(diǎn)，這一點(diǎn)也是前端大神告訴我的悲敷。webpack打完包以后是可以通過(guò)webpack官方網(wǎng)站查看這個(gè)包里面究竟打入了哪些文件和依賴究恤。雖然我打包都是一股腦的都打完，但是資深前端開(kāi)發(fā)也許還會(huì)再去檢查一下是否有多的文件被打進(jìn)去了后德。極限壓縮包的體積部宿，1KB的文件也不多放進(jìn)去。
再談?wù)劙l(fā)布的問(wèn)題瓢湃。由于有了Weex以后理张，每次發(fā)布都會(huì)把上個(gè)版本累計(jì)到這個(gè)版本的hotPatch都累計(jì)修復(fù)掉，并在新版里面直接內(nèi)置最新的JSBundle文件绵患。內(nèi)置JS的目的也是為了首屏加載秒開(kāi)雾叭。
4. 熱更新
關(guān)于熱更新的作用大家都明白，不然用Weex的意義就少了好多落蝙。不過(guò)這里還有一點(diǎn)需要說(shuō)明的是——熱更新的策略织狐。
在日常開(kāi)發(fā)過(guò)程中，我們?cè)跒g覽器上面連著手機(jī)調(diào)試筏勒，也并不是實(shí)時(shí)刷新的移迫。(不過(guò)通過(guò)在手機(jī)上掃描二維碼，并且手機(jī)和電腦在同一個(gè)局域網(wǎng)之內(nèi)管行，可以做到實(shí)時(shí)更新)
所以在實(shí)際生產(chǎn)環(huán)境中厨埋，熱更新的策略應(yīng)該是這樣：有新的HotPatch就下發(fā)到客戶端，然后客戶端在下次啟動(dòng)的時(shí)候捐顷，先比對(duì)版本信息荡陷，如果是新版本，就去加載這個(gè)最新的HotPatch套菜，然后渲染在屏幕上亲善。
曾經(jīng)我幻想著能實(shí)時(shí)在線更新，就是線上一發(fā)布逗柴，所有用戶在聯(lián)網(wǎng)的情況下蛹头，下發(fā)HotPatch完畢以后直接加載，聯(lián)網(wǎng)的用戶可以實(shí)現(xiàn)秒級(jí)別的熱更新戏溺。這種雖然可以做到渣蜗，但是意義不大。做法是專門(mén)維護(hù)一套Websocket旷祸，直連服務(wù)器耕拷，下發(fā)完畢以后可以通過(guò)調(diào)用Native的通知，Native客戶端自己刷新頁(yè)面即可托享。（目前應(yīng)該沒(méi)有多少公司是這樣做的吧骚烧？）
5. JSBundle版本管理與部署
關(guān)于JSBundle的版本管理這塊是應(yīng)該交給前端來(lái)管理浸赫。前端可能會(huì)用版本號(hào)來(lái)管理各個(gè)包的版本。部署也會(huì)牽扯到每個(gè)公司前端部署的流程赃绊。他們會(huì)更加了解既峡。部署一般也會(huì)放到CDN上加速。
6. 踩坑和避坑
如果說(shuō)Weex一點(diǎn)坑都沒(méi)有碧查，那是不可能的运敢。
比如說(shuō)在某些界面連續(xù)Push的時(shí)候，頁(yè)面邊緣會(huì)有一些線條從屏幕上掃過(guò)忠售。還有捕捉JS錯(cuò)誤或者異常的時(shí)候传惠，Weex并不能可靠的捕捉到異常，這點(diǎn)需要靠Native來(lái)做稻扬，Native捕捉到異常以后再傳遞事件給JS Runtime去處理卦方。
計(jì)算頁(yè)面寬高尺寸這點(diǎn)是最需要注意的。Weex進(jìn)行界面適配的時(shí)候是用750為標(biāo)準(zhǔn)的泰佳，所以需要根據(jù)750去換算愿汰。還有一點(diǎn)是Weex里面有四舍五入的操作，是會(huì)丟失一點(diǎn)精度的乐纸。具體這塊請(qǐng)看《Weex 事件傳遞的那些事兒》這篇文章里面的源碼分析。
Weex JS 引擎也不支持 HTML DOM APIs 和 HTML5 JS APIs摇予，這包括 document, setTimeout 等汽绢。
Weex關(guān)于Web標(biāo)準(zhǔn)的實(shí)現(xiàn)現(xiàn)在還沒(méi)有達(dá)到100%，所以用Vue來(lái)寫(xiě)Weex的話侧戴，有些是不支持的宁昭。
比如說(shuō)一些CSS樣式，最令人想不到的就是不支持
酗宋，還不支持<form>积仗，<table>，<tr>蜕猫，<td>寂曹，不支持CSS percentage 單位，不支持類似 em回右，rem隆圆，pt 這樣的 CSS 標(biāo)準(zhǔn)中的其他長(zhǎng)度單位。不支持 hsl(), hsla(), currentColor, 8個(gè)字符的十六進(jìn)制顏色翔烁。
Weex對(duì)W3C上的FlexBox的規(guī)范也沒(méi)有支持完全渺氧，暫不支持inline，也不支持Z軸上面的變化蹬屹，不過(guò)移動(dòng)端在Z軸上的需求真的沒(méi)有侣背。Weex的Layout是用的Yoga之前的某個(gè)版本白华，解決問(wèn)題的方式也比較直接，后期升級(jí)到最新版的Yoga贩耐，便可以支持更多的Flex的標(biāo)準(zhǔn)了弧腥。
具體還有不支持的就要多翻翻文檔，比如這里的《Weex 目前不支持的Web 標(biāo)準(zhǔn)有哪些》憔杨。這些最好先看看鸟赫，心里有個(gè)數(shù)，以免開(kāi)發(fā)時(shí)候遇到一些莫名的bug消别，殊不知最終是因?yàn)椴恢С謱?dǎo)致的抛蚤。
然后還有一些是組件暫時(shí)還不支持同步方法。這里是Vue 2.0還不支持寻狂，官方預(yù)計(jì)是在 0.12 版本支持岁经。
額外提醒一點(diǎn)，由于蘋(píng)果前段時(shí)間對(duì)JSPatch的封殺蛇券，所以導(dǎo)致Weex官方對(duì)自定義模塊給出了一個(gè)警告：
Weex 所有暴露給 JS 的內(nèi)置 module 或 component API 都是安全和可控的缀壤， 它們不會(huì)去訪問(wèn)系統(tǒng)的私有 API ，也不會(huì)去做任何 runtime 上的 hack 更不會(huì)去改變應(yīng)用原有的功能定位纠亚。
如果需要擴(kuò)展自定義的 module 或者 component 塘慕，一定注意不要將 OC 的 runtime 暴露給 JS ， 不要將一些諸如 dlopen()蒂胞， dlsym()图呢， respondsToSelector:，performSelector:骗随，method_exchangeImplementations() 的動(dòng)態(tài)和不可控的方法暴露給JS蛤织， 也不要將系統(tǒng)的私有API暴露給JS
上述警告特別強(qiáng)調(diào)了不要用dlopen()， dlsym()鸿染， respondsToSelector:指蚜，performSelector:，method_exchangeImplementations()這幾個(gè)函數(shù)涨椒。這也是為什么同樣是用Weex有些人沒(méi)有通過(guò)審核摊鸡，有些人卻能通過(guò)審核的原因。
聽(tīng)說(shuō)安卓上有Refresh Control的一些bug丢烘，安卓在Weex上的表現(xiàn)我沒(méi)有怎么了解過(guò)柱宦，不過(guò)這塊如果出現(xiàn)在iOS上，我覺(jué)得可以直接用Native來(lái)替換掉這塊播瞳，有bug的地方都用原生來(lái)做掸刊。
總之Weex還是多多少少有一些問(wèn)題，但是目前使用來(lái)看赢乓，不影響使用忧侧，只要懂得靈活變通石窑，遇到實(shí)在過(guò)不去的坎，或者是真的一時(shí)hold不住的bug蚓炬，那么多考慮用原生來(lái)替代松逊。
三. 更多高級(jí)的玩法
接下來(lái)說(shuō)一下稍微高級(jí)的玩法。以下這些即使沒(méi)有做肯夏，也不影響Weex正常上線经宏。
1.頁(yè)面降級(jí)
Weex默認(rèn)是支持頁(yè)面降級(jí)的。比如出現(xiàn)了錯(cuò)誤驯击，就會(huì)降級(jí)到H5烁兰。這里建議最好做一個(gè)線上的開(kāi)關(guān)。我司在處理頁(yè)面降級(jí)的問(wèn)題上采取了兩種級(jí)別的開(kāi)關(guān)：
- App級(jí)的開(kāi)關(guān)徊都。這個(gè)開(kāi)關(guān)是管理用戶App是否使用Weex SDK的沪斟，這塊是可以在線配置的。
- 頁(yè)面級(jí)的開(kāi)關(guān)暇矫。這個(gè)開(kāi)關(guān)是管理某個(gè)頁(yè)面是否開(kāi)啟Weex的主之。如果不開(kāi)啟就降級(jí)成H5頁(yè)面。
除了降級(jí)以后李根，還對(duì)應(yīng)采取了灰度的策略槽奕，這樣保證線上bug降低到最低。
比如在用戶量低峰期的時(shí)候開(kāi)啟開(kāi)關(guān)進(jìn)行灰度房轿。還有一級(jí)灰度就通過(guò)線上實(shí)時(shí)錯(cuò)誤監(jiān)控平臺(tái)來(lái)控制史翘，如果因?yàn)橥话l(fā)事件導(dǎo)致Crash率陡升，那么就立即關(guān)閉Weex的開(kāi)關(guān)冀续，立即進(jìn)行降級(jí)處理。
2. 性能監(jiān)控和埋點(diǎn)
在Weex給的官方Demo里面有一個(gè)M的小圓點(diǎn)浮框必峰，點(diǎn)開(kāi)會(huì)看到如下的界面：
在這里我們點(diǎn)開(kāi)性能的按鈕：
在這里我們可以看到監(jiān)控了CPU洪唐，幀率，內(nèi)存吼蚁，電量凭需，流量等數(shù)據(jù)，這些數(shù)據(jù)也是我們?cè)贜ative APM中監(jiān)控的常見(jiàn)數(shù)據(jù)肝匆。當(dāng)然粒蜈，這個(gè)M圓點(diǎn)并不沒(méi)有開(kāi)源。所以這塊需要各個(gè)公司自己做一套自己的監(jiān)控系統(tǒng)旗国。這塊可能每個(gè)公司的前端已經(jīng)做好了枯怖，所以Weex需要接入到前端的性能監(jiān)控里。
如果我們?cè)冱c(diǎn)開(kāi)工具的界面能曾，就會(huì)看到如下的選項(xiàng)：
這里就有埋點(diǎn)監(jiān)控度硝。在初期可能Weex埋點(diǎn)還是由Native進(jìn)行埋點(diǎn)肿轨，因?yàn)楦骷叶加凶约业腘ative完整的埋點(diǎn)系統(tǒng)了。后期埋點(diǎn)這塊也可以交給前端在前端埋點(diǎn)蕊程。
3. 增量更新和全量更新
暫時(shí)筆者還沒(méi)有實(shí)踐過(guò)Weex的增量更新椒袍，所以這里就不提增量更新了。全量更新就比較簡(jiǎn)單藻茂，下發(fā)整個(gè)JSBundle驹暑，App在下次啟動(dòng)的時(shí)候再加載即可。Weex的包比RN的包小很多辨赐，一般就100-200K左右优俘。阿里的一次Weex分享里面提到他們gzip壓縮以后能達(dá)到60-80K。
4. 首屏加載時(shí)間極致優(yōu)化
上圖是阿里在Weex Conf大會(huì)上提出的一個(gè)挑戰(zhàn)肖油，網(wǎng)絡(luò)請(qǐng)求加上首屏渲染的時(shí)間加起來(lái)小于1秒兼吓。
這里面涉及到3方面的因素，網(wǎng)絡(luò)下載耗時(shí)森枪，JS和Native通信耗時(shí)视搏，還有渲染耗時(shí)。
網(wǎng)絡(luò)下載耗時(shí)可以通過(guò)支持HTTP / 2县袱，配置Spdy協(xié)議浑娜，域名收斂，支持http-cache式散，極致壓縮JSBundle的大小筋遭，JSBundle預(yù)加載。
JSBundle預(yù)加載的時(shí)候可以在App啟動(dòng)時(shí)候預(yù)先下載JS暴拄。遠(yuǎn)程服務(wù)器推包的時(shí)候通過(guò)長(zhǎng)連通道Push漓滔，這里可以是全量 / 增量，被動(dòng) / 強(qiáng)制更新相互結(jié)合乖篷。
阿里關(guān)于JS和Native通信耗時(shí)响驴，渲染耗時(shí)的相關(guān)優(yōu)化見(jiàn)上圖。這兩方面筆者也沒(méi)有相關(guān)的實(shí)踐撕蔼。
5. Vue全家桶
雖然Weex有屬于它自己的全家桶豁鲤，但是在支持了Vue 2.0以后，它的全家桶完全可以換成Vue的全家桶鲸沮。Vue琳骡，Vue-Router，Vuex讼溺，原來(lái)還有Vue-resource楣号，不過(guò)尤大后來(lái)去掉了這個(gè)Vue-resource，更加推薦axios了。所以全家桶里面就是Vue竖席，Vue-Router耘纱，Vuex，axios毕荐。
如果全部都換成了Vue以后束析，那么前端首屏渲染的速度就需要Vue來(lái)解決了。為了提高首屏渲染速度憎亚，wns緩存+直出 是必不可少的员寇。在Vue 1. x 時(shí)代，沒(méi)有 server-side-render 方案第美，直出需要專門(mén)給寫(xiě)一份首屏非Vue語(yǔ)法的模板蝶锋。Vue2.0 server-side-render（簡(jiǎn)稱Vue SSR）的推出，成功地讓前后端渲染模板代碼同構(gòu)什往。
如果只用了Vue-Router以后扳缕，當(dāng)打包構(gòu)建應(yīng)用時(shí)，JSBundle 包會(huì)變得非常大别威，影響頁(yè)面加載躯舔。如果我們能把不同路由對(duì)應(yīng)的組件分割成不同的代碼塊，然后當(dāng)路由被訪問(wèn)的時(shí)候才加載對(duì)應(yīng)組件省古，這樣就更加高效了粥庄。
結(jié)合 Vue 的 異步組件 和 Webpack 的 code splitting feature, 輕松實(shí)現(xiàn)路由組件的懶加載。減少JSBundle的體積豺妓。
還有一點(diǎn)需要注意的是惜互，Vue-Router 提供了三種運(yùn)行模式：
hash : 使用 URL hash 值來(lái)作路由。默認(rèn)模式琳拭。
history : 依賴 HTML5 History API 和服務(wù)器配置训堆。
abstract: 支持所有 JavaScript 運(yùn)行環(huán)境，如 Node.js 服務(wù)器端白嘁。
不過(guò)Weex 環(huán)境中只支持使用 abstract 模式蔫慧！
就在7天前，Vue 發(fā)布了v2.3.0版本权薯，官方支持了SSR。所以在支持了SSR以后睡扬，可以大幅提升SEO盟蚣，也可以做到首屏秒開(kāi)。所以為了性能卖怜，SSR必做屎开！
四. 頂級(jí)玩法
最后的最后，還有一些“前瞻性”的玩法马靠。
1. 強(qiáng)大的JSService
JS service 和 Weex 實(shí)例在 JS runtime 中并行運(yùn)行奄抽。Weex 實(shí)例的生命周期可調(diào)用 JS Service 生命周期蔼两。目前提供創(chuàng)建、刷新逞度、銷毀生命周期额划。
這塊我在官方的Demo里面也沒(méi)有找到相關(guān)的例子。在官方的文檔里面有相關(guān)的例子档泽。在官方手冊(cè)里面有這樣一句話：
重要提醒: JS Service 非常強(qiáng)大但也很危險(xiǎn)俊戳，請(qǐng)小心使用！
可見(jiàn)馆匿，這塊非常強(qiáng)大抑胎，也許可以做很多“神奇的”事情。
2. Weex可能有更大的“野心”
在官方手冊(cè)《拓展JS framework》這一章節(jié)里面渐北，提到了可以橫向拓展JS framework阿逃。這個(gè)功能可能一般公司都不會(huì)去擴(kuò)展。
Weex 希望能夠尊重盡可能多的開(kāi)發(fā)者的使用習(xí)慣赃蛛，所以除了 Weex 官方支持的 Vue 2.0 之外恃锉，開(kāi)發(fā)者還可以定制并橫向擴(kuò)展自己的或自己喜歡的 JS Framework。
定制完自己的JS Framework以后焊虏，就可能出現(xiàn)下面的代碼：
import * as Vue from '...'
import * as React from '...'
import * as Angular from '...'
export default { Vue, React, Angular };
這樣還可以橫向擴(kuò)展支持Vue淡喜，React，Angular诵闭。
如果在 JS Bundle 在文件開(kāi)頭帶有如下格式的注釋：
// { "framework": "Vue" }
...
這樣 Weex JS 引擎就會(huì)識(shí)別出這個(gè) JS bundle 需要用 Vue 框架來(lái)解析炼团。并分發(fā)給 Vue 框架處理。
所以疏尿，Weex 支持同時(shí)多種框架在一個(gè)移動(dòng)應(yīng)用中共存并各自解析基于不同框架的 JS bundle瘟芝。
可以支持多種框架并存這點(diǎn)非常強(qiáng)大，當(dāng)然還沒(méi)有完褥琐，one more thing……
如果正常使用API锌俱，看官方文檔，不開(kāi)源碼敌呈，是不會(huì)發(fā)現(xiàn)Rax的身影的贸宏。官方文檔絲毫沒(méi)有提及到它。
Rax是什么呢磕洪？
在《淘寶雙促中的 Rax》這篇文章里面介紹了Rax：
Rax 是一個(gè)基于 React 方式的跨容器的 JS 框架吭练。
Rax 經(jīng)過(guò) gzip 以后的大小 8k，與 Angular析显、React鲫咽、Vue 相比更加輕量。相比React的43.7kb，小了太多分尸。
Rax 在設(shè)計(jì)上抽象出 Driver 的概念锦聊，用來(lái)支持在不同容器中渲染，比如目前所支持的：Web, Weex, Node.js 都是基于 Driver 的概念箩绍，未來(lái)即使出現(xiàn)更多的容器（如 VR 孔庭，AR等），Rax 也可以從容應(yīng)對(duì)伶选。Rax 在設(shè)計(jì)上盡量抹平各個(gè)端的差異性史飞，這也使得開(kāi)發(fā)者在差異性和兼容性方面再也不需要投入太多精力了。
如果說(shuō)RN和Weex這些技術(shù)是用來(lái)跨端的技術(shù)仰税，那Rax是用來(lái)跨容器的：Browser构资、Weex、Node.js等陨簇。
那么Weex里面加了Rax能干些什么事情呢吐绵？值得期待！
GitHub Repo：Halfrost-Field
Follow: halfrost · GitHub
Weex 源碼解析系列文章：
Weex 是如何在 iOS 客戶端上跑起來(lái)的
由 FlexBox 算法強(qiáng)力驅(qū)動(dòng)的 Weex 布局引擎
Weex 事件傳遞的那些事兒
Weex 中別具匠心的 JS Framework
iOS 開(kāi)發(fā)者的 Weex 偽最佳實(shí)踐指北
