我的Android重构之旅：架构篇

我的Android重构之旅：架构篇
我的Android重构之旅：框架篇
我的Android重构之旅：插件化篇

去年10月底来到了新公司，刚开始接手 Android 项目时，发现该项目真的是一团遭，项目开发上没有任何架构可言，开发人员连简单的 MVC、MVP 都不了解，Activity 及其臃肿，业务边界也不明确，因此我决定重新分析一下当前主流的几种开发架构，选出适合当前项目的架构形式。

这是“我的Android重构之旅”的开篇之章，在这一篇中，我将依次的和大家介绍一下 MVVM、MVP、MVC、AndroidFlux 这几种主流的架构设计，本文中不会很深入的分析这些架构的代码上有何区别，只是将它们的设计思路带给大家，让大家更方便的选择在项目适用的架构。

MVC

MVC 简单来说就是将整个应用分为 Model、View 和 Controller 三个部分

• 视图（View）：管理作为位图展示到屏幕上的图形和文字输出。
• 控制器（Controller）：翻译用户的输入并依照用户的输入操作模型和视图。
• 模型（Model）：管理应用的行为和数据，响应数据请求（经常来自视图）和更新状态的指令（经常来自控制器）。

MVC 架构

从上图可以看出来 View 层需要由 Controller 发起事件通知 View 然后 View 从 Model 获取数据，这在 APP 中是较难实现的，我们的事件往往是由 Activity 或 View 发起并主导的，如果将事件的发起与控制权交由 Controller 处理的话经常会出现一些意想不到的问题，如内存泄漏等，这就导致了 MVC 的变种 MVP 的出现，Android 本身的设计还是符合 MVC 架构的，但是 Android 中纯粹作为 View 的 XML 视图功能太弱，我们大量处理 View 的逻辑只能写在 Activity 中，这样 Activity 就充当了 View 和 Controller 两个角色，直接导致 Activity 中的代码大爆炸。相信大多数 Android 开发者都遇到过一个 Acitivty 数以千行的代码情况吧！所以，更贴切的说法是，这个 MVC 结构最终其实只是一个 Model-View（Activity:View&Controller）的结构。

MVP

MVP 架构模式是 MVC 的一个变种，很多框架都自称遵循 MVC 架构模式，但是它们实际上却实现了 MVP 模式。MVC 与 MVP 之间的区别其实并不明显，我认为俩者之间的最大区别就是 View 层可以发起事件。

MVC 架构

在 MVP 中，Presenter 可以理解为松散的控制器，其中包含了视图的 UI 业务逻辑，所有从视图发出的事件，都会通过代理给 Presenter 进行处理，同时，Presenter 也通过视图暴露的接口与其进行通信。

APP 中的应用

在 MVC 中，控制器负责 以不同的视图响应客户端请求的不同动作，然而，不同于 MVC 模式，MVP 中视图将所有的动作交给 Presenter 进行处理，MVC 中的所有的动作都对应着一个控制器的方法调用，Web 应用中的每一个动作都是对某一个 URL 进行的操作，控制器根据访问的路由和方法（GET 等）对数据进行操作，最终选择正确的视图进行返回。

MVC 中控制器返回的视图没有直接绑定到模型上，它仅仅被控制器渲染并且是完全无状态的，其中不包含任何的逻辑，但是 MVP 中的视图必须要将对应的事件代理给 Presenter 执行，否则事件就无法被响应。

上述内容取自 What are MVP and MVC and what is the difference? · Stack Overflow 中的 Model-View-Controller 部分。

从这里可以看出，Presenter 层的出现帮助我们减轻了 Activity 的压力，结构上也较为清晰，但是 View 层将存在较多与 Presenter 沟通的代码这是我们较为不希望看到的结果，MVVM 架构在这种情况下被提了出来。

MVVM

MVVM 架构模式是微软在 2005 年诞生的，第一次进入 Android 人员视野是从 Google 2015 推出 DataBinding 组建开始，后续 Google 不断的推出了 ViewModels、LiveData、Android Loader、Lifecycles 等适用于 MVVM 架构的组件，由此可见 Google 已经“钦定” MVVM 是 Android 开发未来的第一架构了。

MVVM 架构

