Flutter 不同的跨平臺解決方案

本文主要介紹Flutter相關的東西，包括Fuchsia、Dart、Flutter特性、安裝以及總體架構等內容。

1. 簡介

Flutter做爲谷歌最近推出的跨平臺開發框架，一經推出便吸引了很多注意。關於Flutter，目前咱們知道它是一個跨平臺開發框架。可是它自己並不止於此，例如Fuchsia、Dart等，咱們也都須要去了解。

1.1 Fuchsia

說到Flutter，絕對繞不開Fuchsia，這個是谷歌開發的一款全新的操做系統，GitHub地址以及Google source主頁。Fuchsia內核是Magenta Kernel，一個基於LittleKernel的項目。該系統與Android相比，不管是存儲器仍是內存之類的硬件要求都大幅下降，外界推論是一款面向物聯網的系統。筆者卻是沒有查到谷歌開發這款操做系統的目的，若是有知曉的，也煩請告知。

就像不少博客主說的那樣，若是隻是取代Android，那無疑是一種很很差的作法。任何技術的推進，都得靠背後的商業驅動，尤爲是這種涉及到手機廠商利益的技術。

1.2 Flutter

Flutter是Fuchsia的開發框架，是一套移動UI框架，能夠快速在iOS、Android以及Fuchsia上構建高質量的原生用戶界面。 目前Flutter是徹底免費、開源的，GitHub地址。其官方編程語言爲Dart，也是一門全新的語言。因此說，上手成本比較高，對於移動端開發人員，語言以及框架都是全新的，整個技術棧的積累也都得從頭開始。

能夠看下其官方介紹的特性：

• 快速開發：Flutter的熱重載能夠快速地進行測試、構建UI、添加功能並更快地修復錯誤。
• 富有表現力，漂亮的用戶界面：自帶的Material Design和Cupertino（iOS風格）widget、豐富的motion API、平滑而天然的滑動效果。
• 響應式框架：使用Flutter的現代、響應式框架，和一系列基礎widget，輕鬆構建您的用戶界面。
• 訪問本地功能和SDK：Flutter能夠複用現有的Java、Swift或ObjC代碼，訪問iOS和Android上的原生系統功能和系統SDK。
• 統一的應用開發體驗：Flutter擁有豐富的工具和庫，能夠幫助開發者輕鬆地同時在iOS和Android系統中實現想法和創意。
• 原生性能：Flutter包含了許多核心的widget，如滾動、導航、圖標和字體等，這些均可以在iOS和Android上達到原生應用同樣的性能。

其實從官方特性來看，惟一有點吸引力的就是統一的應用開發體驗。一套代碼運行在多個平臺，作到真正的跨平臺。像熱加載，目前Android開發自己就支持了，響應式框架以及訪問本地功能和SDK，對於Native來講，自己並無多大的吸引。至於漂亮的用戶界面，國內的商業項目，哪個會去按照Material Design去設計。

跨平臺自己，每每意味着性能受損，通用性解決不了的問題，又得回到Native去實現。因此這些因素也是跨平臺從移動端誕生之初就開始提，到如今也沒有被很好解決的一個緣由。至於谷歌可以作到什麼程度，或者說開發者該保持什麼期許，我以爲都很差說，或許谷歌解決了一個多年的難題，或者又像被谷歌放棄掉的其餘項目同樣。拋開商業層面，對於技術人員，咱們更多的是應該去關注它的思想，谷歌是如何去解決這些實際存在好久的問題的，至於技術自己的發展，這個是我的開發者沒法去左右的，技術的更迭，保持一種學習的狀態，而後努力鍛鍊身體，就可以保證不被淘汰掉。

1.3 Dart

Dart是谷歌開發的計算機編程語言，於2011年10月份發佈，能夠被用於web、服務器、移動端和物聯網等領域的開發。Flutter採用Dart，緣由不少，拋開商業層面的Java版權問題，單純從技術層面：

• Dart是AOT（Ahead Of Time）編譯的，編譯成快速、可預測的本地代碼，使Flutter幾乎均可以使用Dart編寫；
• Dart也能夠JIT（Just In Time）編譯，開發週期快；
• Dart能夠更輕鬆地建立以60fps運行的流暢動畫和轉場；
• Dart使Flutter不須要單獨的聲明式佈局語言；
• Dart容易學習，具備靜態和動態語言用戶都熟悉的特性。

Dart最初設計是爲了取代JavaScript成爲web開發的首選語言，最後的結果可想而知，到Dart 2的發佈，專一於改善構建客戶端應用程序的體驗，能夠看出定位的轉變。用過Java、Kotlin的人，能夠很快的上手Dart。

