一、MVCModel‑View‑Controller角色职责Model 模型数据层负责数据、业务逻辑、数据库、网络请求。不关心界面。View 视图UI 界面展示数据接收用户输入。Controller 控制器中间人接收 View 事件调用 Model 处理业务再通知 View 更新界面。执行流程用户操作ViewView 将事件交给ControllerController 操作Model获取 / 修改数据Model 更新完成通知 ControllerController 去更新View经典 MVC 关系图View -- Controller -- ModelView 和 Model不直接通信全部经过 Controller 中转。实际开发变种Android 老式 MVCAndroid 中 Activity/Fragment 既充当 Controller又承担 ViewController 和 View 高度耦合这是 Android MVC 最大痛点。MVC 优点概念简单上手容易Model 独立可复用职责初步拆分MVC 缺点Controller 臃肿大量逻辑堆在 Controller容易形成大 Activity / 大 ControllerView 强依赖 ControllerView 不好独立单元测试耦合高视图改动会修改 Controller 代码二、MVPModel‑View‑Presenter为了解决 MVC 中 Controller 臃肿、View 与 Controller 耦合而诞生。角色职责Model和 MVC 一致数据、业务、网络数据库。View接口抽象定义 UI 要做什么具体页面实现这个接口。View 只做 UI 渲染不处理业务。Presenter替代 Controller业务逻辑全部放在 Presenter。持有 View 接口引用调用 View 接口方法更新 UI。关键点View 是接口Presenter 依赖 View 接口不依赖具体页面。执行流程用户操作 ViewView 回调给PresenterPresenter 调用Model处理数据Model 返回结果给 PresenterPresenter 调用View 接口更新界面View -- Presenter -- ModelModel 完全不知道 PresenterPresenter 持有 View 接口View 不能直接访问 Model。MVP 优点业务逻辑全部剥离到 PresenterActivity/Fragment 只做 View 实现代码清爽Presenter 依赖 View 接口非常方便单元测试Mock View 即可测试业务View、Model 解耦视图可以替换MVP 缺点接口爆炸每一个 UI 动作都要定义 View 接口模板代码多Presenter 持有 View 引用容易发生内存泄漏页面销毁Presenter 还持有 ViewPresenter 依然会随着业务膨胀变庞大内存泄漏问题页面退出必须断开 Presenter 对 View 的引用。三、MVVMModel‑View‑ViewModelMVVM 核心创新数据双向绑定消除大量手动调用 UI 更新的代码。角色职责Model同上数据、业务逻辑。ViewUI 视图页面、xml、模板只负责展示。ViewModel视图模型。保存视图状态、暴露可观察的数据处理业务不持有 View 的引用。ViewModel 向外提供可观察的数据源View 绑定这些数据数据变UI 自动刷新。执行流程用户操作 View通过双向绑定自动修改 ViewModel 中的数据ViewViewModel 调用 Model 执行业务、网络Model 返回数据更新 ViewModel 内部可观察数据数据变化自动驱动 View 刷新不需要手动调用 View 方法View --[数据绑定]-- ViewModel -- ModelViewModel 不知道 View 是谁View 订阅 ViewModel 的数据。技术代表Android Jetpack ViewModelDataBindingVue、Angular、WPF。单向绑定 vs 双向绑定单向绑定ViewModel→View数据变化更新 UI双向绑定View↔ViewModelUI 输入反过来自动回写到 ViewModelMVVM 优点去掉大量 UI 更新模板代码不用写view.setText()这类调用ViewModel 不持有 View规避 MVP 的内存泄漏风险ViewModel 独立易于单元测试Mock Model 即可UI 与业务进一步解耦页面销毁 ViewModel 可以保留状态Jetpack ViewModelMVVM 缺点双向绑定逻辑藏在框架内部调试困难数据流向不直观复杂页面数据状态多ViewModel 依然容易膨胀DataBinding 会增加编译时间数据变更过多容易引发意外 UI 刷新学习成本高需要理解响应式、可观察对象四、三者核心对比表维度MVCMVPMVVM中间人ControllerPresenterViewModelView 与中间层关系View 持有 ControllerController 操作 ViewPresenter 持有View 接口无引用靠数据绑定更新 UI 方式Controller 主动调用 ViewPresenter 调用 View 接口方法数据自动驱动 UIView 是否抽象一般不抽象必须抽象为接口不需要接口绑定字段内存泄漏风险中高Presenter 持有 View低ViewModel 不持有 View模板代码量少多大量 View 接口中等框架接管绑定单元测试困难优秀Mock View 接口优秀Mock 数据调试难度简单中等困难双向绑定黑盒适用场景简单页面快速开发中大型项目重视单元测试复杂页面响应式 UIVue/WPF/Jetpack核心差异通俗总结MVC控制器指挥视图干活视图和控制器容易粘在一起。MVPPresenter 指挥 View 接口干活把 UI 行为抽象成接口方便测试但是接口写得多。MVVM不再手动指挥 View数据一变界面自动变中间人 ViewModel 不认识 View。误区MVVM 不是完全消灭业务复杂度只是转移ViewModel 依然可能臃肿需要配合 UseCase、Repository 进一步分层。五、常见实践建议简单小页面MVC 够用不要过度设计需要大量单元测试、不想引入绑定框架选 MVP复杂 UI、表单多、状态多使用官方响应式框架Jetpack、Vue选 MVVM现实项目不会严格纯净模式经常出现混合架构比如 MVVM 里少量手动调用 View。六、关键陷阱MVC 不要把业务全部写 View 层MVP 一定要页面销毁切断 Presenter‑View 引用防止内存泄漏MVVM 不要把 View 相关逻辑放进 ViewModelViewModel 不能持有 Context、View 实例。如果你需要我可以给你写一份极简伪代码示例分别演示 MVC/MVP/MVVM 代码写法对比。