作為 GSY 開源系列的作者，在去年也整理過 《移動端跨平臺開發(fā)的深度解析》 的對比文章，時隔一年之后，本篇將重新由 環(huán)境搭建、實現(xiàn)原理、編程開發(fā)、插件開發(fā)、編譯運(yùn)行、性能穩(wěn)定、發(fā)展未來 等七個方面，對當(dāng)前的 React Native 和 Flutter 進(jìn)行全面的分析對比，希望能給你更有價值的參考。

是的，這次沒有了 Weex，超長內(nèi)容預(yù)警，建議收藏后閱。

前言

臨冬之際，移動端跨平臺在經(jīng)歷數(shù)年沉浮之后，如今還能在舞臺聚光燈下雀躍的， 也只剩下 React Native 和 Flutter 了，作為沉淀了數(shù)年的 “豪門” 與 19 年當(dāng)紅的 “新貴” ，它們之間的 “針鋒相對” 也成了開發(fā)者們關(guān)心的事情。

過去曾有人問我：“他即寫 Java 又會 Object-C ，在 Android 和 IOS 平臺上可以同時開發(fā)，為什么還要學(xué)跨平臺呢？”

而我的回答是：跨平臺的市場優(yōu)勢不在于性能或?qū)W習(xí)成本，甚至平臺適配會更耗費(fèi)時間，但是它最終能讓代碼邏輯（特別是業(yè)務(wù)邏輯），無縫的復(fù)用在各個平臺上，降低了重復(fù)代碼的維護(hù)成本，保證了各平臺間的統(tǒng)一性， 如果這時候還能保證一定的性能，那就更完美了。

一、環(huán)境搭建

無論是 React Native 還是 Flutter ，都需要 Android 和 IOS 的開發(fā)環(huán)境，也就是 JDK 、Android SDK、Xcode 等環(huán)境配置，而不同點在于 ：

• React Native 需要 npm 、node 、react-native-cli 等配置 。
• Flutter 需要 flutter sdk 和 Android Studio / VSCode 上的 Dart 與 Flutter 插件。

從配置環(huán)境上看， Flutter 的環(huán)境搭配相對簡單，而 React Native 的環(huán)境配置相對復(fù)雜，而且由于 node_module 的“黑洞”屬性和依賴復(fù)雜度等原因，目前在個人接觸的例子中，首次配置運(yùn)行成功率 Flutter 是高于 React Native 的，且 Flutter 失敗的原因則大多歸咎于網(wǎng)絡(luò)。

同時跨平臺開發(fā)首選 Mac ，沒有為什么。

二、實現(xiàn)原理

在 Android 和 IOS 上，默認(rèn)情況下 Flutter 和 React Native 都需要一個原生平臺的
Activity / ViewController 支持，且在原生層面屬于一個“單頁面應(yīng)用”， 而它們之間最大的不同點其實在于 UI 構(gòu)建 ：

• React Native ：

React Native 是一套 UI 框架，默認(rèn)情況下 React Native 會在 Activity 下加載 JS 文件，然后運(yùn)行在 JavaScriptCore 中解析 Bundle 文件布局，最終堆疊出一系列的原生控件進(jìn)行渲染。

簡單來說就是 通過寫 JS 代碼配置頁面布局，然后 React Native 最終會解析渲染成原生控件，如 <View> 標(biāo)簽對應(yīng) ViewGroup/UIView ，<ScrollView> 標(biāo)簽對應(yīng) ScrollView/UIScrollView ，<Image> 標(biāo)簽對應(yīng) ImageView/UIImageView 等。

所以相較于如 Ionic 等框架而言， React Native 讓頁面的性能能得到進(jìn)一步的提升。

• Flutter ：

如果說 React Native 是為開發(fā)者做了平臺兼容，那 Flutter 則更像是為開發(fā)者屏蔽平臺的概念。

Flutter 中只需平臺提供一個 Surface 和一個 Canvas ，剩下的 Flutter 說：“你可以躺下了，我們來自己動”。

Flutter 中絕大部分的 Widget 都與平臺無關(guān)， 開發(fā)者基于 Framework 開發(fā) App ，而 Framework 運(yùn)行在 Engine 之上，由 Engine 進(jìn)行適配和跨平臺支持。這個跨平臺的支持過程，其實就是將 Flutter UI 中的 Widget “數(shù)據(jù)化” ，然后通過 Engine 上的 Skia 直接繪制到屏幕上 。

