Square 開源庫Flow和Mortar的介紹，flowmortar

Square 開源庫Flow和Mortar的介紹，flowmortar

• 原文連結 : Architecting An Investigation into Flow and Mortar
• 譯者 : sundroid( chaossss 協同翻譯)
• 校對者: chaossss、Mr.Simple
• 狀態 : 完成

“在 App 開發過程中儘可能使用 Fragment 替代 Activity”，Google 官方的這個建議無疑讓萬千 Android 開發人員開始關注、使用 Fragment。但隨著使用 Fragment 的人數增多，Fragment 存在的各種問題也開始暴露，在各種 Android 社區中，已經開始有人質疑用 Fragment 替代 Activity 在應用開發中是否真的像 Google 說的那樣有益。質疑 Fragment 的理由大體如下：

• 在使用 Fragment 時，我們只能選擇使用預設的構造方法，而不能自由地構造我們想要的構造方法。

• 嵌套使用 Fragment 很容易出現各種奇奇怪怪的 Bug，抑或是受到種種讓人鬱悶的限制。

• Fragment 自身的生命週期非常複雜。

更讓人哭笑不得的是，讓這部分開發人員堅定地站在“反 Fragment”隊伍中的原因竟然是：在開發過程中使用 Fragment 完全不能讓這部分 Android 開發人員感受到使用 Fragment 能給他們帶來的便利和愉悅；相反，使用 Fragment 給他們帶來的是無盡的困然和煩惱。真不知道 Google 看到這些批評 Fragment 的文章會想什麼…………

但在我們的 Android 學習社區 Big Nerd Ranch 中，我們製作的 Android bootcamp 課程一直堅持使用 Fragment ，並且為大家介紹 Fragment 給我們帶來的種種便利和好處（特別是 Android 開發的新手），此外，我們還在我們做的 資訊項目 中廣泛地使用了 Fragment。

然而，雖然我們是 Fragment 的忠實粉絲，但本著不斷學習和探索新知識的心態，我們還是對現有的 Android 庫進行了相當多的研究和探索，以求能夠找到 Fragment 的最佳替代物，協助這些備受煎熬的 Android 開發人員早日脫離苦海，走向 Android 開發的美麗新世界。

進入Flow和Mortar

奉行著想毀滅世界上所有 Fragment 的信條，Square 大概在一年前介紹了兩個全新的庫： Flow 和 Mortar。作為反 Fragment 教主，Square 還創造了許多很好的庫：

• Dagger
• Retrofit
• Picasso
• Otto
• And so many more

我只想說，我相信他們，我認為任何來自Square的資源可能是有用的或者至少是有趣的，所以他們的項目都值得一看。

在我們深入瞭解這些庫之前我想提醒大家的是，Square只在他們內部的一小部分項目中使用這些庫，並且我在寫本文章時這些庫還在預發布階段。也就是說，這兩個庫在最近幾個月取得了積極的進展，這預示著一個值得尊敬的未來，雖然庫就像流沙，隨時可能改變，崩潰甚至停止發布，但庫所依賴的核心架構原則是一成不變的。

體系架構

首先，我們先來看下 Android 應用的體系架構，在 Android Honeycomb 被使用之前，甚至在Fragment 出現之前，開發 Android 應用的標準模式是建立許多 Activity。在那個時候最常見的現象是：大多數開發人員都沒有規範地遵循 MVC模式進行開發，不過這也很正常。因為模型(Model)依賴於資料，傳統的一些資料庫或者是以 JSON 的形式儲存的 Web 請求，抑或是各種各樣的java對象枚舉。開發人員們很高興地通過 XML 布局去為 Activity 設定 View ，而且 View 的控制器就是每一個螢幕顯示的 Actvitiy 自身。

雖然這隻是一個簡要的概述，但是你能從中瞭解到 Android 與 MVC 模式是如何自然契合的。

隨著 Fragment 在 Honeycomb 中的出現，Android 團隊也讓處理不同形式的事件變得更簡單。到了今天，標準的 Android 應用架構已經轉變為由一小部分的 Activity 和 許多 Fragment 構成，使得我們的 App 能夠在 手機、平板、智能手錶甚至是太空船上跨平台使用。

在這樣的願景下，有關 Fragment 的一切都是美好的，Fragment 變得流行起來，將一個 Activity 分解為幾個 Fragment 是被提倡的。除此以外，即使 Activity 常常被簡化為 Fragment 的持有人，或者是 Fragment 和 系統之間的介面，Android 應用的架構仍然遵循著 MVC 模式。

但到底是 Activity 不能實現我們 App 跨平台使用的願望，還是我們沒有用正確的方式使用 Activity呢？也許，如果將 Activity 與 自訂 View結合在一起使用，說不定不需要 Fragment 就能讓 Activity 實現跨平台使用的目標呢。使用 Flow 和 Mortar庫背後的關鍵目的就是探索這個問題，並得到確切的答案。Flow 和 Mortar 的工作通過用自訂 View 代替 Fragment，並使用注入自訂 View 中的特定 Controller 對象，控制視圖，以此允許我們通過 View 來代替 Fragment 完成工作。

