Flutter手势源码解析

1.手势处理流程

从runApp函数启动入口，主要使用WidgetsFlutterBinding进行渲染前的绑定，WidgetsFlutterBinding继承了多个Binding用于扩展功能，其中GestureBinding用于手势处理。

GestureBinding初始化时，_handlePointerDataPacket方法绑定到platformDispatcher的onPointerDataPacket事件上。

图1.1 GestureBinding初始化

从此处可以判断onPointerDataPacket是在Framework层首先接收手势事件的入口。_dispatchPointerDataPacket接收到由Embedder层的发起的手势事件，并通过_unpackPointerDataPacket转换成Framework层适配的手势数据。

此处@pragma注释将阻止AOT编译器将改方法优化。这里说明@pragma主要用于标记与Engine层交互的内容，dart层面的AOP也是基于该注解实现。

图1.2 embedder层通过engine层传递到framework

此时重新看GestureBinding的_handlePointerDataPacket方法实现。

_pendingPointerEvents作为一个队列，将加入一条手势事件。此时收到的PointerDataPacket事件里面的数据源还是基于Engine层，与Framework层的坐标系不一致。locked变量将控制手势事件的处理队列永远在当前最近的一次帧刷新触发之后，类似于Android Handler中的同步屏障效果，只是dart使用变量实现了类似于锁的机制，具体机制由渲染相关文章进行说明。

当当前时机可以让手势处理时，_flushPointerEventQueue方法中，将循环取出当前队列的队头事件，并使用handlePointerEvent进行具体处理。

图1.3 手势事件加入队列并循环取出进行处理

PointerEventConverter.expand将PointerDataPacket的数据转变为Framework层的数据，由方法实现中可以看出，PointerData类型的数据，携带的都是像素单位，需要转换成Flutter的逻辑像素单位，此时得出的Flutter的屏幕显示单位公式：

LogicalPixel * DevicePixelRatio = PhysicalPixel

此处也说明了，如果在Flutter层要直接与Engine的渲染方法进行交互，必须查看相关方法是否进行了单位转换，否则在不同屏幕上的效果会出现单位问题。

图1.4 Engine层数据转换为Flutter坐标系

handlePointerEvent主要是调用_handlePointerEventImmediately方法进行实现。这边额外加入了一个多点触控的支持，如果支持后，处理流程将转至多点触控的处理队列。

图1.5 handlePointerEvent实现

_handlePointerEventImmediately将手势事件分成3个条件进行处理：

1.按下/焦点/平移/缩放

此类事件，将会新建一个HitTestResult用于存储手势命中的结果，并且调用hitTest进行递归增加符合的命中结果。如果是点击和平移/缩放，还会将将命中结果存到_hitTests的映射表中，key为事件的唯一识别。

2.松开/失去焦点/结束平移/结束缩放

移除_hitTests中相关事件命中结果。

3.持续性事件

获取_hitTests相关的事件命中结果。

如果有手势命中的结果，则调用dispatchEvent方法。

图1.6 _handlePointerEventImmediately实现

这边主要是hitTest方法的实现。GestureBinding继承HitTestable，RenderBinding继承GestureBinding，所以在_handlePointerEventImmediately中调用的hitTest方法，实际是调用RenderBinding的hitTest方法。

hitTest实际调用了rederView.hitTest方法，renderView为RenderObject树的根节点。

super.hitTest将调用GestureBinding的hitTest方法。

1.rederView.hitTest

判断RenderView下是否存在子RenderBox，如果存在的话则优先使用子节点进行判定，并且无条件将自己加入到命中测试结果中。

2.super.hitTest

无条件将自己加入到命中测试结果中。

3.renderBox.hitTest

RenderBox中将判定事件的坐标点是否在RenderObject的绘制区域中，如果处于区域，则像判断下级的RenderObject节点是否满足条件，满足 条件则将当前节点加入命中结果。此处可以看见满足条件分别为子节点是否命中区域或者自己是否命中，此处hitTestSelf默认false，如重写为true，则可以强制将当前的节点视为命中结果。

