在過(guò)去的24個(gè)月中，我們花費(fèi) 17.193,00 個(gè)小時(shí)使用 Flutter 完成了10個(gè)商業(yè)應(yīng)用程序，本文將分享我們的見(jiàn)解。

閱讀本文后，您將學(xué)習(xí)到：

• 選擇Flutter的原因是什么？ Flutter對(duì)預(yù)算和穩(wěn)定性有什么影響？
• Flutter準(zhǔn)備好用于企業(yè)應(yīng)用程序了嗎？
• 與Xamarin相比，F(xiàn)lutter的表現(xiàn)如何？
• Flutter適合哪些項(xiàng)目？

[[344070]]

自2018年7月在LeanCode上開(kāi)始在Flutter上開(kāi)發(fā)我們的第一個(gè)商業(yè)應(yīng)用程序以來(lái)，到現(xiàn)在已經(jīng)有兩年了，當(dāng)我第一次了解Flutter時(shí)，盡管它很有前景，但我仍然持懷疑態(tài)度，主要是因?yàn)槲覀冏罱鼘?duì)Xamarin的投資給我們帶來(lái)了負(fù)面體驗(yàn)。 由于我們的團(tuán)隊(duì)一直希望在項(xiàng)目中使用一些激動(dòng)人心的新技術(shù)，因此我們希望它能夠證明它能給客戶帶來(lái)真正的價(jià)值。

這是一個(gè)農(nóng)業(yè)項(xiàng)目，與牧群管理打交道，這是一個(gè)非常有趣而且典型的項(xiàng)目，管理員使用該系統(tǒng)來(lái)計(jì)算對(duì)谷倉(cāng)的需求，而我們的團(tuán)隊(duì)認(rèn)為，從UX的角度來(lái)看，這是一個(gè)很好的見(jiàn)解。

在兩天內(nèi)，他們自豪地展示了概念驗(yàn)證方案，證明了制作動(dòng)畫(huà)非常容易，可以為您帶來(lái)出色而流暢的體驗(yàn)。最終，這已演變?yōu)橥暾壤膭?dòng)畫(huà)，您可以在此處看到：

有了這個(gè)喜悅，我確信Flutter值得嘗試。

最初，我們沒(méi)有將自己100％投入Flutter，而是與 React Native 項(xiàng)目并行進(jìn)行。在沒(méi)有Flutter團(tuán)隊(duì)官方支持的情況下編寫(xiě)第一個(gè)Google Maps實(shí)現(xiàn)，對(duì)此我感到悲觀。您可以在https://leancode.pl/case-studies/kezia-app 了解有關(guān)在Flutter中編寫(xiě)第一個(gè)商業(yè)應(yīng)用程序的經(jīng)驗(yàn)以及相關(guān)困難的更多信息。最終，我們交付的是一個(gè)相對(duì)簡(jiǎn)單的應(yīng)用程序，少于40個(gè)視圖，且Flutter開(kāi)發(fā)時(shí)間不到500小時(shí)。

自從我們交付了第一個(gè)應(yīng)用程序并從客戶那里收集到了五星級(jí)好評(píng)，我們認(rèn)為，我們應(yīng)該開(kāi)始更加積極地向客戶推薦Flutter。從2019年5月開(kāi)始，我們決定Flutter將是我們移動(dòng)技術(shù)的第一選擇。同時(shí)，我們將停止在其他不同框架上開(kāi)發(fā)應(yīng)用程序的工作。

自那時(shí)以來(lái)，我們已經(jīng)在Flutter中交付了10多種移動(dòng)產(chǎn)品，并提供了數(shù)十種MVP / PoC?，F(xiàn)在，該得出結(jié)論了。

Flutter 更快

