这是 知天气 实践中的架构搭建方式,建议先下载应用【 应用宝 ,或 腾讯bugly分发平台 】体验下,以免浪费你的时间O(∩_∩)O~~。
项目的构架搭建过程包括MVP的使用,MVP使用中P层的组织,Model层的管理,以及划分P层和Model层的理解。除了项目的框架部分,结构分包方式也很重要,一个好的分包方式能让项目更加清晰,开发过程也会更有效率。除此之外,再加上一些第三方开源框架就能很好的搭建出一个Android应用了。
关于MVP的介绍和优点分析的文章很多,可以自行google。主要分析项目中的应用。
MVC全名是Model View Controller,如图,是模型(model)-视图(view)-控制器(controller)的缩写
MVC是一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。MVC是一种很被广泛使用的框架,但在Android开发中,Activity并不是一个标准的MVC模式中的Controller,它的首要职责是加载应用的布局和初始化用户界面,并接受并处理来自用户的操作请求,进而作出响应。随着界面及其逻辑的复杂度不断提升,Activity类的职责不断增加,以致变得庞大臃肿。
MVP从更早的MVC框架演变过来,与MVC有一定的相似性:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。可以看做MVP就是将MVC中Controller更加细分开来,减少Controller的体积,这很好理解,如果一个类过于庞大,不妨在将其细分,除此之外将View和Model的通信隔绝,都通过Presenter来传递。
MVP在Android中的体现
上面的框架只是一些理论式的知识,具体的应用中还需要更加详细的设计,如:
Presenter其实就是一些普通的类,只是负责将View层(Activity等)中的只和 当前View的业务逻辑 放在这一层来避免随着业务的增多导致View层过大,如很多应用的主界面,然后通过接口来和View交互。生命周期也应该和View保持一致。并要注意避免由于持有View的引用而导致View结束时内存泄露的产生。
Presenter层和Model的划分问题,经常见到的说法是Model层应用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法,如数据的存储与获取等。这种说法没什么问题,但是和Presenter在一起使用的时候容易让人迷惑,Presenter也是处理逻辑,Model也是处理逻辑,那应该怎么区别呢,我的理解是看这些逻辑能否被共用,如果能被多个View或Presenter共用,那这部分逻辑应该放到model层,否则应该在Presenter。Model由于共用的原因,所以其生命周期应该和应用的生命周期保持一致,而写需要一个管理类ModelManager来统一管理。
对于View层与Presenter层,通过接口的方式进行通信,所以View与Presenter是强依赖关系,是共同存在。而Presenter层与Model层则是通过事件总线库如EventBus,我是用的 Router ,主要是用起来更方便。这样Presenter层与Model层关系是弱依赖,因为它们的生命周期不同,而且一个Model肯需要对多个Presenter服务。
下面是总结出来的框架图:
结合上面的图在总结一下,Presenter应该是单一职责的,只用于处理一个View的逻辑,而一个View可以有多个Presenter,以避免如果View中逻辑过多而导致单个Presenter过于庞大臃肿。而Model层应该被共用,以体现其复用性。
在实际的使用中应该注意的是:
MVP搭建的纵向的框架,横向的分割依据AOP面向切面的思想,主要是提取出共用方法作为一个单独的Util,这些Util会在App整体中穿插使用。很多人的App都会引入自己封装的Jar包,封装了包括文件、JSON、SharedPreference等在内的常用操作,自己写的用起来顺手,也大幅度降低了重复作业。
框架搭好后,还需要好的分包方式来管理,我偏向于先根据模块划分,然后在不同的模块里在再按逻辑划分。这样可以很好的使项目模块化,而且开发的时候更方便。
不要畏惧构架,也不要过度设计,具体过度设计的度,可能就需要经验了,但不实践,永远也不会有这个经验。
知天气 即将开源,敬请期待