哈嘍，我是老劉

我們團隊使用Flutter已經快6年了。
有很多人問過我們對Flutter的評價。
今天在這里回顧一下6年前選擇Flutter時的原因，以及Flutter在這幾年中的實際表現如何。

選擇Flutter時的判斷

1、性能

最開始吸引我們的就是其優秀的性能。
特別是獨立渲染引擎，從架構上避免了其它基于原生渲染的跨平臺框架的先天問題。

2、高度的兩端一致性

Flutter的最大魅力之一在于其跨平臺能力，能夠實現iOS和Android兩端的高度一致體驗。
也是得益于其獨立渲染的架構，不需要再在不同端上分別進行UI細節的調試。

3、和原生的無縫銜接

Flutter本身提供的channel機制，以及Flutter工程能夠和原生工程混合的特點是我們的剛需。
我們的項目已經上線運行好幾年了，如果切換到跨平臺需要把所有功能重新開發一遍，那是沒法接受的。
所以類似Flutter這種能無縫融入原生項目的方案才是我們的選擇。

4、開發效率

這可能是大多數團隊選擇跨平臺框架的重要原因之一了吧。
但事實上一份代碼多平臺運行，不僅僅是減少了一個平臺的開發量。
它同時還因為避免了不同平臺程序員因為思路不同導致的多端邏輯差異。
而這種邏輯差異很多時候會對開發效率造成嚴重影響。

5、客戶端上最好的TDD支持

對于注重軟件質量的我們來說，Flutter提供的優秀測試支持是一大福音。
?

TDD是我一直以來最為推崇的軟件工程方法。
但是在客戶端上因為其效率極低的單元測試解決方案，讓TDD成為了一個極為復雜的事情。
Flutter的優秀單元測試能力，為客戶端領域實現有實戰價值的TDD流程帶來了新的可能性。

使用六年，當初的判斷都對了嗎？

1、性能媲美原生

在大多數日常使用場景中，Flutter應用的性能幾乎可以與原生應用媲美，用戶難以察覺到差異。
特別是隨著Impeller渲染引擎的引入，Flutter在圖形處理和動畫方面的表現更令人期待。
當然在極少數極端性能要求下，Flutter相較于原生應用仍可能略顯遜色。
不過這也讓Impeller更被期待了。

2、兩端一致性非常好

早期因為原生和Flutter頁面混雜情況比較多，每個需求都要安排Android和iOS各一個開發
從中期開始，我們發現一個開發者就能高效地完成大部分工作，另一端的同事僅需在遇到特定原生集成問題時提供支持。
到了后期，Flutter幾乎成為新功能開發的唯一選擇，大大簡化了團隊結構和溝通成本。
這時只需要安排一個開發即可，偶爾碰到原生問題協調另一端的原生開發臨時幫忙看一下就行。

3、長期使用原生+Flutter的混合開發模式

我們的項目在切換到Flutter之前，已經上線很多年了。
經過不停的發展、迭代，已經積累了大量沒有記錄在文檔中的隱藏功能和代碼邏輯。
換句話說就是你不動他們，他們就能正常運行，
你隨便改一點，就不一定會回發生什么事情。
所以我們最開始選擇Flutter的時候，選擇的策略就是混合開發、逐步過渡。

最開始的時候只把少數頁面切換到Flutter上進行灰度測試。
確認了Flutter的穩定性和用戶體驗沒有問題后才開始把Flutter座位正式項目的首選。
但也不是把所有的頁面都遷移到Flutter。
而是新項目、新頁面優先采用Flutter開發，老頁面仍然保留原生。
只有在新需求中老頁面的變動超過50%，才考慮遷移到Flutter重做一遍。
經過這幾年的逐步替換，目前常用頁面的80%已經切換到Flutter上面了。
剩下的頁面有歷史原因，有技術原因。
但是我們打算長期保持這種混合開發的狀態，不會整體切換到Flutter。
這種靈活性讓Flutter在保持跨平臺優勢的同時，沒有犧牲對平臺特性的支持。

4、開發效率比兩端單獨開發時節省60%的人力

