flutter加载框,flutter 全局Loading框

Flutter组件（Widget）的局部刷新方式

Flutter中有两个常用的状态Widget分为StatefulWidget和StatelessWidget，分别为动态视图和静态视图，视图的更新需要调用StatefulWidget的setState方法，这会遍历调用子Widget的build方法。如果一个页面内容比较复杂时，会包含多个widget，如果直接调用setState，会遍历所有子Widget的build，这样会造成很多不必要的开销，所以非常有必要了解Flutter中局部刷新的方式：

globalkey唯一定义了某个element，它使你能够访问与element相关联的其他对象，例如buildContext、state等。应用场景：跨widget访问状态。

例如：可以通过key.currentState拿到它的状态对象，然后就可以调用其中的onPressed方法。

Flutter框架内部提供了一个非常小巧精致的组件，专门用于局部组件的刷新。适用于值改动的刷新。

实现原理：在 initState 中对传入的可监听对象进行监听，执行 _valueChanged 方法，_valueChanged 中进行了 setState 来触发当前状态的刷新。触发 build 方法，从而触发 widget.builder 回调，这样就实现了局部刷新。可以看到这里回调的 child 是组件传入的 child，所以直接使用，这就是对 child 的优化的根源。

可以看到 ValueListenableBuilder 实现局部刷新的本质，也是进行组件的抽离，让组件状态的改变框定在状态内部，并通过 builder 回调控制局部刷新，暴露给用户使用。

通过这个可以创建一个支持局部刷新的widget树，比如你可以在StatelessWidget里面刷新某个布局，但是不需要改变成StatefulWidget；也可以在StatefulWidget中使用做部分刷新而不需要刷新整个页面，这个刷新是不会调用Widget build（BuildContext context）刷新整个布局树的。

异步UI更新：

很多时候我们会依赖一些异步数据来动态更新UI，比如在打开一个页面时我们需要先从互联网上获取数据，在获取数据的过程中显示一个加载框，等获取到数据时我们再渲染页面；又比如我们想展示Stream（比如文件流、互联网数据接收流）的进度。当然StatefulWidget我们完全可以实现以上功能。但由于在实际开发中依赖异步数据更新UI的这种场景非常常见，并且当StatefulWidget中控件树较大时，更新一个属性导致整个树重建，消耗性能，因此Flutter专门提供了FutureBuilder和SteamBuilder两个组件来快速实现这种功能。

通常情况下，子Widget无法单独感知父Widget的变化，当父state变化时，通过其build重建所有子widget；

InheriteddWidget可以避免这种全局创建，实现局部子Widget更新。InheritedWidget提供了一种在Widget树中从上到下传递、共享数据的方式。Flutter SDK正是通过InheritedWidget来共享应用主题和Locale等信息。

InheritedWidgetData

TestData

InheritedTest1Page

provider是Google I/O 2019大会上宣布的现在官方推荐的管理方式，而ChangeNotifierProvider可以说是Provider的一种：

yaml文件需要引入provider: ^3.1.0

顶层嵌套ChangeNotifierProvider

创建共享数据类DataInfo：

数据类需要with ChangeNotifier 以使用 notifyListeners()函数通知监听者更新界面。

使用Provider.of(context)获取DataInfo

nextPage：

使用Consumer包住需要使用共享数据的Widget

RepaintBoundary就是重绘边界，用于重绘时独立于父视图。页面需要更新的页面结构可以用 RepaintBoundary组件嵌套,flutter 会将包含的组件独立出一层"画布"，去绘制。官方很多组件 外层也包了层 RepaintBoundary 标签。如果你的自定义view比较复杂，应该尽可能的避免重绘。

以上总结了几种Flutter的局部刷新的方式，可根据实际需要使用不同的方式，最适合的才是最好的。

相关问答

Q1: Flutter下拉刷新、上拉加载

注意： 滚动组件添加： physics: ClampingScrollPhysics() 可以处理IOS系统的物理滚动的效果（即橡皮筋效果）

ListView 是最常用的可滚动组件之一，可以沿一个方向线性排布所有子组件，并且它也支持基于Sliver的延迟构建模型

默认构造函数：

ListView.builder：

ListView.separated：

ListView.separated 可以在生成的列表项之间添加一个分割组件，它比 ListView.builder 多了一个 separatorBuilder 参数，该参数是一个分割组件生成器。

RefreshIndicator 下拉刷新：

RefreshIndicator 是 Material 风格的下拉刷新组件。

CupertinoSliverRefreshControl 下拉刷新：

CupertinoSliverRefreshControl 是 ios 风格的下拉刷新控件。

上拉加载的功能，需要用到 ScrollController + ListView组件:

Q2: Flutter图片加载与缓存

其中，参数 image 类型为抽象类 ImageProvider ，定义了图片数据获取和加载的相关接口。

根据不同的数据来源，派生出不同的 ImageProvider ：

抽象类 ImageProvider 提供了一个用于加载数据源的抽象方法 @protected ImageStreamCompleter load(T key, DecoderCallback decode); 接口，不同的数据源定义各自的实现。

子类 NetworkImage 实现如下：

