app架构思考

2019-02-12 本文已影响904人 kangomake

整个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六个部分。