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

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

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

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

后端渲染：

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

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

前端渲染：

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

劣勢：首屏性能問題以及 SEO 問題

同構(gòu)渲染：

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

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

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

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

首次進入以及線上代碼有更新之后還是需要下載前端資源

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

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

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

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

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

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

而如何在用戶還沒有打開新聞之前客戶端就能把我們的頁面資源下載下來呢？這里就不得不提一下我們的場景，因為在我們的信息流場景中，用戶永遠是通過流點擊進入到詳情頁中。而在客戶端的流中是需要加載服務(wù)端數(shù)據(jù)的，所以在這個時候其實我們就可以告知客戶端讓其提前下載好模板。當(dāng)然大家不要忘記，除了頁面之外我們還要有新聞數(shù)據(jù)，為了實現(xiàn)純離線化同時也避免新聞數(shù)據(jù)接口的請求，在列表中還會將每條新聞的詳細數(shù)據(jù)下發(fā)下去，保證必備要素的本地化。

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

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

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

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

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

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

客戶端獲取到模板下載地址后進行下載

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

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

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

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

loadData：和 loadUrl 類型，好的地方在于不需要寫成文件，可以直接加載頁面字符串，不過此時加載完之后頁面的 URL 是 about:blank

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

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

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

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