一、整体构架
整个APP架构上从上到下分为三层，独立于APP的通用层，通用业务层，业务层。业务层用来处理上层业务，业务层可以依赖通用业务层和独立于APP的通用层，而且这种依赖是单向的，由上到下的，不能下层依赖上层。
1.首先客户端整体架构的最底层有一个独立于APP的通用层，在这一层里有崩溃的统计，网络的第三方，分享的第三方库等。也就是说这一层的框架或者说架构放在任何一个APP当中，都可以起到一个底层的支撑作用，它是独立于APP之上的。
2.在独立于APP的通用层之上，有一个通用的业务层。比如说针对当下公司，他有一些通用的基础组件，比如说第三方库的二次封装，toast，刷新控件等，这些往往是和当下公司的业务相关的。但是对于APP来说，各个业务线，对于这些通用控件都有需求，那么我们可以将这些内容沉降到通用的业务层。
3.最上层就是我们的业务模块了，业务层的模块应该按照模块化的设计思想，尽量做到高度的“高内聚，低耦合”。
这么做的好处是为以后可能的组件化做准备，目前APP业务规模较小，等以后APP业务规模增大，需要进行重构做组件化的时候，在业务层加入中间层，进行业务模块之间的解耦，将会方便很多。
目标：单独拎出一个业务，不用做过多修改，然后就能生成一个新的APP。这个就是我们做整体的一个客户端的架构的目的或者说它的意义。
app架构.png
二、设计思想
所有模块的开发，包括独立于APP的通用层，通用业务层，业务层，都应该遵循模块化的思想，做到高度的“高内聚，低耦合”。
实现模块化需要注意的点：
- 不跨业务模块使用宏，在开发中可以使用宏，但是不能出现全局的自定义宏，使用的宏只能在当前业务模块内使用
业务层不允许出现common组件，单个模块一定要分工明确，功能单一 - 去基类，单个业务模块内可以有继承关系，不能有跨模块的继承，例如，所有的Controller都继承一个基类。继承也是一种变相的耦合
三、设计模式
关于设计模式的选择，借鉴MVVM设计模式，将业务模块划分为Controller+View+Model+ViewModel+Service+Constant六个部分。
- Controller负责视图创建、组合，协调逻辑，事件回调处理
View负责控件初始化，设置数据，交互事件代理 - Model模型模块，分为网络数据，业务数据，UI数据三种类型
Service组建网络请求 - ViewModel负责业务逻辑处理，数据增删改查封装，线程安全处理，网络请求以及数据解析
- Constant存放该模块的一些公用的常量，例如通知名称，常量字符串等
