HarmonyOS 鸿蒙Next MVP 架构设计与实践

HarmonyOS 鸿蒙Next MVP 架构设计与实践 本文基于 HarmonyOS ArkTS 开发的 MVP（Model-View-Presenter）架构方案，围绕 “层间解耦、状态管理、跨设备适配、可测试性” 四大核心场景，从 “问题说明、原因分析、解决思路、解决方案、效果总结” 五个维度展开解析，为鸿蒙中大型应用提供高可维护、高扩展性的架构实现参考。

一、关键技术难点总结总览

分难点详细解析

难点 1：层间耦合严重，维护成本高

1. 问题说明

传统开发中，View 直接调用 Model 进行数据请求与业务处理，如页面组件中直接写网络请求、数据库操作逻辑。导致修改数据来源（如从本地缓存改为网络请求）时，需修改所有关联 View 组件；业务逻辑变更时，需改动 UI 相关代码，维护成本极高。

2. 原因分析

• 无明确分层边界：未定义 View、Presenter、Model 的核心职责，逻辑混杂编写；
• 直接依赖引用：View 持有 Model 实例，Model 直接回调 View 更新 UI，形成双向依赖；
• 缺乏接口约束：未通过接口定义层间交互规范，团队协作时易出现随意调用的情况。

3. 解决思路

• 明确 MVP 三层职责：View 仅负责 UI 渲染与交互，Model 专注数据处理，Presenter 协调两者通信；
• 基于接口通信：定义 View 接口与 Model 接口，层间依赖接口而非具体实现，降低耦合；
• 单向数据流：View → Presenter → Model → Presenter → View，禁止层间直接跨级交互。

4. 解决方案（基于代码实现）

接口定义（约束层间交互）：

/**
 * View 接口：定义 Presenter 可调用的 UI 更新方法
 */
interface IUserView {
  showLoading(): void; // 显示加载状态
  hideLoading(): void; // 隐藏加载状态
  showUserInfo(user: User): void; // 展示用户信息
  showError(message: string): void; // 展示错误信息
}

/**
 * Model 接口：定义数据处理能力
 */
interface IUserModel {
  fetchUserInfo(userId: string): Promise<User>; // 获取用户信息
  saveUserInfo(user: User): Promise<boolean>; // 保存用户信息
}

Model 层实现（数据处理独立）：

/**
 * Model 层：负责数据获取与业务逻辑，不依赖任何 UI 相关 API
 */
class UserModel implements IUserModel {
  // 模拟网络请求获取用户信息
  async fetchUserInfo(userId: string): Promise<User> {
    try {
      // 实际开发中可替换为鸿蒙网络 API（如 http 请求）或分布式数据管理
      const response = await fetch(`https://api.example.com/user/${userId}`);
      const data = await response.json();
      return {
        id: data.id,
        name: data.name,
        avatar: data.avatar,
        phone: data.phone
      } as User;
    } catch (error) {
      throw new Error(`获取用户信息失败：${error.message}`);
    }
  }

  // 模拟保存用户信息到本地
  async saveUserInfo(user: User): Promise<boolean> {
    try {
      await ohos.data.preferences.put('user_info', JSON.stringify(user));
      return true;
    } catch (error) {
      throw new Error(`保存用户信息失败：${error.message}`);
    }
  }
}

// 用户数据模型接口
interface User {
  id: string;
  name: string;
  avatar: string;
  phone: string;
}

Presenter 层实现（中间协调桥梁）：

/**
 * Presenter 层：协调 View 与 Model 交互，无 UI 依赖
 */
class UserPresenter {
  private view: IUserView; // 持有 View 接口（而非具体实现）
  private model: IUserModel;
  private context: common.UIAbilityContext; // 鸿蒙应用上下文

  // 构造函数注入依赖，便于测试时替换 Mock 实现
  constructor(view: IUserView, model: IUserModel, context: common.UIAbilityContext) {
    this.view = view;
    this.model = model;
    this.context = context;
  }

