我们可以回想下,在 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)
}
...
}
注释 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)
}
下面对 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
本节完成了对触摸点的 PointerInputFilters 收集,下一章我们来讲下事件的分发处理