View的事件机制分析
为什么要去分析view的事件
关于view的事件，百度google一搜。一批又一批。但是能让人理解的少之又少。换句话说，不是那些作者不懂。只是说，他懂了，但他讲解后不一定能让别人看得懂。我记得有人问我当初是怎么接触自定义view这东西的。因为他们觉得自定义view这个东西很难。我就回了如下几句话：自定义view你把paint和canvas。弄懂了基本也就差不多了。我这边说的是差不多，不是完全，你们别曲解哈= =当然前提是数学和物理要好= =。对于View来说，我认为，paint和canvas都不是重点，如何分析他的事件处理才是重点。下面我们一步步的来了解。
View的结构
想要了解view的事件，他的结构我们是需要知道的，我们先放一张view的结构图。然后根据图来一步步分析：
最顶层的PhoneWindow是什么呢？通过字面意思，我们知道他是手机窗口。我们需要知道window到底是什么才能分析phonewindow的作用。
简单来说，Window是一个抽象类，是所有视图的最顶层容器，视图的外观和行为都归他管，不论是背景显示，标题栏还是事件处理都是他管理的范畴，虽然能管的事情看似很多，但是没实权，因为抽象类不能直接使用。
而 PhoneWindow 作为 Window 的唯一实现类，PhoneWindow 的权利可是非常大大，不过对于我们来说用处并不大。
下面我们来说说DecorView：
这样，我们做个假设，一个跟布局高度是wrap的控件，我们运行之后可以发现，除了那个控件，留下了大量的空白区域，由于我们的手机屏幕不能透明，所以这些空白区域肯定要显示一些东西，那么应该显示什么呢？当然如果你没有设置全屏。我们还会发现标题栏状态栏那些。而这些就是所谓的DecorView。
事件处理的过程
我们先看下下面的表格：
| 事件分发 | dispatchTouchEvent | √ | √ | √ |
| 事件拦截 | onInterceptTouchEvent | X | √ | X |
| 事件消费 | onTouchEvent | √ | √ | √ |
从上表可以看到 Activity 和 View 都是没有事件拦截的，这是因为：
1. Activity 作为原始的事件分发者，如果 Activity 拦截了事件会导致整个屏幕都无法响应事件，这肯定不是我们想要的效果。
2. View最为事件传递的最末端，要么消费掉事件，要么不处理进行回传，根本没必要进行事件拦截。所以我们知道了activity是最上层，而view是最底层，那么结合之前view的结构的那张图，我们可以知道view的传递流程应该是这样：
1 | Activity －> PhoneWindow －> DecorView －> ViewGroup －> ... －> View |
而view的处理恰恰相反，那就是这样:
1 | Activity <－ PhoneWindow <－ DecorView <－ ViewGroup <－ ... <－ View |
如果上面的你理解了，下面这张图，对你来说也就是小意思了。
如果你已经完全理解了上面的内容。那么对于view的事件处理。你已经懂了50%了。
事件分发和拦截
事件分发和拦截的流程其实就是上面那张图。《群英传》中举得例子很恰当。我们现在也对所有的流程对应一个职位:
1 | Activity:公司大boss |
前面已经知道了处理流程，我们这边在写一次。
分发(dispatch)–>拦截(onIntercept)–>消费(ontouch)
public boolean dispatchTouchEvent(MotionEvent ev)
用来进行事件分发。如果事件能够传递到当前view。那么此方法一定会调用，返回结果受当前View的ontouch和下级的dispatchtouchevent影响，表示是否消耗当前事件。
public boolean onInterceptTouchEvent(MotionEvent ev)
在上述方法内部调用，用来判断是否拦截事件，如果当前view拦截了事件，那么在同一序列中此方法不会在调用，返回结果表示是否拦截事件。
public boolean onTouchEvent(MotionEvent event)
在dispatch方法中调用，用来处理点击事件，返回结果表示是否消耗当前事件，如果不消耗，那么当前view再也无法接受事件。
| 事件传递 | 拦截，不继续 | 不拦截，继续 | onIntercept |
| 事件处理 | 处理了，无需审核 | 给上级处理 | ontouch |
默认情况下，我们都是返回false。
默认的点击事件
我们先看下整体的效果图，再来进行点击查看结果：
当然这是一个framelayout。你们只要知道是一层盖一层就对了= = 。那么现在所有的事件我们直接return super来看下效果图：
我们通过上面列举的职位可以分析下情况，具体详情如下：
1 | MainActivity [老板]: dispatchTouchEvent 经理,我准备发展一下电商业务,下周之前做一个淘宝出来. |
可以从log日志中看出，和我们上面的流程是一模一样的。我们尝试下对某个view的TouchEvent 直接拦截了（return true），然后在看看效果图：
流程应该就是这样：
1 | MainActivity [老板]: dispatchTouchEvent 把按钮做的好看一点,要有光泽,给人一种点击的欲望. |
那么我们如果ViewGroup进行拦截处理呢？也就是View的事件不响应了。我们再一次的看看效果图：
流程如下：
1 | MainActivity [老板]: dispatchTouchEvent 现在项目做到什么程度了? |
总结
综上所失，我们可以发现，我们几乎没有在dispatch里面进行任何处理，不是说用不到，只是这个方法用的不多，一般都在拦截和消费里面进行处理，通知上层或者下层是否需要执行。昨天一个小伙伴刚和我说他最近也在重新整理view这块，也是一个功能就要用到了dispatch这个方法。这个具体我就不细说了。你们可以自己理理。
这个篇幅我只是对view做了一个简单的介绍，通过标题“浅析”也知道。不过，如果这篇你们看懂了。对于正常的需求开发已无大碍。后面我尽可能去深入分析一次。
参考文献
《android群英传》
微信
支付宝
