瀏覽器探究——執(zhí)行網(wǎng)頁跳轉(zhuǎn)
Main線程中執(zhí)行。
UrlInputView
控件UrlInputView執(zhí)行OnEditorAction->finishInput
/**
*url/search input view
*handling suggestions
*/
public class UrlInputView extendsAutoCompleteTextView
implements OnEditorActionListener,
CompletionListener, OnItemClickListener, TextWatcher
由此可見，UrlInputView即輸入網(wǎng)址的那個控件，該控件包括輸入URL和執(zhí)行搜索輸入。
Controller
在經(jīng)過UrlInputView的處理后，會調(diào)用Controller.handleNewIntent。
Controller是瀏覽器中最重要的類，作為整個瀏覽器的主控類。Controller中有IntentHandler，這里會調(diào)用IntentHandler.onNewIntent
IntentHandler
//Handle all browser related intents
這里對一些特殊的URL做處理這里還包含了一些debug信息，比如”about:debug.dom.file"這種形式的網(wǎng)址。如果是普通的 url，不需要做特殊處理，則執(zhí)行到最后執(zhí)行Controller.loadUrlDataIn，即經(jīng)過了IntentHandler后又回到了 Controller。
Controller
/**
* Load UrlData into a Tab and update the title bar to reflect the new
* load. Call this instead ofUrlData.loadIn directly.
* @param t The Tab used to load.
* @param data The UrlData being loaded.
*/
經(jīng)過簡單的處理，會把要加載的url作為參數(shù)調(diào)用被顯示的tab，即執(zhí)行Tab.loadUrl。這樣看來Controller還只是個橋梁的作 用，把從UrlInputView得到的url，交給IntentHandler做處理，然后再把url交給Tab做實際的加載。
Tab
//Class for maintaining Tabs with a mainWebView and a subwindow.
Tab作為一個窗口的抽象概念而存在，對一個窗口的操作都需要通過Tab來進入。另外有個TabControl用來管理所有的Tab.
執(zhí)行語句mMainView.loadUrl。這個mMainView是個WebView。從這終于進入了framework的webkit層了。
WebView
WebView作為Tab的核心控件，負責網(wǎng)頁的真正的加載，顯示等操作，是framework/webkit中最主要的類。通過Tab來找到WebView.
在WebView.loadUrl->WebView.loadUrlImpl中會向WebViewCore發(fā)消息，
WebViewCore
該類在一個獨立的線程中運行，該類主要通過Message，Handler的機制在WebView與WebViewCore之間通訊的，這里 WebView是在Main線程中，而WebViewCore是在單獨的 WebViewCoreThread線程中。WebViewCore是 framework/webkit核心類，它在單獨的線程中來接收消息，每個消息相當于一個請求的任務(wù)，而這個WebViewCore相當于一個服務(wù)，它 在消息循環(huán)中不停的接收任務(wù)（消息），然后處理任務(wù)，然后再接收下一個任務(wù)（消息）。任務(wù)的執(zhí)行很多是通過jni調(diào)用c層webkit來操作的。在c層 webkit有webkit/Source/WebKit/android/jni/WebViewCore.cpp與該java層的 WebViewCore對應(yīng)。即這個WebViewCore是java層與c層的一個主要橋梁。
在WebView.loadUrlImpl在執(zhí)行了mWebViewCore.sendMessage(EventHub.LOAD_URL, arg);則WebViewCore接收到LOAD_URL任務(wù)，執(zhí)行對它的處理。
WebViewCore中有BrowserFrame成員
BrowserFrame
BrowserFrame extends Handler它也有很多JNI與C層的webkit的Webkit/Source/WebKit/android/jni /WebCoreFrameBridge.cpp對應(yīng)。它用來處理頁面的具體情況，即Frame，這個Frame是一個具體的頁面的概念。
WebViewCore.loadUrl會調(diào)用BrowserFrame.loadUrl。BrowserFrame會調(diào)用到WebCoreFrameBridge.cpp的LoadUrl。
這里略去c層的處理部分。
WebCoreFrameBridge.cpp的LoadUrl執(zhí)行后會執(zhí)行到WebCoreFrameBridge.cpp的loadStarted，這里又會回調(diào)BrowserFrame.loadStarted函數(shù)。
/**
* native callback
* Indicates the beginning of a new load.
* This method will be called once for the main frame.
*/
即通過BrowserFrame的loadUrl在c層做處理后，又回調(diào)到BrowserFrame的loadStarted。
這里在理一下，主線程中有Tab，Tab里有WebView。即WebView也是運行在主線程的。而WebView里有WebViewCore，WebViewCore又是運行在一個單獨的線程里的。
那么多個WebView是否就對應(yīng)多個WebViewCore和多個WebViewCore線程呢？
看下WebView，WebView的構(gòu)造函數(shù)中會mWebViewCore= new WebViewCore(context, this, mCallbackProxy, javaScriptInterfaces);創(chuàng)建了WebViewCore對象，即每個WebView都有個WebViewCore對象。但是 WebViewCore中的WebCoreThread是一個靜態(tài)的，即一個單例的。而這個WebCoreThread中運行的 privatestatic Handler sWebCoreHandler;也是個靜態(tài)的。
由此可見WebViewCore類本身就是個外殼，真正處理任務(wù)的是WebCoreThread及其里面的sWebCoreHandler，這個真 正處理任務(wù)的是靜態(tài)的，只有一份，WebViewCore這個外殼只是溝通webView與WebCoreThread的橋梁，相當于一個代理類。是 WebCoreThread提供給外面的處理接口。
那么BrowserFrame呢？在WebViewCore的構(gòu)造最后會發(fā)送一個INITIALIZE的消息給 WebCoreThread，WebCoreThread接收到后會執(zhí)行WebViewCore.initialize，這個函數(shù)會構(gòu)造 mrowserFrame。即每次構(gòu)造WebViewCore時同樣會構(gòu)造一個BrowserFrame。但是為什么不在主線程中創(chuàng)建呢？一方面它是繼承 自Handler，這個Handler需要在WebViewCoreThread線程中運行，所以需要在該線程來創(chuàng)建。另一方面在它的構(gòu)造中需要創(chuàng)建 JWebCoreJavaBridge這個是C層的類，貌似這個類也需要在WebViewCoreThread線程中創(chuàng)建和銷毀才行。
由上分析可知，WebView包含一個WebViewCore，WebViewCore包含一個BrowserFrame。多個 WebViewCore共同對應(yīng)唯一的一個WebCoreThread。WebViewCore只是個外殼，WebCoreThread作為任務(wù)的處 理，WebCoreThread主要就是個大Handler不停的處理接收到的任務(wù)，WebCoreThread會調(diào)用很多jni來調(diào)用webkit接 口，BrowserFrame也有很多jni來調(diào)用webkit接口。由他們的組成情況又可知WebCoreThread直接調(diào)的jni是多個 WebView共同的，即不跟具體的WebView相關(guān)，而通過BrowserFrame調(diào)用的則跟一個具體的WebView相關(guān)了。
CallBackProxy
/**
*This class is a proxy class for handling WebCore -> UI thread messaging. All
*the callback functions are called from the WebCore thread and messages are
*posted to the UI thread for the actual client callback.
*/
/*
*This class is created in the UI thread so its handler and any private classes
*that extend Handler will operate in the UI thread.
*/
class CallbackProxy extends Handler {
另外還有個類CallBackProxy。它存在于WebView，WebViewCore，BrowserFrame中。在WebView構(gòu)造函 數(shù)中創(chuàng)建，并在WebViewCore和BrowserFrame構(gòu)造函數(shù)中作為參數(shù)傳入并賦值給它們內(nèi)部的引用。可見CallBackProxy是 WebViewCore和BrowserFrame向WebView回調(diào)的橋梁。
CallBackProxy是一個Handler，它在主線程中被創(chuàng)建，即WebViewCore和BrowserFrame會通過發(fā)消息的方式將 需求傳遞到主線程的CallBackProxy中，CallBackProxy的事件處理循環(huán)會執(zhí)行相應(yīng)的處理。可見主線程中WebView通過 WebViewCore發(fā)消息給WebViewCoreThread線程執(zhí)行操作，WebViewCoreThread線程又會通過 CallBackProxy回調(diào)消息給主線程執(zhí)行處理。
再回到BrowserFrame.loadStarted處。
BrowserFrame.loadStarted會調(diào)用 CallBackProxy.onPageStarted，CallBackProxy.onPageStarted中會給發(fā)PAGE_STARTED消 息，主線程中的CallBackProxy的handleMessage會執(zhí)行處理。在處理時會執(zhí)行 WebViewClient.onPageStarted。
WebViewClient
mWebViewClient本身只是提供一個接口基類，Tab中private finalWebViewClient mWebViewClient = new WebViewClient()
// WebViewClient implementation for themain WebView
//Set the WebViewClient that will receivevarious notifications and requests. This will replace the current handler.
這個WebViewClient會傳給Tab中的WebView的CallbackProxy。這個WebViewClient會讓CallbackProxy返回信息或回調(diào)處理給Tab。
回到WebViewClient.onPageStarted，這里做了一些判斷處理后，調(diào)用WebViewController.onPageStarted。
WebViewController
//WebView aspect of the controller
public interface WebViewController
在Tab的構(gòu)造時，WebViewController會作為參數(shù)傳入，并設(shè)置給Tab。那么Tab中的WebViewController到底是什么？Tab是在TabController中創(chuàng)建的，而Tab構(gòu)造時傳入的是Controller。
public class Controller implementsWebViewController, UiController
由此可見Tab中的WebViewController其實就是對應(yīng)Controller。只是通過WebViewController接口作為引用的。即Tab中只關(guān)心Controller的WebViewController接口部分。
這樣就可以看出BrowserFrame通過消息與主線程中的CallbackProxy處理循環(huán)關(guān)聯(lián)，CallbackProxy又通過 WebViewClient與Tab關(guān)聯(lián)，回調(diào)了Tab提供的接口，而Tab又通過WebViewController接口，調(diào)用了Controller 這個核心類的函數(shù)。即調(diào)用到WebViewController.onPageStarted，也即是 Controller.onPageStarted.
Controller.onPageStarted中一個主要的處理是
if (!mNetworkHandler.isNetworkUp()) { view.setNetworkAvailable(false); }這里判斷網(wǎng)絡(luò)是否是激活狀態(tài)，如果不是激活 狀態(tài)則執(zhí)行WebView.SetNetworkAvailable(Boolean networkUp)
/** * Inform WebView ofthe network state. This is used to set * the JavaScript property window.navigator.isOnline and * generates the online/offline event asspecified in HTML5, sec. 5.7.7 *@param networkUp boolean indicating if network is available */
該函數(shù)其實就是像WebViewCore發(fā)送SET_NETWORK_STATE消息，好吧，又回到了WebViewCoreThread線程了， 處理的方式是直接BrowserFrame.sJavaBridge.setNetworkOnLine。這個函數(shù)是個jni函數(shù)，其調(diào)用的是c層 JavaBridge的函數(shù)。這個jni函數(shù)主要就是通知c層WebCore網(wǎng)路狀態(tài)已經(jīng)變化，并把最新的網(wǎng)絡(luò)狀態(tài)告訴WebCore。
由此可見WebView.setNetworkAvailable還是個挺重要的函數(shù)，通過它才能告訴底層網(wǎng)絡(luò)的狀態(tài)。
那么額外看下網(wǎng)絡(luò)狀態(tài)如何獲取并傳遞的，在loadUrl發(fā)起加載url這塊判斷了一次，即當無網(wǎng)絡(luò)時主動通知一次。其他的呢？
在NetworkStateHandler中會注冊一個BroadcastReceiver，該receiver會關(guān)注 ConnectivityManager.CONNECTIVITY_ACTION廣播，該廣播是在網(wǎng)絡(luò)發(fā)生連接變化時被發(fā)出，該receiver在接收 到網(wǎng)絡(luò)連接變化的廣播后，會查詢當前的連接情況，然后執(zhí)行NetworkStarteHandler.onNetworkToggle，這個函數(shù)里面就會 調(diào)用WebView.setNetworkAvailable，也即跟上述描述的那樣，給WebViewCoreThread線程發(fā)消息，通知c層 WebCore網(wǎng)絡(luò)的最新狀態(tài)。
這樣就清楚了，網(wǎng)絡(luò)廣播時會通知C層最新狀態(tài)，在執(zhí)行l(wèi)oadUrl時，如果網(wǎng)絡(luò)不可用也會通知C層網(wǎng)絡(luò)最新狀態(tài)。
這里先跨過Controller.onPageStarte的其他處理過程。此次任務(wù)處理完畢。
此時WebViewCoreThread線程中BrowserFrame仍然處于c層的LoadUrl中，此時的調(diào)用棧為:
BrowserFrame.nativeLoadUrl
BrowserFrame.loadUrl
WebViewCore.loadUrl
這里又會回調(diào)BrowserFrame.shouldInterceptRequest，它會調(diào)用BrowserFrame.inputStreamForAndroidResource函數(shù)
/**
* Get the InputStream for an Android resource
* There are three different kinds of android resources:
* - file:///android_res
* - file:///android_asset
* - content://
* @param url The url to load.
* @return An InputStream to the android resource
*/
這個函數(shù)會對幾種特殊的url做不同的處理，當輸入一個標準的http的url時，該函數(shù)不起什么作用。
BrowserFrame.shouldInterceptReques接下來會調(diào)用 CallbackProxy.shouldInterceptRequest，看到調(diào)用CallbackProxy的函數(shù)，基本上就是要發(fā)消息給主線程讓 主線程去處理任務(wù)了，這里發(fā)送了LOAD_RESOURCE消息，主線程接收后執(zhí)行WebViewClient.onLoadResource。回到 BrowserFrame.nativeLoadUrl處，此時這個jni的函數(shù)終于執(zhí)行完畢，也不再回調(diào)其他函數(shù)了，該函數(shù)完 成，WebViewCoreThread線程執(zhí)行完LoadUrl的處理。
當沒有連接網(wǎng)絡(luò)時，有個單獨的線程會執(zhí)行JWebCoreJavaBridge.signalServiceFuncPtrQueue這個JNI的 回調(diào)函數(shù)，該回調(diào)函數(shù)會發(fā)FYBCPTR_MESSAGE消息給WebViewCoreThread線程，但處理函數(shù)是 JWebCoreJavaBridge.handle，由此可見WebViewCoreThread線程不僅僅有一個Handler在處理事件.
JWebCoreJavaBridge
JWebCoreJavaBridge extends Handler 可見JWebCoreJavaBridge也是個Handler也是在WebViewCoreThread線程中運行的，只是發(fā)送消息的線程不是主線程， 是另一個單獨的線程，并且消息的發(fā)送來源是JNI的回調(diào)。
JWebCoreJavaBridge對應(yīng)的JNI是webkit/Source/WebKit/android/jni/JavaBridge.cpp的函數(shù)。
JWebCoreJavaBridge處理FYBCPTR_MESSAGE消息時會調(diào)用一個JNI函數(shù)，在JNI函數(shù)里又會回調(diào)BrowserFrame.reportError。
又是跟上面類似的流程，BrowserFrame.reportError調(diào)用CallbackProxy.onReceiveError，這個 CallbackProxy里會發(fā)消息REPORT_ERROR，然后主線程接收消息，執(zhí)行 WebViewClient.onReceivedError。
接著又是收到FUNCPTR_MESSAGE消息，調(diào)用nativeServiceFuncPtrQueue，但是這里回調(diào)了 BrowserFrame.loadStarted，然后的處理流程跟上述的LoadUrl中調(diào)用BrowserFrame.loadStarted過程 一樣。
接著WebViewCoreThread線程又是收到FUNCPTR_MESSAGE消息，調(diào)用 JWebCoreJavaBridge.nativeServiceFuncPtrQueue，WebViewCore.contentDraw被調(diào)用， 該函數(shù)發(fā)送WEBKIT_DRAW，處理該消息會執(zhí)行繪制的操作。
接著WebViewCoreThread線程中JWebCoreJavaBridge.handleMessage又被調(diào)用，還是 FUNCPTR_MESSAGE消息，仍然是調(diào)用nativeServiceFuncPtrQueue。但此時BrowserFrame收到 loadFinished的回調(diào)，發(fā)PAGE_FINISHED消息，主線程接收消息處理時會執(zhí)行WebView.onPageFinished和 WebViewClient.onFinished.