離不開(kāi)DART的Flutter（dart篇）

hello world例子

創(chuàng)新互聯(lián)是網(wǎng)站建設(shè)專(zhuān)家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營(yíng)銷(xiāo)，專(zhuān)業(yè)領(lǐng)域包括網(wǎng)站建設(shè)、網(wǎng)站制作、電商網(wǎng)站制作開(kāi)發(fā)、微信小程序開(kāi)發(fā)、微信營(yíng)銷(xiāo)、系統(tǒng)平臺(tái)開(kāi)發(fā)，與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開(kāi)發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營(yíng)銷(xiāo)的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評(píng)估并優(yōu)化我們的方案，為客戶(hù)提供全方位的互聯(lián)網(wǎng)品牌整合方案！

在終端打印字符串‘Hello World!’

計(jì)算斐波那契數(shù)列

一個(gè)簡(jiǎn)單的類(lèi)

計(jì)算兩點(diǎn)距離

異步并發(fā)示例

使用了Isolate

1.面向?qū)ο?/p>

對(duì)于面向?qū)ο筮@個(gè)概念，相信了解Java的同學(xué)對(duì)這個(gè)概念一定不會(huì)陌生。

例如：我們有個(gè)Person Object他有很多特征和行為。

這些都是這個(gè)Person Object的屬性。

也就是因?yàn)橛辛诉@些特征，行為等等才決定了這個(gè)人是誰(shuí)。

那么回到Dart當(dāng)中，所有的都是對(duì)象，那么在就可以可以跟進(jìn)對(duì)象的屬性的特征，方法等等來(lái)進(jìn)行編程。

之所以我們?cè)谶@里又特別強(qiáng)調(diào)了一下面向?qū)ο蟮母拍睿且驗(yàn)檫@個(gè)概念在Dart語(yǔ)言當(dāng)中，至關(guān)重要！

2.最重要的幾個(gè)概念

3.Dart的部分特性

4.Dart的內(nèi)置庫(kù)

包名

描述

dart:asynv

異步編程，提供Future，Stream類(lèi)

dart：collection

集合

dart：convert

不同類(lèi)型的字符編碼解碼

dart：core

Dart語(yǔ)言核心功能，內(nèi)置類(lèi)型

dart:html

網(wǎng)頁(yè)開(kāi)發(fā)用到的庫(kù)

dart:io

文件讀寫(xiě)，IO相關(guān)

dart:math

數(shù)字常量以及函數(shù)，隨機(jī)算法等

dart:svg

事件和動(dòng)畫(huà)矢量圖支持

綜上述所說(shuō)要想學(xué)Flutter，先學(xué)Dart！關(guān)于Flutter下篇我會(huì)講到。為什么離不開(kāi)dart！

有關(guān)更多面經(jīng)、核心技術(shù)筆記；自己也是從事Android開(kāi)發(fā)5年有余了；整理了一些Android開(kāi)發(fā)技術(shù)核心筆記和面經(jīng)題綱， 如有需要的同學(xué)請(qǐng)私信我回復(fù)“核心筆記”或“面試”領(lǐng)取！

算法題有多重要 | 來(lái)看看Android-Flutter面試親歷者的經(jīng)驗(yàn)總結(jié)

這兩周面試遇到的算法題，都是需要手寫(xiě)實(shí)現(xiàn)，本人算法相當(dāng)菜，面試之前也沒(méi)刷題的概念，所以算法答的很不好，下面只簡(jiǎn)單說(shuō)下都遇到了哪些吧。

該問(wèn)題被問(wèn)到過(guò)三次，應(yīng)該是相當(dāng)高頻的吧，第一次我只想到了下面的第一種方法，面試官很nice，引導(dǎo)著我給出了第二種解決方案

1-2-3-4 交換之后為 2-1-4-3.（基本沒(méi)有寫(xiě)出來(lái)，當(dāng)時(shí)面試官問(wèn)我你沒(méi)刷題嗎，我實(shí)話實(shí)話沒(méi)刷過(guò)）

