釋出時間：2019年2月18日 - 11分鐘閱讀
從移動應用開發的早期開始，就有一場激烈的爭論，是使用原生平臺技術還是跨平臺技術來構建應用。Flutter為這場爭論創造了一個新的維度，因為它同時具有多平臺和跨平臺的特點。
Flutter的承諾和開發社群的興趣意味著值得在原生與Flutter的背景下再次列舉這場辯論。
以下是我們認為在看待跨平臺移動開發時的重要因素：
- 最好的原生應用體驗與更容易的工具鏈。
- 平臺專業性VS抽象成本。
- 平臺專業程式語言 vs 通用語言。
- 最新的平臺發展 vs 追趕。
- 多程式碼庫和測試工作 vs 單一程式碼庫和增量測試工作。
- 平臺專用測試框架 vs 通用測試框架。
關於Flutter的一點背景
讓我們先非常快速地概述一下為什麼Flutter與其他跨平臺的工作不同。簡單來說，Flutter採用了類似於手機遊戲引擎的方法，並分解為這三塊
- iOS(.ipa)和Android(.apk)應用，作為執行器，但不包含編譯後的應用程式碼本身。
- 原生執行時引擎處理低階職責，如繪製使用者介面和裝置和/或平臺庫訪問的互操作設施。對於iOS來說，這個引擎是通過LLVM交付的，而Android則是通過NDK交付的。
- 應用程式程式碼編譯成ARM庫，與引擎一起創造應用程式體驗。
這與跨平臺的Ionic/Cordova以Web檢視執行，ReactNative以JavaScript為核心，並與原生UI元件進行互操作有很大的區別。
Flutter之所以能讓更多人重新關注跨平臺，是因為它：
- 執行時效能非常快，解決了持續困擾基於JavaScript的解決方案（Ionic/Cordova或ReactNative）的滯後問題。 Flutter的工具鏈意味著可以在模擬器和裝置上進行開發（就像原生開發一樣）與使用Chrome開發工具進行移動應用開發（Ionic/Cordova或ReactNative）。
- 一流的IDE支援。在工具方面有大量的投資，這也是現在對谷歌的期望。
- Google在移動作業系統方面的血統讓Flutter具有合法性。它是由Adam Barth等傑出的谷歌工程師構思的。
下面我們重述一下我們對原生與跨平臺的看法，並在Flutter的背景下重新評估這些看法。
同類最佳的原生應用體驗VS更簡單的工具鏈
我們的觀點是什麼？
原生應用基於速度、平臺符合性和最新功能的使用提供最佳的使用者體驗。跨平臺產品關注的是使用來自非移動世界的程式語言和執行時，其基礎是這樣可以簡化開發。
這在Flutter身上是怎麼看的呢？
從表面上看，Flutter只是之前的變種。事實上，你可以重新利用React、Cordova或Xamarin的語句來描述Flutter *。 在這方面，Flutter並沒有挑戰我們當前的思維。
然而，Flutter的故事有3個方面是不同的，也是比較有趣的。
首先，它正在顛覆原生開發者對自己原生工具鏈的看法。
Flutter驚人的Hot Reload是原生開發者長期以來所需要的。原始碼的變化會立即反映在裝置/模擬器上。Flutter正引領著原生應用開發的方式。（參見Android Studio最近對即時執行的更新 bit.ly/2N6YcTo ）。
其次，Flutter正在實現原生開發者會滿意的應用效能。即使是在Android One這樣資源緊張的裝置上，Flutter示例應用的流暢度也遠超預期。 之所以能夠做到這一點，是因為Flutter是按照ARM指令編譯的（通過Android的NDK和iOS的LLVM）。更具創新性的是Flutter採用的獨特的渲染模型，即通過widget（又稱檢視）層次結構的一個通道實現渲染。此外，無狀態與有狀態widget的概念允許佈局的快取。然而，Flutter還很年輕，在效能方面，陪審團還沒有出來。
第三，Flutter使用了一種較新的現代程式語言。
我們對JavaScript這種語言有偏見。(很遺憾，我們在這裡沒有時間去討論這個話題。)Flutter有趣的地方在於它使用了Dart語言，這意味著開發者得到了一種現代的、成熟的程式語言，也是非常熟悉的。(未來我們會寫一篇關於Dart的文章)。
這意味著什麼呢？
雖然很明顯，Flutter與之前的跨平臺努力相比是一個更令人信服的出發點，但它無法擺脫一些缺陷，這繼續形成我們的想法，即Flutter仍然是一流的原生體驗和工具鏈簡單性之間的妥協。
Flutter的UI小部件是原生小部件的摹本。因此，它們的感覺並不總是很正確。另外，Flutter將處於不斷追趕的狀態，因為它必須對iOS和Android的創新和改進做出反應。例如，Flutter並沒有（尚未）讓你訪問ARKit/iOS或ARCore/Android。
*用 "Flutter "代替其他工具的名稱時，其他跨平臺工具的說法似乎還算成立。
"[Flutter] R̵e̵a̵c̵t̵N̵a̵t̵i̵v̵e̵讓你只用[Dart] J̵a̵v̵a̵S̵c̵r̵i̵p̵t̵. ....讓你從宣告式元件中組成一個豐富的移動UI"。(React Native facebook.github.io/react-nativ…)
"[Flutter]A̵p̵a̵c̵h̵e̵C̵o̵r̵d̵o̵v̵a̵是一個開源的移動開發框架。它允許你使用標準的[Dart]w̶e̶b̶技術--H̵T̵Mn_335̵5̵,̵C̵S̵S̵3̵,̵a̵d̵J̵a̵v̵a̵S̵c̵r̵i̵p̵t̵進行跨平臺開發。" (Cordova bit.ly/2Br2enX)
"用一個共享的[Dart].̵N̵E̵T̵程式碼庫來交付原生的Android、iOS和Windows應用。" (Xamarin)
平臺專業知識與抽象成本
我們的觀點是什麼？
平臺的專業性意味著對API和SDK的訪問和理解是平臺開發者的意圖。因此，本地開發不需要任何抽象成本。所有跨平臺的努力都是試圖將開發者從底層平臺的現實中抽象出來。開發者的代價是，跨平臺工具要麼是一個未知的黑盒子，要麼是開發者必須同時兼顧原生平臺和跨平臺抽象的一些知識。
這在Flutter上是怎麼看的呢？
使用Flutter開發並沒有改變跨平臺工具的侷限性--它們提供了原生開發者可用的功能子集。如果你想超越這個子集，你需要一個互操作機制和平臺專業知識。Flutter也不例外，採用了外掛機制來實現與原生程式碼的互操作性。
然而Flutter是與眾不同的。
首先，你不用特別擔心底層平臺，因為Flutter承擔了很多平臺本來要做的事情。Flutter自帶引擎，包括Skia圖形庫，用於繪製所有UI元素。Flutter框架負責整個UI的渲染。你不需要同時瞭解Android和iOS檢視和渲染的差異，因為你使用Flutter的widget。Flutter的小部件也讓你很容易推出自己的小部件。
其次，另一個常見的抽象成本來為什麼剖析跨平臺應用效能。跨平臺執行時（通常是效能最關注的領域）通常不直接可能用原生iOS和Android剖析工具來剖析。在這些情況下，回到Chrome開發工具是一種常見的剖析方法。
Flutter確實帶來了自己的剖析工具(bit.ly/2PXMIDo)--我們對這些工具的瞭解還不足以形成意見，所以這可能是未來文章的主題。
這意味著什麼？
Flutter並沒有使用原生平臺UI渲染，因此該框架並不是對底層平臺進行抽象，而是提供一個替代的執行時。
然而仍然需要訪問底層裝置服務，和其他跨平臺框架一樣，這是通過外掛機制完成的。抽象的成本即使比其他跨平臺技術少，也是存在的。
平臺專用程式語言VS通用語言
我們的觀點是什麼？
Swift和Kotlin（含Android擴充套件）是iOS和Android平臺上事實上的語言。蘋果和谷歌已經投入了大量的資金，以確保這些語言在編譯和執行時的效能上得到優化，並在工具、文件和社群參與方面提供卓越的支援。跨平臺方法的明確目標是將語言從移動開發背景之外，並建立一個環境，使它們可以在本地環境中重複使用。
Flutter的情況如何？
Flutter應用是使用Dart構建的，這是一種相對陌生的程式語言。Dart的起源可以追溯到7年前，最初的希望是讓它成為JavaScript的現代替代品。這從未實現，因為Dart虛擬機器從未進入Chrome。今天，Dart通常被移植到JavaScript中或編譯成機器程式碼。Dart虛擬機器仍然存在，但其關注度不如以前。
因此很容易看出，Dart與使用JavaScript或C#的跨平臺表兄弟非常一致--它顯然是一種來自移動開發背景之外的語言。
然而，最近釋出的Dart 2.0是該語言的 "重啟"，專門 "讓移動和Web開發更加愉快和高效"（ bit.ly/2MLR828 ）。Dart已經發展成為一種專門為Flutter和Angular Dart服務的語言。這與JavaScript等語言形成鮮明對比，這些語言從來就不是為了移動開發而設計的。
這意味著什麼？
Dart是幸運的，它的重啟主要是為了服務Flutter和Angular Dart。事實上，Flutter的開發很大程度上要歸功於JIT（Just-in-Time）編譯的能力，即當熱過載，或Ahead-of-Time（AOT）編譯。這就是熱重灌的基礎。 Dart很容易學習。它的非同步程式設計模型以及它是一種單執行緒語言的事實會讓JavaScript開發人員特別熟悉--它甚至共享async/await語法。 然而，另一種程式語言的前景很可能成為接受的障礙。
最新的平臺發展與追趕
我們的意見是什麼？
原生應用開發者總是受益於最新的平臺更新和功能。跨平臺方法只能對變化做出反應。根據平臺變化的大小和重要性，在跨平臺應用反映原生應用已經接受的內容之前，可能會有顯著的延遲。
Flutter的情況如何？
再次，Flutter與其他跨平臺方法一致。隨著iOS和Android功能的改進，Flutter團隊必須做出反應，將這些改進帶到框架中。 Flutter比其他的優勢之一是，谷歌可以選擇讓Flutter跟上Android的步伐。這並不確定，因為Flutter和Android團隊有單獨的路線圖和優先順序。然而，最近對Material Design的更新，Flutter與Android和iOS同時得到了支援。
不太令人鼓舞的是，谷歌自己的服務在支援程度上還處於相對早期階段。舉個例子，Flutter/Dart中對Firebase的支援還比iOS和Android落後不少。
這意味著什麼呢？
Flutter與Google的關係意味著它可能會在其他跨平臺框架上佔據優勢。然而，在提供最新功能方面，Flutter仍然比原生應用開發落後幾步。作為證據，Flutter並沒有為iOS或Android提供擴增實境功能的訪問。最新的iOS和Android版本中的機器學習功能也沒有提供。
這仍然是跨平臺開發方式的一個缺點。
多個程式碼庫和測試工作與單一程式碼庫和增量測試工作的對比。
我們的看法是什麼？
對於原生開發來說，兩次構建相同的應用是一個現實。除了額外的努力和成本之外，長期保持兩個應用程式的功能均等也是一個挑戰。然而，來自戰壕的故事顯示，跨平臺程式碼並不能實現一刀切的承諾。
支援平臺UI和互動的差異開始侵蝕單一程式碼庫的誘惑力。特定於平臺或裝置的UI故障也導致越來越多的平臺特定程式碼。用一個程式碼庫在廣泛的裝置和作業系統版本上實現效能也是一個挑戰。我們期待著有一天，更多的程式碼可以跨平臺共享。我們不相信今天的跨平臺方法是答案。
Flutter的情況如何？
到目前為止，看起來Flutter在不同的移動作業系統和裝置上始終執行良好，這主要得益於它的UI渲染方法。在這方面，Flutter似乎提供了單一程式碼庫的優勢。
然而，無法避免的是，需要在Flutter程式碼中加入作業系統的特殊考慮。例如應用正確的iOS或Android外觀和感覺，或者在UI中使用iOS與Android小部件。
這意味著什麼？
與其他跨平臺方法一樣，Flutter意味著iOS和Android的單一程式碼庫。這確實意味著程式碼仍然要照顧到所支援平臺上UI呈現的差異。 雖然Flutter很新，但並沒有很多最佳實踐和既定模式來管理這種程式碼中的差異。它落在開發者身上，以一種可維護的方式乾淨地管理這些差異。在某些情況下，不可避免地會導致一堆義大利麵條。然而隨著Flutter足跡的增加，好的實踐將會出現。
特定平臺的測試框架與一般測試框架的比較
我們的意見是什麼？
測試移動應用有一些獨特的挑戰。單元測試孤立執行，工具化測試需要訪問平臺服務或庫。整合測試需要在無頭模式或裝置上執行。原生開發者可以使用測試框架來正面解決這些挑戰。跨平臺開發者必須使用非移動測試框架或通過appium或類似的東西進行一般的黑盒測試。
這在Flutter上是怎麼看的？
測試Flutter應用並沒有使用原生測試框架。而是使用Dart單元測試機制和Flutter特定的單元測試包進行測試。這些包支援測試Widget（即UI檢視）和黑盒整合測試。Widget測試是在應用程式的上下文之外執行，而整合測試必須在裝置上或模擬器中執行。
這意味著什麼？
在測試方面，谷歌的支援變得很明顯。Flutter超越了其他跨平臺框架所提供的功能，並將測試支援作為Flutter的重點。
在其他跨平臺專案中，測試並不是一個核心話題。在React Native文件中，並沒有任何關於測試的具體指導。Ionic有一篇部落格文章來涵蓋這個話題，但沒有更多的內容。他們似乎把它留給了JavaScript測試框架，比如Mocha或Jasmine。Xamarin似乎有一些測試支援，但我一直在文件中找到死連結--比如到 bit.ly/2wQO5f6 。
這讓Flutter又處於原生能力和跨平臺現實的中間位置。像Flutter的其他方面一樣，該框架從一定程度的自我控制中獲利。
TL;DR
在Snapp，我們對我們的立場感到滿意，即與原生開發相比，跨平臺方法代表了一系列的妥協和缺點。我們長期以來一直認為，跨平臺倡導者提出的 "銀彈 "說法在現實中並不存在。最近AirBnB等公司對跨平臺方法的偏離就是很好的例子。 Flutter是谷歌的一項有趣舉措，其野心遠超移動裝置。與所有新技術一樣，隨著時間的推移，Flutter在現實世界中的優勢、劣勢和現實情況還需要一些時間來觀察。 我們將饒有興趣地關注Flutter。
通過www.DeepL.com/Translator（免費版）翻譯