[譯] 爲何每一個 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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。