被問(wèn)到過(guò)兩次，第一次是某公司的技術(shù)負(fù)責(zé)人，人超級(jí)好，我第一中解法用的棧實(shí)現(xiàn)的，然后就問(wèn)我時(shí)間復(fù)雜度和空間復(fù)雜度是多少，還耐心給我講解這兩個(gè)的概念和如何計(jì)算，然后又讓我想第二種解法，第二種我寫(xiě)的是chartAt實(shí)現(xiàn)，面試官又問(wèn)時(shí)間復(fù)雜度和空間復(fù)雜度是多少，然后讓我再想更優(yōu)的解法，最后在面試官的開(kāi)導(dǎo)下寫(xiě)了下面第三種實(shí)現(xiàn)，特感謝這位面試官。

當(dāng)時(shí)大體寫(xiě)出來(lái)了 但是臨界值判斷錯(cuò)了

當(dāng)時(shí)是寫(xiě)出來(lái)了，但是方法很笨，之后去看了下源碼，膜拜啊

就遇到了這五個(gè)算法，其中一個(gè)出現(xiàn)過(guò)三次，一個(gè)出現(xiàn)過(guò)兩次，覺(jué)得自己還是挺幸運(yùn)的吧。希望大家在找工作前多看看算法吧，這個(gè)是面試必問(wèn)的，而且是手寫(xiě)實(shí)現(xiàn)，最近兩天也在看算法，感覺(jué)大神們的想法真的太好了，自己是很難想到這些思路的。

flutter檢測(cè)當(dāng)前剩余的時(shí)間

我想你想要的是：target.difference(DateTime.now()).toString().split('.')[0])

使用.split('.')[0]持續(xù)時(shí)間來(lái)去掉秒的分?jǐn)?shù)。

其中target是DateTime對(duì)象。flutter計(jì)算給定小時(shí)的剩余時(shí)間,以秒為單位更新flutter，因此,時(shí)間以h:m:s為單位,例如,如果給定的時(shí)間是(6:27pm),我希望得到此結(jié)果（剩余時(shí)間02:21:02）。

打印結(jié)果:Text('Timeuntil${DateFormat.Hms().format(target)}');Text(target.difference(DateTime.now()).toString().split('.')[0])

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

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

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

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

那使用 BuildContext 有什么需要注意的問(wèn)題 ？

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

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

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

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

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

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

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

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

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

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

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

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

為什么頁(yè)面銷(xiāo)毀了，但是 SnackBar 還能正常彈出 ？

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

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

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

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

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

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

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

首先前面我們一直說(shuō)，通過(guò) of(context) 獲取到的是 InheritedWidget ，而 當(dāng) InheritedWidget 發(fā)生改變時(shí)，就是通過(guò)觸發(fā)綁定過(guò)的 Element 里 State 的 didChangeDependencies 來(lái)觸發(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 里通過(guò) key - value 獲取泛型對(duì)象，所以對(duì)性能不會(huì)有太大的影響。

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

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

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

2020-05-15 flutter BoxConstraints and layout

在出現(xiàn)布局錯(cuò)誤時(shí)能盡快找到錯(cuò)誤原因。

以下是對(duì)關(guān)鍵內(nèi)容的翻譯和注解。

flutter的布局模型是“一步布局模型”（one-pass layout model），在渲染樹(shù)中，向下treewalk傳遞給子 盒約束，然后再向上treewalk將計(jì)算好的幾何形狀(比如高度、寬度等)傳遞給父。我理解one-pass layout model就是一遍就將布局計(jì)算好。不會(huì)多次treewalk去計(jì)算布局，或多次重繪(repaint)并多次計(jì)算布局。

計(jì)算的好的幾何形狀必須符合盒約束的要求。

盒約束有四個(gè)值，minWidth,maxWidth,minHeight,maxHeight，符合盒約束的意思就是說(shuō) 計(jì)算出的寬高必須在最大值和最小值之間 。

我猜測(cè)，在將盒約束向子傳遞的過(guò)程中，子會(huì)根據(jù)父的盒約束，設(shè)置自己的盒約束，而不是單純的繼承父的盒約束。稍后結(jié)合Flex布局可以解釋。

盒約束的最小值和最大值相等。因此在tight約束下的子的高寬將等于父的高寬，也就是說(shuō)子是緊緊(tight)貼著父的。

盒約束的最小值為0，也就是說(shuō)子可以是小于盒約束最大值的任何值，也就是說(shuō)子是不緊貼(松的，loose)父的。

盒約束的最大值不是infinite(無(wú)窮大)

盒約束的最大值是infinite(無(wú)窮大)

盒約束的最小值是infinite(無(wú)窮大)，他的子的寬或高只能取無(wú)窮大。

子的寬高(Size)符合盒約束的要求。

以下摘抄原文檔并翻譯，并加以分析。為了關(guān)注要點(diǎn)， 忽略crossAxis方向(水平方向)的處理 。

以下圖為Column布局實(shí)例。

給column布局進(jìn)行了以下6步操作

首先給每個(gè)非flex子元素，設(shè)置豎直方向unbounded(無(wú)界)的盒約束。結(jié)合圖片，也就是將1、2兩個(gè)子設(shè)置好豎直方向無(wú)界的盒約束。示例中1和2設(shè)置了高度，因此一共占用高度是5+3=8.

按flex的比例給flex元素分配剩余的空間。因?yàn)槭纠挥幸粋€(gè)flex元素，即3號(hào)元素，因此將占有剩余全部空間，高度是20-5-3 = 12。

