flutter 实践
数加产品线完整的闭环有一个面向用户的 APP 端，由于公司没有 native app 开发，所以选用了跨平台技术开发，任务也自然交给了前端。
技术选型
由于大家都没有 APP 开发的经验，技术选型显得尤为重要。本着用新不用旧的原则，技术团队对 flutter 这个极其新的东西产生了浓厚的兴趣。经过一系列调研，对比 react native，以下便是差异之处。
| 基础特性 | RN | flutter |
|---|---|---|
| 语言 | JS | Dart |
| 渲染机制 | 通过 JS 代码调用原生 UI 渲染界面，效率要慢一些，UI 统一性也并不能做到完全统一，只能牺牲部分设计 | 框架自带 UI 体系，直接与更底层的 skia 交互，理论上效率要更高，并且能保证在不同平台上的一致表现 |
| 生态 | 有大量的开源组件以及成熟的解决办法 | 刚开始兴起，有一些高质量的开源组件，但数量不多 |
| 上手难度 | 简单 | 对于前端工程师需要另学一门语言，布局方式也和 CSS 截然不同，上手偏难 |
通过上述分析可以得知 flutter 作为一个新兴框架，其底层机制比 RN 更为优秀，但是由于处于起步阶段，生态上来说是比不上 RN 的，再次本着程序员对未知事物充满好奇的心，大家一致选择 flutter。
项目搭建
有对新事物的热情就必然要有采坑的准备，搭建项目时问题就层出不穷，iOS 端 cocoapods 下了一天都没下下来，最终解决办法竟然是多试几次 … 接下来使用安卓模拟器控制台报错不断，原因是不能使用最新的安卓 Q 版本，原来 flutter 在 GitHub 上几千个 issue 是有道理的。虽然困难重重，但是花了一周时间终于把项目建好了，谷歌还是给了开发者一条活路。
编码体验
在通读了一遍 Dart 文档加上 flutter 教程的基础上，本以为按照知乎大神们俩小时上手开发的速度应该可以马上高效的进行编码了，然而对着 UI 设计图，脑子空空如也，完全不知道该如何下手，无奈的又边翻阅文档边看技术博客一点一点把页面磊出来了，开始的开发速度简直不忍直视。
- 首先的难点在于 flutter 整个的布局规则已经大改了，需要理解很多新的概念，溢出，堆叠，边界约束全部都和 CSS 不一样。就拿溢出举例，CSS 溢出是自然溢出，父元素样式决定子元素溢出表现，到 flutter 那是直接报错！是的，你没看错，完全不允许溢出，要先考虑内容是否过长来使用不一样的盒子。更别说还有一堆的概念比如长宽自动伸缩方式，对齐方式，堆叠情况下占满宽度的盒子等等，现在想起来都是一头的包。
- 还有一个比较典型的就是 flutter 也是组件化理念，状态控制视图，但是组件之间通过类来进行蹩脚的通信实在是感觉麻烦，远没有 react 或者 Vue 简单直观。
- 各种基础 widget 的设计纷繁杂乱，有的使用难度极高，到现在我还不明白 ListView 的 builder 模式是怎么工作的。
打包部署
本以为在构建项目时遇到的问题在部署时应该会重现，但实际打包过程出奇的流畅，只有在打 IOS 包的时候由于其平台的安全性而显得有点步骤冗长之外，基本没有别的问题，成功的能在双端真机上运行 release 包，项目开发到最后也是终于松了口气。
flutter 的优点
虽然对于前端程序员来说编码体验很糟糕，但是不得不说这个糟糕体验是在快速上手的前提下，深入理解加上大量的代码经验我相信同样能让 flutter 工程师高效的进行开发。flutter 也有很多不可否认的闪光点的，在 release 环境下，速度和流畅度都有着非常优良的体验，并且整个项目做下来，几乎没有遇到过双端 UI 表现不一致的情况，谷歌这个承诺是达到了，不用为平台做特殊兼容对于之前受 IE 荼毒的前端工程师来说无疑是幸福愉悦的。
以上就是 flutter 开发的实践体验，总得来说 flutter 是一个优秀的框架，性能以及 UI 表现值得肯定，但是还是希望谷歌能够多照顾照顾开发者，大家时间都很宝贵，对于一个框架来说易用性也是一个很重要的因素。