華為快應用引擎技術架構詳解

作者｜華為快應用團隊

編輯｜覃雲 - 前端之巔公眾號

1. 快應用技術架構

快應用介紹及其特點

2018 年 3 月華為與小米，Oppo，Vivo 等 9 家手機廠商，聯合發布快應用聯盟標準。快應用是一種基於手機硬體平台的新型應用形態，無需安裝，即點即用，又兼具原生應用體驗（性能、系統整合、交互等）。同時，快應用在誕生之初就在開發規範、能力接入、開發者服務等層面實現了手機廠商間的標準化統一，極大地降低開發者的適配成本。

與傳統應用相比，快應用具備如下特點：

Instant：即點即用，用戶無需等待

Everywhere：與手機的使用場景深度整合，入口無處不在（搜索，智能助手，智能推薦，應用市場，瀏覽器 ……）

Efficient：准前端的開發方式，效率高

華為快應用引擎架構簡介

上圖是快應用的總體框架示意圖。最上面是應用形態以及場景入口，中間是快應用引擎，底下是 OS(操作系統) 的基礎設施及其硬體。從執行路徑層面，有標準的 HTML5 方式支撐通用的 Web 場景（一般通過系統的 Webview 組件或定製的 Webview）， 以及 JS（JavaScript）+Native 的方式，支撐更輕量、更快速的體驗。 下面將按 3 個層面方面簡要介紹快應用引擎的架構。

應用開發（前端框架 + 組件 & API 能力）

快應用的前端設計借鑒並整合了主流前端框架（Vue，React 等）的設計思路：以組件化的方式構建應用，以數據綁定為核心的 MVVM 設計模式，以 V-DOM 的方式提升性能，同時選擇了簡潔清晰的類 Vue 的模板。同時對布局方面做了相應精簡。從新的應用形態、映射原生 UI、能力開放的角度，需要定義一套組件與 API 規範，方便開發這快速開發應用。

系統整合（應用管理，卡片 - 嵌入式 SDK，安全機制等等）

快應用作為完整的應用形態，可以與系統深入整合，如同原生應用一樣運行，以及和系統交互。快應用目前有兩種形態：全屏方式的獨立應用形態與嵌入方式的卡片形態。在獨立應用的形態下，給用戶的體驗就像原生的應用程序，有完整的生命周期管理，頁面管理，路由等。快應用可以寄生於安卓的 Activity，頁面寄生於 Fragment，並通過獨立的後台 Service 進行實例的管控。卡片則是另外一種形態，通過嵌入式 SDK 作為一個獨立的局部控制項嵌入到系統的各個角落，輕量化的展現動態內容。在安全隔離方面，可通過沙盒機制，進程隔離，許可權控制，並結合操作系統層的支持做到較好的安全保障。

性能體驗 & 新興場景 （JavaScript 引擎，渲染引擎，端 - 雲 - 芯加速，新興場景）

在交互體驗、資源開銷和穩定性等方面，快應用通過引入原生渲染路徑，進而實現前端開發方式 + 原生渲染與平台能力有效組合。

不同於其它的應用層的跨平台框架，快應用植根於手機系統，可實現從晶元操作系統雲的深度整合。端和雲的結合以啟動性能加速為例，通過雲和端的協同渲染，網路鏈路層的優化可以大大加速快應用啟動速度。同時可以整合硬體平台的特有能力，進一步提升體驗。例如可以結合華為手機 AI 晶元，將 NPU 的算力整合到快應用引擎中來，使得 AI 場景（人臉識別、圖像超分等）在端側可以低延時、高性能的執行，同時又有效保護了用戶的隱私，並節省帶寬。

下面以啟動加速作為案例，分享一下體驗優化方面做的一些工作。

秒開的用戶體驗是快應用的核心競爭力之一。Google 的統計表明，頁面打開時間超過 3 秒用戶會流失 13%，超過 6 秒用戶會流失 60%。反過來，打開時間每減少 1 秒可提升 27% 的轉化率。目前快應用從用戶點擊到首頁內容完全展示基本需要 2 秒左右甚至更久。

