這篇文章主要介紹“分析Flutter應(yīng)用性能檢測與優(yōu)化”，在日常操作中，相信很多人在分析Flutter應(yīng)用性能檢測與優(yōu)化問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”分析Flutter應(yīng)用性能檢測與優(yōu)化”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

10年積累的成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有四子王免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

圖層分析

Flutter運(yùn)行模式

1、Debug

Debug模式可以在真機(jī)和模擬器上同時(shí)運(yùn)行，此模式會打開所有的斷言，包括debugging信息、debugger aids（比如observatory）和服務(wù)擴(kuò)展。優(yōu)化了快速develop/run循環(huán)，但是沒有優(yōu)化執(zhí)行速度、二進(jìn)制大小和部署。命令flutter run就是以這種模式運(yùn)行的，通過sky/tools/gn --android或者sky/tools/gn --ios來構(gòu)建應(yīng)用的。

2、Release

Release模式只能在真機(jī)上運(yùn)行，不能在模擬器上運(yùn)行：會關(guān)閉所有斷言和debugging信息，關(guān)閉所有debugger工具。優(yōu)化了快速啟動、快速執(zhí)行和減小包體積。禁用所有的debugging aids和服務(wù)擴(kuò)展。這個(gè)模式是為了部署給最終的用戶使用。命令flutter run --release就是以這種模式運(yùn)行的，通過sky/tools/gn --android --runtime-mode=release或者sky/tools/gn --ios --runtime-mode=release來構(gòu)建應(yīng)用。

3、Profile

Profile模式只能在真機(jī)上運(yùn)行，不能在模擬器上運(yùn)行，基本和Release模式一致，除了啟用了服務(wù)擴(kuò)展和tracing，以及一些為了最低限度支持tracing運(yùn)行的東西（比如可以連接observatory到進(jìn)程）。命令flutter run --profile就是以這種模式運(yùn)行的，通過sky/tools/gn --android --runtime-mode=profile或者sky/tools/gn --ios --runtime-mode=profile來構(gòu)建應(yīng)用。

4、test

headless test模式只能在桌面上運(yùn)行，基本和Debug模式一致，除了是headless的而且你能在桌面運(yùn)行。命令flutter test就是以這種模式運(yùn)行的，通過sky/tools/gn來build。

在實(shí)際開發(fā)中，應(yīng)該用到上面所說的四種模式又各自分為兩種：一種是未優(yōu)化的模式，供開發(fā)人員調(diào)試使用；一種是優(yōu)化過的模式，供最終的開發(fā)人員使用。默認(rèn)情況下是未優(yōu)化模式，如果要開啟優(yōu)化模式，build的時(shí)候在命令行后面添加--unoptimized參數(shù)。

不管是移動開發(fā)還是前端開發(fā)，對于性能問題分析的思路都是先分析并定位問題，F(xiàn)lutter也不例外，借助Flutter 提供的度量性能工具，我們可以快速定位代碼中的性能問題，而性能圖層就是幫助我們確認(rèn)問題影響范圍的利器，它類似Android的圖層分析工具。

為了使用性能圖層，F(xiàn)lutter提供了分析（Profile）模式，與調(diào)試代碼可以通過模擬器在調(diào)試模式下找到代碼邏輯 Bug 不同，性能問題需要在發(fā)布模式下使用真機(jī)進(jìn)行檢測。相比發(fā)布（Release）模式而言，調(diào)試模式增加了很多額外的檢查（比如斷言），這些檢查可能會耗費(fèi)很多資源；更重要的是，調(diào)試模式使用 JIT （即時(shí)編譯）模式運(yùn)行應(yīng)用，代碼執(zhí)行效率較低。這就使得調(diào)試模式運(yùn)行的應(yīng)用，無法真實(shí)反映出它的性能問題。

