Compose 事件分发(上) 寻找触摸点

codelang

发布于 2022-08-30 16:53:05

9870

发布于 2022-08-30 16:53:05

文章被收录于专栏：codelang

我们可以回想下，在 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 集：

image-20220524160027633.png

从 root LayoutNode 开始遍历，寻找可以被 hitTest 的 LayoutNodeWrapper，LayoutNodeWrapper 的类结构如下：

image-20220524161951717.png

只有 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