揭开这一面纱的最佳位置是源代码。这些文档在解释这一点方面非常不充分。
dispatchTouchEvent 实际上是在 Activity、View 和 ViewGroup 上定义的。可以将其视为决定如何路由触摸事件的控制器。
例如,最简单的情况是 View.dispatchTouchEvent,它将触摸事件路由到 OnTouchListener.onTouch(如果已定义)或路由到扩展方法 onTouchEvent。
对于ViewGroup.dispatchTouchEvent来说,事情要复杂得多。它需要弄清楚它的哪个子视图应该获取该事件(通过调用 child.dispatchTouchEvent)。这基本上是一个命中测试算法,您可以在其中找出哪个子视图的边界矩形包含触摸点坐标。
但是,在将事件调度到适当的子视图之前,父级可以监视和/或拦截事件。这就是OnInterceptTouchEvent的用途。因此,它首先在执行命中测试之前调用此方法,如果事件被劫持(通过从onInterceptTouchEvent返回true),它会向子视图发送一个ACTION_CANCEL,以便它们可以放弃触摸事件处理(来自以前的触摸事件),从那时起,父级别的所有触摸事件都将调度到onTouchListener.onTouch(如果已定义)或onTouchEvent()。同样在这种情况下,永远不会再调用 onInterceptTouchEvent。
您是否甚至想要覆盖[活动|视图组|View].dispatchTouchEvent?除非您正在执行某些自定义路由,否则可能不应该这样做。
主要的扩展方法是ViewGroup.onInterceptTouchEvent(如果要在父级别监视和/或拦截触摸事件)和View.onTouchListener/View.onTouchEvent(用于主要事件处理)。
总而言之,它过于复杂的设计imo,但Android apis更倾向于灵活性而不是简单性。