起點海外版 Hybrid App-內嵌頁優化實踐

本文做者:劉文濤前端

原創聲明:本文爲閱文前端團隊 YFE 成員出品,請尊重原創,轉載請聯繫公衆號 (id: yuewen_YFE) 獲取受權,並註明做者、出處和連接。web

今年年初我司開啓了起點品牌的海外之旅,名爲「 Webnovel 」。算法

目前 PC / M站 / App 三端都在快速的迭代中。而其中起點海外版 App 是基於 Hybird 技術進行開發的。做爲起點海外 Hybird App 中內嵌頁的前端開發,從 1.0.0 版本的陌生,到最近發佈的 2.0.0 版本的嫺熟,海外版內嵌頁的開發方式一直都在改進,力求最大程度的接近 Native App 的頁面性能和用戶體驗。瀏覽器

Webnovel App 頁面截圖

在開始講解起點海外版 App 中內嵌頁的具體實現以及優化以前,讓咱們先來了解下整個 Hybird App 實現的具體方案。緩存

1、Hybrid App 實現方案

1. 什麼是 Hybrid App ?

Hybrid App(混合模式移動應用)是指介於 WebApp 、Native-App 這二者之間的 App,兼具「 Native App 良好用戶交互體驗的優點 」和「 Web App 跨平臺開發的優點 」。網絡

2. 爲何選擇 Hybrid App

  1. Web 實現相對簡單,一套代碼,兩端兼容;
  2. 產品還在快速迭代,變數大,而 Native App 開發,成本偏高;
  3. Web 開發時間較短,減小成本,能夠應付產品的快速迭代;
  4. Hybrid App 的開發方式在公司其餘項目上已經有了很好的運用,技術方案已有沉澱;

以上幾點,是促使海外版 App 使用 Hybird 模式進行開發的主要緣由。架構

2、總體架構

Hybird App 的開發方案的整體架構圖

1. Hybird 實現方案

Hybird App 是使用 iOS 原生 、 Andoird 原生 、Web 頁面 「 內置於 App 中的頁面,既內嵌頁 」一塊兒實現的方式進行開發。工具

2. 完整的SDK工具

  1. 離線包:Web 頁面資源以離線包的形式內嵌在 App 本地存儲中。當訪問頁面的時候,WebView 對於本地存儲的資源無須額外發起的網絡請求,直接讀取。而剩下的請求中,就只剩下 Ajax 拉取的 Json 動態數據,和渲染這部分數據時攜帶的圖片資源,以及一些必要的埋點請求。這使 Web 頁面便是在弱網的狀況下也能夠很快的打開;性能

  2. 完善的JSSDK:使用 JSSDK 與 App 進行交互,透明且跨平臺地使用客戶端的能力,造成交互閉環,給用戶良好的交互體驗;優化

  3. 離線包打包工具:自動化打包工具能快速的產出離線包。沒有了人工干預,App 離線包正確性也能得以保證;

  4. 完善的熱更新機制:App 客戶端監測到離線包更新以後,客戶端靜默更新(用戶無感知),解決了 Native App 頁面不能補丁更新,只能發版修復 Bug 的問題;

3. 完善的後臺系統平臺

  1. 一鍵打包:內嵌頁離線包打包工具可視化,實現一鍵打包產出離線包;

  2. 降級融災:快速回退至以前版本,若有問題,快速下線新版本功能;

  3. 數據採集:完善的數據採集平臺,經過數據分析優化用戶體驗;

  4. 灰度更新:支持根據配置進行灰度更新;

  5. 持續集成:系統平臺目前還在持續集成當中,爲提供更好的開發流程;

3、內嵌頁的優化

咱們起點海外 App 大部分頁面都採用 Hybird 實現的,對於最大程度的接近 Native App 的頁面性能和用戶體驗這兩個點,我着重講解下面兩個部分:

  1. 內嵌頁全局優化-接口頁面並行加載;
  2. 詳情頁加載優化- localStorage ;

1. 內嵌頁全局優化-接口頁面並行加載

以前內嵌頁的開發方式,是在 JS 中發出 Ajax 請求拉取數據,而後使用模版引擎拼接模版,插入到頁面中,再由 WebView 進行頁面渲染。

以前內嵌頁的加載流程

從上圖咱們能夠看到,雖然頁面很快就有了佔位顯示,可是整個操做是串行的,須要等到 Ajax 數據返回以後才能看到頁面。而這個從 WebView 到發起 Ajax 請求之間的時間是被浪費掉了的。

