Flutter的内部渲染机制：BuildContext与Element Tree的解释

const组件的存在使得Flutter可以完全跳过与该组件相关的第3步和第4步处理流程，因为const组件的实例每次都是同一个对象，所以根本不存在需要比较的内容。将某个组件提取出来单独定义为一个类，也可以限制第3步的处理流程在树结构中传播的范围，因为setState方法只会将拥有该状态对象的元素标记为“需要重新构建”，而不会自动影响其下方的所有元素（不过，除非有特殊情况阻止它，否则Flutter还是会重新构建这个被标记为“需要重建”的元素的整个子树）。

BuildContext到底是什么

当我第一次了解到这一点的时候，我真的觉得这部分内容非常重要。我真希望当时有人能直接告诉我这些知识，而不是让我通过错误信息自己去慢慢理解。

BuildContext实际上就是一个元素。

就是这么简单。BuildContext在Flutter的源代码中被定义为一个抽象类，实际上它起着接口的作用，而Element则是实现这个接口的具体类。

当Flutter调用你的`build(BuildContext context)`方法时，它传递给你的`context`参数实际上就是那个在树结构中决定该组件位置的对象。你对`context`读取的任何属性或调用的任何方法，其实都是由这个对象自身的实现来处理的。

@override
Widget build(BuildContext context) {
// 这里的context并不是某个独立存在的辅助对象，
// 它本身就是那个负责管理该组件在树结构中位置的元素。
// 它通过`BuildContext`接口暴露给开发者，而不是直接使用`Element`类——这样做的目的之一是为了防止你在`build`方法内部意外地调用那些不应该被使用的`Element`内部方法。
return Container();
}


一旦理解了这一点，很多之前令人困惑的现象就会变得合情合理了。

为什么上下文能够了解元素的祖先信息？

因为元素们构成了一个树结构，而每个元素都会保留对其父元素的引用。当你调用像`Theme.of(context)`这样的方法时，其内部实现会从当前上下文所代表的元素开始，通过`_parent`属性逐层向上查找，直到找到一个其组件类型为`Theme`的祖先元素，然后返回该祖先元素所持有的数据。

这种查找机制之所以能够正常工作，是因为元素们在被插入树结构后就会保持这种父子关系。

// Theme.of(context)会从当前上下文所代表的元素开始，
// 逐层向上查找其祖先元素中那些组件类型为Theme的元素。
final theme = Theme.of(context);


为什么在异步操作间隔后使用上下文有时会出问题？

因为在你等待某个操作结果的过程中，你所引用的那个元素可能已经被从树结构中移除了。

当一个组件被从树结构中移除时，Flutter会调用该元素的`deactivate()`方法。被停用的元素就不再与活跃的树结构相连了——它的父元素引用可能会被清除，此时它就处于一种待处理的状态，要么会被重新插入到树结构中（比如在列表中使用`GlobalKey`移动组件），要么会被永久销毁。

如果你试图使用这个已被停用的元素的上下文来继续查找其祖先元素，Flutter会抛出我们在文章开头提到的那个错误：“尝试查询已停用的组件的祖先是不安全的”，因为此时你尝试遍历的父元素链可能已经不再反映任何有效的信息了。

Future〈void〉 _submit() async {
await someApiCall();

// 如果在上面的异步操作期间该组件被从树结构中移除了——比如用户返回到了之前的页面——
// 那么这个上下文所引用的元素就已经被停用了。
// 此时尝试使用它来获取Navigator.of(context)会引发错误，因为Flutter认为这条父元素链已经不可信任了。
Navigator.of(context).pop();
}


你可能已经使用过这个解决方法，但却并不完全了解它之所以有效的原因：

Future _submit() async {
  await someApiCall();

  // `mounted` 是 `State` 对象中的一个属性，用于判断持有该 `State` 对象的 `StatefulElement` 是否仍然属于活动视图树中——也就是说，它是否还没有被从视图中移除。如果在执行 `await` 操作期间该组件已被移除，那么 `mounted` 的值就会变为 `false`，此时我们应该立即返回而无需继续执行后续代码。
  if (!mounted) return;

  Navigator.of(context).pop();
}

现在你应该清楚地知道为什么这一行代码能够正常工作了，而不仅仅只是知道它确实有效。`mounted` 并不是被硬加到 `State` 对象上的某种“安全标志”；它实际上反映了底层组件是否仍然存在于视图树中。

