Flutter state management framework Provider and Get analysis

Posted by Nayuta, CFUG Community

State management has always been a hot topic in Flutter development. When it comes to the state management framework, the community also has various schemes represented by Get and Provider , and they have their own advantages and disadvantages. Faced with so many choices, you may think: "Do I need to use state management? Which framework is more suitable for me?" This article will start from the author's actual development experience, analyze the problems and ideas solved by state management, and hope to help You make a choice.

Why do you need state management?

First, why do you need state management? According to the author's experience, this is because Flutter builds UI based on declarative, and one of the purposes of using state management is to solve the problems caused by "declarative" development.

"Declarative" development is a different way from native, so we haven't heard of state management in native development, so how do we understand "declarative" development?

"Declarative" VS "imperative" analysis

Take the most classic counter example to analyze:

As shown in the figure above: Click the button in the lower right corner, and the displayed text number increases by one. This can be achieved in Android: when the button in the lower right corner is clicked, TextViewthe object obtained, manually set the displayed text.

The implementation code is as follows:

// 一、定义展示的内容
private int mCount =0;
 
// 二、中间展示数字的控件 TextView
private TextView mTvCount;
 
// 三、关联 TextView 与 xml 中的组件
mTvCount = findViewById(R.id.tv_count)
 
// 四、点击按钮控制组件更新
private void increase( ){ 
	mCount++;
	mTvCounter.setText(mCount.toString()); 
}

复制代码

In Flutter, we only need setState((){})to . setStateThe entire page will be refreshed, causing the value displayed in the middle to change.

// 一、声明变量
int _counter =0; 

// 二、展示变量 
Text('$_counter')

//  三、变量增加，更新界面
setState(() {
   _counter++; 
});
复制代码

It can be found that only the _counterproperty , and no operation is performed on the Text component. The entire interface changes with the change of the state.

So there is such a saying in Flutter: UI = f(state) :

上面的例子中，状态 (state) 就是 _counter 的值，调用 setState 驱动 f build 方法生成新的 UI。

那么，声明式有哪些优势，并带来了哪些问题呢？

优势: 让开发者摆脱组件的繁琐控制，聚焦于状态处理

习惯 Flutter 开发之后，回到原生平台开发，你会发现当多个组件之间相互关联时，对于 View 的控制非常麻烦。

而在 Flutter 中我们只需要处理好状态即可 (复杂度转移到了状态 -> UI 的映射，也就是 Widget 的构建)。包括 Jetpack Compose、Swift 等技术的最新发展，也是在朝着「声明式」的方向演进。

声明式开发带来的问题

没有使用状态管理，直接「声明式」开发的时候，遇到的问题总结有三个:

1. 逻辑和页面 UI 耦合，导致无法复用/单元测试、修改混乱等
2. 难以跨组件 (跨页面) 访问数据
3. 无法轻松的控制刷新范围 (页面 setState 的变化会导致全局页面的变化)

接下来，我先带领大家逐个了解这些问题，下一章向大家详细描述状态管理框架如何解决这些问题。

1) 逻辑和页面 UI 耦合，导致无法复用/单元测试、修改混乱等

一开始业务不复杂的时候，所有的代码都直接写到 widget 中，随着业务迭代， 文件越来越大，其他开发者很难直观地明白里面的业务逻辑。 并且一些通用逻辑，例如网络请求状态的处理、分页等，在不同的页面来回粘贴。

这个问题在原生上同样存在，后面也衍生了诸如 MVP 设计模式的思路去解决。

2) 难以跨组件 (跨页面) 访问数据

第二点在于跨组件交互，比如在 Widget 结构中， 一个子组件想要展示父组件中的 name 字段， 可能需要层层进行传递。

又或者是要在两个页面之间共享筛选数据， 并没有一个很优雅的机制去解决这种跨页面的数据访问。

3) 无法轻松的控制刷新范围 (页面 setState 的变化会导致全局页面的变化)

最后一个问题也是上面提到的优点，很多场景我们只是部分状态的修改，例如按钮的颜色。 但是整个页面的 setState 会使得其他不需要变化的地方也进行重建， 带来不必要的开销。

Provider、Get 状态管理框架设计分析

Flutter 中状态管理框架的核心在于这三个问题的解决思路， 下面一起看看 Provider、Get 是如何解决的：

解决逻辑和页面 UI 耦合问题

传统的原生开发同样存在这个问题，Activity 文件也可能随着迭代变得难以维护， 这个问题可以通过 MVP 模式进行解耦。

简单来说就是将 View 中的逻辑代码抽离到 Presenter 层， View 只负责视图的构建。