啟動流程：

1）首次啟動時，用戶點擊觸發快應用包的下載，同時做引擎初始化相關工作。當整包下載與校驗完成後，需要展示的第一個頁面的 JavaScript 文件才會被載入並開始渲染。這個過程中包下載是瓶頸，從實測數據看，正常網路下 200K 左右的包下載時間至少要 400 毫秒以上，2M 包要 2 秒以上。

2）頁面渲染包括 JavaScript 載入、頁面與 JavaScript 框架邏輯的執行、布局的運算，最終到原生 UI 控制項的繪製。其中，頁面內邏輯執行時會有一次或多次的到應用自己的三方伺服器的網路請求，請求返還的數據驅動頁面的再次渲染，直至首屏內容完全展示。

這裡網路請求、JavaScript 執行、排版與繪製並非簡單的串列關係，而是並行化地交織在一起影響著整個頁面的渲染性能，並與頁面設計的邏輯、網路狀況與設備運行的狀態強相關。

啟動性能的優化涉及到的內容較多，這裡主要介紹兩種優化方案：

流式載入 -- 解決網路延時問題

快應用首次啟動需要從雲端下載快應用的程序包（RPK），整包下載完成才能進行解壓與校驗，之後載入並執行相應的 JavaScript 文件。排除伺服器端響應速度與網路狀況的影響，下載延時與文件包大小成正比。我們引入了端雲協同的流式載入方式以減少包延時。

流式載入：

流式載入是將啟動所需要的資源在網路流中優先傳輸，這部分資源傳輸完後並進行解壓與校驗，首頁的渲染就可以立即執行了。網路流的後續傳輸仍在持續進行直至下載過程全部完成。首次渲染所需資源往往很小，所以流式載入能明顯降低下載延時，包越大效果越明顯。流式載入需要解決如下問題：

1）如何決定哪些內容要優先下載？

正常情況下啟動所需資源比較固定（公共資源、全局的配置文件、首頁 JavaScript 文件與圖片等等），這些在應用打包的時候排在文件的前部即可；當首次打開是某個非首頁時，我們就需要在傳輸時將該頁面所需資源排列到網路流前部。

2）訪問到了某個未下載的資源怎麼辦？

網路狀況是不可控的，存在一定的概率出現延時較高的情況。如果此時從首次打開的 A 頁面跳轉的 B 頁面而 B 頁面所需的資源尚未下載完成，則需要在頁面跳轉的過程進行等待，並向服務發起優先調度 B 頁面資源。等 B 頁面資源下載完成後，繼續頁面跳轉的過程。

3）簽名問題如何解決？

原始的簽名方式是對整包進行簽名，待整個包下載完成後才能執行校驗，這是無法滿足流式載入的需求的。為此我們引入了二級校驗的方式：對包的不同片段單獨生成 hash 值，將所有的 Hash 值拼接成一個 Hash 文件，對該 Hash 文件進行簽名。下載時 Hash 文件被優先傳輸，傳輸完先校驗 Hash 文件的合法性。之後流式載入過程中，無論哪個片段下載完成後，可以立即計算 Hash 值，並與 Hash 文件中相應的 Hash 值進行比對，校驗合法性。

快照 -- 解決首屏渲染問題

首頁的渲染也是一個比較耗時的過程，要經過 JavaScript 載入、頁面與 JavaScript 框架邏輯的執行、布局的運算，最終到原生 UI 控制項的繪製。這裡我們引入一種快照機制，來加速渲染過程。

快照：

首先，在雲端對所需要的頁面進行預渲染處理，生成一種渲染的中間格式 -- 快照。它不需要 JavaScript 的運算，解析後可以直接快速地進行頁面數據請求、UI 的排版與繪製。快照格式壓縮後也非常小，50K 左右的 JavaScript 文件生成快照的大約 3K。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！