状态管理中的声明式编程思维
Flutter应用是 声明式 的，这也就意味着 Flutter 构建的用户界面就是应用的当前状态，在 Flutter 应用中，当状态变化时，会重新构建部分界面，而不是原生Android或iOS的命令式。当Flutter应用的状态发生改变时（例如：点击了一个按钮，触发了某个动画或者某个值的更新），改变状态就会导致UI界面重绘。去改变用户界面本身是没有必要的（例如 widget.setText ），因为这样的代码不会在UI界面上更新，只要改变了状态，那么用户界面将重新构建。
通过setState更新
class MyHomePage extends StatefulWidget {
const MyHomePage({super.key, required this.title});
final String title;
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
int _counter = 0;
void _incrementCounter() {
setState(() {
_counter++;
});
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text(widget.title),
),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
const Text(
'You have pushed the button this many times:',
),
Text(
'$_counter',
style: Theme.of(context).textTheme.headlineMedium,
),
],
),
),
floatingActionButton: FloatingActionButton(
onPressed: _incrementCounter,
tooltip: 'Increment',
child: const Icon(Icons.add),
), // This trailing comma makes auto-formatting nicer for build methods.
);
}
}
从上述代码可以看出，如果我们需要改变某个值，只需要使用 setState((){ }) 在此函数中更新就会导致界面重绘，会重新执行build构建UI，前提是此Widget是StatefulWidget的子类。
State方式的状态属于短暂状态，widget 树中其他部分不需要访问这种状态。不需要去序列化这种状态，这种状态也不会以复杂的方式改变，需要用的只是一个 StatefulWidget。
了解Provider
如果我们想在应用中的多个部分之间共享一个非短时的状态，并且在用户会话期间保留这个状态，我们称之为应用状态（有时也称共享状态）,为了管理应用状态，就需要研究使用Provider。
示例
假设我们有2个页面，A页面编辑的信息，在B页面需要使用，那此时我们可能无法在B中使用State拿到A页面的信息，此时Provider就帮上忙了，需要访问一些全局的状态。比如，A页面的会被添加到B页面中。但是它可能需要检查和自己相同的元素是否已经被添加到B页面中。
这里我们出现了第一个问题：我们把当前页面的状态放在哪合适呢？
提高状态的层级
在 Flutter 中，有必要将存储状态的对象置于 widget 树中对应 widget 的上层。
为什么呢？在类似 Flutter 的声明式框架中，如果你想要修改 UI，那么你需要重构它。并没有类似 B.updateWith(newData) 的简单调用方法。很难通过外部调用方法修改一个 widget。即便自己实现了这样的模式，那也是和整个框架不相兼容。
比如在B页面的入口在A页面，那需要在A页面创建Provider，在B中可以共享到A页面创建的 数据，更新数据后A也能同步到最新的数据。
void onTap(BuildContext context) {
var model = ProviderModel(context);
model.add(item);
}
这里 B页面 可以在各种版本的 UI 中调用同一个代码路径，获取数据
Widget build(BuildContext context) {
var model = ProviderModel(context);
return Continer(
// ···
);
}
在上面的例子中，model会存在于A-B 的生命周期中。当它发生改变的时候，它会从上层重构 B页面 。因为这个机制，所以 B页面 无需考虑生命周期的问题—它只需要针对 providerModel声明所需显示内容即可。当内容发生改变的时候，旧的 B的 widget 就会消失，完全被新的 widget 替代。
如何使用
在使用 provider 之前，请不要忘记在 pubspec.yaml 文件里加入依赖。
运行 flutter pub add 将 provider 添加为依赖：
flutter pub add provider
现在可以在代码里加入 import 'package:provider/provider.dart'; 进而开始构建你的应用了
provider 你无须关心回调或者 InheritedWidgets。但是你需要理解三个概念：
- ChangeNotifier
- ChangeNotifierProvider
- Consumer
ChangeNotifier
ChangeNotifier 是 Flutter SDK 中的一个简单的类。它用于向监听器发送通知。换言之，如果被定义为 ChangeNotifier，你可以订阅它的状态变化。（这和大家所熟悉的观察者模式相类似）。
在 provider 中，ChangeNotifier 是一种能够封装应用程序状态的方法。对于特别简单的程序，你可以通过一个 ChangeNotifier 来满足全部需求。在相对复杂的应用中，由于会有多个模型，所以可能会有多个 ChangeNotifier。 (不是必须得把 ChangeNotifier 和 provider 结合起来用，不过它确实是一个特别简单的类)。
在示例中用 ChangeNotifier 来管理状态。我们创建一个新类，继承它（可以把他理解成MVVM中的viewModel），像下面这样：
class ProviderModel extends ChangeNotifier {
/// Internal, private state of the cart.
final List<Item> _items = [];
/// An unmodifiable view of the items in the cart.
UnmodifiableListView<Item> get items => UnmodifiableListView(_items);
/// The current total price of all items (assuming all items cost $42).
int get totalPrice => _items.length * 42;
/// Adds [item] to cart. This and [removeAll] are the only ways to modify the
/// cart from the outside.
void add(Item item) {
_items.add(item);
// This call tells the widgets that are listening to this model to rebuild.
notifyListeners();
}
/// Removes all items from the cart.
void removeAll() {
_items.clear();
// This call tells the widgets that are listening to this model to rebuild.
notifyListeners();
}
}
唯一一行和 ChangeNotifier 相关的代码就是调用 notifyListeners()。当模型发生改变并且需要更新 UI 的时候可以调用该方法。而剩下的代码就是 ProviderModel 和它本身的业务逻辑。可以这么理解，调用了 notifyListeners()之后，会执行创建Provider的Build方法重新构建UI
如果使用创建的Provider：
class MyApp extends StatelessWidget {
const MyApp({super.key});
// This widget is the root of your application.
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
primarySwatch: Colors.blue,
),
home: ChangeNotifierProvider(
create: (context) => ProviderModel(), child: MyHomePage(title: 'Flutter Demo Home Page')),
);
}
}
或者
class MyApp extends StatelessWidget {
const MyApp({super.key});
// This widget is the root of your application.
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
primarySwatch: Colors.blue,
),
home: ChangeNotifierProvider(
create: (context) => ProviderModel(),
child: Consumer<ProviderModel>(builder: (context, viewModel, child) {
return MyHomePage(title: 'Flutter Demo Home Page');
})));
}
}
现在 ProviderModel 已经通过 ChangeNotifierProvider 在应用中与 widget 相关联。我们可以开始调用它了。
child: Consumer<ProviderModel>(builder: (context, viewModel, child) {}
我们必须指定要访问的模型类型。在这个示例中，我们要访问 ProviderModel 那么就写上 Consumer<ProviderModel>。
Consumer widget 唯一必须的参数就是 builder。当 ChangeNotifier 发生变化的时候会调用 builder 这个函数。（换言之，当你在模型中调用 notifyListeners() 时，所有相关的 Consumer widget 的 builder 方法都会被调用。）
builder 在被调用的时候会用到三个参数。第一个是 context，在每个 build 方法中都能找到这个参数。
builder 函数的第二个参数是 ChangeNotifier 的实例。它是我们最开始就能得到的实例。你可以通过该实例定义 UI 的内容
第三个参数是 child，用于优化目的。如果 Consumer 下面有一个庞大的子树，当模型发生改变的时候，该子树 并不会 改变，那么你就可以仅仅创建它一次，然后通过 builder 获得该实例。
return Consumer<ProviderModel>(
builder: (context, cart, child) => Stack(
children: [
// Use SomeExpensiveWidget here, without rebuilding every time.
if (child != null) child,
Text('Total price: ${cart.totalPrice}'),
],
),
// Build the expensive widget here.
child: const SomeExpensiveWidget(),
);
如果我们Widget树比较庞大，那么就需要考虑到，更换Consumer的位置，在需要更新的位置使用，这样当数据发生改变时就不会全盘重新构建 widget 树了。例如：
return Consumer<ProviderModel>(
builder: (context, cart, child) {
return AWidget(
// ...
child: BWidget(
// ...
child: Text('Total price: ${cart.totalPrice}'),
),
);
},
);
换成：
return AWidget(
// ...
child: Consumer<ProviderModel>(
builder: (context, cart, child) {
return BWidget(
// ...
child: Text('Total price: ${cart.totalPrice}'),
),
);
},
);
有的时候你不需要模型中的 数据 来改变 UI，但是你可能还是需要访问该数据。比如A页面的一个按钮能够B页面的数据。它不需要显示B页面里的内容，只需要调用 clear() 方法。
我们可以使用 Consumer<ProviderModel> 来实现这个效果，不过这么实现有点浪费。因为我们让整体框架重构了一个无需重构的 widget，所以这里我们可以使用 Provider.of，并且将 listen 设置为 false
可以使用：
Provider.of<ServicePieceViewModel>(context, listen: false).clear();
或许通过context：
context.read<ServicePieceViewModel>().clear();
在 build 方法中使用上面的代码，当 notifyListeners 被调用的时候，并不会使 widget 被重构。
context.read和context.watch的区别
extension ReadContext on BuildContext {
T read<T>() {
return Provider.of<T>(this, listen: false);
}
}
extension WatchContext on BuildContext {
T watch<T>() {
return Provider.of<T>(this);
}
}
context.read是ReadContext类中的函数，继承了BuildContext，其实就是封装了一下获取Provider的方法，用read方法获取的Provider,那么当value改变的时候，不会使页面重建，而且这个方法不能再StatelessWidget.build和State.build方法中调用，也就是说可在这些方法外面随意调用。
context.watch是WatchContext类中的函数，刚好和read相反，WatchContext中的watch方法和ReadContext中的read方法是相似的，但是watch方法会导致widget重构。
总结
Flutter的状态管理机制涵盖了短时状态和共享状态，足够满足我们在日常开发中所遇到的数据更新去刷新UI的需求，个人感觉比命令式编程轻松了很多，后面我也会在此基础上看看是否能够封装一套自己的状态管理框架，欢迎同学们一起交流讨论。
扫一扫
1957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