load 方法返回类型为抽象类 ImageStreamCompleter ，其中定义了一些管理图片加载过程的接口，比如 addListener 、 removeListener 、 addOnLastListenerRemovedCallback 等， MultiFrameImageStreamCompleter 为其子类。

MultiFrameImageStreamCompleter 第一个参数 codec 类型为 Futureui.Codec ，用来对突破进行解码，当 codec 准备好的时候，就会立即对图片第一帧进行解码操作。

codec 为 _loadAsync 方法返回值，

_loadAsync 方法实现：

decode 方法的类型：

其中解码传入的回调方法 image_provider.DecoderCallback decode ，

传入 Uint8List ，返回 Futureui.Codec 。

而对 decode 回调方法的具体定义，在 ImageProvider 的 resolveStreamForKey 方法中做了定义， resolveStreamForKey 方法在 ImageProvider 的 resolve 方法中有调用， resolve 方法则为 ImageProvider 类层级结构的公共入口点。

resolveStreamForKey 和 resolve 实现如下：

decode 方法，即 PaintingBinding.instance!.instantiateImageCodec ，即为具体图片解码的方法实现。

ui.instantiateImageCodec 实现：

descriptor.instantiateCodec 方法实现：

_instantiateCodec 方法的实现，最终到了 native 的实现：

其中返回值类型 Codec 里定义了一些属性：

obtainKey 方法：

ImageProvider 定义了一个抽象方法 FutureT obtainKey(ImageConfiguration configuration); ，供子类来实现，其中 NetworkImage 的实现为：

obtainKey 作用：

配合实现图片缓存， ImageProvider 从数据源加载完数据后，会在 ImageCache 中缓存图片数据，图片数据缓存时一个 Map ，其中 Map 中的 key 便是 obtainKey 。

resolve 作为 ImageProvider 提供给 Image 的主入口方法，参数为 ImageConfiguration ，

resolve 其中调用了 _createErrorHandlerAndKey 方法，设置了成功回调和失败回调：

其中 _createErrorHandlerAndKey 方法的实现，便调用了 obtainKey 来设置 key 。

在成功回调里，调用了方法 resolveStreamForKey ，里面有具体的缓存实现 PaintingBinding.instance!.imageCache!.putIfAbsent ：

PaintingBinding.instance!.imageCache 是ImageCache的一个实例，是 PaintingBinding 的一个属性，是一个单例，图片缓存是全局的。

如上述判断：

ImageCache 定义：

ImageCache 缓存池：

在 NetworkImage 中，对 ImageProvider 的抽象方法 obtainKey 进行了实现，将自己创建了一个同步 Future 进行返回：

同时，自身又重写了 ImageProvider 定义的 == 比较操作符，通过图片 url 和图片的缩放比例 scale 进行比较：

通过ImageCache提供的方法来设置：

Q3: Flutter中showDialog()后关闭Dialog

在耗时操作的时候，一般都要弹出一个加载框，然后在完成的时候再把加载框关掉，在Flutter中可以直接用showDialog()来弹出一个对话框。

这是一个简单的提示对话框，包含了关闭按钮，点击就能关闭。但一般的耗时操作完成，就需要我们自己把dialog关闭掉。

首先，开启dialog的时机。由于我们需要获取到BuildContext，所以就得等build()方法走完，这里可以用Future.delayed()来等创建好BuildContext再进行创建，或者用Timer来延迟操作，我选择了前者。

其中delayed()在initState()结尾来做就行，这里参考网友封装了一个LoadingDialog。

那么接下来要在什么时机关闭呢？

一开始，我理所当然的以为，是在异步方法结束后，去更新界面的时候关闭，也就是setState(() {})的时候，可是不管怎么尝试，用Navigator.pop()不行，用Navigator.of(context, rootNavigator: true).pop(result)也不行，用FlutterBoost.singleton.close(id)也不行，用FlutterBoost.singleton.closeCurrent()也不行，都会直接把非Dialog的页面也关闭掉，这让我百思不得其解，因为showDialog()的本质也是新建了一个Route出来，也就是最顶层的页面是弹出的Dialog，可是为什么关不掉呢。

一番思前想后，把showDialog的逻辑移到和异步逻辑同级，也就是setState(() {})外面，然后把showDialog()自身创建的BuildContext传进去就能正常关闭了。也就是，在setState(() {})的时候，其实用的context还是非Dialog页面的，所以关闭的当然就不是Dialog了。

持有Dialog自己的BuildContext，然后在异步以后调用就行了。

Q4: flutter在initState中显示Dialog加载框

Future.delayed(Duration.zero, () {

showDialog(

context: context,

barrierDismissible: false,

builder: (_) {

return LoadingDialog();

});

});

Q5: Flutter 异步加载数据，UI卡顿

记录下坑

一开始我就使用Future、async、await去做异步操作，以为这样能解决问题，经过一天研究发现他们都还在同一个线程里面，也就是UI线程，导致卡顿，这明显不是我们想要的异步加载数据。

Dart真正的线程叫隔离（Isolate）

难受香菇

有点心累，记录下吧。