每日一题: MVP开发模式
面试率: ★★★★★
面试提醒
在Android中MVP已经不算是什么新鲜东西了,记得Android以前比较流行的开发模式是MVC,而MVP是MVC的一个扩展,当随着项目越来越庞大,复杂,参与开发人员越来越多,MVP模式的优势就充分显示出来了.
- 在一个复杂的项目中,不会全部都使用MVP,可能会在某个功能模块,组件,或者某个页面中使用.
- 有时你也会发现一个项目中使用了多种开发模式,这是项目的不断迭代,业务不断扩展引起的.
面试技巧
- MVP模式是MVC模式在Android上的一种变体,要介绍MVP就得先介绍MVC.
在MVC模式中,Activity应该是属于View这一层.而实质上,它既承担了View,同时也包含一些Controller的东西在里面.这对于开发与维护来说不太友好,耦合度大高了.把Activity的View和Controller抽离出来就变成了View和Presenter,这就是MVP模式. - MVP虽好,但并不是每个地方都适合去使用,正确的选择开发模式有利于项目的维护和扩展.
至少你要了解MVP的优缺点,项目中如何正确使用.
面试题
根据上面问题,我整理了一些相关的问题.
MVP与MVC之间的区别?
- MVC
View:对应于xml布局文件
Model:实体模型
Controler:对应于Activity业务逻辑,数据处理和UI处理
- MVP
View:对应于Activity和xml,负责View的绘制以及与用户交互(接口)
Model:实体模型(也可以是耗时操作)
Presenter:负责完成View于Model间的交互和业务逻辑(中转器)
在Android开发中MVP的设计思想用得比较多,利用MVP的设计模型可以把部分的逻辑的代码从Fragment和Activity业务的逻辑移出来,在Presenter中持有View（Activity或者Fragment）的引用,然后在Presenter调用View暴露的接口对视图进行操作,这样有利于把视图操作和业务逻辑分开来.MVP能够让Activity成为真正的View而不是View和Control的合体,Activity只做UI相关的事.
MVP优缺点
- 优点
解耦合:分离了视图逻辑和业务逻辑,降低了耦合
代码简洁:Activity只处理生命周期的任务,代码变得更加简洁
可读性高:视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去,提高代码的可阅读性
单元测试:Presenter被抽象成接口,可以有多种具体的实现,所以方便进行单元测试
避免OOM:把业务逻辑抽到Presenter中去,避免后台线程引用着Activity导致Activity的资源无法被系统回收从而引起内存泄露和OOM
- 缺点
不美观:Activity需要实现各种跟UI相关的接口,同时要在Activity中编写大量的事件,然后在事件处理中调用presenter的业务处理方法,View和Presenter只是互相持有引用并互相做回调,代码不美观.
逻辑耦合高:这种模式中,程序的主角是UI,通过UI事件的触发对数据进行处理,更新UI会有线程的问题.而且牵扯到的逻辑耦合度太高,一旦控件更改（如TextView 替换 EditText等）牵扯的更新UI的接口就必须得换.
代码臃肿:复杂的业务同时会导致Presenter层太大,代码臃肿的问题.
类变多:类变多了,本来一个Activity就可以完成的功能,现在多了Model,View,Presenter类,对于一些简单的功能模块还是用这种开发模式的话会得不偿失.
对于MVP的缺点有什么建议或者优化方案?
对于上面部分缺点,我的一些优化方案:
代码臃肿
mvp中本身model就是一个实体bean,可有可无,并没有发挥作用,而一个完整框架应该有三大层(展示层,业务层,数据层)m层相当于数据层.数据层是数据管理者,主要任务就是封装API,并将数据结果交付给上层.也就是说我们可以将于数据相关的操作封装在数据层,如网络请求,网络状态判断,缓存策略等在model中去处理,这样可以有效的解决Presenter业务过于庞大导致的代码臃肿问题.不美观,逻辑耦合高,类变多
对这些有问题想进一步优化的,可以考虑使用MVVM开发模式.该模式优点低耦合,UI刷新简便,使用的类减少,开发效率高,可复用性强,单元测试方便等.
MVP中Presenter在哪里初始化?
Presenter会在UI(Activity,Fragment)中初始化,在这我们可以通过Presenter的引用来调用其内部方法(或者调用Model对象方法)来执行业务,请求回来的数据会在View接口中被回调过来.
MVP中new Presenter(this);这里的this代表什么,是context还是View?
这里的this是MVP中的View接口,因为View接口被UI实现(Activity/Fragment)了所以传入的并不如context.
单元测试可以在MVP的哪个层里去进行?
MVP中,由于业务逻辑都在Presenter里,我们完全可以写一个PresenterTest的实现类继承Presenter的接口,现在只要在Activity里把Presenter的创建换成PresenterTest,就能进行单元测试了,测试完再换回来即可.万一发现还得进行测试,那就再换成PresenterTest吧.
为什么MVP可以避免Activity内存泄漏?
Android APP 发生OOM的最大原因就是出现内存泄露造成APP的内存不够用,而造成内存泄露的两大原因之一就是Activity泄露（Activity Leak）（另一个原因是Bitmap泄露（Bitmap Leak））.
Activity是有生命周期的,用户随时可能切换Activity,当APP的内存不够用的时候,系统会回收处于后台的Activity的资源以避免OOM.
采用MVP模式,业务操作都在P层处理了,context没有被关联进来,因此可以避免因其导致的oom问题.
另外如果presenter层真的要使用到Activitycontext的引用的话
只要在当前的Activity的onDestroy里,分离异步任务对Activity的引用,就能避免 Activity Leak.
为什么采用传统的MV模式不易解决OOM问题?
采用传统的MV模式,一大堆异步任务和对UI的操作都放在Activity里面,比如你可能从网络下载一张图片,在下载成功的回调里把图片加载到 Activity 的 ImageView 里面,所以异步任务保留着对Activity的引用.这样一来,即使Activity已经被切换到后台（onDestroy已经执行）,这些异步任务仍然保留着对Activity实例的引用,所以系统就无法回收这个Activity实例了,结果就是Activity Leak.Android的组件中,Activity对象往往是在堆（Java Heap）里占最多内存的,所以系统会优先回收Activity对象,如果有Activity Leak,APP很容易因为内存不够而OOM.
举例说明:遍历搜索指定sdcard目录下的图片集文件夹,并显示出来?
遍历文件
线程控制
显示图片
