- 原文地址:One Year with Flutter: My Experience
- 原文做者:Nick Manning
- 译文出自:掘金翻译计划
- 本文永久连接:github.com/xitu/gold-m…
- 译者:ssshooter
- 校对者:shixi-li, MirosalvaSun
这是 Flutter 美好的一年。html
大概恰好一年前,我写了一篇名为「为何 Flutter 2018 年即将起飞」的文章。虽然 Flutter 几乎通过整个 2018 年的测试阶段才达成如今的 1.0 版本,可是它的社区和产品已经在这个过程当中获得了飞速的成长,如今 Flutter 已经进入 GitHub 仓库 star 排名前 20。而这篇文章,介绍的是我一年来使用 Flutter 的经验,以及我在此过程当中发现的 Flutter 的优缺点。前端
过去一年我用 Flutter 作了什么:react
在我列出个人想法以前,先介绍一下个人技术背景,就移动开发来讲我是 iOS 开发。另外,去年我在平常工做中也大量使用了 React Native。我不打算将 Flutter 与这些技术进行比较,但这些移动开发经验确实会影响我对 Flutter 的印象。android
而后,如下就是我使用 Flutter 一年来学到的:ios
相比去年我在 React Native 开发中普遍使用的 TypeScript 和 Flow,Dart 更容易学习,语法更简单。我可以高效开发应用,必不可少的是可靠的编译器,它有明确的,定义良好的错误消息,极少的意外隐藏运行时错误。若是有足够多的人但愿了解相关内容,我会写一篇更详细的例子比较。我要说的是,即便是编写中等规模的应用程序,开发人员也应该考虑强类型语言,由于这为高速开发和编写可靠代码节省了大量时间。git
涉及新技术的另外一个常见状况是:须要「本身动手」写一个库对接第三方服务。例如,要使用 Mixpanel 分析个人应用程序(由于他们大方地给出了免费套餐,而且 UI 简单,清晰),我不得不本身动手封装一个库:pure_mixpanel,这不难,并且颇有意思。github
我使用 scoped_model 得到了不错的实践,由于它很好的去掉了流的使用,使用方法很像 React 刚更新的 Context API。你能够干净利落地将业务逻辑和渲染逻辑完美地分开,而且很是容易上手。web
Flutter 是一项新技术,所以在实践、架构模式和状态管理等方面仍然难以得到足够的意见。有些人遵循「BLoC」(business logic component)模式。由于我认为它有点过于的复杂,因此仍未肯定使用它。还有 RxDart 和 Redux for Flutter,这两个我还没用过,由于它们彷佛也太麻烦了。另外一方面,Android 或 React 工程师彷佛有很多成功实践,多是由于他们已经习惯这种模式。typescript
我认为整个生态系统将在 2019 年成熟,由于愈来愈多的人正在编写更复杂的 Flutter 应用程序。编程
关于这一点其实没什么好说的,Flutter 这个特性的重要程度,足以在本文增长这一节。Flutter 热重载很快,并且更可靠。对于其余技术的热重载,我真不敢这么说(告诉本身我没有黑其余技术)。
Material Design 很美好,可让咱们快速起步。显然对于某些类型的 web app 以及 Android 应用来讲是个不错的选择,可是将它呈现给 iOS 用户并非一个好主意,除非它是谷歌应用或其余很是简单的应用。iOS 用户习惯使用 CocoaTouch 风格的 UX。
「一次编写随处运行」、定制的自定义设计、引入设计常见的设计元素(例如,标签栏)等状况愈来愈广泛。尽管 Flutter 确实提供了大量 iOS 风格的 widget,但为了使代码易于维护,大多数人会使用封装定制后的 Flutter 的 Material Design 库,这是很容易实现的。
我将撰写另外一篇关于这个主题的文章,但个人建议是坚持使用 Material Design,能够在某些方面,试着让那些 iOS 用户以为不那么「安卓」。以表单为例,使用 Material Design 样式的表单字段对两种类型的用户都是足够熟悉的。
我习惯使用 React、CSS Grid、Flexbox 等库来实现布局。Flutter 的布局方法从这些库中借鉴了许多。若是你已经熟悉这些基于 Web 的布局概念,那么学习 Flutter 布局将会很是简单。即便不懂 Web 布局,它仍然很简单。若是你想感觉一下 Flutter 的布局方法,能够观看此视频。
此外,从代码可读性的角度来看,Dart 和 Flutter 中的 UI 逻辑很是出色。总的来讲,比起 JSX 我我的更喜欢这种布局方式。它让我想起了 Swift 和 iOS 中简单的布局逻辑(若是你是以编程方式实现布局的话)。
虽然有大量可靠的文档,教程,社区以及与其余 Flutter 使用者的帮助,可是这些都太着重于 widget 了。Flutter 刚出来时这确实很必要。但最终,愈来愈多的人不只仅是实现纯 UI 和动画,而是开始编写更多更完善的应用程序,我认为 Flutter 的网站上应该突出介绍更多的端到端教程。这也是我本身开设课程网站的主要缘由。
我学习编写 Flutter 应用并不局限于仅仅使用控件。我发现有许多更高级的 Dart 功能很是有用,你必须挖掘它们。我提到的架构模式也值得挖掘。最后,集成 Web 服务和其余 Dart 最佳实践集成仍须要更多文档和教程。
我老是争取更少的模版代码。虽然某些工具在一些简单项目中解决了个人问题,但我想个人下一个项目我会使用 GraphQL 或 gRPC。我认为对这二者的投入都是值得的。关于 gRPC,我不推荐将它用于较小的项目,但对于中大型项目,一旦你使用它,就会爱上它。gRPC 在个人一个 Swift 项目行之有效,已经投入生产环境运行好几年了。
你须要必定时间习惯为每一个平台(特别是 Google Play 商店和 iTunes Connect)提交应用程序所需的工具和步骤,但这很是简单。我会说为 iOS 提交应用程序确定更符合学习曲线。
在 Flutter 应用开发过程我认为有必要学习的那些控件中,实际被我用到的大概只有 20%。例如 Center widget,为何须要一个只具有使子控件居中这样单一功能的控件?虽然它使新手很容易上手,可是在实现复杂的布局时,widget 会产生太多嵌套的Dart代码。相反,我会回到基本的 Container 布局,由于这相比起来更灵活。
个人建议先关注于简单,基本的 widget,真正须要时再学习其余 widget。
Firebase 彷佛是一款出色的产品。它让我想起了当年的 Parse。Firebase 对这些状况是比较好的选择:简单的项目,或者你将要把项目移交到没有足够后端技术人员的客户时。
但事实上,大多数产品已经有现成的后端,或者技术团队编写本身的后端。无论大型公司或者甚至是初创企业都是如此。
对于独立开发者或小团体,若是你的流量激增,每个月 Firebase 帐单会发生什么变化?这就是我避免使用 Firebase 的主要缘由,若是个人应用真的如梦想通常被用户疯传,Firebase 找我要钱怎么办?
请注意,个人职业是编写后端系统,因此这仅仅是个人我的见解。若是你是初级开发人员,想要将简单的后端交付给客户,或者你只是不想编写后端 API,我仍然推荐使用 Firebase。
Widget 和 class 文档如今有愈来愈多的示例(例如)。这是对比其余缺少适当示例的库是巨大的优点,更不用说编写良好的文档了。
除了文档以外,去年 Stack Overflow 上还有不少热情、知识丰富的人为我提供技术支持。
我当 iOS 工程师不少年了,因此我有点被 iOS 开发惯坏了。不只是文档和支持,仍是 iOS 生态系统的总体质量,从库到 Xcode,再到 CocoaTouch SDK 的组织方式。
Flutter 也符合我以前的体验。它也很是简单,同时也考虑了某些 React Native 组件的简单性,好比 ListView(朋友,你使用过 iOS 的 UITableViewController 吗?Yuck)因此总的来讲,有了成熟的工具来配合 Flutter,学习和使用它会很是流畅。再也不须要像 Xcode 这样复杂的工具真的让人眼前一亮。
游戏开发者可能永远不会只为一个平台编写一套代码。React Native 和 Flutter 出现后,「非游戏开发者」也能作到一样的事。
例如,在空闲时,我会参与夫妻经营的小项目,与个人 UX 设计师妻子编写应用程序。Flutter 重构这个 iOS 应用后,用户基数变为双倍,如今它已经在两个平台上发布,我确定不会再考虑回到单平台了。
一年以后,我将开始编写下一个 Flutter 应用程序时(以后将会发布记录开发过程的视频!),我仍然很是高兴我将时间投入到学习 Flutter 中。我如今已经不能回到以前的开发模式。对于企业来讲,做为一种用于多平台编写技术的可行选择是有意义的,并且,做为开发人员使用跨平台技术也是一种乐趣。再加上网页 Flutter 技术,好比 Hummingbird 以及谷歌为全新 Fuschia 操做系统 长期投入 Flutter,这些事实都代表谷歌注重这项技术。
欢迎随时经过 Twitter 与我联系。另外若是你感兴趣,能够看看个人网站 fluttercrashcourse.com 上的免费 Flutter 课程!
2019 编程快乐!
若是发现译文存在错误或其余须要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。
掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。