一門語言的成敗，拋開背後的商業推進，我想很重要的一點在於其生態，生態的好壞，主要包括開發者以及第三方庫的數目，目前看，Dart的生態仍是比較差。對於我的開發者，能夠根據心情來選擇，可是對於商業應用，有更復雜的考量標準。Dart背後有谷歌的推進，能發展到什麼程度，還得看其商業運做能力了。

2. 配置

此部分針對Mac平臺，Windows平臺的安裝配置，Linux平臺的安裝配置。因爲筆者主要作移動端開發，若是想使用Flutter進行iOS和Android全平臺的開發，環境也建議是Mac平臺，畢竟iOS只能在Mac下進行模擬調試。

2.1 安裝Flutter

git clone -b beta https://github.com/flutter/flutter.git
export PUB_HOSTED_URL=https://pub.flutter-io.cn //國內用戶須要設置
export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn //國內用戶須要設置
export PATH=`pwd`/flutter/bin:$PATH

2.2 iOS設置

brew update
brew install --HEAD libimobiledevice
brew install ideviceinstaller ios-deploy cocoapods
pod setup

2.3 Android設置

下載Android Studio，安裝Flutter插件，會將Dart插件也一塊兒安裝。

2.4 體驗Flutter

IDE建議選擇Android Studio，安裝了Flutter插件後，Flutter的開發跟Android
開發相似，附帶三種模版工程、斷點調試等。

在Android Studio裏面新建一個Flutter Application的項目，選擇模擬器或者直接鏈接真機運行，就能夠看到一個簡單的Flutter應用了，能夠在Android和iOS不一樣平臺下看看差別。

3. Flutter架構

Flutter是一款移動應用程序SDK，一份代碼能夠同時生成iOS和Android兩個高性能、高保真的應用程序。

Flutter對於移動開發人員，最誘惑的能力是其徹底的跨平臺特性，不一樣於RN這種一處學處處寫，它是一處寫到出跑，可是他跟其餘的跨平臺有何區別呢？

3.1 跨平臺解決方案

市面上的跨平臺解決方案，能夠大體歸結爲兩類：

• 使用平臺支持的web技術：這些解決方案基本上加載了應用程序中的移動瀏覽器，並在該瀏覽器中執行全部的邏輯，例如PhoneGap。
• 本地跨平臺：程序員編寫的代碼自動轉換爲Native代碼，這種方式的優勢是近乎原生的性能，例如RN、Weex、Xamarin等。

這些方案是否真正的解決了跨平臺問題呢？從目前的情況來看，很顯然是沒有的，由於它們都始終逃不開性能、包大小、流暢性、內存、平臺特性等問題。

RN單獨擰出來講，是由於它們並非追求的一次寫處處跑，FB本身也知道不現實，因此把口號改爲一次學處處寫，去考慮平臺的特性，去考慮這個被跨平臺方案常常忽略的問題。可是RN也並無被普遍的接納，從阿里開始使用到放棄，裏面的不少坑都繞不過去。寫一次處處跑確實很誘人，從企業角度講，能夠節省大量的人力，可是卻忽略了一個很基礎的問題，不一樣平臺是否但願如此，蘋果是否會願意本身的生態被打破，不一樣平臺的特性是否應該被歸爲一致。

3.2 Flutter的跨平臺解決方案

上面簡單說了傳統跨平臺解決方案，咱們再回過頭看看Flutter的解決方案，Flutter跨平臺最核心的部分，是它的高性能渲染引擎（Flutter Engine）。Flutter不使用瀏覽器技術，也不使用Native的原生控件，它使用本身的渲染引擎來繪製widget。

說到widget，就要說一句Flutter的一切皆爲widget理念。widget是Flutter應用程序用戶界面的基本構建塊。每一個widget都是用戶界面一部分的不可變聲明。與其餘將視圖、控制器、佈局和其餘屬性分離的框架不一樣，Flutter具備一致的統一對象模型：widget。在更新widget的時候，框架可以更加的高效。

對於Android平臺，Flutter引擎的C/C++代碼是由NDK編譯，在iOS平臺，則是由LLVM編譯，兩個平臺的Dart代碼都是AOT編譯爲本地代碼，Flutter應用程序使用本機指令集運行。

Flutter正是是經過使用相同的渲染器、框架和一組widget，來同時構建iOS和Android應用，而無需維護兩套獨立的代碼庫。

