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