『CSDN』不用掉一根头发!用 Flutter + Dart 快速构建一款绝美移动 App


『CSDN』不用掉一根头发!用 Flutter + Dart 快速构建一款绝美移动 App
本文插图
如今这个时代 , 与前端或移动相关的新框架层出不穷 。 所有从事Web开发的人都应该熟悉各种目不暇接的新方法以及针对复杂问题的轻量级解决方案 。 我们不再因为没有现成的技术而烦恼 , 相反我们常常因为不知道该选哪种技术而感到头疼 。
最近 , 我偶然间发现了Flutter , 于是兴致勃勃地决心一试 , 看看这种技术是否能够成为强有力的竞争对手 , 或者甚至作为一种解决方案 , 让我在进退两难的困境中看到新的希望 。
Flutter简介
Flutter是Google出品的移动应用UI SDK 。 它使用了Dart VM(也是Google出品 , 专门针对UI进行了优化) , 帮助我们开发移动设备和台式设备 。 Dart本身也可用于Web开发 , 甚至可以与我们非常熟悉的Angular框架配合使用 。
Flutter可以通过AoT(提前)编译方式编译成原生机器代码 , 目的是让应用的运行速度达到最高 , 同时又不会产生太多开销 。
对于开发人员 , Flutter提供了JIT(即时)编译器和热重载功能 , 我们能够在不丢失现有状态的情况下修改应用程序 , 这点非常实用 , 因为在复杂的功能中修改一个隐藏得很深的UI非常麻烦 , 所有曾经从事UI工作的人都清楚每次都要千辛万苦才能找到要修改的UI 。
当然 , SDK重要的部分是控制库 。 由于Flutter的定位是Android和iOS开发 , 因此我们可以选择使用Material(Google Android)或Cupertino(Apple iOS)控件集 。 这是否意味着当应用程序部署到Android或iOS手机上时会切换外观 , 让两者看起来都很像是原生的?并非如此 。 你可以随便使用哪个库 , 也可以同时使用两者 , 但是并没有统一的切换UI的功能 。 当然 , 你可以手动实现 , 我并不是说不建议这种做法 。 但请记住这种功能需要管理两组不同的布局控件 , 很快就会乱成一锅粥 , 因此应当谨慎地采用这种方法 。
在默认情况下 , Flutter中的所有内容都是小部件(widget) 。 如果你有使用Angular 2+的经验 , 那么可以认为wdiget就是更强大的组件 , 而且应该是一个非常熟悉的概念 。 在默认情况下 , 这种基本类型包含一个定义外观的build方法 , 而且还可以根据传递的参数和上下文自定义外观 。 小部件可以是无状态的也可以是有状态的 。 无状态小部件大部分都是静态的 , 不会在生命周期中发生任何明显的变化 。 另一方面 , 有状态的小部件在每次触发时都会被构建(例如 , 当监视的变量发生变化、用户执行单击等特定的操作) 。
Flutter是响应式编程(类似于React) , 这意味着没有默认的持续刷新循环(像Angular那样) 。 取而代之的是 , 一旦执行了关键操作 , UI或其一部分(比如其中一个小部件)就会根据状态的变化重新绘制 。
我曾提过 , Dart为处理UI进行了大幅优化以 , 但这意味着什么?在Flutter中 , 经过优化后的Dart支持丰富的集合处理、基于隔离的并发以及future的async-await 。 基本上这种SDK面向的应用程序都是构建业务 , 而不是游戏 。 尽管我们不能假设人们不会尝试使用Flutter制作游戏 , 甚至现在已经出现了2D游戏引擎 。 但我想说的是 , 这种应用程序的模式似乎非常适合这组特定的功能 , 而这也是我决定探索的角度 。
风险
尽管上述一切听起来很美好 , 但也有一些弊端 。
首先 , Flutter仍然是一个处于起步阶段的SDK 。 虽然从它的年龄上来看属于正常 , 但应该注意的是 , alpha版于2017年5月发布 , 而1.0版本到于2018年12月才发布 。 这意味着在撰写本文之际 , Flutter仅有一年的历史 。 这有什么后果?Flutter的社区虽然已具规模 , 但仍不能与当前的主流技术相提并论 。 这会影响我们寻找一些常见问题的解决方案 , 而且可能会经历多次失败 , 需要付出额外的努力 , 并仔细阅读规范 。 但是 , Flutter的文档很健全 , 并且社区在不断发展 , 因此我们可以认为Flutter在发展中 , 没有明显的缺陷 。


推荐阅读