Tim Sneath：“Flutter 之于应用，就像 Unity 之于游戏”

简介

我们与 Google 负责 Flutter 和 Dart 的产品经理 Tim Sneath 进行了交流，讨论了这个语言和框架组合在过去两年的发展情况、目前的使用情况，以及它们未来的发展方向。

采访

Evrone: 你的职位是“Flutter 与 Dart 产品经理”。 作为与开发人员相关的框架和编程语言方面的产品经理，而不是消费品产品经理，需要具备什么条件？

Tim: 我从没做过消费品产品经理，所以我只了解开发人员相关的情况！ 但总的来说，作为产品经理，就是要把经营策略、客户反馈、工程资源和一定数量的预测直觉结合起来，打造一款有望受到目标用户喜爱的产品。

在过去的几年中，Flutter 的使用量大幅增长，许多我需要花时间思考的挑战都涉及到如何处理和权衡这种增长：分别为构建新功能和完善现有内容分配多少资源？ 我们如何在内部用户、企业和初创公司之间分配注意力？ 我们如何不过度分散注意力的情况下，支持折叠式设备等新的规格以及 Windows 和 macOS 等平台？

Evrone: 目前，使用代码构建 UI 的框架似乎正在复兴，Flutter、Swift UI 和 Jetpack Compose 都是在过去几年公布或发布的。 热重载是在提到 Flutter 时经常会谈论的话题。 对此，你观察到了什么趋势？

Tim: 我认为这些年来，开发人员的生产力都耗费在创新上了。 当 Visual Basic 1.0 问世时，我还在上大学，它在许多方面代表了 UI 开发便捷性的较高水准。 我的意思是，你想想看，在 VB 之前，构建一个 Windows 应用程序需要用 C 语言编写几百行代码 ，要使用 DOS 编辑器和命令行编译器，还要经过细致的编辑/编译/调试循环才能运行。 Visual Basic 使业余开发人员能够在屏幕上直接绘制 UI 设计 ，同时还提供了“编辑和继续”功能，即暂停某个应用，进行修改，然后继续而无需重新编译。

在过去的几十年里，这种操作的难度只增不减。 我们给曾经简单的操作增加了许多复杂度，包括预处理器和转译器，传递依赖性不明确的深层嵌套模块层次结构，还有使你的应用在完成之前就已过时的快速转变的栈。

我们还有很长的路要走，但有状态的热重载是一个进步，有助于恢复“编辑并继续”这种 UI 开发的便捷性。 我希望我们能够继续降低使用 Flutter 将构想变为应用的认知负担，使开发人员能够将更多精力放在他们想要构建的内容上，而不是放在如何用代码进行表达上。

Evrone: 从第一个 Qt 版本开始，“原生操作系统部件”与“像素级绘制的自有部件”之间的战争已经持续了几十年。 根据你在许多大公司创建移动应用的经验，目前的情况如何？

Tim: 我认为这是一种错误的二分法。 质量才是最重要的：你能不能打造出深受挑剔用户青睐的美好体验？ 而质量与哪个二进制符号在屏幕上呈现哪个像素的关系不大：质量是性能、对细节的关注和技术能力的结合。 许多获奖游戏都是使用 Unity 游戏引擎打造的，但没人关心《纪念碑谷》是否使用了“原生操作系统部件”。

我们相信 Flutter 之于应用，就像 Unity 之于游戏：无论目标平台是什么，都能为应用带来原生性能和视觉效果。

Evrone: Dart 与 Google 全新的“Fuchsia”项目有什么关系？ 它和 C ++、Rust 和 Python 一起被列为“推荐”语言之一。

Tim: Fuchsia 是一个实验性的开源操作系统，我们已经研究了一段时间。 现阶段我们没有太多可以分享的内容，但源代码都是公开的。 Flutter 支持 Fuchsia. 的构建，所以你会在 Flutter 源代码中看到各种对它的引用。 当然，Dart 是编写 Flutter 的语言。

Evrone: 像 eBay 或 BMW 这样的大公司在他们的移动项目中采用了 Dart+Flutter 的组合。 对于他们来说，主要卖点是什么？

