赞
踩
对应于布局文件
但是细细的想想这个View对应于布局文件,其实能做的事情特别少,实际上关于该布局文件中的数据绑定的操作,事件处理的代码都在Activity中,造成了Activity既像View又像Controller
业务逻辑和实体模型
对应于Activity
对应于Activity,负责View的绘制以及与用户交互
业务逻辑和实体模型
负责完成View与Model间的交互
负责绘制UI元素、与用户进行交互(在Android中体现为Activity)
需要View实现的接口,View通过Activity interface与Presenter进行交互,降低耦合,方便进行单元测试
负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。
减少了Activity的职责,简化了Activity中的代码,将复杂的逻辑代码提取到了Presenter中进行处理。与之对应的好处就是,耦合度更低。
Activity 代码变得更加简洁。
使用MVP之后,Activity就能瘦身许多了,基本上只有FindView、SetListener以及Init的代码。其他的就是对Presenter的调用,还有对View接口的实现。这种情形下阅读代码就容易多了,而且你只要看Presenter的接口,就能明白这个模块都有哪些业务,很快就能定位到具体代码。Activity变得容易看懂,容易维护,以后要调整业务、删减功能也就变得简单许多。
方便进行单元测试
避免 Activity 的内存泄露
1)发生OOM异常的原因
i)现内存泄露造成APP的内存不够用,而造成内存泄露的两大原因之一就是Activity泄露(Activity Leak)(另一个原因是Bitmap泄露(Bitmap Leak))
ii)Java一个强大的功能就是其虚拟机的内存回收机制,这个功能使得Java用户在设计代码的时候,不用像C++用户那样考虑对象的回收问题。然而,Java用户总是喜欢随便写一大堆对象,然后幻想着虚拟机能帮他们处理好内存的回收工作。可是虚拟机在回收内存的时候,只会回收那些没有被引用的对象,被引用着的对象因为还可能会被调用,所以不能回收。
iii)Activity是有生命周期的,用户随时可能切换Activity,当APP的内存不够用的时候,系统会回收处于后台的Activity的资源以避免OOM。
2)MVC产生内存泄漏异常分析
i)采用传统的MVC模式,一大堆异步任务和对UI的操作都放在Activity里面,比如你可能从网络下载一张图片,在下载成功的回调里把图片加载到 Activity 的 ImageView 里面,所以异步任务保留着对Activity的引用。这样一来,即使Activity已经被切换到后台(onDestroy已经执行),这些异步任务仍然保留着对Activity实例的引用,所以系统就无法回收这个Activity实例了,结果就是Activity Leak。Android的组件中,Activity对象往往是在堆(Java Heap)里占最多内存的,所以系统会优先回收Activity对象,如果有Activity Leak,APP很容易因为内存不够而OOM。
3)MVC模式如何处理内存泄漏
i)只要在当前的Activity的onDestroy里,分离异步任务对Activity的引用,就能避免 Activity Leak
代码框图:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。