状态管理必要性
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组件更新文章来源:https://www.toymoban.com/news/detail-645671.html
使用缺陷
- provider的context层级过高,如provider传入的context是根层级的,而provider在element树中是根层级下面
解决:对应组件外嵌套一层builder,拿到该结点对应的context / provider作为根结点文章来源地址https://www.toymoban.com/news/detail-645671.html
- Get全局单例
Get全局单例默认以runtimeType为key进行对象存储,而不同详情页实例对应的是同一个class,key值一样,不添加tag参数,在Get.find时会获取到已经存储的对象,即数据混淆了。
Get存储的对象也得回收,dipose时进行delete或者使用Get中提供的组件,如GetBuilder,会在dispose中释放
到了这里,关于Flutter 状态管理 Provider的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!