而另一方面，模擬器使用的指令集為 x86，而真機(jī)使用的指令集是 ARM，由于這兩種方式的二進(jìn)制代碼執(zhí)行行為完全不同，因此模擬器與真機(jī)的性能差異較大。一些 x86 指令集擅長的操作模擬器會比真機(jī)快，而另一些操作則會比真機(jī)慢，這也使得我們無法使用模擬器來評估真機(jī)才能出現(xiàn)的性能問題。

為了調(diào)試性能問題，我們需要在發(fā)布模式的基礎(chǔ)之上，為分析工具提供少量必要的應(yīng)用追蹤信息，這就是分析模式。除了一些調(diào)試性能問題必須的追蹤方法之外，F(xiàn)lutter 應(yīng)用的分析模式和發(fā)布模式的編譯和運(yùn)行是類似的，只是啟動參數(shù)變成了 profile 而已。我們可以在 Android Studio 中通過菜單欄點(diǎn)擊 【Run】-【Profile 】‘main.dart’ 選項(xiàng)啟動應(yīng)用，也可以通過命令行參數(shù) flutter run --profile 運(yùn)行 Flutter 應(yīng)用。

渲染問題分析

在完成了應(yīng)用啟動之后，接下來我們就可以利用 Flutter 提供的渲染問題分析工具，即性能圖層（Performance Overlay）來分析渲染問題了。性能圖層會在當(dāng)前應(yīng)用的最上層，以 Flutter 引擎自繪的方式展示 GPU 與 UI 線程的執(zhí)行圖表，而其中每一張圖表都代表當(dāng)前線程最近 300 幀的表現(xiàn)，如果 UI 產(chǎn)生了卡頓（跳幀），這些圖表可以幫助我們分析并找到原因，如下圖所示。

上圖演示了性能圖層的展現(xiàn)樣式。其中，GPU 線程的性能情況在上面，UI 線程的情況顯示在下面，藍(lán)色垂直的線條表示已執(zhí)行的正常幀，綠色的線條代表的是當(dāng)前幀。

同時(shí)，為了保持 60Hz 的刷新頻率，GPU 線程與 UI 線程中執(zhí)行每一幀耗費(fèi)的時(shí)間都應(yīng)該小于 16ms（1/60 秒）。在這其中有一幀處理時(shí)間過長，就會導(dǎo)致界面卡頓，圖表中就會展示出一個(gè)紅色豎條，如下圖所示。

如果紅色豎條出現(xiàn)在 GPU 線程圖表，意味著渲染的圖形太復(fù)雜，導(dǎo)致無法快速渲染；而如果是出現(xiàn)在了 UI 線程圖表，則表示 Dart 代碼消耗了大量資源，需要優(yōu)化代碼執(zhí)行時(shí)間。

GPU問題定位

GPU渲染問題主要集中在底層渲染耗時(shí)上，有時(shí)候 Widget 樹雖然構(gòu)造起來容易，但在 GPU 線程下的渲染卻很耗時(shí)。例如，涉及 Widget 裁剪、蒙層這類多視圖疊加渲染，或是由于缺少緩存導(dǎo)致靜態(tài)圖像的反復(fù)繪制，都會明顯拖慢 GPU 的渲染速度。

接下來，使用性能圖層提供的兩項(xiàng)參數(shù)，即檢查多視圖疊加的視圖渲染開關(guān) checkerboardOffscreenLayers和檢查緩存的圖像開關(guān)checkerboardRasterCacheImages來檢查這兩種情況。

checkerboardOffscreenLayers

多視圖疊加通常會用到 Canvas 里的 savaLayer 方法，這個(gè)方法在實(shí)現(xiàn)一些特定的效果（比如半透明）時(shí)非常有用，但由于其底層實(shí)現(xiàn)會在 GPU 渲染上涉及多圖層的反復(fù)繪制，因此會帶來較大的性能問題。

