Flutter学习-数据层相关

当你探索 Flutter 时，你需要在屏幕之间、应用之间共享应用程序状态。您可以采取许多方法，并且需要考虑许多问题。

如果你是从命令式框架(如 Android SDK 或 iOS UIKit)来到 Flutter 的，那么你需要从一个新的角度来思考应用开发。以前你基于命令式的许多假设可能都不适用于Flutter。例如，在 Flutter 中，通常是从头开始重新构建部分 UI，而不必修改它。Flutter 的速度足以做到这一点，甚至在每一帧，如果需要的。

Flutter 是声明性的，是状态到UI的映射，这意味着 Flutter 建立它的用户界面来反映你的应用程序的当前状态:

就是我们定义好UI构建函数，构函数函数依赖于一定的数据，然后你设置或者改变数据状态，那么Flutter自动根据你的构造函数构造并绘制界面，基于代价最小化原则。

区分短暂状态和应用程序状态

临时状态

(有时称为 UI 状态或局部状态)是您可以整洁地包含在单个小部件中的状态。
在 PageView 中的当前页
复杂动画的最新进展
BottomNavigationBar 中当前选定的选项卡

应用程序状态(有时也称为共享状态)

应用程序状态不是短暂的，您希望在应用程序的许多部分之间共享，并且希望在用户会话之间保持这种状态。
用户首选项
登录信息
社交网络应用中的通知

管理应用程序状态，没有明确的规则，
您需要研究您的选项。您的选择取决于您的应用程序的复杂性和性质，您的团队以前的经验，以及许多其他方面。

总之，在任何 Flutter 应用程序中都有两种概念性的状态类型。临时状态可以使用 State 和 setState ()实现，并且通常局部于单个小部件。剩下的就是你的应用程序状态了。这两种类型在任何 Flutter 应用程序中都有自己的位置，它们之间的区别取决于你自己的偏好和应用程序的复杂性。

APP状态管理

如果你是 Flutter 的新手，并且你没有强烈的理由去选择另一种方法(Redux，Rx，hooks，等等) ，provider 可能就是你应该开始使用的方法。provider 很容易理解，并且不需要很多代码。它还使用适用于所有其他方法的概念。
如果您具有其他反应式框架的状态管理的强大背景，您可以在选项页面上找到列出的包和教程。
https://docs.flutter.dev/development/data-and-backend/state-mgmt/options

在 Flutter 这样的声明性框架中，如果想要更改 UI，就必须重新构建它，即创建了一个新的对象。通过调用小部件上的方法，很难从外部对其进行必要的更改。即使你可以做到这一点，你也会与框架作斗争，而不是让它帮助你。因为要从外部更改，您只能在它们父节点的构建方法中构建新的小部件，所以如果您想要更改内容，更改位置需要位于父节点或以上节点中。

当我们需要使用跨组件的状态时，StatefulWidget 将不再是一个好的选择。
State 属于某一个特定的 StatefulWidget，在多个 Widget 之间进行交流的时候，虽然你可以使用 callback 解决，但是当嵌套足够深的话，很容易就增大代码耦合度。
Provider 从名字上就很容易理解，它用来提供数据，而它的优秀之处在于无论是在单个页面还是在整个 app 都有相应的解决方案，我们可以很方便的管理状态，并在合适的时机释放资源。可以说，Provider 的目标就是完全替代 StatefulWidget。

Provider使用方式

参考 https://zhuanlan.zhihu.com/p/70280813
以创建一个简单计数器 app为例，给大家介绍如何在两个独立的页面中共享计数器（counter）的状态应该怎么做,具体会像下面这样。

两个页面中心字体共用了同一个字体大小。
第二个页面的按钮将会让数字增加（第一个页面的数字将会同步增加。）

首先要添加依赖
在 pubspec.yaml 中添加 Provider 的依赖。

然后

第一步：定义数据 Model类

这里的 Model 实际上就是我们的状态，它不仅储存了我们的数据模型，而且还包含了更改数据的方法，并暴露出它想要暴露出的数据。约等于增改查

import ‘package:flutter/material.dart’;

class CounterModel with ChangeNotifier {
int _count = 0;
int get value => _count;

void increment() {
_count++;
notifyListeners();
}
}

这里使用了 mixin 混入了 ChangeNotifier，这个类能够帮助我们自动管理所有听众。
注意model类里面调用 notifyListeners();通知数据刷新。

第二步：创建数据类对象

对象存放位置视情况而定
还需要考虑懒加载问题
对象释放，待研究

第三步：设置观察者或者说订阅者、监听者 = 将数据打包放入顶层Widget = Provider.value

