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树中需要使用数据（状态）的地方
