*View 对应于Activity，负责View的绘制以及与用户交互
*Model 依然是业务逻辑和实体模型
*Presenter 负责完成View于Model间的交互
View与Model并不直接交互，所有的交互放在Presenter中
*我们的presenter完成二者的交互，那么肯定需要二者的实现类。
大致就是从View中获取需要的参数，交给Model去执行业务方法，执行的过程中需要的反馈，以及结果，再让View进行做对应的显示
在这种模式下，整个框架内部模块之间的逻辑操作均由Presenter控制，View仅仅是整个操作的汇报者和结果接收者，Model根据Presenter的单向调用返回数据。并且MVP模式使得View与Model的耦合性更低，降低了Presenter对View的依赖，实现了关注点分离的初衷，方便开发人员的编码和测试工作。
具体到Android App中，我一般将App根据程序的结构进行纵向划分，对应MVP分别为模型层，UI层和逻辑层。UI层一般包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动之后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，两者之间的通信通过BroadCast、Handler或者接口完成，只传递事件和结果。举个简单的例子，UI层通知逻辑层（Presenter）用户点击了一个Button，逻辑层（Presenter）自己决定应该用什么行为进行响应，该找哪个模型（Model）去做这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。
从零开始开发一款Android app，前期需要哪些规划工作避免代码臃肿混乱？
在开发GUI应用程序的时候，会把管理用户界面的层次称为View，应用程序的数据为Model
在MVP模式里通常包含4个要素：
(1) View :负责绘制UI元素、与用户进行交互(在Android中体现为Activity);
(2) View interface :需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试;
(3) Model :负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合);
(4) Presenter :作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。
