Flutter BuildContext在颤振中做什么？

BuildContext

做了什么，我们从中得到了什么信息

只是不清楚

在术语

BuildContext

的第9个实例中有一个例子，但不清楚它是如何使用的。这是一组更大的代码中的一部分，我很难理解什么是

BuildContext

---

有人能用简单/非常基本的术语解释一下吗？

BuildContext

就像它的名字所暗示的那样，是构建特定小部件的上下文

如果您以前做过一些React，那么该上下文与React的上下文类似（但使用起来更流畅）；还有一些奖金

一般来说，上下文有两个用例：

• 与父母互动（主要是获取/发布数据）
• 在屏幕上渲染后，获取屏幕大小和位置

第二点很少见。另一方面，第一点几乎无处不在

例如，当您想要推送新路由时，您将执行

Navigator.of（context.pushNamed（'myRoute'）

注意这里的上下文。它将用于获取树中上面的

NavigatorState

小部件的最近实例。然后对该实例调用方法

pushNamed

---

很酷，但是我什么时候想用它

例如，当您希望向下传递数据而不必手动将数据分配给每个小部件的配置时，BuildContext非常有用；您将希望在任何地方访问它们。但你不想把它传递给每一个构造函数

您可以潜在地创建一个全局或单个；但是，当conf更改时，您的小部件将不会自动重建

在本例中，使用

InheritedWidget

。使用它，您可以潜在地编写以下内容：

class Configuration extends InheritedWidget {
  final String myConf;

  const Configuration({this.myConf, Widget child}): super(child: child);

  @override
  bool updateShouldNotify(Configuration oldWidget) {
    return myConf != oldWidget.myConf;
  }
}

然后，这样使用它：

void main() {
  runApp(
    new Configuration(
      myConf: "Hello world",
      child: new MaterialApp(
        // usual stuff here
      ),
    ),
  );
}

多亏了这一点，现在应用程序中的无处不在，您可以使用

构建上下文

访问这些配置。通过做

final configuration = context.inheritFromWidgetOfExactType(Configuration);

更酷的是，所有调用

inheritFromWidgetOfExactType（配置）

的小部件都会在配置更改时自动重建

---

很棒，对吧？

BuildContext

类只不过是对所有构建的小部件树结构中小部件位置的引用

每个flatter小部件都有一个参数为

BuildContext

的

@override build（）

方法

class CartItemWidget extends StatelessWidget {

  @override
  Widget build(BuildContext context) {.....

简单解释一下，

BuildContext

是：

BuildContext只属于一个小部件

BuildContext对象被传递给WidgetBuilder函数

构建上下文只属于一个小部件。

如果小部件“a”有子部件，小部件“a”的

BuildContext

将成为直接子部件

BuildContext

的父BuildContext

阅读本文，很明显，

BuildContexts

是链接的，并且构成了一个

BuildContexts

树（父子关系）

如果我们现在尝试在前面的图中说明BuildContext的概念，我们会得到（仍然是一个非常简化的视图），其中每个颜色代表一个BuildContext（MyApp one除外，它是不同的）：

下面显示了与创建有状态小部件相关的操作/调用序列（的简化版本）

小部件的状态独立于参数，但每次参数改变时，它都会被重建。在这种情况下，需要使用

InheritedWidget

是一种特殊的小部件，它在子树的根位置定义上下文。它可以有效地将该上下文传递给该子树中的每个小部件。对于Flatter开发人员来说，访问模式看起来很熟悉：

class MyInheritedWidget extends InheritedWidget {

MyInheritedWidget({
      Key key,
      @required Widget child,
      this.data,
   }): super(key: key, child: child);

   final data;

   static MyInheritedWidget of(BuildContext context) {
      return context.inheritFromWidgetOfExactType(MyInheritedWidget);
   }

   @override
   bool updateShouldNotify(MyInheritedWidget oldWidget) => data != oldWidget.data;
}

（BuildContext上下文）的静态MyInheritedWidget方法允许所有子部件获取包含上下文的最近的MyInheritedWidget的实例

最后，

updateShouldNotify

overrided方法用于告诉

InheritedWidget

如果对数据应用修改，是否必须将通知传递给所有子widget（已注册/订阅的）

更多信息

什么是BuildContext对象/上下文

在了解BuildCotext之前，我们必须了解元素对象

什么是元素对象

（注意：作为一名颤振开发人员，我们从未使用过Element对象，但我们使用过一个类似Element对象的对象（称为BuildContext对象）

元素对象是当前小部件的构建位置

什么是“构建位置”？

当框架通过调用其构造函数来构建一个小部件对象时，相应地需要为该小部件对象创建一个元素对象

这个元素对象表示小部件的构建位置

此元素对象有许多有用的实例方法

谁使用元素对象及其方法？

它们是使用元素对象及其方法的02个参与方

框架（用于创建RenderObject树等）

开发者（比如我们）

什么是BuildContext对象？

BuildContext对象实际上是元素对象。BuildContext接口用于阻止直接操纵元素对象

因此

BuildContext对象=不推荐的元素对象

（与原始元素对象相比，它包含更少的实例方法）

为什么框架不鼓励元素对象并将其传递给我们？

因为元素对象具有实例