最后
目前已经更新的部分资料：
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
这里涉及到了WindowManagerService和Binder跨进程通信，读者不需要纠结于详细的细节，只需了解最终在SystemServer进程中，WindowManagerService根据当前的Window创建了SocketPair用于跨进程通信，同时并对App进程中传过来的InputChannel进行了注册，这之后，ViewRootImpl里的InputChannel就指向了正确的InputChannel, 作为Client端，其fd与SystemServer进程中Server端的fd组成SocketPair, 它们就可以双向通信了。
对该流程感兴趣的读者可以参考 这篇文章。
应用整体的事件分发
App端与服务端建立了双向通信之后，InputManager就能够将产生的输入事件从底层硬件分发过来，Android提供了InputEventReceiver类，以接收分发这些消息：
public abstract class InputEventReceiver {
// Called from native code.
private void dispatchInputEvent(int seq, InputEvent event, int displayId) {
// …
}
}
复制代码
InputEventReceiver是一个抽象类，其默认的实现是将接收到的输入事件直接消费掉，因此真正的实现是ViewRootImpl.WindowInputEventReceiver类：
public final class ViewRootImpl {
final class WindowInputEventReceiver extends InputEventReceiver {
@Override
public void onInputEvent(InputEvent event, int displayId) {
// 将输入事件加入队列
enqueueInputEvent(event, this, 0, true);
}
}
}
复制代码
输入事件加入队列之后，接下来就是对事件的分发了，设计者在这里使用了经典的 责任链 模式：对于一个输入事件的分发而言，必然有其对应的消费者，在这个过程中为了使多个对象都有处理请求的机会，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象串成一条链，并沿着这条链一直传递该请求，直到有对象处理它为止。
InputStage
因此，设计者针对事件分发的整个责任链设计了InputStage类作为基类，作为责任链中的模版，并实现了若干个子类，为输入事件按顺序分阶段进行分发处理：
// 事件分发不同阶段的基类
abstract class InputStage {
private final InputStage mNext; // 指向事件分发的下一阶段
}
// InputStage的子类，象征事件分发的各个阶段
final class ViewPreImeInputStage extends InputStage {}
final class EarlyPostImeInputStage extends InputStage {}
final class ViewPostImeInputStage extends InputStage {}
final class SyntheticInputStage extends InputStage {}
abstract class AsyncInputStage extends InputStage {}
final class NativePreImeInputStage extends AsyncInputStage {}
final class ImeInputStage extends AsyncInputStage {}
final class NativePostImeInputStage extends AsyncInputStage {}
复制代码
输入事件整体的分发阶段十分复杂，比如当事件分发至SyntheticInputStage阶段，该阶段为 综合性处理阶段 ，主要针对轨迹球、操作杆、导航面板及未捕获的事件使用键盘进行处理:
final class SyntheticInputStage extends InputStage {
@Override
protected int onProcess(QueuedInputEvent q) {
// 轨迹球
if (…) {
mTrackball.process(event);
return FINISH_HANDLED;
} else if (…) {
// 操作杆
mJoystick.process(event);
return FINISH_HANDLED;
} else if (…) {
// 导航面板
mTouchNavigation.process(event);
return FINISH_HANDLED;
}
// 继续转发事件
return FORWARD;
}
}
复制代码
比如当事件分发至ImeInputStage阶段，即 输入法事件处理阶段 ，会从事件中过滤出用户输入的字符，如果输入的内容无法被识别，则将输入事件向下一个阶段继续分发：
final class ImeInputStage extends AsyncInputStage {
@Override
protected int onProcess(QueuedInputEvent q) {
if (mLastWasImTarget && !isInLocalFocusMode()) {
// 获取输入法Manager
InputMethodManager imm = InputMethodManager.peekInstance();
final InputEvent event = q.mEvent;
// imm对事件进行分发
int result = imm.dispatchInputEvent(event, q, this, mHandler);
if (result == …) {
// imm消费了该输入事件
return FINISH_HANDLED;
} else {
return FORWARD; // 向下转发
}
}
return FORWARD; // 向下转发
}
}
复制代码
当然还有最熟悉的ViewPostImeInputStage，即 视图输入处理阶段 ，主要处理按键、轨迹球、手指触摸及一般性的运动事件，触摸事件的分发对象是View，这也正是我们熟悉的 UI层级的事件分发 流程的起点:
final class ViewPostImeInputStage extends InputStage {
private int processPointerEvent(QueuedInputEvent q) {
// 让顶层的View开始事件分发
final MotionEvent event = (MotionEvent)q.mEvent;
boolean handled = mView.dispatchPointerEvent(event);
//…
}
}
复制代码
读到这里读者应该理解了， UI层级的事件分发只是完整事件分发流程的一部分，当输入事件（即使是MotionEvent）并没有分发到ViewPostImeInputStage（比如在 综合性处理阶段 就被消费了），那么View层的事件分发自然无从谈起，这里再将整体的流程图进行展示以方便理解：
组装责任链
现在我们理解了，新分发的事件会通过一个InputStage的责任链进行整体的事件分发，这意味着，当新的事件到来时，责任链已经组装好了，那么这个责任链是何时进行组装的？
不难得出，对于责任链的组装，最好是在系统服务和Window建立通信成功的时候，而上文中也提到了，通信的建立是执行在ViewRootImpl.setView()方法中的，因此在InputChannel注册成功之后，即可对责任链进行组装：
public final class ViewRootImpl implements ViewParent {
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
// …
// 1.开始根布局的绘制流程
requestLayout();
// 2.通过Binder建立双端的通信
res = mWindowSession.addToDisplay(…)
mInputEventReceiver = new WindowInputEventReceiver(mInputChannel, Looper.myLooper());
// 3.对责任链进行组装
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;
// …
}
}
复制代码
这说明ViewRootImpl.setView()函数非常重要，该函数也正是ViewRootImpl本身职责的体现：
- 1.链接
WindowManager和DecorView的纽带，更广一点可以说是Window和View之间的纽带； - 2.完成
View的绘制过程，包括measure、layout、draw过程； - 3.向DecorView分发收到的用户发起的
InputEvent事件。
最终整体事件分发流程由如下责任链构成：
SyntheticInputStage --> ViewPostImeStage --> NativePostImeStage --> EarlyPostImeStage --> ImeInputStage --> ViewPreImeInputStage --> NativePreImeInputStage
事件分发结果的返回
上文说到，真正从Native层的InputManager接收输入事件的是ViewRootImpl的WindowInputEventReceiver对象，既然负责输入事件的分发，自然也负责将事件分发的结果反馈给Native层，作为事件分发的结束：
public final class ViewRootImpl {
final class WindowInputEventReceiver extends InputEventReceiver {
@Override
public void onInputEvent(InputEvent event, int displayId) {
// 【开始】将输入事件加入队列,开始事件分发
enqueueInputEvent(event, this, 0, true);
}
}
}
// ViewRootImpl.WindowInputEventReceiver 是其子类，因此也持有finishInputEvent函数
public abstract class InputEventReceiver {
private static native void nativeFinishInputEvent(long receiverPtr, int seq, boolean handled);
public final void finishInputEvent(InputEvent event, boolean handled) {
//…
// 【结束】调用native层函数，结束应用层的本次事件分发
nativeFinishInputEvent(mReceiverPtr, seq, handled);
}
}
复制代码
ViewPostImeInputStage：UI层事件分发的起点
上文已经提到，UI层级的事件分发 作为 完整事件分发流程的一部分，发生在ViewPostImeInputStage.processPointerEvent函数中：
final class ViewPostImeInputStage extends InputStage {
private int processPointerEvent(QueuedInputEvent q) {
// 让顶层的View开始事件分发
final MotionEvent event = (MotionEvent)q.mEvent;
boolean handled = mView.dispatchPointerEvent(event);
//…
}
}
复制代码
这个顶层的View其实就是DecorView（参见上文 建立通信-ViewRootImpl的创建 小节），读者知道，DecorView实际上就是Activity中Window的根布局，它是一个FrameLayout。
现在DecorView执行了dispatchPointerEvent(event)函数，这是不是就意味着开始了View的事件分发？
DecorView的双重职责
DecorView作为View树的根节点，接收到屏幕触摸事件MotionEvent时，应该通过递归的方式将事件分发给子View，这似乎理所当然。但实际设计中，设计者将DecorView接收到的事件首先分发给了Activity，Activity又将事件分发给了其Window，最终Window才将事件又交回给了DecorView，形成了一个小的循环：
// 伪代码
public class DecorView extends FrameLayout {
// 1.将事件分发给Activity
@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
return window.getActivity().dispatchTouchEvent(ev)
}
// 4.执行ViewGroup 的 dispatchTouchEvent
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
}
// 2.将事件分发给Window
public class Activity {
public boolean dispatchTouchEvent(MotionEvent ev) {
return getWindow().superDispatchTouchEvent(ev);
}
}
// 3.将事件再次分发给DecorView
public class PhoneWindow extends Window {
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
}
复制代码
事件绕了一个圈子最终回到了DecorView这里，对于初次阅读这段源码的读者来说，这里的设计平淡无奇，似乎说它莫名其妙也不过分。事实上这里是 面向对象程序设计 中灵活运用 多态 这一特征的有力体现——对于DecorView而言，它承担了2个职责：
- 1.在接收到输入事件时，
DecorView不同于其它View，它需要先将事件转发给最外层的Activity，使得开发者可以通过重写Activity.onTouchEvent()函数以达到对当前屏幕触摸事件拦截控制的目的，这里DecorView履行了自身（根节点）特殊的职责； - 2.从
Window接收到事件时，作为View树的根节点，将事件分发给子View，这里DecorView履行了一个普通的View的职责。
实际上，不只是DecorView，接下来View层级的事件分发中也运用到了这个技巧，对于ViewGroup的事件分发来说，其本质是递归思想的体现，在 递流程 中，其本身被视为上游的ViewGroup，需要自定义dispatchTouchEvent()函数，并调用child.dispatchTouchEvent(event)将事件分发给下游的子View；同时，在 归流程 中，其本身被视为一个View，需要调用View自身的方法已决定是否消费该事件（super.dispatchTouchEvent(event)），并将结果返回上游，直至回归到View树的根节点，至此整个UI树事件分发流程结束。
同时，读者应该也已理解，平时所说View层级的事件分发也只是 UI层的事件分发 的一个环节，而 UI层的事件分发 又只是 应用层完整事件分发 的一个小环节，更遑论后者本身又是Native层和应用层之间的事件分发机制的一部分了。
UI层级事件分发
虽然View层级之间的事件分发只是 UI层级事件分发 的一个环节，但却是最重要的一个环节，也是本文的重点，上文所有内容都是为本节做系统性的铺垫 ——为了方便阅读，本小节接下来的内容中，事件分发 统一泛指 View层级的事件分发。
1.核心思想
了解 事件分发 的代码流程细节，首先需要了解整个流程的最终目的，那就是 获知事件是否被消费 ，至于事件被哪个角色消费了，怎么被消费的，在外层责任链中的ViewPostImeInputStage不关心，其更上层ViewRootImpl.WindowInputEventReceiver不关心，native层级的InputManager自然更不会关心了。
因此，设计者设计出了这样一个函数：
// 对事件进行分发
public boolean dispatchTouchEvent(MotionEvent event);
复制代码
对于事件分发结果的接收者而言，其只关心事件是否被消费，因此返回值被定义为了boolean类型：当返回值为true，事件被消费，反之则事件未被消费。
上文中我们同样提到了，在ViewGroup的事件分发过程中，其本身的dispatchTouchEvent(event)和super.dispatchTouchEvent(event)完全是两个完全不同的函数，前者履行的是ViewGroup的职责，负责将事件分发给子View；后者履行的是View的职责，负责处理决定事件是否被消费（参见 应用整体的事件分发-DecorView的双重职责 小节）。
因此，对于事件分发整体流程，我们可以进行如下定义：
- 1、
ViewGroup将事件分发给子View，当子View从ViewGroup中接收到事件，若其有child，则通过dispatchTouchEvent(event)再将事件分发给child…以此类推，直至将事件分发到底部的View，这也是事件分发的 递流程； - 2、底部的
View接收到事件时，通过View自身的dispatchTouchEvent(event)函数判断是否消费事件： - 2.1 若消费事件，则将结果作为
true向上层的ViewGroup返回，ViewGroup接收到true，意味着事件已经被消费，因此跳过了是否要消费该事件的判断，直接向上一级继续返回true，以此类推直到将true结果通知到最上层的View节点； - 2.2 若不消费事件，则向上层返回
false，ViewGroup接收到false，意味着事件未被消费，因此其本身执行super.dispatchTouchEvent(event)——即执行View本身的dispatchTouchEvent(event)函数，并将结果向上级返回，以此类推直到将true结果通知到最上层的View节点。
对于初次了解事件分发机制或者不熟悉递归思想的读者而言，上述文字似乎晦涩难懂，实际上用代码实现却惊人的简单：
// 伪代码实现
// ViewGroup.dispatchTouchEvent
public boolean dispatchTouchEvent(MotionEvent event) {
boolean consume = false;
// 1.将事件分发给Child
if (hasChild) {
consume = child.dispatchTouchEvent();
}
// 2.若Child不消费该事件,或者没有child，判断自身是否消费该事件
if (!consume) {
consume = super.dispatchTouchEvent();
}
// 3.将结果向上层传递
return consume;
}
复制代码
上述代码中已经将 事件分发 最核心的流程表现的淋漓尽致，读者需认真理解和揣摩。View层级的事件传递的真正实现虽然复杂，但其本质却和上述代码并不不同，理解了这个基本的流程，接下来对于额外功能扩展的设计与实现也只是时间问题了。
2.事件序列与分发链
在上一小节中，读者已经了解事件分发的本质原理就是递归，而目前其实现方式是，每接收一个新的事件，都需要进行一次递归才能找到对应消费事件的View，并依次向上返回事件分发的结果。
每个事件都对View树进行一次遍历递归？这对性能的影响显而易见，因此这种设计是有改进空间的。
如何针对这个问题进行改进？首先，设计者根据用户的行为对MotionEvent中添加了一个Action的属性以描述该事件的行为：
- ACTION_DOWN：手指触摸到屏幕的行为
- ACTION_MOVE：手指在屏幕上移动的行为
- ACTION_UP：手指离开屏幕的行为
- …其它Action，比如
ACTION_CANCEL…
定义了这些行为的同时，设计者定义了一个叫做 事件序列 的概念：针对用户的一次触摸操作，必然对应了一个 事件序列，从用户手指接触屏幕，到移动手指，再到抬起手指 ——单个事件序列必然包含ACTION_DOWN、ACTION_MOVE … ACTION_MOVE、ACTION_UP 等多个事件，这其中ACTION_MOVE的数量不确定，ACTION_DOWN和ACTION_UP的数量则为1。
定义了 事件序列 的概念，设计者就可以着手对现有代码进行设计和改进，其思路如下：当接收到一个ACTION_DOWN时，意味着一次完整事件序列的开始，通过递归遍历找到View树中真正对事件进行消费的Child，并将其进行保存，这之后接收到ACTION_MOVE和ACTION_UP行为时，则跳过遍历递归的过程，将事件直接分发给Child这个事件的消费者；当接收到ACTION_DOWN时，则重置整个事件序列：
如图所示，其代表了一个
View树，若序号为4的View是实际事件的消费者，那么当接收到ACTION_DOWN事件时，上层的ViewGroup则会通过递归找到它，接下来该事件序列中的其它事件到来时，也交给4号View去处理。
这个思路似乎没有问题，但是目前的设计中我们还缺少一把关键的钥匙，那就是如何在ViewGroup中保存实际消费事件的View？
为此设计者根据View的树形结构，设计了一个TouchTarget类，为作为一个成员属性，描述ViewGroup下一级事件分发的目标：
public abstract class ViewGroup extends View {
// 指向下一级事件分发的View
private TouchTarget mFirstTouchTarget;
private static final class TouchTarget {
public View child;
public TouchTarget next;
}
}
复制代码
这里应用到了树的 深度优先搜索算法（Depth-First-Search，简称DFS算法），正如代码所描述的，每个ViewGroup都持有一个mFirstTouchTarget, 当接收到一个ACTION_DOWN时，通过递归遍历找到View树中真正对事件进行消费的Child，并保存在mFirstTouchTarget属性中，依此类推组成一个完整的分发链。
比如上文的树形图中，序号为1的
ViewGroup中的mFirstTouchTarget指向序号为2的ViewGroup，后者的mFirstTouchTarget指向序号为3的ViewGroup，依此类推，最终组成了一个 1 -> 2 -> 3 -> 4 事件的分发链。
对于一个 事件序列 而言，第一次接收到ACTION_DOWN事件时，通过DFS算法为View树事件的 分发链 进行初始化，在这之后，当接收到同一事件序列的其它事件如ACTION_MOVE、ACTION_UP时，则会跳过递归流程，将事件直接分发给 分发链 下一级的Child中：
// ViewGroup.dispatchTouchEvent
public boolean dispatchTouchEvent(MotionEvent event) {
boolean consume = false;
// …
if (event.isActionDown()) {
// 1.第一次接收到Down事件，递归寻找分发链的下一级，即消费该事件的View
// 这里可以看到，递归深度搜索的算法只执行了一次
mFirstTouchTarget = findConsumeChild(this);
}
// …
if (mFirstTouchTarget == null) {
// 2.分发链下一级为空，说明没有子View消费该事件
consume = super.dispatchTouchEvent(event);
} else {
// 3.mFirstTouchTarget不为空，必然有消费该事件的View，直接将事件分发给下一级
consume = mFirstTouchTarget.child.dispatchTouchEvent(event);
}
// …
return consume;
}
复制代码
至此，本小节一开始提到的问题得到了解决。
3.事件拦截机制
写在最后
今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。
最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。
还有 高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。
【Android核心高级技术PDF文档，BAT大厂面试真题解析】
【算法合集】
【延伸Android必备知识点】
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
【Android核心高级技术PDF文档，BAT大厂面试真题解析】
[外链图片转存中…(img-6IYDBOcC-1715637219437)]
【算法合集】
[外链图片转存中…(img-CWxSQj65-1715637219438)]
【延伸Android必备知识点】
[外链图片转存中…(img-LjTdFxQA-1715637219438)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
1792
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
