理解WebKit和Chromium: Android 4.4 上的Chromium WebView

轉載請註明原文地址：http://blog.csdn.net/milado_nju

## 概述

相信讀者已經注意到了，在最新的Android 4.4 Kitkat版本中，本來基於Android WebKit的WebView實現被換成基於Chromium的WebView實現。在前面的章節中，筆者也介紹過基於Chromium的WebView實現即將成爲Android系統上的缺省實現方式，筆者也一直期待這一重大轉變，如今它真的發生了。而以前基於WebView接口的應用程序甚至能夠直接工做在該實現上而不須要任何特別的改變。舉個例子來講，Android系統上的缺省瀏覽器（AOSP中的瀏覽器），能夠不須要任何改變直接工做在新的實現上。

WebView是一種嵌入式的編程接口，可以提供Java接口給開發者來使用該模塊來渲染網頁。如今的WebView只是一個接口類，經過一些內部設計的改變，其具體的實現能夠在以前的Android WebKit和Chromium之間進行切換。新的Chromium實現專一於提供一致性的接口（爲了兼容之前的應用），而內部的渲染引擎改成使用基於Blink/Content內核的引擎，這實現不論是從功能上仍是性能來說，都帶來巨大的提高。爲了支持WebView的工做方式，Chromium仍是作了很多的改變的，例如前面提到的進程模型，渲染方式等，下面一一對他們做介紹。

## 層次結構

在Android 4.4中，基於Chromium項目的WebView千呼萬喚始出來。爲了支持歷史遺留的接口，Chromium仍是作了很大改變的，讓筆者結合下圖的層次結構來解釋基本的過程。

上圖主要有四個部分，其中跟WebView相關的主要是上面三個部分，首先是WebView接口部分，它提供對外編程接口，同時它的內部實現能夠基於橋接代碼，也就是第二個部分。橋接部分的代碼主要有兩個做用，其一是實現WebView接口對實現的調用，第二是調用下面一層的代碼，這裏面有個重要的部分就是須要設置AwContents爲了繪圖而須要設置的兩組函數數組，這個在渲染部分介紹。它的代碼能夠在frameworks/webview/chromium部分找到。以上兩個部分都是AOSP部分代碼，而第三個部分是AwContents是在Chromium項目中的，主要是構建被橋接代碼使用的接口，這一部分主要基於Content接口，裏面有不少不一樣於Chrome瀏覽器的實現。Android的開源代碼爲了編譯上的方面，直接將Chromium 版本30代碼包含到external/chromium_org目錄中，有興趣的讀者能夠自行查看。

## 同Chrome瀏覽器的比較

同Chrome瀏覽器比較，Chromium WebView在不少部分很是不同，例如開源與否、HTML5功能、版本支持、進程模型、渲染方式等。下表分析了這兩者的主要區別。

	Chromium WebView	Chrome瀏覽器（Android版）
是否開源	所有開源，包括內核，橋接層等	Java層部分的代碼，包括用戶界面的代碼是閉源的，也就是說開發者是沒有辦法基於Chrome瀏覽器定製新瀏覽器，只能夠基於Content層
HTML5功能	目前不支持WebGL，WebRTC，WebAudio等	支持絕大多數HTML5功能（HTML5test得分超過450），包括WebGL，WebRTC，WebAudio等
版本	僅能工做在Android4.4上，並且依賴於系統內部的函數，只能同Android AOSP一塊兒編譯，目前是Chromium 30的版本	能工做在>=Android 4.0，並且不須要依賴Android系統內部的函數。Chromium方面是跟隨最新的代碼。
進程模型	僅單進程	支持多進程和單進程（不過，目前單進程工做還有些問題）
渲染方式	支持軟件渲染和硬件加速渲染方式	目前只是硬件加速渲染方式

## 渲染方式

至於WebView內部所使用的Chromium實現是採用硬件加速渲染仍是軟件渲染，這裏仍是比較複雜的。根據Android的View結構，WebView的內容須要經過一個onDraw(Canvas c)來完成繪製。爲了將Chromium渲染網頁的結果繪製到該Canvas中，須要兩組繪圖函數組，第一組用來軟件渲染，第二組用來硬件加速渲染。而這兩組函數須要使用Android內部函數，這決定了目前WebView只能同Android AOSP代碼一塊兒編譯，而不能像應用程序同樣，只是依賴於Android SDK/NDK來編譯。下圖是當用戶界面或者網頁須要繪製的時候，繪圖的基本過程。

這裏Chromium的合成器具備兩種能力，就是包含支持軟件渲染的軟件渲染器和硬件加速渲染的渲染器。當用戶界面所對應的畫布（canvas）是硬件加速的話，那麼內部採用硬件渲染機制。若是不是硬件加速的話，那麼採用軟件渲染機制。當用戶的界面設置爲硬件加速的時候（開發者能夠在應用程序的AndroidManifest.xml中設置屬性android:hardwareAccelerated="true"），那麼用戶界面對應的畫布即爲硬件加速，不然即爲軟件渲染方式。因此，具體Chromium WebView採用什麼樣的方式，取決於調用WebView的應用程序的設置方式。

值得提出的是，這裏的硬件加速機制同Chrome瀏覽器的硬件加速機制是不一致的，由於Chrome瀏覽器爲渲染網頁使用的控件是Android的SurfaceView，根據Android系統的說明，SurfaceView是能夠在不一樣的線程來繪製的(One of the purposes of this class is to provide a surface in which a secondary thread can render into the screen)，請讀者閱讀這裏瞭解背後的原理http://developer.android.com/reference/android/view/SurfaceView.html。由此，Chrome瀏覽器是首先獲取SurfaceView的Surface對象的句柄（ID），而後由Chrome瀏覽器的GPU線程來繪製網頁。這樣，網頁的渲染工做同主線程徹底隔離開來了，不會由於網頁的渲染而阻礙用戶界面的響應。

而在Chromium WebView的實現中，由於WebView不是基於SurfaceView類的（由於歷史遺留問題），因此，繪製內容到畫布上必須在主線程來操做，有鑑於此，這些渲染任務只能在主線程上工做，可能在某種程度上會阻礙用戶界面的響應，這是一個重大缺陷。根據筆者的數據來看，目前它的性能同Chrome瀏覽器/Content Shell也有必定的差距，考慮使用它的讀者可能須要權衡一下。

由於WebView採用單進程的渲染方式並省略了一些共享內存和進程間通訊的基礎設備，因此能夠節省一些內存使用空間，Chromium的官方也給出了一些數據，例如打開一個空白頁，WebView目前只是須要33MB內存，而Chrome瀏覽器須要大概49MB，而單進程模式的Chrome瀏覽器須要大概45MB內存，還有更多詳細的數據，有興趣的讀者能夠進行參考和一些分析。

## 基於WebView的瀏覽器和基於Content接口的瀏覽器

目前Android默認瀏覽器（Stock Browser）是基於WebView接口，由於ChromiumWebView的實現被直接用於默認瀏覽器中，因此繼承了ChromiumWebView的一些缺點，例如多標籤頁也只是在同一進程中工做，沒有沙箱模型的支持等，性能也要差很多。而Chrome瀏覽器的Android版是基於Content接口的多進程方式工做的，於是保留了穩定性好，安全等好處。

## 參考資料

1. https://developers.google.com/chrome/mobile/docs/webview/overview

2. https://android.googlesource.com/platform/external/chromium_org/

by yongsheng@chromium.org