本文由玉剛說寫作平臺提供寫作贊助，版權歸玉剛說微信公眾號所有
原作者：Xiasm
版權宣告：未經玉剛說許可，不得以任何形式轉載
前言
自從今年google IO大會推出flutter跨平臺開發框架以來，flutter在各個技術論壇裡被吵得如日中天。flutter團隊直言flutter可以幫助開發者輕鬆實現恆定60fps的效能體驗。這裡附上flutter官方效能介紹：flutter應用程式效能介紹
我們知道flutter跨平臺的原理是採用dart語言預編譯的方式直接編譯出各個平臺的原生程式碼，而不需要類似RN用JavaScript橋接器執行原生程式碼。那麼這樣做的效能究竟如何呢？是否能達到和原生一樣的流暢度，是否如官方所說達到恆定60fps的效能體驗？今天我們就以android為例從幾個不同的維度來實際測試一下！
安裝包對比
我們分別用 flutter 和 android 原生來編寫一個ui效果一模一樣的 apk，然後打出 release 版本的安裝包，為了保證測試結果的可靠性，我們不引入任何第三方庫，只用框架提供的控制元件做一些簡單ui，這裡附上demo原始碼：flutter demo，android demo。好了，我們打出各自的release版本apk，然後使用AndroidStudio自帶的APK Analyzer進行分析，如下圖：
android原生apk
flutter apk
- apk 大小
可以明確的看出來，原生的安裝包要比 flutter 安裝包小約 6M 左右。
- classes.dex 大小 看 dex 大小你會不會很奇怪，原生的 classes.dex 竟然比 flutter 版的dex大六百多KB，這是因為原生的 dex 裡引入了 support 庫和各種基礎控制元件(ImageView TextView等等)，而 flutter 的 dex 裡面沒有support庫，也沒有原生控制元件，實際上 flutter 實現了一套自己的控制元件，包括 Material Design 和 Cupertino（iOS風格的widget）。
- res 對比 可以看到原生的資原始檔要比 flutter 大約200多k，而我們專案中沒有編寫任何資原始檔，所以這些資原始檔大多是 support 包和 sdk 自帶的。
- lib 庫
大家可能會發現，我們的 flutter 版 app 多出了一個 lib 庫，開啟裡邊是一個 libflutter.so，因為 Flutter 引擎是用 C、C++ 來編寫的，在 android 上會使用 ndk 編譯，在 iOS 上使用 LLVM 編譯，而我們自己寫的 dart 程式碼會通過 AOT 編譯成各個平臺的原生程式碼。
通過對比我們瞭解到，flutter 版的 apk 大小會比 android 原生的多出約 6M 左右，其中核心引擎大約 3.2MB，框架+應用程式程式碼大約是 1.25MB，必需的 Java 程式碼 .dex 將近 60k，而 assets 檔案裡還約有 2.1MB 的 ICU 資料等，單純從安裝包上來說，原生是要優於 flutter 的。
執行效能測試
為了測試覆蓋更加充分，我們分別在 debug 和 release 模式上進行效能測試。而據官方介紹 flutter 的 debug 模式在效能上是要略於 release 版的，所以他們提供了 profile 模式供我們測試，profile 模式編譯和啟動 Flutter 應用程式幾乎與 release 模式完全相同。
我們先看 android 原生的 debug 和 flutter 的 proflle 模式效能對比,這裡我們用 Android Profiler 進行效能指標檢測，demo 只有一個介面，用 ListView 展示 10000 條資料。下面看圖：
android原生debug效能檢測圖
flutter profile效能檢測圖
- CPU資源佔用 首先，我們看 CPU 的佔用，在啟動的時候，android 原生對 cpu 的佔用峰值在 26.8%，而且幾乎是比較平穩的變化，而 flutter 對 cpu 的佔用峰值達到了 35.5%，是一種很陡峭的形態，然後在大約十六七秒的時候，分別滑動了 listview， android 原生對 cpu 資源的佔用峰值約 23%，而flutter約 22.5%。從圖中也可以看得出，flutter 對 cpu 資源的佔用是突然之間佔用很高，而 android 則相對平穩一些。
- 記憶體佔用 記憶體佔用表現上兩者都很相似，android 原生在啟動時佔用記憶體最高達到 58.1MB，而 flutter 則為 72MB，在滑動 listview 的時候，兩者表現也很一致，都沒有突然出現很高的記憶體佔用。達到穩定狀態後，android 原生記憶體佔用穩定在35MB，而 flutter 為 52.5MB。
debug 和profile 模式的效能測試如果你還不放心的話，那麼下面我分別打包出用 flutter 和 android 原生構建出的release apk，然後將手機開啟ROOT許可權，以便可以用 Android Profiler 檢測到這兩個版本的程式，進行效能測試。下面看圖：
android原生效能檢測圖
flutter 效能檢測圖
我在開啟 app 並鎖定當前程式後，分別在大約第 10 秒的時候，用手指輕輕滑動了 ListView，下面我們分析下兩種方式的資源佔用情況。
- CPU資源佔用 首先，我們看 CPU 的佔用，正常情況下，兩者都沒有佔用多少 CPU 資源，當我滑動 listview 的時候，原生的大約會佔用最高 7.7% 的 CPU 資源，而 flutter 版的則佔用高一些，峰值大概在 18.8%。
- 記憶體佔用
原生的app記憶體佔用維持在 12M 左右，而 flutter 版的則維持在 21M 左右，原生應用比 flutter 大約低了 9M 的記憶體佔用。
從上邊兩種模式的效能檢測結果分析我們可以總結出，flutter 應用在 CPU 和記憶體的資源佔用上會比原生方式多一些，所以單純的從效能上來說，android 原生是肯定要優於 flutter 的，但是從使用者體驗上來說，兩者的滑動同樣順暢無比，幾乎感覺不到差別。
應用啟動對比
啟動是我們衡量一個應用程式效能的重要指標，下面我先通過一個 gif 來演示下 android 版和 flutter 版啟動 app 的體驗：
看得出，android 版和 flutter 版從啟動體驗上來說幾乎不相上下。這裡我大膽做一個猜測，flutter app的啟動機制和原生還是一模一樣，所以呼叫啟動 Application 也是建立 ActivityThread 然後最終執行 Application 的 onCreate 方法，所以從啟動上來說相差無幾。下面我貼出 android 原生和 flutter 版的啟動trance檔案，
android原生trance檔案
flutter trance檔案
trance 檔案幾乎一模一樣，我一度都懷疑是自己弄錯了，然後又仔細確認了一下沒出錯才放心，可以得出結論，flutter 版的啟動流程跟原生是一模一樣的。
flutter 60幀/秒的重新整理率測試
Flutter 官方指出其旨在提供 60 幀/秒的重新整理率，60 fps 意味著大約平均每 16 ms 渲染一幀。我們知道，當 UI 不能平滑的渲染時就會出現掉幀。舉個例子，假如有一幀執行的東西太多，花費了 160 ms 的時間去渲染，這段期間就會產生丟幀現象，從而就會看到動畫出現了明顯的抖動。flutter release 版本是沒法去測試渲染指數的，這裡我們還是以 profile 模式執行，然後在用官方給我們提供的 Flutter Inspector 工具去展示 fps 變化。下面看 Gif 圖：
我的手機是小米Note 2，高通驍龍821處理器 4G 記憶體，效能大概屬於 Anroid 陣營中上等。我開啟 app 後先是平穩的滑動 listview，然後又快速的滑動，由圖可看出，重新整理率起初恆定在 60fps，當我快速滑動的時候，重新整理率大約保持在58~59 之間，所以 flutter 官方所說 fps 恆定在 60fps 還是可信的。
總結
通過以上的分析，我們可以很明確的得出結論，android 原生在記憶體、CPU 資源佔用方面要低於 flutter，並且安裝包的體積也要小於 flutter，所以，不考慮其他因素，單純從效能角度來說，android 原生肯定是要優於 flutter 的。但 flutter 也有它的優點，比如跨平臺的開發、毫秒級的熱過載等等，另外跨端開發也逐漸的流行起來，所以，我們在學好android原生的基礎上，對跨端開發也要抱有積極的心態。