我們并未在這里討論理論方法（在此處可以查找https://blog.codemagic.io/flutter-vs-ios-android-reactnative-xamarin/  ），盡管這也很有趣。后來(lái)我們重寫(xiě)了基于 Xamarin 和 ReactJS 的App，將二者進(jìn)行對(duì)比，在后端使用相同API的情況下，與Xamarin（667h vs 987h）相比，我們減少了33％的時(shí)間，使用ReactJS（486h vs 704h）相比，則減少了31％的時(shí)間。

停下來(lái)思考一下這些數(shù)字。這些數(shù)據(jù)回答了如何更快，更便宜地構(gòu)建移動(dòng)應(yīng)用程序（使用Flutter）。隨著經(jīng)濟(jì)不景氣，在預(yù)算范圍內(nèi)按時(shí)交付產(chǎn)品變得越來(lái)越重要。這也意味著對(duì)于相同的預(yù)算，您可以多交付50％的訂單。想象一下，您是一名產(chǎn)品負(fù)責(zé)人，負(fù)責(zé)開(kāi)發(fā)團(tuán)隊(duì)的優(yōu)先事項(xiàng)，能夠?qū)㈩A(yù)算壁壘進(jìn)一步提高50％。

這將極大地提高團(tuán)隊(duì)的創(chuàng)造力和他們交付的工作質(zhì)量。有關(guān)GastroJob案例的詳細(xì)分析，請(qǐng)查看我們?cè)?nbsp;Flutter Europe Conference 上的演講，或在https://leancode.pl/case-studies/gastrojob 上查看我們的案例研究。

平均90％的代碼在iOS和Android之間共享。

我們的90％的代碼不會(huì)在兩個(gè)本機(jī)平臺(tái)上都編寫(xiě)兩次。與本地應(yīng)用程序開(kāi)發(fā)相比，節(jié)省了90％的時(shí)間，并且由于一致性和團(tuán)隊(duì)圍繞一個(gè)目標(biāo)團(tuán)結(jié)而不是分成兩個(gè)本地流，因此釋放了很多創(chuàng)造力。除了共享業(yè)務(wù)邏輯和用戶體驗(yàn)外，我們還可以使用大量現(xiàn)成的庫(kù)，這些庫(kù)帶來(lái)了更多的好處。首先，他們可以通過(guò)為應(yīng)用程序內(nèi)使用的許多不同事物提供常用邏輯來(lái)加快開(kāi)發(fā)過(guò)程（例如與服務(wù)器（HTTP客戶端）的通信，推送通知，安全存儲(chǔ)，數(shù)據(jù)庫(kù)，動(dòng)畫(huà)等）。其次，與許多流行的服務(wù)（例如Firebase，地圖，支付，社交登錄，分析，崩潰報(bào)告服務(wù)等）集成起來(lái)更加容易。因此，只有在編寫(xiě)特定于平臺(tái)的自定義代碼時(shí)，才需要編寫(xiě)兩次代碼（分別適用于iOS和Android）。但是，即使那樣，在Dart和本機(jī)代碼之間進(jìn)行橋接還是相當(dāng)合理的 簡(jiǎn)單，這將在本文后面進(jìn)行解釋。

更重要的是，如果考慮到質(zhì)量因素，則可以節(jié)省更多，因此從長(zhǎng)遠(yuǎn)來(lái)看，該應(yīng)用程序的維護(hù)成本也更低。事實(shí)上，我們研究在Xamarin，React Native和Flutter構(gòu)建的所有項(xiàng)目中修復(fù)bug的時(shí)間，，F(xiàn)lutter通常需要8–10％的修復(fù)bug時(shí)間。而 React Native 需要7–14％，Xamarin 需要11–23％。

與UX / UI的合作從未如此之好

