Flutter入门初步2019-11-22

前端的特点

1. 复杂多样，有各种各样的端。常见的有以下几种：

• 移动-iOS
• 移动-Android
• 移动-Web，PC-Web
• 嵌入设备

移动Win Phone已经边缘化了；PC-Client，（即桌面应用），目前主要是开发工具和游戏；TV和watch都可以归结到嵌入式设备那一类。

2. Flutter的野心：

image.png

Flutter 成为多平台框架，支持移动、Web、桌面和嵌入式设备
Flutter全平台制霸！新增Web和嵌入式目标平台

• 一开始，Flutter的目标是统一iOS和Android开发，Flutter1.0就已经实现了。

• Flutter1.5开始了Flutter For Web，在Flutter 1.9的时候将这个web分支和入了主干，Flutter 1.12 实现Beta版web支持，实现了iOS，Android，web三端统一。
  Flutter1.9升级体验总结（帮大家填坑了）
  Flutter 1.12 正式发布，为这一年画上圆满的句号！
  Flutter Web Beta版本终于发布了

跨平台发展历程

面对前端的多样性，跨平台方案一直是追求。一套代码，只写一遍，在所有端上运行。

1. WebView

• 标志性事件是Facebook将自己的应用采用WebView实现
• iOS和Android两端实现了统一
• 性能问题导致体验下降，Facebook后来又改成了iOS和Android的原生应用。
• 折中的Hybrid方案成为主流。主体采用原生开发，动态内容，（比如公告，促销活动），采用H5实现。

5G之后，如果网速够快，流量基本不要钱，这个方案的短板就没了，感觉很有前景啊。

小结：编码效率：高；动态更新：好；双端一致：好；性能：差

2. React Native & Weex

• Facebook推出的，有了上一次的教训，这次很低调，自己内部也很少使用。不过，这个无心插柳，后来却获得了极大的关注和发展。

• 原生实现，JS调用，极大地提升了性能，又保留了web的热更新特性。思路比较有创意，获得了很大的认同。

• 一开始在Facebook内部并不受重视，用起来也不方便。在集成时，对小公司并不友好，现实中就遇到好几个使用失败的例子。

• 蚂蚁金服是使用React Native比较好的公司，并且还封装了一套组件ADT（ant design tool），用起来比较方便。

• 因为React Native使用不方便，所以阿里进行了二次开发，推出了Weex

• Weex使用相对简单，现实中已经遇到好几个使用成功的例子。

• 类前端语法，有点四不像的感觉，程序员的编码体验并不好。纯前端的来写，有点别扭；iOS或者Android开发者学点前端知识，然后来写，反而更好。并且，遇到缺少的组件，自己顺手就实现一个。 ==》这是一种很奇怪的编程体验。

小结：编码效率：前低后高，看组件的完备状态；动态更新：较好；双端一致：差；性能：较好

3. 小程序

PC上，BS架构替代了CS架构，Web成为了主流，IE或者Chrome等浏览器成为了PC上最重要的工具。但是，和曾今很多人预测的相反，相同的事情在移动端并没有重现。现在，很多人手机上最重要的应用是微信和支付宝，而不是Safari和Chrome浏览器。

• 既然如此，那么微信和支付宝是不是可以替换浏览器，承当“容器”的作用？

• 在手机上，输入url真是太麻烦了，那么用扫描二维码的方式替代，不是方便了？（所谓的所见即所得）。不用记网址，不用输入字符，真是太方便了。

• React Native很不好用，所以，在VS Code的基础上二次开发，提供了一个IDE，打开就能用，不要说公司，就是个人学习，也能很快上手。

• PC-Web上低质量的内容和广告很多，很烦人。那么就学苹果，也来个“应用审核”。

• 微信先出，支付宝一年之后再出来，并且从行为上来看，“几乎是照抄”。现在据说出来了工具，一套代码，两个平台的小程序都能运行。

这种老大老二秘而不宣合作的行径，使得老三，快应用，发展严重受限。

• 对小公司和个人开发者来说，小程序还是非常友好的。平台兼容性让微信和支付宝去考虑，使用者只要专注业务就好了。这是一个共生共荣的关系。

• 小程序没有提供新技术，底层仍然是React Native或者WebView，但是却成功地创造了一个充满活力的生态圈。

小结：编码效率：高；动态更新：好；双端一致：好；性能：好。在巨人肩膀上的改良，很好的解决方案。

4. Flutter

• 可以简单的理解为“画界面”。不使用JS过渡，不使用原生控件，比如按钮，输入框等，而是直接调用画图API，将界面的样子，“画出来”。从这个实现原理上来说，应该有接近原生的性能体验。

理论上，Flutter应该比ReactNative更快；不过，实际上，由于发展成熟度等客观原因，两者目前在性能表现上差别不大。

• IDE: Android Studio， VS Code都可以，增加相应的插件就可以，使用门槛很低。

• Dart语言：编程语言的背后更重要的是编程范式。C语言是结构化编程的代表。Object-C和Java是面向对象的主流语言。而很多现代编程语言，越来越多地加入了函数式编程的特性。为什么iOS要转向Swift, Android要转向kotlin？函数式编程的特性带来很多方便，应该是其中一个原因之一。而JS很有特色，随着web的发展，在不断进化。一开始只是浏览器脚本，属于结构化编程；后来通过原型链，模拟出对象，编程了面向对象；ES6又加入了很多函数式编程的特性，成了现代编程预言的一员。Dart主要是面向对象的，也有函数式的特性，使用起来非常方便。体验过的大多数人认为，Flutter采用Dart语言是一项加分项。

