小编默认你已经是开发者，并对Flutter有基本的了解，但是还未深入使用，希望了解Flutter在商业级（而非demo）的项目中的优势与劣势。
近期在公司做一个项目，很多公司有做的事情。android ios 手机H5 pch5通通向上封装一层，通过接口下发数据生成页面（写的是真的累，加班加死我了，文字颜色，位置，大小，背景颜色，图片圆角等等，通通通过接口下发，累）。今天我们就谈一下flutter 2019的发展方向。
很多前端开发者应该都寻找过跨平台的App解决方案，包括没有同时独立开发iOS和Android双端原生app的开发者，应该都接触过或者看到过Google的Flutter框架。我对于iOS原生开发与基于Vue.js的web开发比较熟悉，并在一个正在进行的蓝牙硬件项目中应用了Flutter框架，经历的漫长的适应，在本文中我将以iOS原生开发者与web开发者的视角看待Flutter框架，简单罗列Flutter的优势与缺点。
Flutter优点
Flutter的优点非常明显，如果你选择一个跨平台框架，与众多基于html的跨平台框架相比，Flutter绝对是体验最好，性能与构建思路几乎最接近原生开发的框架。
性能强大，流畅
Flutter对比weex和react native相比，性能的强大是有目共睹的。基于dom树渲染原生组件，很难与直接在原生视图上绘图比肩性能，Google作为一个轮子大厂，直接在两个平台上重写了各自的UIKit，对接到平台底层，减少UI层的多层转换，UI性能可以比肩原生，这个优势在滑动和播放动画时尤为明显。
路由设计优秀
Flutter的路由传值非常方便，push一个路由，会返回一个Future对象（也就是Promise对象），使用await或者.then就可以在目标路由pop，回到当前页面时收到返回值。这个反向传值的设计基本是甩了微信小程序一条街了。弹出dialog等一些操作也是使用的路由方法，几乎不用担心出现传值困难
单例模式
Flutter支持单例模式，单例模式的实现也非常简单。单例模式很好的解决了一些问题。相比之下，js的单例则并不是一个真正的单例，或者说不是一个简单的单例，这也是受限于js所运行的环境。单例模式并不总是合理的，容易被滥用。但是在App的初期开发中，往往一个容易实现的单例可以帮助我们快速完成一些逻辑的搭建。
优秀的动画设计
Flutter的动画简单到不可思议，动画对象会根据屏幕刷新率每秒产生很多个（一般是60个）浮点数，只需要将一个组件属性通过补间（Tween）关联到动画对象上，Flutter会确保在每一帧渲染正确的组件，从而形成连贯的动画。这种十分暴力的操作在Flutter上却看不到明显的卡顿，这也是Flutter的一个魔力所在。相比之下其他跨平台框架几乎不能设计动画……往往会遭遇非常严重的性能问题。
UI跨平台稳定
Google直接在两个平台上在底层重写了UIKit，不依赖于Css等外部解释器，几乎不存在UI表达不理想，渲染不正常的情况，可以获得非常稳定的UI表达效果。Css换个浏览器就有不同的表现，基于Css的跨平台框架很难获得稳定的UI表现。
可选静态的语言，语言特性优秀
Dart是一个静态语言，这也是相对于js的一个优势。Dart可以被编译成js，但是看起来更像java。静态语言可以避免错误，获得更多的编辑器提示词，极大的增加可维护性。很多js库也已经用ts重写了，Vue3.0的底层也将全部使用ts编写，静态语言的优势不言而喻。
Flutter缺点
假装跨平台，躲不开原生代码
这是最大的问题，跨平台框架说白了就是UI跨平台，最后还是在原生平台运行，本来两个平台就有天壤之别，一套代码就想吃掉iOS和Android在实际应用之中其实根本就不现实。Flutter具有与原生代码互相调用的能力固然非常科学，但是问题反而显得更加明显——我一个前端工程师上哪里去知道什么是UIViewController，什么是Activity呢？我要是双端都熟悉，学习Flutter就显得很没有必要。这是一个很矛盾的点，特别是在团队里，只有几个前端突然想学Flutter，是绝对做不来大项目的，如果有原生开发者，那就没必要搞Flutter了。
组合而不是继承的思路
Flutter提倡“组合”，而不是“继承”。在iOS开发中，我们经常会继承UIView，重写UIView的某个生命周期函数，再添加一些方法和属性，来完成一个自定义的View。但是在Flutter中这些都是不可能的——属性都是final的，例如你继承了了一个Container，你是不能在它的生命周期中修改他的属性的。你始终需要嵌套组合几种Widget，例如Row，Container，ListView等Widget。这种方法非常不符合直觉，初学时很难想明白如何构建一个完整的组件。
Widget的类型难以选择
Flutter的Widget分为StatefulWidget和StatelessWidget两种，一种是带状态的一种是不带状态的，刚开发的时候很难想明白用哪个，因为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的硬实力.
因为Flutter的出现在一定程度上能解决掉以前困扰web前端开发程序员的很多难题，这些对于前端程序员真的是一大福利，但是也有不少前端开发者担心随之而来的更新兼容问题甚至前端开发者就业问题，担心这是一个灾难。关于Flutter的现状和未来，你有什么看法？欢迎下方留言和大家讨论！
爱前端-专注全栈大前端
爱前端—只专注全栈大前端技术培训，注重于企业实战型人才培养，帮助更多的零基础学员和在职前端开发人员真正掌握企业实际开发经验技术。
关注公众号【爱前端】，获取课程大纲介绍及优惠名额，领取【内部资料+试听】！
全栈大前端技术交流群：137503198，学习规划、学习路线、学习资料、问题解答，学前端，你想要的，在这都能找的到。
网友评论