“查找祖先元素”的工作原理

让我们再深入探讨一下“查找祖先元素”的机制，因为很多难以察觉的错误往往就源于这里：使用错误的上下文，或者假设某个上下文能够了解某些它实际上并不具备的信息。

你编写的每一个组件都会对应一个独立的 `Element`，这个元素在视图树中占据一个固定的位置。而这个元素只知道它上面的那些元素——也就是它的祖先元素链；它根本不知道自己的兄弟组件是什么，更不可能了解它下面的元素。

这意味着，在 `build` 方法内部可以访问的上下文，其作用范围始终局限于该组件在视图树中的具体位置，而且这种作用范围会一直持续到该元素被销毁为止。

在我真正理解这一原理之前，我曾经多次编写过这样的错误代码：

@override
Widget build(BuildContext context) {
  return Scaffold(
    body: ElevatedButton(
      onPressed: () {
        // 这个上下文实际上属于包含 `Scaffold` 的那个组件的 `build` 方法中——也就是说，在视图树中，这个上下文位于 `Scaffold` 的上一层。从这个上下文的角度来看，我们在同一个 `build` 方法中创建的 `Scaffold` 实际上应该是它的后代元素，而不是祖先元素。因此，`ScaffoldMessenger.of(context)` 需要向上搜索才能找到对应的 `Scaffold`，但在这个上下文中并没有这样的元素存在，只有下层的 `Scaffold`。在结构简单的单层应用程序中，这种情况可能不会导致错误；但在结构更复杂的视图中，这种方法要么会完全失败，要么会找到错误的 `Scaffold`。
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('已保存')),
        );
      },
      child: const Text('保存'),
    ),
  );
}

正确的解决方法应该是获取一个实际上位于 `Scaffold` 下方的上下文，这样在向上搜索时才能正确地找到 `Scaffold`。

@override
Widget build(BuildContext context) {
  return Scaffold(
    // Builder是一种专门用于在构建树中的特定位置提供新的BuildContext对象的 widget。由于在这里Builder被作为Scaffold的子节点放置，因此它提供的BuildContext位于Scaffold的下方。当ScaffoldMessenger从这个上下文开始向上遍历时，它会正确地找到这个Scaffold。
    body: Builder(
      builder: (scaffoldContext) {
        return ElevatedButton(
          onPressed: () {
            ScaffoldMessenger.of(scaffoldContext).showSnackBar(
              const SnackBar(content: Text('已保存')),
            );
          },
          child: const Text('保存'),
        );
      },
    ),
  );
}

这种错误在你不了解其内部机制之前看起来似乎是随机的，但一旦你了解了这个逻辑结构，它就会变得完全可预测：上下文查找的过程总是向上进行，从不会向侧面或向下移动，而你的上下文在树结构中的确切位置决定了它能够找到什么内容。
还有另一种相关的查找机制也值得了解，因为Theme.of、MediaQuery.of以及大多数.of(context)方法的内部实现都是基于这种机制的：InheritedWidget。InheritedWidget》是一种特殊的组件，当它被插入到树结构中时，任何它的子元素都可以注册为“依赖项”。
当你调用context.dependOnInheritedWidgetOfExactType()时——实际上Theme.of(context)就是通过这种方式工作的——就会发生两件事：Flutter会沿着元素链向上查找，找到最接近的、类型匹配的InheritedWidget》；同时，它还会在那个父元素上记录下你的当前元素依赖于它这一信息。
第二部分的作用其实比听起来要重要得多。因为一旦某个元素被注册为依赖项，而对应的InheritedWidget》发生了变化，并且它的updateShouldNotify方法返回了true，Flutter就会自动安排所有注册的依赖项进行重新构建——而你根本不需要编写任何订阅或监听相关的代码。
这就是整个机制的核心所在，正是它让Theme.of(context)能够在应用程序的主题发生变化时自动更新用户的界面。这并不是通过轮询来实现的，也不是基于数据流来工作的，而是通过在查找过程中直接在元素上注册依赖关系来完成的。实际上，Provider以及其他几种状态管理方法也是建立在这一机制之上的。

// 这个过程完全可以在合成阶段完成。
// myWidget的RenderObject不需要重新绘制，
// GPU只会调整已绘制图层的显示位置而已。
Transform.translate(
  offset: const Offset(10, 0),
  child: myWidget,
)

