自己写flutter也有段时间了,这次来聊聊flutter开发App和原生iOS开发App各有什么优缺点.
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：主机域名、雅安服务器托管、营销软件、网站建设、邯山网站维护、网站推广。
不废话,直奔主题????
本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。
测试网页打开的速度，只需要获取 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。这个就需要根据自己的情况自己取舍了。
前言
为什么跨平台是发展趋势？
同一个应用，各个“端”独立开发，不仅开发周期长，而且人员成本高。同时，作为技术人员，也不应该满足于这种重复、低能的工作状态。在这样的形势下，跨平台的技术方案也受到越来越多人和企业的关注。
本篇文章我将从原理、优缺点等方面为大家分享跨平台技术
一. 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.优缺点分析
优点
缺点
腾讯课堂14M
今日头条3M
闲鱼22M
百度贴吧13M
蚂蚁财富56.8M
百度网盘14M
手机淘宝15M
贝壳找房8M
由粗粒度小组件动态拼装出页面，Native端已经有很多成熟的框架，如天猫的Tangram。
开发语言：iOS、Android
适用场景：快速迭代的活动营销页面
优点：无侵入，更新简单
缺点：提前预埋，扩展性差，灵活性差
以webview作为容器的app，历史悠久，最早到2011年。
开发语言：HTML
适用场景：双端严格一致的银行类app，容器类的支付宝小程序等
优点：动态更新，跨平台
缺点：性能，加载速度
UI用Xml+JS表达，用Native View渲染。
开发语言：Xml+JS
适用场景：双端严格一致的银行类app，容器类的支付宝小程序等
优点：native组件，生态成熟
缺点：三方库crash，性能缺陷
UI用Dart表达，用Dart engine渲染。
Flutter官方不支持动态化。原因是Flutter在 Release 模式下构建的是 AOT 编译产物，在 Debug 模式下构建的是 JIT ，AOT 依赖的 Dart VM 和 JIT 并不一样， JIT Release 并不支持 iOS 设备。可行的方案是：AOT 需要一个编译后的 “Dart VM”。抽离一份 DartVM 独立编译，再以动态库的形式引入项目。
开发语言：Dart
适用场景：iOS、Android、Web、Desktop、Embed
优点：性能最佳
缺点：增大包体积 20MB+
大厂的主流方案。UI用JS表达，用Dart engine渲染。
开发语言：JS、类JS
适用场景：iOS、Android
优点：性能最佳
缺点：需要掌握JS、Dart两个语言和框架
大厂的主流方案。UI用Dart表达，用Dart engineX渲染。
开发语言：Dart
适用场景：iOS、Android
优点：性能最佳
缺点：需要改造Dart engine
1、 美团外卖Flutter动态化实践
2、 携程App 首页动态化探索
3、 Flutter 动态化在最右 App 中的实践
4、 Flutter 动态化热更新的思考与实践
5、 NOW直播Flutter动态搜索列表页实现
6、 Flutter动态化的方案对比及最佳实现-闲鱼
7、 基于JavaScript 的MXFlutter
