Flutter 状态管理 Provider

状态管理必要性

Flutter基于声明式构建UI，原生则是命令式，状态管理是用于解决声明式开发带来的问题。

例：命令式的原生，数据更新需要拿到对应控件并更改其显示值；而声明式则需要更改数据值并通过setstate更新状态，重新构建组件

Flutter 中有这么一种说法: UI = f(state):

声明式的优势

• 优势：

• 无需繁琐地控制组件，只需聚焦于状态管理，负责状态—>UI的映射

• 劣势：

• 逻辑和页面UI耦合，导致无法复用/单元测试、修改混乱等：MVVM等架构解决

• 跨页面访问数据

• 控制页面刷新范围

provider工作原理

provider内部为DelegateWidget(委托组件)是一个StatefulWidget，可更新，具有生命周期，借助各种代理完成
状态共享使用InheritedProvider这个InheritedWidget实现
通过MultiProvider和Consumer封装，对组合与刷新颗粒度控制

provider工作流程：

设置到changeNotifierProvider的changeNotifier被执行addListener添加监听listener
listener内会调用StateDelegate的StateSetter方法，从而调用到StatefulWidget的setState
在changeNotifier执行notifyListeners时，最终触发setState更新

provider异同

• ListenableProvider / ChangeNotifierProvider

ListenableProvider提供的对象是继承了Listenable抽象类的子类，只能通过继承来实现addListener/removeListener方法，手动管理收听者

changeNotifier实现了Listenable，而混入了changeNotifier的类自动实现了监听管理

ChangeNotifierProvider 和 ListenableProvider 究竟区别在哪呢，ChangeNotifierProvider 会在你需要的时候，自动调用其 _disposer 方法。

• ValueListenableProvider，提供了继承/混入/实现了ValueListenable的model，专门用于只有一个单一变化数据的ChangeNotifier，通过ValueListenable处理的类不再需要数据更新时调用notifyListeners。

• StreamProvider，专门提供一条Single Stream，提供了方法捕获异常、更新数据、构建流、构建流控制器等

状态同步

• 获取顶层数据：flutter在每个element上维护一个InheritedWidget哈希表来向下传递element树中的信息，通常情况下，多个element引用相同的哈希表，并且该表仅在element引入新的InheritedWidget时改变， 时间复杂度为O(1)。
• 通知刷新：listener模式，model中维护听众，并通过notifiedListener通知刷新，全局状态需放在顶层之上，优先初始化

数据初始化

• 全局数据：main方法执行，保证只执行一次
• 单页面数据：StatefulWidget中的InitState中不可执行Provider.of(context)，当监听后，在notifyListeners的时候，会触发context所对应的State的[State.build]和[State.didChangeDependencies]方法，数据到来时又会触发下一次请求，无限请求下去。

解决页面和逻辑的耦合

思路：

• 通过flutter树机制解决，如provider
• 通过依赖注入，如Get

通过flutter树机制处理V—>P的获取

flutter三棵树：widget、element、render object

widget树是虚拟结构，只是描述组件嵌套关系，但element和renderObject在运行时实际存在。element组件中包含了_parent属性，存放其父节点element，而其又实现了buildContext接口，包含了对树结构操作的方法

原本应该是通过context.findAncestorStateOfType向上获取父组件的信息，在有了provider之后通过provider.of(context)向上获取顶层provider组件中的presenter对象

通过依赖注入解决V—>P的获取

摆脱context依赖，基于get借助一个全局单例的map存储对象，通过依赖注入的方式，实现对Presenter层的获取，使得可在任意类中获取到Presenter

map对应的key是runtimeType+tag，其中tag为可选参数，value对应object

get也可解决跨页面访问数据

避免setstate全局更新

观察者模式，局部更新

• ValueNotifier、ValueListenableBuilder
• ChangeNotifierProvider、ChangeNotifier、Consumer：从顶层ChangeNotifierProvider获取存储的ChangeNotifier，Consumer作为子组件获取对应数据

Get对应方式则是Get.put和GetBuilder，Get.put提前存储数据对象，为GetBuilder组件指定数据类型作为泛型，因为Get基于单例，所以GetBuilder可以直接通过泛型获取到存入的对象，在builder方法中暴露，使得组件和数据建立了监听关系，并在数据更新后只驱动将其作为泛型的GetBuilder组件更新

使用缺陷

• provider的context层级过高，如provider传入的context是根层级的，而provider在element树中是根层级下面

解决：对应组件外嵌套一层builder，拿到该结点对应的context / provider作为根结点

• Get全局单例
  Get全局单例默认以runtimeType为key进行对象存储，而不同详情页实例对应的是同一个class，key值一样，不添加tag参数，在Get.find时会获取到已经存储的对象，即数据混淆了。
  Get存储的对象也得回收，dipose时进行delete或者使用Get中提供的组件，如GetBuilder，会在dispose中释放