浅谈android架构设计

       到目前为止，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之间的状态的时候很管用，跟观察者模式类似。

       希望所写对大家有帮助，互相学习！