對于 saveLayer 方法使用情況的檢查，我們只需要在 MaterialApp 的初始化方法中，將 checkerboardOffscreenLayers 開關(guān)設(shè)置為 true，分析工具就會自動幫我們檢測多視圖疊加的情況。使用了 saveLayer 的 Widget 會自動顯示為棋盤格式，并隨著頁面刷新而閃爍。不過，saveLayer 是一個(gè)較為底層的繪制方法，因此我們一般不會直接使用它，而是會通過一些功能性 Widget，在涉及需要剪切或半透明蒙層的場景中間接地使用。所以一旦遇到這種情況，我們需要思考一下是否一定要這么做，能不能通過其他方式來實(shí)現(xiàn)呢？

比如下面的例子中，我們使用 CupertinoPageScaffold 與 CupertinoNavigationBar 實(shí)現(xiàn)了一個(gè)動態(tài)模糊的效果，代碼如下：

CupertinoPageScaffold(    navigationBar: CupertinoNavigationBar(),//動態(tài)模糊導(dǎo)航欄      child: ListView.builder(        itemCount: 100,        //為列表創(chuàng)建100個(gè)不同顏色的RowItem        itemBuilder: (context, index)=>TabRowItem(              index: index,              lastItem: index == 100 - 1,              color: colorItems[index],//設(shè)置不同的顏色              colorName: colorNameItems[index],            )      )  );

其中，模糊的NavigationBar效果如下圖所示。

當(dāng)我們開啟checkerboardOffscreenLayers之后，可以看到視圖蒙層效果對GPU的渲染壓力導(dǎo)致性能視圖頻繁閃動。如果我們沒有對動態(tài)模糊效果有特殊需求，則可以使用不帶模糊效果的 Scaffold 和白色的 AppBar 實(shí)現(xiàn)同樣的產(chǎn)品功能，來解決這個(gè)性能問題。

Scaffold(    //使用普通的白色AppBar    appBar: AppBar(title: Text('Home', style: TextStyle(color:Colors.black),),backgroundColor: Colors.white),    body: ListView.builder(        itemCount: 100,        //為列表創(chuàng)建100個(gè)不同顏色的RowItem        itemBuilder: (context, index)=>TabRowItem(          index: index,          lastItem: index == 100 - 1,          color: colorItems[index],//設(shè)置不同的顏色          colorName: colorNameItems[index],        )    ),  );

運(yùn)行一下代碼，可以看到，在去掉了模糊效果之后，GPU 的渲染壓力得到了緩解，checkerboardOffscreenLayers 檢測圖層也不再頻繁閃爍了。

checkerboardRasterCacheImages

從資源的角度看，另一類非常消耗性能的操作是渲染圖像，因?yàn)閳D像渲染會涉及 I/O、GPU 存儲以及不同通道的數(shù)據(jù)格式轉(zhuǎn)換，因此渲染過程的構(gòu)建需要消耗大量資源。為了緩解 GPU 的壓力，F(xiàn)lutter 提供了多層次的緩存快照，這樣 Widget 重建時(shí)就無需重新繪制靜態(tài)圖像了。

與檢查多視圖疊加渲染的 checkerboardOffscreenLayers 參數(shù)類似，F(xiàn)lutter 提供了檢查緩存圖像的開關(guān) checkerboardRasterCacheImages，來檢測在界面重繪時(shí)頻繁閃爍的圖像。

為了提高靜態(tài)圖像顯示性能，我們可以把需要靜態(tài)緩存的圖像加到 RepaintBoundary 中，RepaintBoundary 可以確定 Widget 樹的重繪邊界，如果圖像足夠復(fù)雜，F(xiàn)lutter 引擎會自動將其緩存，從而避免重復(fù)刷新。當(dāng)然，因?yàn)榫彺尜Y源有限，如果引擎認(rèn)為圖像不夠復(fù)雜，也可能會忽略 RepaintBoundary。下面的代碼展示了通過 RepaintBoundary，將一個(gè)靜態(tài)復(fù)合 Widget 加入緩存的具體用法，如下所示。

