形象一点的例子就是有一个公司，里面有老板，部门经理，组长，实习生。关系层层包含下去，则这里的老板，部门经理，组长都是有下属的（子view），所以他们都是viewGroup，而实习生没有下属，所以他是view。
目前这个公司的权力，有下属的viewGroup有三种选择，分发这个任务(dispatchTouchEvent)，拦截这个任务给自己做(InterceptTouchEvent)，自己处理这个任务(onTouchEvent)。
没下属的实习生（view）接到任务只能做，所以就没有拦截这个选项(interceptTouchEvent)。因为这个实习生（view）也是公司的一员，所以也有dispatchTouchEvent分发任务这个选项（因为谁知道有一天就升职了呢），但是实习生目前没有下属可以分发，所以一般开发的时候view不对dispatchTouchEvent进行操作，接收到事件直接重写onTouchEvent进行操作。
现在来任务了，老板接到任务，他现在有下属，调用dispatchTouchEvent进行任务分配。他现在有三种选择：
1.今天我想工作了，调用interceptTouchEvent拦截这个事件，这样就可以调用自己的onTouchEvent对事件进行操作。
2.这个需求太SB了，不做，直接在dispatchTouchEvent里面返回true，消耗掉这个事件。
3.今天我不想做，把这个给手下搞吧，调用super.dispatchTouchEvent把这个事件分发下去。
那如果事件被分发下来了，接下来部门经理和组长接收到事件后同样会完成这些工作。
1.今天我想工作了，调用interceptTouchEvent拦截这个事件，这样就可以调用自己的onTouchEvent对事件进行操作。
2.这个需求太SB了，不做，直接在dispatchTouchEvent里面返回true，消耗掉这个事件。
3.今天我不想做，把这个给手下搞吧，调用super.dispatchTouchEvent把这个事件分发下去。
4.任务太难了，我觉得我的手下也做不了，直接返回false让上一级去调用onTouchEvent去完成。
那任务一层层分发下去，最后给到实习生，实习生没有下属了，只能乖乖做事。
他现在有两种选择。
1.任务做完了，在onTouchEvent里面返回true。
2.任务搞不定，在onTouchEvent里面返回false，把这个任务还给上一级的onTouchEvent做。