Tim: 对于许多这样的大公司来说，这仅仅是能够通过一个高质量的解决方案来统一他们的应用开发。 大多数面向消费者的应用都有多个团队在处理完全相同的业务问题，交付成果和时间表也完全相同，不同的团队只是在 iOS、Android 和 Web 上使用不同的语言和工具来完成相同的工作，仔细想想，这真是不可思议。 在如今的软件开发中，几乎没有其他类似的东西：公司不会愿意实现三个新的独立的薪资系统。 当团队发现他们不仅可以同时为多个平台构建高质量的原生体验，而且由于有状态热重载等功能，他们还可以比在任何单个平台上更高效，这就是一个很大的卖点！

最大的挑战是非技术性的：许多公司会围绕他们的目标平台进行组织调整，所以有时会遇到不想进行统一合并的团队的阻力。 当然，我们仍然是一个年轻的平台，所以更多保守的公司会对这条新的路径本能地持怀疑态度。 但时间会解决这个问题：我们的软件包和插件生态系统在去年增长了 5 倍，商店中有成千上万的应用证明了 Flutter 能够大规模提供高质量的产品。

Evrone: 在你看来，对于开发人员来说，为平板电脑和手机分别创建布局更好，还是现代技术已经足够强大，可以创建能够完美适应不同屏幕大小的“自适应”UI？

Tim: 自适应 UI 设计的挑战在于框架和工具两方面。 Web 已经支持媒体查询很多年了，但是要建立能在不同规格的设备上平滑缩放的体验仍然很困难。 Flutter 让这一切成为可能，Matias Duarte 最近演示了一个我们正在 Flutter 中进行实验的工具原型。

Evrone: 你现在喜欢用哪种 IDE？ Android Studio、JetBrains 的产品、VSCode，还是其他产品？

Tim: 就我个人而言，我已经习惯了 VSCode，因为我是从 Visual Studio 团队来到 Google 的，这么多年来我在这个产品套件上花了很多时间。 我很欣赏 Danny Tuppeny 在构建 Flutter 和 Dart 扩展程序方面所做的工作；看到 Flutter 在 VSCode 中成为一种无缝体验，我很高兴。 当然，作为一个团队，我们并不关心你使用什么编程工具，无论是 Android Studio、IntelliJ、VSCode、Vim 还是 Emacs！

有一个项目让我很感兴趣，那就是语言服务器协议，它试图用通用协议来弥补编辑器和语言之间的差距。 除了正在进行的调试适配器的类似项目外，我们希望这能让开发人员逐渐选择适合自己需求的工具，而无需语言作者在每个工具上进行重复工作。

Evrone: 有传言说 Dart 打算取代 Web 浏览器中的 JavaScript，但现在却转而支持 Flutter。 这是真的吗？ 还有，Dart 在移动应用开发之外有哪些用途？

Tim: 没错，Dart 最初起源于 V8 团队，他们当时正在为应用开发的新方式设计原型。 但是当时的 Dart 和现在 Dart 完全不同，几年前，随着 Dart 2.0 的推出，Dart 作为一种客户端优化的语言重生了。 如今的 Dart 专注于一个特定的技术领域：跨 Web、移动和桌面的平台可移植性；快速的对象创建和垃圾回收；在开发过程中进行虚拟机注入，并在运行时进行原生编译。 这使得它特别适合客户端场景，无论是 Flutter、CLI 还是业务逻辑。

Evrone: 您个人对“全栈”这个概念有什么看法？ 像 Dart 这样的语言在前端和后端都能有很好的表现，对于当代的开发人员来说，编写应用的所有部分是否可行？

Tim: 我不知道其他人怎么样，但我发现光是跟上客户端技术就已经很难了! 拥有一种语言能够灵活地在移动、Web、服务器和云端运行，这是非常好的，我们看到许多人在服务器上使用 Dart 取得了很不错的效果，通常是分享他们已经为客户端编写好的现有业务逻辑。 我想对于开发人员来说，做全栈开发是可行的：因为有很多人就是这样做的。 但随着应用规模的增长，对专业化的需求会越来越大，我认为在创业孵化项目之外，你在 Google 不会找到很多真正的全栈开发人员。

