標籤：chrome chromium 瀏覽器
Chromium Android WebView是Chromium專為Android WebView提供一個對Content的封裝層。從整體上來看可以理解為一個特殊化的Embedder, 功能可以概括為： 1. 對Content和部分Browser Components封裝到Java實現，供AOSP WebView調用實現WebView功能。 2. 實現Android WebView使用的單進程渲染架構。 3. 配置網路模組，並實現特定需要的scheme解析。
Content作為一個能力提供者，所以它的API也被稱為SPI, 即Service Provider Interface。CAW一方面要調用Content的介面執行操作，另一方面擴充Content需要Embedder實現的介面(Client類和Observer類)。
其架構如下:
其內部包括了6個部分:native & java
：封裝CAW為java實現，供上層的AOSP WebView使用。
ContentMainDelegate (AwMainDelegate): 像其它Embedder一個，為配合Content的啟動管理者ContentMainRunner提供啟動功能。
Component Clients: 為使用到的Browser Components提供用戶端代碼。比如AutoFill的用戶端AwAutofillClient, 還有一個是WebContentsDelegate。
Renderer: 則是負責利用Renderer進程的擴充機制(基本上都是Observers), 對Renderer進行幹預。
Browser:負責實現Browser進程的商務邏輯，其中也包括了net和renderer_host兩個子項目。
*CAW同時需要使用到網路模組。網路模組本身是一個公用的基礎組件。
*以Renderer/Browser的目錄命名來區分針對不同進程下功能的實現，這在其它模組裡也是普遍使用的方式，如Components。
代碼的命名空間都在android_webview下。
ContentMainDelegate代碼在src/android_webview/lib/main。
ContentMainDelegate是與Content互動的中心介面，負責具體的執行啟動過程，以及按需要建立出與不同進程/線程互動的四個Clients，負責Content初化配置。
主要功能包括: 1. 對應上面類圖中前三個函數。它可以幹開機前過程，特別是在啟動過程指定了一些功能的開關。比如禁用了File System API, WebRTC hardware decoding等。以下是啟動的流程:
2. 對應上面類圖中後四個函數。可以讓Embedder自訂Content的行為。比如ContentRendererClient和ContentBrowserClient, 分別是針對Renderer和Browser進程的擴充機制。下面會再展開。
API (native & java)目錄: src/android_webview/java 和src/android_webview/nativeAOSP WebView對外提供一個WebView控制項，而CAW則負責提供AwContents封裝WebView所需要的Contents功能。如所示：
另一個樣本CookieManager，則是實現到net::CookieMonster的橋接:
主要的介面類包括負責載入native library等初始化操作的AwBrowserProcess， 以及圍繞著AwContents的幾個核心類, 既有直接註冊於Content層的Observer實現的(AwContentsClient)，也有通過native操作Content的(AwSettings):
其中AwContentsClient是一個組合的結果，來自於Content層的兩個重要通知介面ConentViewClient,ContentVideoViewClient, WebContentsObserver都會轉到AwContentsClient，再提供給AOSP層。AwBrowserContext儲存Browser所需要的一些對象，如SharedPreferences (Android的一個基於XML的儲存機制), CookieManager等。
(SharedPreferences主要用於AwGeolocationPermissions儲存在各個網域名稱下的開關設定，是否可以整合到統一的Settings? 或者Global Settings參考SharedPreferences來實現?)
另外在WebView中定義的一些相關類，都可以在這層找到對應的實現。 android.webview.WebStorage <——> AwQuotaManagerBridge <—JNI—> storage::QuotaManager android.webview.CookieManager <——> AwCookieManager <—JNI—>net::CookieMonster
Renderer互動的手段主要基於Renderer的擴充，包括Observer, Client和IPC機制。 涉及的類圖:
各類的職責可以從其方法定義上就可以看出來，不再贅述。
可以反應出其中RenderViewObserver的機制：
*其中AwRenderViewHostExt是類似的類，屬於在Browser進程的實現。 主要的時序圖:
BrowserCAW的Browser模組實現了CAW的大部分商務邏輯，包括對Content的封裝調用，以及單進程渲染架構的實現。渲染的部分和對網路模組的封裝在下面另外說明。
對Content的封裝主要是對content API中Browser進程部分進行封裝、實現，是作為一個Embedder必需的部分，涉及的類比較多，其中以AwContentBrowserClient為核心。(回顧一下AwMainDelegate那張類圖。)
渲染來自再談Chromium WebView硬體渲染模式的演化，其中1&2可以反應出CAW需要負責WebView onDraw操作與Synchronous Compositor之間的聯絡。
上面的數字已經說明了整個繪製過程。簡化來看CAW的渲染基於Android View的onDraw()操作，再調回到Android View的ViewRoot。
以下為主要類圖:
網路
主要類圖如下:
AwNetworkDelegate在請求的Header中添加X-Requested-With來標識是當前包所發送的請求。AwURLRequestContextGetter除了初始化網路上下文(包括指定Android特定scheme的解析器.)，還會將BrowserThread指定為網路線程。
當有第一次擷取URLRequestContext時就會觸發建立建立過程，建立網路上下文環境。然後就可以基於它發起載入請求。如所示:
Android特別的schemes處理中net::URLRequestInterceptingJobFactory使用層層嵌套的Job factory組成針不同schemes的解析鏈。如:
要點: 1. 實現了AndroidStreamReaderURLRequestJob支援以Java Stream的方法讀取資料的請求。 2. AndroidRequestInterceptorBase實現任務控制，並在AwURLRequestContextGetter向網路層註冊分別針對content:和asset (file:///android_asset/ and file:///android_res/ )的協議解譯器。
CAW對Components的依賴
轉載請註明出處: http://blog.csdn.net/horkychen
[Chromium] Chromium Android WebView層的設計
