一种Android客户端架构设计分享

转载请注明出处:http://blog.csdn.net/ahence/article/details/56678126

技术发展日新月异,业界各种Android客户端架构设计,五花八门,但我们不能简单地说哪种架构更好,因为脱离业务谈架构是没有任何意义的,适合业务的才是好架构。而架构也不是一成不变的,随着业务的发展,也许当初设计的架构已不足以支撑目前的业务,那么就需要改变之前的架构。接下来将分享下我们Android客户端的架构设计,在App的某个业务发展阶段或许有一些参考意义。

分层化与模块化

分层化与模块化应该是任何软件开发的共识。

分层化

在Android应用开发中通常可以分为如下几层:

这里写图片描述

  • SDK层:主要是Android SDK及第三方的SDK(可能基于Android SDK或为独立的SDK),这些SDK为上层框架提供核心功能的支持。
  • 基础框架层:这里所谓的基础框架,指多数App都必需的基础功能,是具体业务逻辑实现的基础。主要有网络请求功能、图片加载与缓存功能、SQLite数据库管理功能、Log管理功能等,当然根据对业务逻辑支持的不同,基础框架层的功能支持也不一定相同,上述几个应该是大部分App都要支持的,当然Crash监控与常用工具类也可归为该层次。
    具体到每个基础框架的实现则没有任何限制,如网络功能可以使用Volley、OkHttp或者自己封装实现网络请求逻辑;对于图片管理功能则可以使用Glide、Fresco、Picasso,亦或自己实现……总之每个基础框架都要遵循一定的实现原则,保持功能模块的独立性,与具体业务解耦并对外提供良好的交互接口。
  • 业务逻辑层:如果把App架构比作高层建筑,那么上述两层就是地基。地基打好之后,就可以在上面任意发挥了,至于如何发挥,那就必须结合实际的业务需求,不同的应用往往有不同的业务功能模块。
    另一方面,业务功能模块也并非完全是并列的级别,有一些业务逻辑也是可以抽象出来的,作为通用的功能模块,比如登录、分享、扫描、统计等,其他的业务模块可能会调用到这些功能。

这里需要注意的是SDK层与基础框架层并不是一成不变的,但它们的变化周期往往是比较长的,一般来说当基础功能不能满足最上层的业务逻辑时,就需要对其做扩展。由于基础框架层的功能模块已经是功能级别的粒度划分,因此扩展往往是模块级别的扩展,通常是新增基础功能框架而不是修改原有基础功能框架,这也符合“开放-闭合”原则。

模块化

至于模块化,对于分层化来说则是更细粒度的划分,即将每一层细分为不同的模块,各功能模块尽可能遵循“高内聚、低耦合”的原则,功能模块之间仅提供必要的交互接口。

对于基础框架层,由上图可见,往往是根据功能来划分。这里的基础框架层细分为网络支持功能、图片库、日志系统、数据库支持等模块,如果不足以支撑业务发展,可能会新增其他基础功能模块。

而业务逻辑层则主要由业务需求来决定,如分为扫描功能、电商、快递查询等模块。业务逻辑层的模块化还有一种驱动因素,那就是通用功能的封装,这一点大家应该都有体会,随着App业务逻辑的增加,不同业务功能之间可能会用到相同的功能,如用户登录、分享功能等,我们不希望在每个需要的地方都复写一遍相关代码,于是就需要把通用功能抽取成独立于具体业务需求的模块,如登录模块、分享模块,在模块内部实现通用的业务逻辑,同时对外暴露调用接口,不同的业务只需调用通用模块即可。

业务数据流程设计

由于业务逻辑、数据处理逻辑或网络框架的不同,相信各家应用都有自己的一套数据请求流程。最直接的就是从Activity或Fragment中调用网络请求的方法,然后通过回调将结果返回到Activity或Fragment中,虽然流程最清晰,但这种方式存在几个严重的问题:

  • 网络数据直接返回到Activity或Fragment中,后续需要对数据进行解析、过滤、转换、缓存等操作,这些工作将会大大加重Activity或Fragment的负担。
  • Activity或Fragment的代码量猛增,逻辑繁杂(不仅包含了Vie
  • 4
    点赞
  • 41
    收藏
    觉得还不错? 一键收藏
  • 13
    评论
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值