前言

由 程式設計技術交流聖地[-Flutter群-] 發起的 狀態管理研究小組，將就 狀態管理 相關話題進行為期 兩個月 的討論。

目前只有內定的 5 個人參與討論，如果你對 狀態管理 有什麼獨特的見解，或想參與其中，可諮詢 張風捷特烈 ，歡迎和我們共同交流。

關於這篇文章的一些內容，我很久之前就想寫的，但一直沒啥源動力，就一直鴿著

這次被捷特大佬催了幾次，終於把這文章寫完了，文章裡有我對狀態管理的一些思考和看法，希望能引起茫茫人海中零星的共鳴。。。

狀態管理的認知

變遷

解耦是眾多思想或框架的基石

就拿最最最經典的MVC來說，統一將模組分為三層

  • Model層：資料管理
  • Controller層：邏輯處理
  • View層：檢視搭建

這個經典的層級劃分能應付很多場景

  • MVP，MVVM也是MVC的變種，本質上都是為了在合適的場景，更合理的解耦

  • 其實這些模式應用在移動端是很合適的，移動端舊時XML的寫法，是獲取其View節點，然後對其節點操作

  • 在JSP的時代，JQuery大行其道，操作DOM節點，重新整理資料；如出一轍。

時代總是在發展中前進，技術也在不停變遷；就像普羅米修斯盜火而來，給世間帶來諸多變化

對View節點操作的思想，固定化的套用在如今的前端是不準確的

如今前端是由眾多"狀態"去控制介面展示的，需要用更加精煉的語言去闡述它

包容萬千

狀態管理的重點也就在其表面：狀態和管理

  • 寥寥四字，就精悍的概括了思想及其靈魂

狀態是頁面的靈魂，是業務邏輯和通用邏輯的錨定符，只要分離出狀態，將其管理，就可以將頁面解耦

一般來說，從狀態管理的概念上，可以解耦出多個層級

極簡模式

這是一種十分簡潔的層級劃分，眾多流行的Flutter狀態管理框架，也是如此劃分的，例如：provider，getx

  • view：介面層
  • Logic：邏輯層 + 狀態層

標準模式

這已經是一種類似MVC的層級劃分了，這種層級也十分常見，例如：cubit（provider和getx也能輕鬆劃分出這種結構）

  • view：介面
  • Logic：邏輯層
  • State：狀態層

嚴格模式

對於標椎模式而言，已經劃分的很到位了，但還有某一類層次沒有劃分出來：使用者和程式互動的行為

說明下：想要劃分出這一層級，代價必然是很大的，會讓框架的使用複雜度進一步上升

  • 後面分析為什麼劃分這一層次，會導致成本很大

常見的狀態管理框架：Bloc，Redux，fish_redux

  • view：介面層
  • Logic：邏輯層
  • State：狀態層
  • Action：行為層

強迫症模式

常見的狀態管理框架：Redux，fish_redux

從圖上來看，這個結構已經有點複雜了，為了解耦資料重新整理這一層次，付出了巨大的成本

  • view：介面層
  • Logic：邏輯層
  • State：狀態層
  • Action：行為層
  • Reducer：這個層級，是專門用於處理資料變化的

思考

對於變化的事物和思想，我們應該去恐懼，去抗拒嗎？

我時常認為：優秀的思想見證變遷，它並不會在時光中衰敗，而是變的越來越璀璨

例如：設計模式

解耦的成本

分離邏輯+狀態層

一個成熟的狀態管理框架，必定將邏輯從介面層裡面劃分處理，這是應該一個狀態管理框架的最樸實的初衷

一些看法

實際上，此時付出的成本是針對框架開發者的，需要開發者去選擇一個合適技術方案，去進行合理的解耦

實現一個狀態管理框架，我此時，或許可以說：

  • 這並不是一件多麼難的事
  • 幾個檔案就能實現一個合理且功能強大的狀態管理框架

此時，螢幕前的你可能會想了：這叼毛可真會吹牛皮，把逗笑了