RepaintBoundary(//設(shè)置靜態(tài)緩存圖像    child: Center(      child: Container(        color: Colors.black,        height: 10.0,        width: 10.0,      ),  ));

UI 線程問題定位

如果說 GPU 線程問題定位的是渲染引擎底層渲染異常，那么 UI 線程問題發(fā)現(xiàn)的則是應(yīng)用的性能瓶頸。比如在視圖構(gòu)建時(shí)，在 build 方法中使用了一些復(fù)雜的運(yùn)算，或是在主 Isolate 中進(jìn)行了同步的 I/O 操作。這些問題，都會明顯增加 CPU 的處理時(shí)間，拖慢應(yīng)用的響應(yīng)速度。

針對這類問題，我們可以使用 Flutter 提供的 Performance 工具，來記錄應(yīng)用的執(zhí)行軌跡。Performance 是一個(gè)強(qiáng)大的性能分析工具，能夠以時(shí)間軸的方式展示 CPU 的調(diào)用棧和執(zhí)行時(shí)間，去檢查代碼中可疑的方法調(diào)用。

打開 Android Studio 底部工具欄中的“Open DevTools”按鈕之后，系統(tǒng)會自動打開 Dart DevTools 的網(wǎng)頁，將頂部的 tab 切換到 Performance 后，我們就可以開始分析代碼中的性能問題了。

接下來，我們通過一個(gè)在 ListView 中計(jì)算 MD5 的例子來演示 Performance 的具體分析過程?？紤]到在 build 函數(shù)中進(jìn)行渲染信息的組裝是一個(gè)常見的操作，為了演示Performance的使用過程，我們故意放大計(jì)算 MD5 的耗時(shí)，如循環(huán)迭代計(jì)算了 1 萬次。

class MyHomePage extends StatelessWidget {    MyHomePage({Key key}) : super(key: key);    String generateMd5(String data) {      //MD5固定算法      var content = new Utf8Encoder().convert(data);      var digest = md5.convert(content);      return hex.encode(digest.bytes);    }    @override    Widget build(BuildContext context) {      return Scaffold(        appBar: AppBar(title: Text('demo')),        body: ListView.builder(            itemCount: 30,// 列表元素個(gè)數(shù)            itemBuilder: (context, index) {              //反復(fù)迭代計(jì)算MD5              String str = '1234567890abcdefghijklmnopqrstuvwxyz';              for(int i = 0;i<10000;i++) {                str = generateMd5(str);              }              return ListTile(title: Text("Index : $index"), subtitle: Text(str));            }// 列表項(xiàng)創(chuàng)建方法        ),      );    }  }

與性能圖層能夠自動記錄應(yīng)用執(zhí)行情況不同，使用 Performance 來分析代碼執(zhí)行軌跡，我們需要手動點(diǎn)擊【Record】按鈕去主動觸發(fā)，在完成信息的抽樣采集后再點(diǎn)擊【Stop】按鈕結(jié)束錄制，然后就可以得到在這期間應(yīng)用的執(zhí)行情況了。

Performance 記錄的應(yīng)用執(zhí)行情況叫做 CPU 幀圖，又被稱為火焰圖?；鹧鎴D是基于記錄代碼執(zhí)行結(jié)果所產(chǎn)生的圖片，用來展示 CPU 的調(diào)用棧，表示的是 CPU 的繁忙程度。所以，我們要檢測 CPU 耗時(shí)問題，皆可以查看火焰圖底部的哪個(gè)函數(shù)占據(jù)的寬度最大。只要有“平頂”，就表示該函數(shù)可能存在性能問題，如下圖所示。

可以看到，_MyHomePage.generateMd5 函數(shù)的執(zhí)行時(shí)間最長，幾乎占滿了整個(gè)火焰圖的寬，而這也與代碼中存在的問題是一致的。在找到了問題之后，我們就可以使用 Isolate（或 compute）將這些耗時(shí)的操作挪到并發(fā)主 Isolate 之外去完成了。

到此，關(guān)于“分析Flutter應(yīng)用性能檢測與優(yōu)化”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！