浅谈flutter

1.什么是flutter？

1.1原生开发

移动端的原生开发，好比Android，对应的开发语言java或kotlin；IOS，对应的开发语言Objective-C或者Swift。原生开发具备速度快，性能高，可实现自定义复杂动画，用户体验较好；还可以访问平台所有功能（例如GPS、摄像头）。可是人力成本较高，须要两个特定的团队维护一样的产品。版本迭代，开发，测试成本都会变大。

1.2跨平台开发

针对原生面临的问题，人们一直都在寻找好的解决方案，因此就有跨平台的框架，先实现一处开发，能够运行在多个平台上，看看下面都有哪些跨平台技术：

• H5+原生（Cordova、Ionic、微信小程序）
• JavaScript开发+原生渲染 （React Native、Weex、快应用）
• 自绘UI+原生(QT for mobile、Flutter)

H5+原生混合开发

这类框架主要原理就是将APP的一部分须要动态变更的内容经过H5来实现，经过原生的网页加载控件WebView (Android)或WKWebView（iOS）来加载。这样以来，H5部分是能够随时改变而不用发版，动态化需求能知足；同时，因为h5代码只须要一次开发，就能同时在Android和iOS两个平台运行

混合开发原理

而混合框架通常都会在原生代码中预先实现一些访问系统能力的API， 而后暴露给WebView以供JavaScript调用，这样一来，WebView就成为了JavaScript与原生API之间通讯的桥梁，主要负责JavaScript与原生之间传递调用消息，而消息的传递必须遵照一个标准的协议，它规定了消息的格式与含义，咱们把依赖于WebView的用于在JavaScript与原生之间通讯的工具称之为WebView JavaScript Bridge, 简称JsBridge，它也是混合开发框架的核心。

react native(RN)

React Native 是React在原生移动应用平台的衍生产物，那二者主要的区别是什么呢？其实，主要的区别在于虚拟DOM映射的对象是什么？React中虚拟DOM最终会映射为浏览器DOM树，而RN中虚拟DOM会经过 JavaScriptCore 映射为原生控件树

• React中提出一个重要思想：状态改变则UI随之自动改变，而React框架自己就是响应用户状态改变的事件而执行从新构建用户界面的工做，这就是典型的响应式编程范式

JavaScriptCore 是一个JavaScript解释器，它在React Native中主要有两个做用：

• 为JavaScript提供运行环境。
• 是JavaScript与原生应用之间通讯的桥梁，做用和JsBridge同样，事实上，在iOS中，不少JsBridge的实现都是基于 JavaScriptCore 。

React Native 便实现了跨平台。 相对于混合应用，因为React Native是原生控件渲染，因此性能会比混合应用中H5好不少，同时React Native使用了Web开发技术栈，也只需维护一份代码，一样是跨平台框架

Weex

Weex是阿里巴巴于2016年发布的跨平台移动端开发框架，思想及原理和React Native相似，最大的不一样是语法层面，Weex支持Vue语法和Rax语法，Rax 的 DSL(Domain Specific Language) 语法是基于 React JSX 语法而创造。与 React 不一样，在 Rax 中 JSX 是必选的，它不支持经过其它方式建立组件，因此学习 JSX 是使用 Rax 的必要基础。而React Native只支持JSX语法。

快应用

快应用是华为、小米、OPPO、魅族等国内9大主流手机厂商共同制定的轻量级应用标准，目标直指微信小程序。它也是采用JavaScript语言开发，原生控件渲染，与React Native和Weex相比主要有两点不一样：

• 快应用自身不支持Vue或React语法，其采用原生JavaScript开发，其开发框架和微信小程序很像，值得一提的是小程序目前已经可使用Vue语法开发（mpvue），从原理上来说，Vue的语法也能够移植到快应用上。
• React Native和Weex的渲染/排版引擎是集成到框架中的，每个APP都须要打包一份，安装包体积较大；而快应用渲染/排版引擎是集成到ROM中的，应用中无需打包，安装包体积小，正因如此，快应用才能在保证性能的同时作到快速分发。

JavaScript开发+原生渲染的优缺点

优势：

• 采用Web开发技术栈，社区庞大、上手快、开发成本相对较低。
• 原生渲染，性能相比H5提升不少。
• 动态化较好，支持热更新。

不足：

• 渲染时须要JavaScript和原生之间通讯，在有些场景如拖动可能会由于通讯频繁致使卡顿。
• JavaScript为脚本语言，执行时须要JIT(Just In Time)，执行效率和AOT(Ahead Of Time)代码仍有差距。
• 因为渲染依赖原生控件，不一样平台的控件须要单独维护，而且当系统更新时，社区控件可能会滞后；除此以外，其控件系统也会受到原生UI系统限制，例如，在Android中，手势冲突消歧规则是固定的，这在使用不一样人写的控件嵌套时，手势冲突问题将会变得很是棘手。