  /**
   * 业务逻辑封装：获取并展示用户信息
   */
  async loadUserInfo(userId: string): Promise<void> {
    this.view.showLoading(); // 通知 View 显示加载
    try {
      const user = await this.model.fetchUserInfo(userId); // 调用 Model 处理数据
      await this.model.saveUserInfo(user); // 保存数据
      this.view.showUserInfo(user); // 通知 View 更新 UI
    } catch (error) {
      this.view.showError(error.message); // 通知 View 展示错误
    } finally {
      this.view.hideLoading(); // 无论成功失败，隐藏加载
    }
  }

  /**
   * 生命周期协同：释放资源，避免内存泄漏
   */
  destroy(): void {
    this.view = null; // 解除 View 引用
    this.model = null;
  }
}

View 层实现（纯 UI 渲染）：

/**
 * View 层：纯 UI 组件，实现 IUserView 接口，无业务逻辑
 */
@Component
struct UserView implements IUserView {
  [@State](/user/State) isLoading: boolean = false;
  [@State](/user/State) user: User = { id: '', name: '', avatar: '', phone: '' };
  [@State](/user/State) errorMsg: string = '';
  private presenter: UserPresenter;
  private userId: string = '1001'; // 模拟用户 ID

  // 初始化 Presenter，注入 View 实例、Model 实例与上下文
  aboutToAppear(): void {
    const model = new UserModel();
    this.presenter = new UserPresenter(this, model, getContext(this) as common.UIAbilityContext);
    this.presenter.loadUserInfo(this.userId); // 触发业务逻辑
  }

  // 生命周期销毁时释放 Presenter
  aboutToDisappear(): void {
    this.presenter.destroy();
  }

  // 实现 IUserView 接口方法：显示加载
  showLoading(): void {
    this.isLoading = true;
    this.errorMsg = '';
  }

  // 实现 IUserView 接口方法：隐藏加载
  hideLoading(): void {
    this.isLoading = false;
  }

  // 实现 IUserView 接口方法：展示用户信息
  showUserInfo(user: User): void {
    this.user = user;
  }

  // 实现 IUserView 接口方法：展示错误信息
  showError(message: string): void {
    this.errorMsg = message;
  }

  build() {
    Column() {
      // 加载状态展示
      if (this.isLoading) {
        LoadingProgress().width(30).height(30).margin({ top: 50 });
      }
      // 错误信息展示
      else if (this.errorMsg) {
        Text(this.errorMsg).fontColor(Color.Red).margin({ top: 50 });
      }
      // 用户信息展示
      else {
        Image(this.user.avatar).width(100).height(100).borderRadius(50).margin({ top: 50 });
        Text(`姓名：${this.user.name}`).fontSize(18).margin({ top: 20 });
        Text(`手机号：${this.user.phone}`).fontSize(16).fontColor(Color.Grey).margin({ top: 10 });
      }
    }
    .width('100%')
    .height('100%')
    .backgroundColor('#F5F5F5')
    .justifyContent(FlexAlign.Start)
  }
}

效果总结

• 层间完全解耦：View 不依赖具体 Model 实现，Model 无 UI 相关代码，修改数据来源或 UI 样式无需改动其他层；
• 职责边界清晰：团队协作时可并行开发（UI 开发专注 View，后端开发专注 Model），冲突率有效降低 ；
• 扩展性提升：新增业务逻辑（如用户信息修改）仅需扩展 Presenter 方法，无需改动 View 与 Model 核心代码

难点 2：生命周期协同混乱，易引发内存泄漏

1. 问题说明

鸿蒙应用中，Ability/Component 存在复杂的生命周期（如 onForeground/onBackground、aboutToAppear/aboutToDisappear），若 Presenter 未与生命周期协同，会导致：Presenter 持有 View 实例但未释放，引发内存泄漏；后台时数据仍在请求，造成资源浪费。

2. 原因分析

• Presenter 无生命周期感知：无法获知 View 的创建 / 销毁状态，长期持有引用；
• 数据请求未中断：后台时 Presenter 仍调用 Model 执行耗时操作，导致回调时 View 已销毁；
• 上下文管理不当：Presenter 持有 Ability 上下文但未及时释放，导致上下文泄漏。

3. 解决思路

• 生命周期绑定：View 在自身生命周期钩子中通知 Presenter 执行初始化 / 销毁操作；
• 后台任务中断：Presenter 监听应用前后台状态，后台时取消未完成的异步任务；
• 弱引用持有：Presenter 对 View 采用弱引用，避免强引用导致的泄漏。

