Android应用篇 - app 架构设计的思考_android app 设计分层

对于 Android 客户端的架构设计，可以从分层化和模块化来考虑。

 

目录：

1. 分层化
2. 模块化
3. 业务逻辑层设计

 

 

1. 分层化

在 Android 客户端开发中，通常可以分成以下几层：

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

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

 

 

2. 模块化

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

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

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

 

 

3. 业务逻辑层设计

网络数据直接返回到 Activity 或 Fragment 中，后续需要对数据进行解析、过滤、转换、缓存等操作，这些工作将会大大加重Activity 或 Fragment 的负担。Activity 或 Fragment 的代码量猛增，逻辑繁杂 (不仅包含了 View 的逻辑还包含了数据处理的逻辑)。从整个应用的角度来看，每个页面甚至每个接口都需要重复上述相同的冗余工作，完全可以抽象出来。

可以选用目前主流的设计：Android应用篇 - MVC、MVP 和 MVVM，但是这种标准在不同项目中不一定都适用，得灵活选择。