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

  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/article/details/51733361
Google推出的基于MVP架构的demo,基于此架构我在GitHub上开源了一个项目MinimalistWeather
Android MVP框架MVPro的使用和源码分析- http://blog.csdn.net/qibin0506/article/details/49992897
浅谈Andorid开发中的MVP模式- http://blog.csdn.net/loongggdroid/article/details/50592777

Android官方MVP架构解读：http://blog.csdn.net/ljd2038/article/details/51477475
MVP sample: https://github.com/googlesamples/android-architecture

  MVP模式是MVC模式的一个演化版本，MVP全称Model-View-Presenter。目前MVP在Android应用开发中越来越重要了。
在Android中，业务逻辑和数据存取是紧紧耦合的，很多缺乏经验的开发者很可能会将各种各样的业务逻辑塞进某个Activity、Fragment或者自定义View中，这样会使得这些组件的单个类型臃肿不堪。如果不将具体的业务逻辑抽离出来，当UI变化时，你就需要去原来的View中抽离具体业务逻辑，这必然会很麻烦并且易出错。
 -- 使用MVP的好处
（1）MVP模式会解除View与Model的耦合，有效的降低View的复杂性。同时又带来了良好的可扩展性、可测试性，保证系统的整洁性和灵活性。
（2）MVP模式可以分离显示层与逻辑层，它们之间通过接口进行通信，降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面，因为它们之间并不依赖与具体，而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，使之具有更广泛的适用性，保证了灵活度。
 -- MVP模式的三个角色
（1）Presenter – 交互中间人：Presenter主要作为沟通View与Model的桥梁，它从Model层检索数据后，返回给View层，使得View与Model之间没有耦合，也将业务逻辑从View角色上抽离出来。
（2）View – 用户界面：View通常是指Activity、Fragment或者某个View控件，它含有一个Presenter成员变量。通常View需要实现一个逻辑接口，将View上的操作转交给Presenter进行实现，最后，Presenter 调用View逻辑接口将结果返回给View元素。
（3）Model – 数据的存取：Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据，Model就像一个数据仓库。更直白的说，Model是封装了数据库DAO或者网络获取数据的角色，或者两种数据方式获取的集合。

 -- MVP存在的问题:
  尽管已经有了大量的应用，但不可否认该模式的还是存在一些问题，这些问题在携程的使用过程中也得到了体现。比如，上下文丢失问题，生命周期问题，内存泄露问题以及大量的自定义接口，回调链变长等问题。可以归纳为：
  1.业务复杂时，可能使得Activity变成更加复杂，比如要实现N个IView，然后写更多个模版方法。
  2.业务复杂时，各个角色之间通信会变得很冗长和复杂，回调链过长。
  3.Presenter处理业务，让业务变得很分散，不能全局掌握业务，很难去回答某个业务究竟是在哪里处理的。
  4.用Presenter替代Controller是一个危险的做法，可能出现内存泄漏，生命周期不同步，上下文丢失等问题。

> MVVM

   MVVM与MVP非常相似，唯一区别是View和Model进行双向绑定，两者之间有一方发生变化则会反应到另一方上。MVVM模式有点像ListView与Adapter、数据集的关系，当数据集发生变化时，调用Adapter的notifyDataSetChanged之后View就直接更新，同时它们之间又没有耦合，使得ListView变得更加灵活。

DataBindingDemo- https://github.com/dragonjiang/DataBindingDemo

> MVC与MVP的区别：

MVP中View不能直接访问Model，需要通过Presenter发出请求，View与Model不能直接通信。

> MVP与MVVM 的区别

    MVP与MVVM都是Android中比较好的应用架构模式，它们的优点都是能够降低耦合，提升应 用模块的可测试性，并且能够在一定程度上避免过于复杂的Fragment、Activity类型，使得整个软件架构变得更为简单、清晰。它们缺点主要是职责分得比较细，这样必然会产生很多类型。例如一个Activity，需要有Model、View、Presenter三个元素，这三个元素又要分接口、实现类，页面- 多各种Model、View、Presenter类型就繁杂起来。当然，通过合理的分包也能够在一定程度上缓解这个问题带来的负面影响。因 此，只要你想让你的应用架构更灵活、可扩展、易测试，MVP、MVVM都是很好的选择。

Android App的设计架构：MVC,MVP,MVVM与架构经验谈- https://www.cnblogs.com/wytiger/p/5305087.html
android中的MVC,MVP和MVVM模式简单总结- https://blog.csdn.net/kaikevin01/article/details/78797700
 1.MVC
View：对应于xml布局文件
Model：实体模型
Controllor：对应于Activity业务逻辑，数据处理和UI处理
xml的view功能太过于弱化，导致actvity里面即处理业务逻辑，又处理view。这样activity的类的代码比较长。

 2.MVP
View:对应于Activity和xml，负责View的绘制以及与用户交互
Model:依然是实体模型
Presenter: 负责完成View于Model间的交互和业务逻辑
用得比较多，把视图操作和业务逻辑分开来。复杂的业务同时会导致presenter层太大，代码臃肿的问题。通过UI事件的触发对数据进行处理。activity需要编写大量的事件。通过事件调用presenter的业务处理方法。UI改变后牵扯的逻辑耦合度太高。View和Presenter只是互相持有引用并互相做回调,代码不美观。

 3.MVVM
View:对应于Activity和xml，负责View的绘制以及与用户交互
Model:实体模型
ViewModel:负责完成View于Model间的交互,负责业务逻辑
数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)