// 如果没有key，当你从这个包含三个ItemCard的列表中移除第一个元素时，Flutter会认为：原本位于位置0的ItemCard(item1)现在被替换成了同类型的ItemCard(item2)——由于类型相同，所以它会重用原来的Element，只是更新其对应的部件引用。但它无法知道，实际上应该是在位置1的ItemCard(item2)才应该被重新使用到位置0。
Column(
  children: items.map((item) => ItemCard(item: item)).toList(),
)

class _FormScreenState extends State〈FormScreen〉 {
  // GlobalKey〈FormState〉会将这个键注册到全局注册表中，
  // 并将其与整个应用中当前拥有这个键的任何Form组件关联起来。
  final _formKey = GlobalKey〈FormState〉();

  void _submit() {
    // currentState会查询全局注册表，
    // 找到与该GLOBAL KEY关联的Element，
    // 然后返回它的State对象——在这个例子中，就是FormState对象。
    // 无论(_submit)方法是在组件的哪个位置被调用的，这一过程都是如此。
    // 这与普通的上下文查找机制截然不同，后者只能从固定的起点向上进行查询。
    if (_formKey.currentState!.validate()) {
      // 继续执行提交操作
    }
  }

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: [
          TextFormField(
            validator: (value) =>
                value!.isEmpty ? 'Required' : null,
          ),
          ElevatedButton(
            onPressed: _submit,
            child: const Text('Submit'),
          ),
        ],
      ),
    );
  }
}

// 错误的做法——使用索引作为键值对会完全违背设置键值对的目的。
// 每当列表被重新排序或有项目被删除时，索引值都会发生变化，因此Flutter无法通过索引来区分不同的项目。
ItemCard(key: ValueKey(index), item: item)

// 正确的做法——使用项目自身的唯一标识符作为键值对，这样无论该项目在列表中的位置如何变化，这个唯一标识符都不会改变。
ItemCard(key: ValueKey(item.id), item: item)

import 'package:flutter/material.dart';

class Task {
  final String id;
  final String title;
  bool isDone;

  Task({required this.id, required this.title, this.isDone = false});
}

class TaskListScreen extends StatefulWidget {
  const TaskListScreen({super.key});

  @override
  State createState() => _TaskListScreenState();
}

class _TaskListScreenState extends State {
  final List _tasks = [
    Task(id: '1', title: '撰写文章'),
    Task(id: '2', title: '练习现场编码'),
    Task(id: '3', title: '复习GDE备考题'),
  ];

  void _removeTask(String id) {
    setState(() {
      _tasks.removeWhere((task) => task.id == id);
    });
  }

  void _showSnackbar(BuildContext scaffoldContext, String message) {
    // 这个上下文被正确地放置在Scaffold的下方，因为它是通过列表项内部的Builder传递进来的，而不是通过这个State自己的build方法传递的——后者位于Scaffold的上方。
    ScaffoldMessenger.of(scaffoldContext).showSnackBar(
      SnackBar(content: Text(message)),
    );
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('任务列表')),
      body: ListView.builder(
        itemCount: _tasks.length,
        itemBuilder: (context, index) {
          final task = _tasks[index];

          // 使用任务的ID作为ValueKey，而不是索引。如果某个任务被删除，Flutter会利用这个键来将剩余的Dismissible元素及其携带的拖动偏移状态正确地关联到对应的任务上，而不会错误地关联到当前占据该索引位置的另一个任务。
          return Dismissible(
            key: ValueKey(task.id),
            onDismissed: (_) {
              _removeTask(task.id);
            },
            background: Container(color: Colors.red),
            child: Builder(
              // Builder提供的上下文位于Scaffold的下方，因此通过这个上下文，ScaffoldMessenger可以从这个子树中正确地找到对应的Scaffold。
              builder: (itemContext) {
                return CheckboxListTile(
                  title: Text(task.title),
                  value: task.isDone,
                  onChanged: (value) {
                    setState(() {
                      task.isDone = value ?? false;
                    });
                    _showSnackbar(
                      itemContext,
                      '\({task.title} 已标记为 \){value == true ? "已完成" : "未完成"}',
                    );
                  },
                );
              },
            ),
          );
        },
      ),
    );
  }
}