这也是 Flutter 中几乎所有状态管理框架的解决思路， 上图的 Presenter 你可以认为是 Get 中的 GetController、 Provider 中的 ChangeNotifier 或者 Bloc 中的 Bloc。 值得一提的是，具体做法上 Flutter 和原生 MVP 框架有所不同。

我们知道在经典 MVP 模式中， 一般 View 和 Presenter 以接口定义自身行为 (action)， 相互持有接口进行调用 。

但 Flutter 中不太适合这么做， 从 Presenter → View 关系上 View 在 Flutter 中对应 Widget， 但在 Flutter 中 Widget 只是用户声明 UI 的配置， 直接控制 Widget 实例并不是好的做法。

而在从 View → Presenter 的关系上， Widget 可以确实可以直接持有 Presenter， 但是这样又会带来难以数据通信的问题。

这一点不同状态管理框架的解决思路不一样，从实现上他们可以分为两大类：

• Solved by the Flutter tree mechanism , such as Provider;
• Via Dependency Injection , such as Get.

1) Handle the acquisition of V → P through the Flutter tree mechanism

abstract class Element implements BuildContext { 
	/// 当前 Element 的父节点
	Element? _parent; 
}

abstract class BuildContext {
	/// 查找父节点中的T类型的State
	T findAncestorState0fType<T extends State>( );

	/// 遍历子元素的element对象
	void visitChildElements(ElementVisitor visitor);

	/// 查找父节点中的T类型的 InheritedWidget 例如 MediaQuery 等
	T dependOnInheritedWidget0fExactType<T extends InheritedWidget>({ 
		Object aspect });
	……
} 
复制代码

Element implements the method of manipulating the tree structure in the parent class BuildContext

We know that there are three trees in Flutter, Widget, Element and RenderObject. The so-called Widget tree is actually just a way of describing the nesting relationship of components, which is a virtual structure . But Element and RenderObject actually exist at runtime. You can see that the Element component contains _parentproperties to store its parent nodes. And it implements the BuildContextinterface , which contains many methods for tree structure operations, such as findAncestorStateOfTypelooking up parent nodes; visitChildElementstraversing child nodes.

In the first example, we can find the required Element object layer by context.findAncestorStateOfTypelayer , and get the required variable after getting the Widget or State.

The provider also uses this mechanism to complete the acquisition of View -> Presenter. Provider.ofGet the Present object in the top-level Provider component through . Obviously, all Widget nodes below the Provider can access the Presenter in the Provider through their own context, which solves the problem of cross-component communication well.

2) Solve V → P by means of dependency injection

树机制很不错，但依赖于 context，这一点有时很让人抓狂。 我们知道 Dart 是一种单线程的模型， 所以不存在多线程下对于对象访问的竞态问题。 基于此 Get 借助一个全局单例的 Map 存储对象。 通过依赖注入的方式，实现了对 Presenter 层的获取。 这样在任意的类中都可以获取到 Presenter。

这个 Map 对应的 key 是 runtimeType + tag， 其中 tag 是可选参数，而 value 对应 Object， 也就是说我们可以存入任何类型的对象，并且在任意位置获取。

解决难以跨组件 (跨页面) 访问数据的问题

这个问题其实和上一部分的思考基本类似，所以我们可以总结一下两种方案特点：

Provider

• 依赖树机制，必须基于 context
• 提供了子组件访问上层的能力

Get

• 全局单例，任意位置可以存取
• 存在类型重复，内存回收问题

解决高层级 setState 引起不必要刷新的问题

最后就是我们提到的高层级 setState 引起不必要刷新的问题， Flutter 通过采用观察者模式解决，其关键在于两步：

1. 观察者去订阅被观察的对象；
2. 被观察的对象通知观察者。

系统也提供了 ValueNotifier 等组件的实现：

/// 声明可能变化的数据
ValueNotifier<int> _statusNotifier = ValueNotifier(0); 

ValueListenableBuilder<int>(
	// 建立与 _statusNotifier 的绑定关系 
	valueListenable: _statusNotifier, 
	builder: (c, data, _) {
		return Text('$data'); 
})

///数据变化驱动 ValueListenableBuilder 局部刷新 
_statusNotifier.value += 1;

复制代码

了解到最基础的观察者模式后，看看不同框架中提供的组件：

比如 Provider 中提供了 ChangeNotifierProvider:

class Counter extend ChangeNotifier { 
	int count = 0;

	/// 调用此方法更新所有观察节点
	void increment() {
		count++;
		notifyListeners(); 
	}
}