關於上面的話，我真不是吹牛皮，我看了幾個狀態管理的原始碼後，發現狀態管理的思想其實非常樸實，當然開源框架的程式碼並沒有那麼簡單，基本都做了大量的抽象，方便功能擴充套件，這基本都會對閱讀者產生極大的困擾，尤其是provider，看的頭皮發麻、、、

我將幾個典型的狀態管理的思想提取出來後，用極簡的程式碼復現其執行機制，發現用的都是觀察模式的思想，理解了以後，就並不覺得狀態管理框架多麼的神祕了

我絕沒有任何輕視的思想：他們都是那個莽荒時代裡，偉大的拓荒者！

如何將邏輯+狀態層從介面裡解耦出來？

我總結了幾種很經典的狀態管理的實現機制，因為每一種實現原始碼都有點長，就放在文章後半截了，有興趣的可以看看；每一種實現方式的程式碼都是完整的，可獨立執行的

  • 將邏輯層介面解耦出來

    • 成本在框架端，需要較複雜的實現
    • 一般來說，只解耦倆層，使用上一般較為簡單

  • 解耦狀態層

    • 如果分離出邏輯層，解耦狀態層，一般來說，並不會很難；手動簡單劃分即可，我寫的幾個idea外掛生成模板程式碼，都對該層做了劃分
    • 也可以直接在框架內部直接強行約定，Bloc中的Bloc模式和Cubit模式，redux系列。。。
    • 劃分成本不高，使用成本不高，該層解耦的影響深遠

Action層的成本

Action層是什麼？正如其名字一樣，行為層，使用者和介面上的互動事件都可以劃分到這一層

  • 例如：點選按鈕的事件，輸入事件，上拉下拉事件等等
  • 使用者在介面上生成了這些事件，我們也需要做相應的邏輯去響應

為什麼要劃分Action層？

  • 大家如果寫flutter套娃程式碼寫的很盡興的時候，可能會發現，很多點選事件的互動入口都在widget山裡
  • 互動事件散落在大量的介面程式碼，如果需要跳轉事件調整傳參，找起來會很頭痛
  • 還有一個很重要的方面：實際上互動事件的入口，就是業務入口，需求調整時，找相應業務程式碼也很麻煩！

基於業務會逐漸鬼畜的考量，一些框架劃分出了Action層，統一管理了所有的互動事件

成本

框架側成本

想要統一管理所有的互動事件，實現上難度不是很大

  • 一般情況下，我們可以直接在view層，直接呼叫邏輯層的方法，執行相關有業務邏輯
  • 現在需要將呼叫邏輯層方法的行為，進行統一的管理
  • 所以，需要在呼叫的中間，增加一箇中間層，中轉所有的事件
  • 這個中轉層就是action層，可以管理所有的互動事件

來看下實現思路

框架側實現成本並不高，主要就是對事件的接受和分發

實際上，我們一般也不在乎框架側成本，框架內部實現的再怎麼複雜都無關緊要，用法應該簡潔明瞭

如果內部設計非常精妙，使用起來卻晦澀繁瑣，無疑是給使用者增加心智負擔

使用側成本

劃分出Action層，會給使用者增加一定的使用成本，這是無法避免的

  • 事件定義成本：因為劃分出了事件層，每一種互動，必須在Action層去定義
  • 傳送事件成本：在view層需要將定義的事件用不同的api傳送出去，這個對比以前呼叫區別不大，成本很低
  • 邏輯層處理成本：邏輯層必定會多一個模組或方法，接受分發的方法去分類處理，此處會有一點繁瑣

圖中紅框的模組，是額外的使用成本

外在表現

Bloc不使用Action層

  • View層，程式碼簡寫，只是看看其外在表現
class BlBlocCounterPage extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    return BlocProvider(

      create: (BuildContext context) => BlBlocCounterBloc()..init(),

      child: Builder(builder: (context) => _buildPage(context)),

    );

  }

  Widget _buildPage(BuildContext context) {

    final bloc = BlocProvider.of<BlBlocCounterBloc>(context);

    return Scaffold(

      ...

      floatingActionButton: FloatingActionButton(

        //呼叫業務方法

        onPressed: () => bloc.increment(),

        child: Icon(Icons.add),

      ),

    );

  }

}
  • Bloc層
