原文
Why we chose Flutter and how it’s changed our company for the better.
呼籲全世界的原生iOS和Android開發者-這是一個更好的方法
Google的Flutter可以讓你快速製作iOS和Android App的Mobile App開發框架。閱讀有關為什麼Flutter是具有革命性的。
一點背景
我原生開發的日子可以追溯到Installer，我第一個開發的播客App。在過去的十年裡，我為Comcast 和Associated Press 開發了數十個App，我的本質一直是原生開發者。
在我的職業生涯中，我花很多時間建立客製化企業軟體。在機構/合約工作的這些經驗讓我嘗試去解決問題...企業軟體的建構、佈署、支援和使用都非常困難。我共同創立了AppTree軟體，並著手讓企業軟體更簡單。
在我的職業生涯中，我花很多時間建立客製化企業軟體。在機構/合約工作的這些經驗讓我嘗試去解決問題...企業軟體的建構、佈署、支援和使用都非常困難。我共同創立了AppTree軟體，並著手讓企業軟體更簡單。
我們著手建立一個平台，讓開發者可以更容易地建立、支援和佈署企業應用。我們建立Mobile clients和SDKs，讓你的應用可以快速繼承解決方案，解決複雜的企業軟體問題。我們的目標是讓你只需要關心你的業務邏輯。
採用"原生"方法
由於企業軟體的性質，我們需要處理數十萬筆的紀錄、可離線工作而且是非常安全的。當然，我們很自然的選擇使用iOS和Android SDK來開發我們的App。反過來說，我拒絕跨平台開發框架。它們太慢，工具不好而且你的UI依舊要做兩個平台。
儘管原生開發提供了我們想要的結果，但在開始寫程式與持續的維護都花費了很大的開銷。為了獲得我們需要的效能與可控性我們需要原生應用clients，這意味著我們所有事情都要做兩次，找人也非常困難還有那編譯時間...我的天阿編譯時間(看向Swift)。我們盡一切所能讓我們的App clients在兩個平台上保持相似。我們在iOS上使用Swift在Android上使用Kotlin。我們使用Realm做為跨平台的資料儲存，我們使用RxSwift 和 RxJava。
然後我們決定增加第三個平台...Web。然後我們著手尋找符合我們需求的語言與工具，最後我們找到Dart。
我們繼續採用Mobile應用上的所有功能，並在Dart重新實作，以便我們的客戶可以在瀏覽器中使用他們的應用。
打破那面牆
功能開發開始拖延。現在我們每個功能要做三次，跟所有的新創公司一樣我們有三個不同的團隊，我們正嘗試快速移動。我們整體的生產力下降，我們所有的時間都花在跟不同的團隊同步功能與想法上，架構開始分歧而且QA時間增加，質量降低。
做為Dart社群的一部分，我們聽到Flutter的傳言。身為多年的原生開發者，我對跨平台框架產生了健康的懷疑態度。然而，這似乎不同。到目前為止，我們喜歡在Dart上的體驗，而Flutter團隊在跨平台問題上採取的做法是正確的。
我們對Flutter的激動在波特蘭的Google開發者聚會發了芽。來參加聚會，我們是很有興趣的。Flutter感覺非常適合我們。
那天晚上我自己做了一個提案，看我使用Dart會遇到什麼樣的問題。在練習結束後，我確信我們公司應該轉向Flutter。而且我們應該立刻去做。
這裡是....
做為Dart社群的一部分，我們聽到Flutter的傳言。身為多年的原生開發者，我對跨平台框架產生了健康的懷疑態度。然而，這似乎不同。到目前為止，我們喜歡在Dart上的體驗，而Flutter團隊在跨平台問題上採取的做法是正確的。
我們對Flutter的激動在波特蘭的Google開發者聚會發了芽。來參加聚會，我們是很有興趣的。Flutter感覺非常適合我們。
那天晚上我自己做了一個提案，看我使用Dart會遇到什麼樣的問題。在練習結束後，我確信我們公司應該轉向Flutter。而且我們應該立刻去做。
這裡是....
The Pitch(簡報提案)
我的提案從使用像Flutter這類東西會有什麼缺點開始。為什麼我們不該使用Flutter
- 新技術，APIs可能會變
- Flutter沒有內建的東西像地圖、相機，必須使用原生APIs
- 不支援Realm。我們必須重新考慮長期儲存
- 沒有很多第三方函示庫支援。我們使推桿、擷取簽名、照片編輯等
以上原因是否重要
- 新技術，APIs可能會變 => 不是真的，Google內部已經使用在產品上。有多個App在App商店，我真的看到他們只添加缺少的APIs。
- Flutter沒有內建的東西像地圖、相機，必須使用原生APIs => 不，我們已經在iOS和Android上寫了這些，這些程式碼可以透過plugin的方式重複使用，看我們製作的地圖plugin。
- 不支援Realm。我們必須重新考慮長期儲存 => 是的，這很重要，大部分我們是在重寫這一塊。
- 沒有很多第三方函示庫支援。我們使推桿、擷取簽名、照片編輯等 => 類似地圖，我們可以把第三方函式庫封裝成plugin，以便在Flutter中使用。我們做了這個、這個和這個。
為什麼是Flutter:UI框架
- 現代API，Flutter團隊做了一件了不起的事情，提出一個API來解決Mobile開發常見的需求，同時保持高度的可客制性。
- 完全符合我們的導覽需求，也讓我們分享導覽的概念到Web。
- 開放原始碼
- Reactive Views
- 他是自已透過Skia繪製畫面。這意味著你的UI跟導覽只需要寫一次，就可以在iOS和Android上使用。
為什麼是Flutter:開發周期
- Android完全編譯--2:10秒
- Android增量編譯--20秒
- iOS完全編譯--2:40秒
- iOS增量編譯--40秒
- Flutter完全編譯--25秒。在iOS上這包括建構Dart程式碼，跑pod install和xcodebuild 指令。Android上的結果類似，因為它使用了gradle構建處理過程。
- Flutter 增量編譯--少於一秒，感謝驚人的hot reload。
為什麼是Flutter:單元測試
Android單元測試
- 良好的支持，假如你模擬(mock)Android特定的類別，可以跑在沒有Android的JVM上。
- 編譯時間5秒
- 運行時間1.5秒
iOS單元測試
- 只可以跑在iOS模擬器上(有辦法透過將非iOS的程式碼移到子框架中，來解決這個問題，這對我們來說是很大部分的重寫)
- 編譯時間 40~2:40秒
- 運行時間10秒
Dart
- 神奇的支持。輕鬆指定哪一些測試可以在VM上執行。
- 少於一秒的編譯時間
- 執行時間1秒
但當然，最大的好處是我們的測試只需要寫一次
為什麼是Flutter:共用程式碼
- 95%的程式碼可以在iOS和Android重複使用。我們自己的plugins是唯一的例外
- 60%的程式碼可以在Flutter和Web重複使用
- 主要架構改變只要改一次，而不是三個平台都要改
- 因為Flutter有自己的 UI/Widget函式庫，我們不必處理iOS和Android的實作細節。(即Android Activity, Fragments, 消息傳遞等)
為什麼是Flutter:QA測試
- 非常高的信心，測試iOS，Android和Web也一起被驗證(譯者:因為共用程式碼)
- 現在我們擁有三倍的產能，我們的團隊都集中到同一個程式庫上
- 知識共享處於有史以來最高水平
讓他成真
我相信Flutter的價值，我向我的CEO作了一樣的簡報。他也確信。然後我向團隊簡報，讓每個人的想法一致。
告訴我們是否真的對我們有用的唯一方法就是去嘗試它。我們設定六周的時間，看看我們可以做到哪些。
三周內，我們做了一個app client的雛型，由於我們可以共用我們Dart Web client專案大量的程式碼，所以我們可以很快的完成。
我們在十月開始用Flutter重寫。我們將在一月發布我們的Flutter版本。
提供一些觀點，我們iOS App完成後，Android App花了一年的時間才開發出來。
這不僅是因為有很多的程式碼要寫，還需要替團隊填補適合的人，然後根據產品的複雜性進行訓練。再也不必。現在我們是一個團隊，增加成員可以是一個更循序漸進的過程。
此外，我們不是將人才分成三個不同的平台，而是將團隊成員聚焦在Flutter的不同方面，UI、架構和plugins。
我們在開發新功能的產能大約增加了三倍，原因如下:
不只因為在iOS和Android只有單一的程式碼庫得到效益，我們可以共用web clients與mobile clients ~70%(在撰寫本文時是67%)的程式碼。但這還沒有結束。如果我們在任何一個平台測試功能，除非他是特定平台的UI修改，不然我們三個平台只需要測試一次。我們沒有預料到這個好處，但他是真的而且非常重要。我們還發現，因為我們能將分散的團隊合併為一個擁有共同技能的團隊，我們溝通更順利，更能專心投入工作。說實話，我們更開心。
雖然做新功能很有趣，但如果不得不做兩次，它會變得很麻煩。然後必須寫特定平台的測試。然後再次QA一樣的事情。
譯者:....他們不知道有後面這些好處就衝了，也是蠻有勇氣的，但很多事不去勇於嘗試會怎麼樣?誰知道呢
留言
張貼留言
有什麼想法歡迎跟我們分享