1. 為什么生命周期是Flutter開發(fā)的“任督二脈”剛接觸Flutter那會(huì)兒我對(duì)生命周期的理解就停留在“initState里發(fā)請(qǐng)求dispose里收資源”這個(gè)層面。直到有一次做一個(gè)即時(shí)通訊的頁(yè)面用戶反饋說(shuō)每次切到后臺(tái)再回來(lái)聊天記錄會(huì)重復(fù)加載偶爾還會(huì)閃一下白屏。排查了大半天最后發(fā)現(xiàn)問題出在我把數(shù)據(jù)刷新邏輯寫在了build方法里而頁(yè)面從后臺(tái)恢復(fù)時(shí)觸發(fā)了重建。那次之后我才真正意識(shí)到生命周期不是背幾個(gè)方法名就完事的東西它直接決定了你的頁(yè)面在用戶手里是絲滑還是卡頓是省電還是耗電。Flutter的生命周期其實(shí)分兩個(gè)層面來(lái)看。一個(gè)是Widget層面的生命周期也就是我們常說(shuō)的StatelessWidget和StatefulWidget那一套核心是createState、initState、build、dispose這些。另一個(gè)是應(yīng)用層面的生命周期通過WidgetsBindingObserver來(lái)監(jiān)聽比如didChangeAppLifecycleState它管的是整個(gè)App在前臺(tái)、后臺(tái)、非活躍狀態(tài)之間的切換。很多人只關(guān)注前者忽略了后者結(jié)果就是App切到后臺(tái)再回來(lái)數(shù)據(jù)狀態(tài)全亂了。這篇文章我打算把這兩個(gè)層面都拆開講透。從最基礎(chǔ)的Widget生命周期方法執(zhí)行順序到StatefulWidget的mounted屬性為什么重要再到應(yīng)用級(jí)生命周期怎么監(jiān)聽、怎么和路由結(jié)合使用最后會(huì)給出幾個(gè)我在實(shí)際項(xiàng)目里踩過坑之后總結(jié)出來(lái)的最佳實(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ā)一次頁(yè)面瘋狂閃爍。這里要記住一個(gè)原則StatelessWidget的build方法必須是純函數(shù)它只根據(jù)傳入的參數(shù)決定UI長(zhǎng)什么樣不應(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è)方法適合用來(lái)對(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è)屬性看起來(lái)不起眼但在異步操作里極其重要。想象一個(gè)場(chǎng)景用戶在頁(yè)面A發(fā)起了一個(gè)網(wǎng)絡(luò)請(qǐng)求請(qǐng)求還沒回來(lái)用戶就快速返回了上一頁(yè)頁(yè)面A被銷毀。這時(shí)候請(qǐng)求回來(lái)了回調(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ì)帶來(lái)性能問題但能避免大量“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層面的生命周期管的是頁(yè)面內(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)比如來(lá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ā)刷新。如果用戶只是切出去看了一眼通知就回來(lái)沒必要重新請(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è)頁(yè)面都注冊(cè)了監(jiān)聽要確保每個(gè)頁(yè)面的刷新邏輯不會(huì)互相干擾。我一般只在最頂層的頁(yè)面或者需要刷新的特定頁(yè)面注冊(cè)而不是每個(gè)頁(yè)面都加。3.3 與路由生命周期結(jié)合的場(chǎng)景應(yīng)用級(jí)生命周期和路由生命周期結(jié)合使用時(shí)有一個(gè)經(jīng)典場(chǎng)景用戶正在填寫一個(gè)長(zhǎng)表單突然切到后臺(tái)回來(lái)之后發(fā)現(xiàn)表單內(nèi)容沒了。這是因?yàn)槟承┣闆r下頁(yè)面被重建了。解決辦法是在paused時(shí)把表單數(shù)據(jù)保存到本地或者內(nèi)存緩存在resumed時(shí)恢復(fù)。還有一種情況是視頻播放頁(yè)面。用戶切到后臺(tái)視頻應(yīng)該暫?；氐角芭_(tái)視頻可以繼續(xù)播放。這個(gè)邏輯就放在didChangeAppLifecycleState里處理。但要注意如果用戶是從視頻頁(yè)面跳轉(zhuǎn)到其他頁(yè)面視頻也應(yīng)該暫停這時(shí)候就需要結(jié)合RouteAware來(lái)監(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)到其他頁(yè)面暫停視頻 _videoController.pause(); } override void didPopNext() { // 從其他頁(yè)面返回恢復(fù)視頻 _videoController.play(); } }4. 生命周期與狀態(tài)管理的協(xié)同作戰(zhàn)4.1 在initState里做異步初始化的正確方式initState本身不能是async的這是Flutter框架的硬性規(guī)定。但很多時(shí)候我們需要在頁(yè)面初始化時(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雖然語(yǔ)法上可以通過把initState改成async來(lái)實(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是資源釋放的最后一道防線。我整理了一份常見的需要釋放的資源清單每次寫新頁(yè)面的時(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)聽器無(wú)法釋放釋放順序也有講究一般先釋放自己創(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)致無(wú)限循環(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來(lái)管理異步操作在dispose時(shí)取消。第三種把異步操作的結(jié)果通過Stream或者ValueNotifier來(lái)傳遞在dispose時(shí)取消訂閱。我個(gè)人的習(xí)慣是第一種和第三種結(jié)合簡(jiǎn)單的請(qǐng)求用mounted判斷復(fù)雜的流式數(shù)據(jù)用Stream加cancel。5.2 頁(yè)面重建導(dǎo)致狀態(tài)丟失的修復(fù)方案有時(shí)候用戶反饋說(shuō)“填了一半的表單突然清空了”這通常是因?yàn)轫?yè)面被重建了。觸發(fā)重建的原因可能有很多屏幕旋轉(zhuǎn)、主題切換、字體大小改變、系統(tǒng)語(yǔ)言變化。這些都會(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來(lái)保持頁(yè)面狀態(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來(lái)觸發(fā)重建。理解這個(gè)機(jī)制有助于你判斷哪些操作應(yīng)該放在生命周期方法里哪些應(yīng)該放在幀回調(diào)里。6.3 自定義StatefulWidget的生命周期擴(kuò)展有時(shí)候框架提供的生命周期方法不夠用比如你想在Widget第一次渲染完成后執(zhí)行某個(gè)操作。這時(shí)候可以用WidgetsBinding.instance.addPostFrameCallback來(lái)注冊(cè)一個(gè)幀后回調(diào)override void initState() { super.initState(); WidgetsBinding.instance.addPostFrameCallback((_) { // 這一幀渲染完成后執(zhí)行 _showGuideDialog(); }); }這個(gè)回調(diào)只會(huì)在下一幀渲染完成后執(zhí)行一次適合用來(lái)做引導(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)切換的頁(yè)面注冊(cè)O(shè)bserver比如視頻播放、即時(shí)通訊、定位導(dǎo)航。普通的內(nèi)容展示頁(yè)面沒必要監(jiān)聽否則回調(diào)多了反而影響性能。第五條熱重載不觸發(fā)dispose調(diào)試資源釋放要用熱重啟。這個(gè)坑我踩過好幾次明明在dispose里加了日志熱重載后就是看不到后來(lái)才反應(yīng)過來(lái)是熱重載的機(jī)制問題。最后再分享一個(gè)小技巧如果你不確定某個(gè)生命周期方法什么時(shí)候被調(diào)用可以在方法里加debugPrint然后觀察控制臺(tái)輸出。Flutter的熱重載配合日志輸出是理解生命周期最直觀的方式。我當(dāng)初就是靠這個(gè)方法把整個(gè)執(zhí)行鏈路摸清楚的。