在过去的几年里我先后参与了多款应用的架构设计与重构。面试中我常被问到“Android 架构、架构模式、设计模式到底有什么关系”，于是我把自己的实践经验和理论整理成一份结构化的思考。老实说，

从痛点回顾来看。为什么架构和模式如此关键？

现实项目往往遇到以下痛点：

• 代码量大但质量参差，难以维护。
• 新成员上手慢，团队内部代码规范不统一。
• 功能迭代频繁导致原有模块频繁被拆改。
• 业务逻辑混杂在 UI 层，导致视图层职责失衡。
• 重写成本高，难以持续迭代。

这些痛点的根源在于缺乏清晰的纵向分层、横向拆分还有设计原则支撑。按理说，下面从宏观到微观逐层剖析。

纵向分层与横向拆分

纵向分层

• Google 官方架构 / Clean Architecture / DDD: UI → Domain/Business → Data。职责划分清晰，依赖方向单向。

横向拆分

• 组件化 / 微服务等: 将业务层细化为可复用组件。例如登录/注册等功能模块，接下来在每个模块内部采用 MVVM/MVI 等模式进行数据流管理。不过，

再看一句话。

纵向 + 横向 = 宏观全局视角；让职责划分清晰、解耦协作更高效、维护成本更低。话说回来，

架构模式与设计模式区别

• 架构模式：中观骨架。 规范模块结构、代码分层及数据流动。老实说，例如 MVC、MVVM、MVP 等。
• 设计模式：微观实现细节，用来解决类之间的耦合、复用与 问题。其原则是底层基石，指导如何写出高质量代码；其模式是具体实现招式。

设计原则这方面，SOLID + 补充原则

SOLID • 单一职责 • 开闭原则 • 里氏替换 • 接口隔离 • 依赖倒置
再看补充原则。迪米特法则 、DRY、KISS、YAGNI
S O L I D + L O D 告诉你怎么做对；KISS/YAGNI 告诉你别做过头；DRY 别重复，

从经典案例来看，Activity 与 Repository 的耦合问题

// 原始代码。违反了多个原则
class CarHvacActivity : AppCompatActivity {
private val hvacViewModel: CarHvacViewModel by viewModels {
object : ViewModelProvider.Factory {
override fun  create: T {
val car = Car.createCar
val carPropertyManager = car.getCarManager as CarPropertyManager
val dataSource = CarPropertyDataSource
val repository = CarHvacRepository
return CarHvacViewModel as T
}
}
}
// 重构后使用工厂模式
private val factoryHvacViewModel: CarHvacViewModel by viewModels {
CarHvacViewModelFactory
}
// 再使用 Hilt DI
private val hiltHvacViewModel: CarHvacViewModel by viewModels
}
// 必要依赖：
implementation
implementation
implementation
implementation

主要这方面，让 ViewModel 支持协程 & 自动化 DI，避免 Activity 与 Repository 的直接耦合。

为何这么麻烦？直接 UI 调用 Repository 为什么不可行？

1. 再看直接原因，违反了单向依赖原则
2. 违反了SRP 和 DIP 原则；职责不清晰导致维护成本飙升。
3. 数据流无法管理——UI 会承担状态管理、业务逻辑与线程调度全部责任，相当于回到 MVC 的老问题。

说到讨论。真实项目中的困境与对策

国内许多公司起初只关注开发进度，而忽视整体架构。招聘时技术水平参差不齐，导致后期出现大量技术债务。当业务需求增大时：

● 维护成本剧增，Bug 难以定位；  ● 重写或大范围重构变得不可承受；  ● 团队士气受挫。