Flutter学习-数据层相关

当你探索 Flutter 时,你需要在屏幕之间、应用之间共享应用程序状态。您可以采取许多方法,并且需要考虑许多问题。

如果你是从命令式框架(如 Android SDK 或 iOS UIKit)来到 Flutter 的,那么你需要从一个新的角度来思考应用开发。以前你基于命令式的许多假设可能都不适用于Flutter。例如,在 Flutter 中,通常是从头开始重新构建部分 UI,而不必修改它。Flutter 的速度足以做到这一点,甚至在每一帧,如果需要的。

Flutter 是声明性的,是状态到UI的映射,这意味着 Flutter 建立它的用户界面来反映你的应用程序的当前状态:
Flutter学习-数据层相关_第1张图片
就是我们定义好UI构建函数,构函数函数依赖于一定的数据,然后你设置或者改变数据状态,那么Flutter自动根据你的构造函数构造并绘制界面,基于代价最小化原则。

区分短暂状态和应用程序状态

临时状态

(有时称为 UI 状态或局部状态)是您可以整洁地包含在单个小部件中的状态。
在 PageView 中的当前页
复杂动画的最新进展
BottomNavigationBar 中当前选定的选项卡

应用程序状态(有时也称为共享状态)

应用程序状态不是短暂的,您希望在应用程序的许多部分之间共享,并且希望在用户会话之间保持这种状态。
用户首选项
登录信息
社交网络应用中的通知

管理应用程序状态,没有明确的规则,
您需要研究您的选项。您的选择取决于您的应用程序的复杂性和性质,您的团队以前的经验,以及许多其他方面。

总之,在任何 Flutter 应用程序中都有两种概念性的状态类型。临时状态可以使用 State 和 setState ()实现,并且通常局部于单个小部件。剩下的就是你的应用程序状态了。这两种类型在任何 Flutter 应用程序中都有自己的位置,它们之间的区别取决于你自己的偏好和应用程序的复杂性。

APP状态管理

如果你是 Flutter 的新手,并且你没有强烈的理由去选择另一种方法(Redux,Rx,hooks,等等) ,provider 可能就是你应该开始使用的方法。provider 很容易理解,并且不需要很多代码。它还使用适用于所有其他方法的概念。
如果您具有其他反应式框架的状态管理的强大背景,您可以在选项页面上找到列出的包和教程。
https://docs.flutter.dev/development/data-and-backend/state-mgmt/options

在 Flutter 这样的声明性框架中,如果想要更改 UI,就必须重新构建它,即创建了一个新的对象。通过调用小部件上的方法,很难从外部对其进行必要的更改。即使你可以做到这一点,你也会与框架作斗争,而不是让它帮助你。因为要从外部更改,您只能在它们父节点的构建方法中构建新的小部件,所以如果您想要更改内容,更改位置需要位于父节点或以上节点中。

当我们需要使用跨组件的状态时,StatefulWidget 将不再是一个好的选择。
State 属于某一个特定的 StatefulWidget,在多个 Widget 之间进行交流的时候,虽然你可以使用 callback 解决,但是当嵌套足够深的话,很容易就增大代码耦合度。
Provider 从名字上就很容易理解,它用来提供数据,而它的优秀之处在于无论是在单个页面还是在整个 app 都有相应的解决方案,我们可以很方便的管理状态,并在合适的时机释放资源。可以说,Provider 的目标就是完全替代 StatefulWidget。

Provider使用方式

参考 https://zhuanlan.zhihu.com/p/70280813
以创建一个简单计数器 app为例,给大家介绍如何在两个独立的页面中共享计数器(counter)的状态应该怎么做,具体会像下面这样。
Flutter学习-数据层相关_第2张图片
两个页面中心字体共用了同一个字体大小。
第二个页面的按钮将会让数字增加(第一个页面的数字将会同步增加。)

首先要添加依赖
在 pubspec.yaml 中添加 Provider 的依赖。

然后

第一步:定义数据 Model类

这里的 Model 实际上就是我们的状态,它不仅储存了我们的数据模型,而且还包含了更改数据的方法,并暴露出它想要暴露出的数据。约等于增改查

import ‘package:flutter/material.dart’;

class CounterModel with ChangeNotifier {
int _count = 0;
int get value => _count;

void increment() {
_count++;
notifyListeners();
}
}

这里使用了 mixin 混入了 ChangeNotifier,这个类能够帮助我们自动管理所有听众。
注意model类里面调用 notifyListeners();通知数据刷新。

第二步:创建数据类对象

对象存放位置视情况而定
还需要考虑懒加载问题
对象释放,待研究

第三步:设置观察者或者说订阅者、监听者 = 将数据打包放入顶层Widget = Provider.value

