作为 Android 开发者，我们在构建应用程序时，往往会面临一个核心的挑战：如何组织代码才能让项目不仅模块化清晰，还能轻松应对需求的不断变化？答案很简单——采用成熟的软件架构模式。一个优秀的架构就像建筑的蓝图，它不仅能赋予项目文件良好的逻辑分层，还能确保所有核心代码都能被单元测试覆盖。这不仅让我们更容易维护软件，也使得在未来扩展应用功能时不再像是在“走钢丝”。
在业界公认的众多 Android 架构中，MVP（Model – View – Presenter）和 MVVM（Model – View – ViewModel）是目前开发者中最流行的两种架构模式。在这篇文章中，我们将深入探讨这两者的区别，并通过实际的代码示例，帮助你做出更明智的技术选择。
Model – View – Presenter (MVP) 模式详解
MVP 架构模式早在 Android 发展初期就为了解决代码混乱问题而应运而生。MVP 之所以被广泛接受，是因为它极大地提升了代码的模块化程度、可测试性，并产生了一个相对整洁、易于维护的代码库。在 MVP 中，我们将应用严格划分为三个核心组件：
- Model（模型）：数据存储层。它负责处理领域逻辑（现实世界的业务规则）以及与数据库和网络层的通信。你可以把它想象成后台工作者，不关心 UI，只关心数据的获取和处理。
- View（视图）：UI（用户界面）层。它提供数据的可视化展示，并跟踪用户的操作（如点击事件）。但在 MVP 中，View 是被动的，它不包含任何业务逻辑，只负责将用户指令转发给 Presenter。
- Presenter（展示器）：这是 MVP 的核心大脑。它从 Model 获取数据，应用 UI 逻辑来决定显示什么内容，并管理 View 的状态。Presenter 就像是一个中间人，它根据来自 View 的用户输入通知 Model 进行操作，然后再将结果格式化后更新回 View。
#### MVP 的实际代码实现
让我们来看一个具体的例子：假设我们需要在界面上显示用户信息。
首先，定义 Model 层接口：
// Model 接口：定义数据的获取方式
public interface User {
String getName();
String getEmail();
}
// 具体的数据模型类
public class UserData implements User {
private String name;
private String email;
public UserData(String name, String email) {
this.name = name;
this.email = email;
}
@Override
public String getName() { return name; }
@Override
public String getEmail() { return email; }
}
接下来，是 View 和 Presenter 的交互：
为了确保可测试性，我们需要定义接口，让 Presenter 不依赖具体的 Activity 或 Fragment。
// View 接口：Presenter 将通过这个接口与 UI 通信
public interface UserView {
void showLoading();
void hideLoading();
void displayUser(User user);
void showError(String message);
}
// Presenter 接口：View 将通过这个接口触发事件
public interface UserPresenter {
void loadUserDetails();
}
然后是 Presenter 的具体实现：
import java.util.Random;
public class UserPresenterImpl implements UserPresenter {
private UserView userView;
// 构造函数注入 View
public UserPresenterImpl(UserView userView) {
this.userView = userView;
}
@Override
public void loadUserDetails() {
if (userView != null) {
userView.showLoading();
}
// 模拟网络请求或数据库查询
new Thread(() -> {
try {
Thread.sleep(2000); // 模拟延迟
// 模拟获取数据
User user = new UserData("张三", "[email protected]");
// 在 UI 线程更新 View
// 注意：实际开发中通常使用 Handler 或 RxJava 切换线程
if (userView != null) {
userView.hideLoading();
userView.displayUser(user);
}
} catch (InterruptedException e) {
if (userView != null) {
userView.showError("加载失败");
}
}
}).start();
}
}
最后，在 Activity (View) 中连接它们：
import android.os.Bundle;
import android.widget.TextView;
import android.widget.Toast;
import androidx.appcompat.app.AppCompatActivity;
public class MainActivity extends AppCompatActivity implements UserView {
private TextView nameTextView;
private TextView emailTextView;
private UserPresenter presenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
// 初始化视图
nameTextView = findViewById(R.id.text_name);
emailTextView = findViewById(R.id.text_email);
// 创建 Presenter 实例，并将 this (View) 传递给它
presenter = new UserPresenterImpl(this);
// 触发数据加载
presenter.loadUserDetails();
}
@Override
public void showLoading() {
// 显示进度条，代码略
}
@Override
public void hideLoading() {
// 隐藏进度条，代码略
}
@Override
public void displayUser(User user) {
nameTextView.setText(user.getName());
emailTextView.setText(user.getEmail());
}
@Override
public void showError(String message) {
Toast.makeText(this, message, Toast.LENGTH_SHORT).show();
}
@Override
protected void onDestroy() {
super.onDestroy();
// 防止内存泄漏：在 View 销毁时断开与 Presenter 的联系
// 在实际应用中，我们通常会在 Presenter 中添加 detachView 方法
}
}
在这个例子中，你可以看到 Presenter 是如何作为中间层来协调 Model 和 View 的。View 不关心数据从哪里来，Presenter 不关心 UI 如何绘制，职责分明。
Model — View — ViewModel (MVVM) 模式详解
MVVM 模式与 MVP 有相似之处，因为它也旨在分离关注点。然而，MVVM 引入了 ViewModel 和 Data Binding（数据绑定） 的概念，解决了 MVP 中存在的一些痛点。在 MVP 中，Presenter 需要手动调用 View 的方法（如 view.showText()）来更新 UI，这往往导致大量的样板代码。而 MVVM 主张通过数据驱动 UI，让 View 的状态与 ViewModel 中的数据自动同步。
MVVM 的独立代码层包括：
- Model（模型）：与 MVP 类似，负责数据源的抽象。Model 和 ViewModel 协同工作以获取和保存数据。
- View（视图）：该层负责观察 ViewModel。在 Android 中，我们通常使用 INLINECODE8b4bd75f 或 INLINECODE35d9a4e5 以及 DataBinding 来实现。View 不包含任何业务逻辑，只负责反映数据的变化。
- ViewModel（视图模型）：它不持有 View 的引用（这是与 Presenter 的关键区别）。它暴露与 View 相关的数据流（通常是 Observable 对象），并充当 Model 和 View 之间的桥梁。
#### MVVM 的实际代码实现
让我们用 MVVM 来实现同样的用户展示功能。为了符合现代 Android 开发标准，我们将结合 ViewModel 和 LiveData（或 Data Binding）。
首先，定义 ViewModel：
import androidx.lifecycle.LiveData;
import androidx.lifecycle.MutableLiveData;
import androidx.lifecycle.ViewModel;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class UserViewModel extends ViewModel {
// 使用 MutableLiveData 来让 View 能够观察数据变化
private final MutableLiveData userLiveData = new MutableLiveData();
private final MutableLiveData errorLiveData = new MutableLiveData();
private final MutableLiveData loadingLiveData = new MutableLiveData();
// 公开的不可变 LiveData，供 View 观察
public LiveData getUserLiveData() { return userLiveData; }
public LiveData getErrorLiveData() { return errorLiveData; }
public LiveData getLoadingLiveData() { return loadingLiveData; }
private final ExecutorService executor = Executors.newSingleThreadExecutor();
public void loadUserDetails() {
loadingLiveData.postValue(true);
executor.execute(() -> {
try {
Thread.sleep(2000); // 模拟网络请求
User user = new UserData("李四", "[email protected]");
// 数据更新会自动通知观察它的 View
userLiveData.postValue(user);
loadingLiveData.postValue(false);
} catch (InterruptedException e) {
errorLiveData.postValue("加载失败");
loadingLiveData.postValue(false);
}
});
}
@Override
protected void onCleared() {
super.onCleared();
// 清理资源，防止内存泄漏
executor.shutdown();
}
}
然后，在 View (Activity) 中观察数据：
import android.os.Bundle;
import android.widget.TextView;
import android.widget.Toast;
import androidx.appcompat.app.AppCompatActivity;
import androidx.lifecycle.Observer;
import androidx.lifecycle.ViewModelProvider;
public class UserActivity extends AppCompatActivity {
private TextView nameTextView;
private TextView emailTextView;
private UserViewModel viewModel;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_user);
nameTextView = findViewById(R.id.text_name);
emailTextView = findViewById(R.id.text_email);
// 获取 ViewModel 实例
// 注意：ViewModel 不会因为屏幕旋转而销毁，这解决了 MVP 的一大痛点
viewModel = new ViewModelProvider(this).get(UserViewModel.class);
// 观察数据变化，无需手动调用 updateUI 方法
viewModel.getUserLiveData().observe(this, new Observer() {
@Override
public void onChanged(User user) {
// 当数据变化时，UI 自动更新
if (user != null) {
nameTextView.setText(user.getName());
emailTextView.setText(user.getEmail());
}
}
});
viewModel.getErrorLiveData().observe(this, error -> {
Toast.makeText(this, error, Toast.LENGTH_SHORT).show();
});
// 加载数据
viewModel.loadUserDetails();
}
}
在这个例子中，你发现了吗？Activity 不需要知道谁提供了数据，也不需要手动调用 setText 来响应 Presenter 的命令。它只是“盯着” ViewModel 中的数据，一旦数据变了，UI 就跟着变。这就是 MVVM 的核心魅力。
MVP 与 MVVM 设计模式的深度对比
为了让你在项目选型时更有底气，我们将从多个维度对这两种架构进行深度剖析。
MVP (Model View Presenter)
:—
单向（主要）：通过 Presenter 作为中间人解决 View 依赖性问题。View 调用 Presenter 方法，Presenter 调用 View 接口更新 UI。
一对一：一个 Presenter 通常只对应一个 View 接口。虽然复用困难，但逻辑非常清晰。
n
命令式：Presenter 需要显式调用 view.updateData(data)。不需要可观察对象。
Presenter 持有 View 的接口引用。这使得测试 UI 逻辑时需要模拟 View 接口。
文件较多：Presenter 和 View 接口通常会产生大量的类文件。
较好：由于业务逻辑在 Presenter 中，且与 View 解耦，测试变得容易。但 View 和 Presenter 的紧密联系（通过接口）可能会使编写测试用例稍微繁琐。
维护性取决于开发者的自律。如果不小心，Presenter 容易变成处理所有事情的“上帝类”。
适用于简单到中等复杂的应用，或者团队对响应式编程尚不熟悉的情况。
相对直观。如果 UI 没更新，去断点 Presenter。
传统标准，契合度良好，但在处理配置更改（如屏幕旋转）时需要额外处理（如 onSaveInstanceState）。
性能优化与最佳实践
在深入研究了代码和理论之后，我想分享一些在实际开发中至关重要的经验。
- 解决内存泄漏：
* MVP：由于 Presenter 持有 View 的引用，如果异步任务（如网络请求）在 Activity 销毁后才结束，Presenter 可能会尝试更新一个已销毁的 View，导致崩溃或内存泄漏。
* 解决方案：在 Presenter 中添加 INLINECODE1da52b38 方法，并在 Activity 的 INLINECODE786a6b4f 中调用。同时，在 Presenter 中使用 WeakReference 引用 View。
* MVVM：ViewModel 的生命周期长于 View（Activity），但 ViewModel 本身不持有 View，所以避免了大部分泄漏问题。但在使用 LiveData 时，注意粘性事件可能导致的问题。
- 处理配置更改：
* MVP：屏幕旋转会导致 Activity 重建，Presenter 也随之重建（除非你手动保存）。通常需要配合 INLINECODE55338b6e 或 INLINECODE934e3ef3 来保存状态，这增加了代码复杂度。
* MVVM：这是它的杀手锏。ViewModel 在配置更改期间不会被销毁。旋转屏幕后，Activity 重新连接到同一个 ViewModel 实例，数据自动保留，用户体验无缝衔接。
- 避免“上帝类”：
* 无论在 MVP 还是 MVVM 中，不要让 Presenter 或 ViewModel 承担过多的职责。如果代码行数过多，考虑使用 UseCase（用例）模式来拆分业务逻辑，或者引入 Repository（仓库）模式来统一管理数据源。
总结与下一步
现在我们已经全面剖析了这两种架构。如果你正在开发一个中小型项目，且团队对响应式编程不太熟悉，MVP 是一个非常稳健、易于理解的选择，它强制分离了 UI 和逻辑。然而，如果你希望拥抱现代 Android 开发，追求极致的可测试性，并且希望自动处理屏幕旋转等状态问题，MVVM 配合 Google 的 Jetpack 组件无疑是未来的主流方向。
给你的建议是： 如果你是初学者，先尝试写一个 MVP 项目，理解分层思想；然后立即转向 MVVM，因为你会发现它能让你写出更简洁、更健壮的代码。
希望这篇文章能帮助你清晰地理解 MVP 和 MVVM 的区别，并为你下一个 Android 项目选择合适的架构提供有力参考。