上篇文章中，分析了我之前关于触摸事件的一点疑问，感兴趣的，可点击触摸事件之onTouch和onTouchEvent查看
趁着热乎劲儿，继续再来巩固下完整的事件分发流程吧。
先不回忆细节，单纯从最简单的角度来看，事件分发无非就3步：事件产生->事件传递->事件处理。就跟春晚小品宋丹丹问赵大叔把大象放进冰箱分几步一个道理。从最原始的角度出发来看待这个问题，中间的过程再逐步细化，这样大脑中有个清晰的流程，分析问题也会顺畅的多。
从手指触摸屏幕的那一刻，触摸事件便产生了，抛开硬件层面的电容电流感应，到应用层的APP层面，最先肯定是由Activity接收到事件，咱们来瞧瞧Activity里面的处理过程；
public boolean dispatchTouchEvent(MotionEvent ev) {
//...
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
里面有行代码很关键，“getWindow().superDispatchTouchEvent(ev)”，事件由window分发，如果返回true,后面的onTouchEvent将不执行，怎么感觉这句话很熟悉？？原来上篇文章刚分析过类似的。继续追查这个window是什么，原来是：
mWindow = new PhoneWindow(this, window, activityConfigCallback);
熟悉安卓界面加载的都知道，phoneWindow跟DecorView密切相关，莫非window将事件传给了DecorView，继续看源码：
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
果然，一切尽在预料之中啊，这种感觉很爽。DecorView中分发过程也很简单，
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
DecorView是一个FrameLayout布局，它由上下两部分组成，上面是actionBar，下面是我们最最亲爱的在setContentView（）方法中传进xml布局文件，生成的视图组。上面的事件已经分发至DecorView了，现在我们将样式设为为noActionBar，那么DecorView布局中就只有一个contentView布局。在上面的方法中，由于FrameLayout没有重写分发方法，所以会接着向上查找分发方法，最终找到ViewGroup中的dispatchTouchEvent方法，而这个viewGroup中的第一个子view就是contentView生成的视图组。接下来看看viewGroup中的分发方法。
for (int i = childrenCount - 1; i >= 0; i--) {
//...
if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {
// Child wants to receive touch within its bounds.
mLastTouchDownTime = ev.getDownTime();
}
//...
}
代码很长，挑关键的看，看到for循环，知道重头戏来了，我们知道DecorView作为所有Activity根视图的外层容器，一个Activity界面就是有一个个ViewGroup不断包含子View构成的，在ViewGroup里对所有子view进行遍历，肯定也会遍历传递处理触摸事件，我们找child和touchEvent两个关键字，找到一个方法
“dispatchTransformedTouchEvent”，进去看一下：
private boolean dispatchTransformedTouchEvent(MotionEvent event, boolean cancel,
View child, int desiredPointerIdBits) {
final boolean handled;
// Canceling motions is a special case. We don't need to perform any transformations
// or filtering. The important part is the action, not the contents.
final int oldAction = event.getAction();
if (cancel || oldAction == MotionEvent.ACTION_CANCEL) {
event.setAction(MotionEvent.ACTION_CANCEL);
if (child == null) {
handled = super.dispatchTouchEvent(event);
} else {
handled = child.dispatchTouchEvent(event);
}
event.setAction(oldAction);
return handled;
}
//...
}
期待已久的child.dispatchTouchEvent(event)出现了！！出现了！！截止到目前为止，根据我们所掌握的信息，可以很肯定的是，
根据child类型的不同，dispatchTouchEvent实现肯定也不同，view类型的不细说了，直接贴代码吧：
public boolean dispatchTouchEvent(MotionEvent event) {
//...
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
if (!result && onTouchEvent(event)) {
result = true;
}
//...
}
ViewGroup相比于View肯定要复杂些，其内部多了要处理子view的情况，在这里贴上一位网友制作的图，个人认为很不错：
途中很清晰的描绘了viewgroup是如何把事件传递给子view的，onInterceptTouchEvent是viewGroup中独有的方法，它的返回值直接决定了是否会将事件传递给子view处理。如果子 View 不处理，这个“锅”就得 ViewGroup 自己担着。所以事件会传递到 super.dispatchTouchEvent()。ViewGroup 类继承自 View 类，也就是进入了前文说的 View 事件分发流程，就相当于询问当前 ViewGroup 自己是否处理这个事件，细节这里就不重复了。如果当前 ViewGroup自己处理了，对于上级 ViewGroup 而言，还是找到了 target，如果当前 ViewGroup 不处理，这个“锅”继续抛给上级 ViewGroup。
当最外层的子view接收到分发事件时，会进入它自身的dispatchTouchEvent方法，当它不拦截时，事件会继续进入到onTouchEvent方法中处理，然后再一级一级向上传递返回值。
以上就是触摸事件分发流程的简要分析，源码也一直在更新。掌握了主要的流程，任他怎么改，也能做到心中有数。
