BLoC/肘关节

BLoC非常适合 * 复杂 * 应用的 * 复杂 * 状态管理。然而，在BLoC库中有一种更简单的状态管理方法，称为Cubit（Cubit是BLoC的一个子集）。Cubit与BLoC基本相同，除了：
1.较少样板
1.不使用双向流
这使得它更容易学习，并且是进入全面的BLoC驱动的状态管理解决方案的一个奇妙的垫脚石。
目前，我和我的团队正在开发一个非常复杂的应用程序，我们使用的原则是：使用Cubit的，除非有 * 特定 * 的理由使用BLoC。这对我们来说效果很好（85%的应用使用Cubit，15%使用BLoC）。
相对于其他状态管理技术，大多数人可能会推荐Provider或Riverpod（Riverpod =类固醇上的Provider）。它们比Cubit/BLoC更容易学习。除了，仅适用于简单的情况（少数页面应用）。一旦应用变得复杂（身份验证、提要、API调用等），基于Cubit/BLoC的架构将更好地扩展，而且更干净。
此外，生产级Flutter应用最常用的状态管理系统是BLoC/Cubit，所以，如果你正在寻找一个有市场的技能，我会默认使用它。

有用链接：

• Flutter package that contains BOTH BLoC and Cubit.
• The tutorial series I watched to learn BLoC/Cubit (and recommend!).
• I HIGHLY recommend watching this series as well that shows WHERE to put your BLoC/Cubit in an app to align with best practices and clean architecture.

示例应用程序：

这是我制作的一个simple 1-feature app，作为概念验证，展示了Cubit的具体工作原理

结论：

Provider、GetX、Riverpods等都比BLoC更容易学习，包含的样板文件也更少，只是当你的应用变得更复杂时，它们不会像BLoC那样扩展。
为了帮助解决BLoC的样板文件/复杂性问题，在设计中使用Cubits而不是BLoC，除非您特别需要BLoC。

Cubits非常容易理解，可以在大多数Flutter项目中使用。对于更大的应用程序，我会选择Riverpod。拥有独立的提供程序提供了很大的灵活性，因为它们可以在应用程序的不同部分使用，你可以将任何未来的用例或存储库作为提供程序。
我已经写了一个tutorial与Flutter应用程序就如何写一个名单-细节应用程序使用肘，挂钩和本地数据库与Hive。

我建议使用Getx，因为我已经用了2年了，它很棒。因为它让你的代码安排很棒。我在初学的时候就用过它，从来没有遇到过使用任何其他状态管理的需要。