天津公司网站如何制作,海淀网站建设本溪,狼雨的seo教程,网站工期表怎么做注#xff1a;本文阅读需要对MVP模式有基本了解。 MVP模式已经出现有很长一段时间了#xff0c;但是火起来是这两年的事情。 关于MVP的概览#xff0c;介绍#xff0c;乃至于教程#xff0c;Demo#xff0c;实例#xff0c;网上都有很多#xff0c;我也有一篇文章专门收…注本文阅读需要对MVP模式有基本了解。 MVP模式已经出现有很长一段时间了但是火起来是这两年的事情。 关于MVP的概览介绍乃至于教程Demo实例网上都有很多我也有一篇文章专门收录了一些关于MVP的资料起码现在很多朋友对表现层Presenter视图层View模型协议类接口这些词并不陌生了。 很长一段时间出去面试的筒子们经常会被问到一个问题知道谷歌四件套么MVP, Dagger2 ,retrofit ,RxJava 确实新项目应用四件套带来的好处是大大的当然也会有一些问题。我做的上个项目是个新项目所以就应用了谷歌四件套到目前已经一年多了所以稍微总结一下。在实际项目中是怎么使用MVP带来的好处以及怎么优化。 ##几句话介绍和总结MVP模式和MVC模式 先简单介绍和对比下MVC和MVP下面是摘自百度百科关于MVP的介绍中的图个人再加了一些标注这两张图还是很经典的 【MVC】MVC就不用多说具有悠久的历史。这里View一般是指xmlhtmlController一般是指activityfragment。 好处就是写起来方便并且快缺点就是东西多的时候activity/fragment很重基本上配合数据、业务然后控制view层显示隐藏交互等所有的逻辑都在里面代码动辄上千行维护较困难耦合度高改个bug或者需求眼睛花找不到位置若是没有注释那真的就是……你懂的不过也有一些项目把controller层单独抽出来 View不直接依赖 Model而是把所有业务逻辑都放在 Controller 中处理而 View 只和 Controller 交互。 【MVP】MVP主要就是把Model和View进行了分离通过presenter去连接主要的程序逻辑在Presenter里实现并且Presenter与具体的View是没有直接关联的而是通过定义好的接口Interface Presenter;Interface View进行交互从而使得在变更View时候可以保持Presenter的不变。 总之View很薄activity和fragment代码很少presenter处理逻辑代码有可能会比较多具体根据业务定。然后View只有简单的Set/Get的方法Set--设置界面信息/Get--获取界面信息决不允许直接访问Model。 ##MVP模式的优点 根据个人项目经验总结一下主要有如下几个 结构清晰代码解耦复用性高单元测试方便适用于快速迭代开发####结构清晰 由于MVP中模型与视图完全分离ViewModelPresenter各司其职所以代码看上去会非常清爽 view中单纯的控制视图即可例如显示隐藏修改数据什么的model中只处理数据presenter中是一个个的方法体只处理逻辑不用关心视图怎么处理数据如何获取。这里贴几张项目中实际的代码图虽然是很简单的类但是可以感受到结构有多清晰。 ####代码解耦 同样由于模型与视图完全分离我们可以修改视图而不影响模型。 1我们需要修改视图相关的直接在View层中修改就行了不需要修改Model与Presenter层2我们需要修改Model相关的比如网络框架或者数据库框架则只需要修改Model层不需要修改View层和Presenter层。3我们需要根据不同的参数和规则修改业务或者逻辑则直接在Presenter层中修改就行了通过mView.XXX连接到view层不需要修改View层和Model中的代码。之前看过三个例子非常好的诠释了这三点 如果哪天APP要升级界面风格或者提示的文案颜色等要修改但是展示的数据源没有变化这时候我只需要修改View层的代码其他代码不需要修改。因为把数据处理业务逻辑都融合到View中的话修改起来会比较麻烦改动的代码会很多。如果哪天有更好到网络框架出现你很想换掉原先的网络框架那么你原先写的Model层代码就要做相应的修改这样你只需要对Model部分进行修改不需要对Presenter和View进行修改。假设业务逻辑也要改了那只需要修改Presenter层就行不需要修改其他两个模块。 同样在进行分模块划分分工合作的时候根据不同的人擅长的点不同可以进行多元化的分模块。 在MVC模式中一般是每个人负责一个模块包括ModelView和Controller层。 当然在MVP中也可以这样划分一个人负责一个模块的整个MVP部分。但是我们多了一种选择一个擅长写视图的人负责所有的View层代码一个擅长写逻辑的负责所有的P层代码。 具体实现一般是一个架构师设计好项目架构和写好基本的common部分和MVP类并写好基本方法和暴露的借口这样有利于规范方法名等。然后由开发人员在各自模块工作根据暴露的接口和规范写逻辑的专门写逻辑写视图的专门写视图。####复用性高 为什么这么说呢因为所有的交互和逻辑都发生Presenter内部所以我们可以将一个Presenter用于多个View层不用修改Presenter中的逻辑就算有细微区别的的地方可以通过方法重载等方式处理从而达到高效利用模型。并且做过开发的一半都知道一件事就是视图层的修改远比逻辑层的来的频繁所以逻辑层Presenter不用动是一件很幸福的事。 ####单元测试方便 由于Presenter是纯逻辑层纯Java代码里面没有Android代码所以我们可以直接对Presenter写Junit测试可以脱离用户接口来测试这些逻辑。 ####适用于快速迭代开发 基于以上的优点MVP模式非常适用于快速迭代的项目敏捷开发模式能充分应对多变的需求。 ##MVP模式的缺点 用辩证的角度看世界凡事有利必有弊关于MVP的缺点 爆炸式增长的类和接口原先的1,2个或者2,3个类现在变成6,7个甚至10几个。复用的时候可能造成接口的冗余。Presenter持有着View的强应用在请求网络数据等耗时操作的时候Activity可能被销毁可能会导致View无法回收从而造成内存泄漏问题。##MVP模式在项目中的优化 MVP的优点还是有很多的总的来说是利大于弊所以我们的优化肯定是针对缺点进行优化的。根据个人的经验内存泄漏可以通过一些方法处理掉所以主要是要优化缺点1和2。 ####优化1 MVP的接口类有两种写法一种是直接写接口类一种是通过协议类什么意思呢具体见下图 总的来说直接写接口类1个模块就会比通过协议类多1到2个接口类查找接口和引用的时候也不够方便通过实际尝试个人还是比较推荐协议类写法并且谷歌官方的demo和推荐MVP写法是通过协议类方式 直接接口写法这里引用一下别人的demo图 协议类写法摘自实际开发项目 ####优化2 要灵活应用MVP模式不是每个类都需要用MVP模式去写在项目中更要灵活变通。 例如如果类比较简单处理的东西不多完全可以通过MVC模式又快又方便贴一张实际项目中的图 可以看到我们没有写相关的Interface View、Interface Presenter 和Interface Model。加上ImportButterknife一共才200来行。因为只有一个网络请求几个简单的点击事件所以完全没有必要搞很多类引用来引用去。 ####优化3 由于类和接口众多所以模块A的Presenter并不复杂代码也不多模块B和A之间又有一些关联或者大同小异就尽量让模块B复用模块A的Presenter和Contract通过继承多态方法重载等方式处理这样可以减少很多类和接口结构也不会很复杂看上去也更清爽。 例如我的项目中有两种课程类型类型A和类型B的页面但是仅仅是数据源不一样所以我就统一放在一个Presenter中处理了。 ##写在最后 MVP模式确实是一个非常优秀的架构模式但是每个人、每个项目用起来都是不一样的用法写法也是千千万万。但总归一句话没有最好的架构只有最适合的架构。一定要灵活变通举一反三不管是MVC、MVP还是MVVM只要适合自己适合项目用的好就行了。 转载于:https://juejin.im/post/5a321db4f265da430c11d5bf
