# 主应用进程 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`（从守护进程）<br>通过ID获取：使用 `m_busCore`（UI显示） |
| **数据存储** | ✅ 需要 | `SerialManager`、`CanManager` 存储数据<br>设备配置更新 |
| **数据查询** | ✅ 需要 | UI 组件查询历史数据 |
| **信号连接** | ✅ 需要 | UI 实时更新 |

**结论**: 主应用进程**仍然需要** `m_busCore`，主要用于：
1. 数据存储（写入数据库）
2. 数据查询（读取数据库）
3. 信号连接（UI更新）

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