我們將在我們的討論中構建這個圖的中間部分，弄清楚如何在不使用 Fragment 的情況下把不同的視圖片段拼湊到一個 Activity 裡。我們會看著標準MVC架構演變成完全不同的東西，這將大量涉及到咱們的Flow和Mortar。

那麼，Flow和Mortar到底是什嗎？它們又是如何起作用的呢？

Flow

Flow 將一個應用分成一個邏輯上的 Screen組合，Screen不是任何形式的特殊的庫對象，而是一個被創造來代表我們應用視圖的普通java對象（POJO）。每一個Screen是這個app裡面自包含的段，他們有自己的功能和意圖。一個Screen的用處和傳統Activity的用處沒有什麼不同，應用程式中的每一個Screen都對應於一個特定的位置，有點像一個Android中的URL網頁或者是特定的隱式Intent。所以，Screen類可以被看作是應用中某個部分內建的可讀定義。

我們應用中的每一個Activity將會成為一個 Flow 對象，Flow對象在返回棧中儲存了 Screen 的記錄，和 Activity 或者 FragmentManager 的返回棧有些類似，通過這樣的設計允許我們在 Screen 之間通過簡單地執行個體化就可以輕鬆的切換，而不需要在應用中包含很多Activity。這裡有一小部分 Activity（最好是一個）來持有這些 Screen。他們之間的關係類似：

我們我們想切換到一個新的 Screen，我們只需簡單地執行個體化這個 Screen，並且告訴我們 Flow 對象協助我們切換為這個 Screen。除此以外，正如我們所期待的，Flow 被執行個體化後也會實現 goBack() 和 goUp() 方法。然而，許多開發人員都把 Java 中的 goto 語句看作洪水猛獸，但事實上 Java 中的 goto 語句並沒有它聽起來那麼恐怖。

從本質上看，Flow 的作用僅僅是在 App 中告訴我們將要切換到哪一個 Screen。而這樣設計的好處在於，Flow 通過這樣的設計讓我們能夠方便地在我們定義的各種不同的自訂 View 中切換，並使我們免受在 Activity 或 Fragment 需要考慮的種種麻煩，讓我們把注意力都集中在處理 View上。Flow 為我們創造了一個簡單，方便，以 View 為中心的應用架構。

Mortar

Mortar是一個專註拖拽和依賴注入的庫，Mortar 用以下幾個不同的部分將一個應用分為可組合的模組：Blueprints, Presenters and a boatload of custom Views。

Mortar App裡的每一個部分（在這裡指的是每一個 Screen，因為我們在使用 Flow）都由 Blueprint 定義，並賦予他們一個私人的 Dagger 模組。它看起來有點像是下面這樣的

Flow 和 Mortar 結合在一起使用的效果很好，我們只需要調節我們的 Screen 類實現去 Mortar 提供的 Blueprint 介面，然後它就會給我們一個可以自由使用的 Dagger 範圍。

Presenter 是一個擁有簡單生命週期和伴隨其生命週期的 Bundle 的 View 私人對象，主要被用作該 View 的控制器。每一個 View 都有存在於對應的 Screen （還有 Blueprint）中，與 View 自身相關聯的 Presenter。因為 Presenter 只能作用於他所在的 Screen，所以當我們使用 Flow 進入一個新的 Screen，Presenter（在我們這個架構中非常重要的一環） 很可能會被 Java 的記憶體回收機制自動回收掉。此外，在 Mortar 範圍中的 Dagger 將與自動記憶體回收機制結合在一起，使得我們 App 能更好的管理、使用其記憶體——其中原因當然是：當前沒有被使用的控制器對象都被我們回收掉了。而在傳統的 Activity 開發中，Fragment 和 Activity 的切換過程中，不經意的記憶體回收並不能很好的被注意和提防。

由於自訂 View 在我們的架構中被頻繁地使用，以至於我們只需要通過 Dagger 簡單地注入所有重要的模型資料，然後使用與 View 關聯的 Presenter 去控制 View 本身。即使配置被改變，Presenters 也不會消失，而且我們還非常瞭解與 Activity 生命週期相關的知識，使得 Presenters 在進程被殺死之後還能被恢複。事實上，Presenter 與 Activity onSavedInstanceState() 方法的 bundle 鉤連在一起，使得它能夠用與 Activity 相同的機制儲存和讀取配置改變後產生的資料。而 Presenter 的生命週期非常簡單，只有四個回調方法：

• onEnterScope(MortarScope scope)
• onLoad(Bundle savedInstanceState)
• onSave(Bundle outState)
• onExitScope()