所以從以上可以看出：React Native 的 Learn once, write anywhere 的思路，就是只要你會 React ，那么你可以用寫 React 的方式，再去開發(fā)一個性能不錯的App；而 Flutter 則是讓你忘掉平臺，專注于 Flutter UI 就好了。

• DOM：

額外補(bǔ)充一點，React 的虛擬 DOM 的概念相信大家都知道，這是 React 的性能保證之一，而 Flutter 其實也存在類似的虛擬 DOM 概念。

看過我 Flutter 系列文章可能知道，Flutter 中我們寫的 Widget ， 其實并非真正的渲染控件，這一點和 React Native 中的標(biāo)簽類似，Widget 更像配置文件， 由它組成的 Widget 樹并非真正的渲染樹。

Widget 在渲染時會經(jīng)過 Element 變化， 最后轉(zhuǎn)化為 RenderObject 再進(jìn)行繪制， 而最終組成的 RenderObject 樹才是 “真正的渲染 Dom” ， 每次 Widget 樹觸發(fā)的改變，并不一定會導(dǎo)致RenderObject 樹的完全更新。

所以在實現(xiàn)原理上 React Native 和 Flutter 是完全不同的思路，雖然都有類似“虛擬 DOM 的概念” ，但是React Native 帶有較強(qiáng)的平臺關(guān)聯(lián)性，而 Flutter UI 的平臺關(guān)聯(lián)性十分薄弱。

三、 編程開發(fā)

React Native 使用的 JavaScript 相信大家都不陌生，已經(jīng) 24 歲的它在多年的發(fā)展過程中，各端各平臺中都出沒著它的身影，在 Facebook 的 React 開始風(fēng)靡之后，15 年移動浪潮下推出的 React Native ，讓前端的 JS 開發(fā)者擁有了技能的拓展。

Flutter 的首選語言 Dart 語言誕生于 2011 年，而 2018 年才發(fā)布了 2.0，原本是為了用來對抗 JavaScript 而發(fā)布的開發(fā)語言，卻在 Web 端一直不溫不火，直到 17年 才因為 Flutter 而受關(guān)注起來，之后又因為 Flutter For Web 繼續(xù)嘗試后回歸 Web 領(lǐng)域。

編程開發(fā)所涉及的點較多，后面主要從 開發(fā)語言 、界面開發(fā) 、狀態(tài)管理 、原生控件 四個方面進(jìn)行對比介紹。

至于最多吐槽之一就是為什么 Flutter 團(tuán)隊不選擇 JS ，有說因為 Dart 團(tuán)隊就在 Flutter 團(tuán)隊隔壁，也有說谷歌不想和 Oracle 相關(guān)的東西沾上邊。
同時 React Native 更新快 4 年了，版本號依舊沒有突破 1.0 。

3.1、 語言

因為起初都是為了 Web 而生，所以 Dart 和 JS 在一定程度上有很大的通識性。

如下代碼所示， 它們都支持通過 var 定義變量，支持 async/await 語法糖，支持 Promise(Future) 等鏈?zhǔn)疆惒教幚恚踔?*/yield 的語法糖都類似(雖然這個對比不大準(zhǔn)確)，但可以看出它們確實存在“近親關(guān)系” 。

/// JS

    var a = 1

    async function doSomeThing() {
        var result = await xxxx()
        doAsync().then((res) => {
            console.log("ffff")
        })
    }
    function* _loadUserInfo () {
        console.log("**********************");
        yield put(UpdateUserAction(res.data));
    }


/// Dart

  var a = 1;

  void doSomeThing() async {
    var result = await xxxx();
    doAsync().then((res) {
      print('ffff');
    });
  }
  _loadUserInfo() async* {
    print("**********************");
    yield UpdateUserAction(res.data);
  }

但是它們之間的差異性也很多，而最大的區(qū)別就是： JS 是動態(tài)語言，而 Dart 是偽動態(tài)語言的強(qiáng)類型語言。

如下代碼中，在 Dart 中可以直接聲明 name 為 String 類型，同時 otherName 雖然是通過 var 語法糖聲明，但在賦值時其實會通過自推導(dǎo)出類型 ，而 dynamic 聲明的才是真的動態(tài)變量，在運(yùn)行時才檢測類型。

// Dart

String name = 'dart'; 
var otherName = 'Dart';
dynamic dynamicName = 'dynamic Dart'; 

