Flutter状态管理框架GetX使用体验

Flutter状态管理框架GetX使用体验

因为我们业务中使用的Flutter版本是1.12.13,对应的Dart版本为2.7,所以只使用了2.0.7版本的GetX包。

GetX框架在搭页面时使用起来确实比较方便,可以比较方便的将逻辑代码和界面解耦,并不需要创建诸多的模板文件。
不过这种灵活性也意味着标准不统一,团队协作时反而不太适合;在团队内使用,感觉还是需要搭配一个轻量化的结构化框架使用,比如BLoC。

使用这个版本的GetX写了Demo之后,发现有几个问题:

  1. 感觉不太像是稳定版本,存在一些比较明显的问题;而且2.0.6到2.0.7只是一个小版本,全局状态管理逻辑似乎就有比较大的改动;
  2. 不支持响应式编程,这个版本的状态管理还是基于state的逻辑;因为想要比较高效的解耦页面和逻辑,可能需要搭配响应式编程框架;
  3. 相关功能可能比较少,没有最新版本的功能那么全面;

Demo地址:https://github.com/FantasyWind2016/state_manage_demos

功能理解

路由管理

GetX框架实现无context路由跳转,还是需要接管MaterialApp的创建,并在Get对象中持有navigatorKey,后面路由跳转,就不再需要context来获取了。
所以所有context相关的逻辑优化都是绑定在一起的,比如各种弹框,比如闪退监控;若每个功能都独立,就会是一层嵌套一层。所以对于无context的需求是可以催生出插件化需求的。比如做一个单独的MaterialApp托管框架,允许其他业务接入。类似于GetX高版本中的GetService。

状态管理

这个版本的GetX框架看得出比较简单,尤其是其状态管理部分,它相当于是给StatefulWidget实现了一个简单的子类GetBuilder,然后允许外部传入一个自定义state——GetController,而外部传入的state需要自己控制自己的setState时机。
需要根据状态更新的Widget用GetBuilder包裹,而业务逻辑放在GetController的子类中,这样就达到了将Widget配置和业务逻辑拆分开的目的。
另外,因为自定义state的实例化不是由自定义的statefulWiget创建,所以改state实例是不持有BuildContext的,所以需要在业务逻辑(也就是GetController的子类)中需要路由跳转时,就没法使用Navigator。不过GetX框架支持无context路由跳转。不知道这是一个巧合还是两个方案就是有因果关系的。
不过若是基于MVVM架构思维来考虑,路由的跳转可以放在View层,而负责逻辑的GetController不需要直接进行路由跳转,那么GetX只要实现了响应式编程,就可以在Widget层进行跳转,那么也可以解决该问题。但是如果采用此方案,需要跳转路由的页面还是需要使用StatefulWidget,因为StatelessWidget是没有持有context对象的。
若是想要尽最大可能抛弃StatefulWidget,那么无context路由跳转,还是需要的。

依赖管理

GetX文档中对该功能的描述是依赖注入(Dependency Injection),但感觉GetX所谓的依赖注入和通常说的概念不太一样,反而和依赖查找更像一些。
依赖注入是IoC(控制反转)模式的一种实现方式,它管理依赖关系的过程是IoC容器获得被依赖实例,并将之和依赖它的实例绑定,也就是所谓的“注入”。
而在GetX中,实例A通过GetX提供了Get.find()方法快速获取了他依赖的实例B,但调用Get.find()方法还是A直接发起的,并没有一个“注入”的过程。
GetX的依赖管理的效果有点类似于反射,是一个通过类来获取实例的快捷方式。但因为Flutter官方禁用了反射机制,所以反射实际上是不能用的。而GetX的使用方式基本就是通过Get.find()从实例池中获取指定类型或名称的实例。在这个过程中可能出现的变化(即控制反转)就是find()返回的实例类型。

你可能感兴趣的:(Dart实践,移动端架构,flutter,架构,状态管理,getx,移动开发)