class BlBlocCounterBloc extends Bloc<BlBlocCounterEvent, BlBlocCounterState> {

  BlBlocCounterBloc() : super(BlBlocCounterState().init());

  void init() async {

    ///處理邏輯,呼叫emit方法重新整理

    emit(state.clone());

  }

}

state層：該演示中，此層不重要，不寫了

Bloc使用Action

  • View層，程式碼簡寫，只是看看其外在表現
class BlBlocCounterPage extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    return BlocProvider(

      create: (BuildContext context) => BlBlocCounterBloc()..add(InitEvent()),

      child: Builder(builder: (context) => _buildPage(context)),

    );

  }

  Widget _buildPage(BuildContext context) {

    final bloc = BlocProvider.of<BlBlocCounterBloc>(context);

    return Scaffold(

      ...

      floatingActionButton: FloatingActionButton(

        onPressed: () => bloc.add(AEvent()),

        child: Icon(Icons.add),

      ),

    );

  }

}
  • Bloc層
class BlBlocCounterBloc extends Bloc<BlBlocCounterEvent, BlBlocCounterState> {

  BlBlocCounterBloc() : super(BlBlocCounterState().init());

  @override

  Stream<BlBlocCounterState> mapEventToState(BlBlocCounterEvent event) async* {

    if (event is InitEvent) {

      yield await init();

    } else if (event is AEvent) {

      yield a();

    } else if (event is BEvent) {

      yield b();

    } else if (event is CEvent) {

      yield c();

    } else if (event is DEvent) {

      yield d();

    } else if (event is EEvent) {

      yield e();

    } else if (event is FEvent) {

      yield f();

    } else if (event is GEvent) {

      yield g();

    } else if (event is HEvent) {

      yield h();

    } else if (event is IEvent) {

      yield i();

    } else if (event is JEvent) {

      yield j();

    } else if (event is KEvent) {

      yield k();

    }

  }

  ///對應業務方法

  ...

}
  • Event層：如果需要傳引數，事件類裡面就需要定義相關變數，實現其建構函式，將view層資料傳輸到bloc層
abstract class BlBlocCounterEvent {}

class InitEvent extends BlBlocCounterEvent {}

class AEvent extends BlBlocCounterEvent {}

class BEvent extends BlBlocCounterEvent {}

class CEvent extends BlBlocCounterEvent {}

.......

class KEvent extends BlBlocCounterEvent {}

state層：該演示中，此層不重要，不寫了

fish_redux的使用表現

  • view
Widget buildView(MainState state, Dispatch dispatch, ViewService viewService) {

  return Scaffold(

    //頂部AppBar

    appBar: mainAppBar(

      onTap: () => dispatch(MainActionCreator.toSearch()),

    ),

    //側邊抽屜模組

    drawer: MainDrawer(

      data: state,

      onTap: (String tag) => dispatch(MainActionCreator.clickDrawer(tag)),

    ),

    //頁面主體

    body: MainBody(

      data: state,

      onChanged: (int index) => dispatch(MainActionCreator.selectTab(index)),

    ),

    //底部導航

    bottomNavigationBar: MainBottomNavigation(

      data: state,

      onTap: (int index) => dispatch(MainActionCreator.selectTab(index)),

    ),

  );

}
  • action層
enum MainAction {

  //切換tab

  selectTab,

  //側邊欄item點選

  clickDrawer,

  //搜尋

  toSearch,

  //統一重新整理事件

  onRefresh,

}

class MainActionCreator {

  static Action toSearch() {

    return Action(MainAction.toSearch);

  }

  static Action selectTab(int index) {

    return Action(MainAction.selectTab, payload: index);

  }

  static Action onRefresh() {

    return Action(MainAction.onRefresh);

  }

  static Action clickDrawer(String tag) {

    return Action(MainAction.clickDrawer, payload: tag);

  }

}
  • Event
