Android事件分发溯源详解
前言
前两天华仔给我出了一道难题，我们俩研究了小半天，借着这个契机正好回顾了一下Android事件分发的相关知识点，于是有了这篇文章。
Android事件分发机制大家都非常熟悉，大部分文章对这个过程的描述都是开始于Activity，但是事件是怎么传到Activity的？
这里就涉及到几个重要的部分：Window，WMS，ViewRoot和DecorView。
如果要理解事件分发的源头，就需要搞明白他们之间的关系，所以我们先来看看它们到底有什么关系？
Window
Window是我们比较熟悉的，那么它是如何创建的？
我们来看Activity的attach函数：
@UnsupportedAppUsage
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, ActivityConfigCallback activityConfigCallback, IBinder assistToken) {
attachBaseContext(context);
...
mWindow = new PhoneWindow(this, window, activityConfigCallback);
mWindow.setWindowControllerCallback(mWindowControllerCallback);
mWindow.setCallback(this);
mWindow.setOnWindowDismissedCallback(this);
...
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
...
mWindowManager = mWindow.getWindowManager();
...
}
我这里只展示一部分关键代码。当我们的activity创建完成后会执行attach，这是可以看到创建了PhoneWindow，同时也设置了WindowManager。
注意mWindow.setCallback(this);这行代码，Activity本身实现了Window.Callback接口：
public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, ... {
这里将activity赋值给window的callback，在后面的流程中会发挥作用。
DecorView
DecorView是整个布局的最顶端的view，也就根布局。它很容易与ViewRoot搞混，ViewRoot其实不是View，后面再来说它。
DecorView是如何创建的，这一切要从setContentView说起：
public void setContentView(@LayoutRes int layoutResID) {
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
}
可以看到执行了window的setContentView，它的源码：
@Override
public void setContentView(int layoutResID) {
if (mContentParent == null) {
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}
...
}
可以看到一开始就执行installDecor，这里就是初始化DecorView：
private void installDecor() {
mForceDecorInstall = false;
if (mDecor == null) {
mDecor = generateDecor(-1);
...
} else {
mDecor.setWindow(this);
}
if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
...
}
}
可以看到先通过generateDecor创建了DecorView：
protected DecorView generateDecor(int featureId) {
Context context;
...
return new DecorView(context, featureId, this, getAttributes());
}
创建时将Window也传入了，所以DecorView中保存了一份Window的引用。
然后回到installDecor代码中，又执行了generateLayout，这里创建了mContentParent:
protected ViewGroup generateLayout(DecorView decor) {
...
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
...
return contentParent;
}
可以看到这个mContentParent就是ID_ANDROID_CONTENT，所以它才是真正装载我们通过setContentView所设置的布局那个ViewGroup。所以这个层级应该是：
DecorView -> mContentParent -> 实际布局
ViewRoot
通过上面可以看出，Window的创建是在attach环节，而DecorView则是在create环节。目前虽然创建了DecorView，但是还没有真正添加到Window中，而且ViewRoot还没有创建出来，这两步实际上是一起的，下面来看一下。
Activity创建完成后会通知AMS，AMS处理一些事务后会通知Activity显示，这样就会执行ActivityThread的handleResumeActivity()：
@Override
public void handleResumeActivity(ActivityClientRecord r, boolean finalStateRequest,
boolean isForward, String reason) {
...
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
...
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l);
} else {
a.onWindowAttributesChanged(l);
}
}
} else if (!willBeVisible) {
...
}
...
}
这里会通过WindowManager的addView函数将DecorView添加到屏幕上。WindowManager的实现类是WindowManagerImpl，它的函数代码如下：
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyTokens(params);
mGlobal.addView(view, params, mContext.getDisplayNoVerify(), mParentWindow,
mContext.getUserId());
}
实际上是执行了WindowManagerGlobal的addView：
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow, int userId) {
...
ViewRootImpl root;
View panelParentView = null;
synchronized (mLock) {
...
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// do this last because it fires off messages to start doing things
try {
root.setView(view, wparams, panelParentView, userId);
} catch (RuntimeException e) {
...
}
}
}
这里我们看到创建了ViewRootImpl，这就是ViewRoot。然后将DecorView也传入了，这样ViewRoot就持有了DecorView。
那么ViewRoot到底是什么？
我们可以把看看成是管理DecorView的一个类，比如它初始化的时候得到了一个WindowSession：
public ViewRootImpl(Context context, Display display) {
this(context, display, WindowManagerGlobal.getWindowSession(),
false /* useSfChoreographer */);
}
通过WindowSession可以与WMS进行通信实现一些窗口信息的传递。
另外在它的setView中还创建了一个WindowInputEventReceiver：
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView,
int userId) {
synchronized (this) {
if (mView == null) {
...
InputChannel inputChannel = null;
if ((mWindowAttributes.inputFeatures
& WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {
inputChannel = new InputChannel();
}
...
try {
...
res = mWindowSession.addToDisplayAsUser(mWindow, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(), userId,
mInsetsController.getRequestedVisibility(), inputChannel, mTempInsets,
mTempControls);
...
} catch (RemoteException e) {
...
} finally {
...
}
...
if (inputChannel != null) {
...
mInputEventReceiver = new WindowInputEventReceiver(inputChannel,
Looper.myLooper());
...
}
}
}
}
这个就是用来接收事件的，下面我们来顺着这个看看事件是如何分发到view的。
事件源头
上面创建WindowInputEventReceiver时，可以看到传入了一个InputChannel，它创建之后又传入了WindowSession，即WMS。InputChannel就是底层通知上层事件的核心，系统服务捕获到屏幕事件后，会通过它通知到上层，也就是WindowInputEventReceiver。
所以WindowInputEventReceiver是整个事件的源头：
final class WindowInputEventReceiver extends InputEventReceiver {
...
@Override
public void onInputEvent(InputEvent event) {
...
if (processedEvents != null) {
if (processedEvents.isEmpty()) {
// InputEvent consumed by mInputCompatProcessor
finishInputEvent(event, true);
} else {
for (int i = 0; i < processedEvents.size(); i++) {
enqueueInputEvent(
processedEvents.get(i), this,
QueuedInputEvent.FLAG_MODIFIED_FOR_COMPATIBILITY, true);
}
}
} else {
enqueueInputEvent(event, this, 0, true);
}
}
...
}
事件进入它的onInputEvent后会执行enqueueInputEvent:
void enqueueInputEvent(InputEvent event,
InputEventReceiver receiver, int flags, boolean processImmediately) {
...
if (processImmediately) {
doProcessInputEvents();
} else {
scheduleProcessInputEvents();
}
}
这里通过判断立即执行还是延迟处理，结果差不多，来看立即执行的代码：
void doProcessInputEvents() {
// Deliver all pending input events in the queue.
while (mPendingInputEventHead != null) {
...
deliverInputEvent(q);
}
...
}
进入deliverInputEvent：
private void deliverInputEvent(QueuedInputEvent q) {
...
try {
...
InputStage stage;
if (q.shouldSendToSynthesizer()) {
stage = mSyntheticInputStage;
} else {
stage = q.shouldSkipIme() ? mFirstPostImeInputStage : mFirstInputStage;
}
...
if (stage != null) {
handleWindowFocusChanged();
stage.deliver(q);
} else {
finishInputEvent(q);
}
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
可以看到通过stage进行了deliver，这个stage是什么？
在setView的最后有这么一段代码：
// Set up the input pipeline.
CharSequence counterSuffix = attrs.getTitle();
mSyntheticInputStage = new SyntheticInputStage();
InputStage viewPostImeStage = new ViewPostImeInputStage(mSyntheticInputStage);
InputStage nativePostImeStage = new NativePostImeInputStage(viewPostImeStage,
"aq:native-post-ime:" + counterSuffix);
InputStage earlyPostImeStage = new EarlyPostImeInputStage(nativePostImeStage);
InputStage imeStage = new ImeInputStage(earlyPostImeStage,
"aq:ime:" + counterSuffix);
InputStage viewPreImeStage = new ViewPreImeInputStage(imeStage);
InputStage nativePreImeStage = new NativePreImeInputStage(viewPreImeStage,
"aq:native-pre-ime:" + counterSuffix);
mFirstInputStage = nativePreImeStage;
mFirstPostImeInputStage = earlyPostImeStage;
mPendingInputEventQueueLengthCounterName = "aq:pending:" + counterSuffix;
可以看到是一个套一个，我们重点来看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) {
final MotionEvent event = (MotionEvent)q.mEvent;
mAttachInfo.mUnbufferedDispatchRequested = false;
mAttachInfo.mHandlingPointerEvent = true;
boolean handled = mView.dispatchPointerEvent(event);
...
return handled ? FINISH_HANDLED : FORWARD;
}
...
}
InputStage的deliver最终会通过onProcess来区分事件处理（这块就不细说了，没意义），其中我们最关心的事件交给了processPointerEvent来处理。在这里可以看到执行了mView.dispatchPointerEvent(event)，这个View就是我们提到的DecorView。这样我们总算找到了源头，下面看看是怎么传递下去的。
事件传递
dispatchPointerEvent这个函数是View的一个函数，源码：
public final boolean dispatchPointerEvent(MotionEvent event) {
if (event.isTouchEvent()) {
return dispatchTouchEvent(event);
} else {
return dispatchGenericMotionEvent(event);
}
}
到了我们熟悉的dispatchTouchEvent了，这样直接就将事件分发到各个View了？并不是，来看看DecorView中这块是如何处理的：
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
final Window.Callback cb = mWindow.getCallback();
return cb != null && !mWindow.isDestroyed() && mFeatureId < 0
? cb.dispatchTouchEvent(ev) : super.dispatchTouchEvent(ev);
}
可以看到它通过Window获取了callback，然后执行了callback的dispatchTouchEvent。
不知道大家还是否记得我们一开始分析Window的创建的时候提到过（不记得可以回到文章开始看一下），Activity本身实现了Window.Callback接口，并设置给了window的callback。所以这里的callback其实就是Activity，这样事件就传递到了Activity：
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
Activity中之间将事件传递给了Window，调用了它的superDispatchTouchEvent函数，实际上是PhoneWindow的实现：
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
这样就又传递回DecorView了：
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
在DecorView中执行了super.dispatchTouchEvent(event);，它的父类就是ViewGroup，这样就进入了我们熟悉的ViewGroup分发事件的环节了。
setCallBack
通过上面的分析，我们彻底理解了事件是怎么传递到Activity，然后又如何分发到View上的。
但是这里有一个需要注意的点，就是Window的setCallBack函数是对外的，我们可以设置一个自定义的CallBack，但是这样导致Activity这个CallBack被挤掉，结果就是Activity无法接收到事件。
那么事件还能不能分发下去了呢？我们来看看：
getWindow().setCallback(new Window.Callback() {
...
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
return false;
}
...
});
这里不论我们返回true还是false，事件都不会分发下去。根据上面分析我们知道，在Activity中是调用了getWindow().superDispatchTouchEvent(event);才让事件继续分发的。所以这里我们也可以加上这样的代码，当然最好是调用Activity的dispatchTouchEvent，保证流程的完整。
总结
经过上面的分析，我们知道事件传递路径大致是
ViewRoot -> DecorView -> Activity(Window.CallBack) -> Window -> DecorView -> ViewGroup -> ...
后面就是我们熟悉的事件分发流程。
