X5 瀏覽器核心調研報告

亦默亦風發表於2019-03-03

關於這份調研報告，不是從技術角度深入探索，重點是從產品本身分析，通俗易懂才是重點。主要是為了鍛鍊平時做技術調研和競品分析的能力，以及業務擴充的技術儲備。內容有點多，下面 **X5 **核心調研報告將分為三個環節：Why – What – How 描述。

按照經典的 2W1H 的策略描述

WHY

一、Android 端為什麼需要考慮瀏覽器核心問題？

**一言以蔽之：你是要搞定一個 X5 上的相容性問題，還是要搞定幾百檯安卓手機上的相容性問題。**下面就從多個維度來分析相容性問題：

系統內建瀏覽器核心差異化

對於 Android 系統，通常以下面四個節點作為重要劃分依據，分析瀏覽器核心的差異性先系統差異性說起，下面是目前 Google 最新統計資料：

系統版本	裝置佔比
Android 4.0以下	0.9%
Android 4.0 – Android 4.4	11.0%
Android 4.4	20.0%
Android5.0及以上	68.1%

從上面資料來看，當前絕大多數 Android 手機使用的都是 Android 4.4 或以上的系統，這也是System WebView 核心大變更的分界線。
在 Android 4.4版本中，原本基於 Android WebKit 的 WebView 實現被換成基於Chromium的實現，新的 Chromium 實現專注於提供一致性的介面（為了相容以前的應用），而內部的渲染引擎改為使用基於 Blink/Content 核心的引擎，這實現不管是從功能上還是效能來講，都帶來巨大的提升。

Chromium是一個由Google主導的開源瀏覽器工程，Chrome瀏覽器會選擇在它的某一個穩定版本進行開發和釋出。除了Chrome瀏覽器，Chrome OS也是基於Chromium開發的。

從 Android 5.0 開始，Google 把 Chromium blink核心 webview 作為 apk 單獨從系統抽離出去，可以在應用市場上面接收安裝更新。應用可以直接使用該webview核心，Google也可以及時釋出更新，不用再通過更新系統才能更新瀏覽器核心，也避免部分了 Android 系統碎片化問題。

Android 平臺碎片化

關於 Android 碎片化問題集中表現在下面幾個方面：

裝置繁多，硬體配置參差不棄，裝置效能各異，差距很大
品牌眾多，廠商標準不一致，定製化系統體驗不同
版本各異，國內外系統環境差異巨大
解析度不統一，各種型別尺寸眾多

下圖是 OpenSignal 在 2015 年 8 月釋出的基礎統計資料，針對市場上常見的 1294 種手機品牌進行了市場佔有率統計，可以看出機型分佈非常零碎。

下圖是關於 Android 裝置解析度的分佈圖，可以看出 Android 裝置各種型別尺寸眾多，開發者需要進行適配的難度非常大。

特別是在 Android 系統開源但 Google 提供的基礎服務在國內無法使用的情況下，國內廠商往往拋棄了 Google 既有的規範，對系統進行了大量的定製，導致裝置ROM 與原生 Android 系統環境差異性巨大。

對於瀏覽器核心也是如此，即便是Google推出了基於 Chromium blink 核心實現的 WebView，但是很多國內廠商對其進行了精簡或替代，導致 WebView 核心也是碎片化問題嚴重，這讓開發者直接使用系統瀏覽器核心進行開發產生了眾多顧慮，不同機型適配難度也大大增加。

二、目前移動端 H5 適配已有的問題是什麼？

** 一言以蔽之：裝置碎片化和UI風格的自定義（動畫特效等）效能差。**
由於Android本身碎片化問題嚴重，不同裝置上的體驗差異性太大，開發者很難全面適配。雖然Google在不斷引入行業中領先的技術改善體驗，但是短時間內很難覆蓋，況且開源特性也導致很難統一各廠商對系統定製化的取捨。

