【Android面試查漏補缺】之事件分發機制詳解
前言
查漏補缺,查漏補缺,你不知道哪裡漏了,怎麼補缺呢?本文屬於【Android面試查漏補缺】系列文章第一篇,持續更新中,感興趣的朋友可以【關注+收藏】哦~
本系列文章是對自己的前段時間面試經歷的總結。其實本來自己是不太想繼續寫關於面試題的文章了,因為社群內很多這類的文章,但是如果每個地方翻一下,又不方便自己回顧,所以還是決定寫下本文供自己鞏固,也給大家一個參考。
一、題目層次
面試中提到安卓的事件分發,我們一般都能說到從 Activity -> Window -> DecorView -> ViewGroup -> View 的 dispatchTouchEvent 流程,這個是最基本的需要掌握的,由此能深入引出一些什麼知識點呢?
事件是如何從螢幕點選最終到達 Activity 的?
CANCEL 事件什麼時候會觸發?
如何解決滑動衝突?
二、題目詳解
2.1 安卓事件的分發
安卓的事件分發大概會經歷 Activity -> PhoneWindow -> DecorView -> ViewGroup -> View 的 dispatchTouchEvent。
其中 dispatchTouchEvent 用下面的一段虛擬碼就可以說明了,過程就不具體分析了,大家應該也都比較清晰。
// 虛擬碼
public boolean dispatchTouchEvent() {
boolean res = false;
// 是否不允許攔截事件
// 如果設定了 FLAG_DISALLOW_INTERCEPT,不會攔截事件,所以在 child 裡可以通過 requestDisallowInterceptTouchEvent 控制父 View 是否來攔截事件
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept && onInterceptTouchEvent()) { // View 不呼叫這裡,直接執行下面的 touchlistener 判斷
if (touchlistener && touchlistener.onTouch()) {
return true;
}
res = onTouchEvent(); // 裡面會處理點選事件 -> performClick() -> clicklistener.onClick()
} else if (DOWN) { // 如果是 DOWN 事件,則遍歷子 View 進行事件分發
// 迴圈子 View 處理事件
for (childs) {
res = child.dispatchTouchEvent();
}
} else {
// 事件分發給 target 去處理,這裡的 target 就是上一步處理 DOWN 事件的 View
target.child.dispatchTouchEvent();
}
return res;
}
2.2 事件是如何到達 Activity 的
既然上面的事件分發是從 Activity 開始的,那事件是怎麼到達 Activity 的呢?
總體流程大概是這樣的:使用者點選裝置, linux 核心接受中斷, 中斷加工成輸入事件資料寫入對應的裝置節點中, InputReader 會監控 /dev/input/ 下的所有裝置節點, 當某個節點有資料可以讀時,通過 EventHub 將原始事件取出來並翻譯加工成輸入事件,交給 InputDispatcher,InputDispatcher 根據 WMS 提供的視窗資訊把事件交給合適的視窗,視窗 ViewRootImpl 派發事件
大體流程圖如下:
input
其中主要有幾個階段:
- 硬體中斷
- InputManagerService 做的事情
- InputReaderThread 做的事情
- InputDispatcherThread 做的事情
- WindowInputEventReceiver 做的事情
2.2.1 硬體中斷
硬體中斷這裡就簡單介紹一些,作業系統對硬體事件的接收是通過中斷來進行的。
核心啟動的時候會在中斷描述符表中對中斷型別以及對應的處理方法的地址進行註冊。
當有中斷的時候,就會呼叫對應的處理方法,把對應的事件寫入到裝置節點裡。
2.2.2 InputManagerService 做的事情
InputManagerService 是用來處理 Input 事件的,Java 側的 InputManagerService 就是 C++ 程式碼的一個封裝,以及提供了一些 callback 用來傳遞事件到 Java 層。
我們看一下 native 側的 InputManagerService 初始化程式碼。
NativeInputManager::NativeInputManager(jobject contextObj,
jobject serviceObj, const sp<Looper>& looper) :
mLooper(looper), mInteractive(true) {
// ...
sp<EventHub> eventHub = new EventHub();
mInputManager = new InputManager(eventHub, this, this);
}
主要做的兩件事:
- 初始化 EventHub
EventHub::EventHub(void) {
// ...
mINotifyFd = inotify_init();
int result = inotify_add_watch(mINotifyFd, DEVICE_PATH, IN_DELETE | IN_CREATE);
result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mINotifyFd, &eventItem);
result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, &eventItem);
}
EventHub 的作用是用來監控裝置節點是否有更新。
- 初始化 InputManager
void InputManager::initialize() {
mReaderThread = new InputReaderThread(mReader);
mDispatcherThread = new InputDispatcherThread(mDispatcher);
}
InputManager 裡初始化了 InputReaderThread 和 InputDispatcherThread 兩個執行緒,一個用來讀取事件,一個用來派發事件。
2.2.3 InputReaderThread 做的事情
bool InputReaderThread::threadLoop() {
mReader->loopOnce();
return true;
}
void InputReader::loopOnce() {
// 從 EventHub 獲取事件
size_t count = mEventHub->getEvents(timeoutMillis, mEventBuffer, EVENT_BUFFER_SIZE);
// 處理事件
processEventsLocked(mEventBuffer, count);
// 事件傳送給 InputDispatcher 去做分發
mQueuedListener->flush();
}
這裡程式碼比較多,做一些省略。
InputReaderThread 裡做了三件事情:
- 從 EventHub 獲取事件
- 處理事件,這裡事件有不同的型別,會做不同的處理和封裝
- 把事件傳送給 InputDispatcher
2.2.4 InputDispatcherThread 做的事情
bool InputDispatcherThread::threadLoop() {
mDispatcher->dispatchOnce(); // 內部呼叫 dispatchOnceInnerLocked
return true;
}
void InputDispatcher::dispatchOnceInnerLocked(nsecs_t* nextWakeupTime) {
// 從佇列中取出一個事件
mPendingEvent = mInboundQueue.dequeueAtHead();
// 根據不同的事件型別,進行不同的操作
switch (mPendingEvent->type) {
case EventEntry::TYPE_CONFIGURATION_CHANGED: {
// ...
case EventEntry::TYPE_DEVICE_RESET: {
// ...
case EventEntry::TYPE_KEY: {
// ...
case EventEntry::TYPE_MOTION: {
// 派發事件
done = dispatchMotionLocked(currentTime, typedEntry,
&dropReason, nextWakeupTime);
break;
}
}
上面通過 dispatchMotionLocked 方法派發事件,具體的函式呼叫過程省略如下:
dispatchMotionLocked -> dispatchEventLocked -> prepareDispatchCycleLocked -> enqueueDispatchEntriesLocked -> startDispatchCycleLocked -> publishMotionEvent -> InputChannel.sendMessage
其中會找到當前合適的 Window,然後呼叫 InputChannel 去傳送事件。
這裡的 InputChannel 對應的是 ViewRootImpl 裡的 InputChannel。
至於中間的怎麼做的關聯,這裡就先不做分析,整個程式碼比較長,而且對於流程的掌握影響不大。
2.2.5 WindowInputEventReceiver 接受事件並進行分發
在 ViewRootImpl 裡有一個 WindowInputEventReceiver 用來接受事件並進行分發。
InputChannel 傳送的事件最終都是通過 WindowInputEventReceiver 進行接受。
WindowInputEventReceiver 是在 ViewRootImpl.setView 裡面初始化的,setView 的呼叫是在 ActivityThread.handleResumeActivity -> WindowManagerGlobal.addView。
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
// ...
if (mInputChannel != null) {
if (mInputQueueCallback != null) {
mInputQueue = new InputQueue();
mInputQueueCallback.onInputQueueCreated(mInputQueue);
}
mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,
Looper.myLooper());
}
}
public abstract class InputEventReceiver {
// native 側程式碼呼叫這個方法,把事件派發過來
private void dispatchInputEvent(int seq, InputEvent event, int displayId) {
mSeqMap.put(event.getSequenceNumber(), seq);
onInputEvent(event, displayId);
}
}
final class WindowInputEventReceiver extends InputEventReceiver {
@Override
public void onInputEvent(InputEvent event, int displayId) {
// 事件接受
enqueueInputEvent(event, this, 0, true);
}
// ...
}
void enqueueInputEvent(InputEvent event,
InputEventReceiver receiver, int flags, boolean processImmediately) {
// 是否要立即處理事件
if (processImmediately) {
doProcessInputEvents();
} else {
scheduleProcessInputEvents();
}
}
void doProcessInputEvents() {
// ...
while (mPendingInputEventHead != null) {
deliverInputEvent(q);
}
// ...
}
private void deliverInputEvent(QueuedInputEvent q) {
// ...
InputStage stage;
if (q.shouldSendToSynthesizer()) {
stage = mSyntheticInputStage;
} else {
stage = q.shouldSkipIme() ? mFirstPostImeInputStage : mFirstInputStage;
}
// 分發事件
stage.deliver(q);
}
從上面的程式碼流程中,事件最終走到 InputStage.deliver 裡。
abstract class InputStage {
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));
}
}
}
在 deliver 裡,最終呼叫 onProcess,實現是在 ViewPostImeInputStage。
final class ViewPostImeInputStage extends InputStage {
@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);
}
}
}
private int processPointerEvent(QueuedInputEvent q) {
// 這裡 mView 是 DecorView,呼叫到 DecorView.dispatchPointerEvent
boolean handled = mView.dispatchPointerEvent(event);
// ...
return handled ? FINISH_HANDLED : FORWARD;
}
}
// View.java
public final boolean dispatchPointerEvent(MotionEvent event) {
if (event.isTouchEvent()) {
return dispatchTouchEvent(event);
} else {
return dispatchGenericMotionEvent(event);
}
}
// DecorView.java
public boolean dispatchTouchEvent(MotionEvent ev) {
// 這裡的 Callback 就是 Activity,是在 Activity.attach 裡呼叫 mWindow.setCallback(this); 設定的
final Window.Callback cb = mWindow.getCallback();
return cb != null && !mWindow.isDestroyed() && mFeatureId < 0
? cb.dispatchTouchEvent(ev) : super.dispatchTouchEvent(ev);
}
通過上面一系列流程,最終就呼叫到 Activity.dispatchTouchEvent 裡,也就是開始的流程了。
通過上面的分析,我們基本上知道了事件從使用者點選螢幕到 View 處理的過程了,就是下面這張圖。
input
2.3 CANCEL 事件什麼時候會觸發
這個如果仔細看 dispatchTouchEvent 的程式碼的話,可以看到一些時機:
- View 收到 ACTION_DOWN 事件以後,上一個事件還沒有結束(可能因為 APP 的切換、ANR 等導致系統扔掉了後續的事件),這個時候會先執行一次 ACTION_CANCEL
// ViewGroup.dispatchTouchEvent()
public boolean dispatchTouchEvent(MotionEvent ev) {
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
cancelAndClearTouchTargets(ev);
resetTouchState();
}
}
- 子 View 之前攔截了事件,但是後面父 View 重新攔截了事件,這個時候會給子 View 傳送 ACTION_CANCEL 事件
// ViewGroup.dispatchTouchEvent()
public boolean dispatchTouchEvent(MotionEvent ev) {
if (mFirstTouchTarget == null) {
} else {
// 有子 View 獲取了事件
TouchTarget target = mFirstTouchTarget;
while (target != null) {
final TouchTarget next = target.next;
final boolean cancelChild = resetCancelNextUpFlag(target.child)
|| intercepted;
// 父 View 此時如果攔截了事件,cancelChild 是 true
if (dispatchTransformedTouchEvent(ev, cancelChild,
target.child, target.pointerIdBits)) {
handled = true;
}
}
}
}
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final int oldAction = event.getAction();
// 如果 cancel 是 true,則傳送 ACTION_CANCEL 事件
if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event);
}
event.setAction(oldAction);
return handled;
}
}
2.4 如何解決滑動衝突
這個也是老生常談的一個問題了,主要就是兩個方法:
- 通過重寫父類的 onInterceptTouchEvent 來攔截滑動事件
- 通過在子類中呼叫 parent.requestDisallowInterceptTouchEvent 來通知父類是否要攔截事件,requestDisallowInterceptTouchEvent 會設定 FLAG_DISALLOW_INTERCEPT 標誌,這個在最開始的虛擬碼那裡做過介紹
三、總結
上面就是從 View 事件分發引申出的一些問題,簡單的解答如下:
- View 事件分發
// 虛擬碼
public boolean dispatchTouchEvent() {
boolean res = false;
// 是否不允許攔截事件
// 如果設定了 FLAG_DISALLOW_INTERCEPT,不會攔截事件,所以在 child 裡可以通過 requestDisallowInterceptTouchEvent 控制父 View 是否來攔截事件
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept && onInterceptTouchEvent()) { // View 不呼叫這裡,直接執行下面的 touchlistener 判斷
if (touchlistener && touchlistener.onTouch()) {
return true;
}
res = onTouchEvent(); // 裡面會處理點選事件 -> performClick() -> clicklistener.onClick()
} else if (DOWN) { // 如果是 DOWN 事件,則遍歷子 View 進行事件分發
// 迴圈子 View 處理事件
for (childs) {
res = child.dispatchTouchEvent();
}
} else {
// 事件分發給 target 去處理,這裡的 target 就是上一步處理 DOWN 事件的 View
target.child.dispatchTouchEvent();
}
return res;
}
-
事件是如何從螢幕點選最終到達 Activity 的?
input -
CANCEL 事件什麼時候會觸發?
- View 收到 ACTION_DOWN 事件以後,上一個事件還沒有結束(可能因為 APP 的切換、ANR 等導致系統扔掉了後續的事件),這個時候會先執行一次 ACTION_CANCEL
- 子 View 之前攔截了事件,但是後面父 View 重新攔截了事件,這個時候會給子 View 傳送 ACTION_CANCEL 事件
- 如何解決滑動衝突?
- 通過重寫父類的 onInterceptTouchEvent 來攔截滑動事件
- 通過在子類中呼叫 parent.requestDisallowInterceptTouchEvent 來通知父類是否要攔截事件
最後
我把之前遇到的面試真題做了一個整合,已上傳至開源專案【GitHub】,有需要的朋友可以自行免費獲取。
Activity面試題
Fragment面試題
Service&Broadcast Receiver面試題
WebView&Binder面試題
Handler面試題
AsyncTask面試題
由於篇幅原因,為了避免影響到大家的閱讀體驗,在此只以截圖展示部分內容,有需要的朋友記得點贊支援下哦,【點這裡】即可免費領取!