通过流程可以得知，hitTest调用链是从RenderView自顶向下，事件命中结果存储的顺序则为自顶向上，最后收集的结果全部在BoxHitTestResult._path 。Flutter相关的事件传递机制类似Android的View事件传递，都是从根节点分发到子节点，然后通过子节点的结果来执行链式调用，Flutter可以通过重写hitTestSelf或者hitTestChildren的返回值修改手势事件的传播，类似于Android的onInterceptTouchEvent方法。

图1.7 hitTest在GestureBinding的具体实现

图1.8 hitTest在RenderBinding中的具体实现

图1.9 hitTest在RenderView的具体实现

图1.10 hitTest在RenderBox的具体实现

知道了收集hitTest的结果后命中的RenderObject后，将调用GestureBinding的dispatchEvent方法。

这里先可以看见，如果有测试结果的话，会先调用PointerRouter.route方法，这个方法相关逻辑在第二章节分析。

后面的循环就能看见，hitTestResult将自顶向上循环调用继承HitTestTarget的所有类，这里可以发现RenderObject默认继承了HitTestTarget接口，所以每个RenderBox都会调用handleEvent，默认为空方法，所以正常的RenderObject可以接收事件，只是无法实现具体的逻辑。

图1.11 dispatchEvent具体实现

图1.12 RenderBox的handleEvent具体实现

图1.13 RenderObject的handleEvent具体实现

2.手势竞争流程

第一章结尾，在dispatchEvent中，调用了pointerRouter.route方法，该方法明显不是基于RenderObject树进行传播的流程。

此时查看GestureDetector组件的内部，GestureDetector的build方法包含了绝大部份的逻辑。

GestureDetector中各事件的回调，会根据事件的类型，封装在gestures的Map中，并且传递给RawGestureDetector, GestureDetector是对RawGestureDetector封装了一层的组件，屏蔽了自定义的配置。

图1.14 GestureDetector的build方法具体实现

RawGestureDetector中具体实现方法大部分在build方法中，可以GestureDetector具体有Listener进行实现。由于Listener继承SingleChildRenderObjectWidget，所以Widget所对应的RenderObject节点为RenderPointerListener，RenderPointerListener继承于RenderBox，根据第一章分发事件处理的逻辑，最后回调触发_handlePointerDown和_handlePointerPanZoomStart中的逻辑。

图1.15 Listener相关逻辑实现

_handlePointerDown和_handlePointerPanZoomStart里面的逻辑比较类似，其中分析_handlePointerDown的流程，可以发现将事件分发到所设置的回调中。GestureRecognizer是一个抽象类，具体的设置已经在GestureDetector中实现过。TapGestureRecongnizer的顶层父类是OneSequenceGestureRecognizer，OneSequenceGestureRecognizer实现了addPointer的具体实现。

如果isPointerAllow（设备支持该事件）为true，则具体实现addAllowedPointer中主要是调用了startTrackingPointer，可以看见对于事件，被添加到全局的pointRouter中，对应了第一章的pointerRouter.route相关逻辑。在分发处理事件时，由于GestureDetector不属于RenderBox的子类，所以将回调的方法放入PointerRouter中进行处理。

图1.16 _handlePointerDown相关逻辑实现

由于第一章分析道GestureBinding处于结果列表的最后，所以最终必定会执行GestureBinding的handleEvent方法，可以看见当时期开始时，将使用手势竞技场的close方法。

最终在_tryToResolveArena种，可以看见3种情况：

1.如果竞技场中只有一个相关事件

直接取当前事件为竞技场胜利者。

2.如果竞技场中没有相关事件

清除竞技场相关事件。

3.如果竞技场已经决出了胜者

除了胜者通知acceptGesture，失败者全部通知rejectGesture。

这些判断条件没有符合多事件冲突，说明在事件点击时，竞技场无法判断最终处理者。此时将使用sweep来获取最终胜者。

sweep中可以看见，多事件时，将会直接取渲染树最深的节点作为胜者，其余的节点都为败者。

具体accpetGesture在不同的子类有不同的实现，大致为触发xxxCancel事件。

图1.17 竞技场竞争相关逻辑实现