在一些舊機型上面，就算h5頁面中圖片與文字資訊並不多,但在WebView中展示的時候都會出現拖拽不流暢，切換留白、視窗閃爍等的現象，這是 WebView 自身渲染能力不強的問題所致。

又比如Html5的Video控制元件播放視訊，iOS點選視訊部分，會用系統自帶的瀏覽器全屏播放視訊，體驗效果佳；而Android的WebView無法全屏，體驗效果差一些。
對於頁面載入慢，偶爾記憶體洩露，不同 Android 系統版本採用了不同核心的相容問題等等，這些都是使用原生 webview 元件進行開發時常會遇到的問題。

因此目前面臨的首要問題就是：如何解決當前描述的移動端生態亂象。

三、為什麼要用 X5 核心來改善效果？（替騰訊瀏覽服務 X5 核心官網介紹背書）

騰訊瀏覽服務由QQ瀏覽器團隊出品，致力於優化移動端webview體驗的整套解決方案，使用QQ瀏覽器X5核心SDK和X5雲端服務，解決移動端webview使用過程中出現的一切問題，優化使用者的瀏覽體驗。

X5 SDK是通過呼叫微信/手機QQ/空間的X5核心，解決系統webview相容性差、載入速度慢、功能缺陷等問題，開發接入便捷，大小隻有253K，僅需幾行程式碼，即可解決一切令開發者們頭疼的問題，為使用者提供最優秀的瀏覽體驗。

其相對於系統webview，具有下述明顯優勢：

速度快：相比系統webView的網頁載入速度有近30%的提升。
省流量：雲端優化技術使流量節省20%
更安全：24小時安全問題解決機制
更穩定：經過億級使用者的使用考驗，CRASH率0.15%
整合強大的視訊播放器，支援各種視訊格式直接開啟
適屏排版、字型設定等瀏覽增強功能的提供
Html5更完整支援。
無系統核心的碎片化問題，更少的相容性問題
X5雲端服務是通過雲端技術保證使用者在未裝QQ瀏覽器的情況下同樣可以使用X5核心提供的優秀服務，包括雲加速、雲安全、雲轉換三大功能。

四、小結

關於 Why 這個部分，主要通過分析當前市場環境和開發者所面臨的問題，引出使用 x5 核心必要性討論。
對於前端開發同學而言，考慮如何更加有效的適配儘可能多的裝置，相容更多的使用者環境，打造趨於一致的使用者體驗，在保證高度可用性的情況下，提供更多豐富的互動體驗。
騰訊對 x5 核心的介紹看上去似乎是相當可靠的，但它是什麼，接下來還得一步一步討論關於瀏覽器核心。

WHAT

一、關於瀏覽器核心是什麼？

關於瀏覽器核心的討論可以分成兩部分：渲染引擎(layout engineer 或者 Rendering Engine)和 JS 引擎。
渲染引擎負責取得網頁的內容（HTML、XML、影像等等）、整理訊息（例如加入 CSS 等），以及計算網頁的顯示方式，然後會輸出至顯示器或印表機。瀏覽器的核心的不同對於網頁的語法解釋會有不同，所以渲染的效果也不相同。
JS 引擎則是解析 Javascript 語言，執行 javascript 語言來實現網頁的動態效果。最開始渲染引擎和 JS 引擎並沒有區分的很明確，後來 JS 引擎越來越獨立，核心就傾向於只指渲染引擎。
瀏覽器核心主要的作用是將頁面轉變成視覺化的影像結果，整個過程可以簡化描述成如下步驟：

2013 年以前，常見的瀏覽器核心代表有 Trident（IE），Gecko（firefox），Webkit（Safari chrome 等）以及 Presto（opera)。2013 年，谷歌開始研發 blink 引擎，chrome 28 以後開始使用，而 opera 則放棄了自主研發的 Presto 引擎，投入谷歌懷抱，和谷歌一起研發 blink 引擎，國內各種 chrome系的瀏覽器（360、UC、QQ、百度等等）也紛紛放棄 webkit，投入 blink 的懷抱。

