首先查看入口函數(shù)：
十載建站經(jīng)驗(yàn)， 成都做網(wǎng)站、網(wǎng)站制作客戶的見(jiàn)證與正確選擇。成都創(chuàng)新互聯(lián)公司提供完善的營(yíng)銷(xiāo)型網(wǎng)頁(yè)建站明細(xì)報(bào)價(jià)表。后期開(kāi)發(fā)更加便捷高效，我們致力于追求更美、更快、更規(guī)范。
類(lèi)MyApp：
MyHomePage:
state:
build:
此demo頁(yè)面涉及到兩個(gè)組件：圖片和icon。在這里做一個(gè)簡(jiǎn)單的介紹，更詳細(xì)的學(xué)習(xí)請(qǐng)參考flutter官網(wǎng)和相關(guān)書(shū)籍
在flutter中，我們可以通過(guò)Image組件來(lái)加載并顯示圖片，Image的數(shù)據(jù)源可以是asset、文件、內(nèi)存以及網(wǎng)絡(luò)。
ImageProvider 是一個(gè)抽象類(lèi)，主要定義了圖片數(shù)據(jù)獲取的接口 load() ，從不同的數(shù)據(jù)源獲取圖片需要實(shí)現(xiàn)不同的 ImageProvider ，如 AssetImage 是實(shí)現(xiàn)了從Asset中加載圖片的ImageProvider，而 NetworkImage 實(shí)現(xiàn)了從網(wǎng)絡(luò)加載圖片的ImageProvider。
Image也提供了一個(gè)快捷的構(gòu)造函數(shù) Image.asset 用于從asset中加載、顯示圖片：
Image也提供了一個(gè)快捷的構(gòu)造函數(shù) Image.network 用于從網(wǎng)絡(luò)加載、顯示圖片：
Flutter中，可以像web開(kāi)發(fā)一樣使用iconfont，iconfont也即"字體圖標(biāo)"，它是將圖標(biāo)做成字體文件，然后通過(guò)指定不同的字符而顯示不同的圖片。
加號(hào)為圖片組件，減一為icon組件。點(diǎn)擊加號(hào)，數(shù)字加1；點(diǎn)擊-1，數(shù)字減少1。
本文對(duì)比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加載速度，內(nèi)存使用情況。
測(cè)試網(wǎng)頁(yè)打開(kāi)的速度，只需要獲取 WebView 在開(kāi)始加載網(wǎng)頁(yè)和網(wǎng)頁(yè)加載完成時(shí)的時(shí)間戳，時(shí)間戳的差即為打開(kāi)網(wǎng)頁(yè)的時(shí)間
為了使差異更明顯，我們選擇較為復(fù)雜的 新浪首頁(yè) 進(jìn)行加載的對(duì)比，為了減小網(wǎng)絡(luò)對(duì)加載速度的影響，我們讓手機(jī)連接同一個(gè)網(wǎng)絡(luò)，分別進(jìn)行 10 次測(cè)試然后取平均值，另外，我們需要關(guān)閉 WebView 的緩存，防止緩存對(duì)加載速度產(chǎn)生影響
下面使筆者進(jìn)行 10 次測(cè)試所得到的數(shù)據(jù)
結(jié)果讓我有點(diǎn)驚訝，一直以為 WKWebView 會(huì)是個(gè)王者。結(jié)果看，速度上 WKWebView 略慢一點(diǎn)，不過(guò)總體差異不大（該結(jié)果僅僅是測(cè)試新浪的結(jié)果，僅供參考啦）
在這里，筆者又加了一個(gè)測(cè)試，嘗試記錄從 viewController 的 viewDidLoad 到 webview 的 didFinish 時(shí)間，測(cè)試了新浪的數(shù)據(jù)，如下：
UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加載完所有頁(yè)面）
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 主站的時(shí)間；UIWebViewA 的數(shù)據(jù)是因?yàn)樵诩虞d完 sina 主站之后，新浪又加載了一個(gè) ，所以導(dǎo)致總時(shí)間延長(zhǎng)，不過(guò)即使按照 UIWebViewB 的數(shù)據(jù)來(lái)比較，也是 wkWebView 略勝一籌。
此處可以看出 flutter_webView 使用的是 wkwebView，所以它吃虧的主要原因是 flutter 包了一層。
結(jié)論：
速度（didStart - didFinish） UIWebView flutter_webview WKWebView
速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview
這里查看內(nèi)存使用的是 xcode 的 debug session 中的 memory。
首先看之前測(cè)試時(shí)，連續(xù)打開(kāi)十次新浪的內(nèi)存情況
接著我們?cè)诳匆幌麓蜷_(kāi)淘寶首頁(yè)的內(nèi)存情況
從圖上可以看出，WKWebView 在內(nèi)存方面有很大的優(yōu)勢(shì)啊，UIWebView 的內(nèi)存是真的傷啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。
他相比較原生 WKWebView 的內(nèi)存開(kāi)銷(xiāo)稍大一點(diǎn)，從測(cè)試表現(xiàn)來(lái)看，一般大個(gè) 30 MB 左右。
結(jié)論：內(nèi)存 WKWebView flutter_webview UIWebView
可以在 html5test 中對(duì)瀏覽器的兼容性進(jìn)行評(píng)分，通過(guò)測(cè)試發(fā)現(xiàn)得分分別如下
因?yàn)?flutter 里使用的就是 WK，所以和原生的 WKWebView 一樣都是 444 分，比 UIWebView 的 437 略勝一籌
結(jié)論：兼容性 WKWebView = flutter_webview UIWebView
UIWebView : 速度相比較 WKWebView 稍快一點(diǎn)，但是內(nèi)存是一大硬傷，所以只要條件允許，就不推薦使用了
WKWebView : 速度略慢一點(diǎn)，不過(guò)差別不大，總體可以接受。是比UIWebView更好的選擇，推薦使用。
flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項(xiàng)目中，因?yàn)樗话艘粚?，所以?yè)面加載上存在一定的劣勢(shì)，所以混編項(xiàng)目中仍然推薦使用 WKWebView。不過(guò)如果從多端考慮、以及項(xiàng)目可遷移等，那么使用也未嘗不可，就是維護(hù)成本要增加一些，需要維護(hù)兩套 webView。這個(gè)就需要根據(jù)自己的情況自己取舍了。
這是他提的 ：
用的是這個(gè)官方動(dòng)畫(huà)效果
（ ）
運(yùn)行起來(lái)的效果 如下：就是在一個(gè)Column 中放置了3個(gè)的動(dòng)畫(huà)
目前測(cè)試App在前臺(tái)，運(yùn)行中的CPU的情況
打開(kāi)App的時(shí)候 CPU的使用率 ，當(dāng)App在做網(wǎng)絡(luò)請(qǐng)求的時(shí)候，占用率會(huì)更加的高
這是打開(kāi)百度翻譯的APP CPU占有率
記不記得這個(gè)圖片，電腦的CPU使用率，如果它的占用大于了60%，你就會(huì)發(fā)現(xiàn)電腦的風(fēng)扇在拼命的轉(zhuǎn)，而且電腦會(huì)運(yùn)行過(guò)慢
但是手機(jī)好像沒(méi)有像電腦那么嚴(yán)重，使用起來(lái)也沒(méi)有那么卡，這個(gè)和手機(jī)的固件設(shè)計(jì)有關(guān)系
這是另外一個(gè)小伙伴的公司的App內(nèi)存的占用情況
CPU使用率是性能測(cè)試是一項(xiàng)重要指標(biāo)，CPU占用過(guò)高會(huì)使得設(shè)備運(yùn)行程序出現(xiàn)卡頓與發(fā)熱，甚至出現(xiàn)應(yīng)用程序Crash,影響用戶體驗(yàn)。在排除硬件環(huán)境的限制下，應(yīng)用程序應(yīng)該盡可能少的占用CPU。
一個(gè)Demo，3個(gè)動(dòng)畫(huà)的CPU使用率達(dá)到了80%，如果用java or kotlin 去實(shí)現(xiàn)應(yīng)該不會(huì)有那么高的占有率，所以Flutter的還需要繼續(xù)的優(yōu)化。
(App性能測(cè)試—CPU使用率):
目前Flutter平臺(tái)主流的兩個(gè)播放器是video_player和fijkplayer
pub
github
1、Flutter平臺(tái)官方插件，作者是國(guó)外的，有問(wèn)題溝通比較困難，只能通過(guò)提交issue
2、硬解碼
4、UI封裝： better_player
基于video_player和Chewie的高級(jí)視頻播放器。它解決了許多典型的用例，并且易于運(yùn)行。
5、播放器寬高比例與視頻內(nèi)容寬高比例不一致時(shí)，會(huì)出現(xiàn)圖像壓縮變形的問(wèn)題
6、調(diào)用原生內(nèi)核播放器：iOS--AVPlayer， Android--ExoPlayer
7、對(duì)于分段源 m3u8 的播放不友好，如果一個(gè)切片播放超時(shí)，會(huì)導(dǎo)致整個(gè)播放都失敗
8、better_player可以緩存視頻，但不能自定義緩存的地址，只能指定key，和緩存的最大內(nèi)存量（還未研究超出最大的話是不能緩存新的，還是刪除最舊的）
9、better_player不能完全自定義UI，只能修改類(lèi)中的一些開(kāi)放屬性，比如說(shuō)icon圖標(biāo)，文字顏色啥的
10、無(wú)網(wǎng)絡(luò)有緩存時(shí)，封面可以正常展示
11、better_player播放失敗有手動(dòng)retry的設(shè)計(jì)
pub
github
1、fijkplayer 是一個(gè) Flutter 生態(tài)的媒體播放器，是對(duì) ijkplayer 的 Flutter 封裝，支持 Android 和 iOS。 fijkplayer 使用 ijkplayer 作為播放器內(nèi)核，ijkplayer 使用 ffmpeg 進(jìn)行音視頻解封裝和解碼，同時(shí)添加了 Android 和 iOS 平臺(tái)特有的硬件加速解碼能力。
2 、國(guó)內(nèi)有QQ群，但是活躍度也是不高。
3、可以緩存視頻，可以自定義緩存的地址，方便后續(xù)的內(nèi)存維護(hù)。
4、可以通過(guò)FijkPanelWidgetBuilder較大程度上自定義UI。
5、無(wú)網(wǎng)絡(luò)有緩存視頻時(shí)，無(wú)法展示封面，因?yàn)閮?nèi)部是通過(guò)imageProvider去加載網(wǎng)絡(luò)圖片的。
7、播放失敗無(wú)手動(dòng)retry的設(shè)計(jì)
1、兩種播放器都是通過(guò)外接紋理方案 (Texture)，將播放器視頻畫(huà)面渲染接入 flutter 中，性能上優(yōu)于 PlatformView 的接入方法。
如何自己實(shí)現(xiàn)？
下面以video_palyer的iOS源碼部分解釋：
iOS用CVPixelBufferRef將渲染出來(lái)的數(shù)據(jù)存在內(nèi)存中，F(xiàn)lutter engine會(huì)將Texture的數(shù)據(jù)在內(nèi)存中直接進(jìn)行映射無(wú)需通過(guò)Channel傳輸，然后Texture Widget就可以把你提供的這些數(shù)據(jù)顯示出來(lái)。在我們傳輸數(shù)據(jù)的時(shí)候會(huì)需要將其與 TextureID 綁定，綁定的過(guò)程通過(guò)BasicMessageChannel實(shí)現(xiàn)數(shù)據(jù)流的傳輸，以做到實(shí)時(shí)展示的效果
1.圓角對(duì)性能的影響
盡量避免用Clipxxx組件，建議用BoxDecoration的image屬性實(shí)現(xiàn)，如果用Clipxxx組件，圓角取整后性能會(huì)提升。
2.減少重繪
根據(jù)場(chǎng)景合理使用RePaintBoundary，使繪制獨(dú)立于父布局，避免重繪，提升性能，但過(guò)度使用增加的圖層會(huì)帶來(lái)Raster合成的耗時(shí)。例如scrollview是滑動(dòng)過(guò)程會(huì)導(dǎo)致所有的節(jié)點(diǎn)都重繪，可以在scrollview下一層使用RePaintBoundary。
3.滾動(dòng)步長(zhǎng)插值器優(yōu)化（了解）
官方的滾動(dòng)差值器在出現(xiàn)小卡頓時(shí)，滾動(dòng)步長(zhǎng)會(huì)出現(xiàn)大的跳躍，導(dǎo)致體感上出現(xiàn)很明顯的抖動(dòng)，優(yōu)化步長(zhǎng)偏移量算法與原生效果對(duì)齊。
4.開(kāi)啟SurfaceView
官方推薦Flutter用SurfaceView ，因?yàn)镾urfaceView與應(yīng)用窗口內(nèi)容分隔開(kāi)，在專有硬件中合成，產(chǎn)生的中間副本少于TextureView，所以性能高，占用內(nèi)存少，但是在混合棧遇到的問(wèn)題需要突破
5.使用RepaintBoundary 提升頻繁重繪控件的性能。使用RelayoutBoundary提升頻繁修改大小，增刪的布局中也可以提升性能。
6.build中不要去寫(xiě)大量的耗時(shí)邏輯，因?yàn)閿?shù)據(jù)更新會(huì)觸發(fā)build的多次調(diào)用，在里面做耗時(shí)邏輯會(huì)降低性能。
7.盡量使用statelessWidget代替statefulWidget，因?yàn)閟tatefulWidget的銷(xiāo)毀重建會(huì)引起子widget的銷(xiāo)毀與重建。
8.解析json可以放到子線程線程中，開(kāi)Isolate去解析，這樣，當(dāng)返回?cái)?shù)據(jù)特別大的時(shí)候也不會(huì)阻塞界面。
9.使用不變的組件的時(shí)候可以添加const，const組件不會(huì)進(jìn)行build更新
10.由于flutter通過(guò)widget.runtimeType和key來(lái)判斷是否需要跟新組建，所以我們寫(xiě)組件的時(shí)候盡量保持key不變，或者不寫(xiě)key。對(duì)于一些需要頻繁改變，例如新增、刪除、排序的最好加上key。如果type一直，如果不寫(xiě)key容易導(dǎo)致，element無(wú)法區(qū)分新舊widget，導(dǎo)致無(wú)法更新。
按照給定尺寸進(jìn)行圖片的解碼，而不是解碼整個(gè)圖片的尺寸，用來(lái)減少內(nèi)存的占用。
官方文檔：
官方說(shuō)明：
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.
使用：
三方庫(kù)： cached_network_image 限2.5.0之后版本才可用
設(shè)定最大的緩存寬度和高度 this.maxWidthDiskCache 、 this.maxHeightDiskCache
使用：
從相冊(cè)選取圖片，展示時(shí)使用指定尺寸寬高進(jìn)行處理。
使用三方庫(kù)：
使用自定義 provider 來(lái)指定所需圖片的寬高：
AssetEntityImageProvider 傳入寬高和圖片原圖 AssetEntity 數(shù)據(jù)。
provider 中 key.entity.thumbDataWithSize 方法：
進(jìn)入 entity 中 thumbDataWithSize 方法：
進(jìn)入 _getThumbDataWithId 方法中，
進(jìn)入getThumb：
調(diào)用iOS原生的獲取圖片方法，
進(jìn)入 getThumbWithId 方法，
原生實(shí)現(xiàn)獲取置頂寬高縮略圖方法實(shí)現(xiàn)：
使用 iOS 原生類(lèi) PHImageManager 的
來(lái)獲取縮略圖。
重慶分公司
重慶分公司
