MVC与MVP比较
MVC_MVP.png
相同点：
- View：Activity&Fragment(为省事后文只说Activity啦) + layout xml，职责是显示信息和响应用户操作；
- Model：提供数据的增删改查操作，并通过回调方法把结果反馈出去；数据位置是抽象过的，可能在本地或远程
不同点：
MVC模式
Activity还担当了Controller角色，这样职责又再增加：执行业务逻辑、调用Model操作数据以及把操作结果更新到界面上。
Activity=View+Controller，带来的问题：
- 违背单一职责原则，界面操作和业务逻辑混在一起；
- 业务逻辑原本是与平台无关的抽象，现在和安卓界面捆在一起，没法单元测试了
太Low了，让Presenter来主持大局吧
MVP模式：新增Presenter
-
职责：体现抽象的业务逻辑、调用Model操纵数据、调用View刷新显示和展示信息、响应用户操作
-
Activity的Controler职责废除，由Presenter接手
Activity大大简化
1) 只由Presenter派活儿，被动显示信息 2) 用户操作直接传递给Presenter处理 3)与Model断交，两者互不相认
MVPArms架构实践
问题.Presenter怎么依赖View和Model
Presenter是平台无关的，是抽象的，View和Model是平台相关的，是具体的；既然不能直接依赖，那就需要把View和Model抽象为接口；
google官方todo-mvp是提供一个Contract接口，包含View和Presenter子接口
MVPArms的做法是在Contract接口中包含View和Model子接口；
至于Presenter是否需要抽取为接口，网上颇有争论，后文再聊
问题.类太多啦
嗯，让我们算一下有哪些类和接口
类：Activity, Presenter, Model,
接口：Contract(View、Model)
再加上Dagger需要的Module, Component；吓死宝宝了！
类多对这个问题要理性看待，只要职责清晰不重复，从解耦角度看反而是正面的，不是问题；
当然人都是懒的，工作量太多了怎么办？MVPArms模板出动，全家桶一次创建好
问题：职责细分后对象间的依赖怎么办？让Dagger来
原本Activity的一大块工作，现在被Presenter承包了，起码要创建Presenter吧，此外Presenter和Model也是需要资源才能干活的，比如：application context，adapter等等，这样多出了这些事情要做：
-
activity中创建new presenter，presenter中创建model
-
presenter增加setXXX，setYYY, setZZZ，给activity调用以传递资源
-
model可能也要增加setXXX,setYYY，给presenter调用；
一堆无聊的代码！
你会说不用啊，大部分资源都是全局的，做成单例直接XXX.getInstance就行了，但还是有很多资源不是单例的，而且本身单例模式对单元测试就不友好。
好了，该Dagger登场了，不用再手工创建presenter，也不用setXXX了，全局资源也不用写成单例了，标注为@Singleton再通过AppComponent注入就行
不过Dagger这货确实不直观，需要挺多学习成本，但是值得。
Dagger解惑
-
DI容器和入口
activity,fragment和Application是常用的DI容器。注入入口是：
DaggerUserComponent.builder() .appComponent(appComponent) // MVPArms在此处传入App全局依赖 .userModule(new UserModule(this)) .build() .inject(this);这句调用完以后，带有@Inject注解的字段(Presenter、Model、Adapter等)都会被赋值；
-
Scope和单例生命周期:
普通单例同类的static变量引用，即一个进程中只有一个单例对象；
如果把普通单例说成是全局单例，则dagger Scope修饰出来的单例，是局部单例。
对，这几个Scope作用没有区别，一毛一样：@Singleton @Activity @Fragment
至于被Scope修饰实例的生命周期，则跟随其所属Component：
- Component在activity,fragment中创建：生命周期和activity,fragment一样
- Component在Application中创建：生命周期和app一样长
RxJava:遇见更好的Model
Model的方法举例，调用者是P层：
// 不采用RxJava
void getUser(int idStart, int count, Callback<List<User>> resultCallback);
// 采用RxJava
Observable<List<User>> getUser(int idStart, int count);
采用RxJava后，返回值变为Obserable<XXX>，由于Obserable天然的数据流属性，带来了以下好处：
-
不用Callback了，P层subscribe就行
-
返回值更直观，一目了然
-
Obserable可以自如的切换线程，这样可以把切换线程操作放到P层，Model层方法更简洁
-
Obserable可以进行灵活的变换操作，比如
-
如果网络返回值是包装过的，而非直接是一个List<User>时，可以做map变换，取出map
-
如果网络报错提示token过期，可以做flatMap变换，插入一个login，然后再次getUser
这两种情况用传统Callback方式也能搞定，但嵌套callback远不如Rx分步流水线优雅
-
RxJava 结合Model场景
-
网络
必须是retrofit了，带上RxJavaCallAdapter；
再加上RxCache，则一并搞定缓存读写，RxCache是挺方便的，但功能并不全面，比如要强制读缓存就不行，需要二次开发
-
数据库
这部分MVPArms没有封装；能想到的理想方案是RxJava结合Room，等到有实践再经验再补充；
让Presenter和Model感知ActivityLifeCycle
使用 2017 Google IO 发布的 Architecture Components 中的 Lifecycles 的新特性 (此特性已被加入 Support library)，使Presenter和Model可以感知SupportActivity和Fragment的生命周期；
MVPArms 怎么做到的，上Code:
public class BasePresenter<M extends IModel, V extends IView>
implements IPresenter, LifecycleObserver {
@Override
public void onStart() {
//将 LifecycleObserver 注册给 LifecycleOwner 后 @OnLifecycleEvent 才可以正常使用
if (mRootView != null && mRootView instanceof LifecycleOwner) {
((LifecycleOwner) mRootView).getLifecycle().addObserver(this);
if (mModel!= null && mModel instanceof LifecycleObserver){
((LifecycleOwner) mRootView).getLifecycle().addObserver((LifecycleObserver) mModel);
}
}
}
这样Presenter可以主动执行操作，不需要通过Activity来启动了，比如：
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
void onCreate() {
requestUsers(true);//打开 App 时自动加载列表
}
这段代码是在Activity.onCreate()后面执行
Contact中是否要写Presenter接口
这个问题存在争论，google todo-mvp-exmaple是写了P接口的；
Contract中包含MVP三个接口，看起来是比较清晰了，但在MVPArms框架中，P接口没有必要存在：
- 没有任何地方需要用到，P接口存在反而会让人迷惑：Activity类的Presenter泛型参数到底填P接口还是P类呢，实际填P接口会导致BaseActivity的mPresenter对象Dagger编译报告MissBinding；既然这么尴尬，还是不要写P接口了吧
- 另一个不写P接口的理由是：Activity所依赖的P已经是抽象的业务逻辑了，没有必要再多做抽象
认为要写P接口的人，一般都用这个理由：看起来P暴露给View的接口方法更清晰。
能懒则懒，我喜欢不写。
其它问题
-
Presenter重用问题
网友评论