Provider 与 InheritedWidget
Provider vs. InheritedWidget
我错了吗？或者如果我们只是想将一个值传递给 Widget 树，Provider 只是一个带有 dispose 方法的 InheritedWidget？
Provider 不是必须的，但应该。
首先，它由 Flutter Team 推广，足够灵活，可以处理几乎任何 state-management 解决方案。
说 InheritedWidget 和 dispose 可能不公平，因为 Provider 有太多不同的用例并且继承了一些您可能在其他任何地方都找不到的优化。
如果您在大型应用程序中使用 InheritedWidget，build 方法总是重建整个构建方法。但是使用 Provider 你有 Consumer 小部件，它可以非常具体地控制 build 方法的特定块，所以你有更高的效率。此外，监听器的复杂性低于 InheritedWidgets'（O(N) vs O(N²)）。
问题在于，由于 Flutter 最初旨在成为一个 UI 框架，因此默认的状态管理解决方案也是面向 UI 的。
最后，由于不同的项目需要不同的 state-management 模式，因此一个 package-for-all 场景在我看来是无价的。
是的。 Provider确实大部分是基于Inheritedwidgets的特性。
如果你想自己制作，那很好。但是您很快就会意识到，如果没有提供者，您将拥有数百条无用的重复行。
Provider 基本上采用了 InheritedWidgets 的逻辑，但将样板文件减少到严格的最低限度。
Flutter 文档对此有一个很好的部分，他们在讨论您的应用程序中的状态管理（其中很大一部分是将值传递到树下）。
Flutter has mechanisms for widgets to provide data and services to their descendants (in other words, not just their children, but any widgets below them). As you would expect from Flutter, where Everything is a Widget™, these mechanisms are just special kinds of widgets—InheritedWidget, InheritedNotifier, InheritedModel, and more. We won’t be covering those here, because they are a bit low-level for what we’re trying to do.
Instead, we are going to use a package that works with the low-level widgets but is simple to use. It’s called provider.
因此，截至 2021 年底，似乎建议使用 provider 包，除非您需要较低级别的访问权限——在这种情况下，您可以使用 Inherited* 小部件。例如，如果您编写了自己的 provider 版本，那么您需要较低级别的访问权限。
我上面引用的文档位于 https://docs.flutter.dev/development/data-and-backend/state-mgmt/simple#accessing-the-state
我错了吗？或者如果我们只是想将一个值传递给 Widget 树，Provider 只是一个带有 dispose 方法的 InheritedWidget？
Provider 不是必须的，但应该。
首先，它由 Flutter Team 推广，足够灵活，可以处理几乎任何 state-management 解决方案。
说 InheritedWidget 和 dispose 可能不公平，因为 Provider 有太多不同的用例并且继承了一些您可能在其他任何地方都找不到的优化。
如果您在大型应用程序中使用 InheritedWidget，build 方法总是重建整个构建方法。但是使用 Provider 你有 Consumer 小部件，它可以非常具体地控制 build 方法的特定块，所以你有更高的效率。此外，监听器的复杂性低于 InheritedWidgets'（O(N) vs O(N²)）。
问题在于，由于 Flutter 最初旨在成为一个 UI 框架，因此默认的状态管理解决方案也是面向 UI 的。
最后，由于不同的项目需要不同的 state-management 模式，因此一个 package-for-all 场景在我看来是无价的。
是的。 Provider确实大部分是基于Inheritedwidgets的特性。
如果你想自己制作，那很好。但是您很快就会意识到，如果没有提供者，您将拥有数百条无用的重复行。
Provider 基本上采用了 InheritedWidgets 的逻辑，但将样板文件减少到严格的最低限度。
Flutter 文档对此有一个很好的部分，他们在讨论您的应用程序中的状态管理（其中很大一部分是将值传递到树下）。
Flutter has mechanisms for widgets to provide data and services to their descendants (in other words, not just their children, but any widgets below them). As you would expect from Flutter, where Everything is a Widget™, these mechanisms are just special kinds of widgets—InheritedWidget, InheritedNotifier, InheritedModel, and more. We won’t be covering those here, because they are a bit low-level for what we’re trying to do.
Instead, we are going to use a package that works with the low-level widgets but is simple to use. It’s called provider.
因此，截至 2021 年底，似乎建议使用 provider 包，除非您需要较低级别的访问权限——在这种情况下，您可以使用 Inherited* 小部件。例如，如果您编写了自己的 provider 版本，那么您需要较低级别的访问权限。
我上面引用的文档位于 https://docs.flutter.dev/development/data-and-backend/state-mgmt/simple#accessing-the-state