Flutter將UI組件和渲染器從平臺移動到應用程序中，這使得它們能夠自定義和可擴展。Flutter惟一要求系統提供的是canvas，以便定製的UI組件能夠出如今設備的屏幕上。

3.3 Flutter框架

Flutter框架是一個分層的結構，每一個層都創建在前一層之上。

框架沒什麼可介紹的（主要是詳細介紹我也沒找到啥資料，大寫的尷尬），看着很簡單，就分爲兩個部分，Framework和Engine部分，其中Framework提供了各類基礎的組件庫，Engine部分渲染各類widget，二者共同做用，使得運行性能高效穩定。

4. Flutter調研

4.1 生態

在Flutter官方的Pub平臺上，純Flutter Package大概有兩千多個，基本上常見的庫仍是都有的，例如網絡、圖片、音視頻播放等等。可是對於目前Android以及iOS的生態，仍是遠遠的不足的，對於一些複雜的UI或者一些不是特別通用的功能，就得本身去實現。

4.2 包大小

根據官網的介紹，一個最小的Android版本的Flutter應用。release版本大小約6.7MB，其中核心引擎大約3.3MB，框架+應用程序代碼大約是1.25MB，LICENSE文件（包含在app.flx中）是55k，必需的Java代碼.dex爲40k，而且約有2.1MB的ICU數據。考慮到目前網絡環境，包大小的增長，還也在能夠接受的範圍。

4.3 Crash

iOS運行官方的例子，會有時候crash掉，所以咱們將一個開源的Flutter應用，添加了Bugly上報，在Android平臺進行了衆測。

參與人次大概150人左右，啓動次數大概500次左右，沒有出現一次Crash數據上報，因爲app很簡單，並不能說明不少問題，可是衆測用戶反饋了約12條信息，其中1條是相似於ANR，沒法操做，其他的部分則是卡頓相關的反饋。

4.4 流暢性

將官方的例子發給測試同窗，讓在iOS以及Android平臺的不一樣機子上運行了下。在iOS上基本上流暢運行，沒有出現卡頓的現象，在Android部分設備上，出現了卡頓的現象。

因爲沒有複雜的例子，其實這個流暢性的測試，意義不是特別大，官方簡單的控件展現demo程序，自己就很簡單，可是在Android上仍是出現了很多問題，只能說明總體還有很是大的優化空間。

4.5 編寫複雜程度

試着照着一張設計稿進行了簡單的純佈局代碼工做，初次接觸用起來仍是比較複雜，尤爲是那恐怖的嵌套層級，對代碼維護來講絕對是個問題，並且因爲Flutter的widget機制，不少組件只支持最基本的操做，例如一些擴展的屬性，都得本身去實現，何況如今組件庫還不是很是的豐富。代碼量也比較多，整個代碼大概有500行左右，還只是不涉及到一些交互以及數據綁定等。

從運行效果看，仍是比較的不錯，二者還原的效果都挺不錯的。

4.6 結論

若是是我的而言，我以爲能夠放心大膽的去學習嘗試，若是本身開發app的話，能夠寫一套代碼，在多個平臺運行發佈。

若是是商業團隊，這個就要自行取捨，目前而言，Flutter生態仍是很是的不完善，相關的資料也很是少。目前處於beta 3階段，多久能到release，可否到release，都是個未知數，並且，用Flutter，最大的風險，就是項目總體的不可把控，一旦出現一些坑，若是能填好，那還行，若是涉及到沒法解決的問題，就只能放棄。所以看本身團隊人力以及時間合理安排比較合適。目前看阿里的鹹魚團隊在研究Flutter。

若是單純從Flutter自己可以解決的問題的方面出發，使用Flutter確實可以產生必定的收益，節省開發成本，若是考慮到目前坑比較多的情況，加上踩坑的時間，可能就沒法去評估了。

整體來講，Flutter確實是一個比較不錯的東西，若是谷歌可以把它發展的比較完善，對於我的以及小團隊來講，確實是個福音。

5. 後話

筆者建了一個Flutter學習相關的項目，Github地址，裏面包含了筆者寫的關於Flutter學習相關的一些文章，會按期更新，也會上傳一些學習Demo，歡迎你們關注。

6. 參考

1. Flutter中文網
2. Google 悄悄開發的全新操做系統 Fuchsia 被發現了！
3. 爲何Flutter會選擇 Dart ？
4. Flutter教程(二) 瞭解Dart語言
5. 爲何移動端跨平臺開發不靠譜？
6. 爲何說Flutter是革命性的？