Flutter Provider 与 GetX 的状态管理

Question

我即将开始新的 Flutter 项目，无法在 Provider 和 GetX 之间做出决定。还有其他options，但我的队友在我完成 Flutter 课程时使用 GetX 深信不疑，他使用 Provider 包进行状态管理。

所以我对这两个库的方法都有粗略的想法，但我真正关心的是何时使用哪个库。另外我没有找到真正有建设性的讨论，尽管有一些批评 GetX 臃肿和作者粗鲁:(

因此，需要技术和诚实的观点。

谢谢

Answer 1

正如有人对我说的关于 Riverpod（提供商改进）与 GetX 的对比：

<块引用>

在一天结束时使用任何可以完成工作的东西。我不认为我们 应该理想化（或狂热）这些框架中的任何一个。人们 接线也不同。一个人可能会觉得更舒服 GetX 和另一个与 Riverpod（各自为政）。

我从 Provider 开始，现在使用 GetX，为什么？因为 GetX 更简单，就这样。

Answer 2

在编写了一些 Flutter 应用程序后，我分心了其他工作。现在我又回来了，并尝试再次决定状态管理解决方案，通过当前批次的 YouTube 视频和 Medium 文章工作。

我最大的问题一直是访问在整个大型应用中保持和维护状态的服务。一个很好的例子是访问“Firebase 身份验证”服务，该服务保存来自小部件树之外的许多 ViewModel/Controllers/etc 的当前用户的详细信息。

Provider - 有很多带有简单示例的视频，但是没有使用 Provider 从 ViewModels/Controllers/etc 访问服务的清晰/简单的方法，我被推向了 BLoC

BLoC - 我反对代码生成和样板，这不是 BLoC，是我 ;-)

Cubit - 看起来更适合我的风格，但在它被吸收回 BLoC 之后，我不确定它是否受欢迎/使用，这对我的决定有影响

RiverPod - 我正在尝试在 ChangeNotifier 上使用 RiverPod 和 StateNotifier，但它仍然不直观，而且我在尝试不可变状态时可能会创建更多错误。 要访问保持状态的服务，我可以绕过 Readers，我确信还有其他一些技术，但在我看来，它们有点迟钝，我担心我是否正在创建一个好的应用程序架构，或者只是试图符合当前的教条

GetX - 一年前编写了几个应用程序后，我选择了 GetX。这是解决我遇到的“状态”问题的清晰/简洁的方法。我仍在努力推进 RiverPod，但我越是挣扎，我就越想放弃它并跳回 GetX。此外，它还为我提供了清晰的导航和其他好东西。 我还从 Ben Butterworth 重新生成了图表，GetX 仍在加速并即将超过 Provider，这是社区接受的好兆头

我写过的最长的回复....

Answer 3

我查看了 GitHub 上流行的状态管理解决方案的星星（有些不是只是状态管理）：

我的观察：GetX（RED 系列）是新产品，并且比 Provider 增长得更快。在几个月内，它将成为领导者，并最终成为明显/安全的选择。这也是我对 Flutter 与 React Native 的看法（让我们不要深入讨论 ?）。因此，我将在本周末开始的新项目中使用 GetX。显然 GetX 的创建者夸大了 GetX 的性能，尽管我认为这不应该阻止人们使用它，除非他们使用它纯粹是因为维护者说得很快。

• Pub.dev likes：GetX 有 3643 个赞，比 Provider 的 3670 个赞略少（少 27 个）。
• GetX 尚未被识别为 Flutter 收藏夹，但 Provider 是。
• Github star：GetX 有 2.8k，Provider 有 3.4k，但 GetX 有更好的发展轨迹。

此外，Navigator 2.0 还没有得到很好的接受，这给您使用大多数这些状态管理解决方案的基本方式增加了混乱。不过，GetX 具有导航功能，因此您不必担心 Navigation 1.0 与 2.0 的混淆。 TLDR：它在混乱的世界中提供了简单性。

您可以从 here 生成图表，它是 Tim Qian 的网站。

Answer 4