• Flutter应用采用Dart语言来编写，并没有替代实际的平台做具体的事，更多的是一种描述，一份配置。比如，一个按钮，描述清楚它的大小，颜色，是否有边框等特性就可以了，具体怎么实现这个按钮，交给具体平台就可以了。应该说，这是一种非常聪明的做法，相对于编程语言的转码，这就避开了各种平台的实现细节。

*曾经用Android Studio写过一个Hello World，运行在iOS模拟器上，从调试工具栏看到了“xcode building ....”。这个可以合理地推断，我们用Dart写的Hello World程序，经过Flutter的转换之后，变成了XCode能够处理的内容（Object-C或者Swift），然后编译运行。

• 最近合入主干的Flutter-web，据说也是转成html/css/js，然后在浏览器上运行的。

• 界面和代码分开还是合并？web分为html/css/js三部分，iOS分为xib和代码两部分，Android分为xml和代码两部分。但是Flutter的Dart，只有代码，并没有代表界面的内容。这样带来的好处是，不需要争论和犹豫，大家统一用纯代码。当然，带来的批评就是，界面和逻辑嵌套严重，看着很累很复杂。这一点，应该是褒贬不一。

image.png

• Flutter提供了很多好用的组件，能够做到iOS和Android等不同平台上的UI一致，并且比较繁琐的机型设配问题，也交给Flutter框架负责，能省很多事。

小结：编码效率：高；动态更新：有这个能力，但由于苹果审核政策，此功能不开放；双端一致：好，Material风格很不错；性能：理论上跟原生性能接近，很好。目前来说Flutter是很有吸引力的跨平台（大前端）解决方案。

Flutter:移动端跨平台技术演进之路
跨平台技术演进及Flutter未来

Flutter安装

• 从GitHub上下载源码，开源的，这个让人很安心。

• 打开终端，通过命令行安装一下。基本上是一键搞定。

• 由于“墙”的原因，需要更换一下源的网址，这个稍微有点麻烦，不过文档还是挺完备的。

• 配置一下命令行路径，不然的话，每次打开终端，都要切换到Flutter的目录再用命令行，有点麻烦。

• 升级更新，环境检查等都通过命令行来完成，通过IDE也是可以的，比较方便。

• 实际的操作过程：Flutter在MAC安装实践

Flutter路由

• 基本路由和原生的差不过，名字也叫push和pop；用起来也方便，也能传值。不过，问题也一样，耦合过重。需要先加载下一个页面，然后再跳转。

• 命名路由很不错。先定义一个全局的路由表，然后就可以通过字符串进行页面跳转，跟Web中的url有点类似。好处是实现了页面之间的解耦，但是缺点是不能传递数据。

• 动态路由：这个要自己定义，用起来像命名路由，通过字符串进行页面跳转，实现页面之间的解耦，同时能够传递参数。

• 吐槽：命名路由其实非常好用，为什么要留下不能传递参数这么一个缺陷？

• 相同的功能，在iOS上要借助runtime实现，或者采用第三方库来做，不是很方便。这方面，Flutter整体还是做得不错的。

• 一些不常见的跳转，比如“关闭当前页面，跳转下一页”，iOS没有现成的API支持，Flutter是有的，这点也很好。

• 实际操作：Flutter路由实践

Flutter界面

• 推荐学习网站：Flutter实战电子书

• 实际操作：Flutter UI组件 将其中UI相关的例子整理了一下，能跑起来，看到效果。

• 默认工程不是传统的“Hello World”，而是一个计数器。

image.png

• 采用Android Studio写Dart代码，然后用iOS模拟器看效果。页面有小改动，热加载一下就可以看到改动效果。这些开发体验还是很不错的。

• 一切都是Widget，看得见的比如Button，文字，开关，进度条等等，是Widget；看不见的，比如手势，布局，事件侦听等等，也是Widget

• Widget不是具体的页面组件，而是一种配置。Flutter是“画界面”，Widget就是配置“如何画”。所以，Widget一旦确定，就是不可变的。这个和原生的组件，比如iOS开关组件，带状态变化，是本质不同的。

• Widget分为“无状态”和“有状态”两种类型。“有状态”是通过一个额外的对象State来完成的。改变状态的方式和React的差不多，也叫setState()。状态改变的时候，可以理解为将“页面擦了重绘”

• 在布局上，引入了Web上的Flex弹性盒子的概念，并且引申出Row，Column等布局方式，比较方便。

• 图片，作为一种资源进行管理和加载。要在配置文件中指明路径。相对iOS原生来说，相对要麻烦一点，不过还算可以接受。

• icon图标，内置了相关资源，只要一行函数调用就可以了，非常方便。而在原生的iOS开发中，这些图标都是png图片。比如，“点赞”图标。

IconButton(
  icon: Icon(Icons.thumb_up),
  onPressed: () {},
)

image.png

Flutter动画

• 有一些现成的动画组件，只要设置时长，对应变化的属性值就可以了，比较方便。比如改变位置，透明度，文字样式等

• 页面之间的，过渡动画，在命名路由push中定义，比iOS原生的实现方式要方便。

• 自定义动画，要控制器，运动轨迹，动画时长等对象来定义，相对iOS原生实现来说要麻烦一点。

• 实际操作：Flutter 动画

网络

• 网络访问一般是异步的，可以使用await/async来做，书写形式变成了同步的，很方便。

• 可以用try ... catch ... finally结构来捕捉异常，增加安全性

• 提供HTTPClient对象，来处理网络访问。

• Demo地址

其他

• 包管理，插件开发
• 如何手动接入现有的第三方库，比如密码控件，百度OCR等
• 数据共享
• toast提示
• flutter-web
• ... ...

参考网站

Flutter中文网
掘金Flutter
Flutter实战电子书