为什么说Flutter可能不是下一件大事？
共 3891字，需浏览 8分钟
·
2020-11-15 05:04
我注意到最近有很多文章将 Flutter 宣传为“下一件大事”（next big thing）。一些人甚至详细解释了 Flutter 为什么会替代 React Native 成为开发人员首选的跨平台技术。
但它并没有那个能力。
我见识过 Flutter 的很多缺陷，我认为它遇到了几个关键问题。
请注意，本文在 Flutter 社区中招来了很多热情的评论，赞成和反对皆有。我强烈建议读者读完本文，再去原文看评论区大家的正反意见。
只要谈到跨平台技术，React Native 是绕不开的。
React Native 之所以受欢迎，是因为很多人相信它的愿景，并认为自己的前端 JavaScript 开发人员可以创建一流的应用。他们当然做不到，但这并不能阻止他们尝试一番。
问题是许多公司已经有了 JavaScript 开发人员。而且 JavaScript 人士常常会告诉管理层：“是的，我们可以节约一半时间。”
正如我指出的那样，其实他们做不到。确实，只要你入了门，起码 80% 的应用你都能很快搞出来个大概。可是你要将 80% 的时间花在应用的外观调整上，让它能在各个平台上正确运行。
说到各个平台……
Flutter 的 Skia 渲染引擎可以让你的应用模仿原生的外观和体验，但也只是模仿而已。它可以编译为原生代码，但并不会使用原生按钮、字段、切换、滚动条、表视图或其他界面和导航元素。
苹果和谷歌几乎在每个发行版上都会调整和更新这些界面元素及其行为。因此，只要应用忽略它们，就别想跟上节奏了。
此外，如果 iOS 上的 Flutter 出现错误，你只能等待谷歌来修复了。
说到 iOS……
我应该强调一下，我是从 iOS 的角度开始体验 Flutter 的，而 Flutter 的确让 iOS 感觉像是二等公民。
Flutter 基本上是 Android 优先的开发环境，从底层开始就依赖 Android 的 Material Design 指南。
因此，如果你想开箱即用地创建看起来像 Android 应用、动起来也像 Android 应用的东西，Flutter 很合适——否则……就没那么舒服了。
此外，iOS 开发正在扩展到苹果生态系统内的许多平台（watchOS、tvOS、iPadOS、macOS），因此 Flutter 只能带你入个门而已。
当然，使用 Cupertino 小部件可以解决部分问题，但是……
正如我刚刚指出的，Android 同时提供 Cupertino 和 Material 小部件。
这的确很不错，但这也意味着，如果你希望应用程序看着像原生一样（顺便说一句，React Native 是做得到的），你还得使用正确的小部件集来完成工作。这可能意味着界面的某些部分需要写两次代码。
更不用说你可能还必须为各个平台针对性地重组应用的各个部分，以适应平台的外观和风格（这个平台要求导航栏在标签栏内，那个平台正好相反，诸如此类的问题）。
是的，你可以重用业务逻辑，但是我认为这并不能解决在两个平台上编写、测试和调试用户界面的问题。
一些人在评论中还提到 Flutter 可用于 Web，因此你可以免费获得“另一个”平台。
是的，你可以将 Flutter 用于 Web……尽管 Web 版本仍然处于 beta 阶段，甚至谷歌在大多数情况下都不推荐使用它。
目前，并非每种 HTML 场景都适合用 Flutter 编写。例如，博客文章之类基于流的富文本内容更适合以文档为中心的模型，这种模型是 Web 的基础；而像 Flutter 这样的 UI 框架可以提供的是以应用为中心的服务，和前者并不相称。
因此，是的，如果你想做一些数据可视化、制作一个在线工具（例如汽车配置器），或者制作某种嵌入式图表（同样也是谷歌推荐的用例），那都没问题。
问题是，我们不是刚刚将一些沉重的、非 HTML 的应用渲染技术赶出了互联网吗？
尽管 Flutter 的支持和文档状况略有改善，但远远无法和在 iOS 或 Android 上进行原生应用开发时获得的支持相提并论。
想要关于 Swift、Java、Kotlin、Cocoa 的文章、书籍、视频和课程？随便就能找到一大堆。
需要在 Stack Overflow 上求助吗？你想问的任何问题几乎都已经被问过并得到回答了。
但是 Flutter 呢？就没那么多了。
从评论中可以看出这一点：
单说支持问题就很让人头疼，尤其是在 Android 上（依赖地狱足以与 Windows 上 90 年代中期到 00 年代初的“DLL 地狱”相媲美）。
谷歌抛弃自己曾经热捧技术的历史可谓臭名昭著，谁都没法否认这一点。而且，如果谷歌哪天认为 Flutter 不会取得回报，那么弃之如敝屣也毫不奇怪。
谷歌是在推广 Flutter，但同时他们也在推广 Kotlin 上的 Jetpack Compose，甚至 Kotlin Native Common 模块，以提供跨平台支持。
更不用说苹果也在推进自己的下一代声明式开发技术：SwiftUI。尽管它和 Flutter 不能直接对比，因为它不能用来创建 Android 应用，但是 SwiftUI 确实能让开发人员一次性支持所有苹果平台：iOS、iPadOS、macOS、watchOS 和 tvOS。
如果两种技术都能达到预期的效果，并且都大大减少了开发原生应用程序所需的时间，那么 Flutter 究竟还剩下什么优势可言呢？
Flutter 的最大缺点之一是其实现语言 Dart。
如果你在运行谷歌的 Web 或后端托管环境，那么 Dart 是你可以使用的一种语言，仅此而已。这意味着，如果你为了 Flutter 而花时间去学习 Dart，那么很有可能那些来之不易的经验唯一能发挥价值的场所就是 Flutter。
后一点可能是最让人望而却步的。我的意思是说，如果我想成为一名移动开发人员，我可能会学习 Swift 或 Kotlin，因为它们都是现代语言，而且实际上两者都有很多就业机会。
Dart 呢？显然没那么多。
严格来讲 Dart 并不难学，但这主要是因为它是一种简单的语言。正如另一位评论者所指出的：
学习了 Swift 和 Kotlin 之后，Dart 感觉像是在开倒车。它缺少许多其他现代语言可用的特性。它的类型系统不是很好。设计 Dart 的人似乎有一个“让 JS 开发人员轻松使用”的设计目标。Dart 的边缘也很粗糙，就像 Javascript 一样；而 Swift 和 Kotlin 在所有重要细节上都感觉很精致、成熟和完整。
Dart 缺乏市场渗透力，这意味着如果你的团队中需要更多 Dart 开发人员，可能人都招不到。反过来说，这意味着你只能自己培养人才。这当然可以做到，但在他们还没成长起来之前你仍然要为他们开工资。
最后请记住，在某个时候，你可能会遇到框架的局限性（或需要移植到更多平台上），然后你无论如何都要退下来，并做一些原生开发的工作。
在这种情况下，你仍然需要学习 Swift 和 Kotlin。
作为可能的解决方案，我们曾几次将 Flutter 推荐给客户，而客户一直反对这种想法——尤其是当他们想利用自己内部的 JavaScript 开发人员时，就像我前面提到的那样。
但请放心：他们也提到了我上面列出的几乎所有问题。
上面谈到的这些内容可能会让你相信，Flutter 可能不是你项目的最佳选择。
但我并不是这个意思。你只需要认识到它的局限性即可。
在我看来，Flutter 最适合小型内部开发团队，这些团队需要快速创建概念验证应用，而这种应用在外观和设计上基本上都是非原生的。
一个可能的例子是儿童游戏或应用，它们有着独特的界面，而且外观上肯定不是原生的。在这种情况下，Flutter 并不能完全模仿 iOS 和 Android 体验的问题就显得无关紧要。我在上文提到的需要编写两次界面的问题也不复存在。
哦，你还需要一个不介意学习全新平台和语言的团队。
那么……结论很明显了。
Flutter 是一项很酷的技术，但在大多数情况下，它没法成为舞台上的主角。
再说一遍，本文只是一种见解。欢迎不同意见，你可以在下面的评论中发表自己的意见。（实际上，其中一些要点已经在文章中反馈了。）
另请注意，我不是 React Native 的粉丝。React 遇到了许多相同的问题，此外还带来了一些重大的性能损失。
最后补充一下：我并不是说 Flutter 没有合适的使用场景。但是，与已知领域中的其他事物一样，它也存在一些折衷和已知的局限。最后你必须决定你和你的组织是否愿意给这种技术长期下注。
感谢阅读。
https://medium.com/better-programming/why-flutter-isnt-the-next-big-thing-e268488521f4