在这篇文章中,我将分享我使用Flutter的经验,以及我在整个过程中发现的所有Flutter的优缺点。
在过去的一年里,我是如何使用Flutter的呢?我做了以下这些事情:
使用Flutter重写一款已经发布到App Store的iOS应用程序。
开发了一个Flutter免费速成课程,录制5个多小时的教学视频内容。
使用Flutter开发一些小型尚未发布的应用程序。
以下是在过去一年中,我通过使用Flutter学到的东西。
与TypeScript或Flow相比,Dart更容易学,语法也更简单。我能够快速地进行开发,因为编译器提供了明确的错误消息,具有更少隐藏的非预期运行时错误。在开发中型应用程序时,开发人员应该拥抱强类型语言,因为它在加快开发速度和编写可靠代码方面起到很大作用。
在采用新技术时,有时候需要“推出自己的”库,以便与第三方服务集成。例如,为了在我的应用程序中集成Mixpanel(因为它们提供了一个免费套餐选项和一个非常简单清晰的UI),我不得不开发我自己的库pure_mixpanel。这不是什么大不了的事情,实际上它很有趣。
我个人在使用scoped_model方面有很多成功的经验,它很好地抽象出需要使用流的地方,并且很像React的新Context API。你可以干净利落地将业务逻辑和渲染逻辑完美地分开,并且它非常容易学。
首先,Flutter是一项新技术,因此在实际应用、可信的架构模式和状态管理工具方面仍然有待发展。有些人会遵循“BLoC”(或“业务逻辑组件”)模式。在我看来,它有点太过复杂了,而且有些复杂性是不必要的。还有RxDart和Redux for Flutter,不过我还没有用过它们,因为它们看起来也过于复杂了。但是,Android或React开发者似乎有很多成功使用它们的经验,他们可能已经习惯使用它们了。
我认为整个生态系统在2019年会更加成熟,因为越来越多的人正在开发越来越复杂的Flutter应用程序。
关于这一点没什么好说的,只是Flutter的这个特性太重要了,所以有必要在这里单独提及。它更快,也更可靠了。
Material Design非常棒,对于某些类型的Web应用程序和Android应用程序来说,它都是一个明智的选择。但对于iOS用户来说并不是一个好主意,除非它是谷歌应用程序或非常简单的东西,iOS用户已经习惯使用CocoaTouch风格的UX。
在基于同一个代码库开发两个平台的应用程序时,越来越多的人使用某种定制的自定义设计,并引入了常见的设计元素(例如标签栏)。尽管Flutter也提供了大量iOS风格的小部件,但为了降低代码的维护成本,大多数人选择定制Flutter的Material Design库,这实现起来非常容易。
我想再写一篇有关这个主题的文章,我的建议是坚持使用Material Design,让那些iOS用户不会觉得太“像Android”了。例如表单,使用Material Design的样式来装扮表单字段,对两种类型的用户来说都足够熟悉。
我习惯使用React、CSS Grid、Flexbox等库来实现布局。Flutter的布局方式从这些工具中获取了很多灵感。如果你已经熟悉这些基于Web的布局概念,那么学习Flutter的布局就会非常简单。即使不熟悉,学起来也很容易。如果你想感受一下,可以看一下这个视频。
此外,Dart和Flutter的UI逻辑在代码可读性方面表现得都非常出色。总的来说,我更喜欢自己实现布局,而不是使用JSX之类的东西。它让我想起了Swift和iOS中的布局逻辑是多么的简单,如果你是通过编程的方式实现布局的话。
虽然现在有很多与Flutter相关的文档、教程、社区,但我认为人们对小部件的关注有点过头了。这点是可以理解的,毕竟Flutter还很年轻。但是,最终越来越多的人不仅用Flutter来实现纯粹的UI和动画,而且还会用来开发更多完整的应用程序。我认为,Flutter的网站上将会有更多端到端的示例教程。
我学会了使用Flutter开发整个应用程序,而不仅仅是小部件。我发现了很多非常有用的Dart高级功能。我提到的架构模式也是值得你去深究的。最后,与Web服务集成和其他Dart最佳实践仍然需要更多的文档和教程。
我总是希望能够减少样板代码的使用,虽然有一些工具可以帮我解决这个问题,但对于我的下一个项目,我将使用GraphQL或gRPC。我认为对这两项技术的投入都是值得的。至于gRPC,我不推荐将它用于较小的项目,但对于中型或大型项目,一旦你用了它,就很难再退回去了。gRPC在我的一个使用Swift开发的项目中非常有效,已经在生产环境中运行了好几年。
为每个平台提交应用程序所需的工具和步骤需要花一些时间来学习,特别是谷歌Play商店和iTunes Connect,但其实它们非常简单。
我之前学习了所有我认为必须学习的小部件,但最终只使用了大约20%。例如,Center小部件。为什么要单独使用一个小部件来让元素居中?虽然它让新手很容易上手,但在用它实现更复杂的布局时,会产生太多嵌套的Dart代码。相反,我会选择基本的Container布局,因为它们非常灵活。
我的建议是专注于基本的简单小部件,只有到了真正需要的时候才去了解更多的小部件。
Firebase看起来像是一款出色的产品,它让我想起了之前的Parse。对于简单的项目,或者在后续需要将项目移交给没有足够专业开发人员的客户来说,它似乎是一个不错的选择。
现实情况是,大多数公司都已经有自己的后端,还有一些技术团队选择自己开发后端。大型公司或初创公司倾向于这么做。
对于独立开发者,如果你的流量激增,能承受每月的Firebase账单吗?这实际上也是我避免使用Firebase的主要原因,因为如果我遇到了病毒传播式的“梦想问题”,并且Firebase根据使用情况收取费用,我将如何应对?
因为我是以开发后端系统为生,所以会存在这样的偏见。如果你是初级开发人员,你开发的后端到最后会移交给客户,或者你不开发后端API,那么我仍然会强烈建议你关注Firebase。
窗口小部件和类文档现在有越来越多的示例。相比其他缺乏文档的库,这是Flutter的一个胜利,而且更不用说编写良好的文档了。
除了文档之外,在去年的大部分时间里,Stack Overflow上有很多热情、知识渊博的人为我提供了帮助。
我从事iOS开发已经很多年了,所以我有点被iOS的开发者体验宠坏了。不只是文档和支持,还有iOS生态系统的整体质量,从库到Xcode,再到CocoaTouch SDK的组织方式。
Flutter也提供了类似的体验。它也非常简单,同时也借鉴了某些React Native组件的简单性,比如ListView。所以,整体来说,有了成熟的工具的配合,学习和使用Flutter会非常顺利。
视频游戏开发人员可能永远不会考虑单独为一个平台开发一个代码库。现在,因为React Native和Flutter的出现,“非视频游戏”开发人员也可以这么做。
例如,在空闲时间,我会与妻子(她是一名用户体验设计师)一起开发应用程序。将iOS应用程序转为Flutter后,我们的用户翻了一倍,现在它已经运行在两个平台上,所以无法再回到单平台上。
经过一年的折腾,当我开始开发下一个Flutter应用程序时。我非常庆幸将时间花在学习Fluttet上。对于企业来说,现在有了一种可用于开发多平台应用程序的选项,而对于开发人员来说,使用它是一种乐趣。如果你将这个事实与谷歌在Fuschia操作系统上对Flutter所做的投入相结合,你就可以知道,这些事实本身就表明谷歌非常重视这项技术。
英文原文:https://hackernoon.com/one-year-with-flutter-my-experience-5bfe64acc96f
更多内容,请关注前端之巅。