浅谈flutter

1,557 阅读9分钟

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)作为开发语言的框架那样动态下发代码。

对比