如下圖代碼最能體現(xiàn)這個差異，在下圖例子中：

• var i 在全局中未聲明類型時，會被指定為 dymanic ，從而導(dǎo)致在 init() 方法中編譯時不會判斷類型，這和 JS 內(nèi)的現(xiàn)象會一致。

• 如果將 var i = ""; 定義在 init() 方法內(nèi)，這時候 i 已經(jīng)是強(qiáng)類型 String了 ，所以編譯器會在 i++報錯，但是這個寫法在 JS 動態(tài)語言里，默認(rèn)編譯時是不會報錯的。

動態(tài)語言和非動態(tài)語言都有各種的優(yōu)缺點，比如 JS 開發(fā)便捷度明顯會高于 Dart ，而 Dart 在類型安全和重構(gòu)代碼等方面又會比 JS 更穩(wěn)健。

3.2、界面開發(fā)

React Native 在界面開發(fā)上延續(xù)了 React 的開發(fā)風(fēng)格，支持 scss/sass 、樣式代碼分離、在 0.59 版本開始支持 React Hook 函數(shù)式編程 等等，而不同 React 之處就是更換標(biāo)簽名，并且樣式和屬性支持因為平臺兼容做了刪減。

如下圖所示，是一個普通 React Native 組件常見實現(xiàn)方式，繼承 Component 類，通過 props 傳遞參數(shù)，然后在 render 方法中返回需要的布局，布局中每個控件通過 style 設(shè)置樣式 等等，這對于前端開發(fā)者基本上沒有太大的學(xué)習(xí)成本。

如下所示，如果再配合 React Hooks 的加持，函數(shù)式的開發(fā)無疑讓整個代碼結(jié)構(gòu)更為簡潔。

Flutter 最大的特點在于： Flutter 是一套平臺無關(guān)的 UI 框架，在 Flutter 宇宙中萬物皆 Widget。

如下圖所示，Flutter 開發(fā)中一般是通過繼承 無狀態(tài) StatelessWidget 控件或者 有狀態(tài) StatefulWidget 控件 來實現(xiàn)頁面，然后在對應(yīng)的 Widget build(BuildContext context) 方法內(nèi)實現(xiàn)布局，利用不同 Widget 的 child / children 去做嵌套，通過控件的構(gòu)造方法傳遞參數(shù)，最后對布局里的每個控件設(shè)置樣式等。

而對于 Flutter 控件開發(fā)，目前最多的吐槽就是 控件嵌套和樣式代碼不分離 ，樣式代碼分離這個問題我就暫不評價，這個真要實際開發(fā)才能更有體會，而關(guān)于嵌套這里可以做一些 “洗白” ：

Flutter 中把一切皆為 Widget 貫徹得很徹底，所以 Widget 的顆粒度控制得很細(xì) ，如 Padding 、Center 都會是一個單獨的 Widget，甚至狀態(tài)共享都是通過 InheritedWidget 共享 Widget 去實現(xiàn)的，而這也是被吐槽的代碼嵌套樣式難看的原因。

事實上正是因為顆粒度細(xì)，所以你才可以通過不同的 Widget ， 自由組合出多種業(yè)務(wù)模版， 比如 Flutter 中常用的 Container ，它就是官方幫你組合好的模板之一， Container 內(nèi)部其實是由 Align、 ConstrainedBox 、DecoratedBox 、Padding 、Transform 等控件組合而成 ，所以嵌套深度等問題完全是可以人為控制，甚至可以在幀率和繪制上做到更細(xì)致的控制。

當(dāng)然，官方也在不斷地改進(jìn)優(yōu)化編寫和可視化的體驗，如下圖所示，從目前官方放出的消息上看，未來這個問題也會被進(jìn)一步改善。

最后總結(jié)一下，拋開上面的開發(fā)風(fēng)格，React Native 在 UI 開發(fā)上最大的特點就是平臺相關(guān)，而 Flutter 則是平臺無關(guān)，比如下拉刷新，在 React Native 中， <RefreshControl> 會自帶平臺的不同下拉刷新效果，而在 Flutter 中，如果需要平臺不同下拉刷新效果，那么你需要分別使用 RefreshIndicator 和 CupertinoSliverRefreshControl 做顯示，不然多端都會呈現(xiàn)出一致的效果。

3.3、狀態(tài)管理