完全沒有 Fragment 那樣複雜的生命週期，這可不是我吹的！

There are a lot of moving parts and new terms and classes and all sorts of room for confusion. So in sum, we have the following pieces of the puzzle:

• Screen: A particular location in the application’s navigation hierarchy
• Blueprint: A section of an application with its own Dagger module
• Presenter: A View-controller object
• Custom Views: Views defined by Java and usually some XML

文章寫到這裡，你會發現在 Flow 和 Mortar 中有許多發生改變的部分，新的術語和類，還有新的使用規範，這難免會讓人一頭霧水。所以為了方便大家的理解，總的來說，我們需要重視的是下面幾個部分：

• Screen: 在應用導航階層中的一個特殊存在，用來代表我們視圖的對象
• Blueprint: 應用中具有私人的 Dagger 模組的部分
• Presenter: 一個 View 控制器對象
• Custom Views: 通過 Java 代碼定義的 View，當然，用 XML 定義也是很常見的

Here’s what our final Mortar and Flow architecture looks like:

我們 Mortar 和 Flow 整個體系架構將會如下所示：

Instead of sticking with Model View Controller, the architecture has morphed into more of a Model View Presenter style. The big difference concerns the handling of runtime configuration changes like rotation. In MVC, our Controller (Activities and Fragments) will be destroyed alongside our Views, whereas in MVP, only our View will be destroyed and recreated. Nifty.

拋棄了對 MVC 模式的執念，這個架構在完成之後變得更像 MVP 模式。這樣巨大的轉變使得新的架構需要關注如何處理應用在運行時配置資訊改變的問題，例如：旋轉。在 MVC 模式中，我們的控制器（Activity 和 Fragment）會隨著我們的 View 一起被殺死。然而，在 MVP 模式中，我們只有 View
被殺死，又在需要它的時候重現它。挺有趣的對吧？

積極的反饋

為了擺脫 Fragment，Square 付出了無數的汗水去進行重新架構和設計，並完成了 Mortar 和 Flow庫，他們當然會獲得相應的回報，接下來我就給大家介紹這兩個庫給我們帶來的好處吧。

使用 Mortar 和 Flow 庫強迫我們建立了一個符合 MVP 模式設計的模組化 App 結構，通過這樣做能有效地協助我們保持代碼的整潔。

通過對我們自訂 View 和 Presenters 的依賴注入，測試變得更簡單了

動畫能夠在 View 層被處理，而不用像從前在 Activity 和 Fragment 中使用時那樣擔心動畫會出現Bug

Mortar 在 View 和 Presenter 層中自動進行記憶體回收以處理其範圍，意味著應用能更有效地利用記憶體

可最佳化的空間

儘管 Flow 和 Mortar 給我們帶來了許多好處，但是它們也還存在一些問題：

想要熟練使用 Flow 和 Mortar，需要面對一條陡峭的學習曲線。在你真正理解這兩個庫的設計思想和原理之前，它們的使用模式看起來非常複雜，如果你想要將他們用的得心應手，無疑需要大量的探索和實驗，此外，這些庫並不是為初學者提供的，我們更建議初學者先學習如何正確和有效地使用 Activity 和 Fragment，我可不是嚇唬你們，這樣跟你們說吧，就算是 Android 開發大神，在面對這些庫時仍需要花費大量的精力和時間去學習有關設計模式的知識，才能真正理解這個庫。

如果你正準備使用 Mortar 和 Flow 庫，你真的要全面瞭解它們的用法。因為讓它和標準的“少使用 Fragment”開發模式相互作用是很困難的。如果你想修改一個已經寫好的項目，讓它使用 Mortar 和 Flow，雖然不是不可能的，但是完成這個目標的過程會是非常漫長和艱難的。

這裡還存在無數的模板和配置資訊需要被處理。而這正是我最大的擔憂，在使用這些新的類和介面時，我常常覺得被淹沒在無趣的代碼海洋裡，因為這些代碼都被設計成和其中的各個類、介面鉤連在一起，而這也的設計讓我覺得這兩個庫並沒有像我期待的那樣有趣。

接下來呢

不過現在 Mortar 和 Flow 庫都處於預發布階段，現在也沒有官方發布的版本。這意味著 Square 還在處理這兩個庫存在的問題，改動和更新，但這同樣也意味著它們還需要許多時間作改進，才能真正投入到使用中。

使用 Mortar 和 Flow 庫是個有趣的體驗，我非常享受使用各種新的庫和尋找官方以 Fragment 為導向的應用結構的替代品，但我並不認為 Mortar 和 Flow 是 Android 尋找的替代 Fragment 的辦法，畢竟 Fragment 可能在接下來的幾個月或者幾年中被修改。但我仍然希望這些項目能夠引起更多人關注，並且繼續最佳化，我肯定會繼續關注他們的最新進展的，希望大家繼續關注我的部落格哦。