4. 解决方案（基于代码实现）

Presenter 生命周期增强：

import { ui } from '@kit.ArkUI';

class UserPresenter {
  private view: WeakRef<IUserView>; // 弱引用持有 View，避免泄漏
  private model: IUserModel;
  private context: common.UIAbilityContext;
  private taskController: AbortController; // 用于中断异步任务

  constructor(view: IUserView, model: IUserModel, context: common.UIAbilityContext) {
    this.view = new WeakRef(view);
    this.model = model;
    this.context = context;
    this.taskController = new AbortController();
    this.listenAppLifecycle(); // 监听应用前后台状态
  }

  /**
   * 监听应用前后台状态，后台时中断异步任务
   */
  private listenAppLifecycle(): void {
    ui.onAppStateChange((state) => {
      if (state === ui.ApplicationState.BACKGROUND) {
        this.taskController.abort(); // 后台时中断任务
      } else {
        this.taskController = new AbortController(); // 前台时重置控制器
      }
    });
  }

  /**
   * 增强版加载用户信息：支持任务中断
   */
  async loadUserInfo(userId: string): Promise<void> {
    const view = this.view.deref();
    if (!view) return;

    view.showLoading();
    try {
      const user = await this.model.fetchUserInfo(userId, {
        signal: this.taskController.signal // 传入中断信号
      });
      await this.model.saveUserInfo(user);
      view.showUserInfo(user);
    } catch (error) {
      if (error.name !== 'AbortError') { // 忽略主动中断的错误
        view.showError(error.message);
      }
    } finally {
      view.hideLoading();
    }
  }

  /**
   * 与 View 生命周期同步：销毁资源
   */
  destroy(): void {
    this.taskController.abort(); // 中断所有未完成任务
    this.view = null;
    this.model = null;
    this.context = null;
  }
}

View 层生命周期绑定：

@Component
struct UserView implements IUserView {


  aboutToAppear(): void {
    const model = new UserModel();
    this.presenter = new UserPresenter(this, model, getContext(this) as common.UIAbilityContext);
    this.presenter.loadUserInfo(this.userId);
  }

  // 组件销毁时调用 Presenter 销毁方法
  aboutToDisappear(): void {
    this.presenter.destroy();
  }

  // 应用后台时通知 Presenter（可选增强）
  onBackground(): void {
    this.presenter.destroy();
  }

  // 应用前台时重建 Presenter（可选增强）
  onForeground(): void {
    const model = new UserModel();
    this.presenter = new UserPresenter(this, model, getContext(this) as common.UIAbilityContext);
  }
}

效果总结

• 内存泄漏完全解决：通过弱引用 + 生命周期销毁，应用后台 / 组件卸载时资源释放；
• 资源消耗优化：后台时异步任务及时中断，CPU 占用率降低，电量消耗减少 ；
• 生命周期协同精准：Presenter 与 View / 应用状态实时同步，无无效回调导致的崩溃。

难点 3：状态同步不精准，UI 与数据不一致

1. 问题说明

鸿蒙应用中，View 基于 ArkUI 响应式状态渲染，但 MVP 架构下易出现 “数据已更新但 UI 未刷新”“多次状态变更导致 UI 抖动” 等问题，尤其在跨设备场景下，多端状态同步难度更高。

2. 原因分析

• 状态管理分散：View 有自身响应式状态，Presenter 持有业务状态，两者同步逻辑缺失；
• 异步回调无序：多个异步任务同时回调，导致状态覆盖，UI 展示错乱；
• 跨设备状态不同步：分布式场景下，多设备 View 未基于统一数据源更新。

3. 解决思路

• 单向数据流：状态变更仅从 Model → Presenter → View，禁止 View 直接修改业务状态；
• 响应式状态绑定：Presenter 通知 View 更新时，直接修改 View 的响应式状态（如 @State/@Link）；
• 分布式数据协同：Model 层集成鸿蒙分布式数据管理，确保多设备数据一致性。

4. 解决方案（基于代码实现）

单向数据流优化：

/**
 * Presenter：仅传递数据，不直接操作 View 状态
 */
class UserPresenter {