目前國內主流瀏覽器核心，如UC的U3核心、QQ瀏覽器的X5核心以及百度的T5核心在之前的版本都是基於開源核心 Webkit 開發，所以是在 Webkit 的基礎上進行二次優化，在功能與效能上大同小異。而後隨著 chrome 的發展，也逐漸轉為了 blink 核心。

瀏覽器核心渲染引擎的基礎結構

從核心整體結構上看，渲染引擎可以概括為主要包括HTML直譯器、CSS直譯器、佈局和JavaScript引擎、繪圖等：

HTML直譯器：解釋HTML文字的直譯器，主要作用是將HTML文字解釋成DOM(文件物件模型)樹，DOM是一種文件的表示方法.
CSS直譯器：級聯樣式表的直譯器，主要作用是為DOM中各個元素物件計算出樣式資訊，從而為計算最後網頁的佈局提供基礎設施。
佈局：在DOM建立之後，WebKit需要將其中的元素物件同樣式資訊結合起來，計算他們的大小位置等佈局資訊，形成一個能夠表示這所有資訊的內部表示模型。
JavaScript引擎：使用JavaScript程式碼可以修改網頁的內容，也能修改CSS的資訊，JS引擎能夠解釋JS程式碼並通過DOM介面和CSSOM介面來修改網頁內容和樣式資訊，從而改變渲染的結果。
繪圖：使用圖形庫將佈局計算後的各個網頁的節點繪製成圖形結果。

關於Android 瀏覽器核心

前面介紹有提到，在 Android 4.4版本中，原本基於 Android WebKit 的 WebView 實現被換成的Chromium實現，新的 Chromium 內部的渲染引擎改為使用基於 Blink/Content 核心的引擎。

關於 WebKit 和 Chromium 的區別，關鍵在於Google 放棄了之前由 Apple 主導的開源 WebKit，可以說 WebKit 是以前維繫 Google 和 Apple 一個技術交流的重要紐帶。Chromium 是從一個 WebKit 分支基礎上逐漸走上了自研的道路，其採用了自研的 Blink 渲染引擎和 V8 JavaScript 引擎作為新核心重要支撐。

下面基於高低Android系統版本的兩臺測試機型的實際表現，對 WebView 核心在不同系統版本中的效能差異性進行簡單量化：

從對比測試來看，在 Android 4.4 以上系統中基於 Chromium 核心的開發的WebView對比舊版本的 WebKit 效能和相容性方面有了顯著的提升，與之相對的是 Chromium 多程式的特性導致記憶體佔用變大，而且庫檔案也達到了 28M 左右。
下圖是 Chromium 的架構和主要模組示意圖，從圖上可知 Blink 只是其中的一個模組，和它並列的還有眾多的 Chromium 模組，包括 GPU/CommandBuffe r(硬體加速架構)、V8 JavaScript 引擎、沙箱模型、CC(Chromium合成器)、IPC、UI等

二、關於x5 核心有什麼優劣，是否有其他成熟解決方案？

騰訊瀏覽器服務 TBS —— X5核心

騰訊瀏覽服務 TBS 在 2.3 版本中，其 X5 核心就是基於 Android 5.0 WebView Blink核心（M37版本）適配定製優化。

X5 核心號稱適配 Android 全部主流平臺，可以在所有 Android 手機上使用Blink的技術能力，具有更好的 H5/CSS3 支援和效能。裝置有安裝微信、手機QQ、QQ空間即可使用最新的 TBS2.3Blink 核心。其官網提供了x5核心相關引數資訊：

實際對比測試表現：下面是在同一裝置下，QQ 瀏覽器和 Google Chrome 瀏覽器在 H5 支援度對比資料。
裝置：華為 Nexus 6p Android 7.1
測試平臺：https://html5test.com
左：QQ Browser 7.2 X5 核心
右：Chrome Dev 55 Chromium 核心

