在鸿蒙（HarmonyOS/OpenHarmony）轻量级 UI 框架（如基于 `UIView`/`UIComponent` 的 LiteOS-A 或 MiniSystem UI 子系统）及典型的 **MVP/MVVM 混合架构**中，`Model` 层的 `saveData` **并不是一个固定函数名或标准接口**，而是一个**语义化概念：指 Model 层将业务数据持久化（persist）到本地存储（如文件、KVStore、SQLite 轻量数据库）或同步至服务端的行为抽象**。 你提到的 `MainPresenter::InformCmdNotify()` 是 Presenter 层对 Model 事件（`Next()` 返回的命令 ID）的响应调度器；而 `Model::saveData()` 则是 Model 层内部**被 Presenter 或其他组件调用、用于落盘/提交数据的核心写入操作**。下面从定义、典型实现、调用时机、与 Presenter 关系四方面详述： --- ### ✅ 1. `saveData` 的本质定义（不是语法关键字，而是设计契约） `saveData()` 是 **Model 层对外暴露的数据持久化能力封装**，其语义为： > “将当前 Model 管理的内存态业务数据（如未读消息计数、已读状态、用户配置、消息列表快照等），以线程安全、事务一致、异常可恢复的方式，写入持久化介质。” 它**不负责 UI 更新、不处理手势、不解析事件** —— 只专注「数据存哪里、怎么存、存得是否可靠」。 --- ### ✅ 2. 典型 `saveData()` 实现示例（以 OpenHarmony KVStore 为例） 假设 `MVVMInformModel` 类中维护了消息状态，其 `saveData()` 可能如下实现： ```cpp // MVVMInformModel.h class MVVMInformModel { public: static MVVMInformModel& GetInstance(); void saveData(); // 👈 公共入口：触发持久化 private: void SaveUnreadCountToStorage(); // 存未读数 void SaveMessageListToStorage(); // 存消息列表（序列化） void SaveConfigFlagsToStorage(); // 存开关配置（如 wechatCallRemind） void SaveDragStatusToStorage(); // 存拖拽状态（CONFIG_SVR_MSG_SLIDE） // 使用 OpenHarmony 提供的轻量级 KVStore（需初始化 g_kvStore） static std::shared_ptr<KvStoreDelegate> g_kvStore; }; ``` ```cpp // MVVMInformModel.cpp #include "distributed_kv_store/kv_store_delegate.h" #include "utils/log.h" void MVVMInformModel::saveData() { if (g_kvStore == nullptr) { HILOG_ERROR(HILOG_MODULE_APP, "KVStore not initialized"); return; } // 1. 保存未读消息数（int32_t） int32_t unreadCount = GetUnreadCount(); g_kvStore->PutInt("inform_unread_count", unreadCount); // 2. 保存消息列表（序列化为 JSON 字符串，或分条存） std::string jsonList = SerializeMessageList(); // 自定义序列化函数 g_kvStore->PutString("inform_message_list_json", jsonList); // 3. 保存配置标志位（bool → int） g_kvStore->PutInt("wechat_call_remind_enabled", static_cast<int>(InformationModel::GetInstance().GetWechatCallRemind())); // 4. 保存拖拽状态（CONFIG_SVR_MSG_SLIDE） #if (defined CONFIG_SVR_MSG_SLIDE) g_kvStore->PutBool("msg_drag_status", GetMsgDragStatus()); #endif // 5. 强制同步刷盘（确保断电不丢） g_kvStore->Sync({{"inform_unread_count", "inform_message_list_json"}}, SyncMode::SYNC_MODE_SYNC); } ``` 📌 **关键点说明：** - 使用 `KvStoreDelegate`（OpenHarmony 分布式 KV 存储）实现跨进程/跨设备一致性（若启用分布式）； - `Sync(..., SYNC_MODE_SYNC)` 保证数据真正写入 Flash，而非仅缓存； - 所有 `PutXxx()` 调用是非阻塞但线程安全的（KVStore 内部加锁）； - `SerializeMessageList()` 通常采用轻量 JSON（如 cJSON）或二进制协议（如 FlatBuffers），避免 XML/完整 JSON 开销。 --- ### ✅ 3. `saveData()` 的典型调用时机（谁在何时调用？） | 调用方 | 触发场景 | 说明 | |--------|----------|------| | **Presenter**（如 `MainPresenter`） | 用户执行“标记全部已读”后：<br>`view_->SetAllMsgRead();` → `model_.saveData();` | Presenter 在完成业务逻辑后，主动通知 Model 持久化 | | **Model 自身**（定时/批量） | 消息批量到达时暂存内存，每 30 秒自动 `saveData()` | 避免高频 I/O，提升性能 | | **系统生命周期回调** | `OnAppTerminate()` / `OnBackground()` 中调用 | 防止退后台时数据丢失 | | **网络同步成功后** | 收到服务端 ACK 后，将最终态 `saveData()` | 保证本地与服务端最终一致 | ⚠️ 注意：`InformCmdNotify()` 中 **不会直接调用 `saveData()`** —— 因为它是「读命令分发器」，只负责响应 `Next()` 返回的 *通知类事件*（如刷新 UI、跳转页面），而非 *变更类事件*（如新增/删除/修改消息）。 真正的 `saveData()` 调用往往发生在： - `MVVMInformModel::AddNewMessage(...)` - `MVVMInformModel::MarkAsRead(id)` - `MVVMInformModel::DeleteMessage(id)` - 或 Presenter 中显式调用（如 `OnAllReadConfirmed()`） --- ### ✅ 4. `saveData()` 与 `InformCmdNotify()` 的协作关系图 ``` [User Action] ↓ [View: Click "Mark All Read"] ↓ [Presenter: OnAllReadClicked()] → model_.MarkAllAsRead() // 内存态更新 → model_.saveData() // ⚠️ 此处才真正落盘！ → view_->RefreshInformation() ↓ [Model: MarkAllAsRead()] → update in-memory list & unreadCount → (optional) trigger Notify(TOPIC_AST_NOTIFY_MSG) → InformCmdNotify() ← 仅用于后续 UI 响应 ``` 即： 🔹 `saveData()` 是 **数据写入动作**（Model 的职责）； 🔹 `InformCmdNotify()` 是 **数据读取/响应动作**（Presenter 协调 View 对 Model 状态变化的反应）； 二者分工明确：**一写一读，一存一显**。 --- ### ✅ 补充：为什么不用 SQLite？轻量系统如何选型？ 在鸿蒙 LiteOS-A / MiniSystem（如智能手表、IoT 设备）中： - ❌ 不适用 SQLite：依赖 `libc` + 文件系统 + 较大内存（>512KB）； - ✅ 优先 KVStore：单键值对、支持加密、分布式、内存占用 < 100KB； - ✅ 备选：自研 `FlashDB`（类似 LittleFS + KV 封装）、或纯文件 + `fopen/fwrite`（无事务，适合只读配置）。 ---