Flutter 與 iOS 原生 webView 對比

本文對比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加載速度，內(nèi)存使用情況。

創(chuàng)新互聯(lián)專注于企業(yè)網(wǎng)絡(luò)營銷推廣、網(wǎng)站重做改版、武陵網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5高端網(wǎng)站建設(shè)、商城建設(shè)、集團公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為武陵等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

測試網(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屬于原生開發(fā)嗎

Flutter只是 谷歌的移動 UI 框架，在Android開發(fā)中，你可以理解為 嵌套在activity里面的一個view即可。

目前有純flutter開發(fā)，還有 flutter，原生混合開發(fā) 兩種模式。。

flutter與原生交互方法和底層原理分析

1.環(huán)境準(zhǔn)備， 參考鏈接

2.添加國內(nèi)環(huán)境配置： 參考鏈接

3.新建

name: String類型，代表Channel的名字，也是其唯一標(biāo)識符。

messager：BinaryMessenger類型，代表消息信使，是消息的發(fā)送與接收的工具。

codec: MessageCodec類型或MethodCodec類型，代表消息的編解碼器。

fluuter中的MessageCodec用于二進制格式數(shù)據(jù)與基礎(chǔ)數(shù)據(jù)之間的編解碼。BasicMessageChannel所使用的編解碼器就是MessageCodec。

iOS中，名稱為FlutterMessageCodec，是一個協(xié)議，定義了兩個方法：encode接收一個類型為id的消息，將其編碼為NSData類型，而decode接收NSData類型消息，將其解碼為id類型數(shù)據(jù)。

MessageCodec有多種不同的實現(xiàn)：

與MessageCodec不同的是，MethodCodec用于MethodCall對象的編解碼，一個MethodCall對象代表一次從Flutter端發(fā)起的方法調(diào)用。MethodCall有2個成員變量：String類型的method代表需要調(diào)用的方法名稱，通用類型(Android中為Object，iOS中為id)的arguments代表需要調(diào)用的方法入?yún)?/p>

由于處理的是方法調(diào)用，故相比于MessageCodec，MethodCodec多了對調(diào)用結(jié)果的處理。當(dāng)方法調(diào)用成功時，使用encodeSuccessEnvelope將result編碼為二進制數(shù)據(jù)，而當(dāng)方法調(diào)用失敗時，則使用encodeErrorEnvelope將error的code、message、detail編碼為二進制數(shù)據(jù)

MethodCodec有兩種實現(xiàn)：

標(biāo)題名稱：flutter和原生,flutter和原生共用一套資源
文章來源：http://jinyejixie.com/article6/dsdjjig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、微信小程序、外貿(mào)建站、自適應(yīng)網(wǎng)站、全網(wǎng)營銷推廣、虛擬主機

廣告

聲明：本網(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)