我們都知道混合應(yīng)用的流暢性不如原生應(yīng)用，除了不能像原生一樣輕松駕馭各種狂拽酷炫的效果，混合應(yīng)用還有一個(gè)難以消除的弱點(diǎn)在于頁(yè)面打開(kāi)速度上，如果有機(jī)會(huì)在同一臺(tái)手機(jī)上直接對(duì)比的話，這種差距是肉眼都能直觀感受到的，這主要是由于web頁(yè)面每次打開(kāi)前需要初始化，在那一瞬間需要完成DOM創(chuàng)建、資源下載、樣式渲染、js執(zhí)行，這些時(shí)間消耗造成了按鍵按下與頁(yè)面進(jìn)場(chǎng)之間短暫的停頓，也造成了混合應(yīng)用整體“不流暢，不跟手”的印象。

為了盡可能解決這個(gè)問(wèn)題，最近想到了一種新的優(yōu)化思路，優(yōu)化后在測(cè)試機(jī)上空白頁(yè)面的打開(kāi)速度較之前提升100ms左右，對(duì)于大量依賴(lài)js運(yùn)行的頁(yè)面提速效果更明顯。思路并不復(fù)雜，就是先移除頁(yè)面中所有的js資源，加速頁(yè)面渲染速度，當(dāng)頁(yè)面開(kāi)始進(jìn)場(chǎng)動(dòng)畫(huà)后，再開(kāi)始加載執(zhí)行js，充分利用了進(jìn)場(chǎng)動(dòng)畫(huà)的時(shí)間，以縮短整個(gè)頁(yè)面展現(xiàn)的時(shí)間，核心代碼就是選擇時(shí)機(jī)動(dòng)態(tài)插入js節(jié)點(diǎn)部分，該方案已經(jīng)應(yīng)用于HybridStart項(xiàng)目，詳細(xì)過(guò)程點(diǎn)此了解。

應(yīng)用該方案后同時(shí)還解決了混合應(yīng)用的另一個(gè)問(wèn)題，那就是打開(kāi)不同APP頁(yè)面不再有速度差別了，之前產(chǎn)生的速度差別，主要是因?yàn)閖s代碼可能產(chǎn)生異步請(qǐng)求或者生成DOM節(jié)點(diǎn)，這些耗時(shí)都不可預(yù)估，長(zhǎng)的甚至以秒計(jì)算，優(yōu)化后的頁(yè)面完全排除掉js資源的干擾，渲染速度的差別就僅在于DOM渲染量的差別，而這個(gè)基本上任何頁(yè)面都不會(huì)差太多，因此不同頁(yè)面的打開(kāi)速度也就基本一致了。

最后安利一下HybridStart項(xiàng)目，如果你也在用apicloud做混合應(yīng)用，這一定是你的不二之選，很難想象開(kāi)發(fā)體驗(yàn)?zāi)鼙冗@更好的了。另外HybridStart的開(kāi)發(fā)原則之一是UI可剝離，我認(rèn)為框架的UI跟功能綁定就是耍流氓，沒(méi)錯(cuò)我說(shuō)的就是mui，沒(méi)法想象怎么用mui做自定義風(fēng)格的項(xiàng)目，這方面HybridStart是完勝的，使用HybridStart做項(xiàng)目完全不需要擔(dān)心UI好不好改，因?yàn)槟闵踔量梢砸慌聦⒆詭I刪掉重寫(xiě)，完全不影響核心功能，當(dāng)然了即便UI不是重點(diǎn)，HybridStart的自帶UI也足夠滿足普通APP項(xiàng)目需求了，而且附帶less文件，只要是別太非主流的風(fēng)格都能通過(guò)改變量實(shí)現(xiàn)。

最后，雖然目前HybridStart是基于apicloud平臺(tái)，但未來(lái)還會(huì)跟進(jìn)dcloud平臺(tái)，因?yàn)镠ybridStart的初衷就是跨平臺(tái)，最初一版是脫胎于古老的appcan平臺(tái)，在飽嘗appcan之坑后，決心將其打造成一款跨引擎的混合應(yīng)用開(kāi)發(fā)框架，目的就是抹平不同平臺(tái)的引擎api差別，減少平臺(tái)遷移成本，就目前來(lái)看，apicloud跟dcloud相比，還是稍遜一籌的。