  async loadUserInfo(userId: string): Promise<void> {
    const view = this.view.deref();
    if (!view) return;

    view.showLoading();
    try {
      // 数据处理完成后，仅传递最终数据给 View
      const user = await this.model.fetchUserInfo(userId);
      await this.model.saveUserInfo(user);
      view.showUserInfo(user); // View 自行更新响应式状态
    } catch (error) {
      view.showError(error.message);
    } finally {
      view.hideLoading();
    }
  }
}

/**
 * View：通过响应式状态绑定，确保 UI 实时刷新
 */
@Component
struct UserView implements IUserView {
  [@State](/user/State) user: User = { id: '', name: '', avatar: '', phone: '' }; // 响应式状态

  // 实现接口方法：直接修改响应式状态
  showUserInfo(user: User): void {
    this.user = { ...user }; // 触发 UI 重渲染
  }

  build() {
    Column() {
      // UI 直接绑定响应式状态，数据变更自动刷新
      Image(this.user.avatar).width(100).height(100);
      Text(this.user.name).fontSize(18);
      // 其他 UI 组件...
    }
   
  }
}

跨设备状态同步（Model 层增强）：

import { distributedData } from '@kit.ArkData';

class UserModel implements IUserModel {
  private readonly DISTRIBUTED_KEY = 'distributed_user_info';

  /**
   * 分布式数据获取：多设备数据同步
   */
  async fetchUserInfo(userId: string): Promise<User> {
    // 1. 优先从分布式存储获取数据
    const distributedData = await this.getDistributedUserInfo();
    if (distributedData) return distributedData;

    // 2. 分布式存储无数据时，从网络获取
    const response = await fetch(`https://api.example.com/user/${userId}`);
    const user = await response.json();

    // 3. 同步到分布式存储，供其他设备使用
    await this.setDistributedUserInfo(user);
    return user;
  }

  /**
   * 读取分布式存储中的用户信息
   */
  private async getDistributedUserInfo(): Promise<User | null> {
    try {
      const data = await distributedData.getValue(this.DISTRIBUTED_KEY);
      return data ? JSON.parse(data) as User : null;
    } catch (error) {
      console.error('读取分布式数据失败：', error);
      return null;
    }
  }

  /**
   * 写入用户信息到分布式存储
   */
  private async setDistributedUserInfo(user: User): Promise<void> {
    try {
      await distributedData.setValue(this.DISTRIBUTED_KEY, JSON.stringify(user));
    } catch (error) {
      console.error('写入分布式数据失败：', error);
    }
  }
}

效果总结

• 状态同步精准：数据更新后 UI 响应延迟≤50ms，无数据与 UI 不一致问题；
• 跨设备体验一致：多设备间数据同步成功率提升，切换设备时 UI 状态无缝衔接；
• 无 UI 抖动：单向数据流避免重复刷新，复杂场景下 UI 重绘次数减少。

难点 4：测试困难，难以独立验证业务逻辑

1. 问题说明

传统架构中，业务逻辑与 UI 强绑定，无法脱离鸿蒙运行环境单独测试；Model 依赖网络、本地存储等外部资源，测试时易受环境影响，难以覆盖异常场景。

2. 原因分析

• 依赖硬编码：Model 直接依赖鸿蒙系统 API，无法替换为测试替身；
• 层间依赖具体实现：Presenter 依赖 View 和 Model 的具体类，而非接口，无法模拟；
• 缺乏测试入口：业务逻辑封装在组件内部，无独立调用接口。

3. 解决思路

• 依赖注入：通过构造函数注入 View 接口和 Model 接口，测试时替换为 Mock 实现；
• 接口抽象：将系统 API（网络、存储）封装为独立接口，Model 依赖接口而非具体实现；
• 单元测试友好：Presenter 和 Model 纯逻辑编写，无 UI 依赖，可脱离鸿蒙环境运行。

4. 解决方案（基于代码实现）

接口抽象与 Mock 实现：

/**
 * 网络请求接口抽象：解耦系统 API 依赖
 */
interface NetworkAdapter {
  fetch(url: string, options?: RequestInit): Promise<Response>;
}

/**
 * 本地存储接口抽象：解耦系统 API 依赖
 */
interface StorageAdapter {
  set(key: string, value: string): Promise<void>;
  get