從實際測試對比來看，對比Chromium 核心實際資料，X5 核心的表現並不及預期。當然測試依據主要是從相容性和 H5 支援度這些技術指標，主要是從技術的維度來考察的。
考慮到實際開發場景中主要是相容性問題比較突出，跑分不是最終目的，所以統一場景才是最重要的。下面看看 x5 的特點，可以做些什麼。

典型行業解決方案介紹——白鷺引擎

目前針對HTML5遊戲的解決方案已經非常多，針對成熟的技術類產品對比，通常有多個維度進行對比，不僅僅是技術層面，還有許多非技術層面的內容，這裡不展開比較。

之所以選擇白鷺引擎來介紹，不僅僅是因為白鷺引擎擁有眾多成熟的產品可以一站式解決而受開發者熱捧，關鍵在於它還跟騰訊 X5 瀏覽器有深度合作，其好處不言而喻，恐怕會是微信遊戲開發不二之選。
白鷺Egret引擎是一個開源免費的遊戲框架，用於構建二維遊戲、演示程式和其他圖形介面互動應用等。Egret使用TypeScript指令碼語言開發。當遊戲完成最終的打包後，可以將程式轉換為HTML5遊戲。實現跨平臺特性。

Egret Runtime 是白鷺一款支援3D的HTML5遊戲加速器，解決低端機對HTML5標準支援不佳、體驗差的弊端，適配不同的系統讓HTML5遊戲效果媲美原生遊戲。跟騰訊瀏覽器 x5的合作，直接支援了H5遊戲執行所需的底層功能，從根本上解決了碎片化和效能問題。

騰訊瀏覽器 X5 已經解決了 HTML5 遊戲在各個應用場景的執行問題，而跟合作白鷺 Egret Runtime 又可以大幅優化終端體驗。根據官網介紹，在有 Egret Rumtime 加速的情況下，HTML5遊戲會有3-5倍的效能提升，對比 PhoneGAP 方案約有30倍的效能提升，從而使 HTML5 遊戲接近原生遊戲的體驗。

HOW

一、如何藉助 x5 核心來進行實踐？

通過騰訊瀏覽服務官網提供的 X5 核心接入指南，將提供的核心服務的sdk整合到應用中。由於 x5 核心是在 Android 原生 WebView 基礎上的二次開發，所以其提供的在開發者呼叫介面上和原生保持一致，相容原生 webview 的各種屬性設定，如果之前使用原始 webview 的幾乎時可以無縫替換。

雖然對於主流移動應用開發模式的討論已經是老生常談，之前熱議的 Hybrid 混合開發模式也被現在 ReactNative 、Weex 搶了風頭。關鍵還是越來越多的場景需要高度動態化的內容，保持對使用者友好且統一的體驗同時，考慮更多的輕便快捷互動、快速迭代更新的特性。

脫離實際的應用場景來討論哪一種開發模式孰優孰劣沒有意義，關鍵還是要貼合場景選擇最適合的，所以這裡對三種開發模式的相關細節不展開討論，只針對開發有 Web 類場景需求的情況進行考慮：

相比Native App，Web 體驗中受限於以上5個因素：網路環境，渲染效能，平臺特性，受限於瀏覽器核心，系統限制。

因此解決這些問題的關鍵在於提供一個良好的基礎執行環境和一個成熟的完整解決方案。藉助 x5 核心可以改善執行環境，到達互動趨於一致性。

關於“一致性”經常被理解為同一個應用在各種平臺和場景下要有一致性的體驗。但是在移動平臺開發過程中，“一致性”應該是App視覺和互動習慣與其執行平臺的習慣保持一致，使用者整體體驗保持一致。而 Web 開發“一次開發，跨平臺執行”的特性與此存在一定程度上的衝突是合理的。

如上所述，藉助 x5 核心的來進行實踐的目的也就是如此。下面就按照這個設計思路就來進行具體的 x5 嵌入實施過程，從技術角度切入後，通過編寫Demo試驗比對實際效果，來判斷帶來怎樣效益的提升。

