View的事件分发机制总结

1.view的重要性

view的虽称不上Android四大组件，但它的重要性可以说是跟四大组件平级，根据使用频率，甚至比广播跟内容提供器重要。view主要包含两类：ViewGroup和具体的View,有Android开发经验的都知道这两类的区别了。我们时时刻刻都有使用到view，例如TextView、ImageView等，正因为我们时时刻刻都在用，所以就显得特别重要了。

2.view的知识体系

view的事件分发机制、view的绘制流程、滑动冲突解决、熟悉sdk提供的常用view、自定义view相关知识与技巧、view的性能优化。

3.view事件分发的重要性

事件分发作为view的基础知识，view的滑动冲突以及自定义view都需要了解view的事件分发流程，所以足以体现view事件分发机制的重要性。

4、事件分发流程梳理

事件分发流程说简单不简单，说难不难，曾今试过拼命记住这个流程，但发现不久之后都会忘记，因为记的都是别人写出来的总结，所以这次试着自己跟着源码走一遍流程，再用流程图表达出来，就清晰很多了。先上流程图，再跟着流程图走一遍。

View事件分发流程图

顺着箭头走，可以看到事件是被
Activity 的dispatchTouchEvent(MotionEvent ev)方法先拿到的，从方法名可以看出来这个方法就是分发触摸事件的；接着会调用
PhoneWindow 的superDispatchTouchEvent(MotionEvent event)方法，其实PhoneWindow是Window的唯一实现类；再调用
DecorView 的superDispatchTouchEvent(MotionEvent event)方法，DecorView其实就是最顶级的View，继承自FrameLayout，平时我们熟悉的setContentView(R.layout.activity_layout)就是将布局设置到这个DecorView；接着来到
ViewGroup ,这个ViewGroup就是我们平时自己布局里面的最外层的父布局，例如LinearLayout，事件来到这里就会稍微复杂起来了，会根据情况处理事件，首先还是调用ViewGroup的dispatchTouchEvent(MotionEvent ev)方法，在该方法会优先判断disallowIntercept这个布尔值，这个disallowIntercept后面会讲到，如果为true，则说明ViewGroup不消费事件，事件就来到了子
View 的dispatchTouchEvent(MotionEvent event)，这里假设我们的布局是很简单的，一个LinearLayout包含一个Button，这样方面分析，所以这个子View就是Button,如果有设置mOnTouchListener，这事件会来到mOnTouchListener.onTouch(this, event)，如果onTouch方法返回true则该事件就被消费了，返回false的话事件会来到onTouchEvent(event)方法，在该方法会判断mOnClickListener是否被设置，这个监听器是我们平时用的最多的setOnClickListener(@Nullable OnClickListener l)方法，这个方法的优先级从这里可以看出优先级是最低的，因为事件到最后才会来到这里，如果onTouchEvent(event)返回false则会调用ViewGroup的onTouchEvent(ev)，如果ViewGroup的onTouchEvent(ev)还是返回false，则事件最终丢回给Activity的onTouchEvent(ev)方法了，相当于这个事件走了地球一圈都没人要还是回到了原点。

刚刚分析到ViewGroup的时候，当disallowIntercept为false时，事件会来到它的onInterceptTouchEvent(ev)，这个方法的从名字可以看出是否拦截事件的意思，返回true表示拦截，则会交给自己的onTouchEvent(ev)方法，返回false表示不拦截事件，将事件丢给了View的dispatchTouchEvent(MotionEvent event)，也就相当于disallowIntercept等于true。

前面ViewGroup 说到的disallowIntercept变量是通过parent.requestDisallowInterceptTouchEvent(boolean)设置的，设置是否禁止拦截事件的意思，一般子view不希望父类拦截事件的话可以调用该方法，在处理滑动冲突的时候会经常用到这个方法，他的优先级也是最高的。

5.记忆技巧

要想对这个事件流程做到熟练也不易忘记，跟着源码走一遍的必须的，只有自己分析过一遍了才能有更深的体会，过完之后需要再跟着源码将流程图画出来，不要参考别人的流程图这点很重要，熟练的表达才是掌握的最好证明。整个流程就是事件从某个地方出发，一层一层的传递下去，如果在某一层被消费掉的话，则该事件就结束掉了，如果传到最外一层的子view还没被消费的话，该事件又会往回走，往回走如果还是没人消费的话就会回到出发点。

6.解决滑动冲突

滑动冲突是很长见的一种场景，下面是其中一种比较常见的滑动冲突

父View与子View都可以左右滑动.png

例如ViewPager装载多个可以缩放的ZoomImageView，默认情况下ViewPager或拦截滑动事件，所以当ZoomImageView的宽或高大于ViewPager的宽或者高时，这个时候滑动的话应该是滑动ZoomImageView而不是ViewPager。如果没有解决滑动冲突就会出现下面gif的情况

未解决.gif

这种用户体验是为0的，这种情况一般可以使用内部拦截法或外部拦截法处理，下面是内部拦截法的核心代码：

 @Override
    public boolean onTouch(View v, MotionEvent event) {
        ...
         switch (event.getAction()) {
            case MotionEvent.ACTION_DOWN:
                if ((rectF.width() > width + 0.01 || rectF.height() > height + 0.01)) {
                    if (getParent() instanceof ViewPager) {
                        //禁止父类拦截事件
                        getParent().requestDisallowInterceptTouchEvent(true);
                    }
                }
                break;
      ...
    return true;
}

只需要在ZoomImageView的onTouch方法的MotionEvent.ACTION_DOWN事件调用getParent().requestDisallowInterceptTouchEvent(true);就可以了，当ZoomImageView的宽或高大于ViewPager的宽或高时禁止ViewPager拦截事件，最后一行return true则表示该事件自己消费掉了。

解决冲突.gif

滑动冲突还有其他几种场景，但核心都是根据业务需求使用外部拦截或内部拦截基本都可以解决。
view的事件分发机制对于自定义view的作用更是重中之中。