前言
本文是就Flutter的數(shù)據(jù)更新形式來操作，然后通過以觀測觀測臺(tái)的狀態(tài)數(shù)據(jù)報(bào)告，來完成對(duì)代碼執(zhí)行效率的監(jiān)控，并找到突破口。
觀測臺(tái)
不管是Idea還是Android Studio都提供了觀測臺(tái)的功能。
一般我們使用的都是Observatory的timeline部分。
我打開的方式一般都是在
terminal中輸入flutter run，如果要使用真機(jī)測試則輸入flutter run --profile。成功后會(huì)出現(xiàn)如圖所示的網(wǎng)址，不過這個(gè)網(wǎng)址適合在Google瀏覽器中進(jìn)行顯示。
一般在timeline中，我們一般選用Flutter Developer的選項(xiàng)。出現(xiàn)的渲染顯示我們一般會(huì)看到gpu和ui的渲染，以及重構(gòu)過程。
性能優(yōu)化
在性能優(yōu)化之前，我們需要知道Flutter重構(gòu)的邏輯。
在Android中我們知道繪制需要的三個(gè)步驟是 measure、layout、draw。
而Flutter對(duì)應(yīng)的是build、layout、paint。
他的重構(gòu)是基于一種標(biāo)臟和重新創(chuàng)建的方式進(jìn)行的，所以我們的性能影響一般來自于一個(gè)復(fù)雜界面的不斷重建?？赡苣阒恍枰薷囊粋€(gè)很小的部分，也就是很小的一個(gè)子樹需要進(jìn)行修改，那么在代碼沒有規(guī)范的情況下，可能會(huì)出現(xiàn)整個(gè)界面的刷新，這樣我們的性能可能就要下降了數(shù)倍。
對(duì)于我的代碼而言，就是整個(gè)界面的代碼都得到了重建的，但是這是基于本身代碼還是簡單的原因，如果代碼是非常復(fù)雜的，那會(huì)得到怎樣毀滅性的結(jié)果，也是可想而知。
上文的意思用這張圖來表示，就是本來我們重構(gòu)的就是實(shí)線叉號(hào)的子樹，但是因?yàn)榇a的書寫原因，導(dǎo)致我們的結(jié)果重構(gòu)的虛線叉號(hào)的整棵樹。所以代碼的書寫規(guī)范在性能優(yōu)化上起了至關(guān)重要的作用。
代碼測試
測試代碼位于包
test:WanAndroid-Flutter
上圖是我測試的代碼，黑色圖形中的數(shù)據(jù)是通過
Timer自動(dòng)更新的。
int _num = 0;
@override
void initState() {
// TODO: implement initState
super.initState();
Timer.periodic(Duration(seconds: 1), (timer) {
setState(() {
_num = timer.tick;
});
});
}
在initState()函數(shù)中，我們做了一件事情，就是一個(gè)初始化，并且這是一個(gè)每1s進(jìn)行一次更新的。
在源碼中，這個(gè)數(shù)據(jù)更新處于兩種位置：Main頁面、組件化的_buildBottom。
- Main頁面：在這個(gè)頁面中，如果重構(gòu)，就會(huì)發(fā)生我們上述所說的情況，把整個(gè)頁面全部重構(gòu)了。
- 組件化的_buildBottomde：將上述的更新代碼轉(zhuǎn)移到這個(gè)組件中，那么重構(gòu)的效果就會(huì)和上述的一樣，當(dāng)然你可以更進(jìn)行細(xì)化。
 性能優(yōu)化前
|
 性能優(yōu)化后
|
|---|
通過Observatory的觀測，我們能夠看到兩種位置進(jìn)行更新，他們重構(gòu)所需要進(jìn)行的步驟是完全不一樣的程度的，更何況我的頁面邏輯是處于一個(gè)還算簡單的狀態(tài)呢。
以上就是我的學(xué)習(xí)成果，如果有什么我沒有思考到的地方或是文章內(nèi)存在錯(cuò)誤，歡迎與我分享。
相關(guān)文章推薦：
手撕Flutter
