本文的讀者需要有一定的 Hybrid 基礎，相關的概念已經(jīng)有很多優(yōu)秀的文章進行過講解，這里不再贅述。本文的重點在于如何基于 Hybrid 框架，在移動端（不限于具體平臺）完成一個 wap 頁面的完整下載。這個頁面會包含豐富的媒體資源，包括圖片、音頻、視頻等。下載完成之后，我們在離線時依然能夠流暢閱讀該頁面的完整內(nèi)容。
場景分析
在移動端使用 wap 頁面展示內(nèi)容有非常多的應用場景，比如常見的新聞資訊閱讀、簡書或掘金的文章展示?？蛻舳颂峁?webview 容器，配套一系列前端與客戶端交互的能力，前端使用模板批量生成不同的內(nèi)容后下發(fā)，發(fā)揮著前端極高靈活性的同時又可以享受到客戶端原生的許多能力。
前面說的場景，用戶很少有緩存的需求。不過對于某些產(chǎn)品中用戶可能會反復查看的內(nèi)容，提供頁面的下載以供離線查看就很有必要了。wap 頁面不僅可以展示文本，還經(jīng)常出現(xiàn)圖片，有的頁面中還會包含音頻甚至視頻，該采用什么方式完成下載，需要根據(jù)不同的場景具體分析。
方案選擇
一般而言，提供了下載功能的 wap 頁面，它將展示的內(nèi)容形式必然是有限制的。如果任何一個頁面丟過來都要求緩存，我們很難保證離線情況下的展示效果。
利用 NSURLProtocol 實現(xiàn)緩存
對于簡單的頁面，比如它只包含文本和圖片，那么不依賴 Hybrid 也可以實現(xiàn)。NSURLProtocol 就是一個可選方案，并且它的覆蓋范圍可以更廣。使用 NSURLProtocol 對網(wǎng)絡請求進行過濾，如果是特定的 html、css、js 等請求和圖片請求，就在本地緩存數(shù)據(jù)中進行查找，命中緩存則使用本地數(shù)據(jù)包裝成網(wǎng)絡請求的響應數(shù)據(jù)進行回傳，否則才執(zhí)行對應的網(wǎng)絡請求。這樣即使在網(wǎng)絡可用的情況下，也會優(yōu)先使用本地緩存數(shù)據(jù)，不僅可以完成頁面的離線展示，還有效地加快了網(wǎng)絡可用時頁面的加載速度。自然想到，這也是很多 wap 頁面加速方案會采用的方式。
基于 Hybrid 的 wap 頁面
而對于包含了音頻、視頻等內(nèi)容的 wap 頁面，出于用戶體驗等目的，客戶端往往會將這些資源的展示進行接管。比如頁面中包含音樂時，用戶進行點擊會發(fā)現(xiàn)是客戶端的播放器在進行播放，這便是 Hybrid 應用的例子。它的一個常見實現(xiàn)方案是：客戶端為前端提供了播放音頻的接口，對于 wap 頁面中的所有音頻，放棄前端的原生寫法，采用客戶端提供的接口。而客戶端中這個接口的實現(xiàn)，自然是調(diào)起客戶端音頻播放器，播放對應的音頻，這個過程中又會涉及到是否成功的回調(diào)、客戶端播放器和 wap 頁中播放狀態(tài)的同步等諸多問題，不過這不是本文關注的重點。本文討論的需要完整下載的 wap 頁面的場景，就是基于這種方案。
具體實現(xiàn)
頁面的展示方案
通過上面的例子可以看到，基于 Hybrid 方案展示的 wap 頁面，不僅需要客戶端提供面向前端調(diào)用的各種能力，也需要前端在編寫代碼時進行相應的調(diào)用。兩端相互配合，完成高度定制化的 wap 頁面。對于上面的例子，客戶端提供出來圖片、音頻、視頻的接口，這樣 wap 頁面中對應內(nèi)容的交互，便都交由客戶端的原生實現(xiàn)。而客戶端接口的實現(xiàn)，自然就是首先在本地緩存數(shù)據(jù)中進行查找，若該數(shù)據(jù)已下載，則使用本地數(shù)據(jù)，否則進行對應的網(wǎng)絡獲取，以此兼容有網(wǎng)和離線的情況。
交由客戶端接管的好處，除了上述離線緩存的應用，還有一點是能夠讓 webview 中的內(nèi)容也可以享受到客戶端原生的處理方式。比如圖片接口的客戶端實現(xiàn)，就可以交由項目中使用的網(wǎng)絡圖片異步加載工具（SDWebImage 或 YYWebImage 等），這樣 webview 中的圖片加載和原生場景下的圖片加載可以共享緩存數(shù)據(jù)，原生場景加載過的圖片，在 webview 中展示時便無需重復網(wǎng)絡獲取，反過來也如此?；诰植啃栽?，這樣可以在一定程度上達到圖片加載加速的效果（減少了重復網(wǎng)絡請求）。
進一步優(yōu)化
事實上，在高度定制的 wap 頁面場景下，我們對于 webview 中可能出現(xiàn)的頁面類型會進行嚴格控制?？梢酝ㄟ^內(nèi)容的控制，避免 wap 頁中出現(xiàn)外部頁面的跳轉(zhuǎn)，也可以通過 webview 的對應代理方法，禁掉我們不希望出現(xiàn)的跳轉(zhuǎn)類型，或者同時使用，雙重保護來確保當前 webview 容器中只會出現(xiàn)我們定制過的內(nèi)容。既然 wap 頁的類型是有限的，自然想到，同類型頁面大都由前端采用模板生成，頁面所使用的 html、css、js 的資源很可能是同一份，或者是有限的幾份，把它們直接隨客戶端打包在本地也就變得可行。加載對應的 url 時，直接 load 本地的資源。
對于 webview 中的網(wǎng)絡請求，其實也可以交由客戶端接管，比如在你所采用的 Hybrid 框架中，為前端注冊一個發(fā)起網(wǎng)絡請求的接口。wap 頁中的所有網(wǎng)絡請求，都通過這個接口來發(fā)送。這樣客戶端可以做的事情就非常多了，舉個例子，NSURLProtocol 無法攔截 WKWebview 發(fā)起的網(wǎng)絡請求，采用 Hybrid 方式交由客戶端來發(fā)送，便可以實現(xiàn)對應的攔截。
基于上面的方案，我們的 wap 頁的完整展示流程是這樣：客戶端在 webview 中加載某個 url，判斷符合規(guī)則，load 本地的模板 html，該頁面的內(nèi)部實現(xiàn)是通過客戶端提供的網(wǎng)絡請求接口，發(fā)起獲取具體頁面內(nèi)容的網(wǎng)絡請求，獲得填充的數(shù)據(jù)從而完成展示。
下載時如何確定具體需要下載的資源
客戶端如何確定某個具體 wap 頁中會包含的資源，我們沒有找到很高效的辦法。所幸這種場景下的頁面多是內(nèi)部生產(chǎn)、高度定制的，這也就為后端提供資源統(tǒng)計提供了可能（頁面數(shù)據(jù)本來就是后端生產(chǎn)的~），所以我們采用了后端提供對應接口支持的方案，根據(jù) wap 頁的 id，可以獲取該頁面包含的具體資源。執(zhí)行用戶的下載行為時，使用對應頁面 id 調(diào)用資源統(tǒng)計接口，獲得該頁面包含的資源。這其中包括 JSON 格式的頁面填充數(shù)據(jù)，也包括媒體文件的 url。對于 JSON 數(shù)據(jù)，可以采用簡單的緩存框架進行緩存（YYCache 等），圖片采用場景的圖片緩存框架，音頻、視頻等可以處理成常規(guī)的文件下載任務。
結(jié)語
- 本文并沒有關注具體的 Hybrid 框架如何實現(xiàn)，重點在于提供一個基于 Hybrid 可以實現(xiàn)的具體業(yè)務場景。
- 文中所述的方案，是公司內(nèi)部場景下剝離了業(yè)務的技術實現(xiàn)闡述。會有不盡合理的地方，歡迎討論。
