[译] 为何每一个 Android 开发者都应该尝试 Flutter

• 原文地址：Why every Android Developer should try out Flutter
• 原文做者：Aaron Oertel
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：ALVINYEH
• 校对者：DateBro

几个月前，我写过一篇题为“为何 Flutter 能最好地改变移动开发”的文章。虽然已通过去了一段时间，可是我对 Flutter 的热爱依然很是强烈；事实上，当我继续使用它时，我意识到了我以前忽略了 Flutter 独特方面的重要性。不要误会个人意思 —— 我仍然认为 Flutter 最强大的一点就是如何解决跨平台开发的许多问题。但最近我开始关注移动开发发展的更多领域，特别是声明性用户界面的概念。

摄影者：来自 Unsplash 的 Chris Charles。

我相信你已经听过一系列关于为何 Android 开发者应该关注 Flutter 的若干论据（若是你尚未看过，请让我谦逊地建议你瞧瞧这个），可是我想指出一个我尚未真正解决的大问题，那就是 Flutter 可让你对 App 开发有彻底不一样的见解。首先，你的应用自己将采用不一样的方式构建 —— 但更重要的是，实际的 UI 开发经过将其合并到你的 Dart 代码（而不是 XML）中而被推到前台，所以使它成为了“一等公民”。一旦你的 UI 代码忽然出如今一种非标记语言中，你就会意识到你忽然有了构建应用的可能性。说实话，在使用 Flutter 以后，我开始讨厌在 Android 上编写 UI 代码；由于在 Android 中步骤更加繁琐，虽然你仍然可使用数据绑定等工具构建响应式应用，但它实际上比 Flutter 中要花费更多的时间。

当你考虑在 Android 中整合动画和其余动态数据时，使用 Flutter 的论点变得更加有力。整合动画可能会不太方便，有时你可能不得不拒绝设计师的要求，由于要实现他们的需求太难了。谢天谢地，Flutter 改变了这一切。若是你一直在关注 Flutter，你可能已经从 Fluttery 据说过 Flutter 挑战。这些挑战展现了构建具备大量自定义组件和精美设计（包括动画）的复杂 UI 的快速和直观性。在 Android 上实现这样的东西会变得很是困难 —— 特别是由于与 Flutter 不一样，Android 的视图基于继承而非组合，这使得构建视图变得更加复杂。

下面，让咱们切入正题：使用 Flutter 构建声明性 UI，这改变了 UI 开发的一切。如今也许你在想，Android 布局不也是以声明方式构建的吗？ 答案是确定的，但事实不是。使用 XML 来定义布局让咱们有了以声明方式定义布局的感受，但若是你的视图是彻底静态的，而且全部数据都是以 XML 格式设置的，那么这种感受才真正成立。不幸的是，这种状况几乎从未发生过；一旦添加动态数据和相似列表之类的东西，你天然必须使用一些 Java / Kotlin 代码将数据绑定到视图。而后咱们最终获得某种 ViewModel，它将数据设置为视图。想象一下，这就像在 Android 上调用 textView.text =“Hello Medium！” 同样。在 Flutter 上，这是彻底不一样的：你建立了一个包含某个状态的窗口组件类，而后根据该状态以声明方式定义你的布局。每当状态改变时，咱们调用 setState（） 来从新渲染咱们改变的组件树的部分。让咱们看一下如何在 Flutter 中使用 API，并使用结果渲染一个 List：

@override
Widget build(BuildContext context) {
  return new FutureBuilder<Repositories>(
    future: apiClient.getUserRepositoriesFuture(username),
    builder: (BuildContext context, 
        AsyncSnapshot<Repositories> snapshot) {
      if (snapshot.hasError)
        return new Center(child: new Text("Network error"));
      if (!snapshot.hasData)
        return new Center(
          child: new CircularProgressIndicator(),
        );
      return new ListView.builder(
        itemCount: snapshot.data.nodes.length,
        itemBuilder: (BuildContext context, int index) =>
            new RepoPreviewTile(
              repository: snapshot.data.nodes[index],
            ),
      );
    },
  );
}
复制代码

在这里，咱们使用了 FutureBuilder 来等待网络调用（Future）的完成。一旦网络调用完成，出现结果或错误，FutureBuilder 组件会在内部调用 setState 来调用所提供的 builder 方法来从新渲染。正如你在这个例子中看到的，一切都是声明式的。在 Android 上作一样的事情一般须要一个被动的 XML 布局，而后须要一些其余类来手动设置状态，好比 Adapter 和视图模型。这种方法的问题在于，状态可能与屏幕上渲染的状态不一样。这就是为何咱们但愿拥有像 Flutter 为咱们提供的那样的声明性布局。咱们最终编写的代码要少得多，同时将状态绑定到要在屏幕上显示的内容。

有了这些声明性布局，咱们也开始对架构进行了不一样的思考。忽然间，reactive 这个词出现了，咱们谈论了更多的是关于状态管理的内容，而不是架构。有了 Flutter，像 MVP 和 MVVM 这样的架构已经没有多大有意义了；咱们再也不使用它们了，而是考虑状态如何流经咱们的应用。状态忽然成为讨论的一个重要部分，咱们将投入愈来愈多精力去思考构建应用的新方法上。这对咱们全部人来讲都是一次新的旅程，有许多事情能够解决，但最重要的是，这是咱们开阔视野的机会。

坦白地说，Flutter 也不仅有阳光和彩虹。我目前正在与 Flutter 合做开展一个更大的项目来了解它的弱点，迄今为止我遇到的最大缺陷是缺少基础设施。当我尝试使用 Graphql-API 时，这个问题就很是明显；虽然有库确实会这样作，但它们并无接近 Android 与 Apollo 的关系。不过，好消息是，Flutter 迎头遇上只是时间的问题，在此期间扩展示有的库，甚至创建本身的库并不困难。请注意，你可能须要花一些时间投入在应用程序的基础设施中，而对于 Android 和 iOS 来讲，状况一般并不是如此 —— 毕竟，天下没有免费的午饭。

最后，我最近从使用 Flutter 中获得的最大启示之一就是，体验这种构建 UI 的声明方式以及它对状态管理的影响是很是有用的。我以为 Flutter 太棒了；不过，我告诫你不要把它看成解决你全部问题的银弹，而应该是做为一种创新的工具，它能够比在 Android 上更快地构建漂亮的自定义 UI。更重要的是，它展现了强大的声明性布局功能，并让你将应用视为渲染状态，而不是非连贯性 Activity，视图和视图模型 —— 仅此而言，我强烈建议你尝试一下 Flutter。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。