QT

Qt是一个1991年由Qt Company开发的跨平台C++图形用户界面应用程序开发框架。2008年，Qt Company科技被诺基亚公司收购，Qt也所以成为诺基亚旗下的编程语言工具。2012年，Qt被Digia收购。2014年4月，跨平台集成开发环境Qt Creator 3.1.0正式发布，实现了对于iOS的彻底支持，新增WinRT、Beautifier等插件，废弃了无Python接口的GDB调试支持，集成了基于Clang的C/C++代码模块，并对Android支持作出了调整，至此实现了全面支持iOS、Android、WP，它提供给应用程序开发者构建图形用户界面所需的全部功能。可是，QT虽然在PC端得到了巨大成功，备受社区追捧，然而其在移动端却表现不佳，在近几年，虽然偶尔能听到QT的声音，但一直很弱，不管QT自己技术如何、设计思想如何，但事实上终究是败了，没火起来感受有一下缘由：

• QT移动开发社区过小，学习资料不足，生态很差
• 官方推广不利，支持不够。
• 移动端发力较晚，市场已被其它动态化框架占领（Hybrid和RN)。
• 在移动开发中，C++开发和Web开发栈相比有着先天的劣势，直接结果就是QT开发效率过低。

终于引出了本文重点-flutter

Flutter是Google发布的一个用于建立跨平台、高性能移动应用的框架。Flutter和QT mobile同样，都没有使用原生控件，相反都实现了一个自绘引擎，使用自身的布局、绘制系统。那么，咱们会担忧，QT mobile面对的问题Flutter是否也同样，Flutter会不会步入QT mobile后尘，成为另外一个烈士？要回到这个问题，咱们先来看看Flutter诞生过程：

• 2017 年 Google I/O 大会上，Google 首次推出了一款新的用于建立跨平台、高性能的移动应用框架——Flutter
• 2018年2月，Flutter发布了第一个Beta版本，同年五月， 在2018年Google I/O 大会上，Flutter 更新到了 beta 3 版本。
• 2018年6月，Flutter发布了首个预览版本，这意味着 Flutter 进入了正式版（1.0）发布前的最后阶段。 观其发展，在2018年5月份，Flutter 进入了 GitHub stars 排行榜前 100 名，已有 27k star。而今天(2019年5月29日)，已经有65K的Star。经历了短短2年多的时间，Flutter 生态系统得以快速增加，因而可知，Flutter在开发者中受到了热烈的欢迎，其将来发展值得期待！

如今，咱们来和QT mobile作一个对比：

• 生态：从Github上来看，目前Flutter活跃用户正在高速增加。从Stackoverflow上提问来看，Flutter社区如今已经很庞大。Flutter的文档、资源也愈来愈丰富，开发过程当中遇到的不少问题均可以在Stackoverflow或其github issue中找到答案。
• 技术支持：如今Google正在大力推广Flutter，Flutter的做者中不少人都是来自Chromium团队，而且github上活跃度很高。另外一个角度，从今年上半年Flutter频繁的版本发布也能够看出Google对Flutter的投入的资源不小，因此在官方技术支持这方面，大可没必要担忧
• 开发效率：Flutter的热重载可帮助开发者快速地进行测试、构建UI、添加功能并更快地修复错误。在iOS和Android模拟器或真机上能够实现毫秒级热重载，而且不会丢失状态。这真的很棒，相信我，若是你是一名原生开发者，体验了Flutter开发流后，极可能就不想从新回去作原生了，毕竟不多有人不吐槽原生开发的编译速度。

自绘UI+原生的优缺点

绘UI+原生。这种技术的思路是，经过在不一样平台实现一个统一接口的渲染引擎来绘制UI，而不依赖系统原生控件，因此能够作到不一样平台UI的一致性。注意，自绘引擎解决的是UI的跨平台问题，若是涉及其它系统能力调用，依然要涉及原生开发。这种平台技术

优势：

• 性能高；因为自绘引擎是直接调用系统API来绘制UI，因此性能和原生控件接近。
• 灵活、组件库易维护、UI外观保真度和一致性高；因为UI渲染不依赖原生控件，也就不须要根据不一样平台的控件单独维护一套组件库，因此代码容易维护。因为组件库是同一套代码、同一个渲染引擎，因此在不一样平台，组件显示外观能够作到高保真和高一致性；另外，因为不依赖原生控件，也就不会受原生布局系统的限制，这样布局系统会很是灵活。

不足：

• 动态性不足；为了保证UI绘制性能，自绘UI系统通常都会采用AOT模式编译其发布包，因此应用发布后，不能像Hybrid和RN那些使用JavaScript（JIT）做为开发语言的框架那样动态下发代码。

对比