很多剛開(kāi)始接觸 Flutter 的朋友在看完一堆“Hello World”和基礎(chǔ)組件之后大概率都會(huì)撞上同一堵墻StatefulWidget 里那堆 initState、build、dispose 方法到底什么時(shí)候被調(diào)用為什么順序是那樣在里面到底能干什么、不能干什么說(shuō)實(shí)話(huà)這些知識(shí)點(diǎn)單個(gè)拎出來(lái)都不難但組合在一起就成了很多人對(duì)狀態(tài)管理理解深淺的分水嶺。我最初寫(xiě) Flutter 時(shí)就因?yàn)楦悴磺?build 和 setState 的真正關(guān)系把一個(gè)小小的計(jì)數(shù)器頁(yè)面寫(xiě)出了沒(méi)必要的性能損耗后來(lái)翻文檔、看調(diào)試日志才把這套機(jī)制徹底理順。這篇文章就圍繞 Widget 的一生把 initState、build、dispose 這幾個(gè)關(guān)鍵節(jié)點(diǎn)的調(diào)用時(shí)機(jī)、底層原因、實(shí)戰(zhàn)姿勢(shì)和容易踩的坑一次性講透。適合那些已經(jīng)知道怎么用 StatefulWidget但還想把“為什么”搞清楚的同學(xué)。1. Widget 是“圖紙”不是“房子”為什么 Flutter 要給 StatefulWidget 設(shè)計(jì)生命周期1.1 Flutter 里三棵樹(shù)的“三角關(guān)系”要聊生命周期得先回到一個(gè)最容易被忽略的基礎(chǔ)概念Flutter 的界面并不是“畫(huà)”出來(lái)的而是“配置”出來(lái)的。每當(dāng)你寫(xiě)一個(gè) Widget它并不是屏幕上的真實(shí)像素而是一份描述界面的數(shù)據(jù)這東西更像建筑圖紙。真正負(fù)責(zé)蓋房子、貼瓷磚、刷墻的是 Element 和 RenderObject。Widget輕量、不可變、可以被快速創(chuàng)建和銷(xiāo)毀它只負(fù)責(zé)描述“我想要什么樣的界面”。ElementWidget 在樹(shù)中的實(shí)例化節(jié)點(diǎn)維護(hù)著運(yùn)行時(shí)的狀態(tài)負(fù)責(zé)把 Widget 配置同步到 RenderObject。RenderObject真正執(zhí)行布局和繪制的那一層。這就是 Flutter 里著名的三棵樹(shù)。StatelessWidget 因?yàn)楸旧頉](méi)有需要跨幀保存的狀態(tài)所以它的 Element 相對(duì)簡(jiǎn)單生命周期也就幾句話(huà)講完。但對(duì) StatefulWidget 來(lái)說(shuō)State 對(duì)象需要存活在 Element 上并且跟隨界面狀態(tài)的變化不斷更新那就必須有一套明確規(guī)定好的“出生、成長(zhǎng)、死亡”流程這就是你在文檔里看到的那幾個(gè)方法存在的根本原因。1.2 State 的“戶(hù)口”落在 Element 上很多初學(xué)者會(huì)以為 setState 是“刷新 Widget”其實(shí)嚴(yán)格來(lái)說(shuō)setState 是通知框架“State 里存儲(chǔ)的數(shù)據(jù)發(fā)生了變化需要重新執(zhí)行 build 來(lái)生成一份新的配置”。這份配置依然會(huì)被交給 Element由 Element 去比對(duì)、復(fù)用舊節(jié)點(diǎn)最小化更新底層渲染。理解了這一點(diǎn)你就能明白為什么 initState 和 dispose 在整個(gè)生命周期里只調(diào)用一次而 build 可能被調(diào)用無(wú)數(shù)次。initState 是給 State 對(duì)象上戶(hù)口這意味著每個(gè) State 實(shí)例只有一次初始化機(jī)會(huì)dispose 是注銷(xiāo)戶(hù)口意味著 State 實(shí)例即將被銷(xiāo)毀。而 build 是每次“重新生成配置”的執(zhí)行入口只要配置可能發(fā)生了變化它就會(huì)被再次調(diào)用。1.3 生命周期方法不是“回調(diào)地獄”而是狀態(tài)管理的基石Flutter 之所以把這幾個(gè)方法暴露給開(kāi)發(fā)者本質(zhì)上是在告訴你這是你管理狀態(tài)的安全邊界。在 initState 里框架還沒(méi)完成樹(shù)的構(gòu)建所以你不能依賴(lài)某些上下文信息在 dispose 里框架即將拆除 Element所以你必須把手上的資源交回去。只要按照這套邊界的約束去使用State 的生命周期就是可靠的如果無(wú)視邊界亂操作各種內(nèi)存泄漏、異常崩潰就會(huì)找上門(mén)來(lái)。2. initState初始化邏輯的起點(diǎn)也是最容易踩坑的入口2.1 調(diào)用時(shí)機(jī)State 對(duì)象被創(chuàng)建之后、掛載到樹(shù)上之前很多人背過(guò) initState 的定義當(dāng) State 對(duì)象被插入到渲染樹(shù)時(shí)調(diào)用。但這句話(huà)還可以拆得更細(xì)一點(diǎn)它是在 State 對(duì)象創(chuàng)建完成之后、Element 第一次執(zhí)行 build 之前調(diào)用的。也就是說(shuō)initState 的執(zhí)行早于第一次 build而且在整個(gè) State 的生命周期里只執(zhí)行一次。有個(gè)非常直觀的驗(yàn)證方式在 initState 里打一個(gè) debugPrint然后在 build 里也打一個(gè) debugPrint你會(huì)在控制臺(tái)看到 initState 永遠(yuǎn)先于 build 出現(xiàn)。之后再怎么觸發(fā)刷新initState 都不會(huì)再次打印build 倒是會(huì)頻繁出現(xiàn)。2.2 initState 里應(yīng)該做什么我一般按這三件事來(lái)檢查經(jīng)歷過(guò)幾個(gè)項(xiàng)目之后我給初始化邏輯總結(jié)了一張清單每次寫(xiě)完 initState 都會(huì)對(duì)著過(guò)一遍初始化 State 自己持有的字段。凡是需要在生命周期內(nèi)長(zhǎng)期保存的數(shù)據(jù)比如計(jì)數(shù)器、開(kāi)關(guān)狀態(tài)、列表數(shù)據(jù)容器都可以在這里賦初值。準(zhǔn)備好需要被釋放的資源對(duì)象。比如創(chuàng)建 AnimationController、TextEditingController、FocusNode、ScrollController。這些對(duì)象的特點(diǎn)是創(chuàng)建時(shí)需要持有狀態(tài)銷(xiāo)毀時(shí)也需要顯式釋放所以非常適合在 initState 里創(chuàng)建、在 dispose 里釋放。發(fā)起一些只需要做一次的數(shù)據(jù)準(zhǔn)備操作。例如從本地?cái)?shù)據(jù)庫(kù)讀取初始配置、訂閱一個(gè)流式數(shù)據(jù)源。但要注意這里只能“發(fā)起”不能“阻塞”更不要直接去等結(jié)果。為什么要把“創(chuàng)建可釋放資源”這一項(xiàng)單獨(dú)拿出來(lái)因?yàn)檫@是最容易出問(wèn)題的場(chǎng)景。比如動(dòng)畫(huà)控制器如果不在 initState 里創(chuàng)建而在 build 里每次重建那你需要管理的生命周期就亂套了如果創(chuàng)建了但忘了釋放頁(yè)面關(guān)閉后動(dòng)畫(huà) ticker 還在跑就是一個(gè)實(shí)打?qū)嵉膬?nèi)存泄漏。2.3 initState 里的三個(gè)“不能”initState 的坑主要集中在這三個(gè)方面我把它們當(dāng)成鐵律記著不能在這里調(diào)用 setState。因?yàn)榈谝淮?build 還沒(méi)執(zhí)行State 還沒(méi)有被“渲染”到樹(shù)上所謂刷新根本無(wú)從談起。如果你有初始值要設(shè)置直接改字段就行。不能在這里直接讀取 InheritedWidget 提供的數(shù)據(jù)。原因是 didChangeDependencies 還沒(méi)有被調(diào)用上下文依賴(lài)還沒(méi)有建立。想拿 InheritedWidget 的值去 didChangeDependencies 里拿或者放到 build 里取。不能在這里同步執(zhí)行耗時(shí)操作。比如從磁盤(pán)同步讀取一個(gè)大文件、做復(fù)雜的加密計(jì)算這些都會(huì)卡住 UI 首幀渲染。耗時(shí)的事放到異步里做結(jié)果通過(guò) setState 回來(lái)就好。其中關(guān)于 InheritedWidget 的這條限制尤其容易踩。很多人遇到“在 initState 里拿不到主題、拿不到本地化字符串”的報(bào)錯(cuò)然后一臉茫然。其實(shí)只要記住本來(lái)就不是在這里取的moveOn。2.4 一次真實(shí)的初始化示例下面是一個(gè)我當(dāng)時(shí)做項(xiàng)目時(shí)寫(xiě)過(guò)的代碼結(jié)構(gòu)功能是進(jìn)入頁(yè)面后啟動(dòng)一個(gè)每秒計(jì)數(shù)的定時(shí)器同時(shí)創(chuàng)建兩個(gè)控制器一個(gè)是文本輸入框的一個(gè)是動(dòng)畫(huà)用的class _TimerPageState extends StateTimerPage with SingleTickerProviderStateMixin { int _seconds 0; late Timer _timer; late TextEditingController _textController; late AnimationController _animationController; override void initState() { super.initState(); _textController TextEditingController(); _animationController AnimationController( vsync: this, duration: const Duration(milliseconds: 300), ); _timer Timer.periodic(const Duration(seconds: 1), (timer) { setState(() { _seconds; }); }); } override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: const Text(生命周期演示)), body: Column( children: [ Text(計(jì)時(shí)$_seconds 秒), TextField(controller: _textController), ], ), ); } override void dispose() { _timer.cancel(); _textController.dispose(); _animationController.dispose(); super.dispose(); } }這段代碼有幾個(gè)細(xì)節(jié)值得注意。第一late關(guān)鍵字是為了延遲初始化因?yàn)檫@三個(gè)字段在 initState 里才真正被賦值。第二withSingleTickerProviderStateMixin是在告訴框架這個(gè) State 可以作為一個(gè) vsync 信號(hào)源用于 AnimationController 的 ticker 管理。如果你用了多個(gè)動(dòng)畫(huà)控制器就得換成TickerProviderStateMixin。第三dispose 里三個(gè)資源的釋放順序其實(shí)也有講究先取消定時(shí)器再釋放可能會(huì)回調(diào)的控制器最后釋放動(dòng)畫(huà)控制器。雖然 Flutter 對(duì)釋放順序沒(méi)有強(qiáng)制規(guī)定但我習(xí)慣把“更可能觸發(fā)異步回調(diào)”的資源放在前面釋放把純本地的資源放在最后釋放。3. buildFlutter 里被誤解最深的“畫(huà)圖”方法3.1 build 不是畫(huà)圖而是生成新配置很多剛從 Android 或者 Web 轉(zhuǎn)過(guò)來(lái)的同學(xué)會(huì)下意識(shí)地把 build 和“繪制”“渲染”畫(huà)等號(hào)覺(jué)得只要刷新界面系統(tǒng)就要重新畫(huà)一幀。這個(gè)理解偏差會(huì)直接導(dǎo)致性能上的一堆壞習(xí)慣。實(shí)際情況是build 方法返回的是一個(gè) Widget 樹(shù)這套 Widget 樹(shù)是“新配置”。Flutter 拿到新配置之后會(huì)交給 Element 去做 diff看舊的節(jié)點(diǎn)和新的節(jié)點(diǎn)能不能復(fù)用。如果能復(fù)用只需要更新差異部分底層渲染對(duì)象并不會(huì)重畫(huà)如果節(jié)點(diǎn)類(lèi)型變了才會(huì)銷(xiāo)毀舊的 Element 并創(chuàng)建新的。所以build 的調(diào)用頻率遠(yuǎn)沒(méi)有“每幀重畫(huà)”那么恐怖。Flutter 只在某些特定時(shí)機(jī)才執(zhí)行 buildState 首次掛載到樹(shù)上。setState 被調(diào)用之后。依賴(lài)的 InheritedWidget 數(shù)據(jù)發(fā)生了變化。父 Widget 重建并且子 Widget 的配置發(fā)生了變化。其中最后一條想多提一句。父 Widget build 的時(shí)候會(huì)連帶調(diào)用子 Widget 的 build這是 Flutter 的默認(rèn)行為也是性能問(wèn)題的高發(fā)區(qū)。如果父 Widget 只是布局信息變了子 Widget 完全不必重新生成配置那你還得配合const構(gòu)造、或者用shouldRebuild之類(lèi)的優(yōu)化手段去阻止無(wú)意義的 rebuild。3.2 build 方法里的大忌清單為了避免把 build 寫(xiě)成性能殺手我給自己定了一組禁令不要在 build 里發(fā)起網(wǎng)絡(luò)請(qǐng)求。網(wǎng)絡(luò)請(qǐng)求的響應(yīng)是異步的結(jié)果回來(lái)之后還得 setState而 setState 又可能再次觸發(fā) build。如果在 build 里直接發(fā)請(qǐng)求就等于每次構(gòu)建都發(fā)一次頁(yè)面還沒(méi)人等數(shù)據(jù)刷新就先把服務(wù)器轟炸了。不要在 build 里做耗時(shí)計(jì)算。包括大量列表項(xiàng)的排序過(guò)濾、大字符串拼接、圖片解碼。這些計(jì)算應(yīng)該提前算好把結(jié)果存到 State 的字段里build 只負(fù)責(zé)讀取展示。不要在 build 里修改 State 字段。這一點(diǎn)很容易被忽視。比如在 build 里做_count然后 lay out 時(shí)依賴(lài)_count就可能出現(xiàn)渲染結(jié)果不確定的問(wèn)題嚴(yán)重的還會(huì)陷入無(wú)限重建循環(huán)。不要無(wú)腦在 build 里創(chuàng)建昂貴的對(duì)象。像重復(fù)創(chuàng)建同一個(gè)TextStyle其實(shí)開(kāi)銷(xiāo)不大但如果你在 build 里創(chuàng)建AnimationController這類(lèi)帶生命周期對(duì)象那問(wèn)題就大了。我把這幾條禁令和之前提到的 initState 結(jié)合著用了所有“需要保持長(zhǎng)期存活”的對(duì)象一律在 initState 里創(chuàng)建所有“臨時(shí)計(jì)算結(jié)果”盡量提前算好build 里只做 Widget 配置的組裝。3.3 一個(gè) build 性能問(wèn)題的調(diào)試思路曾經(jīng)有個(gè)頁(yè)面列表滾動(dòng)的時(shí)候明顯卡頓。我用性能分析工具看了眼發(fā)現(xiàn) build 被調(diào)用的頻率沒(méi)有異常但 build 方法內(nèi)部每次都把一個(gè)幾百長(zhǎng)度的 JSON 字符串jsonDecode了一遍用來(lái)生成 ListView 的數(shù)據(jù)。問(wèn)題就在這里明明數(shù)據(jù)在 initState 里拿過(guò)一次卻因?yàn)閳D省事把它塞到了 build 里。后來(lái)我把 JSON 解析挪到 initState 里解析結(jié)果存進(jìn) State 字段build 里只做_listData.map(...)組裝 Widget 列表卡頓立刻消失。這不是 Flutter 的坑而是對(duì) build 機(jī)制理解不到位造成的自傷。每次想復(fù)用時(shí)我都拿這個(gè)例子提醒自己。3.4 build 與 const 優(yōu)化的關(guān)系你會(huì)在很多 Flutter 代碼里看到 const Widget比如const Text(你好)。const 在這里的意思是這個(gè) Widget 配置在編譯期就是常量永遠(yuǎn)不會(huì)變化。這樣一來(lái)Element 比對(duì)的時(shí)候可以直接復(fù)用節(jié)點(diǎn)連新配置都不需要生成。養(yǎng)成隨手加 const 的習(xí)慣可以在很大程度降低 build 方法的消耗這在大型頁(yè)面里的收益非常明顯。4. dispose收尾工序里漏掉的每一處最后都會(huì)變成泄漏4.1 什么時(shí)候觸發(fā) disposeState 要從樹(shù)上被移走了dispose 是 State 生命周期里的最后一站代表這個(gè) State 對(duì)象即將被永久銷(xiāo)毀之后不會(huì)再有機(jī)會(huì)執(zhí)行任何代碼。最常見(jiàn)的觸發(fā)場(chǎng)景是頁(yè)面被 pop 出棧、列表里的某個(gè)子項(xiàng)在條件渲染中被移除、或者整個(gè)頁(yè)面被系統(tǒng)回收。這里有個(gè)容易搞錯(cuò)的點(diǎn)deactivate 和 dispose 不一樣。deactivate 是在 State 被暫時(shí)從樹(shù)上移除、但還有可能被重新插入時(shí)調(diào)用比如列表項(xiàng)在 key 調(diào)整時(shí)移動(dòng)位置。dispose 則意味著徹底結(jié)束。所以如果你在處理的是“臨時(shí)離開(kāi)”的場(chǎng)景應(yīng)該考慮的是 deactivate 的邏輯而不是把資源在 deactivate 里就全釋放掉。4.2 dispose 必須釋放的東西我列了個(gè)表就我自己的項(xiàng)目經(jīng)驗(yàn)來(lái)看下面這些資源如果在 dispose 里沒(méi)處理干凈后續(xù)大概率出問(wèn)題資源類(lèi)型典型對(duì)象不釋放的后果定時(shí)器Timer、Timer.periodic頁(yè)面銷(xiāo)毀后仍觸發(fā)回調(diào)setState 報(bào)錯(cuò)或做無(wú)用功動(dòng)畫(huà)控制器AnimationControllerTicker 持續(xù)運(yùn)行內(nèi)存泄漏甚至導(dǎo)致系統(tǒng)丟幀文本控制器TextEditingController輸入框銷(xiāo)毀后監(jiān)聽(tīng)器仍然存活狀態(tài)殘留滾動(dòng)控制器ScrollController列表移除后監(jiān)聽(tīng)還在內(nèi)存泄漏焦點(diǎn)節(jié)點(diǎn)FocusNode焦點(diǎn)狀態(tài)無(wú)法回收數(shù)據(jù)流訂閱StreamSubscription后臺(tái)持續(xù)收到數(shù)據(jù)無(wú)法取消監(jiān)聽(tīng)自定義監(jiān)聽(tīng)ChangeNotifier 的 addListener頁(yè)面銷(xiāo)毀后仍然收到通知這張表我建議直接保存下來(lái)。每寫(xiě)一個(gè)帶資源的 State把表拿出來(lái)對(duì)照一遍你就能避免 90% 以上的生命周期泄漏問(wèn)題。4.3 mounted 到底是什么為什么要用它dispose 做完之后State 對(duì)象并沒(méi)有馬上被垃圾回收它可能還會(huì)在異步代碼里被引用。如果你在異步回調(diào)里寫(xiě)了setState而此時(shí) State 已經(jīng)被 dispose 了Flutter 會(huì)直接拋出一個(gè)異常setState() called after dispose()。這時(shí)候就需要mounted這個(gè)屬性派上用場(chǎng)了。mounted 表示當(dāng)前 State 是否還附著在 Element 樹(shù)上。正確的姿勢(shì)是在異步回調(diào)里先判斷 mounted再?zèng)Q定要不要 setState_timer Timer.periodic(const Duration(seconds: 1), (timer) { if (mounted) { setState(() { _seconds; }); } });看起來(lái)就是多了一個(gè)判斷但在頁(yè)面銷(xiāo)毀后它可以幫你避免大量無(wú)意義的異常。同樣在 build 里拿 context 做異步操作時(shí)回調(diào)里也要加 mounted 保護(hù)道理是一樣的。4.4 dispose 里訪問(wèn) context 的隱患dispose 階段State 的 context 已經(jīng)從樹(shù)上拆下來(lái)了此時(shí)如果你還嘗試用這個(gè) context 去做 Navigator 跳轉(zhuǎn)、顯示 SnackBar都可能觸發(fā)異常。有個(gè)常見(jiàn)場(chǎng)景用戶(hù)點(diǎn)返回鍵退出登錄頁(yè)登錄頁(yè)的 dispose 里判斷“如果登錄成功了就跳轉(zhuǎn)主頁(yè)面”這明顯是設(shè)計(jì)錯(cuò)誤。正確做法是在頁(yè)面切走之前用能用的 context 完成必要操作dispose 只負(fù)責(zé)資源的收尾。5. 串起全過(guò)程一個(gè)帶定時(shí)器頁(yè)面的完整生命周期時(shí)間線5.1 從路線入棧開(kāi)始一步步跟蹤 State 的運(yùn)行軌跡理論說(shuō)了這么多不如走一遍完整的執(zhí)行流程。假設(shè)你有一個(gè)頁(yè)面打開(kāi)時(shí)有計(jì)時(shí)器中間有文本框用戶(hù)能點(diǎn)擊按鈕加計(jì)數(shù)然后關(guān)閉頁(yè)面。我們從頁(yè)面被 push 進(jìn)導(dǎo)航棧的那一刻開(kāi)始跟蹤。第一步Navigator 構(gòu)造這個(gè)頁(yè)面的 Widget 樹(shù)。Widget 本身被創(chuàng)建State 對(duì)象也被創(chuàng)建但此時(shí)還沒(méi)有上樹(shù)。緊接著 Element 掛載State 被插入到 Element 上此時(shí) initState 被調(diào)用。在這個(gè)例子里我們創(chuàng)建了 Timer、TextEditingController、AnimationController并初始化_seconds 0。第二步initState 返回后框架調(diào)用 didChangeDependencies。如果有對(duì) InheritedWidget 的依賴(lài)這是第一次能安全獲取依賴(lài)數(shù)據(jù)的地方。之后框架馬上調(diào)用 build生成第一幀的 Widget 配置。這一次 build 里我們組裝了包含計(jì)時(shí)文本、文本框、按鈕的界面。第三步用戶(hù)點(diǎn)了一下按鈕調(diào)用 setState?？蚣馨l(fā)現(xiàn)這個(gè) State 需要重建于是再次調(diào)用 build生成新的配置。舊的 Widget 配置被丟棄Element 更新差異部分界面上計(jì)數(shù)數(shù)字變化。第四步計(jì)時(shí)器每秒觸發(fā)一次每次都執(zhí)行同樣的流程setState - build - 局部更新。這一幀一幀的構(gòu)建只要頁(yè)面還在就會(huì)持續(xù)進(jìn)行。第五步用戶(hù)按了返回鍵導(dǎo)航棧把頁(yè)面彈出。此時(shí) State 從樹(shù)上被移除先觸發(fā) deactivate。如果這個(gè) State 之后沒(méi)有通過(guò)某種機(jī)制被重新插入緊跟著就是 dispose。我們?cè)?dispose 里取消定時(shí)器、銷(xiāo)毀所有控制器State 生命周期正式結(jié)束。5.2 為什么我推薦用日志驗(yàn)證生命周期順序光靠看文章還是不夠我強(qiáng)烈建議你自己動(dòng)手驗(yàn)證一次。在 initState、didChangeDependencies、build、didUpdateWidget、deactivate、dispose 里各打一個(gè) debugPrint然后做各種操作觀察日志順序。這個(gè)方法花不了幾分鐘卻能讓這套機(jī)制像肌肉記憶一樣長(zhǎng)在腦子里。有一次我就是靠日志發(fā)現(xiàn)了一個(gè)詭異問(wèn)題頁(yè)面明明還在屏幕上dispose 卻已經(jīng)被調(diào)用了。一查原來(lái)是父組件在某種布局條件下把子頁(yè)面從樹(shù)里刪掉了但從導(dǎo)航角度看頁(yè)面還在棧頂所以看起來(lái)“頁(yè)面沒(méi)關(guān)State 沒(méi)了”。這類(lèi)問(wèn)題在生命周期混亂的史前項(xiàng)目里特別常見(jiàn)先別急著噴框架日志會(huì)告訴你真相。5.3 didUpdateWidget 和 didChangeDependencies 的補(bǔ)充位置雖然這篇文章重點(diǎn)在 initState、build、dispose但完整時(shí)間線里另外兩個(gè)方法也應(yīng)該知道它們的位置。didUpdateWidget 在父 Widget 重建導(dǎo)致子 Widget 配置變化時(shí)調(diào)用如果你需要對(duì)比新舊 widget 配置差異來(lái)執(zhí)行額外邏輯就在這里寫(xiě)。didChangeDependencies 則是在 initState 之后、以及依賴(lài)的 InheritedWidget 變化時(shí)被調(diào)用。記住一句話(huà)initState 和 dispose 是出生和死亡build 是常駐循環(huán)而 didUpdateWidget 和 didChangeDependencies 是圍繞“依賴(lài)變化”的前后呼應(yīng)。6. 生命周期相關(guān)的常見(jiàn)崩潰、卡頓與內(nèi)存泄漏排查清單6.1 高頻問(wèn)題對(duì)照表按癥狀定位根因我根據(jù)自己的踩坑經(jīng)歷和帶新人時(shí)的經(jīng)驗(yàn)整理了一張對(duì)照表。遇到生命周期相關(guān)的問(wèn)題按表排查比重新翻所有代碼快得多。癥狀描述可能原因處理方法setState() called after dispose()異步回調(diào)未判斷 mounted在回調(diào)里先檢查 mounted再 setState頁(yè)面關(guān)閉后定時(shí)器還在跑Timer 沒(méi)在 dispose 里 cancel在 dispose 里逐一定時(shí)器 cancel動(dòng)畫(huà)結(jié)束后報(bào) Ticker 異常AnimationController 未 dispose釋放所有 controller確認(rèn) mixin 類(lèi)型輸入框內(nèi)容丟失但頁(yè)面內(nèi)存暴漲TextEditingController 未釋放在 dispose 里銷(xiāo)毀 controller列表滾動(dòng)后頁(yè)面卡頓build 里有耗時(shí)計(jì)算或?qū)ο髣?chuàng)建把計(jì)算提到 initStatebuild 只組裝initState 里拿不到主題或本地化試圖在 initState 讀取 InheritedWidget移到 didChangeDependencies 或 build頁(yè)面關(guān)閉后控制臺(tái)不斷有數(shù)據(jù)流日志StreamSubscription 未取消在 dispose 里 cancel 所有訂閱Widget 和 State 對(duì)不上界面錯(cuò)亂列表項(xiàng)缺少 keyState 被錯(cuò)誤復(fù)用給列表項(xiàng)加上唯一 key這張表治標(biāo)但更重要的是治本也就是養(yǎng)成“創(chuàng)建資源和釋放資源成對(duì)出現(xiàn)”的潛意識(shí)。每次在 initState 里 new 出來(lái)一個(gè)對(duì)象順手在 dispose 里補(bǔ)上對(duì)應(yīng)的 dispose 調(diào)用寫(xiě)完代碼自查一遍比事后排查效率高得多。6.2 Flutter DevTools 的檢查方法如果項(xiàng)目已經(jīng)出現(xiàn)了疑似泄漏別靠肉眼看代碼硬猜。建議打開(kāi) Flutter DevTools 的 Memory 頁(yè)面利用里面的 Heap Snapshot 功能查看頁(yè)面銷(xiāo)毀后是否還有對(duì)應(yīng)對(duì)象的實(shí)例持有。凡是生命周期沒(méi)收干凈的資源基本上都會(huì)在這里現(xiàn)出原形。更簡(jiǎn)單粗暴的辦法是你在關(guān)鍵生命周期方法里加日志然后反復(fù)打開(kāi)、關(guān)閉同一個(gè)頁(yè)面觀察日志是否每次都成對(duì)出現(xiàn)。正常情況應(yīng)該是一對(duì)一的initState 一次對(duì)應(yīng) dispose 一次中間 build 的次數(shù)隨意。如果 initState 出現(xiàn)兩次而 dispose 只有一次那多半就是 State 被重新創(chuàng)建而沒(méi)有銷(xiāo)毀重點(diǎn)去找那些沒(méi)有 key 的列表項(xiàng)或者被錯(cuò)誤緩存的頁(yè)面。6.3 我踩過(guò)的最隱蔽的一個(gè)坑Timer 回調(diào)和 BuildContext最后分享一個(gè)我自己翻車(chē)過(guò)的問(wèn)題。某個(gè)頁(yè)面的定時(shí)器在每次回調(diào)時(shí)都要用 State 里的 context 去更新一個(gè)進(jìn)度條。頁(yè)面還在的時(shí)候一切正常但用戶(hù)一旦快速退出頁(yè)面Timer 還沒(méi)來(lái)得及 cancel回調(diào)先一步觸發(fā)了 setState然后就崩了。我當(dāng)時(shí)第一反應(yīng)是加 mounted 判斷加了之后確實(shí)不崩了但定時(shí)器還沒(méi)取消等于每秒鐘都在做一個(gè)毫無(wú)意義的空回調(diào)白白耗電。那個(gè)坑給我的教訓(xùn)是mounted 判斷只能保證“不報(bào)錯(cuò)”不能替代“資源釋放”。真正該做的是在 dispose 里及時(shí) cancel而不是依賴(lài) mounted 去兜底。后來(lái)我再寫(xiě)定時(shí)器相關(guān)的邏輯都會(huì)保持一個(gè)習(xí)慣dispose 里先取消一切異步源再釋放所有 controller最后調(diào)用 super.dispose。最后再分享一個(gè)小技巧如果你跟我一樣經(jīng)常在幾個(gè)頁(yè)面之間來(lái)回復(fù)制初始化代碼可以考慮給自己定一個(gè)“生命周期三件套”檢查習(xí)慣寫(xiě)完 initState接著寫(xiě) dispose再看 build 里有沒(méi)有不該出現(xiàn)的東西。這不是什么高深的工程規(guī)范只是防呆措施。我在實(shí)際項(xiàng)目里就是靠這個(gè)習(xí)慣把排查生命周期問(wèn)題的時(shí)間縮短了至少一半。等你把這個(gè)節(jié)奏融入到肌肉記憶里再看那些“偶發(fā)崩潰”“頁(yè)面卡頓”“內(nèi)存暴漲”你會(huì)發(fā)現(xiàn)自己已經(jīng)能第一時(shí)間猜到是哪類(lèi)原因了。