HTML5頁面無縫閃開的問題及解決方案

在傳統(tǒng)的 web 優(yōu)化中，我們可以采取壓縮、拆包、動態(tài)加載等方法減少首屏資源大小，也能通過離線包、頁面直出等方案加速 html 返回，之前一篇h5 秒開大全有部分簡析。在大部分場景中，這些方案都足夠用，也能得到出色的效果。但仍有兩種無法盡善盡美的地方：其一是短暫的白屏現(xiàn)象不可避免，其二是對于超大型 web 應(yīng)用難以做到秒開。結(jié)合客戶端特性，我們有沒有辦法，進(jìn)一步做到極致，打開 web 頁面和打開客戶端頁面無差異的體驗(yàn)?zāi)兀?/p>

傳統(tǒng)方案的困境

無論是 html 離線，還是直出，以及讓 webview 啟動和網(wǎng)絡(luò)請求并行 ，頁面的切換和打開都無法避免 html 加載這一過程。對于大型應(yīng)用而言，龐大的 js 初始化解析和執(zhí)行會耗費(fèi)巨大的時間。

新的思考方向？

速度優(yōu)化的本質(zhì)是以空間換時間。我們是否可以從這個思路，將打開 webview 及解析 html 這以過程省略掉呢？答案是可以的。

容器化方案

容器化 即是我們最終探索與實(shí)踐的出來的一套方案。正常 web 頁面關(guān)閉后，webview 組件即會銷毀掉，下一次再打開需要重新啟動。通常讓 webview 保持常駐的做法可以節(jié)省 webview 啟動時間， 但簡單的常駐 webview 并不能做到頁面秒開，頁面打開仍然需要重新解析 html。

對于我們的應(yīng)用特征而言，頁面切換實(shí)際上是僅僅內(nèi)容數(shù)據(jù)的變化，比如切換一篇文檔，其 html 容器及樣式都是同一套，而差異僅僅只是在數(shù)據(jù)上，重新載入 html 及初始化 js 這部分耗時完全可以避免掉。讓 webview 組件及其容器內(nèi)的 html 頁面常駐，在文檔切換的過程，僅僅對數(shù)據(jù)進(jìn)行替換，這即是容器化方案。容器化方案省去了 webview 重復(fù)啟動和渲染 html 的問題，打開文檔，耗時只在做數(shù)據(jù)替換，真正做到了秒開。

容器切換

web 側(cè)如何感知到不同的頁面在進(jìn)行互切換，數(shù)據(jù)如何做到替換呢？

首先在 app 打開的時候，文檔列表會進(jìn)行數(shù)據(jù)預(yù)拉取，同時觸發(fā)客戶端預(yù)啟動容器，除此外，其他任意場景也能按需觸發(fā)容器啟動（后面會聊到）。容器內(nèi)會提前進(jìn)行 html 渲染和 js 執(zhí)行，此時的數(shù)據(jù)是空的。用戶點(diǎn)擊文檔，客戶端會對打開 url 這一行為進(jìn)行監(jiān)聽，同時解析 url，取出唯一標(biāo)識符， 判斷本地是否已經(jīng)存在并且符合要求的數(shù)據(jù)，如果條件命中，直接使用已經(jīng)打開的容器切出，通知到容器內(nèi)的 web，web 收到通知，通過 url 取出標(biāo)識符，從本地進(jìn)行數(shù)據(jù)獲取，然后對數(shù)據(jù)進(jìn)行替換渲染，從而完成頁面切換。

容器化數(shù)據(jù)替換

直接容器替換的思路省去了代碼加載和解析時間，但對于前端代碼而言，需要支持直接替換數(shù)據(jù)。大部分前端項(xiàng)目代碼設(shè)計都是 自執(zhí)行調(diào)用 方式，支持容器化的前提是：需要對代碼改造成可支持 數(shù)據(jù)組裝和銷毀 。

// 大部分應(yīng)用加載頁面初始化的場景
class App {
    public init() {
     initA();
     initB();
        // 初始化各種模塊
        ...
    }
}
 
const app = new App();
app.init();

