在很多 Android 项目中，我们经常能看到各种 Manager：
这些类似乎什么都能做：
- 管理数据
- 协调业务
- 调用网络
- 操作数据库
- 维护状态
于是一个 Manager 很容易变成这样：
看起来似乎没什么问题，但随着业务增长，这些 Manager 往往会逐渐变成：
业务逻辑、数据逻辑、状态管理全部混在一起。
但问题是：
Manager 从来不是一种架构。
在现代软件架构中，例如 Clean Architecture， 业务逻辑应该被清晰地拆分为：
这篇文章我们就来聊聊：
为什么是时候告别 Manager 了，以及如何用 UseCase + Repository 重建 Android 架构。
一、为什么 Android 项目到处都是 Manager
Android 项目大量使用 Manager，其实是历史原因。
早期 Android Framework 就大量使用这种命名：
例如 Android SDK 中的系统服务几乎都是 Manager。
于是很多开发者也沿用了这种模式：
但这些类在实际项目中通常会承担多种职责：
这就违背了软件架构中最重要的原则：
二、Manager 架构的三个核心问题
随着项目变大，Manager 模式通常会出现三个问题。
1 Manager 会变成“上帝类”
例如：
随着业务增长：
变成一个难以维护的类。
2 业务逻辑和数据逻辑混在一起
例如：
这里其实混合了两种职责：
架构层级被打乱。
3 无法形成清晰的业务边界
当所有逻辑都写在 Manager 里：
ViewModel 直接调用各种方法：
但你很难知道：
代码结构会越来越混乱。
三、Clean Architecture 的解决方案
在 Clean Architecture 中，系统被拆成清晰的层：
在 Android 中通常对应：
职责变得非常清晰：
四、UseCase：业务逻辑的唯一入口
UseCase 的职责只有一个：
例如：
代码示例：
UseCase 的特点：
这就是 业务边界（Business Boundary）。
五、Repository：数据边界
Repository 负责：
例如：
实现类：
Repository 的职责：
例如：
六、最终的 Android 架构
当我们用 UseCase + Repository 重新组织代码时，架构会变成：
每一层职责非常清晰：
七、Manager → Clean Architecture
很多项目其实可以这样迁移：
旧结构：
新结构：
Manager 被自然拆解成：
架构会清晰很多。
八、什么时候 Manager 仍然是合理的
虽然业务代码不推荐使用 Manager，但有两种情况仍然合理：
1 系统能力封装
例如：
这是 系统 API 适配层。
2 第三方 SDK 封装
例如：
用于隔离第三方 SDK。
九、总结
Manager 在 Android 项目中非常常见，但它并不是一种架构模式。
随着业务复杂度增加，Manager 很容易变成：
而在现代 Android 架构中，更推荐使用：
来建立清晰的业务边界和数据边界。
简单来说：
当你开始这样组织代码时，架构会变得更加清晰、可维护。
所以：
结尾：是时候告别什么都往 Manager 里塞的习惯了。