void main() { 
	runApp(
		ChangeNotifierProvider(
			///  返回一个实现 ChangeNotifier 接口的对象 
			create: (_) => Counter(),
			child: const MyApp( ), 
		),
	);
 }

///  子节点通过 Consumer 获取 Counter 对象 
Consumer<Counter>(
	builder:(_, counter, _) => Text(counter.count.toString()) 

复制代码

还是之前计数器的例子，这里 Counter 继承了 ChangeNotifier 通过顶层的 Provider 进行存储。 子节点通过 Consumer 即可获取实例， 调用了 increment 方法之后，只有对应的 Text 组件进行变化。

同样的功能，在 Get 中， 只需要提前调用 Get.put 方法存储 Counter 对象， 为 GetBuilder 组件指定 Counter 作为泛型。 因为 Get 基于单例，所以 GetBuilder 可以直接通过泛型获取到存入的对象， 并在 builder 方法中暴露。这样 Counter 便与组件建立了监听关系， 之后 Counter 的变动，只会驱动以它作为泛型的 GetBuilder 组件更新。

class Counter extends GetxController { 
	int count = 0;

	void increase() { 
		count++;
		update(); 
	}
}

/// 提前进行存储
final counter = Get.put(Counter( )); 

/// 直接通过泛型获取存储好的实例
GetBuilder<Counter>(
	builder: (Counter counter) => Text('${counter.count}') ); 

复制代码

实践中的常见问题

在使用这些框架过程中，可能会遇到以下的问题：

Provider 中 context 层级过高

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Provider(
      create: (_) => const Count(),
      child: MaterialApp(
        home: Scaffold(
          body: Center(child: Text('${Provider.of<Counter>(context).count}')),
        ),
      ),
    );
  }
}
复制代码

如代码所示，当我们直接将 Provider 与组件嵌套于同一层级时， 这时代码中的 Provider.of(context) 运行时抛出 ProviderNotFoundException。 因为此处我们使用的 context 来自于 MyApp， 但 Provider 的 element 节点位于 MyApp 的下方， 所以 Provider.of(context) 无法获取到 Provider 节点。 这个问题可以有两种改法，如下方代码所示：

改法 1: 通过嵌套 Builder 组件，使用子节点的 context 访问:

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Provider(
      create: (_) => const Count(),
      child: MaterialApp(
        home: Scaffold(
          body: Center(
            child: Builder(builder: (builderContext) {
              return Text('${Provider.of<Counter>(builderContext).count}');
            }),
          ),
        ),
      ),
    );
  }
}
复制代码

改法 2: 将 Provider 提至顶层:

void main() {
  runApp(
    Provider(
      create: (_) => Counter(),
      child: const MyApp(),
    ),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(child: Text('${Provider.of<Counter>(context).count}')),
      ),
    );
  }
}
复制代码

Get 由于全局单例带来的问题

As mentioned earlier, Get uses a global singleton to store objects runtimeTypeas the some scenarios, the obtained objects may not meet expectations, such as jumping between product detail pages. Because different details page instances correspond to the same Class, that is, the runtimeTypesame . If the tag parameter is not added, calling on a certain page Get.findwill get the objects that have been stored in other pages. At the same time, you must pay attention to the recycling of objects in Get, otherwise it is likely to cause memory leaks. Either do it manually at disposepage time delete, or completely use the component provided in Get, for example GetBuilder, it will disposebe released in .

GetBuilderRecycling in disposephase :

@override
void dispose() {
  super.dispose();
  widget.dispose?.call(this);
  if (_isCreator! || widget.assignId) {
    if (widget.autoRemove && GetInstance().isRegistered<T>(tag: widget.tag)) {
      GetInstance().delete<T>(tag: widget.tag);
    }
  }

  _remove?.call();

  controller = null;
  _isCreator = null;
  _remove = null;
  _filter = null;
}

复制代码

Summary of the advantages and disadvantages of Get and Provider

Through this article, I introduced to you the necessity of state management, what problems it solves in Flutter development and how to solve them. At the same time, I also summarize the common problems in practice for you, see here You may still have some doubts, do you need to use state management?

In my opinion, frameworks exist to solve problems. So it depends on whether you are also going through those questions that were posed at the beginning. If there is, then you can try to solve it with state management; if not, there is no need to overdesign, use it for the sake of use.

Second, if using state management, which is better, Get or Provider?

These two frameworks have their own advantages and disadvantages. I think if you or your team is new to Flutter, using Provider can help you understand the core mechanism of Flutter faster. If you already have an understanding of the principles of Flutter, Get's rich functions and concise API can help you improve development efficiency.

Thanks to community members Alex, Luke, Lynn, Ming for their contributions to this article.