在第二步中分配好空間的flex元素，給他設(shè)置的盒約束不是豎直方向unbounded(給非flex元素設(shè)置的是豎直方向unbounded)，而是有界的盒約束，盒約束的maxHeight是12，即第二步中被分配的高度。

水平方向不解釋了。高度設(shè)置完了他去設(shè)置寬度。

Column組件的總高度是由mainAxisSize屬性決定的，如果值是MainAxisSize.max，Column的高度就是Column的盒約束的maxHeight值，示例中我們給Column設(shè)置了高度為20的bounded盒約束，假設(shè)Column.mainAxisSize=MainAxisSize.max,那么Column的高度就是20.如果mainAxisSize=MainAxisSize.min，Column的高度將由其子元素的高度和決定。假設(shè)3號(hào)flex元素不設(shè)置成flex元素，而是固定高度為8，那么Column的高度就是5+3+8=16.

設(shè)置子元素的位置，即設(shè)置靠左，靠右，居中，分散等，與本示例關(guān)系不大。

根據(jù)第一步，inner column被outer column設(shè)置了無(wú)界(unbounded)的盒約束，Column會(huì)緊包c(diǎn)hildren，而inner column的Expanded要撐開(kāi)以占用inner column的剩余空間，這就沖突了。

解決方案:給inner column設(shè)置有界的盒約束即可。比如給inner column外包一層有高度的Container。

下面這種方案，給inner column包一層Expanded也可以，是因?yàn)樵趏uter column中，Expanded會(huì)被設(shè)置成有界的盒約束(結(jié)合第三步)，因此Expanded就可以向外擴(kuò)展(expand)了。

Flutter 疑難雜癥（一）

說(shuō)明：Column中空Text會(huì)占一定空間，會(huì)影響布局效果，這空間大小跟文字設(shè)置的大小有關(guān)；建議用Container，SizedBox來(lái)替換，一般在動(dòng)態(tài)控制一些view的加載會(huì)用到，不需要加載直接返回Container或SizeBox；

說(shuō)明：早期版本sdk Row和Column 默認(rèn)的對(duì)齊參數(shù)MainAxisAlignment和CrossAxisAlignment都為start，現(xiàn)在新版的sdk變化了，CrossAxisAlignment變?yōu)閏enter，所以對(duì)于頻繁使用的 Row和Column，建議寫(xiě)時(shí)添加對(duì)齊方式，不依賴(lài)sdk默認(rèn)，避免升級(jí)sdk大面積修改,也可以直接封裝Row和Column；

說(shuō)明：早期版本sdk字體加粗FontWeight bold為w500，新版本sdk為w700，所以建議封裝FontWeight ，有利于界面樣式統(tǒng)一，封裝如下：

說(shuō)明：

說(shuō)明：

說(shuō)明：

int c;

print(c??=5);//如果c為null的話，把5賦值給c

b ??= value;

如果b為空，則將value賦值給b；否則，b保持不變

expr1 ?? expr2

如果expr1為非空，則返回其值；expr1為空，則計(jì)算并返回expr2的值

易錯(cuò)：

正確：

傳送門(mén)

名稱(chēng)欄目：flutter計(jì)算,flutter介紹
標(biāo)題網(wǎng)址：http://chinadenli.net/article38/dsegppp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、自適應(yīng)網(wǎng)站、網(wǎng)站設(shè)計(jì)、品牌網(wǎng)站制作、網(wǎng)站制作、手機(jī)網(wǎng)站建設(shè)

廣告

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