自執(zhí)行調(diào)用后，大量的內(nèi)部依賴模塊也依次進(jìn)行初始化，然后數(shù)據(jù)常駐在內(nèi)存中，通常對于加載一個正常網(wǎng)頁而言，用戶每次都是新開頁面，加載 html， 重新進(jìn)行解析和初始化，并不會帶來什么問題。但是按照容器化思路，頁面不會重新載入，只進(jìn)行數(shù)據(jù)替代，對于大型應(yīng)用而言意味著成千上萬的模塊需要支持內(nèi)存釋放和數(shù)據(jù)切換，一旦沒有處理好，會面臨嚴(yán)重的內(nèi)存泄露和代碼健壯性問題。如何組織和管理這些代碼，支持可插拔式，讓整個頁面初始化流程都能鏈?zhǔn)浇M裝，可以進(jìn)行配置，是進(jìn)行容器化代碼改造的難點(diǎn)。

• 依賴倒置

依賴倒置原則的是指內(nèi)部模塊不應(yīng)該依賴外部模塊，底層模塊不應(yīng)該依賴上層模塊。

哪些才是底層模塊，哪些才是上層模塊呢？通常而言，越穩(wěn)定不變邏輯，應(yīng)該是越底層，越接近用戶交互，容易變化的部分是上層。具體層級劃分需要分析應(yīng)用的結(jié)構(gòu)和依賴關(guān)系，良好劃分層級的應(yīng)用是容器化改造的前提。

• 職責(zé)鏈模式

職責(zé)鏈模式是指每個對象都有接受請求的可能，這些對象連接成一條鏈，請求沿著這條鏈的傳遞，直到有對象處理，這樣做的好處是減少接受者和發(fā)送者直接的耦合。比如在一個頁面加載生命周期中，我們可以讓內(nèi)部模塊到外部模塊都實(shí)現(xiàn)相應(yīng)的生命周期職責(zé)，應(yīng)用啟動和銷毀的過程，請求沿著指定鏈條從外到內(nèi)傳遞，也可以按需指定跳躍某個模塊，這樣大大降低了模塊之間的耦合，從而更好的管理代碼。

export default interface IRestart{
    emitter: EventEmitter;
    startDestroy(): void;
    destroy(): void;
    restart(): void;
    restartEnd(): void;
    // ...
}

class Page {
    next: PageFlow|null;
    cache: {
        start: (() => Promise<any>)[];
        end: (() => Promise<any>)[];
    };
    waitStart(callback: () => Promise<any>) {
        this.cache.start.push(callback);
    };
    waitEnd(callback: () => Promise<any>) {
        this.cache.end.push(callback);
    };
    setNext(flow: PageFlow) {
        this.next = flow;
        return flow;
    }
     // ...
   }

• 依賴注入

所謂依賴注入是當(dāng)指 A 對象依賴另一個 B 對象時，不直接在 A 對象內(nèi)初始化 B，而是通過外部環(huán)境進(jìn)行初始化，作為參數(shù)傳入 A 對象中。這樣做的好處是當(dāng) B 模塊的初始化等條件發(fā)生變化時，不必在 A 對象中進(jìn)行重復(fù)的修改。管理成百上千個這樣模塊相互依賴的代碼中，統(tǒng)一的依賴注入管理器會讓依賴關(guān)系管理變得更方便。

// 模塊加載器
class ServiceLoader {
    source: CONFIG;
    loaded: boolean;    // 是否已加載
    initialized: boolean;   // 是否已初始
    module: any;
    constructor(source: CONFIG) {
        this.loaded = false;
        this.initialized = false;
        // ...
    }
    async load(params?: any): Promise<any> {
     // ..load module
        return this.module;
    }
    //...
}

// 模塊管理器
class ServiceCollection {
    stack: ServiceLoader[];
    private services = new Map<CONFIG, ServiceLoader>();
    constructor() {
        this.stack = [];
    }
    createLoader(config: CONFIG): ServiceLoader {
        const loader: ServiceLoader =  new ServiceLoader(config);
        this.services.set(config, loader);
        return loader;
    }
    // ...
}

initA () {
    const ALoader= this.serviceCollection.createLoader(CONFIG.A);
    const discussMobile = ALoader.init(this.app);
}

數(shù)據(jù)預(yù)拉服務(wù)

容器是否會命中依賴兩個條件，其一對應(yīng)離線包代碼是否下載好；其二對應(yīng)版本的數(shù)據(jù)是否已經(jīng)預(yù)拉緩存完畢。

