转载请标明出处:一片枫叶的专栏
从这篇文章中我们开始分析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层都是类似的,无论是按键分发流程还是触摸事件分发流程
另外对android源码解析方法感兴趣的可参考我的:
android源码解析之(一)–>android项目构建过程
android源码解析之(二)–>异步消息机制
android源码解析之(三)–>异步任务AsyncTask
android源码解析之(四)–>HandlerThread
android源码解析之(五)–>IntentService
android源码解析之(六)–>Log
android源码解析之(七)–>LruCache
android源码解析之(八)–>Zygote进程启动流程
android源码解析之(九)–>SystemServer进程启动流程
android源码解析之(十)–>Launcher启动流程
android源码解析之(十一)–>应用进程启动流程
android源码解析之(十二)–>系统启动并解析Manifest的流程
android源码解析之(十三)–>apk安装流程
android源码解析之(十四)–>Activity启动流程
android源码解析之(十五)–>Activity销毁流程
android源码解析(十六)–>应用进程Context创建流程
android源码解析(十七)–>Activity布局加载流程
android源码解析(十八)–>Activity布局绘制流程
android源码解析(十九)–>Dialog加载绘制流程
android源码解析(二十)–>Dialog取消绘制流程
android源码解析(二十一)–>PopupWindow加载绘制流程
android源码解析(二十二)–>Toast加载绘制流程
android源码解析(二十三)–>Android异常处理流程
android源码解析(二十四)–>onSaveInstanceState执行时机
android源码解析(二十五)–>onLowMemory执行流程
android源码解析(二十六)–>截屏事件流程
android源码解析(二十七)–>HOME事件流程
android源码解析(二十八)–>电源开关机按键事件流程
本文以同步至github中:https://github.com/yipianfengye/androidSource,欢迎star和follow