若是當 WebView 啓動的時候就能發送當前頁面的 Ajax 請求,咱們的數據就能夠提早拿到了,而這樣從啓動 WebView 到 Ajax 發請求的之間的空閒時間,就被咱們利用上了。此時上面的流程就變成了以下的樣子:

優化以後內嵌頁的加載流程

當 WebView 啓動的時候,App 根據 Url 地址獲取相應的 Ajax 請求的地址,從而提早發出請求,等到頁面自己請求發出的時候,攔截 Ajax 並判斷是不是已經提早請求過的數據。若是是則基於提早請求的 Ajax 返回的數據渲染頁面,若是不是則繼續發送 Ajax,等到數據返回以後,再進行頁面渲染。

上述作法,咱們充分利用了 App WebView 的啓動到 Ajax 發送獲取數據之間的時間。接口請求與頁面並行加載,加快了頁面顯示。

iOS 端書籍詳情頁加載對比結果

根據上組數據咱們會發現頁面顯示的平均時間幾乎快了 300ms 。在不影響頁面正常加載流程的狀況下,把串行操做變成並行操做,充分利用空餘時間,大大縮短內嵌頁白屏時間,讓用戶更快的看到了咱們起點海外 App 的頁面內容,效果顯著。

2. 詳情頁加載優化- localStorage

採用接口與頁面資源並行加載的方式,使內嵌頁呈現的速度快了不少,可是因爲海外用戶區域普遍,接口加載時長的不肯定,頁面仍是會有白屏的狀況,接下來咱們要作的就是特定頁面,特殊處理。

再整個起點海外 App 頁面中,詳情頁訪問量相對較大,也是整個站點中比較重要的頁面,因此其頁面呈現的速度相當重要。所以本次迭代咱們主要針對詳情頁作了特殊處理。

首先,咱們先分析一下詳情頁的業務形態。書詳情頁數據相對比較穩定,並不會頻繁變化,但接口數據返回須要時間,那咱們是否是可讓書詳情頁的數據先本地存儲,以求達到快速顯示的效果,並同時發出 Ajax 接口,等到數據返回時再糾正頁面上舊的數據。

關於本地存儲,咱們引入 localStorage 來進行本地存儲,緣由以下:

  1. localStorage 能夠存儲的數據容量大;
  2. localStorage 屬於永久性存儲;
  3. localStorage 目前移動端瀏覽器支持度良好;

詳情頁引入localStorage後的加載流程

從上圖咱們能夠看到,當用戶第一次訪問書詳情頁時,localStorage 中沒有相應書籍數據頁面按正常邏輯顯示,但這時咱們會把這份數據緩存到 localStorage 中。當用戶第二次訪問同一本書的詳情頁時,咱們根據 bookId 的 Key 值在 localStorage 中快速找到相應書詳情頁信息數據,並基於該緩存數據拼接模版,渲染頁面。同時繼續發出 Ajax 請求,待數據返回時,與 localStorage 的數據基於 Diff 算法進行對比。若是數據一致,則不作任何處理,不一致則頁面基於新數據從新渲染,而且更新 localStorage 中的數據爲新的 Ajax 返回數據。具體效果對比圖以下,左邊是未作二次加速的,右邊是使用了二次加速的效果:

引入 localStorage 後的頁面加載對比

詳情頁首屏全部數據包括書封顯示時間

能夠看到頁面第一次展現的時候,依然可以明顯看到佔位圖,可是當頁面二次打開就直接呈現,效果很明顯。

結尾~~

作了半年多的 Hybird 頁面的前端開發,針對海外版 App 作了不少的優化,爲的是給用戶帶來更好的體驗。但對於 Hybird 技術自身的瓶頸,咱們也無能爲力。因此目前咱們團隊在嘗試從 Hybird 到 React Native 的技術轉型,以求可以在用戶體驗上更進一步。

一樣延續上一次的分享:一個細節的優化是能夠決定產品的好壞的,良好的用戶體驗,會吸引跟多的用戶,得到更多的稱讚。

如下是起點海外版的訪問地址,請使勁戳戳戳~~~👇

起點海外版 App下載:
請前往 Google play / App Store [ 美區 ] 下載

起點海外版web站:
https://www.webnovel.com

起點海外版m站:
https://m.webnovel.com

更多分享,請關注YFE:

相關文章
相關標籤/搜索