flutter - Builder 与 GlobalKey

Question

许多与构建 Flutter UI 相关的问题归结为错误的 BuildContext(例如显示 SnackBar)。答案通常提供使用 Builder 或使用 GlobalKey。两者都有效，但我注意到 GlobalKey 的文档状态:

Global keys are relatively expensive. If you don't need any of the features listed above, consider using a Key, ValueKey, ObjectKey, or UniqueKey instead.

所指的功能是唯一标识和子树重新父代。在这些情况下使用 GlobalKey 的“相对费用”是否足以使用 Builder 代替？

Answer 1

我们倾向于避免使用 GlobalKey 的真正原因与性能无关。这与它在 flutter 中打破了一些模式有关。

根据定义，小部件不应访问其他小部件的具体信息(例如它们的大小或位置)。并且 GlobalKey 授予访问此类信息的能力；允许人们做反模式的事情。

将 GlobalKey 视为弹出 Flutter 的响应层的一种手段。

一些人们想用 GlobalKey 做什么的例子:

• 拥有一个公共(public)单例 GlobalKey。用作不提升状态的手段。使小部件之间的交互难以预测，因为关系不再是单向的(父 -> 子成为双向关系)
• 使用 GlobalKey 计算布局的大小。然后使用此信息触发重新渲染。相反，这是 RenderObject 的角色，不应该在小部件中完成。这使得布局更难维护

---

另一方面，

Builder 和类似的东西不会破坏这些模式。因为，根据定义，Builder什么都不做。这只是使用不同 BuildContext 的一种巧妙方式。

这通常意味着，如果您可以使用 Builder 而不是 GlobalKey 解决布局问题，那么您就走上了可维护布局的正确轨道。

---

那么什么时候使用GlobalKey？

好吧，如果可以的话，永远不要。尝试改用诸如 context.ancestorStateOfType 或 context.inheritWidgetOfExtactType 之类的东西。您可能还需要考虑为特定布局创建自定义 RenderObject。 RenderObject 结合 parentData 如果您需要父/子之间的关系，也可能是您想要的

但这可能更复杂。它可能会花费比您想要的更多的时间。或者您可能会陷入使用当前 API 难以实现的边缘情况。

在这种情况下，只要您知道潜在的后果，就可以使用 GlobalKey。