本篇將帶你深入理解 Flutter 中 State 的工作機制，并通過對狀態(tài)管理框架 Provider 解析加深理解，看完這一篇你將更輕松的理解你的 “State 大后宮” 。
文章匯總地址：
??第十二篇中更多講解狀態(tài)的是管理框架，本篇更多講解 Flutter 本身的狀態(tài)設計。
一、State
1、State 是什么？
我們知道 Flutter 宇宙中萬物皆 Widget ，而 Widget 是 @immutable 即不可變的，所以每個 Widget 狀態(tài)都代表了一幀。
在這個基礎上， StatefulWidget 的 State 幫我們實現了在 Widget 的跨幀繪制 ，也就是在每次 Widget 重繪的時候，通過 State 重新賦予 Widget 需要的繪制信息。
2、State 怎么實現跨幀共享？
這就涉及 Flutter 中 Widget 的實現原理，在之前的篇章我們介紹過，這里我們說兩個涉及的概念：
Flutter 中的
Widget在一般情況下，是需要通過Element轉化為RenderObject去實現繪制的。Element是BuildContext的實現類，同時Element持有RenderObject和Widget，我們代碼中的Widget build(BuildContext context) {}方法，就是被Element調用的。
了解這個兩個概念后，我們先看下圖，在 Flutter 中構建一個 Widget ，首先會創(chuàng)建出這個 Widget 的 Element ，而事實上 State 實現跨幀共享，就是將 State 保存在Element 中，這樣 Element 每次調用 Widget build() 時，是通過 state.build(this); 得到的新 Widget ，所以寫在 State 的數據就得以復用了。
那 State 是在哪里被創(chuàng)建的？
如下圖所示，StatefulWidget 的 createState 是在 StatefulElement 的構建方法里創(chuàng)建的， 這就保證了只要 Element 不被重新創(chuàng)建，State 就一直被復用。
同時我們看 update 方法，當新的 StatefulWidget 被創(chuàng)建用于更新 UI 時，新的 widget 就會被重新賦予到 _state 中，而這的設定也導致一個常被新人忽略的問題。
我們先看問題代碼，如下圖所示：
- 1、在
_DemoAppState中，我們創(chuàng)建了DemoPage, 并且把data變量賦給了它。 - 2、
DemoPage在創(chuàng)建createState時，又將data通過直接傳入_DemoPageState。 - 3、在
_DemoPageState中直接將傳入的data通過Text顯示出來。
運行后我們一看也沒什么問題吧？ 但是當我們點擊 4 中的 setState 時，卻發(fā)現 3 中 Text 沒有發(fā)現改變， 這是為什么呢？
問題就在于前面 StatefulElement 的構建方法和 update 方法：
State 只在 StatefulElement 的構建方法中創(chuàng)建，當我們調用 setState 觸發(fā) update 時，只是執(zhí)行了 _state.widget = newWidget，而我們通過 _DemoPageState(this.data) 傳入的 data ，在傳入后執(zhí)行setState 時并沒有改變。
如果我們采用上圖代碼中 3 注釋的 widget.data 方法，因為 _state.widget = newWidget 時，State 中的 Widget 已經被更新了，Text 自然就被更新了。
3、setState 干了什么？
我們常說的 setState ，其實是調用了 markNeedsBuild ，markNeedsBuild 內部會標記 element 為 diry，然后在下一幀 WidgetsBinding.drawFrame 才會被繪制，這可以也看出 setState 并不是立即生效的。
4、狀態(tài)共享
前面我們聊了 Flutter 中 State 的作用和工作原理，接下來我們看一個老生常談的對象： InheritedWidget 。
狀態(tài)共享是常見的需求，比如用戶信息和登陸狀態(tài)等等，而 Flutter 中 InheritedWidget 就是為此而設計的，在第十二篇我們大致講過它：
在
Element的內部有一個Map<Type, InheritedElement> _inheritedWidgets;參數，_inheritedWidgets一般情況下是空的，只有當父控件是InheritedWidget或者本身是InheritedWidgets時，它才會有被初始化，而當父控件是InheritedWidget時，這個Map會被一級一級往下傳遞與合并。所以當我們通過
context調用inheritFromWidgetOfExactType時，就可以通過這個Map往上查找，從而找到這個上級的InheritedWidget。
噢，是的，InheritedWidget 共享的是 Widget ，只是這個 Widget 是一個 ProxyWidget ，它自己本身并不繪制什么，但共享這個 Widget 內保存有的值，卻達到了共享狀態(tài)的目的。
如下代碼所示，Flutter 內 Theme 的共享，共享的其實是 _InheritedTheme 這個 Widget ，而我們通過 Theme.of(context) 拿到的，其實就是保存在這個 Widget 內的 ThemeData 。
static ThemeData of(BuildContext context, { bool shadowThemeOnly = false }) {
final _InheritedTheme inheritedTheme = context.inheritFromWidgetOfExactType(_InheritedTheme);
if (shadowThemeOnly) {
/// inheritedTheme 這個 Widget 內的 theme
/// theme 內有我們需要的 ThemeData
return inheritedTheme.theme.data;
}
···
}
這里有個需要注意的點，就是 inheritFromWidgetOfExactType 方法剛了什么？
我們直接找到 Element 中的 inheritFromWidgetOfExactType 方法實現，如下關鍵代碼所示：
- 首先從
_inheritedWidgets中查找是否有該類型的InheritedElement。 - 查找到后添加到
_dependencies中，并且通過updateDependencies將當前Element添加到InheritedElement的_dependents這個Map 里。 - 返回
InheritedElement中的Widget。
@override
InheritedWidget inheritFromWidgetOfExactType(Type targetType, { Object aspect }) {
/// 在共享 map _inheritedWidgets 中查找
final InheritedElement ancestor = _inheritedWidgets == null ? null : _inheritedWidgets[targetType];
if (ancestor != null) {
/// 返回找到的 InheritedWidget ，同時添加當前 element 處理
return inheritFromElement(ancestor, aspect: aspect);
}
_hadUnsatisfiedDependencies = true;
return null;
}
@override
InheritedWidget inheritFromElement(InheritedElement ancestor, { Object aspect }) {
_dependencies ??= HashSet<InheritedElement>();
_dependencies.add(ancestor);
/// 就是將當前 element（this） 添加到 _dependents 里
/// 也就是 InheritedElement 的 _dependents
/// _dependents[dependent] = value;
ancestor.updateDependencies(this, aspect);
return ancestor.widget;
}
@override
void notifyClients(InheritedWidget oldWidget) {
for (Element dependent in _dependents.keys) {
notifyDependent(oldWidget, dependent);
}
}
這里面的關鍵就是 ancestor.updateDependencies(this, aspect); 這個方法：
我們都知道，獲取 InheritedWidget 一般需要 BuildContext ，如Theme.of(context) ，而 BuildContext 的實現就是 Element ，所以當我們調用 context.inheritFromWidgetOfExactType 時，就會將這個 context 所代表的 Element 添加到 InheritedElement 的 _dependents 中。
這代表著什么？
比如當我們在 StatefulWidget 中調用 Theme.of(context).primaryColor 時，傳入的 context 就代表著這個 Widget 的 Element， 在 InheritedElement 里被“登記”到 _dependents 了。
而當 InheritedWidget 被更新時，如下代碼所示，_dependents 中的 Element 會被逐個執(zhí)行 notifyDependent ，最后觸發(fā) markNeedsBuild ，這也是為什么當 InheritedWidget 被更新時，通過如 Theme.of(context).primaryColor 引用的地方，也會觸發(fā)更新的原因。
下面開始實際分析 Provider 。
二、Provider
為什么會有 Provider ？
因為 Flutter 與 React 技術棧的相似性，所以在 Flutter 中涌現了諸如flutter_redux 、flutter_dva 、 flutter_mobx 、 fish_flutter 等前端式的狀態(tài)管理，它們大多比較復雜，而且需要對框架概念有一定理解。
而作為 Flutter 官方推薦的狀態(tài)管理 scoped_model ，又因為其設計較為簡單，有些時候不適用于復雜的場景。
所以在經歷了一端坎坷之后，今年 Google I/O 大會之后， Provider 成了 Flutter 官方新推薦的狀態(tài)管理方式之一。
它的特點就是： 不復雜，好理解，代碼量不大的情況下，可以方便組合和控制刷新顆粒度 ， 而原 Google 官方倉庫的狀態(tài)管理 flutter-provide 已宣告GG ， provider 成了它的替代品。
??注意，`provider` 比 `flutter-provide` 多了個 `r`。
題外話：以前面試時，偶爾會被面試官問到“你的開源項目代碼量也不多啊”這樣的問題，每次我都會笑而不語，雖然代碼量能代表一些成果，但是我是十分反對用代碼量來衡量貢獻價值，這和你用加班時長來衡量員工價值有什么區(qū)別？
0、演示代碼
如下代碼所示， 實現的是一個點擊計數器，其中：
-
_ProviderPageState中使用MultiProvider提供了多個providers的支持。 - 在
CountWidget中通過Consumer獲取的counter，同時更新_ProviderPageState中的AppBar和CountWidget中的Text顯示。
class _ProviderPageState extends State<ProviderPage> {
@override
Widget build(BuildContext context) {
return MultiProvider(
providers: [
ChangeNotifierProvider(builder: (_) => ProviderModel()),
],
child: Scaffold(
appBar: AppBar(
title: LayoutBuilder(
builder: (BuildContext context, BoxConstraints constraints) {
var counter = Provider.of<ProviderModel>(context);
return new Text("Provider ${counter.count.toString()}");
},
)
),
body: CountWidget(),
),
);
}
}
class CountWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Consumer<ProviderModel>(builder: (context, counter, _) {
return new Column(
children: <Widget>[
new Expanded(child: new Center(child: new Text(counter.count.toString()))),
new Center(
child: new FlatButton(
onPressed: () {
counter.add();
},
color: Colors.blue,
child: new Text("+")),
)
],
);
});
}
}
class ProviderModel extends ChangeNotifier {
int _count = 0;
int get count => _count;
void add() {
_count++;
notifyListeners();
}
}
所以上述代碼中，我們通過 ChangeNotifierProvider 組合了 ChangeNotifier (ProviderModel) 實現共享；利用了 Provider.of 和 Consumer 獲取共享的 counter 狀態(tài)；通過調用 ChangeNotifier 的 notifyListeners(); 觸發(fā)更新。
這里幾個知識點是：
1、 Provider 的內部
DelegateWidget是一個StatefulWidget，所以可以更新且具有生命周期。2、狀態(tài)共享是使用了
InheritedProvider這個InheritedWidget實現的。3、巧妙利用
MultiProvider和Consumer封裝，實現了組合與刷新顆粒度控制。
接著我們逐個分析
1、Delegate
既然是狀態(tài)管理，那么肯定有 StatefulWidget 和 setState 調用。
在 Provider 中，一系列關于 StatefulWidget 的生命周期管理和更新，都是通過各種代理完成的，如下圖所示，上面代碼中我們用到的 ChangeNotifierProvider 大致經歷了這樣的流程：
- 設置到
ChangeNotifierProvider的ChangeNotifer會被執(zhí)行addListener添加監(jiān)聽listener。 -
listener內會調用StateDelegate的StateSetter方法，從而調用到StatefulWidget的setState。 - 當我們執(zhí)行
ChangeNotifer的notifyListeners時，就會最終觸發(fā)setState更新。
而我們使用過的 MultiProvider 則是允許我們組合多種 Provider ，如下代碼所示，傳入的 providers 會倒序排列，最后組合成一個嵌套的 Widget tree ，方便我們添加多種 Provider ：
@override
Widget build(BuildContext context) {
var tree = child;
for (final provider in providers.reversed) {
tree = provider.cloneWithChild(tree);
}
return tree;
}
/// Clones the current provider with a new [child].
/// Note for implementers: all other values, including [Key] must be
/// preserved.
@override
MultiProvider cloneWithChild(Widget child) {
return MultiProvider(
key: key,
providers: providers,
child: child,
);
}
通過 Delegate 中回調出來的各種生命周期，如 Disposer，也有利于我們外部二次處理，減少外部 StatefulWidget 的嵌套使用。
2、InheritedProvider
狀態(tài)共享肯定需要 InheritedWidget ，InheritedProvider 就是InheritedWidget 的子類，所有的 Provider 實現都在 build 方法中使用 InheritedProvider 進行嵌套，實現 value 的共享。
3、Consumer
Consumer 是 Provider 中比較有意思的東西，它本身是一個 StatelessWidget , 只是在 build 中通過 Provider.of<T>(context) 幫你獲取到 InheritedWidget 共享的 value 。
final Widget Function(BuildContext context, T value, Widget child) builder;
@override
Widget build(BuildContext context) {
return builder(
context,
Provider.of<T>(context),
child,
);
}
那我們直接使用 Provider.of<T>(context) ，不使用 Consumer 可以嗎？
當然可以，但是你還記得前面，我們在介紹 InheritedWidget 時所說的：
傳入的
context代表著這個Widget的Element在InheritedElement里被“登記”到_dependents了。
Consumer 做為一個單獨 StatelessWidget ，它的好處就是 Provider.of<T>(context) 傳入的 context 就是 Consumer 它自己。 這樣的話，我們在需要使用 Provider.value 的地方用 Consumer 做嵌套， InheritedWidget 更新的時候，就不會更新到整個頁面 , 而是僅更新到 Consumer 這個 StatelessWidget 。
所以 Consumer 貼心的封裝了 context 在 InheritedWidget 中的“登記邏輯”，從而控制了狀態(tài)改變時，需要更新的精細度。
同時庫內還提供了 Consumer2 ～ Consumer6 的組合，感受下 ：
@override
Widget build(BuildContext context) {
return builder(
context,
Provider.of<A>(context),
Provider.of<B>(context),
Provider.of<C>(context),
Provider.of<D>(context),
Provider.of<E>(context),
Provider.of<F>(context),
child,
);
這樣的設定，相信用過 BLoC 模式的同學會感覺很貼心，以前正常用做 BLoC 時，每個 StreamBuilder 的 snapShot 只支持一種類型，多個時要不就是多個狀態(tài)合并到一個實體，要不就需要多個StreamBuilder嵌套。
當然，如果你想直接利用 LayoutBuilder 搭配 Provider.of<T>(context) 也是可以的：
LayoutBuilder(
builder: (BuildContext context, BoxConstraints constraints) {
var counter = Provider.of<ProviderModel>(context);
return new Text("Provider ${counter.count.toString()}");
}
其他的還有 ValueListenableProvider 、FutureProvider 、StreamProvider 等多種 Provider ，可見整個 Provider 的設計上更貼近 Flutter 的原生特性，同時設計也更好理解，并且兼顧了性能等問題。
Provider 的使用指南上，更詳細的 Vadaski 的
《Flutter | 狀態(tài)管理指南篇——Provider》 已經寫過，我就不重復寫輪子了，感興趣的可以過去看看。
自此，第十五篇終于結束了！(///▽///)
資源推薦
- 本文Demo ：https://github.com/CarGuo/state_manager_demo
- Github ： https://github.com/CarGuo/
- 開源 Flutter 完整項目：https://github.com/CarGuo/GSYGithubAppFlutter
- 開源 Flutter 多案例學習型項目: https://github.com/CarGuo/GSYFlutterDemo
- 開源 Fluttre 實戰(zhàn)電子書項目：https://github.com/CarGuo/GSYFlutterBook
