1.圓角對性能的影響

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供金城江網(wǎng)站建設(shè)、金城江做網(wǎng)站、金城江網(wǎng)站設(shè)計、金城江網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、金城江企業(yè)網(wǎng)站模板建站服務(wù),10余年金城江做網(wǎng)站經(jīng)驗,不只是建網(wǎng)站,更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
盡量避免用Clipxxx組件,建議用BoxDecoration的image屬性實現(xiàn),如果用Clipxxx組件,圓角取整后性能會提升。
2.減少重繪
根據(jù)場景合理使用RePaintBoundary,使繪制獨立于父布局,避免重繪,提升性能,但過度使用增加的圖層會帶來Raster合成的耗時。例如scrollview是滑動過程會導(dǎo)致所有的節(jié)點都重繪,可以在scrollview下一層使用RePaintBoundary。
3.滾動步長插值器優(yōu)化(了解)
官方的滾動差值器在出現(xiàn)小卡頓時,滾動步長會出現(xiàn)大的跳躍,導(dǎo)致體感上出現(xiàn)很明顯的抖動,優(yōu)化步長偏移量算法與原生效果對齊。
4.開啟SurfaceView
官方推薦Flutter用SurfaceView ,因為SurfaceView與應(yīng)用窗口內(nèi)容分隔開,在專有硬件中合成,產(chǎn)生的中間副本少于TextureView,所以性能高,占用內(nèi)存少,但是在混合棧遇到的問題需要突破
5.使用RepaintBoundary 提升頻繁重繪控件的性能。使用RelayoutBoundary提升頻繁修改大小,增刪的布局中也可以提升性能。
6.build中不要去寫大量的耗時邏輯,因為數(shù)據(jù)更新會觸發(fā)build的多次調(diào)用,在里面做耗時邏輯會降低性能。
7.盡量使用statelessWidget代替statefulWidget,因為statefulWidget的銷毀重建會引起子widget的銷毀與重建。
8.解析json可以放到子線程線程中,開Isolate去解析,這樣,當(dāng)返回數(shù)據(jù)特別大的時候也不會阻塞界面。
9.使用不變的組件的時候可以添加const,const組件不會進行build更新
10.由于flutter通過widget.runtimeType和key來判斷是否需要跟新組建,所以我們寫組件的時候盡量保持key不變,或者不寫key。對于一些需要頻繁改變,例如新增、刪除、排序的最好加上key。如果type一直,如果不寫key容易導(dǎo)致,element無法區(qū)分新舊widget,導(dǎo)致無法更新。
按照給定尺寸進行圖片的解碼,而不是解碼整個圖片的尺寸,用來減少內(nèi)存的占用。
官方文檔:
官方說明:
Instructs Flutter to decode the image at the specified dimensions instead of at its native size.
This allows finer control of the size of the image in ImageCache and is generally used to reduce the memory footprint of ImageCache .
The decoded image may still be displayed at sizes other than the cached size provided here.
使用:
三方庫: cached_network_image 限2.5.0之后版本才可用
設(shè)定最大的緩存寬度和高度 this.maxWidthDiskCache 、 this.maxHeightDiskCache
使用:
從相冊選取圖片,展示時使用指定尺寸寬高進行處理。
使用三方庫:
使用自定義 provider 來指定所需圖片的寬高:
AssetEntityImageProvider 傳入寬高和圖片原圖 AssetEntity 數(shù)據(jù)。
provider 中 key.entity.thumbDataWithSize 方法:
進入 entity 中 thumbDataWithSize 方法:
進入 _getThumbDataWithId 方法中,
進入getThumb:
調(diào)用iOS原生的獲取圖片方法,
進入 getThumbWithId 方法,
原生實現(xiàn)獲取置頂寬高縮略圖方法實現(xiàn):
使用 iOS 原生類 PHImageManager 的
來獲取縮略圖。
Dart的 IO 庫包含了文件讀寫的相關(guān)類,它屬于 Dart 語法標(biāo)準(zhǔn)的一部分,所以通過 Dart IO 庫,無論是 Dart VM 下的腳本還是 Flutter,都是通過 Dart IO 庫來操作文件的,不過和 Dart VM 相比,F(xiàn)lutter 有一個重要差異是文件系統(tǒng)路徑不同,這是因為Dart VM 是運行在 PC 或服務(wù)器操作系統(tǒng)下,而 Flutter 是運行在移動操作系統(tǒng)中,他們的文件系統(tǒng)會有一些差異。
Android 和 iOS 的應(yīng)用存儲目錄不同, PathProvider 插件提供了一種平臺透明的方式來訪問設(shè)備文件系統(tǒng)上的常用位置。該類當(dāng)前支持訪問兩個文件系統(tǒng)位置:
File代表一個整體的文件,他有三個構(gòu)造函數(shù),分別是:
文件讀取本身有兩種形式,一種是文本,一種是二進制。
2.2.1 讀取文本內(nèi)容
如果是文本文件,F(xiàn)ile提供了readAsString、readAsLines、readAsStringSync、readAsLinesSync方法,讀取文本內(nèi)容
readAsString 一次性讀取所有文本
readAsLines 一行行的讀取文本
結(jié)果返回的是一個List,list中表示文件每行的內(nèi)容
readAsStringSync、readAsLinesSync同步讀取文本
2.2.2 讀取二進制內(nèi)容
如果文件是二進制,那么可以使用readAsBytes或者同步的方法readAsBytesSync:
dart中表示二進制有一個專門的類型叫做Uint8List,他實際上表示的是一個int的List。
上面提到的讀取方式,都是一次性讀取整個文件,缺點就是如果文件太大的話,可能造成內(nèi)存空間的壓力。
所以File為我們提供了另外一種讀取文件的方法,流的形式來讀取文件.
示例
dart提供了open和openSync兩個方法來進行隨機文件讀寫:
寫入和文件讀取一樣,可以一次性寫入或者獲得一個寫入句柄,然后再寫入。
一次性寫入的方法有四種,分別對應(yīng)字符串和二進制
句柄形式可以調(diào)用openWrite方法,返回一個IOSink對象,然后通過這個對象進行寫入:
默認(rèn)情況下寫入是會覆蓋整個文件的,但是可以通過下面的方式來更改寫入模式:
雖然dart中所有的異常都是運行時異常,但是和java一樣,要想手動處理文件讀寫中的異常,則可以使用try,catch:
我們還是以計數(shù)器為例,實現(xiàn)在應(yīng)用退出重啟后可以恢復(fù)點擊次數(shù)。 這里,我們使用文件來保存數(shù)據(jù):
1.引入PathProvider插件;在pubspec.yaml文件中添加如下聲明:
執(zhí)行 flutter pub get
2.實現(xiàn)如下
參考:
本文對比的是 UIWebView、WKWebView、flutter_webview_plugin(在iOS中使用的是WKWebView)的加載速度,內(nèi)存使用情況。
測試網(wǎng)頁打開的速度,只需要獲取 WebView 在開始加載網(wǎng)頁和網(wǎng)頁加載完成時的時間戳,時間戳的差即為打開網(wǎng)頁的時間
為了使差異更明顯,我們選擇較為復(fù)雜的 新浪首頁 進行加載的對比,為了減小網(wǎng)絡(luò)對加載速度的影響,我們讓手機連接同一個網(wǎng)絡(luò),分別進行 10 次測試然后取平均值,另外,我們需要關(guān)閉 WebView 的緩存,防止緩存對加載速度產(chǎn)生影響
下面使筆者進行 10 次測試所得到的數(shù)據(jù)
結(jié)果讓我有點驚訝,一直以為 WKWebView 會是個王者。結(jié)果看,速度上 WKWebView 略慢一點,不過總體差異不大(該結(jié)果僅僅是測試新浪的結(jié)果,僅供參考啦)
在這里,筆者又加了一個測試,嘗試記錄從 viewController 的 viewDidLoad 到 webview 的 didFinish 時間,測試了新浪的數(shù)據(jù),如下:
UIWebViewA : 4970、3808、3815、4250、3556 avg(4079.8) (加載完所有頁面)
UIWebViewB : 4103、3124、3070、3256、2835 avg(3277.6)(加載sina完畢)
WKWebView : 3672、3032、2892、2912、2739 avg(3049.4)
flutter_webView : 4532、3901、4310、3496、3378 avg(3923.4)
其中可以看到,webView 有兩行,UIWebViewB 的數(shù)據(jù)就是加載 sina 主站的時間;UIWebViewA 的數(shù)據(jù)是因為在加載完 sina 主站之后,新浪又加載了一個 ,所以導(dǎo)致總時間延長,不過即使按照 UIWebViewB 的數(shù)據(jù)來比較,也是 wkWebView 略勝一籌。
此處可以看出 flutter_webView 使用的是 wkwebView,所以它吃虧的主要原因是 flutter 包了一層。
結(jié)論:
速度(didStart - didFinish) UIWebView flutter_webview WKWebView
速度(viewDidLoad - didFinish)WKWebView UIWebView flutter_webview
這里查看內(nèi)存使用的是 xcode 的 debug session 中的 memory。
首先看之前測試時,連續(xù)打開十次新浪的內(nèi)存情況
接著我們在看一下打開淘寶首頁的內(nèi)存情況
從圖上可以看出,WKWebView 在內(nèi)存方面有很大的優(yōu)勢啊,UIWebView 的內(nèi)存是真的傷啊,然后 debug 看了一下 flutter_webView,他使用的就是原生的 webView 。
他相比較原生 WKWebView 的內(nèi)存開銷稍大一點,從測試表現(xiàn)來看,一般大個 30 MB 左右。
結(jié)論:內(nèi)存 WKWebView flutter_webview UIWebView
可以在 html5test 中對瀏覽器的兼容性進行評分,通過測試發(fā)現(xiàn)得分分別如下
因為 flutter 里使用的就是 WK,所以和原生的 WKWebView 一樣都是 444 分,比 UIWebView 的 437 略勝一籌
結(jié)論:兼容性 WKWebView = flutter_webview UIWebView
UIWebView : 速度相比較 WKWebView 稍快一點,但是內(nèi)存是一大硬傷,所以只要條件允許,就不推薦使用了
WKWebView : 速度略慢一點,不過差別不大,總體可以接受。是比UIWebView更好的選擇,推薦使用。
flutter_webView_plugin :在iOS中使用的就是原生的WKWebView,所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項目中,因為它被包了一層,所以頁面加載上存在一定的劣勢,所以混編項目中仍然推薦使用 WKWebView。不過如果從多端考慮、以及項目可遷移等,那么使用也未嘗不可,就是維護成本要增加一些,需要維護兩套 webView。這個就需要根據(jù)自己的情況自己取舍了。
目前Flutter平臺主流的兩個播放器是video_player和fijkplayer
pub
github
1、Flutter平臺官方插件,作者是國外的,有問題溝通比較困難,只能通過提交issue
2、硬解碼
4、UI封裝: better_player
基于video_player和Chewie的高級視頻播放器。它解決了許多典型的用例,并且易于運行。
5、播放器寬高比例與視頻內(nèi)容寬高比例不一致時,會出現(xiàn)圖像壓縮變形的問題
6、調(diào)用原生內(nèi)核播放器:iOS--AVPlayer, Android--ExoPlayer
7、對于分段源 m3u8 的播放不友好,如果一個切片播放超時,會導(dǎo)致整個播放都失敗
8、better_player可以緩存視頻,但不能自定義緩存的地址,只能指定key,和緩存的最大內(nèi)存量(還未研究超出最大的話是不能緩存新的,還是刪除最舊的)
9、better_player不能完全自定義UI,只能修改類中的一些開放屬性,比如說icon圖標(biāo),文字顏色啥的
10、無網(wǎng)絡(luò)有緩存時,封面可以正常展示
11、better_player播放失敗有手動retry的設(shè)計
pub
github
1、fijkplayer 是一個 Flutter 生態(tài)的媒體播放器,是對 ijkplayer 的 Flutter 封裝,支持 Android 和 iOS。 fijkplayer 使用 ijkplayer 作為播放器內(nèi)核,ijkplayer 使用 ffmpeg 進行音視頻解封裝和解碼,同時添加了 Android 和 iOS 平臺特有的硬件加速解碼能力。
2 、國內(nèi)有QQ群,但是活躍度也是不高。
3、可以緩存視頻,可以自定義緩存的地址,方便后續(xù)的內(nèi)存維護。
4、可以通過FijkPanelWidgetBuilder較大程度上自定義UI。
5、無網(wǎng)絡(luò)有緩存視頻時,無法展示封面,因為內(nèi)部是通過imageProvider去加載網(wǎng)絡(luò)圖片的。
7、播放失敗無手動retry的設(shè)計
1、兩種播放器都是通過外接紋理方案 (Texture),將播放器視頻畫面渲染接入 flutter 中,性能上優(yōu)于 PlatformView 的接入方法。
如何自己實現(xiàn)?
下面以video_palyer的iOS源碼部分解釋:
iOS用CVPixelBufferRef將渲染出來的數(shù)據(jù)存在內(nèi)存中,F(xiàn)lutter engine會將Texture的數(shù)據(jù)在內(nèi)存中直接進行映射無需通過Channel傳輸,然后Texture Widget就可以把你提供的這些數(shù)據(jù)顯示出來。在我們傳輸數(shù)據(jù)的時候會需要將其與 TextureID 綁定,綁定的過程通過BasicMessageChannel實現(xiàn)數(shù)據(jù)流的傳輸,以做到實時展示的效果
首先查看入口函數(shù):
類MyApp:
MyHomePage:
state:
build:
此demo頁面涉及到兩個組件:圖片和icon。在這里做一個簡單的介紹,更詳細(xì)的學(xué)習(xí)請參考flutter官網(wǎng)和相關(guān)書籍
在flutter中,我們可以通過Image組件來加載并顯示圖片,Image的數(shù)據(jù)源可以是asset、文件、內(nèi)存以及網(wǎng)絡(luò)。
ImageProvider 是一個抽象類,主要定義了圖片數(shù)據(jù)獲取的接口 load() ,從不同的數(shù)據(jù)源獲取圖片需要實現(xiàn)不同的 ImageProvider ,如 AssetImage 是實現(xiàn)了從Asset中加載圖片的ImageProvider,而 NetworkImage 實現(xiàn)了從網(wǎng)絡(luò)加載圖片的ImageProvider。
Image也提供了一個快捷的構(gòu)造函數(shù) Image.asset 用于從asset中加載、顯示圖片:
Image也提供了一個快捷的構(gòu)造函數(shù) Image.network 用于從網(wǎng)絡(luò)加載、顯示圖片:
Flutter中,可以像web開發(fā)一樣使用iconfont,iconfont也即"字體圖標(biāo)",它是將圖標(biāo)做成字體文件,然后通過指定不同的字符而顯示不同的圖片。
加號為圖片組件,減一為icon組件。點擊加號,數(shù)字加1;點擊-1,數(shù)字減少1。
分享名稱:flutter內(nèi)存統(tǒng)計,flutter 數(shù)據(jù)存儲
網(wǎng)頁地址:http://chinadenli.net/article17/dsgcggj.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)建站、微信公眾號、定制網(wǎng)站、品牌網(wǎng)站制作、網(wǎng)站改版、搜索引擎優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)