建站
咨詢
售后
建站咨詢
新聞中心
概述
成都創(chuàng)新互聯(lián)公司專業(yè)IDC數(shù)據(jù)服務(wù)器托管提供商，專業(yè)提供成都服務(wù)器托管，服務(wù)器租用，四川電信機(jī)房托管，四川電信機(jī)房托管，成都多線服務(wù)器托管等服務(wù)器托管服務(wù)。
軟件項(xiàng)目的交付是一個(gè)復(fù)雜且漫長的過程，任何細(xì)小的失誤都有可能導(dǎo)致交付過程失敗。在軟件開發(fā)過程中，除了代碼邏輯的 Bug 和視覺異常這些功能層面的問題之外，移動(dòng)應(yīng)用另一類常見的問題是性能問題，比如滑動(dòng)操作不流暢、頁面出現(xiàn)卡頓丟幀現(xiàn)象等。這些問題雖然不至于讓移動(dòng)應(yīng)用完全不可用，但也很容易引起用戶反感，從而對(duì)應(yīng)用質(zhì)量產(chǎn)生質(zhì)疑，甚至失去耐心。
那么，對(duì)于應(yīng)用渲染并不流暢，出現(xiàn)了性能問題，我們?cè)撊绾螜z測，又該從哪里著手處理呢？和移動(dòng)開發(fā)類似， Flutter 的性能問題主要可以分為 GPU 線程問題和 UI 線程（CPU）問題兩類。對(duì)于這些問題，有一個(gè)通用的套路：首先，都需要先通過性能圖層進(jìn)行初步分析，而一旦確認(rèn)問題存在，接下來就是利用 Flutter 提供的各類分析工具來進(jìn)行問題定位。
圖層分析
Flutter運(yùn)行模式
1、Debug
Debug模式可以在真機(jī)和模擬器上同時(shí)運(yùn)行，此模式會(huì)打開所有的斷言，包括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)行：會(huì)關(guān)閉所有斷言和debugging信息，關(guān)閉所有debugger工具。優(yōu)化了快速啟動(dòng)、快速執(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ù)。
不管是移動(dòng)開發(fā)還是前端開發(fā)，對(duì)于性能問題分析的思路都是先分析并定位問題，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)試模式增加了很多額外的檢查（比如斷言），這些檢查可能會(huì)耗費(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 指令集擅長的操作模擬器會(huì)比真機(jī)快，而另一些操作則會(huì)比真機(jī)慢，這也使得我們無法使用模擬器來評(píng)估真機(jī)才能出現(xiàn)的性能問題。
為了調(diào)試性能問題，我們需要在發(fā)布模式的基礎(chǔ)之上，為分析工具提供少量必要的應(yīng)用追蹤信息，這就是分析模式。除了一些調(diào)試性能問題必須的追蹤方法之外，F(xiàn)lutter 應(yīng)用的分析模式和發(fā)布模式的編譯和運(yùn)行是類似的，只是啟動(dòng)參數(shù)變成了 profile 而已。我們可以在 Android Studio 中通過菜單欄點(diǎn)擊 【Run】-【Profile 】‘main.dart’ 選項(xiàng)啟動(dòng)應(yīng)用，也可以通過命令行參數(shù) flutter run --profile 運(yùn)行 Flutter 應(yīng)用。
渲染問題分析
在完成了應(yīng)用啟動(dòng)之后，接下來我們就可以利用 Flutter 提供的渲染問題分析工具，即性能圖層（Performance Overlay）來分析渲染問題了。性能圖層會(huì)在當(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í)間過長，就會(huì)導(dǎo)致界面卡頓，圖表中就會(huì)展示出一個(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ù)繪制，都會(huì)明顯拖慢 GPU 的渲染速度。
接下來，使用性能圖層提供的兩項(xiàng)參數(shù)，即檢查多視圖疊加的視圖渲染開關(guān) checkerboardOffscreenLayers和檢查緩存的圖像開關(guān)checkerboardRasterCacheImages來檢查這兩種情況。
checkerboardOffscreenLayers
多視圖疊加通常會(huì)用到 Canvas 里的 savaLayer 方法，這個(gè)方法在實(shí)現(xiàn)一些特定的效果（比如半透明）時(shí)非常有用，但由于其底層實(shí)現(xiàn)會(huì)在 GPU 渲染上涉及多圖層的反復(fù)繪制，因此會(huì)帶來較大的性能問題。
對(duì)于 saveLayer 方法使用情況的檢查，我們只需要在 MaterialApp 的初始化方法中，將 checkerboardOffscreenLayers 開關(guān)設(shè)置為 true，分析工具就會(huì)自動(dòng)幫我們檢測多視圖疊加的情況。使用了 saveLayer 的 Widget 會(huì)自動(dòng)顯示為棋盤格式，并隨著頁面刷新而閃爍。不過，saveLayer 是一個(gè)較為底層的繪制方法，因此我們一般不會(huì)直接使用它，而是會(huì)通過一些功能性 Widget，在涉及需要剪切或半透明蒙層的場景中間接地使用。所以一旦遇到這種情況，我們需要思考一下是否一定要這么做，能不能通過其他方式來實(shí)現(xiàn)呢？
比如下面的例子中，我們使用 CupertinoPageScaffold 與 CupertinoNavigationBar 實(shí)現(xiàn)了一個(gè)動(dòng)態(tài)模糊的效果，代碼如下：
- CupertinoPageScaffold(
- navigationBar: CupertinoNavigationBar(),//動(dòng)態(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之后，可以看到視圖蒙層效果對(duì)GPU的渲染壓力導(dǎo)致性能視圖頻繁閃動(dòng)。如果我們沒有對(duì)動(dòng)態(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像渲染會(huì)涉及 I/O、GPU 存儲(chǔ)以及不同通道的數(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 引擎會(huì)自動(dòng)將其緩存，從而避免重復(fù)刷新。當(dāng)然，因?yàn)榫彺尜Y源有限，如果引擎認(rèn)為圖像不夠復(fù)雜，也可能會(huì)忽略 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 操作。這些問題，都會(huì)明顯增加 CPU 的處理時(shí)間，拖慢應(yīng)用的響應(yīng)速度。
針對(duì)這類問題，我們可以使用 Flutter 提供的 Performance 工具，來記錄應(yīng)用的執(zhí)行軌跡。Performance 是一個(gè)強(qiáng)大的性能分析工具，能夠以時(shí)間軸的方式展示 CPU 的調(diào)用棧和執(zhí)行時(shí)間，去檢查代碼中可疑的方法調(diào)用。
打開 Android Studio 底部工具欄中的“Open DevTools”按鈕之后，系統(tǒng)會(huì)自動(dò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)建方法
- ),
- );
- }
- }
與性能圖層能夠自動(dòng)記錄應(yīng)用執(zhí)行情況不同，使用 Performance 來分析代碼執(zhí)行軌跡，我們需要手動(dòng)點(diǎn)擊【Record】按鈕去主動(dòng)觸發(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 之外去完成了。
總結(jié)
在 Flutter 中，性能分析過程可以分為 GPU 線程問題定位和 UI 線程（CPU）問題定位，而它們都需要在真機(jī)上以分析模式（Profile）啟動(dòng)應(yīng)用，并通過性能圖層分析大致的渲染問題范圍。
一旦確認(rèn)問題存在，接下來就需要利用 Flutter 所提供的分析工具來定位問題原因了。關(guān)于 GPU 線程渲染問題，我們可以重點(diǎn)檢查應(yīng)用中是否存在多視圖疊加渲染，或是靜態(tài)圖像反復(fù)刷新的現(xiàn)象。而 UI 線程渲染問題，我們則是通過 Performance 工具記錄的火焰圖（CPU 幀圖），分析代碼耗時(shí)來找出應(yīng)用執(zhí)行瓶頸。
總的來說，由于 Flutter 采用基于聲明式的 UI 設(shè)計(jì)理念，以數(shù)據(jù)驅(qū)動(dòng)渲染，并采用 Widget->Element->RenderObject 三層結(jié)構(gòu)，屏蔽了無謂的界面刷新，能夠保證絕大多數(shù)情況下我們構(gòu)建的應(yīng)用都是高性能的，所以在使用分析工具檢測出性能問題之后，通常我們并不需要做太多的細(xì)節(jié)優(yōu)化工作，只需要在改造過程中避開一些常見的坑，就可以獲得優(yōu)異的性能。同時(shí)，為了避免造成性能問題，還應(yīng)該從以下幾個(gè)方面著手：
- 控制 build 方法耗時(shí)，將 Widget 拆小，避免直接返回一個(gè)巨大的 Widget，這樣 Widget 會(huì)享有更細(xì)粒度的重建和復(fù)用；
- 盡量不要為 Widget 設(shè)置半透明效果，而是考慮用圖片的形式代替，這樣被遮擋的 Widget 部分區(qū)域就不需要繪制了；
- 對(duì)列表采用懶加載而不是直接一次性創(chuàng)建所有的子 Widget，這樣視圖的初始化時(shí)間就減少了。
本文名稱：Flutter應(yīng)用性能檢測與優(yōu)化
分享地址：http://www.5511xx.com/article/cceoeci.html