我们在 main 方法中初始化全局数据:刚才编写的 CounterModel 以及 textSize。为了要在不同页面共享这个数据,我们就需要将其放入顶层节点(MaterialApp 之上)进行保存。
void main() {
final counter = CounterModel();
final textSize = 48;

runApp(
Provider.value(
value: textSize,
child: ChangeNotifierProvider.value(
value: counter,
child: MyApp(),
),
),
);
}

通过 Provider.value 能够管理一个恒定的数据,并提供给子孙节点使用。我们只需要将数据在其 value 属性中声明即可。在这里我们将textSize 传入。

而 ChangeNotifierProvider.value 不仅能够提供数据供子孙节点使用,还可以在数据改变的时候通知所有听众刷新。(通过之前我们说过的 notifyListeners)

它们都会返回一个小部件,将value里面的小部件和数据打包包起来

除上述几个属性之外 Provider.value 还提供 UpdateShouldNotify Function,用于控制刷新时机。
注意顶层组件并没有绑定数据Model,需要绑定的化使用addlistenner(context);

第四步:获取数据或者接收数据变化通知 = Provider.of

在这里我们有两个页面,FirstScreen 和 SecondScreen。我们先来看 FirstScreen 的代码。

方法一 Provider.of(context)

class FirstScreen extends StatelessWidget {
@override
Widget build(BuildContext context) {
final _counter = Provider.of(context);
final textSize = Provider.of(context).toDouble();

return Scaffold(
...
  body: Center(
    child: Text(
      'Value: ${_counter.value}',
      style: TextStyle(fontSize: textSize),
    ),
  ),
  ...
);

}
}
获取顶层数据最简单的方法就是 Provider.of(context);

这里的泛型 指定了获取 FirstScreen 向上寻找最近的储存了 T 的祖先节点的数据。在buid的时候,我们通过这个方法获取了顶层的 CounterModel 及 textSize。并在 Text 组件中进行使用。

方法二 Consumer

看到这里你可能会想,两个页面都是获取顶层状态,代码不都一样吗。别忙着跳到下一节,我们来看另外一种获取状态的方式,使用它能够改善应用程序性能。

