最近阅读项目的源码，发现项目中有MVP的痕迹，但是自己却不能很好地理解相关的代码实现逻辑。主要原因是自己对于MVP的理解过于概念话，还没有真正操作过。本文打算分析一个MVP的简单实例，帮助自己更好的理解MVP的内在思想。
对于什么是MVP，MVP和MVC的区别，MVP的有点，大家可以参考这篇文章：MVP 模式简单易懂的介绍方式。文章里面还有demo，可以帮助大家更好的理解。
今天分析的是一个别人写的 demo，其实作者也有写文章来介绍（Android MVP with Fragment and RecyclerView），那我为何还要自己来分析一遍呢？其实我已经仿照这个 demo 将 MVP 的思想用到了自己写的一个 demo 上。但是，时间长了，又忘记了，所以打算梳理下。当然，文章肯定不会跟作者的文章一样，得提出自己的思想。并且还对 demo 进行改造优化，使其更加符合MVP的思想。
推荐先看前面两篇文章，再来看本文，这样能更好的理解文章的内容。
代码结构简析
首先我们来看代码的结构图。 从中可以看到有6个文件夹，与 MVP 模式相关的是后面三个文件夹。model 中存放的是与数据相关的类。Picture 是数据 model，其他几个类是负责下载Picture获取数据的。Presenter 中会引入 model 和 view 的引用，以此来控制 model 和 view。View中只有一个 PictureView 类，但是严格说来，应该把 PictureFragment 和 PictureAdapter 也放在文件夹 view 中，但是这样放也是可以的。
实现逻辑
总体概要
这个项目要做的事情很简单，就是从网络下载图片，显示在手机上，点击图片，弹出一个 Toast。
思路分析
MVP ？在这里 M 不就是图片，所以肯定会有一个 Picture 实体类。图片需要下载，因此，还要建立一个类用来控制，但是最终的调用下载是在 P 中。
那 V ？就是 Fragment 啦，由 recyclerView 和 ProgressBar 构成的。PictureView 是一个接口，用于控制图片的展示等。但是也是在 P 中调用。
最后就是 P 啦，封装了对 M, V 的操作，即 PicturePresenterImpl 这个类。
代码实现
M的实现（只贴重要的代码）：
public class PictureInteractorImpl implements PictureInteractor {
private final static String[] pictureNames = {
"Rocket in the universe",
"A scene in London",
"Moon over mountains",
"A simple moon",
"Sun and volcano",
"A collection of mountains",
"River between mountains",
"Some pine trees",
"On Small Town",
"Volcanos reflection"
};
private final static int pictureImages[] = {
R.drawable.cohete_flat,
R.drawable.london_flat,
R.drawable.material_flat,
R.drawable.moon_flat,
R.drawable.mountain_flat,
R.drawable.mountain_mo_flat,
R.drawable.moutain_go_flat,
R.drawable.pine_flat,
R.drawable.towers_flat,
R.drawable.vulcan_flat
};
@Override
public void loadPictures(final LoaderListener listener) {
new Handler(Looper.getMainLooper())
.postDelayed(new Runnable() {
@Override
public void run() {
listener.onFinish(createPictures());
}
}, 2000);
}
private List<Picture> createPictures() {
ArrayList<Picture> pictures = new ArrayList<>();
for (int i = 0; i < pictureNames.length; i++) {
pictures.add(new Picture(pictureNames[i], pictureImages[i]));
}
return pictures;
}
}
大家看上面的代码，只有 loadPictures 是来自于接口的，为啥 createPictures 方法不写在接口里呢？主要是因为写在接口的方法是要在 P 中调用的。如果不需要外部调用，就没必要接口里面了。
V 的实现（只贴重要的代码）：
public interface PictureView {
void showProgressBar();
void hideProgressBar();
void showMsg(String msg);
void showPictures(List<Picture> pictures);
}
虽然 View 中只有 PictureView 一个类，但是从这个类可以对 view 要做的事一清二楚。
P 的实现（只贴重要的代码）：
public class PicturePresenterImpl implements PicturePresenter, LoaderListener {
private PictureView mPictureView;
private PictureInteractor mInteractor;
public PicturePresenterImpl(PictureView pictureView) {
this.mPictureView = pictureView;
mInteractor = new PictureInteractorImpl();
}
@Override
public void onResume() {
mPictureView.showProgressBar();
mInteractor.loadPictures(this);
}
@Override
public void onDestroy() {
mPictureView = null;
}
@Override
public void onItemClick(int pos) {
mPictureView.showMsg(String.valueOf(pos));
}
@Override
public void onFinish(List<Picture> pictures) {
mPictureView.hideProgressBar();
mPictureView.showPictures(pictures);
}
}
可以看出来，P 中其实就是对 M，V 的逻辑进行了封装，统一由其来掌控。
最后来讲讲 fragment，内部引入了 P 。主要是由于 P 无法控制生命周期，所以需要借用 fragment 的生命周期来对整个过程进行控制。
疑问？
大家看了上面的demo，不觉得在 fragment 中，即夹杂着 V， 又有 P，这样其实不利于维护，尤其是后期当 view 越来越多的时候，那时候，还要把 view 的初始化等等都写在 fragment 中嘛？所以接下去要对 fragment 内容进行瘦身。那怎么瘦身呢？具体请看下文。
改造
改造后的结构，只在 view 中新建了一个 BasePageView 来处理 view 的初始化和控制逻辑。
其代码具体如下：
public class BasePageView extends FrameLayout implements PictureView {
private RecyclerView mRecyclerView;
private ProgressBar mProgress;
private PictureAdapter mAdapter;
private PicturePresenter mPresenter;
private Context mContext;
/**
* 构造函数。
*/
public BasePageView(Context context){
this(context, null);
};
public BasePageView(Context context, AttributeSet attributeSet) {
this(context, attributeSet, 0);
}
public BasePageView(Context context, AttributeSet attributeSet, int defStyleAttr){
super(context, attributeSet, defStyleAttr);
init(context);
}
/**
* 初始化
*/
public void init(Context context) {
mContext = context;
inflate(mContext, R.layout.base_view_layout, this);
mRecyclerView = (RecyclerView) findViewById(R.id.recycler_view);
mProgress = (ProgressBar) findViewById(R.id.progress_bar);
mRecyclerView.setLayoutManager(new LinearLayoutManager(mContext));
}
@Override
public void showProgressBar() {
mProgress.setVisibility(View.VISIBLE);
mRecyclerView.setVisibility(View.INVISIBLE);
}
@Override
public void hideProgressBar() {
mProgress.setVisibility(View.INVISIBLE);
mRecyclerView.setVisibility(View.VISIBLE);
}
@Override
public void showMsg(String msg) {
Toast.makeText(mContext, msg, Toast.LENGTH_LONG).show();
}
@Override
public void showPictures(List<Picture> pictures) {
mAdapter = new PictureAdapter(pictures);
mAdapter.setRecyclerItemClickListener(new OnRecyclerItemClickListener() {
@Override
public void onItemClick(int pos) {
mPresenter.onItemClick(pos);
}
});
mRecyclerView.setAdapter(mAdapter);
}
}
这样当需要对视图进行更改的时候，只需要更改这个类就可以了，不用在跑到 fragment 中去了。
于此同时，fragment 也瘦身成功了：
public class PictureFragment extends Fragment{
private PicturePresenter mPresenter;
public static PictureFragment newInstance() {
return new PictureFragment();
}
public PictureFragment() {
}
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_picture, container, false);
BasePageView basePageView = (BasePageView) view.findViewById(R.id.baseView);
mPresenter = new PicturePresenterImpl(basePageView);
return view;
}
@Override
public void onResume() {
super.onResume();
mPresenter.onResume();
}
@Override
public void onDestroy() {
super.onDestroy();
mPresenter.onDestroy();
}
}
改造之后，是不是更好理解了啊。当我们需要对某一部分需要修改的时候，能够轻松定位要修改的地方。
好了，通过改造之后，相信大家对 MVP 的理解也就更加深刻了。
希望这篇文章对大家有所帮助。
原文地址：https://www.cnblogs.com/huansky/p/8545734.html