MVC设计模式是什么？怎么理解？

什么是MVP

View ：是指显示数据并且和用户交互的层。在安卓中，它们可以是一个Activity，一个Fragment，一个android.view.View或者是一个Dialog。

Model ：是数据源层。比如数据库接口或者远程服务器的api。

Presenter：是从Model中获取数据并提供给View的层，Presenter还负责处理后台任务。

MVP是一个将后台任务和activities/views/fragment分离的方法，让它们独立于绝大多数跟生命周期相关的事件。这样应用就会变得更简单，整个应用的稳定性提高10倍以上，代码也变得更短，可维护性增强，程序员也不会过劳死了~~。

为什么要在安卓上使用MVP原因一: 尽量简单

如果你还没有阅读过这篇文章，阅读它: Kiss原则(https://people.apache.org/%7Efhanik/kiss.html)。- kiss是Keep It Stupid Simple或者Keep It Simple, Stupid的缩写。

.绝大多数的安卓程序都只使用了View-Model架构。

.程序员被绞尽了复杂的界面开发中，而不是解决事务逻辑。

在应用中使用Model-View的坏处是“每个东西之间都是相互关联的”如下图:

如果上面的图解看起来还不够复杂，那么想想这些情况：每个view可能在任意的时间出现或者消失，view数据需要保存与恢复，在临时的view上挂载一个后台任务。

而与“每个东西之间都是相互关联的”的相反选择是使用一个万能对象（god object）。注：god object是指一个对象/例程在系统中做了太多的事情，或者说是有太多不怎么相关的事情放在一个对象/例程里面来完成。

god object过于复杂，他的不同部分无法重用、测试，无法轻易的debug和重构。

使用MVP

复杂的任务被分割成简单的任务。

.更小的对象，更少的bug。

.更好测试

MVP的view层变得如此简单，在请求数据的时候甚至不需要使用回调。view的逻辑变得非常直接。

原因二: 后台任务

当你需要写一个Activity，Fragment或者一个自定义View的时候，你可以将所有和后台任务相关的方法放在一个外部的或者静态的类中。这样你的后台任务就不会再与Activity相关联，不会在泄漏内存同时也不会依赖于Activity的重建。我们称这样的一个类为“Presenter”。注：要理解此话的含义最好先看懂第一个MVP示例的代码。

虽然有一些方法可以解决后台任务的问题，但是没有一种和MVP一样可靠。

为什么这是可行的

下面的图解显示了在configuration改变或者发生out-of-memory事件的情况下应用的不同部分所发生的事情。每一个开发者都应该知道这些数据，但是这些数据并不好发现。

|    Case 1     |   Case 2     |    Case 3

|A configuration| An activity  |  A process

|   change      |   restart    |   restart

---------------------------------------- | ------------- | ------------ | ------------

Dialog                                   |     reset     |    reset     |    reset

Activity, View, Fragment                 | save/restore  | save/restore | save/restore

Fragment with setRetainInstance(true)    |   no change   | save/restore | save/restore

Static variables and threads             |   no change   |   no change  |    reset

情景1：configuration的改变通常发生在旋转屏幕，修改语言设置，链接外部的模拟器等情况下。要知道更多的configuration change事件请阅读：configChanges（developer.android.com/reference/android/R.attr.html#configChanges）。

情景2：Activity的重启发生在当用户在开发者选项中选中了“Don't keep activities”（“中文下为 不保留活动”）的复选框，然后另一个Activity在最顶上的时候。

情景3：进程的重启发生在应用运行在后台，但是这个时候内存不够的情况下。

结论

现在你可以发现，一个拥有setRetainInstance(true)的Fragment并没有带来帮助 - 我们还是要保存和/恢复这种fragment的状态。因此我们可以去掉可保持Fragment的情景，把问题简单化。Occam's razor（https://en.wikipedia.org/wiki/Occam%27s_razor）