我们在 main 方法中初始化全局数据：刚才编写的 CounterModel 以及 textSize。为了要在不同页面共享这个数据，我们就需要将其放入顶层节点（MaterialApp 之上）进行保存。
void main() {
final counter = CounterModel();
final textSize = 48;

runApp(
Provider.value(
value: textSize,
child: ChangeNotifierProvider.value(
value: counter,
child: MyApp(),
),
),
);
}

通过 Provider.value 能够管理一个恒定的数据，并提供给子孙节点使用。我们只需要将数据在其 value 属性中声明即可。在这里我们将textSize 传入。

而 ChangeNotifierProvider.value 不仅能够提供数据供子孙节点使用，还可以在数据改变的时候通知所有听众刷新。(通过之前我们说过的 notifyListeners)

它们都会返回一个小部件，将value里面的小部件和数据打包包起来

除上述几个属性之外 Provider.value 还提供 UpdateShouldNotify Function，用于控制刷新时机。
注意顶层组件并没有绑定数据Model，需要绑定的化使用addlistenner(context);

第四步：获取数据或者接收数据变化通知 = Provider.of

在这里我们有两个页面，FirstScreen 和 SecondScreen。我们先来看 FirstScreen 的代码。

方法一 Provider.of(context)

class FirstScreen extends StatelessWidget {
@override
Widget build(BuildContext context) {
final _counter = Provider.of(context);
final textSize = Provider.of(context).toDouble();

return Scaffold(
...
  body: Center(
    child: Text(
      'Value: ${_counter.value}',
      style: TextStyle(fontSize: textSize),
    ),
  ),
  ...
);

}
}
获取顶层数据最简单的方法就是 Provider.of(context);

这里的泛型 指定了获取 FirstScreen 向上寻找最近的储存了 T 的祖先节点的数据。在buid的时候，我们通过这个方法获取了顶层的 CounterModel 及 textSize。并在 Text 组件中进行使用。

方法二 Consumer

看到这里你可能会想，两个页面都是获取顶层状态，代码不都一样吗。别忙着跳到下一节，我们来看另外一种获取状态的方式，使用它能够改善应用程序性能。

