前言
人心中的偏见是一座大山，任你怎么致力都休想搬动。
这是电影《哪吒》里申公豹说的一句话，也是贯彻整部电影的一个主题；或者这句话引起了太多人的共鸣：35岁职场危机，大厂卡本科学历，无房无车结婚难等等，所以，这句话也常常被人提起。
同时，因为GetX作者的一些舆论，也让一些偏见始终随同着GetX这个框架。
我写这篇文章，并不是为GetX正名
- 我自问本人并不是任何一个状态框架的死忠者，Provider和Bloc，我写了相干应用、原理分析文章和相干代码生成插件
- 在我心中，这类框架并没有如许神秘
- 因为对其原理较熟，上手应用是一件较为容易的事，所以切换相干框架没有多大的工夫老本
- 所以，我无需去做一个卫道者
GetX整体设计，有不少优良点思维，我心愿将这些优良设计思路展示给大家；或者会对你设计本人的框架有一些帮忙，同时也是对本人思考历程的一个记录。
前置常识
在说GetX设计思维之前，须要先介绍几个常识，在Flutter茁壮倒退的历程里，他们都留下了浓墨重彩的一笔
InheritedWidget
不得不说，这个控件真的是一个神奇控件，它就好像是一把神兵利器
- 宝刀屠龙，号令天下，莫敢不从，倚天不出，谁与争锋
- 倚天剑，剑藏《九阴真经》
- 屠龙刀，刀藏《降龙十八掌》、《武穆遗书》
InheritedWidget这把神兵藏有什么？
- 依赖节点，数据传输
- 定点刷新机制
数据传输
InheritedWidget是咱们统称的一个控件名，精华还是InheritedElement，InheritedWidget的数据传递，来看下存和取这俩个过程
存数据
- InheritedWidget存数据，是一个比较简单的操作，存储在InheritedElement中即可
class TransferDataWidget extends InheritedWidget { TransferDataWidget({required Widget child}) : super(child: child); @override bool updateShouldNotify(InheritedWidget oldWidget) => false; @override InheritedElement createElement() => TransferDataElement(this);}class TransferDataElement extends InheritedElement { TransferDataElement(InheritedWidget widget) : super(widget); ///轻易初始化什么, 设置只读都行 String value = '传输数据';}取数据
- 只有是 TransferDataWidget（下面InheritedWidget的子类） 的子节点，通过子节点的BuildContext（Element是BuildContext的实现类），都能够无缝的取数据
var transferDataElement = context.getElementForInheritedWidgetOfExactType<TransferDataWidget>() as TransferDataElement?;var msg = transferDataElement.value;能够发现，咱们只须要通过Element的getElementForInheritedWidgetOfExactType办法，就能够拿到父节点的TransferDataElement实例（必须继承InheritedElement）
拿到实例后，天然就能够很简略的拿到相应数据了
原理
能够发现咱们是拿到了XxxInheritedElement实例，继而拿到了贮存的值，所以要害在 getElementForInheritedWidgetOfExactType<T extends InheritedWidget>() 这个办法
- 代码很简略，就是从 _inheritedWidgets这个map里取值，泛型T是key
abstract class Element extends DiagnosticableTree implements BuildContext { Map<Type, InheritedElement>? _inheritedWidgets; @override InheritedElement? getElementForInheritedWidgetOfExactType<T extends InheritedWidget>() { assert(_debugCheckStateIsActiveForAncestorLookup()); final InheritedElement? ancestor = _inheritedWidgets == null ? null : _inheritedWidgets![T]; return ancestor; } ...}- 接下来只有搞清楚 _inheritedWidgets 是怎么存值，那么所有都会清朗
abstract class ComponentElement extends Element { @mustCallSuper void mount(Element? parent, dynamic newSlot) { ... _updateInheritance(); } void _updateInheritance() { assert(_lifecycleState == _ElementLifecycle.active); _inheritedWidgets = _parent?._inheritedWidgets; } ...}abstract class ProxyElement extends ComponentElement { ...}class InheritedElement extends ProxyElement { InheritedElement(InheritedWidget widget) : super(widget); @override void _updateInheritance() { assert(_lifecycleState == _ElementLifecycle.active); final Map<Type, InheritedElement>? incomingWidgets = _parent?._inheritedWidgets; if (incomingWidgets != null) _inheritedWidgets = HashMap<Type, InheritedElement>.from(incomingWidgets); else _inheritedWidgets = HashMap<Type, InheritedElement>(); _inheritedWidgets![widget.runtimeType] = this; }}整体上逻辑还是比拟清晰
遇到某个节点为 InheritedWidget 时，会将父节点的 _inheritedWidgets 变量给 incomingWidgets 这个长期变量
- incomingWidgets 为空：为父类Element的 _inheritedWidgets 变量， 实例了一个map对象
- incomingWidgets 不为空：将父节点_inheritedWidgets 所有数据深拷贝，返回一个全新的Map实例（含有父节点 _inheritedWidgets 所有数据），赋值给父类Element的 _inheritedWidgets 变量
- 将本身实例赋值给父类Element的 _inheritedWidgets 变量，key为其widget的runtimeType
为什么任何一个Widget的Element实例的 _inheritedWidgets 变量，可间接拿到父节点InheritedElement实例？
- Element中做了一个父节点向子节点赋值的操作：整个数据传输链清晰了
abstract class Element extends DiagnosticableTree implements BuildContext { Map<Type, InheritedElement>? _inheritedWidgets; void _updateInheritance() { assert(_lifecycleState == _ElementLifecycle.active); _inheritedWidgets = _parent?._inheritedWidgets; } ...}- 图示
刷新机制
InheritedElement和Element之间有一些交互，实际上自带了一套刷新机制
- InheritedElement存子节点Element： _dependents，这个变量是用来存储，须要刷新的子Element
class InheritedElement extends ProxyElement { InheritedElement(InheritedWidget widget) : super(widget); final Map<Element, Object?> _dependents = HashMap<Element, Object?>(); @protected void setDependencies(Element dependent, Object? value) { _dependents[dependent] = value; } @protected void updateDependencies(Element dependent, Object? aspect) { setDependencies(dependent, null); }}InheritedElement刷新子Element
- notifyClients这个办法就是将 _dependents 存储的Element，全副拿了进去，传入notifyDependent
- 在notifyDependent办法中，传入Element调用了本身didChangeDependencies()办法
- Element的didChangeDependencies() 办法会调用 markNeedsBuild() ，来刷新本身
class InheritedElement extends ProxyElement { InheritedElement(InheritedWidget widget) : super(widget); final Map<Element, Object?> _dependents = HashMap<Element, Object?>(); @protected void notifyDependent(covariant InheritedWidget oldWidget, Element dependent) { dependent.didChangeDependencies(); } @override void notifyClients(InheritedWidget oldWidget) { for (final Element dependent in _dependents.keys) { ... notifyDependent(oldWidget, dependent); } }}abstract class Element extends DiagnosticableTree implements BuildContext { ... @mustCallSuper void didChangeDependencies() { assert(_lifecycleState == _ElementLifecycle.active); // otherwise markNeedsBuild is a no-op assert(_debugCheckOwnerBuildTargetExists('didChangeDependencies')); markNeedsBuild(); } ...}InheritedWidget的子节点是怎么将本身Element
增加到InheritedElement的_dependents变量里的呢？
Element外面有个 dependOnInheritedElement 办法
- Element中dependOnInheritedElement办法，会传入InheritedElement实例 ancestor
- ancestor调用updateDependencies办法，将本身的Element实例传入
- InheritedElement中就将这个Element，增加到_dependents变量中了
abstract class Element extends DiagnosticableTree implements BuildContext { ... @override InheritedWidget dependOnInheritedElement(InheritedElement ancestor, { Object? aspect }) { assert(ancestor != null); _dependencies ??= HashSet<InheritedElement>(); _dependencies!.add(ancestor); ancestor.updateDependencies(this, aspect); return ancestor.widget; } ...}class InheritedElement extends ProxyElement { InheritedElement(InheritedWidget widget) : super(widget); final Map<Element, Object?> _dependents = HashMap<Element, Object?>(); @protected void setDependencies(Element dependent, Object? value) { _dependents[dependent] = value; } @protected void updateDependencies(Element dependent, Object? aspect) { setDependencies(dependent, null); }}dependOnInheritedElement该办法的应用也很简略
- 一般来说在某个Widget应用 getElementForInheritedWidgetOfExactType 获取父节点的 InheritedElement
- 而后将其传入 dependOnInheritedElement 办法中即可
// 举例var inheritedElement = context .getElementForInheritedWidgetOfExactType<ChangeNotifierEasyP<T>>() as EasyPInheritedElement<T>?;context.dependOnInheritedElement(inheritedElement);Provider外围原理，就是采纳了InheritedWidget这种刷新机制
想具体理解Provider相干原理，可参考上面文章
- 源码篇：Flutter Provider的另一面（万字图文）
图示
- 来看下InheritedWidget刷新机制的图示
路由小常识
- 路由Navigator中根本都是些操作路由的静态方法，NavigatorState是实现的具体逻辑
大家在应用InheritedWidget获取数据的时候，或者有过这样一种困扰：A页面 ---> B页面 ---> C页面
如果我在A页面应用InheritedWidget贮存了数据，跳转到B页面或者C页面，会发现应用context获取不到A页面的InheritedElement
这侧面证实了Navigator路由跳转：A页面跳转B页面，B页面并不是A页面的子节点
- 大抵构造：可勉强了解为，Navigator是所有页面父节点，页面与页面之间是平级关系
这里我画了下大抵构造，如有偏差，请务必指出来，我会尽快批改
对于Flutter路由原理解析，可参考此文章（作者为啥当初不更文了呢 ~~）：Flutter 路由原理解析
思考
InheritedWidget为咱们带了很多便当
- 能够在一个Widget树范畴，获取到咱们想要InheritedElement（通过泛型辨别即可）
- InheritedElement和Element各种交互，也实现了一套极其简洁的刷新机制
- 进行一些深度封装，甚至能够无缝的治理很多控件的资源开释
然而，Element提供的获取InheritedElement的形式，究竟和路由机制无奈很好的联合；这也模块设计无奈防止的事件，或者某些模块设计的最优解，很难顾虑到其它模快的一些机制
InheritedWidget这把神兵利器，在咱们学习Flutter历程中给予了很多帮忙
- 然而，当需要逐步简单，你的技术一直精进
- 屠龙刀这把神兵，或者慢慢的，不太适宜你了
- 有时候，它甚至制约了你的出招
- 一位制作神兵的铁匠，在他心中，最好的神兵利器，或者永远是下一把
大部分的状态治理框架，将界面层和逻辑层离开，都是逻辑层来解决界面的刷新；逻辑层能够交给InheritedWidget存储管理；阐明，咱们本人也肯定能够存储管理！
- 本人来治理逻辑层，能够解脱Element树的束缚，不必被困在Element树的父子节点中
- 在路由跳转的页面中，能够很轻松的获取上一页面，下一个页面或者上上一个页面逻辑层。
这也是GetX中一个核心思想，这并不是一个如许新鲜或浅近技术，然而，我这感觉这是一种思维上的冲破，能够带来更多的可能
依赖注入
阐明
依赖注入有如下实现形式（维基百科）：
- 基于接口。实现特定接口以供内部容器注入所依赖类型的对象。
- 基于 set 办法。实现特定属性的public set办法，来让内部容器调用传入所依赖类型的对象。
- 基于构造函数。实现特定参数的构造函数，在新建对象时传入所依赖类型的对象。
- 基于注解。基于Java的注解性能，在公有变量前加“@Autowired”等注解，不须要显式的定义以上三种代码，便能够让内部容器传入对应的对象。该计划相当于定义了public的set办法，然而因为没有真正的set办法，从而不会为了实现依赖注入导致裸露了不该裸露的接口（因为set办法只想让容器拜访来注入而并不心愿其余依赖此类的对象拜访）。
强耦合类型的，基于构造函数
class Test { String msg; Test(String msg) { this.msg = msg; }}set形式
class Test { String? _msg; void setMsg(String msg) { this._msg = msg; }}如果在Java中，图一时不便，间接在构造函数外面传值，而后须要的值越来越多，导致须要减少该构造函数传参，因为强耦合很多类，一改构造函数，爆红一大片（Dart构造函数可选参数的个性，就没有这类问题了）
- Getx注入的GetXController都是由GetX框架本人来保护的，如果没有GetX这个中间层会是什么样的？
引入GetX这个中间层来治理
- 看下图，霎时就想到了中介者模式
- 这也是管制反转的思维（创建对象的控制权原本在本人手上，当初交给了第三方）
Put
来看下GetX注入的操作
- put应用
var controller = Get.put(XxxGetxController());看看外部操作
- 哎，各种骚操作
- 次要逻辑在Inst中，Inst是GetInterface的扩大类
class _GetImpl extends GetInterface {}final Get = _GetImpl();extension Inst on GetInterface { S put<S>(S dependency, {String? tag, bool permanent = false, InstanceBuilderCallback<S>? builder}) => GetInstance().put<S>(dependency, tag: tag, permanent: permanent);}次要的逻辑看来还是GetInstance中
- 大家能够看看这中央单例的实现，我发现很多源码都用这种形式写的，十分简洁
全局的数据都是存在 _singl 中，这是个Map
- key：对象的runtimeType或者类的Type + tag
- value：_InstanceBuilderFactory类，咱们传入dependedt对象会存入这个类中
_singl 这个map存值的时候，不是用的put，而是用的putIfAbsent
- 如果map中有key和传入key雷同的数据，传入的数据将不会被存储
- 也就是说雷同类实例的对象，传入并不会被笼罩，只会存储第一条数据，后续被放弃
- 最初应用find办法，返回传入的实例
class GetInstance { factory GetInstance() => _getInstance ??= GetInstance._(); const GetInstance._(); static GetInstance? _getInstance; static final Map<String, _InstanceBuilderFactory> _singl = {}; S put<S>( S dependency, { String? tag, bool permanent = false, @deprecated InstanceBuilderCallback<S>? builder, }) { _insert( isSingleton: true, name: tag, permanent: permanent, builder: builder ?? (() => dependency)); return find<S>(tag: tag); } void _insert<S>({ bool? isSingleton, String? name, bool permanent = false, required InstanceBuilderCallback<S> builder, bool fenix = false, }) { final key = _getKey(S, name); _singl.putIfAbsent( key, () => _InstanceBuilderFactory<S>( isSingleton, builder, permanent, false, fenix, name, ), ); } String _getKey(Type type, String? name) { return name == null ? type.toString() : type.toString() + name; } S find<S>({String? tag}) { final key = _getKey(S, tag); if (isRegistered<S>(tag: tag)) { if (_singl[key] == null) { if (tag == null) { throw 'Class "$S" is not registered'; } else { throw 'Class "$S" with tag "$tag" is not registered'; } } final i = _initDependencies<S>(name: tag); return i ?? _singl[key]!.getDependency() as S; } else { // ignore: lines_longer_than_80_chars throw '"$S" not found. You need to call "Get.put($S())" or "Get.lazyPut(()=>$S())"'; } }}find
- find办法还是蛮简略的，就是从map中取数据的操作
S find<S>({String? tag}) => GetInstance().find<S>(tag: tag);看下具体逻辑
- 先判断 _singl 中是否含有该key的数据，有则取，无则抛异样
- 要害代码： _singl[key]!.getDependency() as S ，间接通过key去map取值就行了
class GetInstance { factory GetInstance() => _getInstance ??= GetInstance._(); const GetInstance._(); static GetInstance? _getInstance; static final Map<String, _InstanceBuilderFactory> _singl = {}; String _getKey(Type type, String? name) { return name == null ? type.toString() : type.toString() + name; } bool isRegistered<S>({String? tag}) => _singl.containsKey(_getKey(S, tag)); S find<S>({String? tag}) { final key = _getKey(S, tag); if (isRegistered<S>(tag: tag)) { if (_singl[key] == null) { if (tag == null) { throw 'Class "$S" is not registered'; } else { throw 'Class "$S" with tag "$tag" is not registered'; } } final i = _initDependencies<S>(name: tag); return i ?? _singl[key]!.getDependency() as S; } else { // ignore: lines_longer_than_80_chars throw '"$S" not found. You need to call "Get.put($S())" or "Get.lazyPut(()=>$S())"'; } }}GetBuilder刷新机制
应用
为了常识的连续性，此处简略的写下应用
- 逻辑层
class GetCounterEasyLogic extends GetxController { var count = 0; void increase() { ++count; update(); }}- 界面
class GetCounterEasyPage extends StatelessWidget { final GetCounterEasyLogic logic = Get.put(GetCounterEasyLogic()); @override Widget build(BuildContext context) { return BaseScaffold( appBar: AppBar(title: const Text('计数器-简略式')), body: Center( child: GetBuilder<GetCounterEasyLogic>(builder: (logic) { return Text( '点击了 ${logic.count} 次', style: TextStyle(fontSize: 30.0), ); }), ), floatingActionButton: FloatingActionButton( onPressed: () => logic.increase(), child: Icon(Icons.add), ), ); }}GetBuilder
有一天，我躺在床上思考
- Obx的状态治理，GetXController实例回收是放在路由外面，在很多场景下，存在一些局限性
- 起初我想到，GetBuilder应用带泛型，这就能拿到GetxController实例，GetBuilder又是StatefulWidget
- 这样就能够应用它来回收实例，能解决很多场景下，GetXController实例无奈回收的问题（不应用Getx路由）
- 我兴致冲冲的关上Getx我的项目，筹备提PR，而后发现GetBuilder曾经在dispose外面写了回收实例的操作
- 淦！
内置回收机制
- 此处精简很多代码，只展现回收机制的代码
class GetBuilder<T extends GetxController> extends StatefulWidget { final GetControllerBuilder<T> builder; final bool global; final String? tag; final bool autoRemove; final T? init; const GetBuilder({ Key? key, this.init, this.global = true, required this.builder, this.autoRemove = true, this.initState, this.tag, }) : super(key: key); @override GetBuilderState<T> createState() => GetBuilderState<T>();}class GetBuilderState<T extends GetxController> extends State<GetBuilder<T>> with GetStateUpdaterMixin { T? controller; bool? _isCreator = false; VoidCallback? _remove; Object? _filter; @override void initState() { super.initState(); widget.initState?.call(this); var isRegistered = GetInstance().isRegistered<T>(tag: widget.tag); if (widget.global) { if (isRegistered) { controller = GetInstance().find<T>(tag: widget.tag); } else { controller = widget.init; GetInstance().put<T>(controller!, tag: widget.tag); } } else { controller = widget.init; controller?.onStart(); } } @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; } @override Widget build(BuildContext context) { return widget.builder(controller!); }}代码里的逻辑还是相当清晰的，initState获取实例，dispose回收实例
通过GetBuilder上泛型获取相应GetXController实例
- 不存在：应用init传入的实例
- 存在：间接应用；init传入的实例有效
autoRemove能够管制是否主动回收GetXController实例
- 默认为true：默认开启主动回收
- true：开启主动回收 false：敞开主动回收
刷新逻辑
- 这里仅保留刷新逻辑的相干代码，去掉了无需关注的代码
mixin GetStateUpdaterMixin<T extends StatefulWidget> on State<T> { void getUpdate() { if (mounted) setState(() {}); }}class GetBuilder<T extends GetxController> extends StatefulWidget { final GetControllerBuilder<T> builder; final bool global; final T? init; final Object? id; const GetBuilder({ Key? key, this.init, this.id, this.global = true, required this.builder, }) : super(key: key); @override GetBuilderState<T> createState() => GetBuilderState<T>();}class GetBuilderState<T extends GetxController> extends State<GetBuilder<T>> with GetStateUpdaterMixin { T? controller; @override void initState() { super.initState(); ... if (widget.global) { if (isRegistered) { controller = GetInstance().find<T>(tag: widget.tag); } else { controller = widget.init; GetInstance().put<T>(controller!, tag: widget.tag); } } else { controller = widget.init; controller?.onStart(); } _subscribeToController(); } void _subscribeToController() { _remove?.call(); _remove = (widget.id == null) ? controller?.addListener( _filter != null ? _filterUpdate : getUpdate, ) : controller?.addListenerId( widget.id, _filter != null ? _filterUpdate : getUpdate, ); } void _filterUpdate() { var newFilter = widget.filter!(controller!); if (newFilter != _filter) { _filter = newFilter; getUpdate(); } } @override void didChangeDependencies() { super.didChangeDependencies(); widget.didChangeDependencies?.call(this); } @override void didUpdateWidget(GetBuilder oldWidget) { super.didUpdateWidget(oldWidget as GetBuilder<T>); if (oldWidget.id != widget.id) { _subscribeToController(); } widget.didUpdateWidget?.call(oldWidget, this); } @override Widget build(BuildContext context) { return widget.builder(controller!); }}关键步骤
- 通过泛型获取注入的GetXController实例
增加监听代码
- addListener：增加监听回调
- addListenerId：增加监听回调，必须设置id，update刷新的时候也必须写上配套的id
监听代码：外围代码就是getUpdate办法，办法在 GetStateUpdaterMixin 中
- getUpdate()逻辑就是 setState()，刷新以后GetBuilder
图示
Update
触发逻辑还是很简略的，应用update即可
- Ids：和下面的Getbuilder对应起来了，可刷新对应设置id的GetBuilder
- condition：是否刷新一个判断条件，默认为true（假如必须某个id大于3能力刷新：update([1, 2, 3, 4], index > 3) ）
abstract class GetxController extends DisposableInterface with ListNotifier { void update([List<Object>? ids, bool condition = true]) { if (!condition) { return; } if (ids == null) { refresh(); } else { for (final id in ids) { refreshGroup(id); } } }}看下要害办法 refresh()，在ListNotifier类中
- 能够发现，_updaters中泛型就是一个办法
- 在GetBuilder中增加的监听就是一个办法参数，办法体外面就是 setState()
- 齐活了！GetBuilder增加办法（办法体是setState），update遍历触发所有增加办法
typedef GetStateUpdate = void Function();class ListNotifier implements Listenable { List<GetStateUpdate?>? _updaters = <GetStateUpdate?>[]; HashMap<Object?, List<GetStateUpdate>>? _updatersGroupIds = HashMap<Object?, List<GetStateUpdate>>(); @protected void refresh() { assert(_debugAssertNotDisposed()); _notifyUpdate(); } void _notifyUpdate() { for (var element in _updaters!) { element!(); } } ...}如果在update中加了id参数，会走refreshGroup办法，逻辑和refresh简直一样，差异是对id的判断：有则执行，无则跳过
- 遍历所有ids，而后执行refreshGroup办法
abstract class GetxController extends DisposableInterface with ListNotifier { void update([List<Object>? ids, bool condition = true]) { if (!condition) { return; } if (ids == null) { refresh(); } else { for (final id in ids) { refreshGroup(id); } } }}class ListNotifier implements Listenable { HashMap<Object?, List<GetStateUpdate>>? _updatersGroupIds = HashMap<Object?, List<GetStateUpdate>>(); void _notifyIdUpdate(Object id) { if (_updatersGroupIds!.containsKey(id)) { final listGroup = _updatersGroupIds![id]!; for (var item in listGroup) { item(); } } } @protected void refreshGroup(Object id) { assert(_debugAssertNotDisposed()); _notifyIdUpdate(id); }}总结
- 来看下GetBuilder刷新图示
Obx刷新机制
这套刷新机制，和咱们罕用的状态治理框架（provider，bloc）以及下面的GetBuilder，在应用上有一些区别
变量上：根底类型，实体以及列表之类的数据类型，作者都封装了一套Rx类型，快捷在数据后加obs
- 例如：RxString msg = "test".obs（var msg = "test".obs）
- 更新上：根底类型间接更新数据就行，实体须要以 .update() 的模式
应用上：应用这类变量，个别要加上 .value ，作者也给出一个快捷方式变量前面加个 ()
- 我不太举荐加 () 的模式，对后续保护我的项目人太不敌对了
Obx刷新机制，最乏味应该就是变量扭转后，包裹该变量的Obx会主动刷新！留神喔，仅仅是包裹该变量的Obx会刷新！其它的Obx并不会刷新。
这是怎么做到的呢？
- 实际上，实现起来很简略
- 然而，如果没有接触过这个思路，恐怕抓破头，都很难想进去，还能这么玩。。。
应用
简略的来看下应用
- logic
class GetCounterRxLogic extends GetxController { var count = 0.obs; ///自增 void increase() => ++count;}- view
class GetCounterRxPage extends StatelessWidget { final GetCounterRxLogic logic = Get.put(GetCounterRxLogic()); @override Widget build(BuildContext context) { return BaseScaffold( appBar: AppBar(title: const Text('计数器-响应式')), body: Center( child: Obx(() { return Text( '点击了 ${logic.count.value} 次', style: TextStyle(fontSize: 30.0), ); }), ), floatingActionButton: FloatingActionButton( onPressed: () => logic.increase(), child: Icon(Icons.add), ), ); }}Rx类变量
此处以 RxInt 为例，来看下其外部实现
- 先来看下整型前面的拓展 obs ，这是一个扩大类，0.obs 等同 RxInt(0)
extension IntExtension on int { /// Returns a `RxInt` with [this] `int` as initial value. RxInt get obs => RxInt(this);}- 来看下RxInt：这中央明确了应用 .value 运行时，会主动返回一个以后实例，并批改相应value数值
class RxInt extends Rx<int> { RxInt(int initial) : super(initial); /// Addition operator. RxInt operator +(int other) { value = value + other; return this; } /// Subtraction operator. RxInt operator -(int other) { value = value - other; return this; }}来看下父类 Rx<T>
- 这中央呈现了一个很重要的类： _RxImpl<T>
class Rx<T> extends _RxImpl<T> { Rx(T initial) : super(initial); @override dynamic toJson() { try { return (value as dynamic)?.toJson(); } on Exception catch (_) { throw '$T has not method [toJson]'; } }}_RxImpl<T> 类继承了 RxNotifier<T> 和 with 了 RxObjectMixin<T>
- 这个类内容是比拟宏大的，次要是 RxNotifier<T> 和 RxObjectMixin<T> 内容很多
- 代码很多，先展现下残缺代码；在下一个阐明处会进行简化
abstract class _RxImpl<T> extends RxNotifier<T> with RxObjectMixin<T> { _RxImpl(T initial) { _value = initial; } void addError(Object error, [StackTrace? stackTrace]) { subject.addError(error, stackTrace); } Stream<R> map<R>(R mapper(T? data)) => stream.map(mapper); void update(void fn(T? val)) { fn(_value); subject.add(_value); } void trigger(T v) { var firstRebuild = this.firstRebuild; value = v; if (!firstRebuild) { subject.add(v); } }}class RxNotifier<T> = RxInterface<T> with NotifyManager<T>;mixin NotifyManager<T> { GetStream<T> subject = GetStream<T>(); final _subscriptions = <GetStream, List<StreamSubscription>>{}; bool get canUpdate => _subscriptions.isNotEmpty; void addListener(GetStream<T> rxGetx) { if (!_subscriptions.containsKey(rxGetx)) { final subs = rxGetx.listen((data) { if (!subject.isClosed) subject.add(data); }); final listSubscriptions = _subscriptions[rxGetx] ??= <StreamSubscription>[]; listSubscriptions.add(subs); } } StreamSubscription<T> listen( void Function(T) onData, { Function? onError, void Function()? onDone, bool? cancelOnError, }) => subject.listen( onData, onError: onError, onDone: onDone, cancelOnError: cancelOnError ?? false, ); void close() { _subscriptions.forEach((getStream, _subscriptions) { for (final subscription in _subscriptions) { subscription.cancel(); } }); _subscriptions.clear(); subject.close(); }}mixin RxObjectMixin<T> on NotifyManager<T> { late T _value; void refresh() { subject.add(value); } T call([T? v]) { if (v != null) { value = v; } return value; } bool firstRebuild = true; String get string => value.toString(); @override String toString() => value.toString(); dynamic toJson() => value; @override bool operator ==(dynamic o) { if (o is T) return value == o; if (o is RxObjectMixin<T>) return value == o.value; return false; } @override int get hashCode => _value.hashCode; set value(T val) { if (subject.isClosed) return; if (_value == val && !firstRebuild) return; firstRebuild = false; _value = val; subject.add(_value); } T get value { if (RxInterface.proxy != null) { RxInterface.proxy!.addListener(subject); } return _value; } Stream<T?> get stream => subject.stream; void bindStream(Stream<T> stream) { final listSubscriptions = _subscriptions[subject] ??= <StreamSubscription>[]; listSubscriptions.add(stream.listen((va) => value = va)); }}简化 _RxImpl<T>，下面内容太多了，我这中央简化下，把须要关注的内容展现进去：此处有几个须要重点关注的点
- RxInt是一个内置callback的数据类型（GetStream）
- RxInt的value变量扭转的时候（set value），会触发subject.add(_value)，外部逻辑是主动刷新操作
- 获取RxInt的value变量的时候（get value），会有一个增加监听的操作，这个灰常重要！
abstract class _RxImpl<T> extends RxNotifier<T> with RxObjectMixin<T> { void update(void fn(T? val)) { fn(_value); subject.add(_value); }}class RxNotifier<T> = RxInterface<T> with NotifyManager<T>;mixin NotifyManager<T> { GetStream<T> subject = GetStream<T>(); final _subscriptions = <GetStream, List<StreamSubscription>>{}; bool get canUpdate => _subscriptions.isNotEmpty; void addListener(GetStream<T> rxGetx) { if (!_subscriptions.containsKey(rxGetx)) { final subs = rxGetx.listen((data) { if (!subject.isClosed) subject.add(data); }); final listSubscriptions = _subscriptions[rxGetx] ??= <StreamSubscription>[]; listSubscriptions.add(subs); } }}mixin RxObjectMixin<T> on NotifyManager<T> { late T _value; void refresh() { subject.add(value); } set value(T val) { if (subject.isClosed) return; if (_value == val && !firstRebuild) return; firstRebuild = false; _value = val; subject.add(_value); } T get value { if (RxInterface.proxy != null) { RxInterface.proxy!.addListener(subject); } return _value; }}为啥GetStream的add会有刷新操作：删了很多代码，保留了重点代码
- 调用add办法时候，会调用 _notifyData 办法
- _notifyData 办法中，会遍历 _onData 列表，依据条件会执行其泛型的 _data 的办法
- 我猜，_data 中的办法体，十有八九在某个中央必定增加了 setState()
class GetStream<T> { GetStream({this.onListen, this.onPause, this.onResume, this.onCancel}); List<LightSubscription<T>>? _onData = <LightSubscription<T>>[]; FutureOr<void> addSubscription(LightSubscription<T> subs) async { if (!_isBusy!) { return _onData!.add(subs); } else { await Future.delayed(Duration.zero); return _onData!.add(subs); } } void _notifyData(T data) { _isBusy = true; for (final item in _onData!) { if (!item.isPaused) { item._data?.call(data); } } _isBusy = false; } T? _value; T? get value => _value; void add(T event) { assert(!isClosed, 'You cannot add event to closed Stream'); _value = event; _notifyData(event); }}typedef OnData<T> = void Function(T data);class LightSubscription<T> extends StreamSubscription<T> { OnData<T>? _data;}图示，先来看下，Rx类具备的性能
- get value 增加监听
- set value 执行已增加的监听
Obx刷新机制
Obx最大的非凡之处，应该就是应用它的时候，不须要加泛型且能主动刷新，这是怎么做到的呢？
Obx：代码并不多，然而皆有妙用
- Obx继承ObxWidget，ObxWidget实际上也是一个StatefulWidget
- _ObxState 中代码就是外围代码了
class Obx extends ObxWidget { final WidgetCallback builder; const Obx(this.builder); @override Widget build() => builder();}abstract class ObxWidget extends StatefulWidget { const ObxWidget({Key? key}) : super(key: key); @override _ObxState createState() => _ObxState(); @protected Widget build();}class _ObxState extends State<ObxWidget> { RxInterface? _observer; late StreamSubscription subs; _ObxState() { _observer = RxNotifier(); } @override void initState() { subs = _observer!.listen(_updateTree, cancelOnError: false); super.initState(); } void _updateTree(_) { if (mounted) { setState(() {}); } } @override void dispose() { subs.cancel(); _observer!.close(); super.dispose(); } Widget get notifyChilds { final observer = RxInterface.proxy; RxInterface.proxy = _observer; final result = widget.build(); if (!_observer!.canUpdate) { throw """ [Get] the improper use of a GetX has been detected. You should only use GetX or Obx for the specific widget that will be updated. If you are seeing this error, you probably did not insert any observable variables into GetX/Obx or insert them outside the scope that GetX considers suitable for an update (example: GetX => HeavyWidget => variableObservable). If you need to update a parent widget and a child widget, wrap each one in an Obx/GetX. """; } RxInterface.proxy = observer; return result; } @override Widget build(BuildContext context) => notifyChilds;}增加监听
一个控件想刷新，必定有增加监听的逻辑，再在某个中央手动触发
- 看下_ObxState类在哪增加监听：只展现监听增加的代码
- _ObxState初始化的时候，会实例化一个 RxNotifier() 对象，应用 _observer变量承受：这个操作很重要
- initState中做了一个比拟要害的操作，_observer的listener办法中，将 _updateTree办法传进去了，这个办法中的逻辑体就是 setState()
class _ObxState extends State<ObxWidget> { RxInterface? _observer; late StreamSubscription subs; _ObxState() { _observer = RxNotifier(); } @override void initState() { subs = _observer!.listen(_updateTree, cancelOnError: false); super.initState(); } void _updateTree(_) { if (mounted) { setState(() {}); } }}上述很多逻辑和 RxNotifier 类相干，来看下这个类
- RxNotifier 这个类，外部会实例一个 GetStream<T>() 对象，而后赋值给 subject
- 下面赋值 _updateTree 办法被传入的 GetStream<T>() 类中，最终增加 _onData 该列表变量中
- 瞟一眼 _notifyData办法，是不是遍历执行了 _onData 列表中item的办法（ item. _data?.call(data) ）
class RxNotifier<T> = RxInterface<T> with NotifyManager<T>;mixin NotifyManager<T> { GetStream<T> subject = GetStream<T>(); final _subscriptions = <GetStream, List<StreamSubscription>>{}; bool get canUpdate => _subscriptions.isNotEmpty; StreamSubscription<T> listen( void Function(T) onData, { Function? onError, void Function()? onDone, bool? cancelOnError, }) => subject.listen( onData, onError: onError, onDone: onDone, cancelOnError: cancelOnError ?? false, );}class GetStream<T> { void Function()? onListen; void Function()? onPause; void Function()? onResume; FutureOr<void> Function()? onCancel; GetStream({this.onListen, this.onPause, this.onResume, this.onCancel}); List<LightSubscription<T>>? _onData = <LightSubscription<T>>[]; FutureOr<void> addSubscription(LightSubscription<T> subs) async { if (!_isBusy!) { return _onData!.add(subs); } else { await Future.delayed(Duration.zero); return _onData!.add(subs); } } int? get length => _onData?.length; bool get hasListeners => _onData!.isNotEmpty; void _notifyData(T data) { _isBusy = true; for (final item in _onData!) { if (!item.isPaused) { item._data?.call(data); } } _isBusy = false; } LightSubscription<T> listen(void Function(T event) onData, {Function? onError, void Function()? onDone, bool? cancelOnError}) { final subs = LightSubscription<T>( removeSubscription, onPause: onPause, onResume: onResume, onCancel: onCancel, ) ..onData(onData) ..onError(onError) ..onDone(onDone) ..cancelOnError = cancelOnError; addSubscription(subs); onListen?.call(); return subs; }}- 下面代码流程有一点绕，上面画了一个图，心愿对各位有所帮忙
监听转移
在_ObxState类中做了一个很重要，监听对象转移的操作
_observer中的对象曾经拿到了Obx控件外部的setState办法，当初须要将它转移进来啦！
上面贴下将 _observer 中对象转移进来的代码：次要的逻辑就是在 notifyChilds 办法中
- RxInterface 类中有个 proxy 动态变量，这个变量非常重要，他是一个中转变量！
`class _ObxState extends State<ObxWidget> { RxInterface? _observer; _ObxState() { _observer = RxNotifier(); } Widget get notifyChilds { final observer = RxInterface.proxy; RxInterface.proxy = _observer; final result = widget.build(); if (!_observer!.canUpdate) { throw """ [Get] the improper use of a GetX has been detected. You should only use GetX or Obx for the specific widget that will be updated. If you are seeing this error, you probably did not insert any observable variables into GetX/Obx or insert them outside the scope that GetX considers suitable for an update (example: GetX => HeavyWidget => variableObservable). If you need to update a parent widget and a child widget, wrap each one in an Obx/GetX. """; } RxInterface.proxy = observer; return result; } @override Widget build(BuildContext context) => notifyChilds;}abstract class RxInterface<T> { bool get canUpdate; void addListener(GetStream<T> rxGetx); void close(); static RxInterface? proxy; StreamSubscription<T> listen(void Function(T event) onData, {Function? onError, void Function()? onDone, bool? cancelOnError});}notifyChilds中的几行代码都有深意，一行行的解读下
- final observer = RxInterface.proxy：RxInterface.proxy失常状况为空，然而，可能作为两头变量暂存对象的状况，当初临时将他的对象取出来，存在observer变量中
RxInterface.proxy = _observer：将咱们在 _ObxState类中实例化的 RxNotifier() 对象的地址，赋值给了RxInterface.proxy
- 留神：这里，RxInterface.proxy中 RxNotifier() 实例，有以后Obx控件的setState() 办法
final result = widget.build()：这个赋值相当重要了！调用咱们在内部传进的Widget
- 如果这个Widget中有响应式变量，那么肯定会调用该变量中获取 get value
还记得get value的代码吗？
mixin RxObjectMixin<T> on NotifyManager<T> { late T _value; T get value { if (RxInterface.proxy != null) { RxInterface.proxy!.addListener(subject); } return _value; }}mixin NotifyManager<T> { GetStream<T> subject = GetStream<T>();}
终于建设起分割了，将变量中 GetStream 实例，增加到了Obx中的 RxNotifier() 实例；RxNotifier() 实例中有一个 subject（GetStream ） 实例，Rx类型中数据变动会触发 subject 变动，最终刷新Obx
mixin NotifyManager<T> { GetStream<T> subject = GetStream<T>(); final _subscriptions = <GetStream, List<StreamSubscription>>{}; bool get canUpdate => _subscriptions.isNotEmpty; void addListener(GetStream<T> rxGetx) { if (!_subscriptions.containsKey(rxGetx)) { //重点 GetStream中listen办法是用来增加监听办法的，add的时候会刷新监听办法 final subs = rxGetx.listen((data) { if (!subject.isClosed) subject.add(data); }); final listSubscriptions = _subscriptions[rxGetx] ??= <StreamSubscription>[]; listSubscriptions.add(subs); } }}
- if (!_observer!.canUpdate) {}：这个判断就很简略了，如果咱们传入的Widget中没有Rx类型变量， _subscriptions数组就会为空，这个判断就会过不了
- RxInterface.proxy = observer：将RxInterface.proxy中原来的值，从新赋给本人，至此 _ObxState 中的 _observer对象地址，进行了一番奇幻游览后，完结了本人的使命
图示
总结
Obx的刷新机制，还是蛮有乏味的
- Rx变量扭转，主动刷新包裹其变量Obx控件，其它的Obx控件并不会刷新
- 应用Obx控件，不须要写泛型！牛批！
然而，我认为Obx刷新机制，也是有着本身的缺点的，从其实现原理上看，这是无奈防止的
- 因为Obx的主动刷新，必须须要每一个变量都自带监听触发机制；所以，所有的根底类型，实体以及列表，都须要从新封装，这会造成很重大的应用影响：变量的赋值，类型标定，刷新都很失常写法有差别，不相熟该写法的人，看了后，会很好受
- 因为对所有类型从新封装，通过下面的代码回溯，大家也发现，封装类型的代码相当多；封装类型占用资源必定要比dart自带类型的大（这个问题能够防止：封装一个响应式的变量，并不一定须要很多代码，上面我给出了一个封装参考）
手搓一个状态治理框架
GetX内置了俩套状态管理机制，这边也会依照其刷新机制，手搓俩套出来
我会用极其简略的代码，再现俩套经典的机制
依赖注入
在做刷新机制前，首先必须写一个依赖注入的类，咱们须要本人治理逻辑层的那些实例
- 我这边写了一个极其简略，仅实现三种根底性能：注入，获取，删除
///依赖注入，内部可将实例，注入该类中，由该类治理class Easy { ///注入实例 static T put<T>(T dependency, {String? tag}) => _EasyInstance().put(dependency, tag: tag); ///获取注入的实例 static T find<T>({String? tag, String? key}) => _EasyInstance().find<T>(tag: tag, key: key); ///删除实例 static bool delete<T>({String? tag, String? key}) => _EasyInstance().delete<T>(tag: tag, key: key);}///具体逻辑class _EasyInstance { factory _EasyInstance() => _instance ??= _EasyInstance._(); static _EasyInstance? _instance; _EasyInstance._(); static final Map<String, _InstanceInfo> _single = {}; ///注入实例 T put<T>(T dependency, {String? tag}) { final key = _getKey(T, tag); //屡次注入会笼罩 _single[key] = _InstanceInfo<T>(dependency); return find<T>(tag: tag); } ///获取注入的实例 T find<T>({String? tag, String? key}) { final newKey = key ?? _getKey(T, tag); var info = _single[newKey]; if (info?.value != null) { return info!.value; } else { throw '"$T" not found. You need to call "Easy.put($T())""'; } } ///删除实例 bool delete<T>({String? tag, String? key}) { final newKey = key ?? _getKey(T, tag); if (!_single.containsKey(newKey)) { print('Instance "$newKey" already removed.'); return false; } _single.remove(newKey); print('Instance "$newKey" deleted.'); return true; } String _getKey(Type type, String? name) { return name == null ? type.toString() : type.toString() + name; }}class _InstanceInfo<T> { _InstanceInfo(this.value); T value;}- 自定义一个监听类，这个类很重要，上面俩种机制都须要用到
///自定义个监听触发类class EasyXNotifier { List<VoidCallback> _listeners = []; void addListener(VoidCallback listener) { _listeners.add(listener); } void removeListener(VoidCallback listener) { for (final entry in _listeners) { if (entry == listener) { _listeners.remove(entry); return; } } } void dispose() { _listeners.clear(); } void notify() { if (_listeners.isEmpty) return; for (final entry in _listeners) { try { entry.call(); } catch (e) { print(e.toString()); } } }}EasyBuilder
实现
该模式须要自定义一个基类
- 我这中央写的极简，相干生命周期都没加，这个加起来也很容易，定义各个生命周期，在Builder控件外面触发，就能够了
- 为了代码简洁，这个暂且不表
class EasyXController { EasyXNotifier xNotifier = EasyXNotifier(); ///刷新控件 void update() { xNotifier.notify(); }}再来看看最外围的EasyBuilder控件：这就搞定了！
- 实现代码写的极其简略，心愿大家思路能有所清晰
///刷新控件,自带回收机制class EasyBuilder<T extends EasyXController> extends StatefulWidget { final Widget Function(T logic) builder; final String? tag; final bool autoRemove; const EasyBuilder({ Key? key, required this.builder, this.autoRemove = true, this.tag, }) : super(key: key); @override _EasyBuilderState<T> createState() => _EasyBuilderState<T>();}class _EasyBuilderState<T extends EasyXController> extends State<EasyBuilder<T>> { late T controller; @override void initState() { super.initState(); controller = Easy.find<T>(tag: widget.tag); controller.xNotifier.addListener(() { if (mounted) setState(() {}); }); } @override void dispose() { if (widget.autoRemove) { Easy.delete<T>(tag: widget.tag); } controller.xNotifier.dispose(); super.dispose(); } @override Widget build(BuildContext context) { return widget.builder(controller); }}应用
- 应用很简略，先看下逻辑层
class EasyXCounterLogic extends EasyXController { var count = 0; void increase() { ++count; update(); }}- 界面层
class EasyXCounterPage extends StatelessWidget { final EasyXCounterLogic logic = Easy.put(EasyXCounterLogic()); @override Widget build(BuildContext context) { return BaseScaffold( appBar: AppBar(title: const Text('EasyX-自定义EasyBuilder刷新机制')), body: Center( child: EasyBuilder<EasyXCounterLogic>(builder: (logic) { return Text( '点击了 ${logic.count} 次', style: TextStyle(fontSize: 30.0), ); }), ), floatingActionButton: FloatingActionButton( onPressed: () => logic.increase(), child: Icon(Icons.add), ), ); }}- 效果图
Ebx：主动刷新机制
主动刷新机制，因为没加泛型，所以无奈确定本人外部应用了哪个注入实例，Getx中是在路由外面去回收这些实例的，然而，如果你没应用GetX的路由，又用Obx，你会发现，GetXController竟然无奈主动回收！！！
此处针对该场景，我会给出一种解决方案
实现
在主动刷新的机制中，须要将根底类型进行封装
- 次要逻辑在Rx<T>中
- set value 和 get value是要害
///拓展函数extension IntExtension on int { RxInt get ebs => RxInt(this);}extension StringExtension on String { RxString get ebs => RxString(this);}extension DoubleExtension on double { RxDouble get ebs => RxDouble(this);}extension BoolExtension on bool { RxBool get ebs => RxBool(this);}///封装各类型class RxInt extends Rx<int> { RxInt(int initial) : super(initial); RxInt operator +(int other) { value = value + other; return this; } RxInt operator -(int other) { value = value - other; return this; }}class RxDouble extends Rx<double> { RxDouble(double initial) : super(initial); RxDouble operator +(double other) { value = value + other; return this; } RxDouble operator -(double other) { value = value - other; return this; }}class RxString extends Rx<String> { RxString(String initial) : super(initial);}class RxBool extends Rx<bool> { RxBool(bool initial) : super(initial);}///主体逻辑class Rx<T> { EasyXNotifier subject = EasyXNotifier(); Rx(T initial) { _value = initial; } late T _value; bool firstRebuild = true; String get string => value.toString(); @override String toString() => value.toString(); set value(T val) { if (_value == val && !firstRebuild) return; firstRebuild = false; _value = val; subject.notify(); } T get value { if (RxEasy.proxy != null) { RxEasy.proxy!.addListener(subject); } return _value; }}须要写一个十分重要的直达类，这个也会贮存响应式变量的监听对象
- 这个类是有着十分外围的逻辑：他将响应式变量和刷新控件关联起来了！
class RxEasy { EasyXNotifier easyXNotifier = EasyXNotifier(); Map<EasyXNotifier, String> _listenerMap = {}; bool get canUpdate => _listenerMap.isNotEmpty; static RxEasy? proxy; void addListener(EasyXNotifier notifier) { if (!_listenerMap.containsKey(notifier)) { //重要：将Ebx中的监听对象转换到此处 easyXNotifier = proxy!.easyXNotifier; //变量监听中刷新 notifier.addListener(() { //刷新ebx中增加的监听 easyXNotifier.notify(); }); //增加进入map中 _listenerMap[notifier] = ''; } }}- 刷新控件Ebx
typedef WidgetCallback = Widget Function();class Ebx extends StatefulWidget { const Ebx(this.builder, {Key? key}) : super(key: key); final WidgetCallback builder; @override _EbxState createState() => _EbxState();}class _EbxState extends State<Ebx> { RxEasy _rxEasy = RxEasy(); @override void initState() { super.initState(); _rxEasy.easyXNotifier.addListener(() { if (mounted) setState(() {}); }); } Widget get notifyChild { final observer = RxEasy.proxy; RxEasy.proxy = _rxEasy; final result = widget.builder(); if (!_rxEasy.canUpdate) { throw 'Widget lacks Rx type variables'; } RxEasy.proxy = observer; return result; } @override Widget build(BuildContext context) { return notifyChild; } @override void dispose() { _rxEasy.easyXNotifier.dispose(); super.dispose(); }}在下面说了，在主动刷新机制中，主动回收依赖实例是个蛋筒的问题，此处我写了一个回收控件，能够解决此问题
- 应用时，必须套一层了；如果大家有更好的思路，麻烦在评论里告知
class EasyBindWidget extends StatefulWidget { const EasyBindWidget({ Key? key, this.bind, this.tag, this.binds, this.tags, required this.child, }) : assert( binds == null || tags == null || binds.length == tags.length, 'The binds and tags arrays length should be equal\n' 'and the elements in the two arrays correspond one-to-one', ), super(key: key); final Object? bind; final String? tag; final List<Object>? binds; final List<String>? tags; final Widget child; @override _EasyBindWidgetState createState() => _EasyBindWidgetState();}class _EasyBindWidgetState extends State<EasyBindWidget> { @override Widget build(BuildContext context) { return widget.child; } @override void dispose() { _closeController(); _closeControllers(); super.dispose(); } void _closeController() { if (widget.bind == null) { return; } var key = widget.bind.runtimeType.toString() + (widget.tag ?? ''); Easy.delete(key: key); } void _closeControllers() { if (widget.binds == null) { return; } for (var i = 0; i < widget.binds!.length; i++) { var type = widget.binds![i].runtimeType.toString(); if (widget.tags == null) { Easy.delete(key: type); } else { var key = type + (widget.tags?[i] ?? ''); Easy.delete(key: key); } } }}应用
- 逻辑层，这次，咱们连基类都不须要写
class EasyXEbxCounterLogic { RxInt count = 0.ebs; ///自增 void increase() => ++count;}- 界面层：页面顶节点套了一个EasyBindWidget，能够保障依赖注入实例能够主动回收
class EasyXEbxCounterPage extends StatelessWidget { final EasyXEbxCounterLogic logic = Easy.put(EasyXEbxCounterLogic()); @override Widget build(BuildContext context) { return EasyBindWidget( bind: logic, child: BaseScaffold( appBar: AppBar(title: const Text('EasyX-自定义Ebx刷新机制')), body: Center( child: Ebx(() { return Text( '点击了 ${logic.count.value} 次', style: TextStyle(fontSize: 30.0), ); }), ), floatingActionButton: FloatingActionButton( onPressed: () => logic.increase(), child: Icon(Icons.add), ), ), ); }}- 效果图
总结
这俩种刷新模式，含金量高的，应该还是主动刷新的机制，思路很乏味，响应式变量和刷新控件通过动态变量的模式建设起分割，cool！又是一种骚操作！
这俩套状态管理机制，我都给出了对依赖注入对象，主动回收的解决方案，心愿对大家的思路有所启迪。
最初
终于把最初一篇GetX的原理分析写完了（只针对GetX状态治理这部分内容），了了一桩心事。。。
- 有些流程比拟绕，顺便画了一些图，图文并茂总会让人情绪愉悦嘛......
如果大家认真看完了整片文章，可能会发现：状态治理+依赖注入，能够使得应用场景大大的被拓展
- GetBuilder的主动回收就是借助依赖注入，无缝获取注入实例，从而实现主动回收的操作
- 而且GetBuilder还无需额定传参数！
整篇文章写下来，我感觉真的尽力了
- 从InheritedWidget到路由
- 而后到依赖注入
- 再就是俩种状态框架原理分析
- 最初根据俩种刷新机制，手搓俩套状态治理框架
也算是层层递进的将其中的常识，一点点的展现在大家的背后，心愿能够帮到各位！！！
系列文章 + 相干地址
- 文章中Demo的Github地址：flutter_use
- Flutter GetX应用---简洁的魅力！
- 源码篇：Flutter Bloc背地的思维，一篇纠结的文章
- 源码篇：Flutter Provider的另一面（万字图文+插件）