从 Model-View-ViewModel 这个名字来看，它由三个部分组成，也就是 Model、View 和 ViewModel，其中视图模型（ViewModel）其实就是 PM 模式中的展示模型，在 MVVM 中叫做视图模型。
除了我们非常熟悉的 Model、View 和 ViewModel 这三个部分，在 MVVM 的实现中，还引入了隐式的一个 Binder 层，而声明式的数据和命令的绑定在 MVVM 模式中就是通过它完成的。

Binder 层

MVVM 架构将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致，唯一的区别是，它采用双向绑定（data-binding）View的变动，自动反映在 ViewModel，反之亦然，这就导致了我们如果要完整的采用 MVVM 必须熟练的掌握 DataBinding 等基础组建，这就给我们将 MVVM 引入项目带了困难。

AndroidFlux

AndroidFlux 是 Facebook 的 Flux 架构的 Android 实现。 Flux 是 Facebook 在14年提出的一种 Web 前端架构，主要用来处理复杂的 UI 逻辑的一致性问题（当时是为了解决 Web 页面的消息通知问题）。经过实践之后发现，这种架构可以很好的应用于 Android 平台，相对于其他的 MVC/MVP/MVVM 等模式，拥有良好的文档和更具体的设计，比较适合于快速开发实现。
Flux 模式最大的特点是单向的数据流，它的 UI 状态更新模式继承了 MVC 模式的设计思想。 Flux 并不是具体的框架，而是一套处理 UI 问题的模式， AndroidFlux 同样不是具体的框架，你不需要导入或者集成任何新的代码就可以使用，而你需要做的事情是了解这套思想、遵循这种开发模式。

AndroidFlux 架构

上述内容取自 AndroidFlux QUICK START。

AndroidFlux 的结构设计很容易让我们想到函数式响应编程（functional-reactive-programming），而且 AndroidFlux 一直在强调它自己本身并非某种具体的框架而是一种 UI 或者说数据流的走向，这个很像我们熟知的 RxJava 设计思路，所有事件、UI 都可以当作为一个数据流并加以处理。

AndroidFlux 的数据流动

只有一个Dispatcher

在 AndroidFlux 应用中 Dispatcher 是中心枢纽，管理所有的数据流。它实际上管理的是 Store 注册的一系列回调接口，本身没有其他逻辑 —— 它仅仅是用来把 Action 发送到各个 Store 的一套简单的机制。每个 Store 都会把自己注册到这里，并提供自己的回调方法。当 ActionCreato 给 Dispatcher 传递一个 Action 的时候，应用中所有的 Store 都会通过回调接口收到通知。

随着 App 的增长，Dispatcher 会变得更加重要，它可以通过调整回调方法的触发次序来管理 Store 之间的依赖关系。Store 可以声明等待其他 Store 更新完毕再更新自己。

Stores

Store 包含应用的状态（State）和逻辑（Logic）。它扮演的角色和 MVC 模式中的 Model 类似，但是它会管理多个对象的状态 —— 它不是像 ORM-Model 一样的单独的数据集。Store 负责管理App中一片区域（Domain）的状态，而不是简单的ORM数据集。

由于 AndroidFlux 是一串的语法、结构规范，他并没有什么组件来协助我们开发，所以使用 AndroidFlux 的难度较高，暂时不考虑在中、小型团队中的应用，仅仅作为一个知识拓展。

总结

在架构模式的选用时，我们往往没有太多的发言权，主要因为平台本身往往对应用层有着自己的设计，我们在开发客户端或者前端应用时，只需要遵循平台固有的设计就可以完成应用的开发，不过，在有些时候，由于工程变得庞大、业务逻辑变得异常复杂，我们也可以考虑在原有的架构之上实现一个新的架构以满足工程上的需要。

最终由于项目上人手不足，我们的项目很遗憾只能选择 MVP 进行重构，但是其他的架构也给我们提供了不错的思路如 MVVM 架构中 Google 官方提供的绑定组件，AndroidFlux 将 UI 作为响应式编程的一部分，这些好的地方都值得我们去反复揣摩深入学习，后续的文章将会陆续的和大家一起讨论一下我们在项目重构中经历过的一些问题，以及我们是如何设计出一个相对简单易用的通用开发架构。