状态管理必要性
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中释放
