一、前言

过去的开发思想，一般都是采取纵向结构的方式去架构项目，自从推出组件化的横向架构后，我们一般都会纵横结合地去构建我们的项目。

前面已经介绍了最近出的几种架构思想，无论是最初的MVC, 还是近几年风头极盛的MVP, Google推出的MVVM,还是系统层面的组件化，他们都具有自己适用的场景，我们因地制宜，选择自己合适的架构，才能将设计效益最大化。

二、如何架构项目

无论是最初的MVC, 还是近几年风头极盛的MVP, Google推出的MVVM,还是系统层面的组件化，最终遵循的架构原则无非就是三点：

1、横向划分模块
2、纵向划分层次
3、解耦通信

image

一个大的项目，代码量是极大的，甚至达到1G以上；这时必须先以大的层级进行划分，才能有效达到分离的目的。

现在流行的组件化思想便有了用武之地；组件化是指解耦复杂系统时将多个功能模块拆分、重组的过程，它是一种高效的处理复杂应用系统，更好的明确功能模块作用的方式，分离组件边界和责任，便于独立升级和维护。

组件化思想主张将一个系统横向切分为不同的子系统或者可以称之为组件，根据业务与开发需要将工程划分为：基础库组件，工具库组件，业务组件1，业务组件2... ，同时不同的模块之间从大的层级实现职责单一原则。

一个系统划分为若干组件后，那么问题就产生了，就是每个子模块之间不能直接调用，那么我们怎么进行模块之间的跳转与数据交流呢。

首先想到的解决的办法有两个，隐式跳转和反射，但是，这两种方式一种实现维护麻烦，一种对性能会有影响，都不是理想的解决办法。

那么，什么方式是实现组件之间交互的的理想方法，从而达到解耦的目的呢？

组件化的解耦思路是实现一套注册路由机制，根据一套统一的注册路由系统来统一实现跨组件通信，当前比较流行的框架有ActivityRouter, ARouter等

另外，插件化的解耦则直接通过Android系统提供的Binder机制来进行

从横向做了组件划分后，每个组件必然也需要自己的架构，这时候就需要使用纵向分层的思想了，也就是要说的纵向分层策略。MVC, MVP, MVVM 这些设计则使用了纵向分层的思想；它们都执行了三层划分的标准，虽然各有不同，但大致可以理解：

经以上划分后，数据处理， Ui显示，逻辑处理都放到了各自的层进行处理，每个层仅执行本层应该做的操作。分层后，代码已经做到了结构清晰，尽可能的解耦，易于理解维护。

根据CleanArchitecture原则，采用圆葱形式的分层与解耦策略，因此在设计时注意：

拿MVP为例，根据洋葱结构，由内到外我们可以得到Model-> Presenter -> UI;

在调用时，某层只能调用向内的邻接层，如Presenter只能调用Model层，而不能出现Model层调用Presenter层的现象；相同的，UI层只能调用Presenter层，而不能跨层调用Model层；

层与层之间的通信，必然不能通过直接调用的方式（特别是View层与Presenter层），我们可以参考MVP模式中的接口通信方式来实现。

我们这里只是从理轮上分析，如何搭建我们的项目架构

横向只有组件化，而纵向选择多样化，并不是越新推出就越好，要根据自己的情况选择。

如果你的项目非常短小，就几个礼拜的功夫就可以搞完，就没必要考虑什么纵横分块分层架构了，抡起键盘一顿敲就是了。

当然还有插件化，理论上插件化不能说是项目上的设计，而是产品上的设计。

理论讲完，接下来，我们就开始实战吧。