用戶進(jìn)入文檔管理首頁，首先會去拉取列表索引數(shù)據(jù)，然后通過列表數(shù)據(jù) id 進(jìn)行文檔內(nèi)容數(shù)據(jù)做預(yù)拉，儲存在本地數(shù)據(jù)庫，本地數(shù)據(jù)庫的存儲可以參考前端離線化探索。

webview service

在整個數(shù)據(jù)預(yù)拉的過程，我們是通過一套獨(dú)立的客戶端后臺 webview 服務(wù)執(zhí)行具體任務(wù)，獨(dú)立服務(wù)的好處是讓各種容器化基礎(chǔ)服務(wù)和文檔管理列表本身進(jìn)行解耦，同時將拉取、解析、儲存數(shù)據(jù)這一對性能有消耗的過程放后臺服務(wù)，減少了列表用戶交互界面層的性能壓力。

另一方面，作為多端公用的一個服務(wù)，構(gòu)建流程上單獨(dú)部署，更新代碼的時候能夠不依賴其他頁面，變得更靈活。

數(shù)據(jù)快照

對于純 dom 結(jié)構(gòu)的文檔型品類，我們會在打開文檔，解析數(shù)據(jù)后，把生成的 html 緩存在本地數(shù)據(jù)庫一張快照表里。下一次切換容器時，在取本地數(shù)據(jù)去解析的同時，會判斷對應(yīng) id 在快照表是否存在緩存，如果有，直接取出來，覆蓋在 html 上，用戶可以提前看到上一次渲染的數(shù)據(jù)，等本地數(shù)據(jù)真正解析完，再展示可交互界面。解析數(shù)據(jù)準(zhǔn)備渲染也是需要一個上百毫秒的過程，這一策略可以讓用戶提前看到內(nèi)容。

預(yù)創(chuàng)建

有了極致的打開速度，如何優(yōu)化新建速度呢。正常的新建流程是這樣的，用戶點(diǎn)擊新建按鈕，前端請求創(chuàng)建 cgi, 等待后臺創(chuàng)建成功返回新文檔 url，前端再新開 webview，加載展示頁面。我們可以看，由于需要等待創(chuàng)建接口返回的原因，到新建的過程比正常打開一個文檔還要更久。

怎么樣才能讓新建也做到秒開呢？思路和數(shù)據(jù)預(yù)拉取一樣，在用戶進(jìn)入文檔首頁的同時，我們會提前預(yù)請求一批創(chuàng)建 id，然后緩存到本地，同時根據(jù)創(chuàng)建 id 生成一篇空白文檔數(shù)據(jù)，儲存在本地，標(biāo)示狀態(tài)為未使用。用戶點(diǎn)擊新建按鈕，本質(zhì)上是從本地取一個未使用的文檔 url，直接用容器切換打開，然后再和后臺進(jìn)行同步。

秒開效果

容器化方案前：

容器化方案后：

監(jiān)控與開關(guān)系統(tǒng)

容器方案使用了數(shù)據(jù)預(yù)取場景，命中率的監(jiān)控非常重要。由于切換頁面的過程，如果命中容器，我們會接受來自客戶端的通知，在這個時機(jī)，我們可以進(jìn)行上報。

另外一個非常重要的是容器能力的開關(guān)系統(tǒng)，在發(fā)布之初保持現(xiàn)網(wǎng)穩(wěn)定性是非常重要的措施，但任何程序都不能保證沒有 bug，我們通過內(nèi)部七彩石配置系統(tǒng)控制這套容器方案的各種特性在不同品類下是否啟用，同時這套配置也支持灰度和回滾方案，能夠應(yīng)急各種突發(fā)問題。

灰度期容器間命中率

待優(yōu)化的問題

容器化方案用各種預(yù)創(chuàng)建 webview 的方式換取了打開速度，app 內(nèi)存占用上會比未使用容器化方案要大非常多，webview 的釋放時機(jī)、預(yù)加載數(shù)據(jù)的策略優(yōu)化，及從客戶端到 web 端，如何更好的做內(nèi)存管理是接下來需要進(jìn)一步優(yōu)化的點(diǎn)。

總結(jié)

到此這篇關(guān)于HTML5頁面無縫閃開方案的文章就介紹到這了,更多相關(guān)HTML5頁面無縫閃開內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！