如何評價 Google 的 Flutter？

Flutter is a new way to build high-performance, cross-platform mobile apps. Flutter is optimized for today"s, and tomorrow"s, mobile devices. We are focused on low-latency input and high frame rates on Android and iOS.

這是項目文檔的第一句話，很簡單扼要，不用翻譯了吧。Fuchsia 項目文檔也在顯著位置提到了Fuchsia 應用必須使用 Dart+Flutter 寫 Fuchsia 應用。

說它是框架簡單了點，目前項目狀況的確達不到可用的程度，但是隨著 Fuchsia 的演進，這個框架必然會是一個移動應用開發的大趨勢。

目前手機應用開發界的狀況是一個應用兩個團隊，兩個平台，兩套代碼。這是很不正常的，有諸多大神各顯神通，用各種方案妄圖解決跨平台開發問題：PhoneGap, Kivy, Python for Android/iOS, Cocos2d-x 等，每個解決方案都有諸多不便。說明要解決這個問題很難，自操作系統外部出發是解決不了的，OS 層面、開發模式的改變是必然的。

還有，Flutter 開發速度其實可以很快的，已經2年為何沒有產品化呢？也是因為需要等待 Fuchsia的出世。

其核心特性有：

• 使用 skia 幾乎實現了所有系統控制項，達到了跨平台，這是相比ReactiveNative的優勢
• 和 NativeCode 無縫集成，不會受系統制約，但是和 WebView 等交互(Cookie同步)將比較困難
• 界面編程理念完全不一樣了，每個控制項都是最輕量級的，只有動畫時需要保留實例，數據改變後更新後才創建
• 整個應用都是單線程的，耗時任務可能必須採用非同步方式，好在 Dart 的非同步設計非常優秀，應該不會重蹈Brew的覆轍
• 優秀的 Hot Reload 表現能創造無數可能

5/9 更新

1. flutter 的熱更新(hot reload)可以用驚才絕艷來形容。還支持調試期更新，能節約開發大量時間，演示圖:
   https://flutter.io/images/intellij/hot-reload.gif
