# HighPerfDataGridDemo

**Repository Path**: erick1999/high-perf-data-grid-demo

## Basic Information

- **Project Name**: HighPerfDataGridDemo
- **Description**: 用于WPF高负载测试环境练习 包含多种解决方案
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-08-06
- **Last Updated**: 2026-08-06

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# WPF 高速数据刷新（CAN 采集类场景）性能方案总结

> 配套演示项目：`WpfHighSpeedDataGrid`。运行后在各页签切换、调节“速率(帧/秒)”并点击“开始”，
> 重点观察顶部 **渲染帧率（RenderFps）**：反面教材会掉到个位数并卡顿，其余方案在高速率下仍保持流畅。

---

## 一、问题背景

典型场景：CAN 采集卡以每秒数千甚至数万帧的速度推送数据，需要实时显示在 `DataGrid` 中。
如果处理不当，界面会卡顿、假死，甚至因内存无限增长而崩溃。

本项目用后台线程模拟高频数据源（可配 100 ~ 50000 帧/秒），并在同一窗口的 6 个页签中
分别演示从「反面教材」到「工业级可用」的多种实现方式。

---

## 二、卡顿的根本原因

| 根因 | 说明 |
|------|------|
| **UI 线程被淹没** | 每帧都 `Dispatcher.Invoke/BeginInvoke` 到 UI 线程，Dispatcher 队列被海量小任务塞满，无暇处理布局、输入与渲染。 |
| **通知次数过多** | `ObservableCollection` 每 `Add` 一条就触发一次 `CollectionChanged`，`DataGrid` 被迫做大量增量更新。 |
| **非虚拟化全量渲染** | 若虚拟化失效，`DataGrid` 会为所有行创建可视化容器，行数一多，测量/布局成本爆炸。 |
| **集合限容方式差** | 用 `RemoveAt(0)` 逐条删头，是 O(n) 的数组搬移，高频下持续吃 CPU。 |
| **GC 压力** | 海量短命对象 + 频繁容器创建，触发频繁 GC，造成周期性卡顿（掉帧）。 |
| **每次渲染重复格式化** | 在绑定/转换器里做 `ToString("X")`、日期格式化等，滚动时被反复执行。 |

**一句话原则**：把「数据产生速率」与「UI 刷新速率」解耦；减少通知次数；只渲染看得见的部分；控制内存与 GC。

---

## 三、六种方案对比

| # | 方案 | 核心手段 | 通知次数 | 内存 | 适用场景 | 对应代码 |
|---|------|----------|----------|------|----------|----------|
| 0 | 反面教材 | 逐帧 `BeginInvoke` + `Add` | 每帧一次 | 无限增长 | ❌ 仅作对比 | `NaiveViewModel` |
| 1 | Dispatcher 批量节流 | 后台入队 + `DispatcherTimer` 定时批量刷新 | 每帧一次（但只在 UI tick 内） | 受限 | ✅ 最通用的第一步 | `DispatcherBatchViewModel` |
| 2 | 批量集合 | `BulkObservableCollection` 单次 Reset | **每次刷新一次** | 受限 | ✅ 大批量追加 | `BulkCollectionViewModel` |
| 3 | UI 虚拟化 | 行/列虚拟化 + 容器回收 + `CanContentScroll` | 每次刷新一次 | 大（20 万行仍流畅） | ✅ 需保留大量历史 | `VirtualizationViewModel` + `VirtualizationView.xaml` |
| 4 | 环形缓冲 + 快照 | 固定容量 `RingBuffer` + 整体替换 | 每次刷新一次 | **恒定** | ✅ 只看最新一屏 | `RingBufferViewModel` |
| 5 | Channel 管道 | 有界 `Channel` 背压/丢弃 + 批量消费 | 每次刷新一次 | **有上限** | ✅ 极高速率、可容忍丢帧 | `ChannelViewModel` |

### 方案要点

**方案 1 · Dispatcher 批量节流（最重要的一步）**
后台线程只把帧塞进无锁并发队列 `ConcurrentQueue`；UI 端用 ~30FPS 的 `DispatcherTimer`
周期性地「一次取空队列」。无论后台每秒来 5000 还是 50000 帧，UI 每秒只被打扰约 30 次。
通常单这一步就能从「卡死」变「流畅」。

**方案 2 · 批量集合（减少通知）**
方案 1 每 tick 内仍逐条 `Add`（N 次通知）；本方案用 `BulkObservableCollection.AppendAndCap`
把整批数据一次写入底层 `List`，只发一次 `Reset`，并用 `List.RemoveRange` 做 O(n) 一次性限容。

**方案 3 · UI 虚拟化（XAML 是关键）**
只要开启虚拟化，`DataGrid` 只为「可见的数十行」创建容器，内存里有 20 万行也不影响滚动。
必需设置（缺一不可）：
- `EnableRowVirtualization` / `EnableColumnVirtualization = True`
- `VirtualizingPanel.IsVirtualizing = True`、`VirtualizationMode = Recycling`（容器回收复用）
- `ScrollViewer.CanContentScroll = True`（按行滚动，虚拟化前提；按像素滚会退化）
- 列宽用固定值，避免 `Auto/SizeToCells` 强制测量所有行

**方案 4 · 环形缓冲 + 快照（内存恒定）**
后台把帧写入固定容量数组（写满覆盖最旧），UI 定时取快照整体替换。
内存占用恒定、几乎不产生 GC，写入 O(1)，适合「只看最新一屏」的滚动监视。

