聊聊Google官方MVP

MVP这个话题也是讨论了很久很久的,热度一直不减,甚至google官方也很认可MVP在Android中的地位。
而我最近一个项目也参照google的那个MVP架构,发现并怎么好用。

果然架构这种东西需要自己思考,根据不同的项目进行变更,MVP MVC MVVM总的来说就是一个架构模式,具体应该怎么实现还是需要依赖于自己不断的探索,照搬别人的项目的话是不可能适合你的项目的。所以网上的MVP项目也是五花八门,看得我欲仙欲死。
google工程师也说了,他们放出的那个Android Architecture只是作为参考,具体怎么实现mvp架构取决于你。

而我也在这篇文章中聊一下我这一个月来照搬Google MVP的感受。


可以先看看这篇文章简单的了解一下google官方mvp
Android官方MVP架构示例项目解析

一、 V层:Fragment

google 用Fragment这个控件作为MVP中的View层,什么回事?
Fragment作为View,那么在Activity就可以初始化Presenter,View和其他一些依赖,让依赖注入独立于MVP外,Activity看起来就像一个Injector。如果Activity作为View的话,那么你需要在Activity中初始化一大堆依赖,View就不是单纯的View了。

这虽然看起来很符合MVP的架构思想,进一步减少了View的工作。但实际上,不好的地方也是很多的。
写项目的时候,不仅要多敲一个Fragment,而且在Activity中也是做反复性的工作:new Fragment,addFragment, new Present……

而且Fragment用起来并没有Activity那么便利,还存在各种莫名其妙的bug,最致命的一点就是:
我们完全可以使用Dagger2进行依赖注入,那么Fragment作为View的好处几乎就没有了。

CleanArchitecture这个开源项目中,虽然也是用Fragment作为View层,但好歹别人用setRetainInstance()维持Presenter啊(presenter生命周期,下面会讲到),不过这方法用不好的话很容易导致内存泄漏……

所以,最终我还是会选择Activity作为View,除非某些页面确实需要用到Fragment。
关于Fragment可以看看这篇文章:我为什么不主张使用Fragment

二、Contract协议类

google用一个Contract类定义了View层接口和Presenter层接口,这看起来是很不错的设计,看起来很符合依赖倒置原则。

但是Presenter真的有必要实现接口吗?
在MVP模式中,Presenter是高层次模块,而View是低层次模块。
而使用依赖倒置原则主要是为了高层和低层模块的解耦,方便替换低层次模块的时候不会影响到高层模块,所以在MVP模式中,View需要实现接口,你可以随时将View替换成Activity,Fragment或者其他,并不会印象到Presesnter。
View使用接口还有另外一个好处:方便测试。你不可能在对Presenter进行单元测试的时候去Mock一个xxxActivity对吧……

而View虽然也依赖于Presenter,但是View和Presenter是一一对应的,Presenter只会有一个,并不可能出现其他实现,所以Presenter实现接口完全是多余的,不仅多了一个无意义的类,还累着自己。

并且,在View中想看Presenter代码的时候,ctrl+左键点击Presenter提示一大堆同名的Presenter。选择其中一个点进去之后,跳转到的是contract类,最终结果你还是需要到目录去找……

关于Presenter到底该不该使用接口解耦的一篇文章,我个人是非常认同作者的。
不要再给MVP中Presenter写接口了

三、P层的生命周期

这一块也是MVP架构中的一个难点
google的mvp很明显没有做额外的Presenter的生命周期管理,让它随着View的生命周期结束而结束。
这看起来没什么问题,但是你们想想,Presenter往往会保存View的一些状态,比如保存是否已经请求过数据的变量,或者某些请求参数。
当Activity或者Fragment因为某些原因生命周期重走了(比如旋转屏幕或者被系统回收),你的Presenter也会重新实例化一个。
如果用户没事做一直来回的旋转屏幕,那么你的Presenter就一次次的实例化,一次次的请求网络……最终可能导致内存溢出或者ANR

不过我们国内的app一般都禁止横屏,所以这一点也不是很重要,但始终算是一个不好的地方吧。
对于延长Activity生命周期的方法有好几种方式
可以看看这篇文章通过Loader延长Presenter生命周期
之前说的使用Fragment的setRetainInstance也是其中一种方法

四、Model层(Repository层)

在上面的图中,也可以看到Google的Model层使用了多种数据源。
内存,本地,网络。
当接收到Prestenr请求数据的时候,Repository就会从内存中取数据,如果没有就从本地取,本地没有就网络请求。
也不用担心每次请求到的数据都是缓存,因为Repository中还有一个变量判断数据是否过期。

这种Model层的设计方式还是很不错的,但是Repository中的代码看起就有点混乱了。
如果单个Repository中的数据量比较多的情况下,那么看起来会非常混乱,因为Repository中是管理了多个数据源的。

我觉得CleanArchitecture的model层设计比google的来的清晰,数据源用一个Factory类管理,并且用Cache类封装缓存,可以管理缓存的过期时间等。比起google直接在Repository中处理数据源逻辑要好些。

还有另外一点就是,有些数据是不需要本地保存的,每次都应该保证是最新的,例如新闻列表,这时候该怎么办。
我个人认为应该统一风格,就算不需要本地缓存,也务必使用多数据源结构的Repository,虽然类会多了,但是可以让你的项目更加清爽。

如果你的项目中,只有少数一两个接口是需要本地缓存的,那么还是不要用多数据源的设计了。这是过度设计,画蛇添足。

五、总结

googlesample的MVP架构用来学习的话是很不错的例子,至少比用其他人过度封装的mvp要简单点。
但是要在实际开发中使用mvp架构,最好是参照google和clean Architecture这两个比较热门的例子,然后花个几天时间认真思考才动手。
Model层,Presenter层的设计,还有统一处理公共参数,统一处理异常等都是值得思考的东西。

相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页