2. flutter 的演示程序(flutter gallery)也已經很完善了
3. 插件(plugins)還很不足夠，dartlang (Search results for flutter) 里和 flutter 相關的庫只有不到50個。
4. 演示程序下載。Flutter Gallery APK(https://pan.baidu.com/s/1kVLsiLD)

瀉藥。

與其評價 Flutter ，不如拿 Flutter 和 Facebook 的 ReactNative 做個對比。

前兩天的 GDD 我也和 Flutter 的開發專家來了一次面對面的交談，以下是總結。

1、跨平台 + ReactNative + Flutter

ReactNative 大家應該不陌生。不過我還是簡單的介紹下， ReactNative 的簡稱是 RN ，是前幾年 Facebook 開源的一個跨平台的框架。

什麼是跨平台？

如果你是移動開發者的話，應該知道 Android 是使用 Java 語言來開發而 iOS 則是 OC 來開發，當然我說的是通常情況下使用這兩種語言來開發的。

所以各大科技圈大佬們都在絞盡腦汁的想統一這兩個平台，無論 Android 還是 iOS 都是移動端，若能統一用一套語言開發應用那最好不過的。這也正是跨平台的意思，簡單的說就是你寫的同一套代碼可以運行在不同的平台。

而 ReactNative 正是跨平台的產品，在 JavaScript 和 React 的基礎上你可以獲得完全一致的開發體驗。你若是 Android 開發者也可以很輕鬆的開發出來 iOS 的產品。

那麼 Flutter 是什麼？

其實這也是一個跨平台的框架，在 GDD 會議之前我其實並不了解這個。這是 Google 在近年來開發出來的一個框架，也是用來達到跨平台的效果。不過現在還處於 Alpha 階段。

2、Flutter 和 ReactNative 的區別

一個是 Facebook 推出兩年多的 RN ，另一個則是 Google 這種頂級科技公司的產品。那麼它們有什麼區別呢？

玩過 ReactNative 的朋友應該或多或少看過它的源碼，從實現原理上來講 ReactNative 提供的組件都是繼承自原生 Native 的 View 組件，比如ReactNative 中的 ListView 在 Android 中就是繼承自 ListView ，還有 RecycleView。

然而 Flutter 則不同，它的所有 UI 組件都是一幀一幀畫出來的。這樣也能夠很準確，也很靈活的做出你想要的 UI 。其次它還非常人性化的貼近了平台的特性，比如 Android 的 Material Design 在 Flutter 就默認支持了進去。

其實話說回來，在開發者角度來講這兩個跨平台都是一樣的使用效果，畢竟都是通過一套語言來搭建可運行不同平台的應用。然而，Flutter 使用 Dart 語言開發而 ReactNative 則使用 JS 結合 XML 來開發的。這就有問題了。

3、Dart 語言開發的 Flutter 框架

相信並沒有幾個讀者知道還有 Dart 這種語言，說實話在這次大會之前我也不知道。不過還好在那場會議上面，他們的工程師親自演示了用 Dart 語言的 Flutter 來搭建了一個應用。也著實讓我大跌眼鏡。

為什麼這麼說呢？因為用 Dart 語言來寫界面真的是看著很不友好。我來貼一段代碼，這是用 Dart 寫的一個簡單的 UI 組件。

作為初次了解到 Dart 得我一眼看去，真的不知道這寫了個什麼。因為括弧太多了，各種嵌套。而且是直接將子 View 整段嵌進去，如果這個 View 更加複雜的話，你就會看到更多的嵌套。

而相比 ReactNative 中 JS 和 XML 的寫法，無論從邏輯上可通讀性都是有一定差距的：

其實話說白了，這也正是 Dart 和 JS 的區別。今天我也抽空搜了下 Dart 這個語言，說 Dart 是非常有能力替代 JS 的代碼，而且 Dart 的開發者也是這麼認為的。他們的目標就是 JS 的開發者會選擇用 Dart 來開發。但。。。

4、為什麼Flutter 用 Dart 開發

在會後，我也主動的去找 Flutter 的開發專家 Divod 聊了會。我問到他一個問題，我說為什麼你們會選擇用 Dart 語言來開發而不選擇用XML 和 JS ，從剛才您的代碼示例上我的第一感覺就是沒有 ReactNative 的可讀性高。

大家也許覺得我太大膽，在 Google 的場子提 Facebook 的東西。但技術畢竟是技術，程序員何苦為難程序員，這是一場技術的交流。最後，他也給了我一個滿意和無力反駁的答案，「因為 Dart 的開發團隊就在他們旁邊，他們能給到我們很快的支持。我們能很快溝通到」。

所以我也就默認了 Flutter 註定會一直使用 Dart 這門語言。

5、親測 Flutter 框架

當然今天我也抽空玩了一把 Flutter 。我把之前在 ReactNative 遇到問題的情況也同樣在 Flutter 上實現了一下。

「用 ListView 載入上千張大圖」。

在 ReactNative 和 Flutter 的表現上來看內存和 CPU 的使用量並沒太大區別，但在頁面渲染上 ReactNative 並沒有 Flutter 流暢。而且圖片量越大， ReactNative 的渲染速度會更慢，甚至是會爆掉。

ReactNative

Flutter

所以，無論是 Flutter 還是 ReactNative，更或者 Weex 其實都是業界很不錯的跨平台框架。只不過從版本歷史還是開發人數上來講，我更傾向於 ReactNative。

因為我是一個 Facebook 粉。

我在過去做過若干年的動態化技術的開發，也寫過類似於 RN 的應用框架（但要早於 RN）。簡單從幾個角度對比下 Flutter RN/Weex，順便聊聊動態化技術：

1. 性能和體驗
   Flutter 由於渲染的基礎（gdi）是自己實現的，所以實現跨平台、性能優化、擺脫平台約束方面的裕度更大。從實際體驗來看， Flutter 的性能比 RN 要高不少。
   我嘗試總結下性能差異的原因以及 Flutter 架構上為「未來」留下的裕度：
   運行時語言：從前端的思維來看，jsl 或 dart 都是一種聲明式的寫法，但 jsl 需要轉譯（工程上看起來美好的東西肯定是需要在別的方面消耗更多），dart 是直接語言層面支持了 node tree 的書寫，且對象創建成本低，可直接編譯成 native 代碼（AOT），VM 效率更高。運行上應該是 dart 效率高很多。

   渲染機制：RN 是從前端思想出發的框架，其在表達複雜 UI 時需要依賴前端「盒子」的深層次疊加嵌套，在 RN 背景下，這每個「盒子」都是一個 native 的 view，這時候就相比 native 開發來說多了很多 view 對象，造成了性能降低。也就是說複雜 UI 需求下，RN 對 UI 的表達效率遠低於 native 造成性能低下。Flutter 是基於 skia (gdi) 層面網上去做的，每個 node/布局是否一定需要是一個 layer 以及 render tree 怎麼來劃分和實現都有更多靈活性和性能優化的空間，所以能做到性能更優。

   組件的兼容性：
   Flutter 提供的 widget 都是基於 skia 來實現和精心定製的，與具體平台沒關，所以能保持很高的跨 os 跨 os version 的兼容性。
2. 跨平台
   RN 是一套概念/設計理念跨越兩個平台，具體到實際平台上去還要去適配和橋接差異性（這其中有巨大的工程成本和性能犧牲，比如做動畫，js 就絕對不能用，用了性能就差了）。Flutter 至少做到了一套代碼（不涉及平台 api 層面的 UI 及純事件響應可以完全一樣）。
   Flutter 相對來說是做到了跨平台。RN 更適合稱為：將一種設計理念延展到兩個平台，不能稱其為「一套代碼，自動部署多平台」的跨平台方案。
3. 對未來的適應性
   由於 Flutter 從更基礎的層去抹平平台差異，Flutter 站在了更寬廣、更可控的一個基礎平台上去演變和發展。RN 永遠需要 follow native 開發的這套約束，橋接和抹平差異乃至應用層去適配的成本、面對具體場景去優化性能所需要的成本都是居高不下的。RN 屬於「大公司扛大旗，賺吆喝，小公司跟著復用下現有資源」。
4. 動態化技術的未來
   我個人認為 RN、weex 這類設計都是走不遠的，為什麼，動態化技術最成熟的就是 H5，所以業界（軟體公司、開發團隊）對於動態化技術的期待就是 H5，H5 是要由瀏覽器來支撐的，RN 的能力不到瀏覽器的 5%（舉例 index = 1000，絕對布局，各種動畫和複雜布局能力很難用 native 來實現，還有各種布局模型、浮動元素、css rule，不一而足），RN、Weex 是無法滿足這個期望的（面對一個複雜點兒的需求，RN、Weex 都需要 case by case 去 review，還可能需要寫 native 代碼去擴展才能實現；而 H5 保證了 99% 概率下都是可以實現的。不需要產品/業務將就「技術」）。
   對於工程而言，RN、Weex 這類方案最大的價值就是提供了一套讓傳統前端開發上手 native 開發的途徑，同時創建了一個社區用於存放可供復用的組件庫，讓小公司、小團隊能共享這部分「生態」。
5. 結論：Flutter 從設計、體驗、跨平台上都有亮點。值得關注和寄予期望。

你們說的都對，我長期押WebAssembly。