Effect<MainState> buildEffect() {

  return combineEffects(<Object, Effect<MainState>>{

    //初始化

    Lifecycle.initState: _init,

    //切換tab

    MainAction.selectTab: _selectTab,

    //選擇相應抽屜內部的item

    MainAction.clickDrawer: _clickDrawer,

    //跳轉搜尋頁面

    MainAction.toSearch: _toSearch,

  });

}

///眾多業務方法

void _init(Action action, Context<MainState> ctx) async {

  ...

}
  • reducer和state層不重要，這地方就不寫了

fish_redux對Action層的劃分以及事件的分發，明顯要比Bloc老道很多

fish_redux使用列舉和一個類就完成了眾多事件的定義；bloc需要繼承類，一個類一個事件

老實說，倆種框架我都用了，bloc這樣寫確實比較麻煩，尤其涉及傳參的時候，就需要在類裡面定義很多變數

總結

上面幾種形式對比，可以發現區別還是蠻大的

增加了Action層，使得使用成本不可避免的飆升

很多人心裡，此時或許都會吐槽：好麻煩，，，

對Action層的思考和演化

通過解耦Action層的設計本質分析，我們會發現一個無法避免的現實！

  • 增加Action層，使用端的成本無法去避免
  • 因為使用端增加的成本，就是框架側的設計核心

當業務逐漸的複雜起來，Action層的劃分是勢在必行的，我們必須歸納事件入口；當業務頻繁調整時，需要快速的去定位對應的業務！

有辦法簡化嗎？

Action層的劃分，會一定程度上增加使用者的負擔，有什麼辦法可以簡化？同時又能達到管理事件入口的效果？

我曾對View層瘋狂的套娃，做了很多思考，關於一些拆分形式做了一些嘗試

拆分後的效果，將View層和Action很好的結合起來了，具體操作：Flutter 改善套娃地獄問題（仿喜馬拉雅PC頁面舉例）

  • 看下拆分後的程式碼效果

    • 因為將View分模組劃分清晰了，對外暴露方法就是業務事件，可以很輕鬆的定位到對應的業務了
    • 如此形式劃分後，對應的頁面結構也變得異常清晰，修改頁面對應的模組也很輕鬆了

  • 對View層進行相關改造後

    • 可以非常方便的定位業務和介面模組
    • 同時也避免的Action層一系列稍顯繁瑣的操作

總結

框架的約定，可以規範眾多行為習慣不同的開發者

後來我提出的對View層的拆分，只能依靠開發者本身的意識

這裡，我給出一種不一樣的方式，其中的取捨，只能由各位自己決定嘍

我目前一直都是使用View層的拆分，自我感覺對後期複雜模組的維護，非常友好~~

Reducer層的吐槽

可能是我太菜了，一直感受不到這一層分化的妙處

我用fish_redux也寫了很多頁面（用了一年了），之前也會將相關資料通過Action層傳遞到Reducer，然後進行相應的重新整理，這導致了一個問題！

  • 我重新整理個數據，就需要建立一個Action
  • 然後在Reducer解析傳過來來的，往clone方法裡賦值，導致我想修改資料的時候，必須先要去Effect層去看邏輯，然後去Reducer裡面修改賦值
  • 來回跳，麻煩到爆！

被繞了多次，煩躁了多次後，我直接把Reducer層寫成了一個重新整理方法！

Reducer<WebViewState> buildReducer() {

  return asReducer(

    <Object, Reducer<WebViewState>>{

      WebViewAction.onRefresh: _onRefresh,

    },

  );

}

WebViewState _onRefresh(WebViewState state, Action action) {

  return state.clone();

}

就算在複雜的模組，我也沒感受到他給我帶來的好處，我就只能把他無限弱化成一個重新整理方法了

狀態管理的幾種實現

這是我看了一些狀態管理的原始碼

  • 總結出的幾種狀態管理的重新整理機制
  • 任選一種，都可以搓出你自己的狀態管理框架

之前的幾篇原始碼剖析文章寫過，整理了下，做個總結

爛大街的實現

實現難度最小

這是一種非常常見的實現

  • 這是一種簡單，易用，強大的實現
  • 同時由於難度不高，也是一種爛大街的實現