在Flutter項(xiàng)目期間，需要UX / UI設(shè)計(jì)師和開(kāi)發(fā)人員之間進(jìn)行合作?？赡苁且?yàn)樗麄儾恍枰M(jìn)行這種乏味的本地改編，而使他們的創(chuàng)造力松散。但是，從React Native團(tuán)隊(duì)的經(jīng)驗(yàn)中也可以期望得到同樣的結(jié)果，事實(shí)并非如此。當(dāng)我們更深入地挖掘時(shí)，我們發(fā)現(xiàn)Flutter為能夠編寫(xiě)漂亮界面的開(kāi)發(fā)人員帶來(lái)了純粹的歡樂(lè)，以前這些界面會(huì)帶來(lái)額外的負(fù)擔(dān)，從而減慢了步伐。因此，他們更愿意合作，并且我們已經(jīng)看到結(jié)對(duì)編程會(huì)議開(kāi)始于設(shè)計(jì)師與開(kāi)發(fā)人員攜手進(jìn)行現(xiàn)場(chǎng)實(shí)驗(yàn)的過(guò)程中。經(jīng)過(guò)幾次這樣的互動(dòng)，得益于強(qiáng)大的主題引擎，團(tuán)隊(duì)能夠?yàn)樵搼?yīng)用程序提供一種自適應(yīng)的設(shè)計(jì)語(yǔ)言，該語(yǔ)言不僅在Figma或Adobe XD中看起來(lái)很棒，而且還提供了最佳的用戶體驗(yàn)以及連貫的感覺(jué)。正確的設(shè)計(jì)順序。怎么樣 在項(xiàng)目的整個(gè)生命周期中保持這種連貫性也很有趣。 以前，當(dāng)UX / UI設(shè)計(jì)師在演示會(huì)議上審查產(chǎn)品時(shí)，他們?cè)陧?xiàng)目結(jié)束時(shí)擁有大部分評(píng)論，在實(shí)踐經(jīng)驗(yàn)之后改變主意或簡(jiǎn)化事情。 Flutter的獨(dú)特之處在于，在項(xiàng)目結(jié)束時(shí)，設(shè)計(jì)師的參與已完全消失，因?yàn)樗麄冊(cè)谠囼?yàn)和錯(cuò)誤的設(shè)計(jì)循環(huán)的初期就開(kāi)始工作。 這也意味著后續(xù)sprint的優(yōu)化花費(fèi)的時(shí)間更少，并且這種持續(xù)的合作體現(xiàn)在下一個(gè)發(fā)行版的穩(wěn)定Scrum速度上。

動(dòng)畫(huà)是如此的簡(jiǎn)單和實(shí)惠

在Flutter中實(shí)現(xiàn)靜態(tài)視圖不僅容易，而且在動(dòng)畫(huà)方面也提供了許多新的機(jī)會(huì)。這將這種UX-DEV的合作推向了新的高度，從而實(shí)現(xiàn)了前所未有的出色過(guò)渡效果。到目前為止，這僅對(duì)大型預(yù)算項(xiàng)目而言是典型的。如今，感謝Flutter，所有開(kāi)發(fā)人員都可以使用它。之所以會(huì)發(fā)生這種情況，是因?yàn)镕lutter可以直接在畫(huà)布上進(jìn)行渲染，并且可以完全控制圖形，這使我們能夠在所有平臺(tái)上創(chuàng)建像素完美的圖像，而無(wú)需像其他跨平臺(tái)框架一樣進(jìn)行附加的條件格式設(shè)置。例如，在使用React Native進(jìn)行繪制時(shí)，您基于默認(rèn)視圖，這些視圖可以改變新控件的外觀，因此，構(gòu)建了一個(gè)臭代碼，該代碼依賴于平臺(tái)，并且與共享代碼不應(yīng)采用的方法直接矛盾進(jìn)入部署平臺(tái)。

Flutter應(yīng)用程序更輕巧

