首先在網(wǎng)上看了很多文章包括郭霖大神的文章,他們都完美分析了ViewGroup和View的事件分發(fā)。可是還是很疑惑:觸摸事件ViewGroup是怎么捕獲到的?大神們都說(shuō)Activity,Window,ViewRoot等等這些東西都是參與了事件分發(fā),他們是怎么參加的?是誰(shuí)最先接收到的觸摸事件的?我是非常不解的,因此咬牙查資料分析源碼學(xué)習(xí)了一波,接下來(lái)我們來(lái)一探究竟!由于為了講得詳細(xì)也為了全面,所以篇幅略長(zhǎng)。所以分為兩個(gè)部分分析。本文為上半部分,用來(lái)專門(mén)分析事件從手機(jī)硬件源頭傳遞到我們自己寫(xiě)的布局之前的過(guò)程。本文源碼均來(lái)自API24。
首先我先總結(jié)一下附帶上一張流程圖來(lái)提前劇透一下:
當(dāng)觸摸事件發(fā)生時(shí),手機(jī)硬件監(jiān)測(cè)到后將事件交給ViewRootImpl,然后ViewRootImpl交給DecorView,然后DecorView通過(guò)Window將事件交給Activity,然后Activity將事件交給Window,Window交給DecorView,然后DecorView開(kāi)始就交給我們定義的布局啦。
(圖中左邊的Receiver,Handler,Stage會(huì)在下文中講解)
接下來(lái)我們來(lái)仔細(xì)分析分析。
當(dāng)我們手指觸碰屏幕時(shí),先是手機(jī)硬件會(huì)進(jìn)行相應(yīng)處理然后發(fā)出通知。而在源碼中有一個(gè)叫做InputEventReceiver的接收器。顧名思義,輸入事件接收器。這個(gè)東西在哪里用到了呢?找啊找,哈哈,發(fā)現(xiàn)在ViewRootImpl里用到了這個(gè)東西!
而ViewRootImpl是什么呢?簡(jiǎn)單說(shuō)明一下:
他是一個(gè)用來(lái)連接Window和DecorView的紐帶,也是它來(lái)觸發(fā)完成View的包括measure、layout、draw繪制過(guò)程。它也起到向View分發(fā)一系列輸入事件的作用,例如觸摸,鍵盤(pán)事件等。
在ViewRootImpl中有一個(gè)WindowInputEventReceiver類繼承自InputEventReceiver并且重寫(xiě)了onInputEvent()方法:
final class WindowInputEventReceiver extends InputEventReceiver {
public WindowInputEventReceiver(InputChannel inputChannel, Looper looper) {
super(inputChannel, looper);
}
@Override
public void onInputEvent(InputEvent event) {
enqueueInputEvent(event, this, 0, true);
}
那么這個(gè)類是在哪里實(shí)例化的呢?在ViewRoot的setView()方法中有這么一段代碼:
if (mInputChannel != null) {
if (mInputQueueCallback != null) {
mInputQueue = new InputQueue();
mInputQueueCallback.onInputQueueCreated(mInputQueue);
}
mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,
Looper.myLooper());
}
正是在這里進(jìn)行了實(shí)例化,因此在ViewRoot將Window加入到WindowManager的時(shí)候(setView()具體在何時(shí)調(diào)用讀者自行查找,可以看我的另一篇Window相關(guān)文章,這里不再深究)會(huì)創(chuàng)建了一個(gè)接收器。當(dāng)手機(jī)硬件發(fā)出InputEvent后會(huì)調(diào)用Receiver的onInputEvent()方法,而在這里就調(diào)用了enqueueInputEvent(event, this, 0, true)(見(jiàn)上面的WindowInputEventReceiver源碼)。
可以看到這里調(diào)用了enqueueInputEvent()方法,顧名思義,插入輸入事件。我們繼續(xù)跟入查看:
void enqueueInputEvent(InputEvent event,
InputEventReceiver receiver, int flags, boolean processImmediately) {
....//其他代碼
if (processImmediately) {
doProcessInputEvents();
} else {
scheduleProcessInputEvents();
}
}
繼續(xù)貼出關(guān)鍵代碼,首先對(duì)processImmediately進(jìn)行了判斷,如實(shí)為true,調(diào)用doProcessInputEvents()方法,如果為false,調(diào)用scheduleProcessInputEvents()方法,實(shí)際上scheduleProcessInputEvents()內(nèi)部最終還是調(diào)用了doProcessInputEvents()方法,這里不深究,有興趣的同志可以自行查看。
我們?cè)俑M(jìn)doProcessInputEvents()方法(跟得好累啊...):
void doProcessInputEvents() {
...//其他代碼
deliverInputEvent(q);
...//其他代碼
}
老規(guī)矩,我們貼出關(guān)鍵代碼,在這里又調(diào)用了deliverInputEvent()方法,還是顧名思義,傳遞輸入事件,我們繼續(xù)跟進(jìn):
private void deliverInputEvent(QueuedInputEvent q) {
....//其他代碼
InputStage stage;
if (q.shouldSendToSynthesizer()) {
stage = mSyntheticInputStage;
} else {
stage = q.shouldSkipIme() ? mFirstPostImeInputStage : mFirstInputStage;
}
代碼標(biāo)注處-----------------------------------
if (stage != null) {
stage.deliver(q);
} else {
finishInputEvent(q);
}
}
在上面中我們可以看到定義了一個(gè)InputStage,這是什么呢?在這里我們看一下官方注釋:
/**
* Base class for implementing a stage in the chain of responsibility
* for processing input events.
* <p>
* Events are delivered to the stage by the {@link #deliver} method. The stage
* then has the choice of finishing the event or forwarding it to the next stage.
* </p>
*/
abstract class InputStage {
大概意思就是這就是用來(lái)處理一系列輸入事件(例如觸屏,鍵盤(pán))的類,事件通過(guò)調(diào)用deliver方法來(lái)傳遞到這個(gè)類,這個(gè)類可以選擇終止事件,可以選擇處理。
回到剛才,在上面的上面的代碼標(biāo)注處調(diào)用了stage.deliver()方法,我們?cè)龠M(jìn)去看看:
public final void deliver(QueuedInputEvent q) {
if ((q.mFlags & QueuedInputEvent.FLAG_FINISHED) != 0) {
forward(q);
} else if (shouldDropInputEvent(q)) {
finish(q, false);
} else {
apply(q, onProcess(q));
}
}
在上面代碼中可以看到:他可以選擇繼續(xù)傳遞事件,也可以選擇終止事件,而最后也可以調(diào)用了一個(gè)apply方法,我理解為表示處理事件。
而當(dāng)一個(gè)InputEvent到來(lái)時(shí),ViewRootImpl會(huì)尋找合適它的InputStage來(lái)處理。而ViewRootImpl中又定義了多個(gè)xxxInputStage類來(lái)繼承自InputStage類,用來(lái)針對(duì)不同事件做不同處理。
對(duì)于點(diǎn)擊事件來(lái)說(shuō),ViewPostImeInputStage可以處理它,因此調(diào)用ViewPostImeInputStage類中的onProcess方法。當(dāng)onProcess被回調(diào)時(shí),processKeyEvent、processPointerEvent、processTrackballEvent、processGenericMotionEvent至少有一個(gè)方法就會(huì)被調(diào)用,這些方法都是屬于ViewPostImeInputStage的。onProgress方法如下:
@Override
protected int onProcess(QueuedInputEvent q) {
if (q.mEvent instanceof KeyEvent) {
return processKeyEvent(q);
} else {
final int source = q.mEvent.getSource();
if ((source & InputDevice.SOURCE_CLASS_POINTER) != 0) {
return processPointerEvent(q);
} else if ((source & InputDevice.SOURCE_CLASS_TRACKBALL) != 0) {
return processTrackballEvent(q);
} else {
return processGenericMotionEvent(q);
}
}
}
這里就看到根據(jù)輸入事件的不同調(diào)用不同的處理方法,我們跟進(jìn)幾個(gè)processxxxEvent方法進(jìn)去都會(huì)發(fā)現(xiàn)會(huì)調(diào)用mView.dispatchxxxEvent()方法。而這些dispatchxxxEvent()方法就是分發(fā)事件機(jī)制的實(shí)現(xiàn)方法了。
好了說(shuō)了那么久了終于撒花撒花撒.....啊呸,啥玩意兒啊?mView是個(gè)啥啊?你這坑爹啊。啥了半天啥Window啊什么之類的都沒(méi)出現(xiàn)。。好好好,別說(shuō)了,自己挖的坑自己慢慢填。。。我們?cè)倮^續(xù)看看這個(gè)mView是啥(說(shuō)實(shí)話很惡心這種變量名字,只能說(shuō)比test名字好一點(diǎn))。
第一反應(yīng)是去ViewRootImpl的構(gòu)造方法去看看,結(jié)果沒(méi)有找到賦值,然后就只能不停的去找,找了一會(huì)兒,誒?找到了,哈哈。在ViewRootImpl的setView()方法中發(fā)現(xiàn),先上源碼:
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
mView = view;
...//其他代碼
}
...//其他代碼
}
...//其他代碼
}
在這里進(jìn)行了賦值,那么這個(gè)傳入的view是啥呢?其實(shí)這個(gè)傳入的View一般都是DecorView,因?yàn)閂iewRoot是聯(lián)系Window和根View的紐帶,而根View都是DecorView。至于在哪里調(diào)用這個(gè)方法,有興趣的同志可以自行(算了吧我去,都寫(xiě)到這兒了我一并寫(xiě)出來(lái)吧)。在我的另一篇記錄里面初探Android中Window與DecorView中提到,將Window加入到WindowManager是在Activity的makeVisible()方法中調(diào)用了windowManager.addView(mDecor, getWindow().getAttributes()); 方法。而addView()方法源碼如下(在WindowManagerImpl中查看):
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}
我們看到是調(diào)用了 mGlobal.addView()方法,在跟進(jìn)去看看:
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
...//其他代碼
ViewRootImpl root;
View panelParentView = null;
...//其他代碼
root = new ViewRootImpl(view.getContext(), display);
...//其他代碼
root.setView(view, wparams, panelParentView);
...//其他代碼
}
}
在這里看到,實(shí)例化了ViweRootImpl對(duì)象,調(diào)用了setView()方法。
!!!!看到?jīng)]!我我我曹!終于看到這個(gè)方法了!在這里將view傳入,而這個(gè)view就是傳入的DecorView!
由此真相大白!事已至此我們就已經(jīng)看到了ViewRoot在事件分發(fā)過(guò)程中的作用!起到了獲取觸摸事件,然后將事件傳遞給DecorView。
那么接下來(lái)很久回到之前我們說(shuō)到的調(diào)用mView.dispatchxxxEvent()方法。那么接下來(lái)我們?nèi)ecorView去看看dispatchxxxEvent()方法,這里拿觸摸事件(dispatchTouchEvent()方法)來(lái)分析,先上代碼:
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
final Window.Callback cb = mWindow.getCallback();//getCallback()返回mCallback變量
return cb != null && !mWindow.isDestroyed() && mFeatureId < 0
? cb.dispatchTouchEvent(ev) : super.dispatchTouchEvent(ev);
}
我們看到,在這里又調(diào)用了一個(gè)Window.Callback的dispatchTouchEvent()方法。沃德天吶,這又是啥(說(shuō)實(shí)話我對(duì)這種變量名真是一覽無(wú)遺無(wú)可奈何/(ㄒoㄒ)/~~)
又開(kāi)始苦逼的找啊找,曹,發(fā)現(xiàn)在Window中沒(méi)找到,然后仔細(xì)想了想,Window是在Activity的attach()方法中新建的,那么去看看呢?
結(jié)果一看,沃日啊,沃德天,我那么厲害?先上代碼:
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, String referrer, IVoiceInteractor voiceInteractor,
Window window) {
...//其他代碼
mWindow.setCallback(this);
...//其他代碼
}
我們看到,在這里設(shè)置了CallBack,參數(shù)為this,意味著當(dāng)前Activity。恍然大悟,原來(lái)CallBack就是Activity啊!那么之前的調(diào)用的cb.dispatchTouchEvent()方法就是Activity的方法。那么接下來(lái)我們就繼續(xù)去Activity看看,先上Activity的dispatchTouchEvent()源碼:
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();//內(nèi)部實(shí)現(xiàn)為空
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
首先看到調(diào)用了window的superDispatchTouchEvent()方法。我們跟進(jìn)PhoneWindow(Android內(nèi)唯一的Winodw實(shí)現(xiàn)類)看看源碼分析:
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
我們可以看到,這里調(diào)用了DecorView的superDispatchTouchEvent()方法,我們繼續(xù)跟進(jìn)去看看:
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
這里又調(diào)用了父類的dispatchTouchEvent()方法,而DecorView是繼承自FrameLayout的,也就是繼承自ViewGroup的。因此dispatchTouchEvent()就是ViewGroup的方法。
至此我們就已經(jīng)將事件分發(fā)從源頭分析到了系統(tǒng)內(nèi)部布局的DecorView。接下來(lái)可以說(shuō)就是從我們自己寫(xiě)的布局開(kāi)始傳遞,處理分發(fā)事件。
介于本文已經(jīng)太長(zhǎng)了,別說(shuō)讀,我寫(xiě)都寫(xiě)暈了。那么具體的ViewGroup和View的事件分發(fā)我將會(huì)再寫(xiě)一篇來(lái)進(jìn)行記錄。
終于完結(jié)撒花!!!!