實現

需要實現一個管理邏輯層例項的的中介軟體：依賴注入的實現

也可以使用InheritedWidget儲存和傳遞邏輯層例項（Bloc就是這樣做的）；但是自己管理，可以大大拓寬使用場景，此處就自己實現一個管理例項的中介軟體

  • 這邊只實現三個基礎api
///依賴注入，外部可將例項，注入該類中，由該類管理

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.putIfAbsent(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;

}

定義一個監聽和基類

  • 也可以使用ChangeNotifier；此處我們自己簡單定義個
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) {

      entry.call();

    }

  }

}
  • 我這地方寫的極簡，相關生命週期都沒加，為了程式碼簡潔，這個暫且不表
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) => widget.builder(controller);

}

使用

  • 使用很簡單，先看下邏輯層
class EasyXCounterLogic extends EasyXController {

  var count = 0;

  void increase() {

    ++count;

    update();

  }

}
  • 介面層
class EasyXCounterPage extends StatelessWidget {

  final 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),

      ),

    );

  }

}
  • 效果圖

InheritedWidget的實現

實現具有一定的難度

更加詳細的解析可檢視：Flutter Provider的另一面

先來看下InheritedWidget它自帶一些功能

  • 儲存資料，且資料可以隨著父子節點傳遞
  • 自帶區域性重新整理機制

資料傳遞

區域性重新整理

InheritedWidget對子節點的Element，有個強大的操作功能

  • 可以將子widget的element例項，儲存在自身的InheritedElement中的_dependents變數中
  • 呼叫其notifyClients方法，會遍歷_dependents中的子Element，然後呼叫子Element的markNeedsBuild方法，就完成了定點重新整理子節點的操作

有了上面這倆個關鍵知識，就可以輕鬆的實現一個強大的狀態管理框架了，來看下實現

實現

  • ChangeNotifierEasyP：類比Provider的ChangeNotifierProvider
class ChangeNotifierEasyP<T extends ChangeNotifier> extends StatelessWidget {

  ChangeNotifierEasyP({

    Key? key,

    required this.create,

    this.builder,

    this.child,

  }) : super(key: key);

  final T Function(BuildContext context) create;

  final Widget Function(BuildContext context)? builder;

  final Widget? child;

  @override

  Widget build(BuildContext context) {

    assert(

      builder != null || child != null,

      '$runtimeType  must specify a child',

    );

    return EasyPInherited(

      create: create,

      child: builder != null

          ? Builder(builder: (context) => builder!(context))

          : child!,

    );

  }

}

class EasyPInherited<T extends ChangeNotifier> extends InheritedWidget {

  EasyPInherited({

    Key? key,

    required Widget child,

    required this.create,

  }) : super(key: key, child: child);

  final T Function(BuildContext context) create;

  @override

  bool updateShouldNotify(InheritedWidget oldWidget) => false;

  @override

  InheritedElement createElement() => EasyPInheritedElement(this);

}

class EasyPInheritedElement<T extends ChangeNotifier> extends InheritedElement {

  EasyPInheritedElement(EasyPInherited<T> widget) : super(widget);

  bool _firstBuild = true;

  bool _shouldNotify = false;

  late T _value;

  late void Function() _callBack;

  T get value => _value;

  @override

  void performRebuild() {

    if (_firstBuild) {

      _firstBuild = false;

      _value = (widget as EasyPInherited<T>).create(this);

      _value.addListener(_callBack = () {

        // 處理重新整理邏輯，此處無法直接呼叫notifyClients

        // 會導致owner!._debugCurrentBuildTarget為null，觸發斷言條件，無法向後執行

        _shouldNotify = true;

        markNeedsBuild();

      });

    }

    super.performRebuild();

  }

  @override

  Widget build() {

    if (_shouldNotify) {

      _shouldNotify = false;

      notifyClients(widget);

    }

    return super.build();

  }

  @override

  void notifyDependent(covariant InheritedWidget oldWidget, Element dependent) {

    //此處就直接重新整理新增的監聽子Element了,不各種super了

    dependent.markNeedsBuild();

    // super.notifyDependent(oldWidget, dependent);

  }

