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

我們應(yīng)用中的每一個Activity將會成為一個 Flow 對象，F(xiàn)low對象在返回棧中保存了 Screen 的記錄，和 Activity 或者 FragmentManager 的返回棧有些類似，通過這樣的設(shè)計允許我們在 Screen 之間通過簡單地實例化就可以輕松的切換，而不需要在應(yīng)用中包含很多Activity。這里有一小部分 Activity（最好是一個）來持有這些 Screen。他們之間的關(guān)系下圖類似

如果我們想切換到一個新的 Screen，我們只需簡單地實例化這個 Screen，并且告訴我們 Flow 對象幫助我們切換為這個 Screen。除此以外，正如我們所期待的，F(xiàn)low 被實例化后也會實現(xiàn) goBack() 和 goUp() 方法。然而，許多開發(fā)者都把 Java 中的 goto 語句看作洪水猛獸，但事實上 Java 中的 goto 語句并沒有它聽起來那么恐怖。

從本質(zhì)上看，F(xiàn)low 的作用僅僅是在 App 中告訴我們將要切換到哪一個 Screen。而這樣設(shè)計的好處在于，F(xiàn)low 通過這樣的設(shè)計讓我們能夠方便地在我們定義的各種不同的自定義 View 中切換，并使我們免Mortar是一個專注拖拽和依賴注入的庫，Mortar 用以下幾個不同的部分將一個應(yīng)用分為可組合的模塊：Blueprints, Presenters and a boatload of custom Views。

Mortar

Mortar App里的每一個部分（在這里指的是每一個 Screen，因為我們在使用 Flow）都由 Blueprint 定義，并賦予他們一個私有的 Dagger 模塊。它看起來有點像是下面這樣的受在 Activity 或 Fragment 需要考慮的種種麻煩，讓我們把注意力都集中在處理 View上。Flow 為我們創(chuàng)造了一個簡單，方便，以 View 為中心的應(yīng)用架構(gòu)。

Flow 和 Mortar 結(jié)合在一起使用的效果很好，我們只需要調(diào)節(jié)我們的 Screen 類實現(xiàn)去 Mortar 提供的 Blueprint 接口，然后它就會給我們一個可以自由使用的 Dagger 作用域。

Presenter 是一個擁有簡單生命周期和伴隨其生命周期的 Bundle 的 View 私有對象，主要被用作該 View 的控制器。每一個 View 都有存在于對應(yīng)的 Screen （還有 Blueprint）中，與 View 自身相關(guān)聯(lián)的 Presenter。因為 Presenter 只能作用于他所在的 Screen，所以當(dāng)我們使用 Flow 進入一個新的 Screen，Presenter（在我們這個架構(gòu)中非常重要的一環(huán)） 很可能會被 Java 的垃圾回收機制自動回收掉。此外，在 Mortar 作用域中的 Dagger 將與自動垃圾回收機制結(jié)合在一起，使得我們 App 能更好的管理、使用其內(nèi)存——其中原因當(dāng)然是：當(dāng)前沒有被使用的控制器對象都被我們回收掉了。而在傳統(tǒng)的 Activity 開發(fā)中，F(xiàn)ragment 和 Activity 的切換過程中，不經(jīng)意的垃圾回收并不能很好的被注意和提防。

由于自定義 View 在我們的架構(gòu)中被頻繁地使用，以至于我們只需要通過 Dagger 簡單地注入所有重要的模型數(shù)據(jù)，然后使用與 View 關(guān)聯(lián)的 Presenter 去控制 View 本身。即使配置被改變，Presenters 也不會消失，而且我們還非常了解與 Activity 生命周期相關(guān)的知識，使得 Presenters 在進程被殺死之后還能被恢復(fù)。事實上，Presenter 與 Activity onSavedInstanceState() 方法的 bundle 鉤連在一起，使得它能夠用與 Activity 相同的機制儲存和讀取配置改變后產(chǎn)生的數(shù)據(jù)。而 Presenter 的生命周期非常簡單，只有四個回調(diào)方法：

onEnterScope(MortarScope scope)
onLoad(Bundle savedInstanceState)
onSave(Bundle outState)
onExitScope()
完全沒有 Fragment 那樣復(fù)雜的生命周期，這可不是我吹的！

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

Screen: 在應(yīng)用導(dǎo)航層次結(jié)構(gòu)中的一個特殊存在，用來代表我們視圖的對象
Blueprint: 應(yīng)用中具有私有的 Dagger 模塊的部分
Presenter: 一個 View 控制器對象
Custom Views: 通過 Java 代碼定義的 View，當(dāng)然，用 XML 定義也是很常見的

拋棄了對 MVC 模式的執(zhí)念，這個架構(gòu)在完成之后變得更像 MVP 模式。這樣巨大的轉(zhuǎn)變使得新的架構(gòu)需要關(guān)注如何處理應(yīng)用在運行時配置信息改變的問題，例如：旋轉(zhuǎn)。在 MVC 模式中，我們的控制器（Activity 和 Fragment）會隨著我們的 View 一起被殺死。然而，在 MVP 模式中，我們只有 View 被殺死，又在需要它的時候重現(xiàn)它。