摘要：而渲染帶來(lái)的性能問(wèn)題主要是由于數(shù)據(jù)接口請(qǐng)求返回以及前端資源獲取所帶來(lái)的網(wǎng)絡(luò)問(wèn)題。本地化實(shí)現(xiàn)由于我們的這面是純渲染的，所以我們一個(gè)最終的詳情頁(yè)主要是由新聞數(shù)據(jù)和靜態(tài)頁(yè)面兩者構(gòu)成的。

開(kāi)篇之前先介紹一下場(chǎng)景。信息流是一個(gè)基于用戶(hù)興趣使用算法將用戶(hù)感興趣的新聞內(nèi)容推薦給用戶(hù)的一種業(yè)務(wù)。這種業(yè)務(wù)帶有非常特色的場(chǎng)景就是用戶(hù)有一個(gè)“永遠(yuǎn)”都刷不完的推薦流列表，點(diǎn)擊列表中的新聞之后可以跳轉(zhuǎn)到其詳情頁(yè)中查看新聞的正文內(nèi)容。列表一般都是由客戶(hù)端原生去實(shí)現(xiàn)的，而詳情頁(yè)這塊由于新聞內(nèi)容結(jié)構(gòu)的復(fù)雜性，一般還是會(huì)使用 h5 來(lái)實(shí)現(xiàn)。這樣就對(duì)我們 h5 的性能提出了要求，我們必須在用戶(hù)切換的時(shí)候?qū)⑶袚Q的白屏?xí)r間盡量減少，這樣才能提高用戶(hù)的閱讀體驗(yàn)。

本文就將為大家講述一下我們是如何實(shí)現(xiàn)性能優(yōu)化達(dá)到“閃開(kāi)”的效果的。我們可以先看看效果
https://v.qq.com/x/page/j0900...，下圖左邊是正常版本，而右邊的是優(yōu)化后的版本。對(duì)比之下可以發(fā)現(xiàn)即使我已經(jīng)悄咪咪的先點(diǎn)擊左邊的手機(jī)，同一篇新聞?dòng)疫叺拇蜷_(kāi)速度明顯比左邊的要快很多。接下來(lái)就讓我們看看這個(gè)是如何做到的吧！

眾所周知，網(wǎng)頁(yè)中內(nèi)容渲染往往根據(jù)渲染方式可以分為后渲染和前端渲染兩種方式，最近幾年由前端渲染又演化出了同構(gòu)渲染，也就是大家經(jīng)常說(shuō)的 SSR。這幾種渲染方式的主要優(yōu)缺點(diǎn)大概整理了主要有如下幾個(gè)方面。

后端渲染：

優(yōu)勢(shì)：服務(wù)端直出首屏性能好，SEO好

劣勢(shì)：交互邏輯復(fù)雜需要兩端維護(hù)結(jié)構(gòu)

前端渲染：

優(yōu)勢(shì)：前端交互易維護(hù)，數(shù)據(jù)渲染分離

劣勢(shì)：首屏性能問(wèn)題以及 SEO 問(wèn)題

同構(gòu)渲染：

優(yōu)勢(shì)：首屏性能好，SEO 好，一份代碼多端運(yùn)行

劣勢(shì)：代碼維護(hù)成本，服務(wù)器性能和維護(hù)成本增加

當(dāng)然本篇文章不是來(lái)講各種渲染方式的優(yōu)缺點(diǎn)的，主要是說(shuō)因?yàn)榉N種原因我們的項(xiàng)目最后使用了前端 JS 渲染的方式。而 JS 渲染帶來(lái)的性能問(wèn)題主要是由于數(shù)據(jù)接口請(qǐng)求返回以及前端 JS 資源獲取所帶來(lái)的網(wǎng)絡(luò)問(wèn)題。為了解決這兩個(gè)問(wèn)題，一方面我們采用了服務(wù)端將數(shù)據(jù)注入到頁(yè)面全局變量中的方式避免了數(shù)據(jù)請(qǐng)求，另一方面我們使用了 localStorage 緩存的方式將前端資源做了 LS 緩存避免了二次打開(kāi)之后的前端資源請(qǐng)求，從而提高了前端渲染的首屏性能。

雖然我們避免了前端渲染的一些問(wèn)題對(duì)首屏的性能做了優(yōu)化，但還遠(yuǎn)遠(yuǎn)不夠。那目前還有哪些點(diǎn)可以進(jìn)行優(yōu)化呢？簡(jiǎn)單的整理了下可以有如下兩個(gè)方面：

首次進(jìn)入以及線(xiàn)上代碼有更新之后還是需要下載前端資源

服務(wù)端頁(yè)面的 ttfb 相應(yīng)還有優(yōu)化的空間

客戶(hù)端 WebView 打開(kāi)的速度和性能還有優(yōu)化的空間

