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 中切换，并使我们免Mortar是一个专注拖拽和依赖注入的库，Mortar 用以下几个不同的部分将一个应用分为可组合的模块：Blueprints, Presenters and a boatload of custom Views。

Mortar

Mortar App里的每一个部分（在这里指的是每一个 Screen，因为我们在使用 Flow）都由 Blueprint 定义，并赋予他们一个私有的 Dagger 模块。它看起来有点像是下面这样的受在 Activity 或 Fragment 需要考虑的种种麻烦，让我们把注意力都集中在处理 View上。Flow 为我们创造了一个简单，方便，以 View 为中心的应用架构。

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 那样复杂的生命周期，这可不是我吹的！

文章写到这里，你会发现在 Flow 和 Mortar 中有许多发生改变的部分，新的术语和类，还有新的使用规范，这难免会让人一头雾水。所以为了方便大家的理解，总的来说，我们需要重视的是下面几个部分：

Screen: 在应用导航层次结构中的一个特殊存在，用来代表我们视图的对象
Blueprint: 应用中具有私有的 Dagger 模块的部分
Presenter: 一个 View 控制器对象
Custom Views: 通过 Java 代码定义的 View，当然，用 XML 定义也是很常见的

抛弃了对 MVC 模式的执念，这个架构在完成之后变得更像 MVP 模式。这样巨大的转变使得新的架构需要关注如何处理应用在运行时配置信息改变的问题，例如：旋转。在 MVC 模式中，我们的控制器（Activity 和 Fragment）会随着我们的 View 一起被杀死。然而，在 MVP 模式中，我们只有 View 被杀死，又在需要它的时候重现它。