327 lines
20 KiB
Markdown
327 lines
20 KiB
Markdown
本篇将带你深入了解 Flutter 中的手势事件传递、事件分发、事件冲突竞争，滑动流畅等等的原理，帮你构建一个完整的 Flutter 闭环手势知识体系，这也许是目前最全面的手势事件和滑动源码的深入文章了。
|
||
|
||
## 文章汇总地址：
|
||
|
||
> [Flutter 完整实战实战系列文章专栏](https://juejin.im/collection/5db25bcff265da06a19a304e)
|
||
>
|
||
> [Flutter 番外的世界系列文章专栏](https://juejin.im/collection/5db25d706fb9a069f422c374)
|
||
|
||
|
||
Flutter 中默认情况下，以 Android 为例，所有的事件都是起原生源于 `io.flutter.view.FlutterView` 这个 `SurfaceView` 的子类，整个触摸手势事件实质上经历了 **JAVA => C++ => Dart** 的一个流程，整个流程如下图所示，无论是 Android 还是 IOS ，原生层都只是将所有事件打包下发，比如在 Android 中，手势信息被打包成 `ByteBuffer` 进行传递，最后在 Dart 层的 `_dispatchPointerDataPacket` 方法中，通过 `_unpackPointerDataPacket` 方法解析成可用的 `PointerDataPacket` 对象使用。
|
||
|
||
|
||
|
||
**那么具体在 Flutter 中是如何分发使用手势事件的呢？**
|
||
|
||
|
||
## 1、事件流程
|
||
|
||
在前面的流程图中我们知道，在 Dart 层中手势事件都是从 `_dispatchPointerDataPacket` 开始的，之后会通过 `Zone` 判断环境回调，会执行 `GestureBinding` 这个胶水类中的 `_handlePointerEvent` 方法。*(如果对 `Zone` 或者 `GestureBinding` 有疑问可以翻阅前面的篇章)*
|
||
|
||
|
||
如下代码所示， `GestureBinding` 的 `_handlePointerEvent` 方法中主要是 `hitTest` 和 `dispatchEvent`： **通过 `hitTest` 碰撞，得到一个包含控件的待处理成员列表 `HitTestResult`，然后通过 `dispatchEvent` 分发事件并产生竞争，得到胜利者相应。**
|
||
|
||
|
||
```
|
||
void _handlePointerEvent(PointerEvent event) {
|
||
assert(!locked);
|
||
HitTestResult hitTestResult;
|
||
if (event is PointerDownEvent || event is PointerSignalEvent) {
|
||
hitTestResult = HitTestResult();
|
||
///开始碰撞测试了，会添加各个控件，得到一个需要处理的控件成员列表
|
||
hitTest(hitTestResult, event.position);
|
||
if (event is PointerDownEvent) {
|
||
_hitTests[event.pointer] = hitTestResult;
|
||
}
|
||
} else if (event is PointerUpEvent || event is PointerCancelEvent) {
|
||
///复用机制，抬起和取消，不用hitTest，移除
|
||
hitTestResult = _hitTests.remove(event.pointer);
|
||
} else if (event.down) {
|
||
///复用机制，手指处于滑动中，不用hitTest
|
||
hitTestResult = _hitTests[event.pointer];
|
||
}
|
||
if (hitTestResult != null ||
|
||
event is PointerHoverEvent ||
|
||
event is PointerAddedEvent ||
|
||
event is PointerRemovedEvent) {
|
||
///开始分发事件
|
||
dispatchEvent(event, hitTestResult);
|
||
}
|
||
}
|
||
```
|
||
|
||
了解了结果后，接下来深入分析这两个关键方法：
|
||
|
||
#### 1.1 、hitTest
|
||
|
||
`hitTest` 方法主要为了得到一个 `HitTestResult` ，这个 `HitTestResult` 内有一个 `List<HitTestEntry>` 是用于分发和竞争事件的，而每个 `HitTestEntry.target` 都会存储每个控件的 `RenderObject` 。
|
||
|
||
因为 `RenderObject` 默认都实现了 `HitTestTarget` 接口，所以可以理解为： **`HitTestTarget` 大部分时候都是 `RenderObject` ，而 `HitTestResult` 就是一个带着碰撞测试后的控件列表。**
|
||
|
||
事实上 `hitTest` 是 `HitTestable` 抽象类的方法，而 Flutter 中所有实现 `HitTestable` 的类有 **`GestureBinding` 和 `RendererBinding`** ，它们都是 `mixins` 在 `WidgetsFlutterBinding` 这个入口类上，并且因为它们的 `mixins` 顺序的关系，所以 **`RendererBinding` 的 `hitTest` 会先被调用，之后才调用 `GestureBinding` 的 `hitTest` 。**
|
||
|
||
那么这两个 hitTest 又分别干了什么事呢？
|
||
|
||
#### 1.2、RendererBinding.hitTest
|
||
|
||
在 `RendererBinding.hitTest` 中会执行 `renderView.hitTest(result, position: position);` ，如下代码所示，`renderView.hitTest` 方法内会执行 `child.hitTest` ，它将尝试将符合条件的 child 控件添加到 `HitTestResult` 里，最后把自己添加进去。
|
||
|
||
```
|
||
///RendererBinding
|
||
|
||
bool hitTest(HitTestResult result, { Offset position }) {
|
||
if (child != null)
|
||
child.hitTest(result, position: position);
|
||
result.add(HitTestEntry(this));
|
||
return true;
|
||
}
|
||
```
|
||
|
||
而查看 `child.hitTest` 方法源码，如下所示，`RenderObjcet` 中的`hitTest` ，会通过 `_size.contains` 判断自己是否属于响应区域，确认响应后执行 `hitTestChildren` 和 `hitTestSelf` ，尝试添加下级的 child 和自己添加进去，这样的**递归就让我们自下而上的得到了一个 `HitTestResult` 的相应控件列表了，最底下的 Child 在最上面**。
|
||
|
||
```
|
||
///RenderObjcet
|
||
|
||
bool hitTest(HitTestResult result, { @required Offset position }) {
|
||
if (_size.contains(position)) {
|
||
if (hitTestChildren(result, position: position) || hitTestSelf(position)) {
|
||
result.add(BoxHitTestEntry(this, position));
|
||
return true;
|
||
}
|
||
}
|
||
return false;
|
||
}
|
||
```
|
||
|
||
#### 1.3、GestureBinding.hitTest
|
||
|
||
最后 `GestureBinding.hitTest` 方法不过最后把 `GestureBinding` 自己也添加到 `HitTestResult` 里，最后因为后面我们的流程还会需要回到 `GestureBinding` 中去处理。
|
||
|
||
#### 1.4、dispatchEvent
|
||
|
||
`dispatchEvent` 中主要是对事件进行分发，并且通过上述添加进去的 `target.handleEvent` 处理事件，如下代码所示，在存在碰撞结果的时候，是会通过循环对每个控件内部的`handleEvent` 进行执行。
|
||
|
||
```
|
||
@override // from HitTestDispatcher
|
||
void dispatchEvent(PointerEvent event, HitTestResult hitTestResult) {
|
||
///如果没有碰撞结果，那么通过 `pointerRouter.route` 将事件分发到全局处理。
|
||
if (hitTestResult == null) {
|
||
try {
|
||
pointerRouter.route(event);
|
||
} catch (exception, stack) {
|
||
return;
|
||
}
|
||
///上面我们知道 HitTestEntry 中的 target 是一系自下而上的控件
|
||
///还有 renderView 和 GestureBinding
|
||
///循环执行每一个的 handleEvent 方法
|
||
for (HitTestEntry entry in hitTestResult.path) {
|
||
try {
|
||
entry.target.handleEvent(event, entry);
|
||
} catch (exception, stack) {
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
事实上并不是所有的控件的 `RenderObject` 子类都会处理 `handleEvent` ，大部分时候，只有带有 `RenderPointerListener` (RenderObject) / `Listener` (Widget) 的才会处理 `handleEvent` 事件，并且从上述源码可以看出，**handleEvent 的执行是不会被拦截打断的。**
|
||
|
||
那么问题来了，如果同一个区域内有多个控件都实现了 `handleEvent` 时，那最后事件应该交给谁消耗呢？
|
||
|
||
更具体为一个场景问题就是：**比如一个列表页面内，存在上下滑动和 Item 点击时，Flutter 要怎么分配手势事件？** 这就涉及到事件的竞争了。
|
||
|
||
> **核心要来了，高能预警！！！**
|
||
|
||
## 2、事件竞争
|
||
|
||
Flutter 在设计事件竞争的时候，定义了一个很有趣的概念：**通过一个竞技场，各个控件参与竞争，直接胜利的或者活到最后的第一位，你就获胜得到了胜利。** 那么为了分析接下来的“战争”，我们需要先看几个概念：
|
||
|
||
- **`GestureRecognizer`** ：手势识别器基类，基本上 `RenderPointerListener` 中需要处理的手势事件，都会分发到它对应的 `GestureRecognizer`，并经过它处理和竞技后再分发出去，常见有 ：`OneSequenceGestureRecognizer` 、 `MultiTapGestureRecognizer` 、`VerticalDragGestureRecognizer` 、`TapGestureRecognizer` 等等。
|
||
|
||
- **`GestureArenaManagerr`** ：手势竞技管理，它管理了整个“战争”的过程，原则上竞技胜出的条件是 ：**第一个竞技获胜的成员或最后一个不被拒绝的成员。**
|
||
|
||
- **`GestureArenaEntry`** ：提供手势事件竞技信息的实体，内封装参与事件竞技的成员。
|
||
|
||
- **`GestureArenaMember`**：参与竞技的成员抽象对象，内部有 `acceptGesture` 和 `rejectGesture` 方法，它代表手势竞技的成员，默认 `GestureRecognizer` 都实现了它，**所有竞技的成员可以理解为就是 `GestureRecognizer` 之间的竞争。**
|
||
|
||
- **`_GestureArena`**：`GestureArenaManager` 内的竞技场，内部持参与竞技的 `members` 列表，官方对这个竞技场的解释是： **如果一个手势试图在竞技场开放时(isOpen=true)获胜，它将成为一个带有“渴望获胜”的属性的对象。当竞技场关闭(isOpen=false)时，竞技场将寻找一个“渴望获胜”的对象成为新的参与者，如果这时候刚好只有一个，那这一个参与者将成为这次竞技场胜利的青睐存在。**
|
||
|
||
好了，知道这些概念之后我们开始分析流程，我们知道 `GestureBinding` 在 `dispatchEvent` 时会先判断是否有 `HitTestResult` 是否有结果，一般情况下是存在的，所以直接执行循环 `entry.target.handleEvent` 。
|
||
|
||
#### 2.1、PointerDownEvent
|
||
|
||
循环执行过程中，我们知道 `entry.target.handleEvent` 会触发`RenderPointerListener` 的 `handleEvent` ，而事件流程中第一个事件一般都会是 `PointerDownEvent`。
|
||
|
||
> `PointerDownEvent` 的流程在事件竞技流程中相当关键，因为它会触发 `GestureRecognizer.addPointer`。
|
||
|
||
**`GestureRecognizer` 只有通过 `addPointer` 方法将 `PointerDownEvent` 事件和自己绑定，并添加到 `GestureBinding` 的 `PointerRouter` 事件路由和 `GestureArenaManager` 事件竞技中，后续的事件这个控件的 `GestureRecognizer` 才能响应和参与竞争。**
|
||
|
||
|
||
|
||
> 事实上 **Down** 事件在 Flutter 中一般都是用来做添加判断的，如果存在竞争时，大部分时候是不会直接出结果的，而 **Move** 事件在不同 `GestureRecognizer` 中会表现不同，而 **UP** 事件之后，一般会强制得到一个结果。
|
||
|
||
所以我们知道了**事件在 `GestureBinding` 开始分发的时候，在 `PointerDownEvent` 时需要响应事件的 `GestureRecognizer` 们，会调用 `addPointer` 将自己添加到竞争中。之后流程中如果没有特殊情况，一般会执行到参与竞争成员列表的 last，也就是 `GestureBinding` 自己这个 handleEvent 。**
|
||
|
||
如下代码所示，走到 `GestureBinding` 的 `handleEvent` ，在 Down 事件的流程中，一般 `pointerRouter.route` 不会怎么处理逻辑，然后就是 `gestureArena.close` 关闭竞技场了，尝试得到胜利者。
|
||
|
||
```
|
||
@override // from HitTestTarget
|
||
void handleEvent(PointerEvent event, HitTestEntry entry) {
|
||
/// 导航事件去触发 `GestureRecognizer` 的 handleEvent
|
||
/// 一般 PointerDownEvent 在 route 执行中不怎么处理。
|
||
pointerRouter.route(event);
|
||
|
||
///gestureArena 就是 GestureArenaManager
|
||
if (event is PointerDownEvent) {
|
||
|
||
///关闭这个 Down 事件的竞技，尝试得到胜利
|
||
/// 如果没有的话就留到 MOVE 或者 UP。
|
||
gestureArena.close(event.pointer);
|
||
|
||
} else if (event is PointerUpEvent) {
|
||
///已经到 UP 了，强行得到结果。
|
||
gestureArena.sweep(event.pointer);
|
||
|
||
} else if (event is PointerSignalEvent) {
|
||
pointerSignalResolver.resolve(event);
|
||
}
|
||
}
|
||
```
|
||
|
||
让我们看 `GestureArenaManager` 的 `close` 方法，下面代码我们可以看到，如果前面 Down 事件中没有通过 `addPointer` 添加成员到 `_arenas` 中，那会连参加的机会都没有，而进入 `_tryToResolveArena` 之后，**如果 `state.members.length == 1` ，说明只有一个成员了，那就不竞争了，直接它就是胜利者，直接响应后续所有事件。** 那么如果是多个的话，就需要后续的竞争了。
|
||
|
||
```
|
||
void close(int pointer) {
|
||
/// 拿到我们上面 addPointer 时添加的成员封装
|
||
final _GestureArena state = _arenas[pointer];
|
||
if (state == null)
|
||
return; // This arena either never existed or has been resolved.
|
||
state.isOpen = false;
|
||
///开始打起来吧
|
||
_tryToResolveArena(pointer, state);
|
||
}
|
||
|
||
void _tryToResolveArena(int pointer, _GestureArena state) {
|
||
if (state.members.length == 1) {
|
||
scheduleMicrotask(() => _resolveByDefault(pointer, state));
|
||
} else if (state.members.isEmpty) {
|
||
_arenas.remove(pointer);
|
||
} else if (state.eagerWinner != null) {
|
||
_resolveInFavorOf(pointer, state, state.eagerWinner);
|
||
}
|
||
}
|
||
```
|
||
|
||
|
||
#### 2.2 开始竞争
|
||
|
||
那竞争呢？接下来我们以 `TapGestureRecognizer` 为例子，如果控件区域内存在两个 `TapGestureRecognizer` ，那么在 `PointerDownEvent` 流程是不会产生胜利者的，这时候如果没有 MOVE 打断的话，**到了 UP 事件时，就会执行 ` gestureArena.sweep(event.pointer);` 强行选取一个。**
|
||
|
||
而选择的方式也是很简单，**就是 `state.members.first` ，从我们之前 `hitTest` 的结果上理解的话，就是控件树的最里面 Child 了。** 这样胜利的 member 会通过 `members.first.acceptGesture(pointer)` 回调到 `TapGestureRecognizer.acceptGesture` 中，**设置 `_wonArenaForPrimaryPointer` 为 ture 标志为胜利区域，然后执行
|
||
`_checkDown` 和 `_checkUp` 发出事件响应触发给这个控件。**
|
||
|
||
而这里有个有意思的就是 ，Down 流程的 `acceptGesture` 中的 `_checkUp` 因为没有 `_finalPosition` 此时是不会被执行的，**`_finalPosition` 会在 `handlePrimaryPointer` 方法中，获得`_finalPosition` 并判断 `_wonArenaForPrimaryPointer` 标志为，再次执行 `_checkUp` 才会成功。**
|
||
|
||
> `handlePrimaryPointer` 是在 UP 流程中 `pointerRouter.route` 触发 `TapGestureRecognizer` 的 `handleEvent` 触发的。
|
||
|
||
**那么问题来了，`_checkDown ` 和 `_checkUp ` 时在 UP 事件一次性被执行，那么如果我长按住的话，`_checkDown` 不是没办法正确回调了？**
|
||
|
||
|
||
当然不会，在 `TapGestureRecognizer` 中有一个 `didExceedDeadline` 的机制，在前面 Down 流程中，**在 `addPointer` 时 `TapGestureRecognizer` 会创建一个定时器**，这个定时器的时间时 ` kPressTimeout = 100毫秒` ，**如果我们长按住的话，就会等待到触发 `didExceedDeadline` 去执行 `_checkDown` 发出 `onTabDown` 事件了。**
|
||
|
||
|
||
> `_checkDown ` 执行发送过程中，会有一个标志为 `_sentTapDown` 判断是否已经发送过，如果发送过了也不会在重发，之后回到原本流程去竞争，手指抬起后得到胜利者相应，同时在 `_checkUp` 之后 `_sentTapDown` 标识为会被重置。
|
||
|
||
这也可以分析点击下的几种场景:
|
||
|
||
##### 普通按下：
|
||
|
||
- 1、区域内只有一个 `TapGestureRecognizer` ：Down 事件时直接在竞技场 `close` 时就得到竞出胜利者，调用 `acceptGesture` 执行 `_checkUp`，到 Up 事件的时候通过 `handlePrimaryPointer` 执行 `_checkUp`，结束。
|
||
|
||
- 2、区域内有多个 `TapGestureRecognizer` ：Down 事件时在竞技场 `close` 不会竞出胜利者，在 Up 事件的时候，会在 `route` 过程通过`handlePrimaryPointer` 设置好 `_finalPosition`，之后经过竞技场 `sweep` 选取排在第一个位置的为胜利者，调用 `acceptGesture`，执行 `_checkDown` 和 `_checkUp ` 。
|
||
|
||
##### 长按之后抬起：
|
||
|
||
1、区域内只有一个 `TapGestureRecognizer` ：除了 Down 事件是在 `didExceedDeadline` 时发出 `_checkDown ` 外其他和上面基本没区别。
|
||
|
||
- 2、区域内有多个 `TapGestureRecognizer` ：Down 事件时在竞技场 `close` 时不会竞出胜利者，但是会触发定时器 `didExceedDeadline`，先发出 `_checkDown`，之后再经过 `sweep` 选取第一个座位胜利者，调用 `acceptGesture`，触发 `_checkUp `
|
||
|
||
**那么问题又来了，你有没有疑问，如果有区域两个 `TapGestureRecognizer` ，长按的时候因为都触发了 `didExceedDeadline` 执行 `_checkDown ` 吗？**
|
||
|
||
答案是：会的！**因为定时器都触发了 `didExceedDeadline`，所以 `_checkDown ` 都会被执行，从而都发出了 `onTapDown` 事件。但是后续竞争后，只会执行一个 `_checkUp ` ，所有只会有一个控件响应 `onTap` 。**
|
||
|
||
|
||
##### 竞技失败：
|
||
|
||
**在竞技场竞争失败的成员会被移出竞技场，移除后就没办法参加后面事件的竞技了** ，比如 `TapGestureRecognizer` 在接受到 `PointerMoveEvent` 事件时就会直接 `rejected` , 并触发 `rejectGesture` ，之后定时器会被关闭，并且触发 `onTapCancel` ，然后重置标志位.
|
||
|
||
总结下：
|
||
|
||
**Down 事件时通过 `addPointer` 加入了 `GestureRecognizer` 竞技场的区域，在没移除的情况下，事件可以参加后续事件的竞技，在某个事件阶段移除的话，之后的事件序列也会无法接受。事件的竞争如果没有胜利者，在 UP 流程中会强制指定第一个为胜利者。**
|
||
|
||
#### 2.3 滑动事件
|
||
|
||
滑动事件也是需要在 Down 流程中 `addPointer` ，然后 MOVE 流程中，通过在 `PointerRouter.route` 之后执行 `DragGestureRecognizer.handleEvent` 。
|
||
|
||
|
||
|
||
在 `PointerMoveEvent` 事件的 `DragGestureRecognizer.handleEvent` 里，会通过在 `_hasSufficientPendingDragDeltaToAccept `判断是否符合条件，如：
|
||
|
||
```
|
||
bool get _hasSufficientPendingDragDeltaToAccept => _pendingDragOffset.dy.abs() > kTouchSlop;
|
||
```
|
||
|
||
如果符合条件就直接执行 `resolve(GestureDisposition.accepted);` ，将流程回到竞技场里，然后执行 `acceptGesture` ，然后触发`onStart` 和 `onUpdate` 。
|
||
|
||
回到我们前面的上下滑动可点击列表，是不是很明确了：**如果是点击的话，没有产生 MOVE 事件，所以 `DragGestureRecognizer` 没有被接受，而Item 作为 Child 第一位，所以响应点击。如果有 MOVE 事件， `DragGestureRecognizer` 会被 `acceptGesture`，而点击 `GestureRecognizer` 会被移除事件竞争，也就没有后续 UP 事件了。**
|
||
|
||
|
||
那这个 `onUpdate` 是怎么让节目动起来的？
|
||
|
||
我们以 `ListView` 为例子，通过源码可以知道， `onUpdate` 最后会调用到 `Scrollable` 的 `_handleDragUpdate` ，这时候会执行 `Drag.update`。
|
||
|
||
|
||
|
||
|
||
通过源码我们知道 `ListView` 的 `Drag` 实现其实是 `ScrollDragController`, 它在 `Scrollable` 中是和 `ScrollPositionWithSingleContext` 关联的在一起的。那么 `ScrollPositionWithSingleContext` 又是什么？
|
||
|
||
|
||
`ScrollPositionWithSingleContext` 其实就是这个滑动的关键，它其实就是 `ScrollPosition` 的子类，而 `ScrollPosition` 又是 `ViewportOffset` 的子类，而 `ViewportOffset` 又是一个 `ChangeNotifier`，出现如下关系：
|
||
|
||
> 继承关系：**ScrollPositionWithSingleContext : ScrollPosition : ViewportOffset : ChangeNotifier**
|
||
|
||
所以 **ViewportOffset** 就是滑动的关键点。上面我们知道响应区域 `DragGestureRecognizer` 胜利之后执行 `Drag.update` ，最终会调用到 `ScrollPositionWithSingleContext` 的 `applyUserOffset`，导致内部确定位置的 `pixels` 发生改变，并执行父类 `ChangeNotifier ` 的方法`notifyListeners` 通知更新。
|
||
|
||
|
||
而在 `ListView` 内部 `RenderViewportBase` 中，这个 `ViewportOffset` 是通过 `_offset.addListener(markNeedsLayout);` 绑定的，so ，**触摸滑动导致 `Drag.update` ，最终会执行到 `RenderViewportBase` 中的 `markNeedsLayout` 触发页面更新。**
|
||
|
||
|
||
至于 `markNeedsLayout` 如何更新界面和滚动列表，这里暂不详细描述了，给个图感受下：
|
||
|
||
|
||
|
||
|
||
|
||
>自此，第十三篇终于结束了！(///▽///)
|
||
|
||
### 资源推荐
|
||
|
||
* 本文Demo ：https://github.com/CarGuo/state_manager_demo
|
||
* Github ： [https://github.com/CarGuo/](https://github.com/CarGuo)
|
||
* **开源 Flutter 完整项目：https://github.com/CarGuo/GSYGithubAppFlutter**
|
||
* **开源 Flutter 多案例学习型项目: https://github.com/CarGuo/GSYFlutterDemo**
|
||
* **开源 Fluttre 实战电子书项目：https://github.com/CarGuo/GSYFlutterBook**
|
||
|
||
##### 完整开源项目推荐：
|
||
|
||
* [GSYGithubApp Flutter](https://github.com/CarGuo/GSYGithubAppFlutter )
|
||
* [GSYGithubApp React Native](https://github.com/CarGuo/GSYGithubApp )
|
||
* [GSYGithubAppWeex](https://github.com/CarGuo/GSYGithubAppWeex)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|