flutter对比前端,flutter 比较

别人说前端的前景不好,后端的发展会好很多？

方向不同岗位对比自然也就不同，一千个人眼里有一千个哈姆雷特

网站建设哪家好，找成都创新互联！专注于网页设计、网站建设、微信开发、小程序制作、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了镇原免费建站欢迎大家使用！

关于Web前端开发，近几年发生了诸多新闻，从React v16普及，到jQuery被GitHub下掉完成阶段性历史使命，再到版本帝AngularJS发布v6和v7两个版本让人们更多地看到了PC端开发的走向。那么，2020年Web前端开发的趋势如何？带你详细了解下。

一、端

Web前端开发的有一个方向就是端体系的打通发展。前端通俗一点理解可以视为是靠前一点的端。而端口的不统一或者说不够树形多态是其麻烦之处。因此在打通场景上会遇到诸多的问题，于是端体系的打通与发展是一个很重要的道路。无论是从产品、业务还是技术角度来说，都是一个具有挑战意义的方向。

二、DevOps的成熟

DevOps是整个IT价值流中实施精益原则的结果。延续端的打通，Web前端将为为整个 DevOps 步调提供服务。从评审=开发=CR=测试=灰度=回滚=发布=运维+运营，单点发展演变为线性发展，形成一套完整的方案。

三、前端云化

GUI 的发展，最终是要发展成云端的形态，这将不仅是前端要的形态，也是服务端的一个形态。我们能体会到的贯穿 DevOps 流程的云态，这个只是一个方向，并不是所有都会去到这个方向。

四、可视化领域

随着端+云化的状态，可视化的领域将进一步的发展，渲染等瓶颈会逐渐增高，以及加上 5G 的发展，必将在 DT 时代为前端带来更多的可视化方向和领域。

五、Flutter

严格来讲，Flutter并不是前端技术，而是“客户端”技术。而目前Web前端的地位远远不如客户端。对于大多数的公司来说。移动App所带来的现金流，仅仅靠下载和推广就可以养活一个灰色的产业链。而移动Web的收益可能不值一提。那么前端与客户端的合二为一的发展趋势是否也将是一个重要的方向！

总之，Web前端开发的就业前景形势一片大好，所以学起来也要趁早，现在很多专业培训学校都很不错，比如北大青鸟、南京中博软件学院和课工场等等，你可以试听课程综合考虑。

为什么Flutter开发APP性能最接近原生，前端程序员请关注

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#语言基础的程序员会比较容易学习。

学js还是直接flutter

js先学在学Flutter

Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面。Flutter可以与现有的代码一起工作。在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。

Flutter组件采用现代响应式框架构建，这是从React中获得的灵感，中心思想是用组件(widget)构建你的UI。组件描述了在给定其当前配置和状态时他们显示的样子。当组件状态改变，组件会重构它的描述(description)，Flutter会对比之前的描述，以确定底层渲染树从当前状态转换到下一个状态所需要的最小更改。

Flutter 与 iOS 原生 webView 对比

本文对比的是 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。这个就需要根据自己的情况自己取舍了。