Evrone: Web 版的 Flutter 现在已经处于 Beta 阶段，而桌面版的 Flutter 已经处于早期 Alpha 阶段。 你对它们有什么展望？

Tim: 它们都还在开发中，但是我们离目标越来越近了，很快我们就会宣布我们在这两个产品中取得的进展。 我们从未将 Flutter 设计为仅限移动设备；我们一直努力将它设计成一个可移植的 UI 框架，而 iOS 和 Android 恰好是前两个目标。 桌面类应用面临着新的挑战：规格和输入法不同，它们通常会使用不同的 UI 隐喻，并且需要能够调整大小和处理多个窗口。 此外，与已安装的桌面或移动应用不同，Web 是短暂的。

作为 Flutter 的目标，Web 版和桌面版都很振奋人心，但方式不同。 Web 在技术上更具挑战性，特别是如果你想避免像 Flash 和 Silverlight 这样的较旧项目产生的“恐怖谷效应”。 我们希望 Web 版能够做到足够好的无缝体验，让你需要查看源代码才能知道页面是否使用了 Flutter。 我们还在性能方面取得了不错的进展：最近，我们已经完成了针对 Web 的 CanvasKit 后端，该后端能够提供巨大的收益。

桌面版提供了一系列有趣的用例：从为开发人员提供一条通往数十亿台 Windows、macOS 和 Linux 机器的便捷通道，到极大减少新用户入门 Flutter 的阻力。 在开发 Flutter 应用时，我越来越多地将桌面版作为我的首要目标，因为不需要模拟器或连接的设备即可查看结果。

更吸引人的是，选择 Web 还是桌面在 Flutter 中是后期绑定的。 我们内部有几个项目正在开发中，但仍然没有选择是否计划以原生编译的桌面应用还是以渐进式网页应用 (PWA) 的形式发布。 能够提供这种程度的灵活性真是太棒了。

Evrone: 你能比较以下 Flutter 和 React Native 吗？ 对于一名普通的开发人员来说，放弃熟悉的 JavaScript 并学习一门新的编程语言会有哪些收获？

Tim: 早期的时候，响应式编程风格给了 Flutter 很大的启发。 与长期以来盛行的消息传递和保留模型风格相比，这是一个重大转变。 但要回答这个问题，就很难不被认为是在贬低另一个框架，这并不是我的本意。 它们各有各的优点和局限性，仁者见仁智者见智，就不用我再补充了！

Evrone: 如果你能穿越时空，改变 Dart 语言的任意一个功能，你会选择哪个功能？

Tim: 哈！ 毫无疑问，在过去的几年里，我们花费时间最多的功能是强模式：将静态的、健全的类型系统引入语言。 Dart 最初的概念是一种可选的类型化语言，为了开发的需要，可以通过注释来表达类型，但没有运行时的语义效果。 在 Dart 1.x 中，这是语言的核心原则，但随着时间的推移，这种方式的局限性就变得非常明显，因为即使是 Web 世界也已经转向使用 TypeScript 进行类型检查了。

对现有的编程语言进行如此大规模的更改并非易事，但工程团队在 Dart 2.0 中完成了这项工作，在这个过程中，将 Google 的 monorepo 里面的数百万行 Dart 代码迁移到了一个新的通用前端编译器上。 现在，我们在这项工作的基础上增加了完善的空类型安全性，在整个框架中提供了可验证的非空类型。

我们差不多花了 50 多年的工程时间来推翻这两个设计决定，但最终的结果是一个健全的、空类型安全的语言，其编译器经过了实战检验，可以从相同的源代码中编译出 JavaScript、Intel 和 ARM 机器代码。 我认为这是独一无二的。

在 Evrone，我们也对 Dart 和 Flutter 的持续发展感到非常兴奋：它们变得越强大，我们就越能为客户和合作伙伴打造更好的移动应用解决方案，他们中的许多人已经亲眼目睹了 Dart 生态系统在加速开发方面带来的好处。