Android音视频播放器开发（二）：MVP模式实践
Android音视频播放器开发（二）：MVP模式实践
本文主要针对上一篇博客的代码进行重构，并简单阐述了使用MVP模式的好处。
以音乐播放部分为例，下图是未重构的代码结构：
虽然还算清晰，但是拓展性很差。经过一番重构，代码结构变成了下面这样：
是不是看起来变得复杂了？再来分析以下具体的代码改变：
这是一个接口，定义了MVP中Presenter的职责。接着定义一个类实现这个接口，而具体的实现代码其实是重构之前散布在Activity和Service中的功能代码，现在通过Presenter实例调用完成：
以上代码其实就是把直接执行的语句封装起来再间接调用。这样有什么用呢？虽然看起来饶了弯路，但却实现了视图和逻辑的分离，接下来举例说明这种解耦的好处。
这里我们获取了本里的音乐列表，但一般音乐播放器都应该有在线播放的功能，所以我们现在需要加一个功能：搜索歌名，显示在线列表。这是最后的效果：
其实原理非常简单，向一个开放的API发送请求，解析返回的JSON数据就可以了，这里不细讲。我们的关注点是重构后代码如何更好的应对这种需求的变化。
仔细分析一下，无论本地音乐列表还是在线音乐列表，其实都是
MVP中的Model层在变化，所以View和Presenter层受到的影响应该尽可能小。在回来看第二张图，可以看到在music.model包下的IMusicDatabase有两个不同实现，对应不同的列表获取源。如此，在View只需要简单地加几行代码：
由于网络操作在子线程，界面刷新在UI线程，所以对比一下本地列表的显示：
发现虽然调用了相同的方法，但却有线程之分了，正是因为采用了MVP的架构，才得以将主要的变化转化为新建一个MusicDatabaseOnlineImpl类，而最大限度的减少对原工程的更改。如下图：
以上，就是我对MVP的一点理解，拖了半个月才补完这篇博客。
此外，对比一下MVC和MVP可以发现，MVP更加符合正交设计的原则（想像Model，View，Presenter垂直排列）：
比如TCP/IP的设计，Android的架构，都符合正交设计的原则：
这种设计的好处是某一层变动（本例是Model层）可以最大限度降低对整个架构的影响。
最后，项目github：vimerzhao/MediaPlayer
