Flutter 的 Widget Key 提议大调整？深入聊一聊 Key 的作用

在 Flutter 里，Key 对象存在的目的主要是区分和维持 Widget 的状态，它是控件在渲染树里的「复用」标识之一，这一点在之前的《深入 Flutter 和 Compose 在 UI 渲染刷新时 Diff 实现对比》聊到过，可以说 Key 的存在关乎了 Flutter 的性能，因为它的作用就是提高 Element Tree 的复用效率，例如减少匹配阶段所需的 Widget 比较次数。

另外通过 Key 还可以提高如 AnimatedList、ListView 里重新排序时对应 Item widget 的效率，通过将 Key 分配给 Item ，Flutter 可以更有效地识别何时添加、删除或更新列表并执行动画，在这个时候， Key 可以确保每个 Item 即使在对列表进行排序时也保持其状态。

大多数情况下，无状态的 Widget 是不需要 Key，而默认情况下，我们在不主动配置 Key 的时候，它会是 null ：

也就是在没有 Key 的情况下，framewok 一般只判断 runtimeType 去决定是否「复用」，举个很老的官方例子，如下图片代码里的 StatelessColorfulTile 所示，它是一个无状态的 StatelessWidget ，显示了一个随机颜色的 200x200 大小的正方形，通过点击右下角按键，每次调整两个方块的位置，可以看到方块可以正常切换：

因为此时没有 Key ，在 Element Tree 只需要判断 runtimeType ，明显此时 Element 符合复用条件，而代码里又是直接使用 StatelessColorfulTile 的 Widget 实例对象进行 tiles.insert(1, tiles.removeAt(0)) ，所以在 Widget 切换位置之后，Element 和 RenderObject 只需要 update 一下新位置 Widget 实例的颜色即可：

但是，如果我们修改为 StatefulWidget ，此时我们再点击右下角按键，可以看到此时颜色方块不会切换了：

因为此时颜色 color 被保存在 State 下，在 Widget 切换位置之后，因为 runtimeType 符合条件，所以 Element 复用，但是颜色被保存在 State 下，State 又是保存在 Element 里，从而导致颜色并没有按照需求被更新切换：

但是，如果这时候我们给两个 StatefulWidget 添加上 Key ，就可以看到它们可以被切换了，因为 canUpdate 判断条件会增加 Key 判断：

也就是，在有了 Key 之后，新 Widget 的 key 就可以在老 Element 列表里进行匹配，从而更新 Element 的位置并刷新 RenderObject，两个 Element 在状态保留的情况下，被 Tree 里调换了位置进行更新，从而实现了切换的效果：

所以，从这个简单的例子，可以直观看到 Key 在有状态的情况下能够发挥的作用，当然，目前在 Flutter 里的 Key 类型很丰富，但是大致可以简单分为两类： Local Keys 和 Global Keys 。

顾名思义就是它的作用范围，举个例子，如果我们给 StatelessColorfulTile 增加了一个 Padding ，再点击切换按键，可以看到此时点击后 Element 一直被重构：

因为此时在 Row 里面，此时处于“一级”位置 children 是两个 Padding，而 Padding 没有 Key，所以它在 runtimeType 条件的情况下，是直接被复用：

而对于 StatelessColorfulTile 而言，它处于 Padding 之下，Padding 不是一个 Multi Child 的控件，所以在 canUpdate 为 false 的时候，Flutter 内部会认为它需要被重新创建：

从这里我们就可以很直观体验到 Local Keys 这个概念：它只作用于标识同一父 Widget 中的 Widget，不能用于识别其父 Widget 之外的 Widget。

同时，我们也可以是直观感受到：Multi Child 和 Single Child 的 Element 对于 Diff 更新时的策略差别。

另外，我们还可以感受到 Widget 作为「配置文件」的存在，要知道，代码里我们操作的一直都是 tiles.insert(1, tiles.removeAt(0)); ，也就是 Widget 的实例化都的对象，虽然 Widget 实例没变，但是 Element 层面还是会根据情况「重新创建」对应的 Element ，由于颜色是在 State 里，所以也就会跟着 Element 重新随机变化。

最后如下图所示，对于 Local Keys 来说，左侧这样的写法是可以的，而右侧这样的写法是违规的：

所以，在 Widget 的 Key 注释里也有这样一句描述：通常情况下，作为另一个 widget 的唯一子项的 widget 不需要显式 Key。

GlobalKey

那么，除开 Local Keys ，Flutter 里还有一个特殊的 GlobalKey，允许开发者在 Widget 树里去「唯一」标识 Widget，并提供 BuildContext(Element)/State 的全局访问：

这里的「唯一」更多体现在当前这一帧里的「唯一」。

比如前面的例子，我们只需要把对应的 Local Keys 换成 GlobalKey ，就可以看到，虽然 Key 所在的 StatelessColorfulTile 还是在 Padding 下的“二级” child ，但是现在点击切换时，它不会被「重新创建」导致颜色发生变化：

这是因为，虽然在 updateChild 的时候，逻辑依然会走到 inflateWidget 去创建 Element ，但是由于是 GlobalKey，所以会从全局保存的 Map 里获取到当前 GlobalKey 绑定的 Element ，从而 retake 复用：

从这里可以看出来， 如果 Element 在同一帧中移动或者删除，并且它具有 GlobalKey，那么它仍然可能被重新激活使用。

所以 GlobalKey 不仅可以作为 Key 区分 Widget ，帧内还可以在 BuildOwner 里“全局”保持住 Element 、State 和关联 RenderObject 的“状态”，即使它出现移动或者删除。

同时，通过 GlobalKey ，我们也可以访问对应的 BuildContext 和 State 数据，甚至是直接给 MaterialApp 添加 GlobalKey 来操作导航：

那么 GlobalKey 这么好用，它又存在什么问题呢？其实在注释里已经有对应说明：

GlobalKey 在使用的过程中可能会出现需要重新设置 [Element] 父级的情况，而这个操作会触发对关联的 [State] 及其所有后代 [State.deactivate] 的调用，还会强制重建所有依赖于 [InheritedWidget] 的控件。

具体就体现在这下面两段代码：

_retakeInactiveElement 内可能会触发所有关联 State 的 deactivate
_activateWithParent 会触发 Element 的 activate ，从而通过 didChangeDependencies 强制重建所有依赖于 [InheritedWidget] 的控件