從上面兩個(gè)優(yōu)化點(diǎn)我們可以看到所有的優(yōu)化還是網(wǎng)絡(luò)的優(yōu)化，主要還是在移動(dòng)端網(wǎng)絡(luò)對(duì)性能的影響是遠(yuǎn)遠(yuǎn)大于其他方面的。那么是否有什么方案能夠讓我們免去這些網(wǎng)絡(luò)請(qǐng)求呢，最終我們給的答案就是詳情頁(yè)本地化。通過(guò)本地化方案，我們將平均 820ms 的首屏渲染時(shí)間優(yōu)化到了 260ms，整整提高了三倍多！

詳情頁(yè)本地化就是客戶(hù)端不走網(wǎng)絡(luò)請(qǐng)求打開(kāi)新聞的方案，解決上文中列舉的所有網(wǎng)絡(luò)請(qǐng)求相關(guān)的優(yōu)化點(diǎn)。它除了能為我們帶來(lái)首屏性能的進(jìn)一步提升之外，由于它不走網(wǎng)絡(luò)請(qǐng)求的特性，也為我們解決了復(fù)雜網(wǎng)絡(luò)環(huán)境下頁(yè)面劫持導(dǎo)致的詳情頁(yè)白頁(yè)打不開(kāi)的問(wèn)題。同時(shí)還為我們帶來(lái)了無(wú)網(wǎng)絡(luò)環(huán)境下的離線(xiàn)閱讀新聞的能力。

由于我們的這面是純 JS 渲染的，所以我們一個(gè)最終的詳情頁(yè)主要是由新聞數(shù)據(jù)和靜態(tài)頁(yè)面兩者構(gòu)成的。
鑒于對(duì)服務(wù)端的依賴(lài)非常的少，和大部分的 SPA 頁(yè)面一樣，本質(zhì)上只要在客戶(hù)端將我們的前端頁(yè)面提前下載下來(lái)就能正常打開(kāi)了。

詳情頁(yè) = 靜態(tài)頁(yè)面 + 新聞數(shù)據(jù)

而如何在用戶(hù)還沒(méi)有打開(kāi)新聞之前客戶(hù)端就能把我們的頁(yè)面資源下載下來(lái)呢？這里就不得不提一下我們的場(chǎng)景，因?yàn)樵谖覀兊男畔⒘鲌?chǎng)景中，用戶(hù)永遠(yuǎn)是通過(guò)流點(diǎn)擊進(jìn)入到詳情頁(yè)中。而在客戶(hù)端的流中是需要加載服務(wù)端數(shù)據(jù)的，所以在這個(gè)時(shí)候其實(shí)我們就可以告知客戶(hù)端讓其提前下載好模板。當(dāng)然大家不要忘記，除了頁(yè)面之外我們還要有新聞數(shù)據(jù)，為了實(shí)現(xiàn)純離線(xiàn)化同時(shí)也避免新聞數(shù)據(jù)接口的請(qǐng)求，在列表中還會(huì)將每條新聞的詳細(xì)數(shù)據(jù)下發(fā)下去，保證必備要素的本地化。

如圖所示，在列表請(qǐng)求的接口中，服務(wù)端會(huì)將需要緩存的靜態(tài)頁(yè)面地址以及每條新聞對(duì)應(yīng)的新聞數(shù)據(jù)全部下發(fā)給客戶(hù)端，客戶(hù)端接收到請(qǐng)求之后會(huì)進(jìn)行模板的下載。

需要的東西下發(fā)下去之后剩下的就是客戶(hù)端進(jìn)行渲染了。正常來(lái)說(shuō)除了模板頁(yè)面之外，服務(wù)端還需要下載其他相關(guān)的靜態(tài)資源，然后啟動(dòng)一個(gè) HTTP 服務(wù)將頁(yè)面和資源文件進(jìn)行關(guān)聯(lián)，關(guān)聯(lián)之后將數(shù)據(jù)注入到頁(yè)面之后打開(kāi)頁(yè)面。但這對(duì)客戶(hù)端的要求就非常多了，為了將客戶(hù)端的工作量降低，我們將所有需要使用的靜態(tài)資源通過(guò)編譯內(nèi)聯(lián)到 HTML 文件內(nèi)，客戶(hù)端通過(guò)字符串拼接的形式將數(shù)據(jù)注入到頁(yè)面的全局變量中。

如圖所示所有靜態(tài)資源都被標(biāo)記了 inline 屬性，我們的編譯工具在讀取到這個(gè)屬性后會(huì)將當(dāng)前資源給內(nèi)聯(lián)到 HTML 中。同時(shí)大家注意到該模板不是以 開(kāi)頭的，而是有一些截?cái)?。這是為了給客戶(hù)端提供注入數(shù)據(jù)空間，客戶(hù)端通過(guò)模板字符串拼接的形式將新聞數(shù)據(jù)注入到全局變量中最終完成整個(gè)新聞頁(yè)面的獲取。前端代碼中則直接使用 __INJECT_DATA_FROM_CLIENT_DONT_MODIFY__ 全局變量獲取注入的數(shù)據(jù)。

上面就是一套完整的本地化下發(fā)并打開(kāi)的流程了，總的來(lái)講就分為四步：

前端將頁(yè)面處理成真·單頁(yè)應(yīng)用

