我们可以回想下，在 Android View 体系中，如果我们想对 canvas 的某个绘制部分命中事件点击的话，我们都会给该区域设置个 Rect，然后在 View 事件到来的时候，循环遍历所有的 Rect，然后将 MotionEvent 的坐标与之遍历，看是坐标是否在 Rect 范围内，如果在范围内，则说明命中，我们即可对该 Rect 做事件处理。那么，基于 canvas 绘制的 compose 控件，他的事件响应是否也是这样的呢？
先下个初步结论，原理基本差不多，只不过 compose 做了两层判断，第一层遍历所有 layoutNode 的 modifier 是否有处理点击事件的 pointerInput，如果都没有，则点击没有反应，如果有 pointerInput，再做 MotionEvent 的坐标是否处于该 layoutNode 范围内，如果处于，先收集起来，然后再做接下来的 dispatchToView 处理。即便是嵌套于 compose 的 AndroidView，也是走的这个判断，如果命中，则将事件转发给原生 view。
接下来，我们会开始分析源码，代码尽量简短，然后配合时序图的解释可能会更简单些。
示例：
AppTheme { Surface() { Box( modifier = Modifier .pointerInput(Unit) { detectTapGestures(onPress = { Log.i("TAG", "detectTapGestures onPress") }) }.size(100.dp) ) } 复制代码
组件如果想监听事件变化的话，只需给 Modifier 添加一个 pointerInput 即可
分析：
根据上篇《Compose 中嵌套原生 View 原理》中，我们梳理出了 Compose 的布局层级，我们再把这个图拿出来：
承载于 Compose 的布局为 AndroidComposeView，Android 事件的分发都会通过
AndroidComposeView 的 dispatchTouchEvent 分发给 Compose：
override fun dispatchTouchEvent(motionEvent: MotionEvent): Boolean { ... try { ... val processResult = trace("AndroidOwner:onTouch") { // 1、将 Android 的 MotionEvent 转成通用的 PointInputEvent val pointerInputEvent = motionEventAdapter.convertToPointerInputEvent(motionEvent, this) if (pointerInputEvent != null) { // 2、处理事件 pointerInputEventProcessor.process(pointerInputEvent, this) } ... } 复制代码
- 将 Android 的 MotionEvent 转成通用的 PointInputEvent，转换这个操作我感觉是为了 Compose 更好的跨平台，对于平台相关性的类和事件，都需要通过适配器去做一层转换，但确实会牺牲一定的可读性
- 处理转换后的 pointerInputEvent
注释 1 处的代码我们就不深入跟踪了，仅仅只是将 MotionEvent 的 action 事件、坐标等记录到 PointerInputEventData 这个数据 bean 中，我们直接来看处理事件的 process 方法，
@OptIn(InternalCoreApi::class) // 1、root 为 AndroidComposeView 传进来的根节点 internal class PointerInputEventProcessor(val root: LayoutNode) { ... fun process( pointerEvent: PointerInputEvent, positionCalculator: PositionCalculator ): ProcessResult { // 2、继续包裹一层 bean，将其转成 InternalPointerEvent val internalPointerEvent = pointerInputChangeEventProducer.produce(pointerEvent, positionCalculator) // Add new hit paths to the tracker due to down events. internalPointerEvent.changes.values.forEach { pointerInputChange -> // 3、是否是 down 事件，如果是的话，则需要记录击中路径，有点 TouchTarget 的味道 if (pointerInputChange.changedToDownIgnoreConsumed()) { // 4、获取命中的 PointerInputFilter ，添加到 hitResult 集合 root.hitTest( pointerInputChange.position, hitResult) if (hitResult.isNotEmpty()) { // 5、添加到命中路径，其实就是用一个链表串起来 hitPathTracker.addHitPath(pointerInputChange.id, hitResult) hitResult.clear() } } } // 6、分发事件 Dispatch to PointerInputFilters val dispatchedToSomething = hitPathTracker.dispatchChanges(internalPointerEvent) .... return ProcessResult(dispatchedToSomething, anyMovementConsumed) } 复制代码
- 构造的 root 为 LayoutNode 的根节点，在 AndroidComposeView 中初始化 PointerInputEventProcessor 时传入
- 对 PointerInputEvent 在包裹一下，生成新的 InternalPointerEvent 数据 bean，produce 里面会合并上一次的事件记录
- 判断是否是 down 事件，内部判断逻辑是，上一次事件的 down 为 false，当前事件的 down 为 true
- 从根节点开始遍历，获取命中的 PointerInputFilter ，添加到 hitResult 集合，这个很重要，需要单独聊，他的作用有点类似 View 的 TouchTarget，记录 down 时命中的 Compose 组件，在 move 和 up 时则会直接使用该 hitResult
- 将 hitResult 集合设置到 hitPathTracker 中，内部会对 hitResult 集合转成 Node 链表，在分发时会遍历该链表，需要注意的是，这个链表的顺序是从 parent layoutNode 到 child LayoutNode 的顺序，跟 view 分发一致
- 开发对 PointerInputFilter 集合分发事件，需要单独聊
下面对 4 单独聊，6 会在下一章进行讲解，这两个是重点，4 是寻找可接收事件的 compose 组件，6 是对可接收事件的 compose 组件分发事件。
进入 hitTest 方法查看一番：
class LayoutNode{ ... internal fun hitTest( pointerPosition: Offset, hitPointerInputFilters: MutableList<PointerInputFilter> ) { val positionInWrapped = outerLayoutNodeWrapper.fromParentPosition(pointerPosition) outerLayoutNodeWrapper.hitTest( positionInWrapped, hitPointerInputFilters ) } } 复制代码
你会发现方法内部又会调用 hitTest，直觉来看，这肯定是一个遍历操作，我们需要找到遍历的第一个节点，也就是 AndroidComposeView 中设置 root layoutNode。并且，我们还需要知道 outerLayoutNodeWrapper 是个什么玩意
class LayoutNode{ ... internal val innerLayoutNodeWrapper: LayoutNodeWrapper = InnerPlaceable(this) private val outerMeasurablePlaceable = OuterMeasurablePlaceable(this, innerLayoutNodeWrapper) internal val outerLayoutNodeWrapper: LayoutNodeWrapper get() = outerMeasurablePlaceable.outerWrapper ... } 复制代码
从 LayoutNode 中声明的 outerLayoutNodeWrapper 来看，最终的 outerWrapper 取的是 innerLayoutNodeWrapper，innerLayoutNodeWrapper 有个默认的实现 InnerPlaceable，他是专门用来遍历子 LayoutNode 的 hitTest 操作，他被放在 wrapper 链的最后一个。我们还需要知道 innerLayoutNodeWrapper 被哪些方法持有，最后发现 modifier 的 set(value) 会做合并操作：
override var modifier: Modifier = Modifier set(value) { .... // Create a new chain of LayoutNodeWrappers, reusing existing ones from wrappers // when possible. val outerWrapper = modifier.foldOut(innerLayoutNodeWrapper) { mod, toWrap -> var wrapper = toWrap ... if (mod is PointerInputModifier) { // 设置 modify 链关系 wrapper = PointerInputDelegatingWrapper(wrapper, mod).assignChained(toWrap) } .... } .. }. 复制代码
每次添加新的 modifier 时，都会重新整理 LayoutNodeWrappers 链，modifier 会通过各种继承自 DelegatingLayoutNodeWrapper 的 wrapper 给包裹起来，并通过 assignChained 插入，串联起调用链。这里我绘制了个图，方便记忆调用链，省略的方框是我们自定义设置的 modifier 集：
从 root LayoutNode 开始遍历，寻找可以被 hitTest 的 LayoutNodeWrapper，LayoutNodeWrapper 的类结构如下：
只有 PointerInputDelegatingWrapper 才会走区域击中判断，PointerInputDelegatingWrapper 的 modifier 是 PointerInputModifier ，也即我们示例 demo 中设置的 pointerInput，我们来看下 PointerInputDelegatingWrapper:
override fun hitTest( pointerPosition: Offset, hitPointerInputFilters: MutableList<PointerInputFilter> ) { // 判断 pointer 坐标是否在 layoutNode 区域内 if (isPointerInBounds(pointerPosition) && withinLayerBounds(pointerPosition)) { // 如果在区域中的话，则记录 pointerInputFilter hitPointerInputFilters.add(modifier.pointerInputFilter) // 继续遍历下一个 wrapper val positionInWrapped = wrapped.fromParentPosition(pointerPosition) wrapped.hitTest(positionInWrapped, hitPointerInputFilters) } } 复制代码
当遍历到 wrapper 没有子节点了，则会遍历结束，这时候就拿到了所有的 PointerInputFilters 集合.
如果按照示例 demo 的话，我们应该能命中 1 个 Box 的 pointerInputFilter，但在调试的过程中发现，hitResult 有 2 个 pointerInputFilter，但当我打开 Surface 源码的时候发现，Surface 原来默认添加了个没有处理事件的 pointerInput
总结
本节完成了对触摸点的 PointerInputFilters 收集，下一章我们来讲下事件的分发处理