近期的項目開發效率，對比切換到Flutter前，整個團隊效率大約提升了60%。
這可能和很多人感覺的不太一樣，大家普遍覺得會節省一半人力或者更少一點。
這主要取決于以下幾個方面：
第一，真正的只寫一次代碼
不同于很多跨平臺框架，仍然需要在不同的端上進行微調。
Flutter是真正意義的只寫一次代碼，調試通過后一般不需要再在各個平臺進行二次調試了。
這部分確實是節省了40%以上的人力。
第二，高度兩端一致性
我覺得這一點上收益最大的是產品和測試團隊。
對產品團隊來說，沒有了以前一個功能點Android需要一周、iOS需要一天這種奇特的情況。
整個項目安排比以前順暢和可控了很多。
對于測試團隊來說，過去一個項目開發完，你去看bug列表，基本上Android和iOS是完全不一樣的。
現在雖然為了保證質量，仍然會區分Android和iOS進行測試。
但是基本上一個Android和iOS發現的是一個bug，也只需要修改一次。
測試和回歸的工作量就少了很多。
第三，TDD對開發流程的優化
基于Flutter的TDD流程給我們團隊帶來了很多影響比較深遠的改變。
比如更可控的項目進度，更好的代碼質量等等。
可以說TDD帶來的人力成本的節省不次于少寫一份代碼。
下面就看看TDD都帶來了哪些好處？

TDD帶來的開發體驗優化

a、提高代碼質量
TDD迫使開發者從一開始就思考代碼的設計和接口，這有助于編寫出更加模塊化、可重用和可維護的代碼。
通過持續的測試，可以確保新添加的代碼不會破壞現有功能。
b、加速開發流程
雖然TDD在項目初期可能會稍顯緩慢，主要是因為人員的不熟悉。
但隨著項目的進展，其優勢會逐漸顯現。
自動化的測試用例能夠快速反饋代碼的正確性，減少了手動測試的時間，使得開發者能夠更加自信地進行重構和添加新功能。
基本上你基于TDD流程添加的代碼，對其可靠性心里是很有底的。
不會出現寫了很多天代碼，一運行到處都崩的情況了。
c、減少長期維護成本
通過TDD開發的代碼通常具有更高的穩定性和更低的缺陷率。
這意味著在產品發布后，團隊將花費更少的時間在修復bug上，從而可以更專注于新功能的開發。
基于TDD提交測試的代碼很少出現一個功能實現的不到位的情況。
bug主要出現在一開始寫測試例時就沒有考慮到的場景中。
d、促進團隊協作
測試用例本身也是對需求的一種文檔化，有助于新團隊成員更快地理解項目和代碼庫。
這一點寫過的同學應該比較有體會。
因為不同程序員的思路其實差異是很大的。
如果直接去讀別人寫的代碼，理解起來相對會比較困難。
但如果從測試例入手去讀代碼，因為測試例本身一般模式相對比較固定，起名也帶有很強的描述性。
所以我們很容易理解別人代碼中每個函數的設計目標。

總之，測試驅動開發是一種強大的開發方法，尤其適用于Flutter這樣的現代開發框架。
通過TDD，團隊不僅能夠提高代碼的質量和穩定性，還能在長期內提升開發效率，減少維護成本。
對于追求高質量和高效開發的團隊來說，TDD無疑是一個值得投資和采用的策略。
而這也是Flutter相對于原生和很多其它跨平臺框架的獨門優勢。

好了，前面說的都是我們最開始基于哪些原因選擇了Flutter，基本都是Flutter的優勢所在。
那么接下來說一說這些年使用中發現的Flutter的缺點。

Flutter的一些缺點

誠然，沒有任何技術是完美的。Flutter在某些方面也暴露出了局限性，比如：

• 包體積問題：
  Flutter應用的初始安裝包相對較大，對于極度關注應用大小的項目來說，是一個考量點。
  這主要是因為Flutter需要把自身的引擎部分也打包到App中。
• 第三方庫依賴：
  雖然Flutter社區日益壯大，但仍有一些領域，特別是針對特定平臺的高級功能，第三方庫的支持不如原生豐富或成熟。
• 學習曲線：
  對于習慣于Java或Swift的開發者而言，學習Dart語言及Flutter框架需要一定時間，初期可能會遇到一定的學習障礙。

總結

綜上所述，Flutter在我們團隊的六年實踐中，不僅證實了其作為跨平臺開發框架的巨大潛力，更是在性能、一致性、開發效率和測試支持等方面超出了我們的最初預期。
當然，我們也意識到持續關注其發展，適時調整策略以應對潛在挑戰的重要性。
Flutter的旅程還在繼續，我們對其未來充滿信心。

如果看到這里的同學有學習Flutter的興趣，歡迎聯系老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發場景的《Flutter開發手冊》https://mp.weixin.qq.com/s?__biz=MzkxMDMzNTM0Mw==&mid=2247483665&idx=1&sn=56aec9504da3ffad5797e703c12c51f6&chksm=c12c4d11f65bc40767956e534bd4b6fa71cbc2b8f8980294b6db7582672809c966e13cbbed25#rd