Flutter 状态管理框架

声明式 UI

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

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

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

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

声明式开发带来的问题

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

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

所以要使用状态管理框架

状态管理框架

fluuter_boost 跳转页面比较方法。。api 统一（原生 flutter），有生命周期，好管理

fluuter_boost3.0 不兼容最新的flutter版本，需要修改flutter_boost源码，暂时放弃该方案

Flutter 状态管理框架 Provider 和 Get 分析

解决逻辑和页面 UI 耦合问题
我们知道 Dart 是一种单线程的模型，所以不存在多线程下对于对象访问的竞态问题。基于此 Get 借助一个全局单例的 Map 存储对象。通过依赖注入的方式，实现了对 Presenter 层的获取。这样在任意的类中都可以获取到 Presenter。

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

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

setState 引起不必要刷新的问题
在 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}') ); 

Get 由于全局单例带来的问题
Get 通过全局单例，默认以 runtimeType 为 key 进行对象的存储，部分场景可能获取到的对象不符合预期，例如商品详情页之间跳转。由于不同的详情页实例对应的是同一 Class，即 runtimeType 相同。如果不添加 tag 参数，在某个页面调用 Get.find 会获取到其它页面已经存储过的对象。同时 Get 中一定要注意考虑到对象的回收，不然很有可能引起内存泄漏。要么手动在页面 dispose 的时候做 delete 操作，要么完全使用 Get 中提供的组件，例如 GetBuilder，它会在 dispose 中释放。

GetX使用

Flutter GetX使用—简洁的魅力！ - 掘金

打开页面，把这个页面前面的页面都关掉
类似 singleTop，启动页面需要指定路由名字
Get.to (() => MineAddAccountPage ( ), routeName: ‘name’);
然后关闭
Navigator.of (context). popUntil (ModalRoute.withName (‘/route-name’));

一样

Get.toNamed(BusinessRoutes.TAXI_HOME_PAGE);
Get.until((route) => Get.currentRoute ==BusinessRoutes.TAXI_HOME_PAGE );