soft_bus/docs/主应用进程m_busCore使用分析.md

主应用进程 m_busCore 使用分析

📋 概述

本文档分析主应用进程 (soft_bus) 是否还需要 m_busCore (DeviceBusCore 实例)，以及在分离架构中的使用场景。

🔍 当前使用场景

1. 数据写入操作（需要写入数据库）

SerialManager 和 CanManager

• 位置: src/serial_manager/, src/can_manager/
• 用途:
  • storeRawData() - 存储原始数据到数据库
  • storeBusMessage() - 存储总线消息到数据库
  • registerDevice() - 注册设备到数据库
  • updateDevice() - 更新设备信息到数据库
  • updateDeviceStatus() - 更新设备状态到数据库
• 说明: SerialManager 和 CanManager 在主应用中运行，负责设备发现、数据接收和存储

SerialDockPage

• 位置: src/view_serial/serialdockpage.cpp
• 用途:
  • updateDevice() - 更新设备配置（串口配置、Modbus配置）
• 说明: 用户修改设备配置后，需要更新到数据库

2. 数据查询操作（需要读取数据库）

UI 组件

• RawDataTableWidget: 查询原始数据 (queryRawData())
• BusDataTableWidget: 查询总线消息 (queryBusMessages())
• DeviceLogDialog: 查询设备信息和历史数据
• MessageViewerWidget: 查询设备列表和数据

设备信息查询

• 已修改: getDeviceInfoByPortname() 已改为通过 SoftBusAPI 从守护进程获取
• 仍需使用: getDeviceInfo(deviceId) 用于通过设备ID查询（UI显示）

3. 信号连接（UI 更新）

• deviceRegistered - 设备注册信号
• deviceUnregistered - 设备注销信号
• busMessageStored - 总线消息存储信号
• rawDataStored - 原始数据存储信号

这些信号用于实时更新UI，当数据写入数据库时触发。

🏗️ 架构分析

当前架构

主应用进程 (soft_bus)
├── CoreService
│   └── DeviceBusCore (m_busCore)
│       ├── 数据库连接 (soft_bus_db)
│       ├── 设备管理（内存缓存）
│       └── 数据存储/查询
├── SerialManager
│   └── 需要 m_busCore 存储数据
├── CanManager
│   └── 需要 m_busCore 存储数据
└── UI 组件
    └── 需要 m_busCore 查询数据和连接信号

守护进程 (soft_bus_daemon)
├── CoreService
│   └── DeviceBusCore
│       ├── 数据库连接 (soft_bus_db) [共享]
│       ├── 设备管理（内存缓存）
│       └── 数据存储/查询
└── 设备扫描和管理

数据库共享

两个进程共享同一个 SQLite 数据库文件 soft_bus_db：

• ✅ 数据持久化共享（设备注册、消息存储等）
• ✅ SQLite 自动处理并发访问
• ❌ 内存状态不共享（每个进程的设备列表缓存独立）

✅ 结论：主应用仍然需要 m_busCore

需要保留的原因

1. 数据存储需求

   • SerialManager 和 CanManager 在主应用中运行，需要直接写入数据库
   • 设备配置更新需要写入数据库
   • 虽然守护进程也管理设备，但主应用的 Manager 也需要存储数据

2. 数据查询需求

   • UI 组件需要查询数据库显示历史数据
   • 虽然设备信息可以从守护进程获取，但数据查询仍需要直接访问数据库

3. 信号连接需求

   • UI 需要实时响应数据存储事件
   • DeviceBusCore 的信号机制用于通知UI更新

4. 向后兼容

   • 支持"仅运行主应用"模式（不启动守护进程）
   • 主应用可以独立运行

使用建议

1. 设备信息获取

   • ✅ 已修改: 使用 SoftBusAPI::getDeviceByPortName() 从守护进程获取
   • ✅ 保留: m_busCore->getDeviceInfo(deviceId) 用于通过ID查询（UI显示）

2. 数据存储

   • ✅ 保留: SerialManager 和 CanManager 继续使用 m_busCore 存储数据
   • ✅ 保留: 设备配置更新继续使用 m_busCore->updateDevice()

3. 数据查询

   • ✅ 保留: UI 组件继续使用 m_busCore 查询数据
   • 数据库是共享的，查询结果是一致的

4. 信号连接

   • ✅ 保留: UI 组件继续连接 m_busCore 的信号
   • 注意：主应用和守护进程各自发出信号，UI只响应主应用的信号

⚠️ 注意事项

1. 内存状态不同步

• 主应用的 m_busCore 和守护进程的 DeviceBusCore 有独立的内存缓存
• 设备注册/更新会写入数据库，但内存状态可能不同步
• 解决方案: 设备信息查询优先从守护进程获取（已实现）

2. 信号重复

• 主应用和守护进程都会发出 deviceRegistered、busMessageStored 等信号
• UI 只连接主应用的 m_busCore 信号，避免重复处理

3. 数据一致性

• 数据库层面的数据是一致的（SQLite 处理并发）
• 内存层面的设备列表可能不同步，但不影响数据存储和查询

📝 总结

操作类型	是否需要 m_busCore	说明
设备信息获取	⚠️ 部分需要	通过端口名获取：使用 SoftBusAPI（从守护进程） 通过ID获取：使用 m_busCore（UI显示）
数据存储	✅ 需要	SerialManager、CanManager 存储数据 设备配置更新
数据查询	✅ 需要	UI 组件查询历史数据
信号连接	✅ 需要	UI 实时更新

结论: 主应用进程仍然需要 m_busCore，主要用于：

1. 数据存储（写入数据库）
2. 数据查询（读取数据库）
3. 信号连接（UI更新）

但设备信息的获取应该优先从守护进程获取（已实现），以确保数据一致性。