新网创想网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
本文对比的是 UIWebView、WKWebView、flutter_webview_plugin(在iOS中使用的是WKWebView)的加载速度,内存使用情况。
创新互联是一家专业提供密云企业网站建设,专注与成都网站设计、成都做网站、H5网站设计、小程序制作等业务。10年已为密云众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。
测试网页打开的速度,只需要获取 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。这个就需要根据自己的情况自己取舍了。
Uniapp目前比较成熟,而且用的是Vue语法,学习成本比较低,而且行业里面用的也比较广泛,而Flutter的话,学习成本略高,因为要学习新的语言,还有就是目前生态不是特别完备,等他再发展发展吧。黑马程序员官网有成套免费视频哦,有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策
转自
在 Flutter 中,有两类常用的 Widget:
在开发过程中,我们经常需要继承它们两来实现自己的 Widget。
一个 StatelessWidget 是不能被改变的,比如: Icon 、 Text 等。
如果你的控件一旦显示,就不需要再做任何的变更,那么你应该使用 StatelessWidget 。
实现一个自己的 StatelessWidget 很简单。
当你看到下面这个例子?时,你就知道它有多简单了。
看,只要在 build() 中返回你的视图就可以了。
一个 StatefulWidget 是有状态的,可变的。
它可以改变自己的外观,以响应用户的操作或者数据的变化。
比如: CheckBox 、 Switch ..
我们之所以能够改变一个 StatefulWidget ,是因为它有一个设置状态的函数:
调用这个函数后,就会触发 StatefulWidget 的视图树重建。
因此,当我们需要一个可交互的,即能根据用户操作或数据变化而改变视图的 Widget 时,那就得用上 StatelessWidget 了。
现在,来创建一个自定义的 StatefulWidget:
从上面的例子中可以看到, StatefulWidget 会要求提供一个含有视图树的 State 。
既然 State 能够控制一个视图的状态,那它肯定会有一系列的生命周期。
上图就是 State 的生命周期图。