好吧！关于这类问题已经有很多答案和意见。最明显的答案是……没有正确的答案。而且不应该有。 除了完成工作之外，还有多种因素。没有完成任何工作的正确方法。但是您应该始终选择与（好吧！没有什么能真正 100% 匹配）您或您的队友的理念相匹配的方式。

我曾经与 Provider 和 Bloc 一起工作，但现在 GetX 变得显而易见，目前，它是 Flutter 开发多个方面的首选解决方案。

我只能分享我对开关背后的推理。也就是说：GetX 是 Fl​​utter 中的一个生态系统/微框架。它并不臃肿，而是它的本意：有点完整的解决方案。我发现只用一个包就可以在一定程度上满足项目要求。使用 Provider 或 Bloc 时这是不可能的。我偶尔会遇到依赖性问题。现在迁移到零安全性是一个更大的问题。我不仅获得了状态管理解决方案，而且还获得了依赖项管理、实用服务、更简单和强大的导航、响应式设计以及在单个包中的关注点分离！

大多数批评 GetX 是因为它没有以所谓的“Flutter 方式”做事。如果 GetX 让我的生活更轻松，我就不会对这种“Flutter 方式”更加粗心。

既然我不认识作者/维护者，也不与他本人互动，那我为什么要关心他是否粗鲁？

GetX 是一个开源项目，社区不断壮大。

Answer 5

我都试过了，加上 RiverPod 以下是我所知道的：

Provider 适用于小型应用程序，但对于大型应用程序，除非您想将其与 get_it 一起使用并编写大量样板，否则它是一个大问题

最好使用 RiverPod（provider 的重写）或 GetX 而不是 provider，因为两者都可以很好且简单地将业务逻辑与 ui 分开.

因此，如果您想知道如何在 GetX 或 RiverPod 之间进行选择，请尝试两者，看看您对哪一个感到满意。 GetX 比 RiverPod 更简单，并且具有状态管理之外的功能，例如导航、小吃店等。另一方面，RiverPod 使用 InheritanceWidget 并有更多选项（提供程序），例如 ProviderScope，它可以让您在小部件树 const 中制作任何小部件（这是我喜欢的最多），所以你可以说 GetX 有更多的东西（除了状态管理），而 RiverPod 有更多的东西（在状态管理中）。

我无法对这两者进行全面比较，但它们都很好（imo 的最佳可用选项），两者都有优点和缺点，因此在决定选择什么或跳到代码编辑器并尝试一下。

Answer 6

就我个人而言，出于几个原因，我会同意你的队友。这绝对不是对提供商或其他任何事情的打击，所有解决方案都很棒，如果它们适合您，那么这才是真正重要的。

A) 您不需要将整个 MaterialApp 包装在一个小部件中，只是为了在需要重建时提供小部件树的范围。如果您需要重建某些东西，只需将其直接包装在一个小部件中，这有助于简化事情。

B) 访问扩展 onInit 的任何类的 GetxController 覆盖替换有状态小部件的 initState。它允许您彻底清理 UI 代码并使用大部分或所有无状态小部件。

C) 将 SingleGetTickerProviderMixin 添加到 GetxController 类允许跨不同页面重用动画和标签控制器，并进一步减少 UI 中的代码

D) Workers 提供了一些很酷的强大功能，可以将侦听器添加到您的可观察流中。

E) 很多很酷的小附加功能可以节省时间，即。 Get.size 与 MediaQuery.of(context).size 相比，前者无需构建方法即可工作，因为它不需要上下文。

总的来说，两者都是不错的选择，而且最容易学习。 Google 推荐 Provider 是有原因的，因为它可靠且简单，而且很重要。再说一次，无论哪种方式你都不会出错。但由于我提到的原因，Getx 成为了我的首选方案。

Answer 7

我想补充一点，没有什么说您不能将两者用于项目的不同方面。

我个人喜欢主要使用 Getx 进行路由，使用 Riverpod 进行状态管理。我很确定还有许多其他方法可以将状态管理与两者混合/匹配并创建适合您的模式。

有些人可能会说这是错误的，但归根结底，如果您和其他人都可以使用该代码，那么就没有错误的答案。

凭直觉行事，最糟糕的行为就是不作为。您以后可以随时修复它。