**方案 5 · Channel 生产者-消费者（现代异步管道）**
有界 `Channel` 相当于带容量上限的线程安全队列：生产者 `TryWrite` 写满即丢弃并计数（**显式背压**，
宁可丢旧数据也不拖垮消费端）；单个消费者异步等待后一次性取空、合并成批投递 UI 并节流。

---

## 四、通用性能优化清单

无论用哪种方案，以下都值得同时应用：

- [ ] **数据产生放后台线程**，绝不在采集回调里直接碰 UI 对象。
- [ ] **合并刷新**：用定时器/批量把「多次小更新」聚合成「一次大更新」。
- [ ] **减少通知**：批量操作只发一次 `Reset`（`BulkObservableCollection`）。
- [ ] **开启并保证虚拟化**：固定列宽、`CanContentScroll=True`、`Recycling`。
- [ ] **控制数据量**：环形缓冲/限容，避免集合无限增长。
- [ ] **预格式化显示字段**：把 `ToString("X")`、日期格式化等放到数据生成时做一次（见 `CanFrame`）。
- [ ] **冻结可共享资源**：`Freezable.Freeze()` 冻结画刷/几何，避免线程亲和与重复通知。
- [ ] **简化单元格模板**：避免复杂 `DataTemplate`、层层 `Converter`、每格触发器。
- [ ] **关闭实时排序/分组**：高频下 `SortDescriptions`/`GroupDescriptions` 代价极高。
- [ ] **降低视觉树复杂度**：行越简单，容器创建越快。
- [ ] **减少绑定开销**：只读列用 `Mode=OneWay`/`OneTime`，避免不必要的双向绑定。

> 进阶：当数据量/刷新率极端到 `DataGrid` 也扛不住时，考虑自绘（`DrawingVisual`/`WriteableBitmap`）
> 或 GPU 加速（`D3DImage`/SkiaSharp），用「画」代替「控件树」。见学习路径第 8 阶段。

---

## 五、如何度量（先测量，再优化）

- **本项目内置指标**：渲染帧率、显示速率、表格行数、已生成/已显示/丢弃数。
- **Visual Studio 诊断工具**：CPU 使用率、内存分配、.NET 对象分配（定位 GC 热点）。
- **Snoop / XAML Hot Reload / Live Visual Tree**：查看运行时视觉树，确认虚拟化是否真正生效。
- **WPF 事件跟踪（ETW）/ PerfView**：分析布局、渲染、GC 事件。
- **JetBrains dotTrace / dotMemory**：更细的性能与内存分析。

**方法论**：不要凭感觉优化。先用工具定位瓶颈（UI 线程？GC？布局？），
针对性地套用上面的方案，再对比指标验证效果。

---

## 六、学习路径（从入门到精通性能优化）

### 阶段 1 · WPF 线程模型与 Dispatcher
- UI 线程亲和性、`Dispatcher` 队列与 `DispatcherPriority`
- `Invoke` vs `BeginInvoke` vs `InvokeAsync`
- 为什么「后台采集 + UI 节流」是所有优化的基础

### 阶段 2 · 数据绑定与通知机制
- `INotifyPropertyChanged` / `INotifyCollectionChanged` 原理
- `ObservableCollection` 的通知开销与瓶颈
- 值转换器、绑定模式（OneWay/OneTime）对性能的影响

### 阶段 3 · 布局系统与虚拟化
- Measure/Arrange 两趟布局的成本
- `VirtualizingStackPanel`、容器回收（Recycling）、`ScrollUnit`
- 哪些操作会「破坏虚拟化」（像素滚动、Auto 列宽、`ScrollViewer` 包裹等）

### 阶段 4 · 渲染管线
- WPF 保留模式（Retained Mode）与合成线程（Render Thread）
- `CompositionTarget.Rendering` 的用途（本项目用它测真实帧率）
- `RenderOptions`、`BitmapCache`、图层合成

### 阶段 5 · 集合与内存性能
- `BulkObservableCollection` 批量单次通知的实现
- 数据虚拟化（只加载可见数据，`IList` 虚拟化）
- GC 分代、短命对象、减少分配（对象复用/环形缓冲）

### 阶段 6 · 异步与并发
- `Task` / `async-await` / `ConcurrentQueue`
- `System.Threading.Channels`：有界/无界、背压、生产者-消费者
- 线程安全的数据交接（不可变对象、`Interlocked`）

### 阶段 7 · 性能诊断工具
- Visual Studio 诊断工具（CPU/内存/分配）
- Snoop、Live Visual Tree、XAML Hot Reload
- PerfView / ETW、dotTrace / dotMemory

### 阶段 8 · 进阶渲染（当控件树也扛不住时）
- `DrawingVisual` 直接绘制（绕过控件树）
- `WriteableBitmap` 像素级绘制（示波器/波形图常用）
- `D3DImage` / SkiaSharp 的 GPU 加速渲染

### 推荐资源
- 官方文档：WPF「Optimizing Performance」系列、Threading Model、Data Binding
- 书籍：《WPF 4.5 Unleashed》(Adam Nathan)、《Pro WPF》
- 关键词检索：`WPF DataGrid virtualization`、`ObservableCollection performance`、
  `WPF high frequency update`、`System.Threading.Channels producer consumer`

---

## 七、运行方式

```powershell
cd 'd:\学习\C#\WPF\项目\Test\WpfHighSpeedDataGrid'
dotnet run
```

打开后逐个页签点「开始」，把速率调高（如 20000+），对比各页签顶部的「渲染帧率」。