Android应用架构的发展和实践，你想学的都在这里

[](

)单体应用架构

---

单体应用架构是指我们的项目在单Module时的架构，此时项目一般会划分一些层级，比如UI层，网络层，逻辑层。这些层级怎么进行组织呢？

最开始，大家刚接触Android开发，统统是MVC。MVC的问题是布局文件作为View层，无法承担任何业务逻辑；UI的逻辑和业务逻辑都写在Activity层，在项目体量不大的时候这样完全没有问题。可是当每个页面的业务逻辑变成之前的2倍的时候，代码量也会增长一倍，这大大降低了项目的扩展性和维护性。这个时候可能你会通过抽取重构的方式来缓解这种局面，可是随着业务增多，不久又会陷入这种局面。

慢慢的我们发现，将Activity层的所有业务逻辑抽出去，只剩下UI相关逻辑。这样既清晰，又能解决上面的问题，所以MVP出现了。在MVP中，Activity充当UI层，Presenter充当业务逻辑；UI层和逻辑层交互，逻辑层和数据层交互。采用接口回调，或者EventBus的方式让UI层和逻辑层进行通信。

客户端开发主要是和UI打交道，最好的一定是MVVM。使用databind，或者LiveData可以替代接口回调和EventBus。关于上面这些内容，我在另一篇文章中有更详细的说明：[juejin.im/post/5c47e1…](

)

MVVM架构下的单体应用项目，应该有这样几个层级：

• 数据层，专门负责数据的存取，方式不限（网络数据，File数据或者KV存储）

• VM层，专门负责执行业务逻辑和数据的处理，与数据层有交互

• UI层，负责显示每个界面，弹窗等，与VM层有交互

如下图示：

[](

)单Module到多Module演变

---

这个演变非常像后台应用的单体架构到微服务架构的演变，适用于公司内部有多个产品需要同时迭代的场景。随着单体应用向多Module的演变，原先的各个组件都独立到不同的Module中去了。

大概有两个阶段：

1. 单一入口Module + 公共类库Module

2. 多入口Module + 多公共业务Module + 公共类库Module

第一个阶段很好理解，也是一个自然而然的演变。因为项目中很多公共的模块，比如日志模块，网络模块，数据模块。这些模块与逻辑无关，可以给任何项目使用，所以单独开一个Module或者传到maven库。如果要开发新的项目，那也只是将公共类库Module移植过去即可。

所以，第一阶段的项目Module结构大概是这样：

• App Module，负责提供项目入口，完成各个业务逻辑功能

• Library Module，负责提供项目公共组件，比如日志组件，网络组件，存储组件

• 其他三方库Module

以抖音App为例：

上面的阶段能做到功能模块的重用，但是没有涉及到业务逻辑的重用。新项目也有登录注册功能，难道要重新写一遍么？

你可能担心两个项目的登录注册逻辑能一样么，界面也不可能一样啊。界面肯定是不一样的，但是登录注册逻辑大部分是一样的。这就说明我们其实可以对一些公共业务划分Module，对于不一样的地方，完全可以动态化。但是公共业务不能划入类库Module中，因为通用性不够；还要注意业务Module的抽离本着只抽业务，不抽UI的原则。

当业务Module和类库Module抽离之后，不同的项目我们可以添加不同的入口Module，入口Module更多是完成入口功能，和UI定制化功能，以及完成一部分差异化的实在不能共用的业务逻辑。

所以，第二阶段的项目Module结构大概是这样：

• App1 Module，负责提供App1的入口，完成App1的所有UI逻辑和部分不能共用的业务逻辑

• App2 Module，负责提供App2的入口，完成App1的所有UI逻辑和部分不能共用的业务逻辑

• Login Module，负责提供登录注册功能

• Video Module，负责提供视频相关功能

• Library Module，负责提供公共模块功能

• 其他三方Module

客户端开发中，UI的变数最大，上面的Module划分尽量将变化少的东西复用，将变化大的东西剥离出来。

他们之间的调用关系应该符合这样的规则：

• App入口Module可以调用业务Module和Library Module；

• 业务Module可以调用Library Module，业务Module之间不能相互调用，也但不能调用App入口Module，目的是保持单向调用流程