【开发经验】浅谈flutter的优势与缺点

本文默认你已是开发者,并对 Flutter有基本的了解,可是还未深刻使用,但愿了解 Flutter在商业级(而非demo)的项目中的优点与劣势。

不少前端开发者应该都寻找过跨平台的App解决方案,包括没有同时独立开发iOSAndroid双端原生app的开发者,应该都接触过或者看到过Google的Flutter框架。我对于iOS原生开发与基于Vue.js的web开发比较熟悉,并在一个正在进行的蓝牙硬件项目中应用了Flutter框架,经历的漫长的适应,在本文中我将以iOS原生开发者与web开发者的视角看待Flutter框架,简单罗列Flutter的优点与缺点。html

Flutter优势

Flutter的优势很是明显,若是你选择一个跨平台框架,与众多基于html的跨平台框架相比,Flutter绝对是体验最好,性能与构建思路几乎最接近原生开发的框架。前端

  • 性能强大,流畅

Flutter对比weexreact native相比,性能的强大是有目共睹的。基于dom树渲染原生组件,很难与直接在原生视图上绘图比肩性能,Google做为一个轮子大厂,直接在两个平台上重写了各自的UIKit,对接到平台底层,减小UI层的多层转换,UI性能能够比肩原生,这个优点在滑动播放动画时尤其明显。java

  • 路由设计优秀

Flutter的路由传值很是方便,push一个路由,会返回一个Future对象(也就是Promise对象),使用await或者.then就能够在目标路由pop,回到当前页面时收到返回值。这个反向传值的设计基本是甩了微信小程序一条街了。弹出dialog等一些操做也是使用的路由方法,几乎不用担忧出现传值困难node

  • 单例模式

Flutter支持单例模式,单例模式的实现也很是简单。单例模式很好的解决了一些问题。相比之下,js的单例则并非一个真正的单例,或者说不是一个简单的单例,这也是受限于js所运行的环境。单例模式并不老是合理的,容易被滥用。可是在App的初期开发中,每每一个容易实现的单例能够帮助咱们快速完成一些逻辑的搭建。react

  • 优秀的动画设计

Flutter的动画简单到难以想象,动画对象会根据屏幕刷新率每秒产生不少个(通常是60个)浮点数,只须要将一个组件属性经过补间(Tween)关联到动画对象上,Flutter会确保在每一帧渲染正确的组件,从而造成连贯的动画。这种十分暴力的操做在Flutter上却看不到明显的卡顿,这也是Flutter的一个魔力所在。相比之下其余跨平台框架几乎不能设计动画……每每会遭遇很是严重的性能问题。web

  • UI跨平台稳定

Google直接在两个平台上在底层重写了UIKit,不依赖于Css等外部解释器,几乎不存在UI表达不理想,渲染不正常的状况,能够得到很是稳定的UI表达效果。Css换个浏览器就有不一样的表现,基于Css的跨平台框架很难得到稳定的UI表现。小程序

  • 可选静态的语言,语言特性优秀

Dart是一个静态语言,这也是相对于js的一个优点。Dart能够被编译成js,可是看起来更像java。静态语言能够避免错误,得到更多的编辑器提示词,极大的增长可维护性。不少js库也已经用ts重写了,Vue3.0的底层也将所有使用ts编写,静态语言的优点不言而喻。segmentfault

Flutter缺点

  • 伪装跨平台,躲不开原生代码

这是最大的问题,跨平台框架说白了就是UI跨平台,最后仍是在原平生台运行,原本两个平台就有天壤之别,一套代码就想吃掉iOS和Android在实际应用之中其实根本就不现实。Flutter具备与原生代码互相调用的能力当然很是科学,可是问题反而显得更加明显——我一个前端工程师上哪里去知道什么是UIViewController,什么是Activity呢?我要是双端都熟悉,学习Flutter就显得很没有必要。这是一个很矛盾的点,特别是在团队里,只有几个前端忽然想学Flutter,是绝对作不来大项目的,若是有原生开发者,那就不必搞Flutter了。微信小程序

  • 组合而不是继承的思路

Flutter提倡“组合”,而不是“继承”。在iOS开发中,咱们常常会继承UIView,重写UIView的某个生命周期函数,再添加一些方法和属性,来完成一个自定义的View。可是在Flutter中这些都是不可能的——属性都是final的,例如你继承了了一个Container,你是不能在它的生命周期中修改他的属性的。你始终须要嵌套组合几种Widget,例如RowContainerListViewWidget。这种方法很是不符合直觉,初学时很难想明白如何构建一个完整的组件。浏览器

  • Widget的类型难以选择

FlutterWidget分为StatefulWidgetStatelessWidget两种,一种是带状态的一种是不带状态的,刚开发的时候很难想明白用哪一个,由于StatelessWidget也能存值,其实区别就在于框架重构UI的时候会使用State来重构,若是是StatelessWidget,暂时存进去的值就没了。可是问题远不止这么简单,好在只是有点麻烦,并不影响产品性能。

  • 糟糕的UI控件API

虽然google尽量的让咱们经过构造函数定制化Widget,可是也不免有遗漏的。例如,又一次我想修改一个Appbar的高度,竟然没有找到关于高度的属性,经过阅读源码发现,高度是写死(const)的。上文已经说过,没法经过生命周期来改变组件属性,本身写Appbar显得很是不必,毕竟我仍是想使用Appbar的各类方便的功能。最后我只能把他的源码所有复制出来,直接修改高度来使用。初学框架,和一些初级开发者是不可能有迅速阅读源码的能力的(做为框架也不该该产生如此问题)。一些定制化的UI的Api设计常常有缺失,好在我已经基本习惯了。除了Appbar这种复杂的组件,本身写一个小组件也并不费事。

  • 糟糕的资源管理设计(已解决)

这里是最蠢的,Flutter支持动态加载不一样分辨率的图片,可是目录设计太鬼畜了。简单的说,Sketch导出的多分辨率资源,几乎不可能直接拖到Flutter里用,极其,极其,麻烦。

为了解决这个问题我编写了一个node脚本工具 fmaker,用来管理多分辨率资源,顺便生成app图标:
使用帮助/仓库地址: 【Flutter工具】fmaker:自动生成倍率切图/自动更换App图标

毕竟国情在此,要用Flutter,先买梯子。虽然有“在中国使用Flutter”指南,可是太麻烦,没梯子开发Flutter,难度系数过高了,总不能碰到每一个问题都花一成天寻找替代方案吧,先买好梯子图个安心……

总结

Flutter主要的坑就在于须要很是了解原生的环境,其实跨平台的框架都是如此,想要经过跨平台的API就拿下双端的开发任务,对认真学习的原生开发者来讲也是不公平的。
主要的优点则在于动画流畅,不少开发者反应比原生安卓还流畅(存疑),至少在iOS上是看不到卡顿的,安卓上动画也很稳定,性能上展现了Google的硬实力

本人是iOS原生开发者,亦熟悉 Vue.js,小程序等前端开发,对 Android开发与 Reactive Naive不甚了解,本文乃是一些初级经验与感悟,如有不当还请评论指正。

本文禁止任何形式转载。