码迷,mamicode.com
首页 > 移动开发 > 详细

浅谈android架构设计

时间:2015-01-20 01:01:46      阅读:188      评论:0      收藏:0      [点我收藏+]

标签:

       到目前为止,android开发在网络上或者社区上没有公认的或者统一的开发框架,好多框架都是基于对方法的封装。今天在这浅谈两年来对android开发的理解,主要是思想上的理解,希望对大家有帮助。

       我认为android开发可以从两个方面去总结架构的设计,在这里对于实现只做陈述:

       一,就是大多数人的设计思路,对方法的封装。

       在这里我根据开发的习惯对工程进行包的设计:

       1. http:网络请求方法封装。这里建议采用线程+Handler的模式,把Http 中get方法和post两种请求方式分开,对于正常的操作逻辑采用post的方式,方便数据的封装,加密和安全。对于获取图片,视频这个可以通过一个URL直接拿来主义的操作用get的方式,速度快且不复杂。

       2. thread:既然http要采用线程的方式那么自然的线程管理就是一个重点,建议整个App对线程进行统一的管理,根据线程池的特性封装多线程和单线程,每次要启用线程的时候都到线程池里面去取,这样整个App的线程数,占用内存的大小基本就在掌控之中了。

       3. download:对apk的下载或者对图片,视频的下载管理。期间结合多线程,软引用,本地存储,内存存储的方式就可以多线程下在图片。下载图片处理结果有两种方式一种直接传递显示Imageview显示,但是这种方式想对返回的图片进行处理就不是很方便了,所以建议再加上回掉的方式,传递回掉的对象,需要回掉到页面处理就添加回掉事件。

       4. upload:上传文件,图片,视频等,这块上传的时候可以进行对文件的压缩再上传会更好些。

       5. dao:对数据库的操作,建表,版本控制,添加数据,对数据的增,删,改,查。

       6. file:对文件的操作。

       7. utils:工具类。

       8. exception:异常类,异常类主要是结合http请求返回的错误码进行解析,还有项目运行中对一些细节进行捕获。

       9. log:log的封装须实现三种,a:开发调试;b:发布时错误log保存本地;c:发布是必要错误日志发送服务器。

      10. bean:数据封装bean。传递数据建议通过bean用Json和Gson相互转换的方式进行。

      

       二,可以从根据数据以及数据的业务逻辑处理进行设计。

      以上是大多数人的封装思路,主要是针对方法的封装,下面要说的是对上面的封装整合到实际项目业务中处理的方式,主要是针对业务的封装,在这里大方向上主要应用了两个设计模式:中介者模式,MVP模式。其间大量用到工厂模式,单利模式,模板模式,观察者模式等等。

     整体思想是:

      11. daorest,httprest,filerest:这几个包主要封装了app与各个渠道的交互之间的接口,可根据实际的项目需求进行添加,里面没有实现方法,所有的类全部是接口。

      12. mediator:中介,如果用普通的方式进行交互的话我们用A,B,C代替三个来源不同的接口,如果有个页面V需要用到这三个来源,那么就会有V和A交互,V和B,V和C两两交互,要是有复杂的关系没准会有V和AB交互等等,这样交互关系就像一个没有规则的网,很难理清楚。这时候我们用一个中介的话问题就会大大改善,我们引入一个中介M这个时候ABC被整合到M中,ABC对于V的关系无论多复杂,由内部整合,最后由M统一发出对V的交互,这时候关系就很清楚。V和ABC无论谁需要改变都不会影响到对方,M充当了一个调停的关系所以中介模式又叫调停者模式。

      13. presenter:这就是MVP模式中的P。很多人都说android不能很好的区分MVC模式,因为Activity中既包含了V也包含了C,其实android真正的V层我感觉应该是XML层,但是XML层没法动态改变数据。所以索性我们退一步,让activity也作为我们唯一的V层,这个时候MVP就诞生了。其中的MV跟MVC中的MV是一样的,P就是我们添加的一个处理Activity中业务的层,我们把他命名为Presenter。P的主要作用就吧原来Activity中一切的数据业务处理挪到了P层,让Activity成为一个纯纯的V。具体的实现方式可参考:http://blog.csdn.net/zhouyinhui/article/details/4614474

      14. view:Activity实现层。

       最终总结下来工程的目录也大概出来了,这里主要介绍的就是Mediator+MVP模式的框架结构以及大致实现思想,其中还有好多细节,比如说各层业务中各个业务接口就需要abstracts限制,管理就需要用工厂模式,代码的实现方式就需要模板,View层状态的变更就需要观察者模式等等。需要写好一个框架是要很大功夫的需要不断的积累不断的重构。啊,对了还差几个目录一并补上。

       15.service:android服务不会随应用的关闭而关闭。经常会被第三方软件关掉。

       16.broadcase:广播,再通知各个activity之间的状态的时候很管用,跟观察者模式类似。

       希望所写对大家有帮助,互相学习!

      



浅谈android架构设计

标签:

原文地址:http://blog.csdn.net/heyouhua123yeah/article/details/42886497

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!