
前言
本文是就Flutter
的資料更新形式來操作,然後通過以觀測觀測臺的狀態資料包告,來完成對程式碼執行效率的監控,並找到突破口。
觀測臺
不管是Idea
還是Android Studio
都提供了觀測臺的功能。
一般我們使用的都是Observatory
的timeline
部分。

terminal
中輸入flutter run
,如果要使用真機測試則輸入flutter run --profile
。成功後會出現如圖所示的網址,不過這個網址適合在Google瀏覽器中進行顯示。

一般在timeline
中,我們一般選用Flutter Developer
的選項。出現的渲染顯示我們一般會看到gpu
和ui
的渲染,以及重構過程。

效能優化
在效能優化之前,我們需要知道Flutter
重構的邏輯。
在Android
中我們知道繪製需要的三個步驟是 measure
、layout
、draw
。
而Flutter
對應的是build
、layout
、paint
。
他的重構是基於一種標髒和重新建立的方式進行的,所以我們的效能影響一般來自於一個複雜介面的不斷重建。可能你只需要修改一個很小的部分,也就是很小的一個子樹需要進行修改,那麼在程式碼沒有規範的情況下,可能會出現整個介面的重新整理,這樣我們的效能可能就要下降了數倍。
對於我的程式碼而言,就是整個介面的程式碼都得到了重建的,但是這是基於本身程式碼還是簡單的原因,如果程式碼是非常複雜的,那會得到怎樣毀滅性的結果,也是可想而知。

程式碼測試
測試程式碼位於包
test
:WanAndroid-Flutter

Timer
自動更新的。
int _num = 0;
@override
void initState() {
// TODO: implement initState
super.initState();
Timer.periodic(Duration(seconds: 1), (timer) {
setState(() {
_num = timer.tick;
});
});
}
複製程式碼
在initState()
函式中,我們做了一件事情,就是一個初始化,並且這是一個每1s進行一次更新的。
在原始碼中,這個資料更新處於兩種位置:Main頁面、元件化的_buildBottom。
- Main頁面:在這個頁面中,如果重構,就會發生我們上述所說的情況,把整個頁面全部重構了。
- 元件化的_buildBottomde:將上述的更新程式碼轉移到這個元件中,那麼重構的效果就會和上述的一樣,當然你可以更進行細化。
![]() |
![]() |
---|
通過Observatory
的觀測,我們能夠看到兩種位置進行更新,他們重構所需要進行的步驟是完全不一樣的程度的,更何況我的頁面邏輯是處於一個還算簡單的狀態呢。
以上就是我的學習成果,如果有什麼我沒有思考到的地方或是文章記憶體在錯誤,歡迎與我分享。
相關文章推薦: 手撕Flutter