  @override

  void unmount() {

    _value.removeListener(_callBack);

    _value.dispose();

    super.unmount();

  }

}
  • EasyP：類比Provider的Provider類
class EasyP {

  /// 獲取EasyP例項

  /// 獲取例項的時候,listener引數老是寫錯,這邊直接用倆個方法區分了

  static T of<T extends ChangeNotifier>(BuildContext context) {

    return _getInheritedElement<T>(context).value;

  }

  /// 註冊監聽控制元件

  static T register<T extends ChangeNotifier>(BuildContext context) {

    var element = _getInheritedElement<T>(context);

    context.dependOnInheritedElement(element);

    return element.value;

  }

  /// 獲取距離當前Element最近繼承InheritedElement<T>的元件

  static EasyPInheritedElement<T>

      _getInheritedElement<T extends ChangeNotifier>(BuildContext context) {

    var inheritedElement = context

            .getElementForInheritedWidgetOfExactType<EasyPInherited<T>>()

        as EasyPInheritedElement<T>?;

    if (inheritedElement == null) {

      throw EasyPNotFoundException(T);

    }

    return inheritedElement;

  }

}

class EasyPNotFoundException implements Exception {

  EasyPNotFoundException(this.valueType);

  final Type valueType;

  @override

  String toString() => 'Error: Could not find the EasyP<$valueType>';

}
  • build：最後整一個Build類就行了
class EasyPBuilder<T extends ChangeNotifier> extends StatelessWidget {

  const EasyPBuilder(

    this.builder, {

    Key? key,

  }) : super(key: key);

  final Widget Function() builder;

  @override

  Widget build(BuildContext context) {

    EasyP.register<T>(context);

    return builder();

  }

}

大功告成，上面這三個類，就基於InheritedWidget自帶的功能，實現了一套狀態管理框架

  • 實現了局部重新整理功能
  • 實現了邏輯層例項，可以隨著Widget父子節點傳遞功能

使用

用法基本和Provider一摸一樣...

  • view
class CounterEasyPPage extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    return ChangeNotifierEasyP(

      create: (BuildContext context) => CounterEasyP(),

      builder: (context) => _buildPage(context),

    );

  }

  Widget _buildPage(BuildContext context) {

    final easyP = EasyP.of<CounterEasyP>(context);

    return Scaffold(

      appBar: AppBar(title: Text('自定義狀態管理框架-EasyP範例')),

      body: Center(

        child: EasyPBuilder<CounterEasyP>(() {

          return Text(

            '點選了 ${easyP.count} 次',

            style: TextStyle(fontSize: 30.0),

          );

        }),

      ),

      floatingActionButton: FloatingActionButton(

        onPressed: () => easyP.increment(),

        child: Icon(Icons.add),

      ),

    );

  }

}
  • easyP
class CounterEasyP extends ChangeNotifier {

  int count = 0;

  void increment() {

    count++;

    notifyListeners();

  }

}
  • 效果圖：

自動化重新整理的實現

實現需要一些的靈感

自動化重新整理的實現

  • 將單個狀態變數和重新整理元件，建立起了連線
  • 一但變數數值改變，重新整理元件自動重新整理
  • 某狀態變化，只會自動觸發其重新整理元件，其它重新整理元件並不觸發

實現

同樣的，需要管理其邏輯類的中介軟體；為了範例完整，再寫下這個依賴管理類

///依賴注入，外部可將例項，注入該類中，由該類管理

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.putIfAbsent(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) {

      entry.call();

    }

  }

}

在自動重新整理的機制中，需要將基礎型別進行封裝

  • 主要邏輯在Rx中
  • 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)) {

      //變數監聽中重新整理

      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 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),

        ),

      ),

    );

  }

}
  • 效果圖

最後

本文總體上，對狀態管理的各個層次劃分做了一些思考和一點個人的見解，文章後半截也給出了一些狀態管理的實現方案

文章裡的內容對想設計狀態管理的靚仔，應該有一些幫助；如果你有相關不同的意見，歡迎在評論區討論

相關地址