服務(wù)端在列表時(shí)將數(shù)據(jù)和本地化模板下載地址通過(guò)接口下發(fā)給客戶(hù)端

客戶(hù)端獲取到模板下載地址后進(jìn)行下載

當(dāng)用戶(hù)打開(kāi)新聞的時(shí)候客戶(hù)端將數(shù)據(jù)和模板進(jìn)行拼接打開(kāi)即可

但是只要有資源的分發(fā)就會(huì)涉及到資源的同步更新問(wèn)題，我們的本地化模板也是一樣。在我們的線(xiàn)上更新的時(shí)候如何讓客戶(hù)端知曉并觸發(fā)更新行為，也是我們需要去考慮的問(wèn)題。實(shí)際上大家在前兩張截圖中可以看到，為了解決這個(gè)問(wèn)題，我們是在服務(wù)端下發(fā)的接口中還增加了一個(gè) version 字段，用來(lái)標(biāo)記當(dāng)前 HTML 的版本。而當(dāng)前端進(jìn)行代碼發(fā)布的時(shí)候，我們的發(fā)布系統(tǒng)會(huì)有一個(gè)類(lèi)似 npm 的 postpublish 的鉤子，利用這個(gè)鉤子我們告訴服務(wù)端發(fā)布成功更新版本號(hào)。最后，當(dāng)客戶(hù)端接收到新的版本號(hào)的時(shí)候則會(huì)重新下載新的模板，完成一次本地模板的更新。

在前端頁(yè)面中，Cookie 和 LocalStorage 等大量的特性是和域名相關(guān)的，而不巧的是我們的頁(yè)面中都有使用，所以跨域也是我們需要考慮到的問(wèn)題。我們知道，本質(zhì)上此種方案下客戶(hù)端相當(dāng)于使用 WebView 打開(kāi)了一個(gè)本地頁(yè)面，而在 Android 系統(tǒng)中 WebView 打開(kāi)本地頁(yè)面的話(huà)有三種方法：

loadUrl：本質(zhì)上使用 file:///temp.html 的形式打開(kāi)一個(gè)本地文件 URL

loadData：和 loadUrl 類(lèi)型，好的地方在于不需要寫(xiě)成文件，可以直接加載頁(yè)面字符串，不過(guò)此時(shí)加載完之后頁(yè)面的 URL 是 about:blank

loadDataWithBaseURL：和 loadData 類(lèi)似，好的地方在于提供了參數(shù)能夠設(shè)置當(dāng)前 URL 地址

從描述中可以看到，很明顯最后一種 loadDataWithBaseURL 才是我們需要的?？蛻?hù)端通過(guò)這個(gè)方法加載，設(shè)置當(dāng)前頁(yè)面的 URL 為真實(shí)線(xiàn)上 URL，對(duì)于前端來(lái)說(shuō)基本上就和線(xiàn)上環(huán)境無(wú)異了，本地化和線(xiàn)上 Cookie 和 LocalStorage 的共享都沒(méi)有問(wèn)題。不過(guò)這里需要注意，第一個(gè)參數(shù) baseUrl 僅能管住當(dāng)前頁(yè)面，如果頁(yè)面做了 history.pushState() 等前進(jìn)后退操作的話(huà)當(dāng)前頁(yè)面地址又會(huì)變成 about:blank，此時(shí)需要再設(shè)置最后一個(gè)參數(shù) historyUrl 才行。

本文給大家講述了實(shí)現(xiàn)本地化離線(xiàn)閱讀的方案。除了以上列舉的問(wèn)題，我們還碰到了一些細(xì)微的問(wèn)題。例如我們發(fā)現(xiàn)在網(wǎng)絡(luò)不好的情況下客戶(hù)端可能會(huì)下載模板失敗緩存了不完整的代碼，所以我們?cè)黾恿四０宓?md5 值一并下發(fā)給客戶(hù)端用來(lái)校驗(yàn)?zāi)０迨欠裣螺d完全。又如上文說(shuō)了模板的更新，實(shí)際上內(nèi)容也會(huì)有更新，特別是一些新聞的實(shí)時(shí)性會(huì)有比較高的要求，為了解決這個(gè)問(wèn)題，我們會(huì)在頁(yè)面打開(kāi)后再次去檢查一下文章的狀態(tài)，如果發(fā)生變量會(huì)切換至線(xiàn)上版本用來(lái)規(guī)避這個(gè)問(wèn)題。除了這些之外我們還做了完備的云控后退方案，能在方案出問(wèn)題的時(shí)候完美回退到普通版本。

其實(shí)大家可以看到，本地化只是我們?cè)谔囟▓?chǎng)景下決絕性能問(wèn)題的一種特定思路。它并不是使用于所有的場(chǎng)景，所以我在文章開(kāi)頭也特別強(qiáng)調(diào)了一下我們的應(yīng)用場(chǎng)景方便大家去理解。但是我們只要理解這種方案的精髓，我相信在其它的一些特定場(chǎng)合總能發(fā)揮它的威力。