前面說過， Flutter 在很多方面都借鑒了 React Native ，所以在狀態(tài)管理方面也極具“即視感”，比如都是調(diào)用 setState 的方式去更新，同時操作都不是立即生效的 ，當(dāng)然它們也有著差異的地方，如下代碼所示：

• 正常情況下 React Native 需要在 Component 內(nèi)初始化一個 this.state 變量，然后通過 this.state.name 訪問 。
• Flutter 繼承 StatefulWidget ，然后在其的 State 對象內(nèi)通過變量直接訪問和 setState 觸發(fā)更新。

/// JS

    this.state = {
       name: ""
    };
    
    ···
     
    this.setState({
        name: "loading"
    });
    
    ···
    
    <Text>this.state.name</Text>
    
    
/// Dart

    var name = "";

    setState(() {
       name =  "loading";
    });
    
    ···
    
    Text(name)

當(dāng)然它們兩者的內(nèi)部實現(xiàn)也有著很大差異，比如 React Native 受 React diff 等影響，而 Flutter 受 isRepaintBoundary 、markNeedsBuild 等影響。

而在第三方狀態(tài)管理上，兩者之間有著極高的相似度，如早期在 Flutter 平臺就涌現(xiàn)了很多前端的狀態(tài)管理框架如：flutter_redux 、fish_redux 、 dva_flutter 、flutter_mobx 等等，它們的設(shè)計思路都極具 React 特色。

同時 Flutter 官方也提供了 scoped_model 、provider 等具備 Flutter 特色的狀態(tài)管理。

所以在狀態(tài)管理上 React Native 和 Flutter 是十分相近的，甚至是在跟著 React 走。

3.4、原生控件

在跨平臺開發(fā)中，就不得不說到接入原有平臺的支持，比如 在 Android 平臺上接入 x5 瀏覽器 、接入視頻播放框架、接入 Lottie 動畫框架等等。

這一需求 React Native 先天就支持，甚至在社區(qū)就已經(jīng)提供了類似 lottie-react-native 的項目。 因為 React Native 整個渲染過程都在原生層中完成，所以接入原有平臺控件并不會是難事 ，同時因為發(fā)展多年，雖然各類第三方庫質(zhì)量參差不齊，但是數(shù)量上的優(yōu)勢還是很明顯的。

而 Flutter 在就明顯趨于弱勢，甚至官方在開始的時候，連 WebView 都不支持，這其實涉及到 Flutter 的實現(xiàn)原理問題。

因為 Flutter 的整體渲染脫離了原生層面，直接和 GPU 交互，導(dǎo)致了原生的控件無法直接插入其中 ，而在視頻播放實現(xiàn)上， Flutter 提供了外界紋理的設(shè)計去實現(xiàn)，但是這個過程需要的數(shù)據(jù)轉(zhuǎn)換，很明顯的限制了它的通用性， 所以在后續(xù)版本中 Flutter 提供了 PlatformView 的模式來實現(xiàn)集成。

以 Android 為例子，在原生層 Flutter 通過 Presentation 副屏顯示的原理，利用 VirtualDisplay 的方式，讓 Android 控件在內(nèi)存中繪制到 Surface 層。 VirtualDisplay 繪制在 Surface 的 textureId ，之后會通知到 Dart 層，在 Dart 層利用 AndroidView 定義好的 Widget 并帶上 textureId ，那么 Engine 在渲染時，就會在內(nèi)存中將 textureId 對應(yīng)的數(shù)據(jù)渲染到 AndroidView 上。

PlatformView 的設(shè)計必定導(dǎo)致了性能上的缺陷，最大的體現(xiàn)就是內(nèi)存占用的上漲，同時也引導(dǎo)了諸如鍵盤無法彈出#19718和黑屏等問題，甚至于在 Android 上的性能還可能不如外界紋理。

所以目前為止， Flutter 原生控件的接入上是仍不如 React Native 穩(wěn)定。

四、 插件開發(fā)

React Native 和 Flutter 都是支持插件開發(fā)，不同在于 React Native 開發(fā)的是 npm 插件，而 Flutter 開發(fā)的是 pub 插件。

React Native 使用 npm 插件的好處就是：可以使用豐富的 npm 插件生態(tài)，同時減少前端開發(fā)者的學(xué)習(xí)成本。

但是使用 npm 的問題就是太容易躺坑，因為 npm 包依賴的復(fù)雜度和深度所惑，以至于你都可能不知道 npm 究竟裝了什么東西，拋開安全問題，這里最直觀的感受就是 ：“為什么別人跑得起來，而我的跑不起來？” 同時每個項目都獨立一個 node_module ，對于硬盤空間較小的 Mac 用戶略顯心酸。

