Flutter 小技巧之優(yōu)化你使用的 BuildContext

Flutter 里的 BuildContext 相信大家都不會(huì)陌生，雖然它叫 Context，但是它實(shí)際是 Element 的抽象對(duì)象，而在 Flutter 里，它主要來自于 ComponentElement 。

成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供江南網(wǎng)站建設(shè)、江南做網(wǎng)站、江南網(wǎng)站設(shè)計(jì)、江南網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、江南企業(yè)網(wǎng)站模板建站服務(wù)，十余年江南做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

關(guān)于 ComponentElement 可以簡單介紹一下，在 Flutter 里根據(jù) Element 可以簡單地被歸納為兩類：

所以一般情況下，我們?cè)? build 方法或者 State 里獲取到的 BuildContext 其實(shí)就是 ComponentElement 。

那使用 BuildContext 有什么需要注意的問題 ？

首先如下代碼所示，在該例子里當(dāng)用戶點(diǎn)擊 FloatingActionButton 的時(shí)候，代碼里做了一個(gè) 2秒的延遲，然后才調(diào)用 pop 退出當(dāng)前頁面。

正常情況下是不會(huì)有什么問題，但是當(dāng)用戶在點(diǎn)擊了 FloatingActionButton 之后，又馬上點(diǎn)擊了 AppBar 返回退出應(yīng)用，這時(shí)候就會(huì)出現(xiàn)以下的錯(cuò)誤提示。

可以看到此時(shí) log 說，Widget 對(duì)應(yīng)的 Element 已經(jīng)不在了，因?yàn)樵? Navigator.of(context) 被調(diào)用時(shí)， context 對(duì)應(yīng)的 Element 已經(jīng)隨著我們的退出銷毀。

一般情況下處理這個(gè)問題也很簡單， 那就是增加 mounted 判斷，通過 mounted 判斷就可以避免上述的錯(cuò)誤 。

上面代碼里的 mounted 標(biāo)識(shí)位來自于 State ， 因?yàn)? State 是依附于 Element 創(chuàng)建，所以它可以感知 Element 的生命周期 ，例如 mounted 就是判斷 _element != null; 。

那么到這里我們收獲了一個(gè)小技巧： 使用 BuildContext 時(shí)，在必須時(shí)我們需要通過 mounted 來保證它的有效性 。

那么單純使用 mounted 就可以滿足 context 優(yōu)化的要求了嗎 ？

如下代碼所示，在這個(gè)例子里：

由于在 5 秒之內(nèi)，Item 被劃出了屏幕，所以對(duì)應(yīng)的 Elment 其實(shí)是被釋放了，從而由于 mounted 判斷， SnackBar 不會(huì)被彈出。

那如果假設(shè)需要在開發(fā)時(shí)展示點(diǎn)擊數(shù)據(jù)上報(bào)的結(jié)果，也就是 Item 被釋放了還需要彈出，這時(shí)候需要如何處理 ？

我們知道不管是 ScaffoldMessenger.of(context) 還是 Navigator.of(context) ，它本質(zhì)還是通過 context 去往上查找對(duì)應(yīng)的 InheritedWidget 泛型，所以其實(shí)我們可以提前獲取。

所以，如下代碼所示，在 Future.delayed 之前我們就通過 ScaffoldMessenger.of(context); 獲取到 sm 對(duì)象，之后就算你直接退出當(dāng)前的列表頁面，5秒過后 SnackBar 也能正常彈出。

為什么頁面銷毀了，但是 SnackBar 還能正常彈出 ？

因?yàn)榇藭r(shí)通過 of(context); 獲取到的 ScaffoldMessenger 是存在 MaterialApp 里，所以就算頁面銷毀了也不影響 SnackBar 的執(zhí)行。

但是如果我們修改例子，如下代碼所示，在 Scaffold 上面多嵌套一個(gè) ScaffoldMessenger ，這時(shí)候在 Item 里通過 ScaffoldMessenger.of(context) 獲取到的就會(huì)是當(dāng)前頁面下的 ScaffoldMessenger 。

這種情況下我們只能保證Item 不可見的時(shí)候 SnackBar 還能正常彈出， 而如果這時(shí)候我們直接退出頁面，還是會(huì)出現(xiàn)以下的錯(cuò)誤提示，因?yàn)? ScaffoldMessenger 也被銷毀了 。

所以到這里我們收獲第二個(gè)小技巧： 在異步操作里使用 of(context) ，可以提前獲取，之后再做異步操作，這樣可以盡量保證流程可以完整執(zhí)行 。

既然我們說到通過 of(context) 去獲取上層共享往下共享的 InheritedWidget ，那在哪里獲取就比較好 ？

還記得前面的 log 嗎？在第一個(gè)例子出錯(cuò)時(shí)，log 里就提示了一個(gè)方法，也就是 State 的 didChangeDependencies 方法。

為什么是官方會(huì)建議在這個(gè)方法里去調(diào)用 of(context) ？

首先前面我們一直說，通過 of(context) 獲取到的是 InheritedWidget ，而 當(dāng) InheritedWidget 發(fā)生改變時(shí)，就是通過觸發(fā)綁定過的 Element 里 State 的 didChangeDependencies 來觸發(fā)更新， 所以在 didChangeDependencies 里調(diào)用 of(context) 有較好的因果關(guān)系 。

那我能在 initState 里提前調(diào)用嗎 ？

當(dāng)然不行，首先如果在 initState 直接調(diào)用如 ScaffoldMessenger.of(context).showSnackBar 方法，就會(huì)看到以下的錯(cuò)誤提示。

