1. 緣起

說起webview與h5，對整個(gè)移動開發(fā)業(yè)界的人來講弓坞，都是又愛又恨渡冻。愛其功能強(qiáng)大族吻、可動態(tài)發(fā)布超歌、又多端復(fù)用握础。。简烘。又恨其加載慢孤澎、響應(yīng)慢覆旭、體驗(yàn)不佳型将。慢荐虐、慢、慢的問題腕铸，往往讓開發(fā)撓頭狠裹、讓客戶罵娘涛菠！天使與惡魔的共同體俗冻，好的壞的都那么明顯梢夯。

業(yè)務(wù)快速迭代颂砸，h5頁面往往承擔(dān)著一家公司的大部分流量來源勤篮，這對有贊也不例外色罚。優(yōu)化h5的加載戳护，提升客戶體驗(yàn)腌且，收益和價(jià)值都是巨大的铺董。

2. 怎樣做webview/h5加速精续？

要提升h5的加載體驗(yàn)，首先要弄清楚的是顷级，到底是什么影響了h5的打開速度愕把。這是一個(gè)系統(tǒng)性的問題森爽，涉及到移動端橘蜜、前端付呕、后端多個(gè)領(lǐng)域徽职、整條鏈接的加載優(yōu)化说订。本文將只聚焦于從移動端的角度怎樣做優(yōu)化。

2.1 從WebView.loadUrl(url)講起

當(dāng)我們開始加載一個(gè)網(wǎng)頁陶冷，從調(diào)用WebView.loadUrl(url)開始煞额，系統(tǒng)到底做了哪些事情膊毁，各個(gè)階段的消耗情況如何？

image

我們對于有贊的的一些典型h5頁面做了各階段的測試（在wifi條件下）涩僻，總結(jié)如下表：

2.2 到底什么更影響加載體驗(yàn)逆日？——白屏?xí)r間 or 整體加載時(shí)間

從直觀的角度講嵌巷，當(dāng)打開一個(gè)h5頁面的時(shí)候，頁面會有較長時(shí)間的白屏——此所謂響應(yīng)慢室抽。反應(yīng)到上圖的系統(tǒng)過程中，它包括：webview內(nèi)核初始化（首次打開）、DNS解析及建連漓概、請求html并下載蜓陌、解析html及同步資源這幾步。我們把這個(gè)過程記為白屏?xí)r間蛀骇。白屏?xí)r間在h5頁面加載的前半程檐晕，對整體的體驗(yàn)影響最大。

而頁面的整體加載時(shí)間，還包括異步資源、數(shù)據(jù)請求的完成武通，往往是在當(dāng)前頁面已經(jīng)可看囚枪、可操作的后臺繼續(xù)進(jìn)行著忆植。對用戶的體驗(yàn)影響較小（除非首屏有大塊區(qū)域需要這種異步資源或者數(shù)據(jù)請求作展示，比如：有贊的商品詳情頁頂部大部分是商品輪播圖）房官。

從上述表格來看，頁面整體的加載過程在1.2s左右蜡峰，白屏?xí)r間至少400ms～800ms油航。這是在wifi條件下測得的數(shù)據(jù)秒啦，換成移動網(wǎng)絡(luò)2G/3G灌诅，情況會更糟！

2.3 從哪些方面著手？

清楚了各個(gè)階段的消耗全景，以及對體驗(yàn)影響最大的白屏?xí)r間揭鳞。從以下方面入手：

• webview內(nèi)核的加載

  這里指webkit內(nèi)核的初次加載乓梨，包含java類的load总处、動態(tài)庫查找load到內(nèi)存中荸频，也包括webview的創(chuàng)建和悦。可考慮的一個(gè)做法是徒探，應(yīng)用啟動時(shí)全局加載webview內(nèi)核钱贯，以空間換時(shí)間（此法大約有10M左右的內(nèi)存占用）。

• DNS解析優(yōu)化

  DNS解析情況好的時(shí)候支竹，幾毫秒扎运、十幾毫秒就完成了。差的時(shí)候启泣，可能需要花很多時(shí)間（遇到過需要1.5s的case）险耀。域名收斂澎媒、對DNS做prefetch, 尤其對優(yōu)化一些長尾case非常有用匀油。

• 靜態(tài)資源緩存

  如果對css/js齐媒、圖片拷恨、或者其他如ttf等靜態(tài)資源，預(yù)先緩存到本地魁淳，可以省去從遠(yuǎn)端拉取靜態(tài)資源的消耗。在我們的解決方案中馋贤，對于初次腰埂、二次打開頁面，靜態(tài)資源的命中率都可以做到80%～100%鱼蝉。

  但是必須清楚呈野，除了那幾個(gè)解析渲染首屏html必要的跃洛、同步的靜態(tài)資源(css/js), 提升靜態(tài)資源的命中率整體對于白屏?xí)r間的優(yōu)化是比較有限的找颓。靜態(tài)資源的加載大多是在頁面加載的后半程。

