首先在網(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()方法生年。
1瘛U艏ā4浮惦界!看到?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é)撒花Q慵选6赂埂>吻辍腿堤!