从这篇文章中我们开始分析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会被销毁了。

总结：

本文中由于是分析的返回按键的处理流程，所以事件的分发流程没有做说明，下面的文章中会着重介绍Android的事件分发流程；
事件分发流程从Native --> ViewRootImpl层 --> DecorView层 --> Activity层都是类似的，无论是按键分发流程还是触摸事件分发流程

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

29 应用程序返回按键执行流程.md

29 应用程序返回按键执行流程.md

Files

29 应用程序返回按键执行流程.md

Latest commit

History

29 应用程序返回按键执行流程.md

File metadata and controls