• html預(yù)取及緩存

  從上面數(shù)據(jù)可以看出，下載html內(nèi)容的消耗在400ms左右，這是白屏?xí)r間的一大來源玫氢。如果能縮減這部分時(shí)間漾峡，則可以大大減少白屏牺陶。將html內(nèi)容提前下載到本地，WebView.loadUrl(ur)時(shí)直接從本地加載，速度要快得多荣倾。

  但html本身是常變化的，如果本地緩存的html內(nèi)容過期了怎么辦推姻？

  如果html的內(nèi)容是用戶相關(guān)平匈、需要登錄才能看的怎么辦？

  不過藏古，html的預(yù)取增炭、緩存雖然有諸多限制，但并非沒有適用的場景拧晕！

  在有贊的webview加速解決方案中隙姿，通過對可緩存的html范圍做限制，解決了店鋪首頁厂捞、活動頁的h5打開提速問題输玷。這些頁面都是屬于變化較少、并不私有的頁面靡馁。

  更重要的是：這些頁面欲鹏，往往都是webview的入口頁（從native到webview），是最可能產(chǎn)生白屏的地方臭墨。進(jìn)入這些頁面后再點(diǎn)擊跳轉(zhuǎn)到其他頁面屬于webview內(nèi)跳轉(zhuǎn)赔嚎，其體驗(yàn)尚可。

3. 有贊前端體系及h5資源分析

3.1 靜態(tài)資源區(qū)分

有贊h5頁面中的資源整體要分成兩種：

一種是有贊統(tǒng)一資源胧弛，這指的是頁面共有的css/js等資源尤误，屬于有贊的頁面都可能會使用;

另一種商家特有的差異資源，只有在這個(gè)商家的店鋪當(dāng)中才會用到结缚，這部分主要是商家上傳的商品圖片损晤。

image

舉幾個(gè)實(shí)例：

假如有贊的兩個(gè)商家A和B沉馆，分別有自己的店鋪或客戶端码党。商家A和B都會共同用到有贊的一些基礎(chǔ)css/js靜態(tài)資源德崭。但A、B各自的商品圖片等靜態(tài)資源是相互隔離的揖盘。

除了共用的基礎(chǔ)css/js等靜態(tài)資源眉厨，在A的端中只能緩存自己的圖片資源，B的端也同樣只需緩存B自己的圖片資源兽狭。

這里有必要解釋一下“商家的端”的概念及具體形式：拿有贊典型的兩個(gè)產(chǎn)品來說憾股，一個(gè)是微商城鹿蜀，一個(gè)是App開店。在微商城客戶端中服球，商家A和B分別用自己的帳號登錄茴恰、管理自己的店鋪，這里斩熊，商家的端=微商城客戶端+A/B的店鋪往枣。

而在App開店中，有贊提供一個(gè)基礎(chǔ)的AppSDK粉渠，包裝有贊的商品系統(tǒng)分冈、營銷系統(tǒng)等后臺服務(wù)，商家A和B在自有的客戶端App中集成這個(gè)基礎(chǔ)SDK霸株，就可以使用有贊的服務(wù)雕沉。這里，商家的端=商家A/B自有的app+AppSDK

image

不同的商家的端去件，所需要的資源是不相同且必需隔離的坡椒。這一特點(diǎn)會影響到我們后面的系統(tǒng)設(shè)計(jì)。

3.2 靜態(tài)資源變化與路徑

做靜態(tài)資源緩存的一大要點(diǎn)是如何解決資源變化后的實(shí)時(shí)更新問題尤溜？以及系統(tǒng)如何自動發(fā)現(xiàn)資源已經(jīng)變化肠牲？變化后如何更新緩存？

我們的前端每天都在發(fā)布靴跛，每天都有一定數(shù)量的css/js等需要更新缀雳。
我們的商家們每天都在做生意、上傳新的商品梢睛，每天都在添加新的圖片肥印。

對于css/js等一類資源，我們采用webpack打包绝葡，資源內(nèi)容的變化就一定會引起資源路徑變化深碱。比如：/v2/build/wap/ump/send_coupon_f4f485ecf5.js 這個(gè)資源，它的后綴部分f4f485ecf5其實(shí)是這個(gè)資源文件的md5值前10位藏畅。

對于圖片類的資源敷硅，每次上傳圖片，它也會有一個(gè)唯一的路徑愉阎。比如：/upload_files/2017/12/14/FlF05IkscTy9TACqGg129U8Kqxex.jpg绞蹦。

