标签：flex 根据 自定义 代码 rebase 概念 ann pac 过程
使用Flutter一年后，这是我得到的经验
作者｜Nick Manning
译者｜薛命灯
在这篇文章中，我将分享我使用 Flutter 的经验，以及我在整个过程中发现的所有 Flutter 的优缺点。
在过去的一年里，我是如何使用 Flutter 的呢？我做了以下这些事情：
与 TypeScript 或 Flow 相比，Dart 更容易学，语法也更简单。我能够快速地进行开发，因为编译器提供了明确的错误消息，具有更少隐藏的非预期运行时错误。在开发中型应用程序时，开发人员应该拥抱强类型语言，因为它在加快开发速度和编写可靠代码方面起到很大作用。
在采用新技术时，有时候需要“推出自己的”库，以便与第三方服务集成。例如，为了在我的应用程序中集成 Mixpanel（因为它们提供了一个免费套餐选项和一个非常简单清晰的 UI），我不得不开发我自己的库 pure_mixpanel（https://pub.dartlang.org/packages/pure_mixpanel）。这不是什么大不了的事情，实际上它很有趣。
我个人在使用 scoped_model 方面有很多成功的经验，它很好地抽象出需要使用流的地方，并且很像 React 的新 Context API。你可以干净利落地将业务逻辑和渲染逻辑完美地分开，并且它非常容易学。
首先，Flutter 是一项新技术，因此在实际应用、可信的架构模式和状态管理工具方面仍然有待发展。有些人会遵循“BLoC”（或“业务逻辑组件”，https://www.youtube.com/watch?v=fahC3ky_zW0）模式。在我看来，它有点太过复杂了，而且有些复杂性是不必要的。
还有 RxDart（https://github.com/ReactiveX/rxdart）和 Redux for Flutter（https://pub.dartlang.org/packages/flutter_redux），不过我还没有用过它们，因为它们看起来也过于复杂了。但是，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 的布局就会非常简单。即使不熟悉，学起来也很容易。如果你想感受一下，可以看一下这个视频：
https://fluttercrashcourse.com/lessons/container-layout-column-row
此外，Dart 和 Flutter 的 UI 逻辑在代码可读性方面表现得都非常出色。总的来说，我更喜欢自己实现布局，而不是使用 JSX 之类的东西。它让我想起了 Swift 和 iOS 中的布局逻辑是多么的简单，如果你是通过编程的方式实现布局的话。
虽然现在有很多与 Flutter 相关的文档、教程、社区，但我认为人们对小部件的关注有点过头了。这点是可以理解的，毕竟 Flutter 还很年轻。但是，最终越来越多的人不仅用 Flutter 来实现纯粹的 UI 和动画，而且还会用来开发更多完整的应用程序。我认为，Flutter 的网站上将会有更多端到端的示例教程。
我学会了使用 Flutter 开发整个应用程序，而不仅仅是小部件。我发现了很多非常有用的 Dart 高级功能。我提到的架构模式也是值得你去深究的。最后，与 Web 服务集成和其他 Dart 最佳实践仍然需要更多的文档和教程。
我总是希望能够减少样板代码的使用，虽然有一些工具（https://flutter.io/docs/development/data-and-backend/json）可以帮我解决这个问题，但对于我的下一个项目，我将使用 GraphQL 或 gRPC。我认为对这两项技术的投入都是值得的。至于 gRPC，我不推荐将它用于较小的项目，但对于中型或大型项目，一旦你用了它，就很难再退回去了。gRPC 在我的一个使用 Swift 开发的项目中非常有效，已经在生产环境中运行了好几年。
为每个平台提交应用程序所需的工具和步骤需要花一些时间来学习，特别是谷歌 Play 商店和 iTunes Connect，但其实它们非常简单。
我之前学习了所有我认为必须学习的小部件，但最终只使用了大约 20％。例如，Center 小部件（https://docs.flutter.io/flutter/widgets/Center-class.html）。
为什么要单独使用一个小部件来让元素居中？虽然它让新手很容易上手，但在用它实现更复杂的布局时，会产生太多嵌套的 Dart 代码。相反，我会选择基本的 Container 布局（https://docs.flutter.io/flutter/widgets/Container-class.html），因为它们非常灵活。
我的建议是专注于基本的简单小部件，只有到了真正需要的时候才去了解更多的小部件。
Firebase 看起来像是一款出色的产品，它让我想起了之前的 Parse（https://parseplatform.org/）。对于简单的项目，或者在后续需要将项目移交给没有足够专业开发人员的客户来说，它似乎是一个不错的选择。
现实情况是，大多数公司都已经有自己的后端，还有一些技术团队选择自己开发后端。大型公司或初创公司倾向于这么做。
对于独立开发者，如果你的流量激增，能承受每月的 Firebase 账单吗？这实际上也是我避免使用 Firebase 的主要原因，因为如果我遇到了病毒传播式的“梦想问题”，并且 Firebase 根据使用情况收取费用，我将如何应对？
因为我是以开发后端系统为生，所以会存在这样的偏见。如果你是初级开发人员，你开发的后端到最后会移交给客户，或者你不开发后端 API，那么我仍然会强烈建议你关注 Firebase。
窗口小部件和类文档现在有越来越多的示例：
https://docs.flutter.io/flutter/widgets/Container-class.html
相比其他缺乏文档的库，这是 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
标签：flex 根据 自定义 代码 rebase 概念 ann pac 过程
原文地址：https://blog.51cto.com/15057848/2567794
