用級實戰(zhàn)避坑指南)
1. 為什么生命周期是Flutter開發(fā)的“任督二脈”剛接觸Flutter那會兒我對生命周期的理解就停留在“initState里發(fā)請求dispose里收資源”這個層面。直到有一次做一個即時通訊的頁面用戶反饋說每次切到后臺再回來聊天記錄會重復(fù)加載偶爾還會閃一下白屏。排查了大半天最后發(fā)現(xiàn)問題出在我把數(shù)據(jù)刷新邏輯寫在了build方法里而頁面從后臺恢復(fù)時觸發(fā)了重建。那次之后我才真正意識到生命周期不是背幾個方法名就完事的東西它直接決定了你的頁面在用戶手里是絲滑還是卡頓是省電還是耗電。Flutter的生命周期其實分兩個層面來看。一個是Widget層面的生命周期也就是我們常說的StatelessWidget和StatefulWidget那一套核心是createState、initState、build、dispose這些。另一個是應(yīng)用層面的生命周期通過WidgetsBindingObserver來監(jiān)聽比如didChangeAppLifecycleState它管的是整個App在前臺、后臺、非活躍狀態(tài)之間的切換。很多人只關(guān)注前者忽略了后者結(jié)果就是App切到后臺再回來數(shù)據(jù)狀態(tài)全亂了。這篇文章我打算把這兩個層面都拆開講透。從最基礎(chǔ)的Widget生命周期方法執(zhí)行順序到StatefulWidget的mounted屬性為什么重要再到應(yīng)用級生命周期怎么監(jiān)聽、怎么和路由結(jié)合使用最后會給出幾個我在實際項目里踩過坑之后總結(jié)出來的最佳實踐。不管你是剛學(xué)Flutter的新手還是已經(jīng)寫過幾個項目但總覺得狀態(tài)管理有點“玄學(xué)”的老手應(yīng)該都能從里面找到一些之前沒注意到的細節(jié)。2. Widget生命周期方法全解析與執(zhí)行順序2.1 StatelessWidget的“一次性”生命周期StatelessWidget的生命周期簡單到幾乎不需要討論但恰恰因為它簡單很多人會忽略它的一個關(guān)鍵特性它本身沒有狀態(tài)但它的build方法會被頻繁調(diào)用。當(dāng)你把一個StatelessWidget放到Widget樹里Flutter框架會調(diào)用它的構(gòu)造函數(shù)創(chuàng)建實例然后調(diào)用build方法返回描述UI的Widget樹。這個過程在父Widget重建時就會重新走一遍。我見過不少新手把網(wǎng)絡(luò)請求直接寫在StatelessWidget的build方法里結(jié)果就是每次父級重建請求就發(fā)一次頁面瘋狂閃爍。這里要記住一個原則StatelessWidget的build方法必須是純函數(shù)它只根據(jù)傳入的參數(shù)決定UI長什么樣不應(yīng)該有任何副作用。如果你需要發(fā)請求、訂閱流、初始化控制器那就必須用StatefulWidget。// 錯誤示范在StatelessWidget里發(fā)請求 class BadExample extends StatelessWidget { override Widget build(BuildContext context) { // 每次重建都會執(zhí)行請求會重復(fù)發(fā)送 fetchDataFromApi(); return Text(數(shù)據(jù)加載中...); } }2.2 StatefulWidget生命周期方法的完整執(zhí)行鏈路StatefulWidget的生命周期才是重頭戲。我把整個鏈路按時間順序拆成三個階段創(chuàng)建階段、更新階段、銷毀階段。每個階段涉及的方法和執(zhí)行時機都不一樣理解清楚這些你就能精準(zhǔn)控制代碼在什么時候跑。創(chuàng)建階段從createState開始。當(dāng)Flutter框架要把一個StatefulWidget插入Widget樹時它會調(diào)用createState方法創(chuàng)建一個State對象。注意createState在整個生命周期里只會被調(diào)用一次。緊接著框架會把新創(chuàng)建的State對象掛載到樹上這時候initState被調(diào)用。initState是整個生命周期里最適合做初始化工作的地方——初始化控制器、訂閱流、發(fā)起初始網(wǎng)絡(luò)請求都放在這里。但有一個坑在initState里不能訪問BuildContext的inheritFromWidgetOfExactType相關(guān)方法因為此時Widget還沒有完全建立依賴關(guān)系。如果你確實需要讀取InheritedWidget的數(shù)據(jù)要放到didChangeDependencies里。didChangeDependencies會在initState之后立即被調(diào)用一次之后每當(dāng)依賴的InheritedWidget發(fā)生變化時也會被調(diào)用。這個方法的典型使用場景是當(dāng)你依賴了MediaQuery、Theme或者自定義的InheritedWidget時在這里根據(jù)新的依賴值更新狀態(tài)。我個人的習(xí)慣是如果初始化邏輯不依賴上下文就放initState如果依賴就放didChangeDependencies并且加一個標(biāo)志位防止重復(fù)初始化。更新階段的核心是build方法。build會在以下幾種情況下被調(diào)用setState被調(diào)用、父Widget重建導(dǎo)致當(dāng)前Widget需要重建、依賴的InheritedWidget發(fā)生變化。build方法應(yīng)該盡可能輕量只做UI構(gòu)建不要在里面做耗時操作。另外didUpdateWidget會在父Widget重建并且新舊Widget的runtimeType和key相同時被調(diào)用參數(shù)是舊的Widget對象。這個方法適合用來對比新舊配置比如當(dāng)傳入的id變了需要重新請求數(shù)據(jù)。銷毀階段就是dispose。當(dāng)State對象從樹上永久移除時dispose被調(diào)用。這是你釋放資源的最后機會——取消訂閱、關(guān)閉控制器、停止動畫、移除監(jiān)聽器統(tǒng)統(tǒng)放這里。如果忘記在dispose里取消訂閱就會造成內(nèi)存泄漏嚴(yán)重的話會導(dǎo)致App崩潰。class LifecycleDemo extends StatefulWidget { final String userId; const LifecycleDemo({Key? key, required this.userId}) : super(key: key); override _LifecycleDemoState createState() _LifecycleDemoState(); } class _LifecycleDemoState extends StateLifecycleDemo { late StreamSubscription _subscription; final ScrollController _scrollController ScrollController(); override void initState() { super.initState(); // 初始化工作訂閱流、發(fā)起請求 _subscription dataStream.listen((data) { if (mounted) { setState(() { /* 更新狀態(tài) */ }); } }); } override void didChangeDependencies() { super.didChangeDependencies(); // 依賴的InheritedWidget變化時執(zhí)行 } override void didUpdateWidget(LifecycleDemo oldWidget) { super.didUpdateWidget(oldWidget); if (oldWidget.userId ! widget.userId) { // userId變了重新請求數(shù)據(jù) _reloadData(); } } override Widget build(BuildContext context) { return ListView( controller: _scrollController, children: [/* UI內(nèi)容 */], ); } override void dispose() { // 釋放資源順序很重要 _subscription.cancel(); _scrollController.dispose(); super.dispose(); } }2.3 mounted屬性一個容易被忽視的安全閥mounted是State對象的一個布爾屬性表示當(dāng)前State是否已經(jīng)掛載到Widget樹上。它的值在initState之前是falseinitState之后變成truedispose之后又變回false。這個屬性看起來不起眼但在異步操作里極其重要。想象一個場景用戶在頁面A發(fā)起了一個網(wǎng)絡(luò)請求請求還沒回來用戶就快速返回了上一頁頁面A被銷毀。這時候請求回來了回調(diào)里調(diào)用了setState但State已經(jīng)dispose了Flutter就會拋出異常。解決辦法就是在異步回調(diào)里先判斷mountedFuturevoid _fetchData() async { final data await api.getData(); if (!mounted) return; // 關(guān)鍵判斷 setState(() { _data data; }); }我個人的經(jīng)驗是所有異步回調(diào)里的setState之前都應(yīng)該加mounted判斷。這不會帶來性能問題但能避免大量“setState called after dispose”的報錯。另外在dispose里調(diào)用super.dispose()之前也要確保所有異步操作都已經(jīng)停止或者加了mounted判斷。3. 應(yīng)用級生命周期didChangeAppLifecycleState實戰(zhàn)3.1 監(jiān)聽App前后臺切換的正確姿勢Widget層面的生命周期管的是頁面內(nèi)部的狀態(tài)但App整體在前臺、后臺、非活躍之間的切換需要另一套機制——WidgetsBindingObserver。這個接口提供了didChangeAppLifecycleState回調(diào)參數(shù)是一個AppLifecycleState枚舉包含resumed、inactive、paused、detached四種狀態(tài)。resumed表示App可見并且可以響應(yīng)用戶輸入也就是回到前臺。inactive是一個過渡狀態(tài)比如來了電話、下拉通知欄App還在前臺但暫時不接收輸入。paused表示App被切到后臺不可見。detached表示App引擎還在運行但沒有任何視圖這個狀態(tài)比較少見。使用方式很簡單讓State類混入WidgetsBindingObserver在initState里注冊監(jiān)聽在dispose里移除監(jiān)聽然后重寫didChangeAppLifecycleState方法。class AppLifecycleAwareState extends StateAppLifecycleAware with WidgetsBindingObserver { override void initState() { super.initState(); WidgetsBinding.instance.addObserver(this); } override void dispose() { WidgetsBinding.instance.removeObserver(this); super.dispose(); } override void didChangeAppLifecycleState(AppLifecycleState state) { super.didChangeAppLifecycleState(state); switch (state) { case AppLifecycleState.resumed: // 回到前臺刷新數(shù)據(jù)、恢復(fù)動畫 _refreshData(); break; case AppLifecycleState.inactive: // 過渡狀態(tài)暫停視頻播放等 _pauseVideo(); break; case AppLifecycleState.paused: // 切到后臺保存草稿、停止定位 _saveDraft(); break; case AppLifecycleState.detached: // 引擎分離做最后的清理 break; } } }3.2 前后臺切換時的數(shù)據(jù)刷新策略很多業(yè)務(wù)場景需要在App回到前臺時刷新數(shù)據(jù)比如即時通訊的消息列表、股票行情、訂單狀態(tài)。但“回到前臺就刷新”這個策略需要謹(jǐn)慎設(shè)計否則會造成不必要的流量消耗和服務(wù)器壓力。我的做法是加一個時間閾值判斷只有當(dāng)App在后臺停留超過一定時間比如30秒才觸發(fā)刷新。如果用戶只是切出去看了一眼通知就回來沒必要重新請求。實現(xiàn)方式是在paused時記錄時間戳在resumed時計算時間差。DateTime? _pausedTime; override void didChangeAppLifecycleState(AppLifecycleState state) { if (state AppLifecycleState.paused) { _pausedTime DateTime.now(); } else if (state AppLifecycleState.resumed) { if (_pausedTime ! null DateTime.now().difference(_pausedTime!).inSeconds 30) { _refreshData(); } _pausedTime null; } }另一個需要注意的點是didChangeAppLifecycleState是全局的每個注冊了Observer的State都會收到回調(diào)。如果你在多個頁面都注冊了監(jiān)聽要確保每個頁面的刷新邏輯不會互相干擾。我一般只在最頂層的頁面或者需要刷新的特定頁面注冊而不是每個頁面都加。3.3 與路由生命周期結(jié)合的場景應(yīng)用級生命周期和路由生命周期結(jié)合使用時有一個經(jīng)典場景用戶正在填寫一個長表單突然切到后臺回來之后發(fā)現(xiàn)表單內(nèi)容沒了。這是因為某些情況下頁面被重建了。解決辦法是在paused時把表單數(shù)據(jù)保存到本地或者內(nèi)存緩存在resumed時恢復(fù)。還有一種情況是視頻播放頁面。用戶切到后臺視頻應(yīng)該暫?；氐角芭_視頻可以繼續(xù)播放。這個邏輯就放在didChangeAppLifecycleState里處理。但要注意如果用戶是從視頻頁面跳轉(zhuǎn)到其他頁面視頻也應(yīng)該暫停這時候就需要結(jié)合RouteAware來監(jiān)聽路由變化。class VideoPageState extends StateVideoPage with WidgetsBindingObserver, RouteAware { override void didChangeAppLifecycleState(AppLifecycleState state) { if (state AppLifecycleState.paused) { _videoController.pause(); } } override void didPushNext() { // 跳轉(zhuǎn)到其他頁面暫停視頻 _videoController.pause(); } override void didPopNext() { // 從其他頁面返回恢復(fù)視頻 _videoController.play(); } }4. 生命周期與狀態(tài)管理的協(xié)同作戰(zhàn)4.1 在initState里做異步初始化的正確方式initState本身不能是async的這是Flutter框架的硬性規(guī)定。但很多時候我們需要在頁面初始化時發(fā)起異步請求。常見的做法是在initState里調(diào)用一個異步方法而不是直接把initState標(biāo)記為async。override void initState() { super.initState(); _loadData(); // 調(diào)用異步方法不await } Futurevoid _loadData() async { final result await api.fetch(); if (mounted) { setState(() { _data result; }); } }這里有一個細節(jié)如果你在initState里直接await雖然語法上可以通過把initState改成async來實現(xiàn)但框架會在await之后繼續(xù)執(zhí)行后續(xù)代碼而此時Widget可能已經(jīng)build完成了導(dǎo)致一些依賴上下文的操作出錯。所以永遠不要在initState里直接await而是把異步邏輯抽到單獨的方法里。4.2 dispose里的資源釋放清單dispose是資源釋放的最后一道防線。我整理了一份常見的需要釋放的資源清單每次寫新頁面的時候都會對照檢查資源類型釋放方法不釋放的后果StreamSubscriptioncancel()內(nèi)存泄漏回調(diào)觸發(fā)時報錯AnimationControllerdispose()動畫繼續(xù)運行消耗CPUTextEditingControllerdispose()內(nèi)存泄漏ScrollControllerdispose()內(nèi)存泄漏Timercancel()定時器繼續(xù)執(zhí)行FocusNodedispose()內(nèi)存泄漏WidgetsBindingObserverremoveObserver()回調(diào)繼續(xù)觸發(fā)ChangeNotifierdispose()監(jiān)聽器無法釋放釋放順序也有講究一般先釋放自己創(chuàng)建的資源最后調(diào)用super.dispose()。如果資源之間有依賴關(guān)系比如先取消訂閱再關(guān)閉流控制器順序不能反。4.3 避免在build里做副作用操作build方法可能會被非常頻繁地調(diào)用官方文檔明確要求build必須是純函數(shù)。但實際開發(fā)中我見過太多人在build里做這些事發(fā)網(wǎng)絡(luò)請求、寫日志、修改全局變量、調(diào)用setState。這些操作輕則導(dǎo)致性能問題重則造成死循環(huán)。一個典型的錯誤是在build里根據(jù)條件調(diào)用setState// 錯誤示范build里調(diào)用setState會導(dǎo)致無限循環(huán) override Widget build(BuildContext context) { if (_data null) { setState(() { _data default; }); // 觸發(fā)重建又進入build死循環(huán) } return Text(_data!); }正確的做法是在initState或者didChangeDependencies里初始化數(shù)據(jù)build里只負責(zé)根據(jù)當(dāng)前狀態(tài)渲染UI。5. 常見生命周期問題排查與避坑指南5.1 setState called after dispose的三種解法這個報錯大概是Flutter開發(fā)者遇到頻率最高的異常之一。根本原因就是異步操作在State銷毀后才完成回調(diào)里調(diào)用了setState。解法有三種第一種在異步回調(diào)里加mounted判斷這是最推薦的方式。第二種使用CancelableOperation或者Completer來管理異步操作在dispose時取消。第三種把異步操作的結(jié)果通過Stream或者ValueNotifier來傳遞在dispose時取消訂閱。我個人的習(xí)慣是第一種和第三種結(jié)合簡單的請求用mounted判斷復(fù)雜的流式數(shù)據(jù)用Stream加cancel。5.2 頁面重建導(dǎo)致狀態(tài)丟失的修復(fù)方案有時候用戶反饋說“填了一半的表單突然清空了”這通常是因為頁面被重建了。觸發(fā)重建的原因可能有很多屏幕旋轉(zhuǎn)、主題切換、字體大小改變、系統(tǒng)語言變化。這些都會導(dǎo)致didChangeDependencies被調(diào)用如果初始化邏輯寫在這里且沒有做防重復(fù)處理狀態(tài)就會被重置。修復(fù)方案是加一個標(biāo)志位bool _initialized false; override void didChangeDependencies() { super.didChangeDependencies(); if (!_initialized) { _initialized true; _loadInitialData(); } }另外對于表單數(shù)據(jù)可以考慮使用AutomaticKeepAliveClientMixin來保持頁面狀態(tài)或者把數(shù)據(jù)提升到父級Widget或者全局狀態(tài)管理里。5.3 生命周期方法執(zhí)行順序速查表下面這張表總結(jié)了StatefulWidget從創(chuàng)建到銷毀的完整方法執(zhí)行順序以及每個方法的典型用途和注意事項執(zhí)行順序方法名調(diào)用時機典型用途注意事項1createStateWidget插入樹時創(chuàng)建State對象只調(diào)用一次2initStateState掛載后初始化控制器、訂閱不能訪問context依賴3didChangeDependenciesinitState后及依賴變化時讀取InheritedWidget可能多次調(diào)用4build需要渲染時構(gòu)建UI必須是純函數(shù)5didUpdateWidget父Widget重建時對比新舊配置參數(shù)是舊Widget6setState主動調(diào)用觸發(fā)重建不能在build里調(diào)用7deactivate從樹中移除時臨時移除處理可能重新插入8dispose永久移除時釋放資源最后調(diào)用super注意deactivate和dispose的區(qū)別在于deactivate可能只是臨時移除比如GlobalKey導(dǎo)致的樹結(jié)構(gòu)變化之后還可能重新插入而dispose是永久銷毀不會再被插入。5.4 熱重載對生命周期的影響熱重載是Flutter開發(fā)的一大殺器但它對生命周期方法的影響經(jīng)常被忽略。熱重載時initState不會被重新調(diào)用但build會被調(diào)用。這意味著如果你在initState里初始化了某個變量熱重載后這個變量還是舊值。如果你修改了initState里的代碼需要熱重啟才能生效。另外熱重載時dispose也不會被調(diào)用所以如果你在dispose里加了日志熱重載時看不到。這個特性有時候會造成困惑明明改了dispose里的代碼怎么沒生效答案是熱重載不觸發(fā)dispose需要熱重啟或者完全重啟App。6. 生命周期進階從源碼角度理解框架行為6.1 Element樹與State的綁定關(guān)系要真正理解生命周期繞不開Element這個概念。在Flutter的渲染流程里Widget只是配置信息Element才是真正被掛載到樹上的節(jié)點。每個StatefulElement持有一個State對象createState就是在StatefulElement掛載時調(diào)用的。當(dāng)Element被卸載時dispose被調(diào)用。mounted屬性的本質(zhì)就是判斷State對應(yīng)的Element是否還在樹上。setState的本質(zhì)是標(biāo)記Element為dirty然后在下一次幀繪制時重建。理解了這一層你就能明白為什么setState之后不是立即重建而是等到下一幀。6.2 生命周期與幀調(diào)度的關(guān)系Flutter的UI渲染是幀驅(qū)動的每一幀會經(jīng)歷build、layout、paint三個階段。生命周期方法里的build就是在build階段被調(diào)用的。setState會把當(dāng)前Element標(biāo)記為dirty然后通過scheduleBuildFor把重建任務(wù)加入到下一幀的build階段。didChangeAppLifecycleState的回調(diào)則是由平臺通道觸發(fā)的它不直接參與幀調(diào)度但可以在回調(diào)里調(diào)用setState來觸發(fā)重建。理解這個機制有助于你判斷哪些操作應(yīng)該放在生命周期方法里哪些應(yīng)該放在幀回調(diào)里。6.3 自定義StatefulWidget的生命周期擴展有時候框架提供的生命周期方法不夠用比如你想在Widget第一次渲染完成后執(zhí)行某個操作。這時候可以用WidgetsBinding.instance.addPostFrameCallback來注冊一個幀后回調(diào)override void initState() { super.initState(); WidgetsBinding.instance.addPostFrameCallback((_) { // 這一幀渲染完成后執(zhí)行 _showGuideDialog(); }); }這個回調(diào)只會在下一幀渲染完成后執(zhí)行一次適合用來做引導(dǎo)彈窗、測量Widget尺寸等操作。注意不要在回調(diào)里直接調(diào)用setState因為此時可能還在build階段會報錯。7. 我在實際項目中的生命周期使用心得做了這么多Flutter項目我總結(jié)出幾條關(guān)于生命周期的個人經(jīng)驗都是踩坑之后才明白的。第一條初始化邏輯盡量放在initState但依賴上下文的放didChangeDependencies。這個原則幫我避免了很多“context not found”的報錯。特別是當(dāng)你需要讀取Theme.of(context)或者MediaQuery.of(context)的時候放initState里會直接崩潰。第二條所有異步回調(diào)里的setState都要加mounted判斷。這個習(xí)慣讓我在測試階段少收到至少一半的異常報告。雖然多寫一行代碼但省下的排查時間遠遠值得。第三條dispose里的釋放順序要固定。我一般按照“后創(chuàng)建的先釋放”的原則比如先創(chuàng)建了ScrollController后創(chuàng)建了StreamSubscription那dispose里就先cancel訂閱再dispose控制器。這樣能避免一些奇怪的依賴問題。第四條應(yīng)用級生命周期監(jiān)聽不要濫用。只在真正需要感知前后臺切換的頁面注冊O(shè)bserver比如視頻播放、即時通訊、定位導(dǎo)航。普通的內(nèi)容展示頁面沒必要監(jiān)聽否則回調(diào)多了反而影響性能。第五條熱重載不觸發(fā)dispose調(diào)試資源釋放要用熱重啟。這個坑我踩過好幾次明明在dispose里加了日志熱重載后就是看不到后來才反應(yīng)過來是熱重載的機制問題。最后再分享一個小技巧如果你不確定某個生命周期方法什么時候被調(diào)用可以在方法里加debugPrint然后觀察控制臺輸出。Flutter的熱重載配合日志輸出是理解生命周期最直觀的方式。我當(dāng)初就是靠這個方法把整個執(zhí)行鏈路摸清楚的。 Flutter生命周期深度解析：Widget與應(yīng)用級實戰(zhàn)避坑指南
1. 為什么生命周期是Flutter開發(fā)的“任督二脈”剛接觸Flutter那會兒我對生命周期的理解就停留在“initState里發(fā)請求dispose里收資源”這個層面。直到有一次做一個即時通訊的頁面用戶反饋說每次切到后臺再回來聊天記錄會重復(fù)加載偶爾還會閃一下白屏。排查了大半天最后發(fā)現(xiàn)問題出在我把數(shù)據(jù)刷新邏輯寫在了build方法里而頁面從后臺恢復(fù)時觸發(fā)了重建。那次之后我才真正意識到生命周期不是背幾個方法名就完事的東西它直接決定了你的頁面在用戶手里是絲滑還是卡頓是省電還是耗電。Flutter的生命周期其實分兩個層面來看。一個是Widget層面的生命周期也就是我們常說的StatelessWidget和StatefulWidget那一套核心是createState、initState、build、dispose這些。另一個是應(yīng)用層面的生命周期通過WidgetsBindingObserver來監(jiān)聽比如didChangeAppLifecycleState它管的是整個App在前臺、后臺、非活躍狀態(tài)之間的切換。很多人只關(guān)注前者忽略了后者結(jié)果就是App切到后臺再回來數(shù)據(jù)狀態(tài)全亂了。這篇文章我打算把這兩個層面都拆開講透。從最基礎(chǔ)的Widget生命周期方法執(zhí)行順序到StatefulWidget的mounted屬性為什么重要再到應(yīng)用級生命周期怎么監(jiān)聽、怎么和路由結(jié)合使用最后會給出幾個我在實際項目里踩過坑之后總結(jié)出來的最佳實踐。不管你是剛學(xué)Flutter的新手還是已經(jīng)寫過幾個項目但總覺得狀態(tài)管理有點“玄學(xué)”的老手應(yīng)該都能從里面找到一些之前沒注意到的細節(jié)。2. Widget生命周期方法全解析與執(zhí)行順序2.1 StatelessWidget的“一次性”生命周期StatelessWidget的生命周期簡單到幾乎不需要討論但恰恰因為它簡單很多人會忽略它的一個關(guān)鍵特性它本身沒有狀態(tài)但它的build方法會被頻繁調(diào)用。當(dāng)你把一個StatelessWidget放到Widget樹里Flutter框架會調(diào)用它的構(gòu)造函數(shù)創(chuàng)建實例然后調(diào)用build方法返回描述UI的Widget樹。這個過程在父Widget重建時就會重新走一遍。我見過不少新手把網(wǎng)絡(luò)請求直接寫在StatelessWidget的build方法里結(jié)果就是每次父級重建請求就發(fā)一次頁面瘋狂閃爍。這里要記住一個原則StatelessWidget的build方法必須是純函數(shù)它只根據(jù)傳入的參數(shù)決定UI長什么樣不應(yīng)該有任何副作用。如果你需要發(fā)請求、訂閱流、初始化控制器那就必須用StatefulWidget。// 錯誤示范在StatelessWidget里發(fā)請求 class BadExample extends StatelessWidget { override Widget build(BuildContext context) { // 每次重建都會執(zhí)行請求會重復(fù)發(fā)送 fetchDataFromApi(); return Text(數(shù)據(jù)加載中...); } }2.2 StatefulWidget生命周期方法的完整執(zhí)行鏈路StatefulWidget的生命周期才是重頭戲。我把整個鏈路按時間順序拆成三個階段創(chuàng)建階段、更新階段、銷毀階段。每個階段涉及的方法和執(zhí)行時機都不一樣理解清楚這些你就能精準(zhǔn)控制代碼在什么時候跑。創(chuàng)建階段從createState開始。當(dāng)Flutter框架要把一個StatefulWidget插入Widget樹時它會調(diào)用createState方法創(chuàng)建一個State對象。注意createState在整個生命周期里只會被調(diào)用一次。緊接著框架會把新創(chuàng)建的State對象掛載到樹上這時候initState被調(diào)用。initState是整個生命周期里最適合做初始化工作的地方——初始化控制器、訂閱流、發(fā)起初始網(wǎng)絡(luò)請求都放在這里。但有一個坑在initState里不能訪問BuildContext的inheritFromWidgetOfExactType相關(guān)方法因為此時Widget還沒有完全建立依賴關(guān)系。如果你確實需要讀取InheritedWidget的數(shù)據(jù)要放到didChangeDependencies里。didChangeDependencies會在initState之后立即被調(diào)用一次之后每當(dāng)依賴的InheritedWidget發(fā)生變化時也會被調(diào)用。這個方法的典型使用場景是當(dāng)你依賴了MediaQuery、Theme或者自定義的InheritedWidget時在這里根據(jù)新的依賴值更新狀態(tài)。我個人的習(xí)慣是如果初始化邏輯不依賴上下文就放initState如果依賴就放didChangeDependencies并且加一個標(biāo)志位防止重復(fù)初始化。更新階段的核心是build方法。build會在以下幾種情況下被調(diào)用setState被調(diào)用、父Widget重建導(dǎo)致當(dāng)前Widget需要重建、依賴的InheritedWidget發(fā)生變化。build方法應(yīng)該盡可能輕量只做UI構(gòu)建不要在里面做耗時操作。另外didUpdateWidget會在父Widget重建并且新舊Widget的runtimeType和key相同時被調(diào)用參數(shù)是舊的Widget對象。這個方法適合用來對比新舊配置比如當(dāng)傳入的id變了需要重新請求數(shù)據(jù)。銷毀階段就是dispose。當(dāng)State對象從樹上永久移除時dispose被調(diào)用。這是你釋放資源的最后機會——取消訂閱、關(guān)閉控制器、停止動畫、移除監(jiān)聽器統(tǒng)統(tǒng)放這里。如果忘記在dispose里取消訂閱就會造成內(nèi)存泄漏嚴(yán)重的話會導(dǎo)致App崩潰。class LifecycleDemo extends StatefulWidget { final String userId; const LifecycleDemo({Key? key, required this.userId}) : super(key: key); override _LifecycleDemoState createState() _LifecycleDemoState(); } class _LifecycleDemoState extends StateLifecycleDemo { late StreamSubscription _subscription; final ScrollController _scrollController ScrollController(); override void initState() { super.initState(); // 初始化工作訂閱流、發(fā)起請求 _subscription dataStream.listen((data) { if (mounted) { setState(() { /* 更新狀態(tài) */ }); } }); } override void didChangeDependencies() { super.didChangeDependencies(); // 依賴的InheritedWidget變化時執(zhí)行 } override void didUpdateWidget(LifecycleDemo oldWidget) { super.didUpdateWidget(oldWidget); if (oldWidget.userId ! widget.userId) { // userId變了重新請求數(shù)據(jù) _reloadData(); } } override Widget build(BuildContext context) { return ListView( controller: _scrollController, children: [/* UI內(nèi)容 */], ); } override void dispose() { // 釋放資源順序很重要 _subscription.cancel(); _scrollController.dispose(); super.dispose(); } }2.3 mounted屬性一個容易被忽視的安全閥mounted是State對象的一個布爾屬性表示當(dāng)前State是否已經(jīng)掛載到Widget樹上。它的值在initState之前是falseinitState之后變成truedispose之后又變回false。這個屬性看起來不起眼但在異步操作里極其重要。想象一個場景用戶在頁面A發(fā)起了一個網(wǎng)絡(luò)請求請求還沒回來用戶就快速返回了上一頁頁面A被銷毀。這時候請求回來了回調(diào)里調(diào)用了setState但State已經(jīng)dispose了Flutter就會拋出異常。解決辦法就是在異步回調(diào)里先判斷mountedFuturevoid _fetchData() async { final data await api.getData(); if (!mounted) return; // 關(guān)鍵判斷 setState(() { _data data; }); }我個人的經(jīng)驗是所有異步回調(diào)里的setState之前都應(yīng)該加mounted判斷。這不會帶來性能問題但能避免大量“setState called after dispose”的報錯。另外在dispose里調(diào)用super.dispose()之前也要確保所有異步操作都已經(jīng)停止或者加了mounted判斷。3. 應(yīng)用級生命周期didChangeAppLifecycleState實戰(zhàn)3.1 監(jiān)聽App前后臺切換的正確姿勢Widget層面的生命周期管的是頁面內(nèi)部的狀態(tài)但App整體在前臺、后臺、非活躍之間的切換需要另一套機制——WidgetsBindingObserver。這個接口提供了didChangeAppLifecycleState回調(diào)參數(shù)是一個AppLifecycleState枚舉包含resumed、inactive、paused、detached四種狀態(tài)。resumed表示App可見并且可以響應(yīng)用戶輸入也就是回到前臺。inactive是一個過渡狀態(tài)比如來了電話、下拉通知欄App還在前臺但暫時不接收輸入。paused表示App被切到后臺不可見。detached表示App引擎還在運行但沒有任何視圖這個狀態(tài)比較少見。使用方式很簡單讓State類混入WidgetsBindingObserver在initState里注冊監(jiān)聽在dispose里移除監(jiān)聽然后重寫didChangeAppLifecycleState方法。class AppLifecycleAwareState extends StateAppLifecycleAware with WidgetsBindingObserver { override void initState() { super.initState(); WidgetsBinding.instance.addObserver(this); } override void dispose() { WidgetsBinding.instance.removeObserver(this); super.dispose(); } override void didChangeAppLifecycleState(AppLifecycleState state) { super.didChangeAppLifecycleState(state); switch (state) { case AppLifecycleState.resumed: // 回到前臺刷新數(shù)據(jù)、恢復(fù)動畫 _refreshData(); break; case AppLifecycleState.inactive: // 過渡狀態(tài)暫停視頻播放等 _pauseVideo(); break; case AppLifecycleState.paused: // 切到后臺保存草稿、停止定位 _saveDraft(); break; case AppLifecycleState.detached: // 引擎分離做最后的清理 break; } } }3.2 前后臺切換時的數(shù)據(jù)刷新策略很多業(yè)務(wù)場景需要在App回到前臺時刷新數(shù)據(jù)比如即時通訊的消息列表、股票行情、訂單狀態(tài)。但“回到前臺就刷新”這個策略需要謹(jǐn)慎設(shè)計否則會造成不必要的流量消耗和服務(wù)器壓力。我的做法是加一個時間閾值判斷只有當(dāng)App在后臺停留超過一定時間比如30秒才觸發(fā)刷新。如果用戶只是切出去看了一眼通知就回來沒必要重新請求。實現(xiàn)方式是在paused時記錄時間戳在resumed時計算時間差。DateTime? _pausedTime; override void didChangeAppLifecycleState(AppLifecycleState state) { if (state AppLifecycleState.paused) { _pausedTime DateTime.now(); } else if (state AppLifecycleState.resumed) { if (_pausedTime ! null DateTime.now().difference(_pausedTime!).inSeconds 30) { _refreshData(); } _pausedTime null; } }另一個需要注意的點是didChangeAppLifecycleState是全局的每個注冊了Observer的State都會收到回調(diào)。如果你在多個頁面都注冊了監(jiān)聽要確保每個頁面的刷新邏輯不會互相干擾。我一般只在最頂層的頁面或者需要刷新的特定頁面注冊而不是每個頁面都加。3.3 與路由生命周期結(jié)合的場景應(yīng)用級生命周期和路由生命周期結(jié)合使用時有一個經(jīng)典場景用戶正在填寫一個長表單突然切到后臺回來之后發(fā)現(xiàn)表單內(nèi)容沒了。這是因為某些情況下頁面被重建了。解決辦法是在paused時把表單數(shù)據(jù)保存到本地或者內(nèi)存緩存在resumed時恢復(fù)。還有一種情況是視頻播放頁面。用戶切到后臺視頻應(yīng)該暫?；氐角芭_視頻可以繼續(xù)播放。這個邏輯就放在didChangeAppLifecycleState里處理。但要注意如果用戶是從視頻頁面跳轉(zhuǎn)到其他頁面視頻也應(yīng)該暫停這時候就需要結(jié)合RouteAware來監(jiān)聽路由變化。class VideoPageState extends StateVideoPage with WidgetsBindingObserver, RouteAware { override void didChangeAppLifecycleState(AppLifecycleState state) { if (state AppLifecycleState.paused) { _videoController.pause(); } } override void didPushNext() { // 跳轉(zhuǎn)到其他頁面暫停視頻 _videoController.pause(); } override void didPopNext() { // 從其他頁面返回恢復(fù)視頻 _videoController.play(); } }4. 生命周期與狀態(tài)管理的協(xié)同作戰(zhàn)4.1 在initState里做異步初始化的正確方式initState本身不能是async的這是Flutter框架的硬性規(guī)定。但很多時候我們需要在頁面初始化時發(fā)起異步請求。常見的做法是在initState里調(diào)用一個異步方法而不是直接把initState標(biāo)記為async。override void initState() { super.initState(); _loadData(); // 調(diào)用異步方法不await } Futurevoid _loadData() async { final result await api.fetch(); if (mounted) { setState(() { _data result; }); } }這里有一個細節(jié)如果你在initState里直接await雖然語法上可以通過把initState改成async來實現(xiàn)但框架會在await之后繼續(xù)執(zhí)行后續(xù)代碼而此時Widget可能已經(jīng)build完成了導(dǎo)致一些依賴上下文的操作出錯。所以永遠不要在initState里直接await而是把異步邏輯抽到單獨的方法里。4.2 dispose里的資源釋放清單dispose是資源釋放的最后一道防線。我整理了一份常見的需要釋放的資源清單每次寫新頁面的時候都會對照檢查資源類型釋放方法不釋放的后果StreamSubscriptioncancel()內(nèi)存泄漏回調(diào)觸發(fā)時報錯AnimationControllerdispose()動畫繼續(xù)運行消耗CPUTextEditingControllerdispose()內(nèi)存泄漏ScrollControllerdispose()內(nèi)存泄漏Timercancel()定時器繼續(xù)執(zhí)行FocusNodedispose()內(nèi)存泄漏WidgetsBindingObserverremoveObserver()回調(diào)繼續(xù)觸發(fā)ChangeNotifierdispose()監(jiān)聽器無法釋放釋放順序也有講究一般先釋放自己創(chuàng)建的資源最后調(diào)用super.dispose()。如果資源之間有依賴關(guān)系比如先取消訂閱再關(guān)閉流控制器順序不能反。4.3 避免在build里做副作用操作build方法可能會被非常頻繁地調(diào)用官方文檔明確要求build必須是純函數(shù)。但實際開發(fā)中我見過太多人在build里做這些事發(fā)網(wǎng)絡(luò)請求、寫日志、修改全局變量、調(diào)用setState。這些操作輕則導(dǎo)致性能問題重則造成死循環(huán)。一個典型的錯誤是在build里根據(jù)條件調(diào)用setState// 錯誤示范build里調(diào)用setState會導(dǎo)致無限循環(huán) override Widget build(BuildContext context) { if (_data null) { setState(() { _data default; }); // 觸發(fā)重建又進入build死循環(huán) } return Text(_data!); }正確的做法是在initState或者didChangeDependencies里初始化數(shù)據(jù)build里只負責(zé)根據(jù)當(dāng)前狀態(tài)渲染UI。5. 常見生命周期問題排查與避坑指南5.1 setState called after dispose的三種解法這個報錯大概是Flutter開發(fā)者遇到頻率最高的異常之一。根本原因就是異步操作在State銷毀后才完成回調(diào)里調(diào)用了setState。解法有三種第一種在異步回調(diào)里加mounted判斷這是最推薦的方式。第二種使用CancelableOperation或者Completer來管理異步操作在dispose時取消。第三種把異步操作的結(jié)果通過Stream或者ValueNotifier來傳遞在dispose時取消訂閱。我個人的習(xí)慣是第一種和第三種結(jié)合簡單的請求用mounted判斷復(fù)雜的流式數(shù)據(jù)用Stream加cancel。5.2 頁面重建導(dǎo)致狀態(tài)丟失的修復(fù)方案有時候用戶反饋說“填了一半的表單突然清空了”這通常是因為頁面被重建了。觸發(fā)重建的原因可能有很多屏幕旋轉(zhuǎn)、主題切換、字體大小改變、系統(tǒng)語言變化。這些都會導(dǎo)致didChangeDependencies被調(diào)用如果初始化邏輯寫在這里且沒有做防重復(fù)處理狀態(tài)就會被重置。修復(fù)方案是加一個標(biāo)志位bool _initialized false; override void didChangeDependencies() { super.didChangeDependencies(); if (!_initialized) { _initialized true; _loadInitialData(); } }另外對于表單數(shù)據(jù)可以考慮使用AutomaticKeepAliveClientMixin來保持頁面狀態(tài)或者把數(shù)據(jù)提升到父級Widget或者全局狀態(tài)管理里。5.3 生命周期方法執(zhí)行順序速查表下面這張表總結(jié)了StatefulWidget從創(chuàng)建到銷毀的完整方法執(zhí)行順序以及每個方法的典型用途和注意事項執(zhí)行順序方法名調(diào)用時機典型用途注意事項1createStateWidget插入樹時創(chuàng)建State對象只調(diào)用一次2initStateState掛載后初始化控制器、訂閱不能訪問context依賴3didChangeDependenciesinitState后及依賴變化時讀取InheritedWidget可能多次調(diào)用4build需要渲染時構(gòu)建UI必須是純函數(shù)5didUpdateWidget父Widget重建時對比新舊配置參數(shù)是舊Widget6setState主動調(diào)用觸發(fā)重建不能在build里調(diào)用7deactivate從樹中移除時臨時移除處理可能重新插入8dispose永久移除時釋放資源最后調(diào)用super注意deactivate和dispose的區(qū)別在于deactivate可能只是臨時移除比如GlobalKey導(dǎo)致的樹結(jié)構(gòu)變化之后還可能重新插入而dispose是永久銷毀不會再被插入。5.4 熱重載對生命周期的影響熱重載是Flutter開發(fā)的一大殺器但它對生命周期方法的影響經(jīng)常被忽略。熱重載時initState不會被重新調(diào)用但build會被調(diào)用。這意味著如果你在initState里初始化了某個變量熱重載后這個變量還是舊值。如果你修改了initState里的代碼需要熱重啟才能生效。另外熱重載時dispose也不會被調(diào)用所以如果你在dispose里加了日志熱重載時看不到。這個特性有時候會造成困惑明明改了dispose里的代碼怎么沒生效答案是熱重載不觸發(fā)dispose需要熱重啟或者完全重啟App。6. 生命周期進階從源碼角度理解框架行為6.1 Element樹與State的綁定關(guān)系要真正理解生命周期繞不開Element這個概念。在Flutter的渲染流程里Widget只是配置信息Element才是真正被掛載到樹上的節(jié)點。每個StatefulElement持有一個State對象createState就是在StatefulElement掛載時調(diào)用的。當(dāng)Element被卸載時dispose被調(diào)用。mounted屬性的本質(zhì)就是判斷State對應(yīng)的Element是否還在樹上。setState的本質(zhì)是標(biāo)記Element為dirty然后在下一次幀繪制時重建。理解了這一層你就能明白為什么setState之后不是立即重建而是等到下一幀。6.2 生命周期與幀調(diào)度的關(guān)系Flutter的UI渲染是幀驅(qū)動的每一幀會經(jīng)歷build、layout、paint三個階段。生命周期方法里的build就是在build階段被調(diào)用的。setState會把當(dāng)前Element標(biāo)記為dirty然后通過scheduleBuildFor把重建任務(wù)加入到下一幀的build階段。didChangeAppLifecycleState的回調(diào)則是由平臺通道觸發(fā)的它不直接參與幀調(diào)度但可以在回調(diào)里調(diào)用setState來觸發(fā)重建。理解這個機制有助于你判斷哪些操作應(yīng)該放在生命周期方法里哪些應(yīng)該放在幀回調(diào)里。6.3 自定義StatefulWidget的生命周期擴展有時候框架提供的生命周期方法不夠用比如你想在Widget第一次渲染完成后執(zhí)行某個操作。這時候可以用WidgetsBinding.instance.addPostFrameCallback來注冊一個幀后回調(diào)override void initState() { super.initState(); WidgetsBinding.instance.addPostFrameCallback((_) { // 這一幀渲染完成后執(zhí)行 _showGuideDialog(); }); }這個回調(diào)只會在下一幀渲染完成后執(zhí)行一次適合用來做引導(dǎo)彈窗、測量Widget尺寸等操作。注意不要在回調(diào)里直接調(diào)用setState因為此時可能還在build階段會報錯。7. 我在實際項目中的生命周期使用心得做了這么多Flutter項目我總結(jié)出幾條關(guān)于生命周期的個人經(jīng)驗都是踩坑之后才明白的。第一條初始化邏輯盡量放在initState但依賴上下文的放didChangeDependencies。這個原則幫我避免了很多“context not found”的報錯。特別是當(dāng)你需要讀取Theme.of(context)或者MediaQuery.of(context)的時候放initState里會直接崩潰。第二條所有異步回調(diào)里的setState都要加mounted判斷。這個習(xí)慣讓我在測試階段少收到至少一半的異常報告。雖然多寫一行代碼但省下的排查時間遠遠值得。第三條dispose里的釋放順序要固定。我一般按照“后創(chuàng)建的先釋放”的原則比如先創(chuàng)建了ScrollController后創(chuàng)建了StreamSubscription那dispose里就先cancel訂閱再dispose控制器。這樣能避免一些奇怪的依賴問題。第四條應(yīng)用級生命周期監(jiān)聽不要濫用。只在真正需要感知前后臺切換的頁面注冊O(shè)bserver比如視頻播放、即時通訊、定位導(dǎo)航。普通的內(nèi)容展示頁面沒必要監(jiān)聽否則回調(diào)多了反而影響性能。第五條熱重載不觸發(fā)dispose調(diào)試資源釋放要用熱重啟。這個坑我踩過好幾次明明在dispose里加了日志熱重載后就是看不到后來才反應(yīng)過來是熱重載的機制問題。最后再分享一個小技巧如果你不確定某個生命周期方法什么時候被調(diào)用可以在方法里加debugPrint然后觀察控制臺輸出。Flutter的熱重載配合日志輸出是理解生命周期最直觀的方式。我當(dāng)初就是靠這個方法把整個執(zhí)行鏈路摸清楚的。