變化后的資源 => 不同的路徑， 這個(gè)特點(diǎn)對于解決如何發(fā)現(xiàn)變化榜旦、緩存實(shí)時(shí)更新的問題真是有太多的方便幽七！

3.3 html頁面特點(diǎn)及區(qū)分

有贊的html頁面有很多種，各有特點(diǎn)：有的變化很快溅呢，有的屬于隱私頁面澡屡。但也有一些相對穩(wěn)定的入口頁猿挚、活動頁。

html的加速驶鹉，除了從html獲取的全鏈接下手（包括服務(wù)器绩蜻、業(yè)務(wù)方、協(xié)議層等）室埋，單就做html緩存預(yù)取來說辜羊，其實(shí)是相當(dāng)難做的。因?yàn)閷?shí)時(shí)性的問題词顾，難以解決八秃。尤其有贊的html頁面并未做前后端分離。它的所有頁面內(nèi)容肉盹，包括一部分頁面數(shù)據(jù)都是在服務(wù)器端中拼接直出的昔驱。

從之前的數(shù)據(jù)分析，html內(nèi)容的獲取是占白屏?xí)r間的大頭上忍。所以對它做優(yōu)化是項(xiàng)目是否取得顯著成效的關(guān)鍵骤肛。但是如果把前后端的同學(xué)聚集起來做大幅度的改造：前后端分離斑鼻、優(yōu)化協(xié)議艇搀。。忆嗜∠朋希恐怕長期也難見成效淑玫。業(yè)務(wù)的發(fā)展和成長是第一位的。

如果我們把要優(yōu)化html頁面的范圍縮小面睛，聚焦于那些相對穩(wěn)定的微頁面/店鋪首頁絮蒿、商品詳情頁、活動頁叁鉴，我們可以犧牲一點(diǎn)點(diǎn)的實(shí)時(shí)性土涝，來換取加載體驗(yàn)極大提升。而恰恰這些頁面往往是webview的入口頁幌墓，也是訪問最多的頁面但壮。對它們的加載做優(yōu)化，可以得到最佳的投入收益比常侣。

4. 金翅(goldwing)——有贊移動端h5加速平臺

初看這個(gè)名字可能會覺得很怪蜡饵，它很中國化，英文代號也很拉風(fēng)袭祟。金翅是一種常見的鳥验残，我們寄寓這套系統(tǒng)能給我們的app帶上翅膀。

金翅是我們對有贊移動端h5加速解決方案的總稱巾乳，它包括Android/iOS客戶端sdk您没、java后臺服務(wù)、還有nodejs寫的管理控制臺胆绊。

image

在這套系統(tǒng)中氨鹏，我們解決了以下幾個(gè)問題：

• 有贊所有靜態(tài)資源的緩存，包括統(tǒng)一的css/js等資源压状，及商家端特有的圖片等資源;
• 店鋪首頁/微頁面仆抵、商品詳情頁、活動頁等入口頁的html加速;
• 動態(tài)化配置种冬、在線接入及管理镣丑。

在不約束下載條件（如:wifi）的情況下，不論是首次娱两、二次以后打開頁面莺匠，靜態(tài)資源的命中率達(dá)到了80%～100%。

對于html的加速優(yōu)化前后十兢，請看如下動圖對比：

• 不使用優(yōu)化

image

• 使用優(yōu)化后（靜態(tài)資源緩存+html緩存預(yù)热たⅰ）

image

效果還是還當(dāng)?shù)拿黠@的！未使用優(yōu)化的第一張圖旱物，可明顯看出有較長時(shí)間的白屏效果遥缕。而使用優(yōu)化后的第二張圖，效果已經(jīng)可以近于native化的加載體驗(yàn)了宵呛。

關(guān)于金翅如何做靜態(tài)資源的緩存单匣？如何做html的加速、緩存預(yù)缺λ搿封孙？后文將單獨(dú)做專題講述。

5. 結(jié)語

做這套h5加速解決方案讽营，前后時(shí)間大概有三個(gè)月之久虎忌。這期間小組內(nèi)同事們除了要繼續(xù)做手頭的業(yè)務(wù)，其他大部分的精力都投入了這項(xiàng)工作當(dāng)中橱鹏。

這期間我們參考了業(yè)內(nèi)許多其他公司同仁的分析膜蠢、思考與總結(jié)，結(jié)合有贊業(yè)務(wù)的特點(diǎn)完成了這套h5加速解決方案莉兰。

目前這套體系穩(wěn)定的接受著千萬級流量的洗禮挑围，我們同時(shí)也在公司內(nèi)的更多業(yè)務(wù)線中推廣鋪開。