這是因?yàn)?Element 里會(huì)判斷此時(shí)的 _StateLifecycle 狀態(tài)，如果此時(shí)是 _StateLifecycle.created 或者 _StateLifecycle.defunct ，也就是在 initState 和 dispose ，是不允許執(zhí)行 of(context) 操作。

當(dāng)然，如果你硬是想在 initState 下調(diào)用也行，增加一個(gè) Future 執(zhí)行就可以成功執(zhí)行

那我在 build 里直接調(diào)用不行嗎 ？

直接在 build 里調(diào)用肯定可以，雖然 build 會(huì)被比較頻繁執(zhí)行，但是 of(context) 操作其實(shí)就是在一個(gè) map 里通過 key - value 獲取泛型對(duì)象，所以對(duì)性能不會(huì)有太大的影響。

真正對(duì)性能有影響的是 of(context) 的綁定數(shù)量和獲取到對(duì)象之后的自定義邏輯 ，例如你通過 MediaQuery.of(context).size 獲取到屏幕大小之后，通過一系列復(fù)雜計(jì)算來定位你的控件。

例如上面這段代碼，可能會(huì)導(dǎo)致鍵盤在彈出的時(shí)候，雖然當(dāng)前頁面并沒有完全展示，但是也會(huì)導(dǎo)致你的控件不斷重新計(jì)算從而出現(xiàn)卡頓。

所以到這里我們又收獲了一個(gè)小技巧： 對(duì)于 of(context) 的相關(guān)操作邏輯，可以盡量放到 didChangeDependencies 里去處理 。

flutter 基于pageview 制作上下輪播文字功能

先制作一個(gè)縱軸滾動(dòng)的pageview

然后我們利用time組件實(shí)現(xiàn)自動(dòng)輪播，這里面有個(gè)小技巧，掌握了這個(gè)小技巧就可以做無縫的循環(huán)播放，比如我有 a b c三項(xiàng)，我們?cè)跇?gòu)造pageview item的時(shí)候人為的構(gòu)造成a b c a，在c的后面加上a,當(dāng)c滾動(dòng)到a的時(shí)候，比如每次動(dòng)畫變換時(shí)間是500毫秒，那么就延遲500好秒快速的跳到第一個(gè)a頁面，剛好等它滾動(dòng)完就快速變換

在視覺上完全看不出來，這樣就造成了無縫循環(huán)滾動(dòng)的假象，同理如果你想反方向也可以無縫循環(huán)滾動(dòng)，那么你在構(gòu)造pageview item的時(shí)候就可以 這樣c a b c a構(gòu)造,只要控制好邏輯，完全沒有任何問題

Flutter 124: 日常問題小結(jié) (三) 自定義 Dialog 二三事

針對(duì)日常不同的需求，我們時(shí)常需要自定義 Dialog ，而小菜在嘗試過程中遇到一些小問題，簡單記錄總結(jié)一下；

小菜在自定義含有文本框的 Dialog 時(shí)，文本框獲取焦點(diǎn)時(shí)，軟鍵盤會(huì)部分遮擋對(duì)話框，但當(dāng)小菜替換為 AlertDialog 時(shí)，文本框獲取焦點(diǎn)時(shí)，對(duì)話框會(huì)向上浮動(dòng)，避免軟鍵盤遮擋；

對(duì)于含有文本框的自定義 Dialog ，小菜在最外層使用的是 Material 嵌套，小菜通過采用 Scaffold 來嵌套處理，默認(rèn) Scaffold 中 resizeToAvoidBottomPadding / resizeToAvoidBottomInset 為 true ，當(dāng)設(shè)置為 false 時(shí)，文本框獲取焦點(diǎn)時(shí)，依舊會(huì)被軟鍵盤遮擋；因?yàn)樵诠潭ㄇ榫翱梢耘浜? resizeToAvoidBottomPadding 實(shí)現(xiàn)是否被軟鍵盤遮擋效果；

resizeToAvoidBottomPadding 主要用于自身 Widget 是否避免被其他窗口遮擋；其中小菜查資料介紹在 Flutter 1.1.9 之后更推薦使用 resizeToAvoidBottomInset ；

小菜自定義一個(gè)可以多選 item 的 Dialog ，但 Dialog 中并沒有狀態(tài)更新的 State ，如何進(jìn)行 Dialog 中狀態(tài)更新呢？

小菜之前在 showDialog 時(shí)直接創(chuàng)建了 TypeListDialog ，此時(shí)是無狀態(tài)的，當(dāng) WidgetBuilder 創(chuàng)建一個(gè) StatefulBuilder 有狀態(tài)的構(gòu)造器即可，可以將 state 傳遞到 Dialog 中；

小菜在自定義 Dialog 時(shí)如何在一個(gè)回調(diào)方法中傳遞多個(gè)參數(shù)？

小菜在 Dialog 的回調(diào)方法中傳遞兩個(gè) List ，而在接收回調(diào)方法中匹配兩個(gè)參數(shù)即可；小菜簡單看作是一個(gè)函數(shù)方法；

小菜在重寫 AppBar 時(shí)，如何取消默認(rèn)的返回按鈕？

取消 AppBar 前面的返回圖標(biāo)有多種方式；

自定義 Dialog 案例源碼

小菜對(duì)于 Flutter 的應(yīng)用還不夠熟悉，很多常用的場景會(huì)處理的很不到位，小菜會(huì)對(duì)日常的小問題進(jìn)行簡單記錄，逐步學(xué)習(xí)；如有錯(cuò)誤，請(qǐng)多多指導(dǎo)！

標(biāo)題名稱：flutter小技巧,flutter入門教程
瀏覽地址：http://www.chinadenli.net/article16/dsdiidg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供用戶體驗(yàn)、商城網(wǎng)站、Google、網(wǎng)站設(shè)計(jì)、微信小程序、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)