> 作者：Łukasz Kosman 和 Jakub Wojtczak > > 原文：[https://medium.com/swlh/lessons-learned-after-making-the-first-10-commercial-apps-in-flutter-f420808048cd](https://medium.com/swlh/lessons-learned-after-making-the-first-10-commercial-apps-in-flutter-f420808048cd) 在過去的24個月中，我們花費 17.193,00 個小時使用 Flutter 完成了10個商業應用程式，本文將分享我們的見解。 閱讀本文後，您將學習到： - 選擇Flutter的原因是什麼？ Flutter對預算和穩定性有什麼影響？ - Flutter準備好用於企業應用程式了嗎？ - 與Xamarin相比，Flutter的表現如何？ - Flutter適合哪些專案？  自2018年7月在LeanCode上開始在Flutter上開發我們的第一個商業應用程式以來，到現在已經有兩年了，當我第一次瞭解Flutter時，儘管它很有前景，但我仍然持懷疑態度，主要是因為我們最近對Xamarin的投資給我們帶來了負面體驗。 由於我們的團隊一直希望在專案中使用一些激動人心的新技術，因此我們希望它能夠證明它能給客戶帶來真正的價值。 這是一個農業專案，與牧群管理打交道，這是一個非常有趣而且典型的專案，管理員使用該系統來計算對穀倉的需求，而我們的團隊認為，從UX的角度來看，這是一個很好的見解。 在兩天內，他們自豪地展示了概念驗證方案，證明了製作動畫非常容易，可以為您帶來出色而流暢的體驗。最終，這已演變為完整比例的動畫，您可以在此處看到：  > 有了這個喜悅，我確信Flutter值得嘗試。 最初，我們沒有將自己100％投入Flutter，而是與 React Native 專案並行進行。在沒有Flutter團隊官方支援的情況下編寫第一個Google Maps實現，對此我感到悲觀。您可以在[此處](https://leancode.pl/case-studies/kezia-app)瞭解有關在Flutter中編寫第一個商業應用程式的經驗以及相關困難的更多資訊。最終，我們交付的是一個相對簡單的應用程式，少於40個檢視，且Flutter開發時間不到500小時。 自從我們交付了第一個應用程式並從客戶那裡收集到了五星級好評，我們認為，我們應該開始更加積極地向客戶推薦Flutter。從2019年5月開始，我們決定Flutter將是我們移動技術的第一選擇。同時，我們將停止在其他不同框架上開發應用程式的工作。 自那時以來，我們已經在Flutter中交付了10多種移動產品，並提供了數十種MVP / PoC。現在，該得出結論了。 #### Flutter 更快 我們並未在這裡討論理論方法（在此處可以查詢[Bran De Connick的論文](https://blog.codemagic.io/flutter-vs-ios-android-reactnative-xamarin/)），儘管這也很有趣。後來我們重寫了基於 Xamarin 和 ReactJS 的App，將二者進行對比，在後端使用相同API的情況下，與Xamarin（667h vs 987h）相比，我們減少了33％的時間，使用ReactJS（486h vs 704h）相比，則減少了31％的時間。 停下來思考一下這些數字。這些資料回答瞭如何更快，更便宜地構建移動應用程式（使用Flutter）。隨著經濟不景氣，在預算範圍內按時交付產品變得越來越重要。這也意味著對於相同的預算，您可以多交付50％的訂單。想象一下，您是一名產品負責人，負責開發團隊的優先事項，能夠將預算壁壘進一步提高50％。  這將極大地提高團隊的創造力和他們交付的工作質量。有關GastroJob案例的詳細分析，請檢視我們在[Flutter Europe Conference](https://www.google.com/sorry/index?continue=https://www.youtube.com/watch%3Fv%3DbE2xqtl0Jhw&q=EgR3UaQPGKT9tvsFIhkA8aeDS-Z7tPHwBoUS4lcIB2tdcoOpSehfMgFy)上的演講，或在[此處](https://leancode.pl/case-studies/gastrojob)檢視我們的案例研究。 #### 平均90％的程式碼在iOS和Android之間共享。 我們的90％的程式碼不會在兩個本機平臺上都編寫兩次。與本地應用程式開發相比，節省了90％的時間，並且由於一致性和團隊圍繞一個目標團結而不是分成兩個本地流，因此釋放了很多創造力。除了共享業務邏輯和使用者體驗外，我們還可以使用大量現成的庫，這些庫帶來了更多的好處。首先，他們可以通過為應用程式內使用的許多不同事物提供常用邏輯來加快開發過程（例如與伺服器（HTTP客戶端）的通訊，推送通知，安全儲存，資料庫，動畫等）。其次，與許多流行的服務（例如Firebase，地圖，支付，社交登入，分析，崩潰報告服務等）整合起來更加容易。因此，只有在編寫特定於平臺的自定義程式碼時，才需要編寫兩次程式碼（分別適用於iOS和Android）。但是，即使那樣，在Dart和本機程式碼之間進行橋接還是相當合理的 簡單，這將在本文後面進行解釋。 更重要的是，如果考慮到質量因素，則可以節省更多，因此從長遠來看，該應用程式的維護成本也更低。事實上，我們研究在Xamarin，React Native和Flutter構建的所有專案中修復bug的時間，，Flutter通常需要8–10％的修復bug時間。而 React Native 需要7–14％，Xamarin 需要11–23％。  #### 與UX / UI的合作從未如此之好 在Flutter專案期間，需要UX / UI設計師和開發人員之間進行合作。可能是因為他們不需要進行這種乏味的本地改編，而使他們的創造力鬆散。但是，從React Native團隊的經驗中也可以期望得到同樣的結果，事實並非如此。當我們更深入地挖掘時，我們發現Flutter為能夠編寫漂亮介面的開發人員帶來了純粹的歡樂，以前這些介面會帶來額外的負擔，從而減慢了步伐。因此，他們更願意合作，並且我們已經看到結對程式設計會議開始於設計師與開發人員攜手進行現場實驗的過程中。經過幾次這樣的互動，得益於強大的主題引擎，團隊能夠為該應用程式提供一種自適應的設計語言，該語言不僅在Figma或Adobe XD中看起來很棒，而且還提供了最佳的使用者體驗以及連貫的感覺。正確的設計順序。怎麼樣 在專案的整個生命週期中保持這種連貫性也很有趣。 以前，當UX / UI設計師在演示會議上審查產品時，他們在專案結束時擁有大部分評論，在實踐經驗之後改變主意或簡化事情。 Flutter的獨特之處在於，在專案結束時，設計師的參與已完全消失，因為他們在試驗和錯誤的設計迴圈的初期就開始工作。 這也意味著後續sprint的優化花費的時間更少，並且這種持續的合作體現在下一個發行版的穩定Scrum速度上。 #### 動畫是如此的簡單和實惠 在Flutter中實現靜態檢視不僅容易，而且在動畫方面也提供了許多新的機會。這將這種UX-DEV的合作推向了新的高度，從而實現了前所未有的出色過渡效果。到目前為止，這僅對大型預算專案而言是典型的。如今，感謝Flutter，所有開發人員都可以使用它。之所以會發生這種情況，是因為Flutter可以直接在畫布上進行渲染，並且可以完全控制圖形，這使我們能夠在所有平臺上建立畫素完美的影象，而無需像其他跨平臺框架一樣進行附加的條件格式設定。例如，在使用React Native進行繪製時，您基於預設檢視，這些檢視可以改變新控制元件的外觀，因此，構建了一個臭程式碼，該程式碼依賴於平臺，並且與共享程式碼不應採用的方法直接矛盾進入部署平臺。 #### Flutter應用程式更輕巧 面對PWA業務選擇時，PWA證明了在手機上新增快捷方式來像儲存應用程式一樣儲存網站是多麼容易。我們先不討論使用者體驗，而只考慮下載應用程式的負擔。是的，在兩種情況下都並非易事。根據SimiCart部落格，最佳PWA網站要求使用者在載入時從4.9MB到11.6MB。這遠遠低於我們的Xamarin應用程式的平均大小25MB，甚至低於我們的React Native 32MB應用程式的平均大小，但非常接近Flutter的平均值11MB，所有Flutter應用程式的範圍為9-14MB （請注意，儘管這些數字突出顯示了模式，但它們不能直接比較）。您必須承認，對於本機應用程式體驗，平滑的外觀，快速的反應以及本機應用程式典型的所有服務（例如推送通知）而言，此（11MB）的空間非常低。這意味著沒有障礙。 使用者下載該應用程式，並開始與所有外掛和整合一起儘可能高效地使用它。 這也意味著應用程式效能更高，因為它們可以使用較小的程式碼執行類似的任務。 與其他跨平臺框架相比，這種效能上的提升直接轉化為毫秒數，從而為您提供了較冷的應用程式，動畫，CPU和記憶體使用方面的更快體驗（實際上，在Flutter可以提供更好的冷啟動應用程式的情況下，即使相比 到Swift / Kotlin本機應用程式）。 #### 需要時可以訪問本機程式碼。 Flutter的優點在於，移動團隊更希望使用本機程式碼並編寫一些Kotlin / Swift軟體包，因為它們可以完全控制本機實現，而Xamarin就是這種情況最終程式碼在一個孤立的黑匣子中生成。到本機程式碼的橋也更強大，因為它們是完全透明的，因此對於從本機環境轉移過來的開發人員來說更友好。由於採用了這種方法，因此可以輕鬆實現特定功能，例如本地支付提供商或一些複雜的庫。更重要的是，即使是需要生物特徵識別演算法進行面部識別或指紋檢查的高階功能，也可以在Flutter上順利執行，這是由ING商業在Flutter中開發的銀行應用程式展示的，該應用程式是在JakubBiliński在Flutter Warsaw Meetup上展示的（[連結](https://leancode.pl/blog/flutter-warsaw-jakub-bilinski)）。 #### Flutter中的概念非常簡單 當我們需要構建概念證明以檢查最危險的假設測試時，與本機程式碼的整合帶來的其他好處。這意味著在客戶決定簽署整個專案的合同之前，我們可以構建最小的應用程式，以回答最關鍵的業務或技術問題。在這一點上，我們不能高估Flutter的功能。每次我們將此類計劃定為兩天的開發時間，試圖找出在這麼短的時間內可以實現的目標。到目前為止，我們正在嘗試各種PoC，包括支援AR的影象檢測系統（如下），  通過白板圖紙繪製高階動畫。  建立快速的PoC不僅使我們能夠展示開發的速度，而且還有助於我們為最終專案提供更準確的估算。 #### 開發人員很高興 從建立內部團隊的角度來看，Flutter被證明是一個不錯的選擇。最初，Flutter開發人員很少，因為沒有專業經驗。但是，與開發人員具有C＃背景的Xamarin相比，情況有所不同，在Flutter的情況下，所有候選人都是已經從本地（主要是Android）背景轉移的移動開發人員。隨著Flutter變得越來越受歡迎，並且由於社群組織的活躍以及定期聚會和網路研討會的興起，可用的候選人數量呈指數增長，如今，有大量的專業人士願意在Flutter專案中尋找工作經過多年的本機應用程式開發，我們改變了看法。得益於檔案詳盡的Flutter程式碼以及社群提供的其他庫的可用性，進行此類轉移非常容易。因此，一些以前擁有獨立移動團隊的公司 正在投資以使它們圍繞Flutter。 在LeanCode，我們甚至組織了Flutter訓練營，在湖邊進行了為期三天的培訓計劃，以提供動手經驗，併為密集的，為期兩個月的學習計劃選擇最佳人選，在那裡學習Flutter 伴隨著做一些非商業專案。 我們驚訝地注意到，經過9個星期的培訓，開發人員準備與他們的同事並肩工作，他們從早期就開始在Flutter中進行編碼。 如此短暫的學習週期證明，從企業主的角度出發，選擇從本地應用程式切換到Flutter並不是一場革命，而是一場內部團隊可以發揮重要作用的演變。 對技術棧做出正確的決定可能會對您的業務和個人職業產生持久的影響。然而，很少有選擇如此簡單。 Flutter已經成為不可阻擋的運動，不可忽視的力量，並且它仍在發展並向具有銀行或保險等極高質量標準的非常保守的行業擴充套件（例如NuBank，ING和AXA等）。 如果考慮到甚至在生產階段釋出Flutter for Web或Flutter for Desktop之前都會發生這種情況，則表明Flutter for mobile具有足夠的價值，可以在這個非常先進的市場上競爭。無論您從事的行業是什麼，早期採用者的時代都已經過去，我們很快就會見證越來越多的成熟參與者進入Flutter生態系統。我希望這將使我們能夠在Flutter中製作出另外10款出色的應用程式後，在明年的總結中分享從這些實現中學到的經驗教訓。 ## 交流 老孟Flutter部落格（330個控制元件用法+實戰入門系列文章）：[http://laomengit.com](http://laomengit.com) 歡迎加入Flutter交流群（微信：laomengit）、關注公眾號【老孟Flutter】： | | | | ----------------------------------------------- | ------------------------------------------------------------ | |  |  |