Flutter 與 iOS 原生 webView 對比

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

創(chuàng)新互聯(lián)公司主要從事網(wǎng)站設計、成都網(wǎng)站制作、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務澠池,10年網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:13518219792

測試網(wǎng)頁打開的速度，只需要獲取 WebView 在開始加載網(wǎng)頁和網(wǎng)頁加載完成時的時間戳，時間戳的差即為打開網(wǎng)頁的時間

為了使差異更明顯，我們選擇較為復雜的 新浪首頁 進行加載的對比，為了減小網(wǎng)絡對加載速度的影響，我們讓手機連接同一個網(wǎng)絡，分別進行 10 次測試然后取平均值，另外，我們需要關閉 WebView 的緩存，防止緩存對加載速度產(chǎn)生影響

下面使筆者進行 10 次測試所得到的數(shù)據(jù)

結果讓我有點驚訝，一直以為 WKWebView 會是個王者。結果看，速度上 WKWebView 略慢一點，不過總體差異不大（該結果僅僅是測試新浪的結果，僅供參考啦）

在這里，筆者又加了一個測試，嘗試記錄從 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 主站之后，新浪又加載了一個 ，所以導致總時間延長，不過即使按照 UIWebViewB 的數(shù)據(jù)來比較，也是 wkWebView 略勝一籌。

此處可以看出 flutter_webView 使用的是 wkwebView，所以它吃虧的主要原因是 flutter 包了一層。

結論：

速度（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 左右。

結論：內(nèi)存 WKWebView flutter_webview UIWebView

可以在 html5test 中對瀏覽器的兼容性進行評分，通過測試發(fā)現(xiàn)得分分別如下

因為 flutter 里使用的就是 WK，所以和原生的 WKWebView 一樣都是 444 分，比 UIWebView 的 437 略勝一籌

結論：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比較 WKWebView 稍快一點，但是內(nèi)存是一大硬傷，所以只要條件允許，就不推薦使用了

WKWebView : 速度略慢一點，不過差別不大，總體可以接受。是比UIWebView更好的選擇，推薦使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以總體和 native WKWebView 表現(xiàn)差不多。如果是混編項目中，因為它被包了一層，所以頁面加載上存在一定的劣勢，所以混編項目中仍然推薦使用 WKWebView。不過如果從多端考慮、以及項目可遷移等，那么使用也未嘗不可，就是維護成本要增加一些，需要維護兩套 webView。這個就需要根據(jù)自己的情況自己取舍了。

我的第一個flutter項目：購物app

這是個產(chǎn)假作業(yè)。故事是這樣的。

生了娃，生活一地雞毛。擦，碎鈔機的需求怎么那么多。

當時，有一堆返利優(yōu)惠券app比較火

...這里扯多了這篇文章被鎖了....

我就想，來扒一扒，他們是怎么賺錢的。

結論：淘寶聯(lián)盟。

淘寶聯(lián)盟是阿里巴巴旗下的親兒子，不那么有名是因為是個私生子吧，官網(wǎng)上還有個沒聽過的名號叫“阿里媽媽”，呵呵。淘寶聯(lián)盟是給淘寶上推廣商品的人用的，他們有一個專門的名稱，叫做淘寶客，即“推廣者（Publisher）”，他們幫電商平臺推薦商品給別的買家，買家購買后，電商平臺可以增加銷量，而他們則可以獲得推廣傭金。

后來，知道京東也有自己的聯(lián)盟平臺，叫做“京東聯(lián)盟”，拼多多也有，叫做“多多進寶”。

回到這些app的賺錢邏輯上來。對于用戶而言，它們的兩個噱頭是：

“用我們的app買，你可以自用省錢”

“用我們的app，分享給別人下單，你可以賺錢！”

所以，這些app推廣起來很容易啊，因為誰用誰賺錢呀！

那么為何不自己搭一個呢？

與其這些傭金落到別人口袋，不如自己直接做最頂層上線，發(fā)展出N個下線，豈不是躺著賺錢，哈哈哈哈哈

搞清楚賺錢邏輯之后，我發(fā)現(xiàn)淘寶聯(lián)盟的api是很開放的。

商品鏈接： ;pid=mm_343780171_368000361_101527600308itemId=595640102734src=qtka_wxxtdx=1

其中，activityId是優(yōu)惠券id，pid是推廣者在阿里媽媽官網(wǎng)注冊的id，只有這個id是我注冊的，那么傭金就到我口袋去了，哈哈哈。

剛好練一下flutter，一次開發(fā)，兩端使用，我一個人就可以了。app暫時取名為“小豬購”，拿粉紅豬貼牌。

演示視頻：

Flutter/IOS混和開發(fā)情況下，項目內(nèi)首個Flutter頁面導航無返回問題

在Flutter內(nèi)部機制中，默認使用自動管理導航機制，該機制在Flutter與原生混和開發(fā)情況下，F(xiàn)lutter頁面不一定作為項目的首頁面，所以出現(xiàn)需要在首個Flutter頁面使用導航返回的需求。

Flutter的AppBar中定義有屬性：

該屬性默認為YES，即默認為自動管理導航欄，該情況下其會在非第一個Flutter頁面創(chuàng)建導航返回按鈕，我們在AppBar中將其設置為false：

并且手動添加導航返回按鈕：

完成