我们可以回想下，在 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 收集，下一章我们来讲下事件的分发处理
