Android应用篇 - app 架构设计的思考
对于 Android 客户端的架构设计，可以从分层化和模块化来考虑。
目录：
- 分层化
- 模块化
- 业务逻辑层设计
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，但是这种标准在不同项目中不一定都适用，得灵活选择。
更多相关文章
- Android多媒体功能的实现上(音频，视频，相机，录音)
- Android中Webview与原生界面交互及二维码扫描功能实现
- Android网络功能之会话发起协议SIP
- android利用handler实现倒计时功能
- Android Intent应用，打开网页，安装程序，打电话，打开地图等功能
- android 带清除功能的输入框控件
- Android前端通过Http协议与J2EE后端数据交互。工具eclipse、MySQ