Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策
创新互联公司是一家集网站建设,临河企业网站建设,临河品牌网站建设,网站定制,临河网站建设报价,网络营销,网络优化,临河网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
本文对比的是 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。这个就需要根据自己的情况自己取舍了。
Flutter是谷歌公司推出的跨终端的开发框架，支持Android、iOS和WEB终端。1.0版在2018年12月5日发布，目前的最新版本是1.5，它采用的开发语言是Dart，Dart也是谷歌开发的计算机编程语言，语法类似C，是编译型语言：
hello world例子，打印字符串“Hello World!”：
1、没有桥接层
React Native、Weex等技术都是跨终端的框架，然而性能跟原生App存在很大差距。这是由于它们的工作原理决定的：
React Native、Weex等技术多了一个桥接层，所以界面渲染会慢一些，由于UI渲染非常频繁，想要不卡顿，基本上比较难，性能和用户体验跟原生代码有差距。而这恰恰是Flutter的优势所在：
Dart可以被编译成不同平台的本地代码，让Flutter不通过桥接层直接跟平台通信，自然性能会快一些。
2、编译执行
JavaScript是解释执行的，Dart是编译执行的，性能谁好一目了然。
3、Flutter Engine虚拟机
Flutter是依靠Flutter Engine虚拟机在iOS和Android上运行的，Flutter Engine使用C/C++编写，开发人员通过Flutter框架直接和API在内部进行交互，所以具有输入低延迟和UI渲染高帧速率的特点。除了这特点之外，Flutter还提供了自己的小部件，Flutter小部件是使用从React获取灵感的现代框架构建的。 中心思想是您使用小部件构建UI。
窗口小部件根据其当前配置和状态描述了它们的视图。 当窗口小部件的状态发生更改时，窗口小部件会重建其描述，框架将根据前面的描述进行区分，以确定底层呈现树从一个状态转换到下一个状态所需的最小更改。可以直接在OS平台提供的画布上进行描绘，也就是一些核心类库直接放到虚拟机里面，调用起来更快。
从它的系统结构可以看出，类似安卓的ART(Android Run Time)虚拟机，同样采用AOT(Ahead of TIme)技术，会在APP安装时就编译成机器语言，不再解释执行，从而优化了APP运行的性能。
4、自带渲染引擎
Flutter使用谷歌自己的Skia渲染引擎，而Android系统自带Skia引擎，iOS平台上Flutter也会把Skia引擎打包到APP中，从而实现了高效渲染。而React Native通过桥接层访问原生UI，操作频繁就容易出性能问题。
综合所述，Flutter 是性能最接近原生代码 的一种开发框架，未来也会是构建谷歌Fuchsia应用的主要方式，前途不可限量，唯一的问题就是需要学习一门新的语言：Dart，而有Java或者C#语言基础的程序员会比较容易学习。
细心的开发者会发现flutter构建的App体积比native的大一些，是什么原因造成App体积大呢？
其实flutter 在release时App体积和native的大小差不多，而debug时体积通常会大。debug版本体积较大是为了Hot reload和快速编译。如果有flutter开发经验的朋友都体验过，如果您修改一下App的背景颜色，只需save一下就可以立刻看到修改后效果。我称之为“像艺术家一样在创造App”，因此为了实现这些目标，提高开发的效率，debug将占用全部资源。而当我们构建release版时，flutter又会采用AOT策略，提高App运行效率，release版只打包必需的资源，因而体积又会减少。
另外，flutter团队也一直在寻找减小程序大小的方法。
