本文对比的是 UIWebView、WKWebView、flutter_webview_plugin(在iOS中使用的是WKWebView)的加载速度,内存使用情况。
创新互联专业为企业提供阿勒泰网站建设、阿勒泰做网站、阿勒泰网站设计、阿勒泰网站制作等企业网站建设、网页设计与制作、阿勒泰企业网站模板建站服务,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。这个就需要根据自己的情况自己取舍了。
1、常用布局的对比
使用下来其他组件大致还算方便,但是相对布局而言使用便利程度上Android原生完胜,ConstraintLayout内部的所有子View可以设置互相之间的位置依赖关系。
而Flutter的Stack组件内部的Children只能通过外层包裹 Align后 固定位置,比如 Alignment.topLeft、Alignment.bottomRight 等。遇到复杂的堆叠布局需要通过外层包裹 Positioned 组件后设置固定的 top 和 left 距离以达到效果,内部子组件之间无法设置位置关联关系。
2、一些常用属性设置上的差异:
Margin外边距
Android:直接在布局文件对View设置android:layout_marginStart、android:layout_marginTop
Flutter:需嵌套 Container 组件并在内部设置具体的 margin 值
Padding内边距
Android:TextView、ImageView、各种Layout都可以直接在属性上设置android:paddingStart
Flutter:需嵌套 Padding 组件并在内部设置具体的值
组件的可见性
Android:每个view都可以通过setVisibility来设置可见、隐藏或者隐藏但占位
Flutter:没有单独设置组件是否显示的api,只能通过 bool 值控制是否添加该组件
事件监听
Android:常规的setOnClickListener和setOnLongClickListener设置单击和长按事件
Flutter:在需要添加事件监听的组件外层嵌套 InkWell 或 GestureDetector 并设置 onTap 等
3、生命周期
Android:
Activity和Fragment各自有完整的生命周期链路onCreate、onStart、onResume、onPause、onDestroy等
Flutter:
万物皆组件,组件继承 WidgetsBindingObserver 并重写 didChangeAppLifecycleState 函数进行监听
退回桌面依次执行inactive 》= paused,此时界面不可见用户不可操作,从桌面重新进入app执行resumed,状态较少如需在某些条件下触发特定操作可能要找别的方案,比如发通知之类的
没有。
咸鱼flutter没有换成h5,咸鱼不仅有flutter的开发应用,还包括h5的开发应用,flutterflutter更偏向客户端的研发体系,h5性能稳定,因为二者有不同的优势,所以咸鱼flutter没有换成h5,而是两者共用。
咸鱼flutter是一个全新的移动UI框架,它允许使用同一个代码库构建高性能的Android和iOS应用,在此基础之上,以h5为数据分析的系统,进行大数据分析,从而二者共同促进咸鱼的使用率。
需求,app中使用webview和h5交互,根据h5发过来的消息,在屏幕上展示flutter组件,并且可以发送消息给h5。
首先使用的组件是flutter_WebView_plugin,这个组件不能嵌套flutter组件,所以放弃这个组件。
flutter_inappbrowser 可以实现组合布局, 所以选用了此库, GitHub链接
[
前言
为什么跨平台是发展趋势?
同一个应用,各个“端”独立开发,不仅开发周期长,而且人员成本高。同时,作为技术人员,也不应该满足于这种重复、低能的工作状态。在这样的形势下,跨平台的技术方案也受到越来越多人和企业的关注。
本篇文章我将从原理、优缺点等方面为大家分享跨平台技术
一. H5
说到跨平台,没人不知道H5。不管是在Mac、Windows、Linux、iOS、Android还是其他平台,只要给一个浏览器,连“月球”上它都能跑。
1.浏览器架构
下面,我们来看看让H5如此横行霸道的浏览器的架构:
浏览器由以上7个部分组成,而“渲染引擎”是性能优化的重中之重,一起了解其中的渲染原理。
2.渲染引擎原理
不同的浏览器内核不同,渲染过程会不太一样,但主要流程还是一致的。
分为下面6步骤:
从以上6步,我们可以总结渲染优化的要点:
以上就是浏览器端的内容。但H5作为跨平台技术的载体,是如何与不同平台的App进行交互的呢?这时候JSBridge就该出场了。
3.JSBridge原理
JSBridge,顾名思义,是JS和Native之间的桥梁,用来进行JS和Native之间的通信。
通信分为以下两个维度:
那么App内加载H5的过程是什么样的呢?
4.App打开H5过程
打开H5分为4个阶段:
这四步,对应的过程如上图所以,我们可以针对性的做性能优化。
5.优缺点分析
下面,我们进行H5的优缺点分析:
优点
缺点
虽然H5目前还存在不足,但随着PWA、WebAssembly等技术的进步,相信H5在未来能够得到越来也好的发展。
二.小程序
2018年是微信小程序飞速发展的一年,19年,各大厂商快速跟进,已经有了很大的影响力。下面,我们以微信小程序为例,分析小程序的技术架构。
小程序跟H5一样,也是基于Webview实现。但它包含View视图层、App Service逻辑层两部分,分别独立运行在各自的WebView线程中。
1.View
可以理解为h5的页面,提供UI渲染。由WAWebview.js来提供底层的功能,具体如下:
每个窗口都有一个独立的WebView进程,因此微信限制不能打开超过5个层级的页面来保障用户体验。
2. App Service
提供逻辑处理、数据请求、接口调用。由WAService.js来提供底层的功能,具体如下:
运行环境:
仅有一个WebView进程
3.View App Service通信
视图层和逻辑层通过系统层的JSBridage进行通信,逻辑层把数据变化通知到视图层,触发视图层页面更新,视图层将触发的事件通知到逻辑层进行业务处理。
4. 优缺点分析
优点
缺点
既然WebView性能不佳,那有没有更好的方案呢?下面我们看看React Native。
三.React Native
RN的理念是在不同平台上编写基于React的代码,实现Learn once, write anywhere。
Virtual DOM在内存中,可以通过不同的渲染引擎生成不同平台下的UI,JS和Native之间通过Bridge通信
1.React Native 工作原理
在 React 框架中,JSX 源码通过 React 框架最终渲染到了浏览器的真实 DOM 中,而在 React Native 框架中,JSX 源码通过 React Native 框架编译后,与Native原生的UI组件进行映射,用原生代替DOM元素来渲染,在UI渲染上非常接近Native App。
2.React Native 与Native平台通信
3.优缺点分析
优点
缺点
4.RN展望
虽然RN还存在不足,但RN新版本已经做了如下改进,并且RN团队也在积极准备大版本重构,能否成为开发者们所信赖的跨平台方案,让我们拭目以待。
既然React Native在渲染方面还摆脱不了原生,那有没有一种方案是直接操控GPU,自制引擎渲染呢,我们终于迎来了Flutter!
四.Flutter
Flutter是Google开发的一套全新的跨平台、开源UI框架,支持iOS、Android系统开发,并且是未来新操作系统Fuchsia的默认开发套件。渲染引擎依靠跨平台的Skia图形库来实现,依赖系统的只有图形绘制相关的接口,可以在最大程度上保证不同平台、不同设备的体验一致性,逻辑处理使用支持AOT的Dart语言,执行效率也比JavaScript高得多。
1.Flutter架构原理
2.Dart优势
很多人会好奇,为什么Flutter要用Dart,而不是用JavaScript开发,这里列下Dart的优势
3.优缺点分析
优点
缺点