二、要怎樣進行具體的實施過程，解決那些已有的問題？

具體實施過程大致分為嵌入整合和實際功能應用兩個部分。

整合 X5 核心

騰訊瀏覽服務 TBS 官網提供了 X5 核心SDK分為完整版和精簡版。精簡版不可獨立下載x5核心，只能共享使用微信或手Q的x5核心，JAR包約190Kb。而完整版可獨立下載x5核心，也可共享使用微信或手Q的x5核心，JAR包約280Kb。

由於X5核心的API介面和系統的保持高度一致，因此實際的使用方式與使用原生進行開發一樣。關於實際的編碼過程不展開描述，具體參照官方的接入文件進行。

x5整合過程中發現了下面有幾個特點：

如果有安裝QQ 或微信（國內釋出的版本），並且已經開啟過內建- web，下拉網頁頂部空白處會出現了由x5核心提供技術，表示應用是可以使用共享的x5核心。
如果沒有安裝qq微信，應用不可以可以共享使用微信或 QQ 中的 x5 核心，但是不能共享使用其他整合了x5應用的核心，只能使用完整版核心sdk包。
有些裝置首次啟動無法啟用 x5 核心，需要程式重啟或首次啟動長耗時等待以後才能正常使用 x5 核心。
當無法使用 x5 核心，騰訊瀏覽服務 TBS SDK 會預設使用系統內建的webview，兩者介面保持高度一致。
x5對視訊播放的支援很好，可全屏效果控制方便，騰訊也提供了配套的sdk後臺服務。

實際功能應用（X5EngineDemo 示例程式）

用QQ瀏覽器 X5 核心SDK和 X5 雲端服務，解決移動端 webview 使用過程中出現困擾開發者需要適配相容性的問題，提升效能的同時優化使用者的瀏覽體驗，有利於統一使用者裝置基礎環境。

帶來的效益，主要是減少適配難度，提升產品相容性和表現效果。成熟的產品和廣泛的使用者人群，提升保障同時減少出現不必要的麻煩，降低開發成本。

在開放中有使用Html5的Video控制元件來播放視訊的情況，為了舉例說明使用 x5 可以帶來的效益。下面就從展示網頁這個角度切入，對比看看 X5 核心能帶來的什麼樣的效果：

從上圖測試可以看出，對於首次載入網頁，使用systemWebView進行網頁載入耗時要優於x5，針對有開啟快取的情況喜愛，多次開啟相同網頁情況，x5的耗時是略比系統的少。

H5 遊戲測試

如下圖所示，在測試全屏H5遊戲效果時，對比發現兩者在高硬體配置的裝置上體驗差異不大，x5的幀率比較穩定。在某些低配置和低版本系統上執行時，x5的表現要優於系統瀏覽器核心，而且適配性更強。

播放網頁視訊

如下圖所示，測試騰訊視訊網站，發現使用系統 WebView 存在視訊載入錯誤的問題，而使用了 X5 核心的則是可以正常播放。

但是，接入 x5 核心的成本也是需要考慮，開發者對於 X5 的評價也褒貶不一。
下面測試嗶哩嗶哩彈幕網站的效果，在使用系統 webview 的情況下，是採用了嗶哩嗶哩帶有彈幕的播放器，可以正常播放的同時也支援彈幕的顯示。而採用了X5核心進行播放時，則自動替換成 x5 自帶的播放器，可以看到loading顯示的也是x5提供的介面，所以導致彈幕無法正常展示。

下面再看看全屏模式下的播放，x5 對比原生區別很明顯。而在測試 H5 遊戲時，x5是能夠正常音畫同步，而系統webview則沒有正常背景音樂，幀率偶爾也會低了10左右，這些也都是很多開發者選擇 x5 的重要因素。

Native與JS互動效果測試（JsBridge）

