个人Android重构之旅：架构篇

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

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

MVC

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

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

从上图能够看出来 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 层能够发起事件。

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

在 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 开发将来的第一架构了。

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

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 QUICK START。

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

只有一个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 做为响应式编程的一部分，这些好的地方都值得咱们去反复揣摩深刻学习，后续的文章将会陆续的和你们一块儿讨论一下咱们在项目重构中经历过的一些问题，以及咱们是如何设计出一个相对简单易用的通用开发架构。

做者：杀鱼能手小耗子
连接：https://www.jianshu.com/p/71c...

阅读更多

react-native技术的优劣*

学习React Native必看的几个开源项目

开发了几个小程序后，说说我对小程序的见解

NDK项目实战—高仿360手机助手之卸载监听

（Android）面试题级答案（精选版）

若是有什么 问题，欢迎随时撩我