今天簡單說一下flutter中的狀態管理，我們這次使用provider；
ps：先說一個概念，Model，模型，這里面定義了我們准備全局使用的數據，或者方法；
舉個栗子：我們有一個User類，用來儲存用戶的信息，比如登錄之后，我們會拿到用戶的一些個人數據，那么這些數據就可以作為屬性寫在Model里，同時我們在User內部，還會提供一個upUser方法，用來更新用戶信息，那么這個方法也可以寫在Model中，OK，以上就是我們准備的User Model;
下面是正題，go，go，go
一、Provider的三個好兄弟：
老大 -- MultiProvider
老二 -- Providers
老三 -- Provider.of<T>(context) / Widget Consumer
二、三兄弟的組合拳：
其實很好理解，我們不去說精髓，先把拳法說一下，靠着拳法去揣摩精髓，會簡單很多；
1、老大 MultiProvider
Widget build(BuildContext context) { return MultiProvider( providers: [], ///先不考慮這一句 child: MaterialApp( title: 'Provider Demo', initialRoute: '/', ), ); }
上面這段代碼想必大家很熟悉，一個根widget（先不考慮這一句 providers: [] ），老大的任務就是包裹根節點，將我們准備好的Model和View建立聯系；可以想象成一只巨大章魚包裹了一棵大樹，他可以將觸手隨意的伸向某一節樹枝；
2、老二 Providers登場：
其實也很好理解，既然老大可以將我們准備好的各個Model輸送到各個節點，那前提是不是老大得知道都有哪些Model需要被送走呢，老二出現了，他就負責預先定義好，需要被共享的Model；
那老二該如何定義呢，我們上面“先不考慮”的那一句就該出現了，providers，老二是個數組，providers中的s也很明顯是個復數，他和老大一起使用，老二就是貨源，老大就是供貨商，那么老三就是消費者了；
當然老二這個數組里面不會這么簡單，providers：[provider，provider，providers]，它肯定不會是這個樣子，因為我們使用Model的需求不同，老二這個數組里裝的兒子有好幾種，下面我們就說一下，老二幾個常用的兒子：
大兒子：provider 不需要被監聽，有的常量或者方法，根本不需要“牽一發而動全身”，也就是說他們不會被要求隨着變動而變動，這樣的需求就用大兒子定義；
二兒子： ChangeNotifierProvider 對這個兒子父親要求的就比較多了，它會隨着某些數據改變而被通知更新，也就是說，比如這個Model被用在多個page，那么當其中一處被改變時，他就應該告訴其他的地方，改更新了，這樣的需求就是用二兒子定義；
三兒子： ChangeNotifierProxyProvider 對這個兒子要求就更高了，所以它的名字都比老二長一截，他不僅要像老二一樣，通知更新，還要協調Model與Model之間的更新，比如一個ModelA依賴另一個ModelB，ModelB更新，他就要讓依賴它的ModelA也隨之更新，這就是老三的活；
具體寫法呢，也很簡單，官網走起；
3、老三這個人有點怪
我們上面說了老三是消費者，也就是說，他就是負責從各個節點取出數據來使用的；
為什么說他怪，因為他有兩種形態，一種是需要綁定在widget中展示用的，另一種則不是，只是需要作為數據去使用；
變身一
var foo = Provider.of<T>(context);
T是你需要的Model，只需如此，你的foo就取出來了；
變身二
Consumer<T>( builder: (context,foo, child) => Text('$foo.text') )
widget展示，foo如上，也是從Model中取出的數據，隨意使用；
OK，三兄弟基本介紹完畢，我也是今天剛剛看到的Provider，如果理解的不對，請你也假裝對，哈哈哈，開玩笑，希望大家共同進步；