首先我們來了解一下為什麼要使用JSBridge，在開發中，為了追求開發的效率以及移植的便利性，一些展示性強的頁面我們會偏向於使用 H5 來完成，功能性強的頁面我們會偏向於使用 Native 來完成。
而一旦使用了 H5，為了在 H5 中儘可能的得到native的體驗，我們 Native 層需要暴露一些方法給js呼叫，比如，彈Toast提醒，彈Dialog，分享等等，有時候甚至把h5的網路請求放著native去完成，而JSBridge做得好的一個典型就是微信，微信給開發者提供了JSSDK，該SDK中暴露了很多微信native層的方法，比如支付，定位等。

測試通過JsBridge進行webview中的js程式碼呼叫本地java介面的效果，試驗進行輔助sdk開發的可行性。X5 核心也提供了js介面安全調研機制來保證webview本身的安全漏洞問題，而且也會及時響應 Google 對於瀏覽器核心漏洞的修復。

三、如何評判引入 x5 核心後帶來的提升？

** 總的來說，關於 X5 引入帶來的提升，可以從下面的維度去討論。在之前的對比分析中依舊有描述相關特性，而且關於實際表現很難定性指標依據，這裡不再重複介紹。具體可以參照 Demo 中的實際使用效果，對比 X5 核心帶來的提升效果。**

頁面載入速度（部分頁面預載入快取控制）
介面使用流暢度（遊戲幀率，效果穩定性）
顯示相容性（頁面相容性，多機型適配，介面效果一致性，視訊播放等）
互動和特性支援（js支援豐富友好程度，新的HTML特性）
穩定性和安全性（安全漏洞補丁修復）
可持續性（迭代更新支援）

總結

通過預研X5核心，梳理了瀏覽器核心相關的概念，按照典型的 2W1H 模型對比分析X5核心其技術特性和實際應用場景，在技術試驗方面從多個維度來討論可應用性。

其實從前面的描述可以知道，騰訊推出 X5 核心主要是為了解決Android終端裝置的差異性所造成的前端頁面適配和瀏覽體驗問題，意在打造一個可以讓開發者減少適配工作成本，提升使用者體驗的一致性，為移動應用提供基礎瀏覽器服務。

根據調研過程中對瀏覽器核心技術的學習，以及對市場成熟應用場景的分析，基於 X5 核心sdk，我們可以做些什麼？

如果考慮開發 H5 遊戲引擎，這個行業中已經太多的成熟解決方案，而且使用者普遍對H5遊戲的接受程度還有待提高。像微信擁有很好的流量入口，本來是擴充H5遊戲的好平臺，但是自身加以了嚴格限制，禁止朋友圈公眾號轉發H5遊戲之類的。

假設基於x5做二次封裝，打造自己的sdk。但是 X5 跟系統 webview 介面保持高度一致，二次封裝只能是增加開發者使用難度。而且瀏覽器核心相當難以維護，因為快速迭代導致直接整合的成本太高。

如果做整合輔助類sdk，類似微信的JS-SDK，這是微信公眾平臺面向網頁開發者提供的基於微信內的網頁開發工具包，目的是減少網頁開發者使用 js 與微信App Native互動的成本。這裡設想一個場景來考慮：
比如有這樣一個場景，一個網頁開發者打算開發一款遊戲或者應用，但是考慮到開發成本和效益，直接通過實現H5介面後包成殼後，作為 App 來上架釋出。這樣實現快速開發的同時，又可以進行動態化內容可以快速更新，減少傳統 App 迭代更新的各種弊端。

現在有很多類似白鷺引擎之類的廠商提供了一整套的解決方案，但是連結 H5 和 Native相關的設想確並不是很多。比如 H5 開發者使用native平臺本身的特性來進行互動設計的成本還是太大。雖然有類似 JsBridge 手段，但是同時兼顧js和native開發，需要網頁開發者更大的成本，而怎麼提供更豐富流暢的H5互動體驗支援就是可以嘗試去解決的問題。

總之，可以利用 x5 的適配性強的特點展開更多豐富互動設計和提升使用者的設想，把瀏覽器核心這項基礎性的底層服務應用得更好。