flutter入门-key

浦东大花菜
154 阅读6分钟

为什么要有key

其实各位熟悉前端框架的大佬应该对key都比较熟悉，如Vue中用key来当作同级别组件的唯一标记，方便在虚拟Dom树Diff的过程中进行组件复用，想必优秀的设计总是趋同，在flutter中也是类似

Widget 更新机制

下面来来看Widget的源码。

@immutable
abstract class Widget extends DiagnosticableTree {
  const Widget({ this.key });
  final Key key;
  ···
  static bool canUpdate(Widget oldWidget, Widget newWidget) {
    return oldWidget.runtimeType == newWidget.runtimeType
        && oldWidget.key == newWidget.key;
  }
}

我们知道 Widget 只是一个配置且无法修改，而 Element 才是真正被使用的对象，并可以修改。

当新的 Widget 到来时将会调用 canUpdate 方法，来确定这个 Element是否需要更新。

canUpdate 对两个（新老） Widget 的 runtimeType 和 key 进行比较，从而判断出当前的 Element 是否需要更新。若 canUpdate 方法返回 true 说明不需要替换 Element，直接更新 Widget 就可以了。

StatelessContainer 比较过程

在 StatelessContainer 中，我们并没有传入 key ，所以只比较它们的 runtimeType。这里 runtimeType 一致，canUpdate 方法返回 true，两个 Widget 被交换了位置，StatelessElement 调用新持有 Widget 的 build 方法重新构建，而我们的 color 实际上就是储存在 widget 中的，因此在屏幕上两个 Widget 便被正确的交换了顺序。

StatefulContainer 比较过程

而在 StatefulContainer 的例子中，我们将 color 的定义放在了 State 中，Widget 并不保存 State，真正 hold State 的引用的是 Stateful Element。

当我们没有给 Widget 任何 key 的时候，将会只比较这两个 Widget 的 runtimeType 。由于两个 Widget 的属性和方法都相同，canUpdate 方法将会返回 true，于是更新 StatefulWidget 的位置，这两个 Element 将不会交换位置。但是原有 Element 只会从它持有的 state 实例中 build 新的 widget。因为 element 没变，它持有的 state 也没变。所以颜色不会交换。这里变换 StatefulWidget 的位置是没有作用的。

而我们给 Widget 一个 key 之后，canUpdate 方法将会比较两个 Widget 的 runtimeType 以及 key。并返回 false。（这里 runtimeType 相同，key 不同）

此时 RenderObjectElement 会用新 Widget 的 key 在老 Element 列表里面查找，找到匹配的则会更新 Element 的位置并更新对应 renderObject 的位置，对于这个例子来讲就是交换了 Element 的位置并交换了对应 renderObject 的位置。都交换了，那么颜色自然也就交换了。

比较范围

为了提升性能 Flutter 的比较算法（diff）是有范围的，它并不是对第一个 StatefulWidget 进行比较，而是对某一个层级的 Widget 进行比较。

···
class _ScreenState extends State<Screen> {
  List<Widget> widgets = [
    Padding(
      padding: const EdgeInsets.all(8.0),
      child: StatefulContainer(key: UniqueKey(),),
    ),
    Padding(
      padding: const EdgeInsets.all(8.0),
      child: StatefulContainer(key: UniqueKey(),),
    ),
  ];
···

在这个例子中，我们将两个带 key 的 StatefulContainer 包裹上 Padding 组件，然后点击交换按钮，会发生下面这件奇妙的事情。

两个 Widget 的 Element 并不是交换顺序，而是被重新创建了。

在 Flutter 的比较过程中它下到 Row 这个层级，发现它是一个 MultiChildRenderObjectWidget（多子部件的 Widget）。然后它会对所有 children 层逐个进行扫描。

在Column这一层级，padding 部分的 runtimeType 并没有改变，且不存在 Key。然后再比较下一个层级。由于内部的 StatefulContainer 存在 key，新旧 key 不同，且现在的层级在 padding 内部，该层级没有多子 Widget。canUpdate 返回 flase，Flutter 的将会认为这个 Element 需要被替换。然后重新生成一个新的 Element 对象装载到 Element 树上替换掉之前的 Element。第二个 Widget 同理。

所以为了解决这个问题，我们需要将 key 放到 Row 的 children 这一层级。

···
class _ScreenState extends State<Screen> {
  List<Widget> widgets = [
    Padding(
      key: UniqueKey(),
      padding: const EdgeInsets.all(8.0),
      child: StatefulContainer(),
    ),
    Padding(
      key: UniqueKey(),
      padding: const EdgeInsets.all(8.0),
      child: StatefulContainer(),
    ),
  ];
···

现在我们又可以愉快的玩耍了（交换 Widget 顺序）了。

Key

Key的种类

key 本身是一个抽象类，有一个工厂构造方法创建ValueKey

