对View事件传递的理解。看的这篇。
对事件传递有了大致的了解。
onInterceptTouchEvent 函数决定是否将事件拦截，拦截之后，该控件的全部子控件接收不到这个事件。onTouchEvent 函数推断是否消费此事件，在父控件把事件传递到子控件的过程中，假设都没有拦截，那么消息会传递究竟层控件，底层控件能够选择消费或者不消费。假设消费，那么事件到此终止，假设没有消费。则一层一层传递给父类。假设中途被拦截了，那么拦截的那个控件充当上述过程的底层控件。最重要的，在这个过程中，事件所经过的控件，都运行了onTouchEvent 方法，仅仅只是返回值不同确定消费与否而已，比方。父控件onTouchEvent返回值为true，子控件为false，且父控件没有拦截。事件的终点是父控件。可是子控件的onTouchEvent方法是运行了！仅仅只是没有消费。
在touch过程中，仅仅有action_dowm事件消费了。才干消费move和up事件。也好理解，不按下，怎么移动和抬起。
之前在研究下拉刷新控件时，遇到的问题：当下拉区域宽度大于临界值时。这时松开手指则開始刷新，假设这时我想取消，那么仅仅能手指向上滑，使这个宽度小于临界宽度再松手就好了，可是，实际的情况是，这时手指向上滑，ListView也開始滑动了，下拉区域就在屏幕之外了。正确的应当是把ListView禁止滑动，过会再取消禁止。当时的解决的方法是在ListView onTouchEvent()中，推断这一情况，并直接返回true就能够解决。当时的理解非常肤浅。仅仅想返回true就把事件消费了。就完事了。如今想想全然不是那回事，所以又一次看那段代码。下拉刷新控件的简单分析
尝试把ListView中super.onTouchEvent(ev)输出，发现这个值是true，感觉不正确啊，和我想的不同，既然都是返回true。为什么还会有上述的解决的方法。于是猜想super.onTouchEvent(ev)不仅仅单纯返回一个true那么简单，可能还响应和改变ListView的滚动栏，打开AbsListView.java。查看这种方法，果然有非常多非常多代码，这样就能够解释了。直接返回true，从而没有运行AbsListView中默认的onTouchEvent方法，所以滚动栏才没有滚动。
ListView相当于父控件。item是子控件。而item布局里的其它控件就是子子控件，依照功能需求能够通过控制touch事件传递来实现。