Flutter 的 pub 插件默認(rèn)統(tǒng)一管理在 pub 上，類似于 npm 同樣支持 git 鏈接安裝，而 flutter packages get 文件一般保存在電腦的統(tǒng)一位置，多個項目都引用著同一份插件。

• win 一般是在 C:\Users\xxxxx\AppData\Roaming\Pub\Cache 路徑下
• mac 目錄在 ~/.pub-cache

如果找不到插件目錄，也可以通過查看 .flutter-plugins 文件，或如下圖方式打開插件目錄，至于為什么需要打開這個目錄，感興趣的可以看看這個問題 13# 。

最后說一下 Flutter 和 React Native 插件，在帶有原生代碼時不同的處理方法：

• React Native 在安裝完帶有原生代碼的插件后，需要執(zhí)行 react-native link 腳本去引入支持，具體如 Android 會在 setting.gradle 、 build.gradle 、MainApplication.java 等地方進(jìn)行侵入性修改而達(dá)到引用。

• Flutter 則是通過 .flutter-plugins 文件，保存了帶有原生代碼的插件 key-value 路徑 ，之后 Flutter 的腳本會通過讀取的方式，動態(tài)將原生代碼引入，最后通過生成 GeneratedPluginRegistrant.java 這個忽略文件完成導(dǎo)入，這個過程開發(fā)者基本是無感的。

所以在插件這一塊的體驗， Flutter 是略微優(yōu)于 React Native 的。

五、 編譯和產(chǎn)物

React Native 編譯后的文件主要是 bundle 文件，在 Android 中是 index.android.bunlde 文件，而在 IOS 下是 main.jsbundle 。

Flutter 編譯后的產(chǎn)物在 Android 主要是 ：

• isolate_snapshot_instr 應(yīng)用程序指令段
• isolate_snapshot_data應(yīng)用程序數(shù)據(jù)段
• vm_snapshot_data 虛擬機(jī)數(shù)據(jù)段
• vm_snapshot_instr 虛擬機(jī)指令段等產(chǎn)物

?注意，1.7.8 之后的版本，Android 下的 Flutter 已經(jīng)編譯為純 so 文件。

在 IOS 主要是 App.framework ，其內(nèi)部也包含了 kDartVmSnapshotData 、kDartVmSnapshotInstructions 、 kDartIsolateSnapshotData 、kDartIsolateSnapshotInstructions 四個部分。

接著看完整結(jié)果，如下圖所示，是空項目下 和 GSY 實際項目下， React Native 和 Flutter 的 Release 包大小對比。

可以看出在 React Native 同等條件下，Android 比 IOS 大很多 ，這是因為 IOS 自帶了 JSCore ，而 Android 需要各類動態(tài) so 內(nèi)置支持，而且這里 Android 的動態(tài)庫 so 是經(jīng)過了 ndk 過濾后的大小，不然還會更大。

Flutter 和 React Native 則是相反，因為 Android 自帶了 skia ，所以比沒有自帶 skia 的 IOS 會小得多。

以上的特點在 GSY 項目中的 Release 包也呈同樣狀態(tài)。

類型	React Native	Flutter
空項目 Android	Rn Android ndk abiFilters arm64-v8a	Flutter Android
空項目 IOS	Rn IOS	Flutter IOS
GSY Android	GSYGIthubApp.apk	GSYGithubAppFlutter.apk
GSY IOS	GSYGithubAPP.ipa	GSYGithubAppFlutter.ipa

值得注意的是，Google Play 最近發(fā)布了 《8月不支持 64 位，App 將無法上架 Google Play！》 的通知 ，同時也表示將停止 Android Studio 32 位的維護(hù)，而 arm64-v8a 格式的支持，React Native 需要在 0.59 以后的版本才支持。

至于 Flutter ，在打包時通過指定 flutter build apk --release --target-platform android-arm64 即可。

六、性能

說到性能，這是一個大家都比較關(guān)心的概念，但是有一點需要注意，拋開場景說性能顯然是不合適的，因為性能和代碼質(zhì)量與復(fù)雜度是有一定聯(lián)系的。

