从只会实现功能的“码农”到软件工程师、设计师的过渡。

  MVP/MVVM架构的优点和缺点？它的使用场景是什么？
  MVC是一种框架模式而非设计模式，GOF把MVC看作是3种设计模式：观察者模式、策略模式与组合模式的合体，而核心是观察者模式。简而言之，框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。

-- 我对移动端架构的思考- https://mp.weixin.qq.com/s?__biz=MzIwMTAzMTMxMg==&mid=2649492922&idx=1&sn=429b586ca376f3b532126b56185efb28&chksm=8eec8645b99b0f53f4ab12338703124f34909042822d8e2c2aea219df43180fef764205bde2b&scene=38#wechat_redirect
移动端架构的差异化体现在通信机制上。通信机制主要分为3种：
1）对象持有 对象持有最简单，但是解耦率最低；
2）接口持有 接口持有较为复杂，实现解耦的需求，但是解耦不彻底，相互持有交互方的接口；
3）路由 路由机制可以实现完全解耦，实现组件化。

-- MVP的问题在于，由于我们使用了接口的方式去连接view层和presenter层，这样就导致了一个问题，如果你有一个逻辑很复杂的页面，你的接口会有很多，十几二十个都不足为奇。想象一个app中有很多个这样复杂的页面，维护接口的成本就会非常的大。这个问题的解决方案就是你得根据自己的业务逻辑去斟酌着写接口。你可以定义一些基类接口，把一些公共的逻辑，比如网络请求成功失败，toast等等放在里面，之后你再定义新的接口的时候可以继承自那些基类，这样会好不少。
  MVVM的问题呢，其实和MVC有一点像。data binding框架解决了数据绑定的问题，但是view层还是会过重。
  MVP+data binding，我们可以使用presenter去做和model层的通信，并且使用data binding去轻松的bind data。

 最佳实践都是人想出来的，用这些框架根本的原因也是为了尽量低的耦合性和尽量高的可复用性。
 activity在MVVM中应该是view层的，但是里面却和MVC一样写了对model的处理。有人会说你可以把对model的处理放到viewmodel层中，这样不是更符合MVVM的设计理念吗？这样确实可以，但是progressDialog的show和dismiss呢？你怎么在viewmodel层中控制？这是view层的东西啊，而且在xml中也没有，我相信会有解决的方案，但是我们有没有一种更加便捷的方式呢？
  MVP和MVVM在分解app使其模块化方面都比MVC更好，但它们也带来了复杂性。对于一个只有一两个界面的app，MVC可以很好地工作。MVVM的数据绑定很吸引力，它是更灵活的编程模式并且可以写更少的代码。

  架构设计的目的：通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题。但设计不能违背目的，对于不同量级的工程，具体架构的实现方式必然是不同的，切忌犯为了设计而设计，为了架构而架构的毛病。

MVC与MVP两种模式的主要区别：
 1.（最主要区别）View与Model并不直接交互，而是通过与Presenter交互来与Model间接交互。而在MVC中View可以与Model直接交互
 2.通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。而Controller是基于行为的，并且可以被多个View共享，Controller可以负责决定显示哪个View
 3.Presenter与View的交互是通过接口来进行的，更有利于添加单元测试。

MVP的优点如下：
 1、模型与视图完全分离，我们可以修改视图而不影响模型；
 2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
 3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
 4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。

> MVC

  MVC全称是Model - View - Controller，是模型(model)－视图(view)－控制器(controller)的缩写。MVC是一种框架模式而非设计模式，GOF把MVC看作是3种设计模式：观察者模式、策略模式与组合模式的合体，而核心是观察者模式。简而言之，框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。
a.MVC的优点：
（1）首先就是理解比较容易，技术含量不高，这对开发和维护来说成本较低也易于维护与修改。
（2）耦合性不高，表现层与业务层分离各司其职，对开发来说很有利。所谓耦合性就是模块代码之间的关联程度。利用MVC框架使得View（视图）层和Model（模型）层可以很好的分离，这样就达到了解耦的目的，所以耦合性低，减少模块代码之间的相互影响。

  (3)可扩展性好。由于耦合性低，添加需求，扩展代码就可以减少修改之前的代码，降低bug的出现率。
  (4)模块职责划分明确。主要划分层M,V,C三个模块，利于代码的维护。
b.MVC的缺点：
（1）完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
（2）对于小项目，MVC反而会带来更大的工作量以及复杂性。

-- MVC在Android中的应用
  Android中对MVC的应用很经典，在Android中视图View层一般采用XML文件进行界面的描述。
而对于模型Model部分则大多对应于本地的数据文件或网络获取的数据体，很多情况下我们对这些数据的处理也会在这一层中进行。最后的控制器Controller则当之无愧的是右Activity承担。
  虽说上面的介绍中我们感受到Android在MVC方面的结构，但是，这个框架并非我们自己完成的，而是由framework给我们搭建好的并提供给我们，在平时的开发中，特别是用Android开发，我们并不常用到MVC模式去脱离Android UI系统构建自己的框架结构。

使用 MVC，把业务逻辑抽离到 Controller 中，让 View 层专注于显示 UI。
  Android中对MVC的应用很经典，在Android中视图View层一般采用XML文件进行界面的描述。如下例子：
<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="50dp"
    android:id="@+id/list_item_text"
    android:textSize="16sp"
    android:gravity="left|center_vertical"
    android:padding="10dp" />
  而对于模型Model部分则大多对应于本地的数据文件或网络获取的数据体，很多情况下我们对这些数据的处理也会在这一层中进行。最后的控制器Controller则当之无愧的是由Activity承担。

-- MVC存在的问题:
  View强依赖于Model是MVC的主要问题。由此导致很多控件都是根据业务定制，从Android的角度来看，原本可以由一个通用的layout就能实现的控件，由于要绑定实体模型，现在必须要自定义控件，这导致出现大量不必要的重复代码。因此有必要将View和Model进行解耦，而MVP的主要思想就是解耦View和Model。由此引入MVP就显得很自然。

> MVP

-- MVP 与Activity、Fragment的生命周期
  由于Presenter 经常性的持有Activity 的强引用，如果在一些请求结束之前Activity 被销毁了，那么Presenter 一直持有Activity 对象，使得Activity 对象无法回收，此时就会发生内存泄露。那么解决方法就是采用弱引用和Activity、Fragment的生命周期来解决这个问题。

TheMVP- https://github.com/kymjs/TheMVP

与mvp相关的开源项目：https://github.com/yaozs/YzsBaseActivity  https://github.com/yaozs/YzsLib
框架模式MVC与MVP在Android中的应用: http://blog.csdn.net/gjnm820