Widget build(BuildContext context) {
return Scaffold(
…
body: Consumer2<CounterModel,int>(
builder: (context, CounterModel counter, int textSize, _) => Center(
child: Text(
‘Value: ${counter.value}’,
style: TextStyle(
fontSize: textSize.toDouble(),
),
),
),
),
floatingActionButton: Consumer(
builder: (context, CounterModel counter, child) => FloatingActionButton(
onPressed: counter.increment,
child: child,
),
child: Icon(Icons.add),
),
}

注意看这个使用方式，创建Consumer对象，Consumer获取的model数量<model1类型,model2类型>，再创建其需要的builder函数， ( builder:(context, model1, model2, child) {
相当于消费者的回调函数，在这里根据数据执行操作，创建小组件，或者修改数据也是可以的
Consumer 使用了 Builder 模式，收到更新通知就会通过 builder 重新构建。Consumer 代表了它要获取哪一个祖先中的 Model。
child：它用来构建那些与 Model 无关的小组件，在多次运行 builder 中，child 不会进行重建。

Provider.of(context) 与 Consumer 的区别
那么，二者到底有什么差别呢？我们来看 Consumer 的内部实现。

Consumer 就是通过 Provider.of(context) 来实现的。但是从实现来讲 Provider.of(context) 比 Consumer 简单好用太多，为什么我要使用更加复杂的 Consumer？
实际上 Consumer 非常有用，它的经典之处在于能够在复杂项目中，极大地缩小你的控件刷新范围。** 就是指定最小范围的受影响者（消费者吧）**
Provider.of(context) 将会把调用了该方法的 context 作为听众，并在 notifyListeners 的时候通知其刷新。

假如你在你的应用的 页面级别 的 Widget 中，使用了 Provider.of(context)。会导致什么后果已经显而易见了，每当其状态改变的时候，你都会重新刷新整个页面。虽然你有 Flutter 的自动优化算法给你撑腰，但你肯定无法获得最好的性能。

相对教复杂一点的 Provider 构建方式

Provider({
Key key,
@required ValueBuilder builder,
Disposer dispose,
Widget child,
})

使用构建函数 ValueBuilder

相比起 .value 构造方式中直接传入一个 value 就 ok，这里的 builder 要求我们传入一个 ValueBuilder。这是什么东西呢？

typedef ValueBuilder = T Function(BuildContext context);

ValueBuilder就是传入一个 Function 返回一个数据而已。

定义释放资源函数 Disposer

当 Provider 所在节点被移除的时候，它就会启动 Disposer，然后我们便可以在这里释放资源。
typedef Disposer = void Function(BuildContext context, T value);

dispose 属性需要一个 Disposer,而这个其实也是一个回调。

在使用 Provider 的时候，我应该选择哪种构造方法呢。

我的推荐是，简单模型就选择 Provider.value，好处是可以精确控制刷新时机。而需要对资源进行释放处理等复杂模型的时候，Provider()默认构造方式绝对是你的最佳选择。

注意 Provider 只能提供恒定的数据，不能通知依赖它的子部件刷新。提示也说的很清楚了，假如你想使用一个会发生 change 的 Provider，请使用下面的 Provider。
ListenableProvider
ChangeNotifierProvider
会在你需要的时候，自动调用其 _disposer 方法。
static void _disposer(BuildContext context, ChangeNotifier notifier) => notifier?.dispose();
我们可以在 Model 中重写 ChangeNotifier 的 dispose 方法，来释放其资源。这对于复杂 Model 的情况下十分有用。

ValueListenableProvider
ValueListenableProvider 用于提供实现了 继承/混入/实现 了 ValueListenable 的 Model。它实际上是专门用于处理只有一个单一变化数据的 ChangeNotifier。

StreamProvider
StreamProvider 专门用作提供（provide）一条 Single Stream。我在这里仅对其核心属性进行讲解。
应该类似于rxjava
T initialData：你可以通过这个属性声明这条流的初始值。
ErrorBuilder catchError：这个属性用来捕获流中的 error。在这条流 addError 了之后，你会能够通过 T Function(BuildContext context, Object error) 回调来处理这个异常数据。实际开发中它非常有用。
updateShouldNotify：和之前的回调一样，这里不再赘述。

FutureProvider
它提供了一个 Future 给其子孙节点，并在 Future 完成时，通知依赖的子孙节点进行刷新，这里不再详细介绍，需要的话自行

优雅地处理多个 Provider

在我们之前的例子中，我们使用了嵌套的方式来组合多个 Provider，但是这样看上去有些傻。这时候我们就可以使用一个非常 sweet 的组件 —— MultiProvider。

这时候我们刚才那个例子就可以改成这样。

void main() {
final counter = CounterModel();
final textSize = 48;

runApp(
MultiProvider(
providers: [
Provider.value(value: textSize),
ChangeNotifierProvider.value(value: counter)
],
child: MyApp(),
),
);
}
可以看到我们的代码意图清晰很多，而且与刚才的嵌套做法完全等价。

更多

原理

参考 https://juejin.cn/post/6886361064330493960
「Component Widget」 —— 组合类 Widget，这类 Widget 都直接或间接继承于StatelessWidget或StatefulWidget，Widget 设计上遵循组合大于继承的原则，通过组合功能相对单一的 Widget 可以得到功能更为复杂的 Widget。平常的业务开发主要是在开发这一类型的 Widget；

「Proxy Widget」 —— 代理类 Widget，正如其名，「Proxy Widget」本身并不涉及 Widget 内部逻辑，只是为「Child Widget」提供一些附加的中间功能。典型的如：InheritedWidget用于在「Descendant（子） Widgets」间传递共享信息、ParentDataWidget用于配置「Descendant Renderer Widget」的布局信息；

「Renderer Widget」 —— 渲染类 Widget，是最核心的Widget类型，会直接参与后面的「Layout」、「Paint」流程，无论是「Component Widget」还是「Proxy Widget」最终都会映射到「Renderer Widget」上，否则将无法被绘制到屏幕上。这 3 类 Widget 中，只有「Renderer Widget」有与之一一对应的「Render Object」

InheritedWidget属于Proxies用于在Widget间传递共享数据

InheritedWidget是Flutter中非常重要的一个功能型组件，它提供了一种数据在widget树中从上到下传递、共享的方式，比如我们在应用的根widget中通过InheritedWidget共享了一个数据，那么我们便可以在任意子widget中来获取该共享的数据！这个特性在一些需要在widget树中共享数据的场景中非常方便！如Flutter SDK中正是通过InheritedWidget来共享应用主题（Theme）和Locale (当前语言环境)信息的

自然的可以想到，这个东西涉及到
创建并设置数据给父组件（增），删除数据（删）（改）数据变化之后子组件是否接收通知，接收通知之后子组件的动作

实现Provider，首先我们需要一个保存共享数据的InheritedWidget，由于具体业务数据类型不可预期，为了通用性，我们使用泛型，定义一个通用的InheritedProvider类，它继承自InheritedWidget：

数据发生变化怎么通知？ 我们使用Flutter SDK中提供的ChangeNotifier类 ，它继承自Listenable，也实现了一个Flutter风格的发布者-订阅者模式，ChangeNotifier定义大致如下：
class ChangeNotifier implements Listenable {
List listeners=[];
@override
void addListener(VoidCallback listener) {
//添加监听器
listeners.add(listener);
}
@override
void removeListener(VoidCallback listener) {
//移除监听器
listeners.remove(listener);
}

void notifyListeners() {
//通知所有监听器，触发监听器回调
listeners.forEach((item)=>item());
}

… //省略无关代码
}

通知是ChangeNotifier发布的，不是Provider
现在，我们将要共享的状态放到一个Model类中，然后让它继承自ChangeNotifier，这样当共享的状态改变时，我们只需要调用notifyListeners() 来通知订阅者，然后由订阅者来重新构建InheritedProvider，这也是第二个问题的答案！接下来我们便实现这个订阅者类

Provider 是如何做到状态共享的

这个问题实际上得分两步。

1 获取顶层数据

实际上在祖先节点中共享数据都是通过系统的 InheritedWidget 进行实现的。

Provider 也不例外，在所有 Provider 的 build 方法中，返回了一个 InheritedProvider。

class InheritedProvider extends InheritedWidget

Flutter 通过在每个 Element 上维护一个 InheritedWidget 哈希表来向下传递 Element 树中的信息。通常情况下，多个
Element 引用相同的哈希表，并且该表仅在 Element 引入新的InheritedWidget 时改变。

所以寻找祖先节点的时间复杂度为 O(1) !

2 通知刷新

通知刷新这一步实际上在讲各种 Provider 的时候已经讲过了，其实就是使用了 Listener 模式。Model 中维护了一堆听众，每次调用Provider.of(context)的时候会进行注册 ，然后 notifiedListener 通知所有听众刷新。

我应该在哪里进行数据初始化

对于数据初始化这个问题，我简单将其分为全局数据初始化与单页面数据初始化两种情况。

全局数据

当我们需要获取全局顶层数据（就像之前 CounterApp 例子一样）并需要做一些会产生额外结果的时候，main 函数是一个很好的选择。

我们可以在 main 方法中创建 Model 并进行初始化的工作，这样就只会执行一次。

单页面

还是使用 StatefulWidget，然后在其 State 的 didChangeDependence 生命周期中，做这些会产生额外结果的动作的事。由于 State 是长声明周期对象，在其存在期间，didChangeDependence 只会在创建的时候执行一次。

class FirstScreen extends StatefulWidget {···}

class _FirstScreenState extends State {
CounterModel _counter;
double _textSize;

@override
void didChangeDependencies() {
super.didChangeDependencies();
_counter = Provider.of(context);
_textSize = Provider.of(context).toDouble();
_counter.increment();
}

…

}

我需要担心性能问题吗

是的，你需要随时注意应用性能是否会因为一些不当操作而降低。虽然 Flutter 可以在不做大量优化的情况下媲美原生应用的体验。然而当我们不遵守其行为规范的时候，会出现这样的情况。性能会因为你的各种不当操作而变得很糟糕。

然而 Provider 仅仅是对 InheritedWidget 的一个升级，你不必担心引入 Provider 会对应用造成性能问题。但是在使用过程中我有下面三个建议，以避免进入性能陷阱：

控制你的刷新范围

在 Flutter 中，组合大于继承的特性随处可见。常见的 Widget 实际上都是由更小的 Widget 组合而成，直到基本组件为止。为了使我们的应用拥有更高的性能，控制 Widget 的刷新范围便显得至关重要。

我们已经通过前面的介绍了解到了，在 Provider 中获取 Model 的方式会影响刷新范围。Provider.of(context)会导致context区域刷新，所有，请尽量使用 Consumer 来获取祖先 Model，以维持最小刷新范围。

在不需要时刻监听状态变化的类中可以通过 Provider.of(context, listen: false); 取消监听, 也是提升刷新效率的方式之一。

保持 build 方法 pure

参考前面文章，build里面不要创建其它对象，或者耗时，耗内存操作等

必要时，通过重写 UpdateShouldNotify 进行性能优化。

缺点

Provider 不仅做到了提供数据，而且它拥有着一套完整的解决方案，覆盖了你会遇到的绝大多数情况。就连 BLoC 未解决的那个棘手的 dispose 问题，和 ScopedModel 的侵入性问题，它也都解决了。

然而它就是完美的吗，并不是，至少现在来说。Flutter Widget 构建模式很容易在 UI 层面上组件化，但是仅仅使用 Provider，Model 和 View 之间还是容易产生依赖。我们只有通过手动将 Model 转化为 ViewModel 这样才能消除掉依赖关系，所以假如各位有组件化的需求，还需要另外处理。

不过对于大多数情况来说，Provider 足以优秀，它能够让你开发出 简单、高性能、层次清晰、高可扩展性 的应用。