  • 直接子类主要有：LocalKey 和 GlobalKey

  • GlobalKey：帮助我们访问某个Widget的信息

  • LocalKey：它用来区别哪个Element要保留，哪个Element要删除。diff 算法核心所在

    • ValueKey ： 以值作为参数 （数字，字符串，任意类型）
    • ObjectKey ： 以对象作为参数
    • LocalKey：(创建唯一标识)

GlobalKey

@optionalTypeArgs
abstract class GlobalKey<T extends State<StatefulWidget>> extends Key {
···
static final Map<GlobalKey, Element> _registry = <GlobalKey, Element>{};
static final Set<Element> _debugIllFatedElements = HashSet<Element>();
static final Map<GlobalKey, Element> _debugReservations = <GlobalKey, Element>{};
···
BuildContext get currentContext ···
Widget get currentWidget ···
T get currentState ···

GlobalKey 继承自 Key，相比与 LocalKey，他的作用域是全局的，而 LocalKey 只作用于当前层级。 整个应用程序里都是唯一的，所以同一个 GlobalKey 只能作用在一个widget上。可以通过 GlobalKey拿到所对应的 state 和 element 或者 widget ，用以改变 state 的状态或者变量值

通过 Global Key 我们获取内容有以下API：

  • currentContext: 可以找到包括renderBox在内的各种element有关的东西
  • currentWidget: 可以得到widget的属性
  • currentState: 可以得到state里面的变量.
Global Key的实现原理

在 GlobalKey 内部有一个静态的_registry Map集合，该集合以 GlobalKey 为 key,以 Element 为Value 。其提供的 currentSate 方法就是以 GlobalKey 对象为 key 获取对应的 Element 对象，然后就可以通过 Element.state 获取具体的值

Key的使用

ValueKey

如果您有一个 Todo List 应用程序，它将会记录你需要完成的事情。我们假设每个 Todo 事情都各不相同，而你想要对每个 Todo 进行滑动删除操作。

这时候就需要使用 ValueKey！

return TodoItem(
    key: ValueKey(todo.task),
    todo: todo,
    onDismissed: (direction){
        _removeTodo(context, todo);
    },
);

ObjectKey

如果你有一个生日应用，它可以记录某个人的生日，并用列表显示出来，同样的还是需要有一个滑动删除操作。

我们知道人名可能会重复，这时候你无法保证给 Key 的值每次都会不同。但是，当人名和生日组合起来的 Object 将具有唯一性。

这时候你需要使用 ObjectKey！

UniqueKey

如果组合的 Object 都无法满足唯一性的时候，你想要确保每一个 Key 都具有唯一性。那么，你可以使用 UniqueKey。它将会通过该对象生成一个具有唯一性的 hash 码。

不过这样做，每次 Widget 被构建时都会去重新生成一个新的 UniqueKey，失去了一致性。也就是说你的小部件还是会改变。（还不如不用😂）

PageStorageKey

当你有一个滑动列表，你通过某一个 Item 跳转到了一个新的页面，当你返回之前的列表页面时，你发现滑动的距离回到了顶部。这时候，给 Sliver 一个 PageStorageKey！它将能够保持 Sliver 的滚动状态。

GlobalKey

GlobalKey 能够跨 Widget 访问状态。 在这里我们有一个 Switcher 小部件，它可以通过 changeState 改变它的状态。

class SwitcherScreenState extends State<SwitcherScreen> {
  bool isActive = false;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Switch.adaptive(
            value: isActive,
            onChanged: (bool currentStatus) {
              isActive = currentStatus;
              setState(() {});
            }),
      ),
    );
  }

  changeState() {
    isActive = !isActive;
    setState(() {});
  }
}

但是我们想要在外部改变该状态，这时候就需要使用 GlobalKey。

class _ScreenState extends State<Screen> {
  final GlobalKey<SwitcherScreenState> key = GlobalKey<SwitcherScreenState>();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: SwitcherScreen(
        key: key,
      ),
      floatingActionButton: FloatingActionButton(onPressed: () {
        key.currentState.changeState();
      }),
    );
  }
}

这里我们通过定义了一个 GlobalKey 并传递给 SwitcherScreen。然后我们便可以通过这个 key 拿到它所绑定的 SwitcherState 并在外部调用 changeState 改变状态了。

avatar
文章
阅读
粉丝