1. 那么,flutter为什么要设计成这样呢?为什么要弄成复杂的三层结构?
答案是性能优化。如果每一点细微的操作就去完全重绘一遍UI,将带来极大的性能开销。flutter的三棵树型模式设计可以有效地带来性能提升。
widget的重建开销非常小,所以可以随意的重建,因为它不一会导致页面重绘,并且它也不一定会常常变化。 而renderObject如果频繁创建和销毁成本就很高了,对性能的影响比较大,因此它会缓存所有页面元素,只是当这些元素有变化时才去重绘页面。
而判断页面有无变化就依靠element了,每次widget变化时element会比较前后两个widget,只有当某一个位置的Widget和新Widget不一致,才会重新创建Element和widget;其他时候则只会修改renderObject的配置而不会进行耗费性能的RenderObject的实例化工作了。
2.flutter 局部更新
a) StatefulBuilder
b) GlobalKey
c) FutureBuilder & StreamBuilder
3flutter状态管理
1)全局事件总线EventBus
它是一个[观察者模式]的实现,通过它就可以实现跨组件状态同步:状态持有方(发布者)负责更新、发布状态,状态使用方(观察者)监听状态改变事件来执行一些操作。
2)InheritedWidget
比如我们在应用的根 widget 中通过InheritedWidget共享了一个数据,那么我们便可以在任意子widget 中来获取该共享的数据!
当InheritedWidget数据发生变化时,可以自动更新依赖的子孙组件!利用这个特性,我们可以将需要跨组件共享的状态保存在InheritedWidget中,然后在子组件中引用InheritedWidget
用法: •自定义Widget继承自lnheritedWidget, 并且自定义static of方法,用于child获取当前实例 •实现 Inheritedwidtet 类中的 updateShoulaNotify 方法,用于返回update条件; 当数据变化时,调用自定义widget的State类中的setState(方法,触发整棵Inheritedwldget tree的更新
定义一个共享数据的InheritedWidget,需要继承自InheritedWidget
3Provider
Provider是目前官方推荐的全局状态管理工具,由社区作者Remi Rousselet 和 Flutter Team共同编写。
它对InheritedWidget进行了上层封装,致力解决原生setState方案的props臃肿、展示与逻辑耦合问题。
它的原理就是绑定 Inheritedwidget 与依 赖它的子孙组件的依赖关系,并且当 Inheritedwidget 数据发生变化时,可以自动更新依赖的子孙 组件。
Provider将页面分为业务和视图两层,并定义Notifier、Consumer两个核心概念:
- Notifier负责实现业务逻辑,且在数据更新时发出通知。
- Consumer负责实现界面逻辑,并在数据更新时更新自身,以及用户交互时调用Notifier方法。
组件间通信依赖公共Notifier父节点完成,其流程为:
- 组件A调用Notifier方法更新数据。
- Notifier节点通知组件B数据更新。
优势
- 方案涉及概念少,上手成本低。
劣势
- 数据流分为业务、视图两层。项目规模变大时,业务层复杂度容易指数级增长。
- 组件通信方式依赖公共Notifier父节点,数据同步与组件树结构强耦合,项目维护成本高。
- 组件不可插拔,组件获取数据依赖Notifier父节点,与组件树结构强耦合,项目维护成本高。
Provider基本使用
在使用Provider的时候,我们主要关心三个概念:
ChangeNotifier:真正数据(状态)存放的地方
ChangeNotifierProvider:Widget树中提供数据(状态)的地方,会在其中创建对应的ChangeNotifier
Consumer:Widget树中需要使用数据(状态)的地方
网友评论