面對(duì)PWA業(yè)務(wù)選擇時(shí)，PWA證明了在手機(jī)上添加快捷方式來(lái)像保存應(yīng)用程序一樣保存網(wǎng)站是多么容易。我們先不討論用戶體驗(yàn)，而只考慮下載應(yīng)用程序的負(fù)擔(dān)。是的，在兩種情況下都并非易事。根據(jù)SimiCart博客，最佳PWA網(wǎng)站要求用戶在加載時(shí)從4.9MB到11.6MB。這遠(yuǎn)遠(yuǎn)低于我們的Xamarin應(yīng)用程序的平均大小25MB，甚至低于我們的React Native 32MB應(yīng)用程序的平均大小，但非常接近Flutter的平均值11MB，所有Flutter應(yīng)用程序的范圍為9-14MB （請(qǐng)注意，盡管這些數(shù)字突出顯示了模式，但它們不能直接比較）。您必須承認(rèn)，對(duì)于本機(jī)應(yīng)用程序體驗(yàn)，平滑的外觀，快速的反應(yīng)以及本機(jī)應(yīng)用程序典型的所有服務(wù)（例如推送通知）而言，此（11MB）的空間非常低。這意味著沒(méi)有障礙。 用戶下載該應(yīng)用程序，并開(kāi)始與所有插件和集成一起盡可能高效地使用它。 這也意味著應(yīng)用程序性能更高，因?yàn)樗鼈兛梢允褂幂^小的代碼執(zhí)行類似的任務(wù)。 與其他跨平臺(tái)框架相比，這種性能上的提升直接轉(zhuǎn)化為毫秒數(shù)，從而為您提供了較冷的應(yīng)用程序，動(dòng)畫(huà)，CPU和內(nèi)存使用方面的更快體驗(yàn)（實(shí)際上，在Flutter可以提供更好的冷啟動(dòng)應(yīng)用程序的情況下，即使相比 到Swift / Kotlin本機(jī)應(yīng)用程序）。

需要時(shí)可以訪問(wèn)本機(jī)代碼。

Flutter的優(yōu)點(diǎn)在于，移動(dòng)團(tuán)隊(duì)更希望使用本機(jī)代碼并編寫(xiě)一些Kotlin / Swift軟件包，因?yàn)樗鼈兛梢酝耆刂票緳C(jī)實(shí)現(xiàn)，而Xamarin就是這種情況最終代碼在一個(gè)孤立的黑匣子中生成。到本機(jī)代碼的橋也更強(qiáng)大，因?yàn)樗鼈兪峭耆该鞯?，因此?duì)于從本機(jī)環(huán)境轉(zhuǎn)移過(guò)來(lái)的開(kāi)發(fā)人員來(lái)說(shuō)更友好。由于采用了這種方法，因此可以輕松實(shí)現(xiàn)特定功能，例如本地支付提供商或一些復(fù)雜的庫(kù)。更重要的是，即使是需要生物特征識(shí)別算法進(jìn)行面部識(shí)別或指紋檢查的高級(jí)功能，也可以在Flutter上順利運(yùn)行，這是由ING商業(yè)在Flutter中開(kāi)發(fā)的銀行應(yīng)用程序展示的，該應(yīng)用程序是在JakubBiliński在Flutter Warsaw Meetup上展示的。

Flutter中的概念非常簡(jiǎn)單

當(dāng)我們需要構(gòu)建概念證明以檢查最危險(xiǎn)的假設(shè)測(cè)試時(shí)，與本機(jī)代碼的集成帶來(lái)的其他好處。這意味著在客戶決定簽署整個(gè)項(xiàng)目的合同之前，我們可以構(gòu)建最小的應(yīng)用程序，以回答最關(guān)鍵的業(yè)務(wù)或技術(shù)問(wèn)題。在這一點(diǎn)上，我們不能高估Flutter的功能。每次我們將此類計(jì)劃定為兩天的開(kāi)發(fā)時(shí)間，試圖找出在這么短的時(shí)間內(nèi)可以實(shí)現(xiàn)的目標(biāo)。到目前為止，我們正在嘗試各種PoC，包括支持AR的圖像檢測(cè)系統(tǒng)（如下），

通過(guò)白板圖紙繪制高級(jí)動(dòng)畫(huà)。

建立快速的PoC不僅使我們能夠展示開(kāi)發(fā)的速度，而且還有助于我們?yōu)樽罱K項(xiàng)目提供更準(zhǔn)確的估算。