先說理論性能，**在理論上 Flutter 的設(shè)計性能是強(qiáng)于 React Native ** ，這是框架設(shè)計的理念導(dǎo)致的，F(xiàn)lutter 在少了 OEM Widget ，直接與 CPU / GPU 交互的特性，決定了它先天性能的優(yōu)勢。

這里注意不要用模擬器測試性能，特別是IOS模擬器做性能測試，因為 Flutter 在 IOS模擬器中純 CPU ，而實際設(shè)備會是 GPU 硬件加速，同時只在 Release 下對比性能。

代碼的實現(xiàn)方式不同，也可能會導(dǎo)致性能的損失，比如 Flutter 中 skia 在繪制時，saveLayer 是比較消耗性能的，比如 透明合成、clipRRect 等等，都會可能需要 saveLayer 的調(diào)用， 而 saveLayer 會清空GPU繪制的緩存，導(dǎo)致性能上的損耗，從而導(dǎo)致開發(fā)過程中如果掉幀嚴(yán)重。

最后如下圖所示，是去年閑魚用 GSY 項目做測試對比的數(shù)據(jù)，原文在《流言終結(jié)者- Flutter和RN誰才是更好的跨端開發(fā)方案？》 ，可以看出在去年的時候， Flutter的整體幀率和繪制就有了明顯的優(yōu)勢。

額外補(bǔ)充一點，JS 和 Dart 都是單線程應(yīng)用，利用了協(xié)程的概念實現(xiàn)異步效果，而在 Flutter 中 Dart 支持的 isolate ，卻是屬于完完全全的異步線程處理，可以通過 Port 快捷地進(jìn)行異步交互，這大大拓展了 Flutter 在 Dart 層面的性能優(yōu)勢。

七、發(fā)展未來

之前一篇 《為什么 Airbnb 放棄了 React Native?》 文章，讓眾多不明所以的吃瓜群眾以為 React Native 已經(jīng)被放棄，之后官方發(fā)布的
《Facebook 正在重構(gòu) React Native，將重寫大量底層》 公示，又再一次穩(wěn)定了軍心。

同時 React Native 在 0.59 版本開始支持 React Hook 等特性，并將原本平臺的特性控件從 React Native 內(nèi)部剝離到社區(qū)，這樣控件的單獨升級維護(hù)可以更加便捷，同時讓 React Native 與 React 之間的界限越發(fā)模糊。

Flutter UI 平臺的無關(guān)能力，讓 Flutter 在跨平臺的拓展上更為迅速，盡管 React Native 也有 Web 和 PC 等第三方實現(xiàn)拓展支持，但是由于平臺關(guān)聯(lián)性太強(qiáng)，這些年發(fā)展較為緩慢， 而 Flutter 則是短短時間又宣布 Web 支持，甚至拓展到 PC 和嵌入式設(shè)備當(dāng)中。

這里面對于 Flutter For Web 相信是大家最為關(guān)心的話題， 如下圖所示，在 Flutter 的設(shè)計邏輯下，開發(fā) Flutter Web 的過程中，你甚至感知不出來你在開發(fā)的是 Web 應(yīng)用。

Flutter Web 保留了 大量原本已有的移動端邏輯，只是在 Engine 層利用 Dart2Js 的能力實現(xiàn)了差異化， 不過現(xiàn)階段而言，F(xiàn)lutter Web 仍處在技術(shù)預(yù)覽階段，不建議在生產(chǎn)環(huán)境中使用 。

由此可以推測，不管是 Flutter 或者 React Native，都會努力將自己拓展到更多的平臺，同時在自己的領(lǐng)域內(nèi)進(jìn)一步簡化開發(fā)。

• 其他參考資料 ：

《Facebook 正在重構(gòu) React Native，將重寫大量底層》

《React Native 的未來與React Hooks》

《庖丁解牛！深入剖析 React Native 下一代架構(gòu)重構(gòu)》

《Flutter 最新進(jìn)展與未來展望》

自此，本文終于結(jié)束了，長呼一口氣。

資源推薦

• Github ： https://github.com/CarGuo
• 開源 Flutter 項目：https://github.com/CarGuo/GSYGithubAppFlutter
• 開源 React Native 項目：https://github.com/CarGuo/GSYGithubApp
• 開源 Fluttre 實戰(zhàn)電子書項目：https://github.com/CarGuo/GSYFlutterBook

文章

《Flutter完整開發(fā)實戰(zhàn)詳解系列》
《移動端跨平臺開發(fā)的深度解析》

GSYTech