一项改变游戏规则的技术 - Flutter

''A fast app is great, but a smooth app is even better.''
使用Flutter beta版上线了一个APP的故事
2018年的11月底，我第一次打开Flutter的官网，想看看Flutter到底是什么；3个星期后，我们赶在Apple的App Store审核团队圣诞节休假前，提交了第一个使用Flutter开发的App 。当然，是iOS和Android双端同时提交。
我们使用Flutter开发的产品是一个图片feed流，作为一个模块嵌入到一个美颜相机里面。
在接下来的2个月内，我们保持着每2个星期发版的频率，成功上线了以下核心功能：

登陆
作品发布
作品删除
关注他人
作品点赞
作品评论
消息中心
发现feed流
关注feed流（你所关注的发布者的动态feed流）
各个页面时长的数据统计

再来看看我们整个Feed流团队有多少人：

产品经理：1人
作品质量把控：1人
后端开发：2人
iOS开发：1人
Android开发：2人
Web端开发：2人
测试：2人

以上是第一个版本发布后的团队组成。其实，我们的第一个版本期间，开发只有4人（后端， iOS ， Android ， Web ，各1人）。
在使用Flutter的这几个月内，我被Flutter这特立独行的跨端思想和优秀的表现所感动。从一开始的全身每个细胞都在抵触到短短几个星期之后就差点成为脑残粉，我经历了难忘的一次“真香”之旅。
思绪回到我们决定使用Flutter的那一天，我们做了一个冷静之后看起来十分激进和冒险的技术选型。因为我们当时的场景是：Flutter beta版 + 和已有的native APP混合 + 已有的native是一个相机类App + Flutter开发的功能是一个feed流。这个组合在当时的场景下是十分苛刻的。接下来我具体解释一下其中的挑战在哪里：

Flutter beta：因为是beta版本，所以框架功能不面面俱到，也存在bug 。
Flutter和已有的native混合：因为当时使用的是beta版本，并没有官方的集成方案。混合模式下如何开发，调试，打包，集成之后对整个App包大小的影响有多大，都是挑战。
已有的native是一个相机类App：相机类的App本身占用的内存就相对来说很大。
feed流：feed流功能，本身对性能要求高，因为刷起来需要流畅，因为图片很多，对内存也是有极高的要求。
上线时间短：第一个版本，必须要赶在圣诞节前上，从项目立项到上线，不过3个星期的时间。
上线频率高：保持每2周发一个新版。

但是，上面的这些挑战， Flutter都很好地消化了。基于我个人的开发体验来讲，是因为Flutter具备以下优点：

高性能：我们的核心是feed流，对于一个feed流来说，滑起来流畅是重要的指标。因为Flutter的高性能的特性，我们的feeds能达到60fps 。
双端一致：因为我们的功能是iOS和Android双端都要支持，因为Flutter优秀的跨端技术，使得我们写一份代码，可以同时在双端运行，并且保持双端UI,功能等高度的一致性。
减少测试时间：因为双端的高度一致，测试同学不需要每一端都事无巨细地测试，特别是UI的部分，只需要测试一端便行。
高效的开发效率：Flutter提供丰富又高度定制化的组件，加上Flutter拥有Hot Reload ，使得你在秒级的时间内看到你的代码更改，而不是像以前那样哪怕只是1px的改动，都需要经历重新的编译，打包，安装，可能2分钟过去之后，才能看到最后的结果。

看到这里的同学，脑子里面可能一直萦绕着一个问号：你一直在说的Flutter到底是什么？