開(kāi)發(fā)人員很高興

從建立內(nèi)部團(tuán)隊(duì)的角度來(lái)看，F(xiàn)lutter被證明是一個(gè)不錯(cuò)的選擇。最初，F(xiàn)lutter開(kāi)發(fā)人員很少，因?yàn)闆](méi)有專業(yè)經(jīng)驗(yàn)。但是，與開(kāi)發(fā)人員具有C＃背景的Xamarin相比，情況有所不同，在Flutter的情況下，所有候選人都是已經(jīng)從本地（主要是Android）背景轉(zhuǎn)移的移動(dòng)開(kāi)發(fā)人員。隨著Flutter變得越來(lái)越受歡迎，并且由于社區(qū)組織的活躍以及定期聚會(huì)和網(wǎng)絡(luò)研討會(huì)的興起，可用的候選人數(shù)量呈指數(shù)增長(zhǎng)，如今，有大量的專業(yè)人士愿意在Flutter項(xiàng)目中尋找工作經(jīng)過(guò)多年的本機(jī)應(yīng)用程序開(kāi)發(fā)，我們改變了看法。得益于文件詳盡的Flutter代碼以及社區(qū)提供的其他庫(kù)的可用性，進(jìn)行此類轉(zhuǎn)移非常容易。因此，一些以前擁有獨(dú)立移動(dòng)團(tuán)隊(duì)的公司 正在投資以使它們圍繞Flutter。 在LeanCode，我們甚至組織了Flutter訓(xùn)練營(yíng)，在湖邊進(jìn)行了為期三天的培訓(xùn)計(jì)劃，以提供動(dòng)手經(jīng)驗(yàn)，并為密集的，為期兩個(gè)月的學(xué)習(xí)計(jì)劃選擇最佳人選，在那里學(xué)習(xí)Flutter 伴隨著做一些非商業(yè)項(xiàng)目。 我們驚訝地注意到，經(jīng)過(guò)9個(gè)星期的培訓(xùn)，開(kāi)發(fā)人員準(zhǔn)備與他們的同事并肩工作，他們從早期就開(kāi)始在Flutter中進(jìn)行編碼。 如此短暫的學(xué)習(xí)周期證明，從企業(yè)主的角度出發(fā)，選擇從本地應(yīng)用程序切換到Flutter并不是一場(chǎng)革命，而是一場(chǎng)內(nèi)部團(tuán)隊(duì)可以發(fā)揮重要作用的演變。

對(duì)技術(shù)棧做出正確的決定可能會(huì)對(duì)您的業(yè)務(wù)和個(gè)人職業(yè)產(chǎn)生持久的影響。然而，很少有選擇如此簡(jiǎn)單。 Flutter已經(jīng)成為不可阻擋的運(yùn)動(dòng)，不可忽視的力量，并且它仍在發(fā)展并向具有銀行或保險(xiǎn)等極高質(zhì)量標(biāo)準(zhǔn)的非常保守的行業(yè)擴(kuò)展（例如NuBank，ING和AXA等）。

如果考慮到甚至在生產(chǎn)階段發(fā)布Flutter for Web或Flutter for Desktop之前都會(huì)發(fā)生這種情況，則表明Flutter for mobile具有足夠的價(jià)值，可以在這個(gè)非常先進(jìn)的市場(chǎng)上競(jìng)爭(zhēng)。無(wú)論您從事的行業(yè)是什么，早期采用者的時(shí)代都已經(jīng)過(guò)去，我們很快就會(huì)見(jiàn)證越來(lái)越多的成熟參與者進(jìn)入Flutter生態(tài)系統(tǒng)。我希望這將使我們能夠在Flutter中制作出另外10款出色的應(yīng)用程序后，在明年的總結(jié)中分享從這些實(shí)現(xiàn)中學(xué)到的經(jīng)驗(yàn)教訓(xùn)。