189 8069 5689
本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。
创新互联专注于企业网络营销推广、网站重做改版、武陵网站定制设计、自适应品牌网站建设、H5高端网站建设、商城建设、集团公司官网建设、成都外贸网站制作、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为武陵等各大城市提供网站开发制作服务。
测试网页打开的速度，只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳，时间戳的差即为打开网页的时间
为了使差异更明显，我们选择较为复杂的 新浪首页 进行加载的对比，为了减小网络对加载速度的影响，我们让手机连接同一个网络，分别进行 10 次测试然后取平均值，另外，我们需要关闭 WebView 的缓存，防止缓存对加载速度产生影响
下面使笔者进行 10 次测试所得到的数据
结果让我有点惊讶，一直以为 WKWebView 会是个王者。结果看，速度上 WKWebView 略慢一点，不过总体差异不大（该结果仅仅是测试新浪的结果，仅供参考啦）
在这里，笔者又加了一个测试，尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间，测试了新浪的数据，如下：
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 的数据就是加载 sina 主站的时间；UIWebViewA 的数据是因为在加载完 sina 主站之后，新浪又加载了一个 ，所以导致总时间延长，不过即使按照 UIWebViewB 的数据来比较，也是 wkWebView 略胜一筹。
此处可以看出 flutter_webView 使用的是 wkwebView，所以它吃亏的主要原因是 flutter 包了一层。
结论：
速度（didStart - didFinish） UIWebView flutter_webview WKWebView
速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview
这里查看内存使用的是 xcode 的 debug session 中的 memory。
首先看之前测试时，连续打开十次新浪的内存情况
接着我们在看一下打开淘宝首页的内存情况
从图上可以看出，WKWebView 在内存方面有很大的优势啊，UIWebView 的内存是真的伤啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。
他相比较原生 WKWebView 的内存开销稍大一点，从测试表现来看，一般大个 30 MB 左右。
结论：内存 WKWebView flutter_webview UIWebView
可以在 html5test 中对浏览器的兼容性进行评分，通过测试发现得分分别如下
因为 flutter 里使用的就是 WK，所以和原生的 WKWebView 一样都是 444 分，比 UIWebView 的 437 略胜一筹
结论：兼容性 WKWebView = flutter_webview UIWebView
UIWebView : 速度相比较 WKWebView 稍快一点，但是内存是一大硬伤，所以只要条件允许，就不推荐使用了
WKWebView : 速度略慢一点，不过差别不大，总体可以接受。是比UIWebView更好的选择，推荐使用。
flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以总体和 native WKWebView 表现差不多。如果是混编项目中，因为它被包了一层，所以页面加载上存在一定的劣势，所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等，那么使用也未尝不可，就是维护成本要增加一些，需要维护两套 webView。这个就需要根据自己的情况自己取舍了。
Flutter只是 谷歌的移动 UI 框架，在Android开发中，你可以理解为 嵌套在activity里面的一个view即可。
目前有纯flutter开发，还有 flutter，原生混合开发 两种模式。。
1.环境准备， 参考链接
2.添加国内环境配置： 参考链接
3.新建
name: String类型，代表Channel的名字，也是其唯一标识符。
messager：BinaryMessenger类型，代表消息信使，是消息的发送与接收的工具。
codec: MessageCodec类型或MethodCodec类型，代表消息的编解码器。
fluuter中的MessageCodec用于二进制格式数据与基础数据之间的编解码。BasicMessageChannel所使用的编解码器就是MessageCodec。
iOS中，名称为FlutterMessageCodec，是一个协议，定义了两个方法：encode接收一个类型为id的消息，将其编码为NSData类型，而decode接收NSData类型消息，将其解码为id类型数据。
MessageCodec有多种不同的实现：
与MessageCodec不同的是，MethodCodec用于MethodCall对象的编解码，一个MethodCall对象代表一次从Flutter端发起的方法调用。MethodCall有2个成员变量：String类型的method代表需要调用的方法名称，通用类型(Android中为Object，iOS中为id)的arguments代表需要调用的方法入参
由于处理的是方法调用，故相比于MessageCodec，MethodCodec多了对调用结果的处理。当方法调用成功时，使用encodeSuccessEnvelope将result编码为二进制数据，而当方法调用失败时，则使用encodeErrorEnvelope将error的code、message、detail编码为二进制数据
MethodCodec有两种实现：