Android Flutter 内存机制初探
阿里妹導讀:閑魚技術(shù)團隊一直在探索如何使用Flutter來統(tǒng)一移動App開發(fā)。移動設(shè)備上的資源有限,內(nèi)存使用成了日常開發(fā)中的常見問題。那么,Flutter是如何使用內(nèi)存,又會對Native App的內(nèi)存帶來哪些影響呢?本文將簡單介紹Flutter內(nèi)存機制,結(jié)合測試和閑魚技術(shù)團隊的開發(fā)實踐,對普遍關(guān)心的Bitmap內(nèi)存使用,View繪制內(nèi)存使用方面做一些探索。
Dart RunTime簡介
Flutter Framework使用Dart語言開發(fā),所以App進程中需要一個Dart運行環(huán)境(VM),和Android Art一樣,Flutter也對Dart源碼做了AOT編譯,直接將Dart源碼編譯成了本地字節(jié)碼,沒有了解釋執(zhí)行的過程,提升執(zhí)行性能。這里重點關(guān)注Dart VM內(nèi)存分配(Allocate)和回收(GC)相關(guān)的部分。
和Java顯著不同的是Dart的"線程"(Isolate)是不共享內(nèi)存的,各自的堆(Heap)和棧(Stack)都是隔離的,并且是各自獨立GC的,彼此之間通過消息通道來通信。Dart天然不存在數(shù)據(jù)競爭和變量狀態(tài)同步的問題,整個Flutter Framework Widget的渲染過程都運行在一個isolate中。
Dart VM將內(nèi)存管理分為新生代(New Generation)和老年代(Old Generation)。
新生代(New Generation): 通常初次分配的對象都位于新生代中,該區(qū)域主要是存放內(nèi)存較小并且生命周期較短的對象,比如局部變量。新生代會頻繁執(zhí)行內(nèi)存回收(GC),回收采用“復制-清除”算法,將內(nèi)存分為兩塊(圖中的from 和 to),運行時每次只使用其中的一塊(圖中的from),另一塊備用(圖中的to)。當發(fā)生GC時,將當前使用的內(nèi)存塊中存活的對象拷貝到備用內(nèi)存塊中,然后清除當前使用內(nèi)存塊,最后,交換兩塊內(nèi)存的角色。
老年代(Old Generation): 在新生代的GC中“幸存”下來的對象,它們會被轉(zhuǎn)移到老年代中。老年代存放生命力周期較長,內(nèi)存較大的對象。老年代通常比新生代要大很多。老年代的GC回收采用“標記-清除”算法,分成標記和清除兩個階段。在標記階段會觸發(fā)停頓(stop the world),多線程并發(fā)的完成對垃圾對象的標記,降低標記階段耗時。在清理階段,由GC線程負責清理回收對象,和應(yīng)用線程同時執(zhí)行,不影響應(yīng)用運行。
可以看到,Dart VM借鑒了很多JVM的思路,Dart中產(chǎn)生內(nèi)存泄露的方式也和Java類似,Java中很多排查內(nèi)存泄露的思路和防止內(nèi)存泄露的編程方法應(yīng)該也可以借鑒過來。
Image內(nèi)存初探
對圖片的合理使用和優(yōu)化是UI編程的重要部分,Flutter提供了Image Widget,我們可以方便地使用:
我們知道Android將內(nèi)存分為Java虛擬機內(nèi)存和Native內(nèi)存,各大廠商都對Java虛擬機內(nèi)存有一個上限限制,到達上限就會觸發(fā)OOM異常,而對Native內(nèi)存的使用沒有太嚴格的限制,現(xiàn)在的手機內(nèi)存都很大,一般有較大的Native內(nèi)存富余。那么Android中ImageView使用的是Java虛擬機內(nèi)存還是Native內(nèi)存呢?
我們可以來做一個測試:在一個界面上,每點擊一次,就在上面堆加一張圖片。為了防止后面的圖片完全覆蓋前面的圖片而出現(xiàn)優(yōu)化的情況,每次都縮小幾個像素,這樣就不會出現(xiàn)完全覆蓋。
打開Android Profiler,一張一張?zhí)砑訄D片,觀察內(nèi)存數(shù)據(jù)。分別測試了Android的6.0,7.0和8.0系統(tǒng),結(jié)果如下:
Android 6.0(Google Nextus5)
Android 7.0(Meizu pro5)
Android 8.0(Google pixel)
在測試中,隨著圖片一張張增加,Android 6.0 和 7.0都是Java部分的內(nèi)存在增長,而Android 8.0則是Native部分的內(nèi)存在增長。由此有結(jié)論,Android原生的ImageView在6.0和7.0版本中使用的Java虛擬機內(nèi)存,而在Android 8.0中則使用的Native內(nèi)存。
而Flutter Image Widget使用的是哪部分內(nèi)存呢?我們用Flutter界面來做相同的測試。Flutter Engine的Debug版本和Release版本存在很大的性能差異,所以我們測試最好使用Release版本,但是,Release版本的Apk又不能使用Android profiler來觀察內(nèi)存,所以我們需要在Debug版本的Apk中打包一個Release版本的Flutter Engine, 可以修改flutter tool中的flutter.gradle來實現(xiàn):
相同地,我們向Flutter界面中添加圖片并用Android Profiler來觀察內(nèi)存,測試使用的dart代碼:
得到的結(jié)果是:
Android 6.0?Android 8.0
可以看到,Flutter Image使用的內(nèi)存既不屬于Java虛擬機內(nèi)存也不屬于Native內(nèi)存,而是Graphics內(nèi)存(在Meizu pro5設(shè)備上也不屬于Graphics,事實上Meizu pro5設(shè)備不能歸類Flutter Image所使用的內(nèi)存),官方對Graphics內(nèi)存的解釋是:
那么至少Flutter Image所使用的內(nèi)存不會是Java虛擬機內(nèi)存,這對不少Android設(shè)備都是一個好消息,這意味著使用Flutter Image沒有OOM的風險,能夠較好的利用Native內(nèi)存。
使用Image的時候,建立一個內(nèi)存緩存池是個好習慣,Flutter Framework提供了一個ImageCache來緩存加載的圖片,但它不同于Android Lru Cache,不能精確的使用內(nèi)存大小來設(shè)定緩存池容量,而是只能粗略的指定最大緩存圖片張數(shù)。
FlutterView內(nèi)存初探
Flutter設(shè)計之初是想統(tǒng)一Android和IOS的界面編程,所以理想的基于Flutter的apk只需要提供一個MainActivity做入口即可,后面所有的頁面跳轉(zhuǎn)都在FlutterView中管理。但是,如果是一個已有規(guī)模的app接入Flutter開發(fā),我們不可能將已有的Activity頁面都用Flutter重新實現(xiàn)一遍,這時候就需要考慮本地頁面和Flutter頁面之間的跳轉(zhuǎn)交互了。iOS可以方便的管理頁面棧,但是Android就很復雜(Android有任務(wù)棧機制,低內(nèi)存Activity回收機制等),所以通常我們還是使用Activity作為頁面容器來展示flutter頁面。這時有兩種選擇,可以每次啟動一個Activity就啟動一個新的FlutterView,也可以啟動Activity的時候復用已有的FlutterView。
不復用FlutterView
復用FlutterView
Flutter Framework中FlutterView是綁定Activity使用的,要復用FlutterView就必須能夠把FlutterView單獨拎出來使用。所幸現(xiàn)在FlutterView和Activity耦合程度并不很深,最關(guān)鍵的地方是FlutterNativeView必須attach一個Activity:
初始化FlutterView時必須傳入一個Activity,當其他Activity復用FlutterView時再調(diào)用該Attach方法即可。這里有個問題,就是FlutterView中必須保存一個Activity引用,這個一個內(nèi)存泄露隱患,我們可以在FluterView detach時候?qū)ainActivity傳入,因為通常整個App交互過程中MainActivity都是一直存在的,可以避免其他Activity泄露。
為了更好的權(quán)衡兩種方法的利弊,我們先用空頁面來測試一下當頁面增加時內(nèi)存的變化:
不復用FlutterView時,頁面增加時內(nèi)存變化
復用FlutterView時,頁面增加時內(nèi)存變化
不復用FlutterView時平均打開一個頁面(空頁面),Java內(nèi)存增長0.02M,Native內(nèi)存增長0.73M。復用FlutterView時平均打開一個頁面(空頁面),Java內(nèi)存增長0.019M,Native內(nèi)存增長0.65M。可見復用FlutterView在內(nèi)存使用上是有優(yōu)勢的,但主要復用的還是Native部分的內(nèi)存。復用FlutterView必然帶來額外的一些復雜邏輯,有時候為了邏輯簡單,后期維護上的方便,犧牲一些相對不太珍貴的Native內(nèi)存也是值得的。
復用單個FlutterView有時會有些“意外”,比如當Activity切換時,就不得不將當前FlutterView detach掉給后面新建的Activity使用,當前界面就會空白閃動,有個想法是可以將當前界面截屏下來遮擋住后面的界面變化,這種方式有時會帶來額外的適配問題。
FlutterView復用與否不是絕對的,有時候可以使用一些綜合性折中方案,比如,我們可以建立一個FlutterViewProvider,里面維護N個可復用的FlutterView,如圖:
這樣的好處是,可以存在一定程度上的復用,又可以避免只有一個FlutterView出現(xiàn)的一些尷尬問題。
FlutterView的首幀渲染耗時較高,在Debug版本有明顯感受,大概會黑屏2秒,release版本會好很多。但我們觀察Cpu曲線,發(fā)現(xiàn)還是一個較為耗時的過程。有一種體驗優(yōu)化的思路是,我們可以預先讓將要使用的FlutterView加載好首幀,這樣,在真正使用的時候就很快了,可以先建立一個只有1個像素的窗口,在這個窗口里面完成FlutterView首幀渲染,代碼如下:
以上就是閑魚團隊在Flutter的應(yīng)用過程中的一些實踐,希望有更多的新技術(shù)嘗試和技術(shù)挑戰(zhàn)的同學,請在下面留言告訴我們。
總結(jié)
以上是生活随笔為你收集整理的Android Flutter 内存机制初探的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 阿里技术大牛最爱的“闲书”,你看过多少?
- 下一篇: 面向云数据库,超低延迟文件系统Polar