根据实际项目浅谈Android项目中的搭建简单的框架

转载:https://silencedut.github.io/2016/12/05/%E6%A0%B9%E6%8D%AE%E5%AE%9E%E9%99%85%E9%A1%B9%E7%9B%AE%E6%B5%85%E8%B0%88Android%E9%A1%B9%E7%9B%AE%E4%B8%AD%E7%9A%84%E6%A1%86%E6%9E%B6%E6%90%AD%E5%BB%BA/

此构架待优化,不要参考!!!

重构中…

这是知天气实践中的架构搭建方式,建议先下载应用【应用宝,或腾讯bugly分发平台】体验下,以免浪费你的时间O(∩_∩)O~~。

项目的构架搭建过程包括MVP的使用,MVP使用中P层的组织,Model层的管理,以及划分P层和Model层的理解。除了项目的框架部分,结构分包方式也很重要,一个好的分包方式能让项目更加清晰,开发过程也会更有效率。除此之外,再加上一些第三方开源框架就能很好的搭建出一个Android应用了。

MVP的使用(纵向)

关于MVP的介绍和优点分析的文章很多,可以自行google。主要分析项目中的应用。

MVC

MVC全名是Model View Controller,如图,是模型(model)-视图(view)-控制器(controller)的缩写

MVC是一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。MVC是一种很被广泛使用的框架,但在Android开发中,Activity并不是一个标准的MVC模式中的Controller,它的首要职责是加载应用的布局和初始化用户界面,并接受并处理来自用户的操作请求,进而作出响应。随着界面及其逻辑的复杂度不断提升,Activity类的职责不断增加,以致变得庞大臃肿。

MVP

MVP从更早的MVC框架演变过来,与MVC有一定的相似性:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。可以看做MVP就是将MVC中Controller更加细分开来,减少Controller的体积,这很好理解,如果一个类过于庞大,不妨在将其细分,除此之外将View和Model的通信隔绝,都通过Presenter来传递。

这里箭头的指向值得是依赖关系,Model不应该依赖上层的逻辑,所以应该是单向的。

MVP在Android中的体现

  • View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity,frament等等)
  • Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
  • Presenter:作为View与Model交互的中间纽带,处理与用户交互的负责逻辑。
  • *View interface:需要View实现的接口,View通过View interface与Presenter进行交

使用

上面的框架只是一些理论式的知识,具体的应用中还需要更加详细的设计,如:

  • Presenter具体是什么,该怎么和View层交互
  • Model层和Presenter怎么划分,怎么管理
  • 对应到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层应该被共用,以体现其复用性。

在实际的使用中应该注意的是:

1.不要死板的按照这个框架,不是任何View都需要一个Presenter,有些View可能只是个很简单的页面,再去写个Presenter就真的为了框架而框架了,这时候框架对你的开发起到的反而是阻碍作用。

2.注意Presenter持有View导致的内存泄露问题,因为二者是强依赖关系,所以在View相应的生命周期对Presenter进行绑定和解绑,也可以通过若引用来持有View对象,但我觉的这是可以自己来避免的,用若引用来处理的方式是一种不好的思想。

MVP搭建的纵向的框架,横向的分割依据AOP面向切面的思想,主要是提取出共用方法作为一个单独的Util,这些Util会在App整体中穿插使用。很多人的App都会引入自己封装的Jar包,封装了包括文件、JSON、SharedPreference等在内的常用操作,自己写的用起来顺手,也大幅度降低了重复作业。

项目划分方式

框架搭好后,还需要好的分包方式来管理,我偏向于先根据模块划分,然后在不同的模块里在再按逻辑划分。这样可以很好的使项目模块化,而且开发的时候更方便。

不要畏惧构架,也不要过度设计,具体过度设计的度,可能就需要经验了,但不实践,永远也不会有这个经验。

知天气已开源。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章