使用Flutter完成10個商業項目後的經驗教訓

做者：Łukasz Kosman 和 Jakub Wojtczak

原文：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實現，對此我感到悲觀。您能夠在此處瞭解有關在Flutter中編寫第一個商業應用程序的經驗以及相關困難的更多信息。最終，咱們交付的是一個相對簡單的應用程序，少於40個視圖，且Flutter開發時間不到500小時。

自從咱們交付了第一個應用程序並從客戶那裏收集到了五星級好評，咱們認爲，咱們應該開始更加積極地向客戶推薦Flutter。從2019年5月開始，咱們決定Flutter將是咱們移動技術的第一選擇。同時，咱們將中止在其餘不一樣框架上開發應用程序的工做。

自那時以來，咱們已經在Flutter中交付了10多種移動產品，並提供了數十種MVP / PoC。如今，該得出結論了。

Flutter 更快

咱們並未在這裏討論理論方法（在此處能夠查找Bran De Connick的論文），儘管這也頗有趣。後來咱們重寫了基於 Xamarin 和 ReactJS 的App，將兩者進行對比，在後端使用相同API的狀況下，與Xamarin（667h vs 987h）相比，咱們減小了33％的時間，使用ReactJS（486h vs 704h）相比，則減小了31％的時間。

停下來思考一下這些數字。這些數據回答瞭如何更快，更便宜地構建移動應用程序（使用Flutter）。隨着經濟不景氣，在預算範圍內按時交付產品變得愈來愈重要。這也意味着對於相同的預算，您能夠多交付50％的訂單。想象一下，您是一名產品負責人，負責開發團隊的優先事項，可以將預算壁壘進一步提升50％。

這將極大地提升團隊的創造力和他們交付的工做質量。有關GastroJob案例的詳細分析，請查看咱們在Flutter Europe Conference上的演講，或在此處查看咱們的案例研究。

平均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上展現的（連接）。

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

歡迎加入Flutter交流羣（微信：laomengit）、關注公衆號【老孟Flutter】：