事件分发机制在android开发中是非常重要的部分，他是用户与手机沟通的桥梁之一；今天我们从应用返回流程开始来分析事件分发机制。
从这篇文章中我们开始分析android系统的事件分发流程，其实网上已经有了很多关于android系统的事件分发流程的文章，奈何看了很多但是印象还不是很深，所以这里总结一番。
android系统的事件分发流程分为很多部分：
- Native层 --> ViewRootImpl层 --> DecorView层 --> Activity层 --> ViewGroup层 --> View层
所以android系统的事件分发流程是从Native层开始的，然后分发到ViewRootImpl中，然后分发到DecorView层，然后分发到ViewGroup层，最后分发到View层中。下面我们将从Native层开始分析事件的分发流程。
在Native层android系统的事件流程：
Android系统是从从底层驱动中获取各种原始的用户消息，包括按键、触摸屏、鼠标、滚迹球等用户事件消息。
在获取用户消息之后，android系统会对最原始的消息进行预处理，包括两个方面：一方面，将消息转化成系统可以处理的消息事件；另一方面，处理一些特殊的事件，比如HOME、MENU、POWER键等处理（前面的几篇文章中我们已经分析了系统按键处理逻辑的执行流程）。
将处理后的消息事件分发到各个应用进程，这个需要使用IPC机制，Android系统使用管道来进行消息的传递。
Android系统使用InputManager类来管理消息，而具体的功能则是通过InputReaderThread和InputDispatcherThread两个线程来实现。其中InputReaderThread线程负责消息的读取，而InputDispatcherThread则负责消息的预处理和分发到各个应用进程中。
Acitivty系统在SystemServer进程中启动WindowManagerService服务，然后在WindowManagerService服务中启动InputManagerService服务。
可以看到在Native层，主要创建了两个两个线程，其中一个用于读取消息，另一个用于分发消息，消息经过分发最终会上传至App中。
在ViewRootImpl层android系统的事件流程
在Native层的事件分发线程中，经过事件的分发流程，最终会调用InputEventSender的dispatchInputEventFinished方法，可以看一下具体代码的实现：
private void dispatchInputEventFinished(int seq, boolean handled) {
onInputEventFinished(seq, handled);
}
在dispatchInputEventFinished方法中我们最终调用的是onInputEventFinished方法，然后我们查看onInputEventFinished方法的实现，发现其是一个空方法。。。，好吧，经过分析我们发现，Native层最终调用的并不是InputEventSender，而是调用InputEventSender的子类ImeInputEventSender，即ImeInputEventSender的onInputEventFinished方法，该类定义在源文件InputMethodManager中：
private final class ImeInputEventSender extends InputEventSender {
public ImeInputEventSender(InputChannel inputChannel, Looper looper) {
super(inputChannel, looper);
}
@Override
public void onInputEventFinished(int seq, boolean handled) {
finishedInputEvent(seq, handled, false);
}
}
可以看到在其onInputEventFinished方法中又调用了finishedInputEvent方法，这样我们在继续看一下finishedInputEvent方法的实现。
void finishedInputEvent(int seq, boolean handled, boolean timeout) {
final PendingEvent p;
synchronized (mH) {
int index = mPendingEvents.indexOfKey(seq);
if (index < 0) {
return; // spurious, event already finished or timed out
}
p = mPendingEvents.valueAt(index);
mPendingEvents.removeAt(index);
Trace.traceCounter(Trace.TRACE_TAG_INPUT, PENDING_EVENT_COUNTER, mPendingEvents.size());
if (timeout) {
Log.w(TAG, "Timeout waiting for IME to handle input event after "
+ INPUT_METHOD_NOT_RESPONDING_TIMEOUT + " ms: " + p.mInputMethodId);
} else {
mH.removeMessages(MSG_TIMEOUT_INPUT_EVENT, p);
}
}
invokeFinishedInputEventCallback(p, handled);
}
在方法finishedInputEvent中，经过一系列的处理之后最终调用的是invokeFinishedInputEventCallback方法，所以我们继续看一下invokeFinishedInputEventCallback方法的实现。
void invokeFinishedInputEventCallback(PendingEvent p, boolean handled) {
p.mHandled = handled;
if (p.mHandler.getLooper().isCurrentThread()) {
// Already running on the callback handler thread so we can send the
// callback immediately.
p.run();
} else {
// Post the event to the callback handler thread.
// In this case, the callback will be responsible for recycling the event.
Message msg = Message.obtain(p.mHandler, p);
msg.setAsynchronous(true);
msg.sendToTarget();
}
}
可以发现这里我们首先判断PendingEvent的mHandler所在的线程是否是当前线程，若是的话则直接调用p.run方法，若不是的话则发送一个异步消息，而异步消息最终也是执行的p.run方法，所以我们继续看一下PendingEvent的run方法。
@Override
public void run() {
mCallback.onFinishedInputEvent(mToken, mHandled);
synchronized (mH) {
recyclePendingEventLocked(this);
}
}
可以发现在run方法中我们调用了mCallback的onFinishedInputEvent方法，需要说明的是这里的mCallback就是我们ViewRootImpl中的ImeInputStage类对象，而这里的ViewRootImpl对象就是我们的系统当前界面，前面我们分析Activity的加载绘制流程的时候知道Activity中保存了一个Window对象用于表示窗口信息，而Window对象内部就是通过ViewRootImpl对象实现窗口的加载绘制，所以这里的mCallback对象就是我们当前的App获取焦点的窗口的ViewRootImpl中的ImeInputStage对象，然后我们看一下该对象的onFinishedInputEvent方法的实现。
final class ImeInputStage extends AsyncInputStage
implements InputMethodManager.FinishedInputEventCallback {
...
@Override
public void onFinishedInputEvent(Object token, boolean handled) {
QueuedInputEvent q = (QueuedInputEvent)token;
if (handled) {
finish(q, true);
return;
}
forward(q);
}
}
这样经过一系列的调用之后我们消息的处理逻辑上传至了ViewRootImpl中，而在ViewRootImpl中经过一些列的调用之后我们ViewRootImpl$ViewPostImeInputStage.processKeyEvent方法：
at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:4152)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:4114)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:3662)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:3715)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:3681)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:3807)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:3689)
at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:3864)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:3662)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:3715)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:3681)
at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:3689)
at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:3662)
at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:3715)
at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:3681)
at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:3840)
at android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent(ViewRootImpl.java:4006)
at android.view.inputmethod.InputMethodManager$PendingEvent.run(InputMethodManager.java:2272)
at android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback(InputMethodManager.java:1893)
at android.view.inputmethod.InputMethodManager.finishedInputEvent(InputMethodManager.java:1884)
at android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished(InputMethodManager.java:2249)
at android.view.InputEventSender.dispatchInputEventFinished(InputEventSender.java:141)
这是通过异常信息打印的堆栈信息，从中我们可以看到在ViewRootImpl中我们经过一系列的调用之后最终执行的是：ViewRootImpl$ViewPostImeInputStage.processKeyEvent方法，这样我们继续看一下processKeyEvent方法。
private int processKeyEvent(QueuedInputEvent q) {
...
// Deliver the key to the view hierarchy.
if (mView.dispatchKeyEvent(event)) {
return FINISH_HANDLED;
}
...
}
可以看到这里调用了mView的dispatchKeyEvent方法，而我们分析过Activity窗口加载绘制流程，从中我们知道ViewRootImpl中的mView对象就是我们PhoneWindow中的mDecorView对象（DecorView），所以经过层层调用我们最终执行到了DecorView层。
在DecorView层android系统的事件流程
从上面我们知道在ViewRootImpl中我们最终调用了mView.dispatchKeyEvent方法，即执行的是PhoneWindow%DecorView.dispatchKeyEvent方法。
@Override
public boolean dispatchKeyEvent(KeyEvent event) {
final int keyCode = event.getKeyCode();
final int action = event.getAction();
final boolean isDown = action == KeyEvent.ACTION_DOWN;
if (isDown && (event.getRepeatCount() == 0)) {
// First handle chording of panel key: if a panel key is held
// but not released, try to execute a shortcut in it.
if ((mPanelChordingKey > 0) && (mPanelChordingKey != keyCode)) {
boolean handled = dispatchKeyShortcutEvent(event);
if (handled) {
return true;
}
}
// If a panel is open, perform a shortcut on it without the
// chorded panel key
if ((mPreparedPanel != null) && mPreparedPanel.isOpen) {
if (performPanelShortcut(mPreparedPanel, keyCode, event, 0)) {
return true;
}
}
}
if (!isDestroyed()) {
final Callback cb = getCallback();
final boolean handled = cb != null && mFeatureId < 0 ? cb.dispatchKeyEvent(event)
: super.dispatchKeyEvent(event);
if (handled) {
return true;
}
}
return isDown ? PhoneWindow.this.onKeyDown(mFeatureId, event.getKeyCode(), event)
: PhoneWindow.this.onKeyUp(mFeatureId, event.getKeyCode(), event);
}
从中我们可以看到如果当前的PhoneWindow不是destroy庄则，则执行cb.dispatchKeyEvent方法，而这里的callback对象就是我们的Activity对象，所以这里最终会执行到Activity的dispatchKeyEvent方法。。。
在Activity层android系统的事件流程
所以我们这里继续看一下Actiivty中的dispatchKeyEvent方法：
public boolean dispatchKeyEvent(KeyEvent event) {
onUserInteraction();
// Let action bars open menus in response to the menu key prioritized over
// the window handling it
if (event.getKeyCode() == KeyEvent.KEYCODE_MENU &&
mActionBar != null && mActionBar.onMenuKeyEvent(event)) {
return true;
}
Window win = getWindow();
if (win.superDispatchKeyEvent(event)) {
return true;
}
View decor = mDecor;
if (decor == null) decor = win.getDecorView();
return event.dispatch(this, decor != null
? decor.getKeyDispatcherState() : null, this);
}
从中我们可以看到我们首先调用了Activity的window对象的superDispatchKeyEvent方法，而这个方法就是将处理方法下发带Activity中的View，而这里我们分析的是返回按键，显然的View层是无法处理这里的返回按键的，所以win.superDispatchKeyEvent方法返回的是false，所以最终我们执行的是event.dispatch方法。这样我们继续看一下event.dispatch方法的实现。
public final boolean dispatch(Callback receiver, DispatcherState state,
Object target) {
switch (mAction) {
...
case ACTION_UP:
if (DEBUG) Log.v(TAG, "Key up to " + target + " in " + state
+ ": " + this);
if (state != null) {
state.handleUpEvent(this);
}
return receiver.onKeyUp(mKeyCode, this);
...
}
return false;
}
这里我们暂时分析一下ACTION_UP事件，可以发现这里最终调用的是receiver.onKeyUp方法，而这里的receiver就是我们的Actiivty，所以这里又回到了Activity并且执行其onKeyUp方法。
public boolean onKeyUp(int keyCode, KeyEvent event) {
if (getApplicationInfo().targetSdkVersion
>= Build.VERSION_CODES.ECLAIR) {
if (keyCode == KeyEvent.KEYCODE_BACK && event.isTracking()
&& !event.isCanceled()) {
onBackPressed();
return true;
}
}
return false;
}
看onKeyUp方法，我们可以发现当我们按的是返回按键时，其回调了onBackPressed方法，所以我们继续看一下onBackPressed方法。
public void onBackPressed() {
if (mActionBar != null && mActionBar.collapseActionView()) {
return;
}
if (!mFragments.getFragmentManager().popBackStackImmediate()) {
finishAfterTransition();
}
}
可以看到，在onBackPressed方法中，我们最终调用的是finishAfterTransition方法，所以继续看一下这个方法的实现逻辑。
public void finishAfterTransition() {
if (!mActivityTransitionState.startExitBackTransition(this)) {
finish();
}
}
O(∩_∩)O哈哈~，原来finish方法是在这里调用的，这样我们按下返回按键并抬起之后，经过层层的调用之后最终调用了我们的finish方法，而这个方法就是finish掉Activity的方法，也就解释了我们在App中默认按下返回按键之后Acitivty会被销毁了。
总结：
事件分发流程从Native --> ViewRootImpl层 --> DecorView层 --> Activity层都是类似的，无论是按键分发流程还是触摸事件分发流程,调用dispatchKeyEvent开始触摸事件传递。