Flutter状态管理框架GetX使用体验
因为我们业务中使用的Flutter版本是1.12.13，对应的Dart版本为2.7，所以只使用了2.0.7版本的GetX包。
GetX框架在搭页面时使用起来确实比较方便，可以比较方便的将逻辑代码和界面解耦，并不需要创建诸多的模板文件。
不过这种灵活性也意味着标准不统一，团队协作时反而不太适合；在团队内使用，感觉还是需要搭配一个轻量化的结构化框架使用，比如BLoC。
使用这个版本的GetX写了Demo之后，发现有几个问题：
- 感觉不太像是稳定版本，存在一些比较明显的问题；而且2.0.6到2.0.7只是一个小版本，全局状态管理逻辑似乎就有比较大的改动；
- 不支持响应式编程，这个版本的状态管理还是基于state的逻辑；因为想要比较高效的解耦页面和逻辑，可能需要搭配响应式编程框架；
- 相关功能可能比较少，没有最新版本的功能那么全面；
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()返回的实例类型。