Widget build(BuildContext context) {
return Scaffold(

body: Consumer2(
builder: (context, CounterModel counter, int textSize, _) => Center(
child: Text(
‘Value: ${counter.value}’,
style: TextStyle(
fontSize: textSize.toDouble(),
),
),
),
),
floatingActionButton: Consumer(
builder: (context, CounterModel counter, child) => FloatingActionButton(
onPressed: counter.increment,
child: child,
),
child: Icon(Icons.add),
),
}

注意看这个使用方式,创建Consumer对象,Consumer获取的model数量,再创建其需要的builder函数, ( builder:(context, model1, model2, child) {
相当于消费者的回调函数,在这里根据数据执行操作,创建小组件,或者修改数据也是可以的
Consumer 使用了 Builder 模式,收到更新通知就会通过 builder 重新构建。Consumer 代表了它要获取哪一个祖先中的 Model。
child:它用来构建那些与 Model 无关的小组件,在多次运行 builder 中,child 不会进行重建。

Provider.of(context) 与 Consumer 的区别
那么,二者到底有什么差别呢?我们来看 Consumer 的内部实现。

Consumer 就是通过 Provider.of(context) 来实现的。但是从实现来讲 Provider.of(context) 比 Consumer 简单好用太多,为什么我要使用更加复杂的 Consumer?
实际上 Consumer 非常有用,它的经典之处在于能够在复杂项目中,极大地缩小你的控件刷新范围。** 就是指定最小范围的受影响者(消费者吧)**
Provider.of(context) 将会把调用了该方法的 context 作为听众,并在 notifyListeners 的时候通知其刷新。

假如你在你的应用的 页面级别 的 Widget 中,使用了 Provider.of(context)。会导致什么后果已经显而易见了,每当其状态改变的时候,你都会重新刷新整个页面。虽然你有 Flutter 的自动优化算法给你撑腰,但你肯定无法获得最好的性能。

相对教复杂一点的 Provider 构建方式

Provider({
Key key,
@required ValueBuilder builder,
Disposer dispose,
Widget child,
})

使用构建函数 ValueBuilder

相比起 .value 构造方式中直接传入一个 value 就 ok,这里的 builder 要求我们传入一个 ValueBuilder。这是什么东西呢?

typedef ValueBuilder = T Function(BuildContext context);

ValueBuilder就是传入一个 Function 返回一个数据而已。

定义释放资源函数 Disposer

当 Provider 所在节点被移除的时候,它就会启动 Disposer,然后我们便可以在这里释放资源。
typedef Disposer = void Function(BuildContext context, T value);

dispose 属性需要一个 Disposer,而这个其实也是一个回调。

在使用 Provider 的时候,我应该选择哪种构造方法呢。

我的推荐是,简单模型就选择 Provider.value,好处是可以精确控制刷新时机。而需要对资源进行释放处理等复杂模型的时候,Provider()默认构造方式绝对是你的最佳选择。

注意 Provider 只能提供恒定的数据,不能通知依赖它的子部件刷新。提示也说的很清楚了,假如你想使用一个会发生 change 的 Provider,请使用下面的 Provider。
ListenableProvider
ChangeNotifierProvider
会在你需要的时候,自动调用其 _disposer 方法。
static void _disposer(BuildContext context, ChangeNotifier notifier) => notifier?.dispose();
我们可以在 Model 中重写 ChangeNotifier 的 dispose 方法,来释放其资源。这对于复杂 Model 的情况下十分有用。

ValueListenableProvider
ValueListenableProvider 用于提供实现了 继承/混入/实现 了 ValueListenable 的 Model。它实际上是专门用于处理只有一个单一变化数据的 ChangeNotifier。

StreamProvider
StreamProvider 专门用作提供(provide)一条 Single Stream。我在这里仅对其核心属性进行讲解。
应该类似于rxjava
T initialData:你可以通过这个属性声明这条流的初始值。
ErrorBuilder catchError:这个属性用来捕获流中的 error。在这条流 addError 了之后,你会能够通过 T Function(BuildContext context, Object error) 回调来处理这个异常数据。实际开发中它非常有用。
updateShouldNotify:和之前的回调一样,这里不再赘述。

FutureProvider
它提供了一个 Future 给其子孙节点,并在 Future 完成时,通知依赖的子孙节点进行刷新,这里不再详细介绍,需要的话自行

优雅地处理多个 Provider

在我们之前的例子中,我们使用了嵌套的方式来组合多个 Provider,但是这样看上去有些傻。这时候我们就可以使用一个非常 sweet 的组件 —— MultiProvider。

这时候我们刚才那个例子就可以改成这样。

void main() {
final counter = CounterModel();
final textSize = 48;

runApp(
MultiProvider(
providers: [
Provider.value(value: textSize),
ChangeNotifierProvider.value(value: counter)
],
child: MyApp(),
),
);
}
可以看到我们的代码意图清晰很多,而且与刚才的嵌套做法完全等价。

更多

原理

参考 https://juejin.cn/post/6886361064330493960
「Component Widget」 —— 组合类 Widget,这类 Widget 都直接或间接继承于StatelessWidget或StatefulWidget,Widget 设计上遵循组合大于继承的原则,通过组合功能相对单一的 Widget 可以得到功能更为复杂的 Widget。平常的业务开发主要是在开发这一类型的 Widget;

「Proxy Widget」 —— 代理类 Widget,正如其名,「Proxy Widget」本身并不涉及 Widget 内部逻辑,只是为「Child Widget」提供一些附加的中间功能。典型的如:InheritedWidget用于在「Descendant(子) Widgets」间传递共享信息、ParentDataWidget用于配置「Descendant Renderer Widget」的布局信息;

「Renderer Widget」 —— 渲染类 Widget,是最核心的Widget类型,会直接参与后面的「Layout」、「Paint」流程,无论是「Component Widget」还是「Proxy Widget」最终都会映射到「Renderer Widget」上,否则将无法被绘制到屏幕上。这 3 类 Widget 中,只有「Renderer Widget」有与之一一对应的「Render Object」

InheritedWidget属于Proxies用于在Widget间传递共享数据

InheritedWidget是Flutter中非常重要的一个功能型组件,它提供了一种数据在widget树中从上到下传递、共享的方式,比如我们在应用的根widget中通过InheritedWidget共享了一个数据,那么我们便可以在任意子widget中来获取该共享的数据!这个特性在一些需要在widget树中共享数据的场景中非常方便!如Flutter SDK中正是通过InheritedWidget来共享应用主题(Theme)和Locale (当前语言环境)信息的

自然的可以想到,这个东西涉及到
创建并设置数据给父组件(增),删除数据(删)(改)数据变化之后子组件是否接收通知,接收通知之后子组件的动作

实现Provider,首先我们需要一个保存共享数据的InheritedWidget,由于具体业务数据类型不可预期,为了通用性,我们使用泛型,定义一个通用的InheritedProvider类,它继承自InheritedWidget:

数据发生变化怎么通知? 我们使用Flutter SDK中提供的ChangeNotifier类 ,它继承自Listenable,也实现了一个Flutter风格的发布者-订阅者模式,ChangeNotifier定义大致如下:
class ChangeNotifier implements Listenable {
List listeners=[];
@override
void addListener(VoidCallback listener) {
//添加监听器
listeners.add(listener);
}
@override
void removeListener(VoidCallback listener) {
//移除监听器
listeners.remove(listener);
}

void notifyListeners() {
//通知所有监听器,触发监听器回调
listeners.forEach((item)=>item());
}

… //省略无关代码
}

通知是ChangeNotifier发布的,不是Provider
现在,我们将要共享的状态放到一个Model类中,然后让它继承自ChangeNotifier,这样当共享的状态改变时,我们只需要调用notifyListeners() 来通知订阅者,然后由订阅者来重新构建InheritedProvider,这也是第二个问题的答案!接下来我们便实现这个订阅者类

Provider 是如何做到状态共享的

这个问题实际上得分两步。

1 获取顶层数据

实际上在祖先节点中共享数据都是通过系统的 InheritedWidget 进行实现的。

Provider 也不例外,在所有 Provider 的 build 方法中,返回了一个 InheritedProvider。

class InheritedProvider extends InheritedWidget

Flutter 通过在每个 Element 上维护一个 InheritedWidget 哈希表来向下传递 Element 树中的信息。通常情况下,多个
Element 引用相同的哈希表,并且该表仅在 Element 引入新的InheritedWidget 时改变。

所以寻找祖先节点的时间复杂度为 O(1) !

2 通知刷新

通知刷新这一步实际上在讲各种 Provider 的时候已经讲过了,其实就是使用了 Listener 模式。Model 中维护了一堆听众,每次调用Provider.of(context)的时候会进行注册 ,然后 notifiedListener 通知所有听众刷新。

我应该在哪里进行数据初始化

对于数据初始化这个问题,我简单将其分为全局数据初始化与单页面数据初始化两种情况。

全局数据

当我们需要获取全局顶层数据(就像之前 CounterApp 例子一样)并需要做一些会产生额外结果的时候,main 函数是一个很好的选择。

我们可以在 main 方法中创建 Model 并进行初始化的工作,这样就只会执行一次。

单页面

还是使用 StatefulWidget,然后在其 State 的 didChangeDependence 生命周期中,做这些会产生额外结果的动作的事。由于 State 是长声明周期对象,在其存在期间,didChangeDependence 只会在创建的时候执行一次。

class FirstScreen extends StatefulWidget {···}

class _FirstScreenState extends State {
CounterModel _counter;
double _textSize;

@override
void didChangeDependencies() {
super.didChangeDependencies();
_counter = Provider.of(context);
_textSize = Provider.of(context).toDouble();
_counter.increment();
}

}

我需要担心性能问题吗

是的,你需要随时注意应用性能是否会因为一些不当操作而降低。虽然 Flutter 可以在不做大量优化的情况下媲美原生应用的体验。然而当我们不遵守其行为规范的时候,会出现这样的情况。性能会因为你的各种不当操作而变得很糟糕。

然而 Provider 仅仅是对 InheritedWidget 的一个升级,你不必担心引入 Provider 会对应用造成性能问题。但是在使用过程中我有下面三个建议,以避免进入性能陷阱:

控制你的刷新范围

在 Flutter 中,组合大于继承的特性随处可见。常见的 Widget 实际上都是由更小的 Widget 组合而成,直到基本组件为止。为了使我们的应用拥有更高的性能,控制 Widget 的刷新范围便显得至关重要。

我们已经通过前面的介绍了解到了,在 Provider 中获取 Model 的方式会影响刷新范围。Provider.of(context)会导致context区域刷新,所有,请尽量使用 Consumer 来获取祖先 Model,以维持最小刷新范围。

在不需要时刻监听状态变化的类中可以通过 Provider.of(context, listen: false); 取消监听, 也是提升刷新效率的方式之一。

保持 build 方法 pure

参考前面文章,build里面不要创建其它对象,或者耗时,耗内存操作等

必要时,通过重写 UpdateShouldNotify 进行性能优化。

缺点

Provider 不仅做到了提供数据,而且它拥有着一套完整的解决方案,覆盖了你会遇到的绝大多数情况。就连 BLoC 未解决的那个棘手的 dispose 问题,和 ScopedModel 的侵入性问题,它也都解决了。

然而它就是完美的吗,并不是,至少现在来说。Flutter Widget 构建模式很容易在 UI 层面上组件化,但是仅仅使用 Provider,Model 和 View 之间还是容易产生依赖。我们只有通过手动将 Model 转化为 ViewModel 这样才能消除掉依赖关系,所以假如各位有组件化的需求,还需要另外处理。

不过对于大多数情况来说,Provider 足以优秀,它能够让你开发出 简单、高性能、层次清晰、高可扩展性 的应用。

你可能感兴趣的:(Flutter,flutter,学习,android)