简介这是一份C# WPF智慧工厂大数据电子看板源码面向中高级WPF开发者与智能制造项目团队。资源以智慧工厂数据平台为整体框架纯源代码形式呈现核心覆盖WPF设计模式、统计图形绘制、页面板块划分与动画触发时机适合搭建工业数据大屏或监控看板时直接参考复用。压缩包共149个文件大小约14MB主体为21个cs源码、4个xaml界面布局及编译生成的baml、dll、exe并提供png/jpg图标资源与sln、csproj工程文件目录结构区分基础样式、业务模块与应用入口便于按模块阅读。模块代码将业务区块与通用样式工程分离有助于理解WPF分层设计和可视化组件的组织方式从中可学到从数据绑定到动画展现的完整实现思路。已有183人学习适合准备用WPF完成工程级大屏看板开发的读者。1. WPF大数据电子看板一个工厂大屏项目为什么值得你复刻车间里的电子看板说到底是两件事把分散在 MES、PLC、扫码枪里的生产数据收上来再以秒级频率推到大屏上让人一眼看懂。C# WPF 在这个场景里是相当能打的选择——它有成熟的数据绑定、矢量渲染和硬件加速配合 C# 后端的多线程能力做出来的看板既能跑 Windows 工控机又不像网页大屏那样容易被浏览器内存拖垮。这篇实战笔记围绕一套典型的大数据电子看板源码展开从 MVVM 架构、数据链路、大屏 UI 到长时间运行的内存问题完整讲清楚这套方案怎么做、参数怎么设、哪些地方会翻车。适合准备接智慧工厂数据平台项目的上位机工程师也适合想自研车间看板的 .NET 开发者。2. MVVM 架构先行看板工程的目录骨架与最小绑定闭环2.1 为什么 WPF 看板要用 MVVM 而不是直接写事件很多从 WinForms 转过来的开发者第一版看板往往是 Button.Click 里写刷新、Timer.Tick 里改 TextBlock.Text。这套写法在数据量小的时候没问题但一旦进入大数据看板的场景——几十台工位机同时上报、十几个图表每秒更新一次、UI 上还要叠加动画——事件满天飞的后果就是代码里到处都是 this.Dispatcher.Invoke改一个需求牵一发动全身。MVVM 在 WPF 看板里的价值不是“规范”两个字能概括的。它的核心收益是让 View 层只做显示所有数据变化通过 INotifyPropertyChanged 通知界面更新。这意味着后台线程可以放心地推进数据只要在正确的同步上下文里触发属性变更界面就会自动跟着走不需要每个控件手动赋值。配合 WPF 数据绑定卡片、表格、图表可以用 DataTemplate 批量生成几千个点位状态用 ItemsControl 一次性铺出来这在事件驱动写法里几乎做不到。我一般会自己做一套轻量级的 ViewModel 基类和 RelayCommand而不是一上来就引全家桶框架。原因很简单看板工程的依赖越少部署到工控机上越省心。CommunityToolkit.Mvvm 这类库当然能用但理解原理之后自己维护一个 50 行的基类更可控。2.2 最小可运行的绑定闭环从 Model 到 View先看核心的 ViewModelBase 和 RelayCommand。这是整套 MVVM 的地基看板里所有属性和命令都从这里派生。// ViewModelBase.cs using System.ComponentModel; using System.Runtime.CompilerServices; public abstract class ViewModelBase : INotifyPropertyChanged { public event PropertyChangedEventHandler? PropertyChanged; // 统一入口所有属性变更都走这里 protected bool SetPropertyT(ref T storage, T value, [CallerMemberName] string? propertyName null) { if (EqualityComparerT.Default.Equals(storage, value)) return false; storage value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); return true; } // 手动触发通知用于集合整体替换等场景 protected void OnPropertyChanged(string propertyName) PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); }// RelayCommand.cs using System.Windows.Input; public sealed class RelayCommand : ICommand { private readonly Actionobject? _execute; private readonly Predicateobject?? _canExecute; public RelayCommand(Actionobject? execute, Predicateobject?? canExecute null) { _execute execute ?? throw new ArgumentNullException(nameof(execute)); _canExecute canExecute; } public bool CanExecute(object? parameter) _canExecute?.Invoke(parameter) ?? true; public void Execute(object? parameter) _execute(parameter); // CanExecuteChanged 触发 WPF 重新查询命令可用状态 public event EventHandler? CanExecuteChanged { add CommandManager.RequerySuggested value; remove CommandManager.RequerySuggested - value; } }SetProperty 用 CallerMemberName 自动捕获属性名写起来很省事。注意它先把新旧值做了一次相等比较值没变就不触发通知——这个细节在高频刷新场景下能砍掉大量没必要的 UI 重绘。RelayCommand 的 CanExecuteChanged 挂在了 CommandManager.RequerySuggested 上这样界面焦点变化、按钮状态切换时 WPF 会自动重新查询可执行状态不需要手动刷新。2.3 我会在工程里放的目录结构Dashboard/ ├─ App.xaml # 全局资源与启动逻辑 ├─ Views/ # 看板视图层 │ ├─ MainWindow.xaml │ └─ Controls/ # 自定义看板控件状态灯、趋势图 ├─ ViewModels/ # 业务逻辑层 │ ├─ MainViewModel.cs │ └─ DashboardViewModel.cs ├─ Models/ # 数据实体 │ ├─ DeviceStatus.cs │ └─ ProductionRecord.cs ├─ Services/ # 数据服务 │ ├─ DataCollector.cs # 采集服务串口/网络/数据库 │ ├─ ChannelService.cs # 实时数据分发总线 │ └─ HistoryService.cs # 历史数据持久化 ├─ Converters/ # 值转换器状态转颜色等 └─ Helpers/ # 基础设施日志、配置读取这套结构和热词里常刷到的“C#上位机”“WPF MVVM”实践是一脉相承的——采集层收数据服务层做分发和落库ViewModel 负责组织展示逻辑View 只管渲染。第一步不追求一次到位但目录从第一天就按这个分后面加功能不会变成一团麻。跑通最小闭环别急着做 UI直接在 MainViewModel 里放两个属性和一个 RelayCommand然后在 MainWindow 里绑上确认状态栏能实时显示“连接中/已连接”这就是地基打好了的信号。3. 数据链路设计从 MES 到看板的两条路实时推送 历史落库3.1 实时数据别用轮询表格用 Channel 做生产者消费者电子看板最忌讳的做法是让 UI 线程定时去查数据库表格。几十个点位还好一旦超过几百个点位、刷新周期压到 3 秒以内数据库连接池和查询延迟会累积成肉眼可见的卡顿。大数据电子看板的正确姿势是“数据变化时才推送”把数据流转做成生产者-消费者模型。定位实时数据总线的首选是 System.Threading.Channels这是 .NET 内置的线程安全队列性能和语义都远好于自己用 lock Queue 拼。采集线程往 Channel 里写UI 侧单独的消费者线程读读写完全解耦。// ChannelService.cs using System.Threading.Channels; public sealed class ChannelServiceT { private readonly ChannelT _channel; public ChannelService(int capacity) { // Bounded 队列容量满了写操作可以等待避免无限积压拖垮内存 _channel Channel.CreateBoundedT(new BoundedChannelOptions(capacity) { FullMode BoundedChannelFullMode.Wait, SingleReader false, SingleWriter false }); } public async ValueTask PublishAsync(T item, CancellationToken ct default) await _channel.Writer.WriteAsync(item, ct); public IAsyncEnumerableT SubscribeAsync(CancellationToken ct) _channel.Reader.ReadAllAsync(ct); }参数说明capacity 设置的是队列最大容量我做看板时一般给 1024 到 4096。FullMode 用 Wait 意思是生产者会阻塞等待消费者消费而不是丢数据或用最新覆盖旧数据——看板上的产量、报警信息丢了是要出事故的。如果现场确实允许丢旧数据保实时可以把 FullMode 改成 DropOldest但默认我建议 Wait。消费端在 ViewModel 里用异步循环读取读到一条就更新一个属性// DashboardViewModel.cs 中的消费循环 public async Task StartConsumeLoopAsync(CancellationToken ct) { await foreach (var data in _channelService.SubscribeAsync(ct)) { if (data is DeviceStatus status) { // 只更新对应工位的状态属性 UpdateDeviceStatus(status); } else if (data is ProductionRecord record) { TotalCount record.Count; // PropertyChanged 自动通知 UI YieldRate record.YieldRate; } } }3.2 历史数据落 SQLite批量写入参数与读写分离看板不能只显示当前状态还要有趋势图和“过去 8 小时产量”这类历史聚合。实时数据经过 UI 展示后必须有一条独立的落库路径。小型看板项目用 SQLite 最合适——零配置、单文件、部署时不用装数据库服务。写入性能的瓶颈在事务粒度。一条条 insert 提交事务每秒撑死几百条改成批量提交轻松过万。// HistoryService.cs using Microsoft.Data.Sqlite; public sealed class HistoryService { private readonly string _connectionString; public HistoryService(string dbPath) { // Poolingtrue 让每个线程复用自己的连接避免反复握手 _connectionString $Data Source{dbPath};Poolingtrue;; InitializeDatabase(); } public void BatchInsert(IEnumerableProductionRecord records) { using var conn new SqliteConnection(_connectionString); conn.Open(); // 一次事务提交所有记录比逐条 commit 快一个数量级 using var tx conn.BeginTransaction(); using var cmd conn.CreateCommand(); cmd.Transaction tx; cmd.CommandText INSERT INTO production_log (device_id, count, yield_rate, timestamp) VALUES ($deviceId, $count, $yieldRate, $timestamp); ; var pDeviceId cmd.Parameters.Add($deviceId, SqliteType.Text); var pCount cmd.Parameters.Add($count, SqliteType.Integer); var pYield cmd.Parameters.Add($yieldRate, SqliteType.Real); var pTime cmd.Parameters.Add($timestamp, SqliteType.Text); foreach (var r in records) { pDeviceId.Value r.DeviceId; pCount.Value r.Count; pYield.Value r.YieldRate; pTime.Value r.Timestamp.ToString(yyyy-MM-dd HH:mm:ss.fff); cmd.ExecuteNonQuery(); } tx.Commit(); } }注意点有三个。第一SqliteParameter 用 $ 前缀是官方推荐写法可读性和安全性都好过字符串拼接。第二时间字段存成 Text 并用 ISO 格式排序SQLite 里字符串比较天然按时间升序——这比存 Unix 时间戳更容易排查问题。第三批量插入的批次大小我一般控制在 500 到 2000 条之间超过 2000 条单次事务的锁持有时间会明显变长前台查询可能被阻塞。查询侧的读写分离很关键写库用独占事务读库走 WAL 模式。在连接字符串里加CacheShared是很多人的误区真正解决并发读的是 PRAGMA journal_modeWAL。开启 WAL 之后写入不会阻塞读取看板趋势图翻历史数据时才不会卡住实时更新。3.3 采集端规范化串口、Modbus 与网络报文统一成一个 DataPoint智慧工厂里的数据源五花八门。老设备走串口 RS485 报 Modbus RTU新设备走 TCP 直接吐 JSON还有一部分设备只能靠定时读 PLC 寄存器。我处理过不下十种协议最深刻的经验是采集层一定要在第一层就把不同协议的数据规范成统一结构否则后面做聚合、报警、历史查询全都得写分支。常见做法是定义一个最小数据点结构所有协议解析后都输出它public sealed record DataPoint(string DeviceId, string PointName, object Value, DateTime Timestamp);DeviceId 区分是哪台设备PointName 区分是温度、转速还是产量Value 用 object 兼容数值型、开关量和字符串状态。串口参数这类配置统一放到 appsettings.json 里采集启动时读串口号、波特率、数据位、校验位。Modbus 帧解析时特别注意字节序——很多国产仪表用的是大端序但寄存器地址映射各不相同这批配置在项目验收阶段最容易反复调。把这个结构定义好之后不管是哪种协议进来的数据到了 Channel 层面长相都一样UI 和各种服务只管消费 DataPoint完全不需要关心底层是串口还是网线。这也是整套大数据看板能应对工厂设备持续接入的前提。4. WPF 大屏 UI 实战绑定、动态样式与动画看板4.1 DataTemplate 把数据变成看板卡片WPF 大屏和普通管理系统界面最大的区别是要展示的点位多、状态变化频繁、视觉上需要让关键信息一眼抓到。用 ItemsControl 加 DataTemplate 是最高效的做法数据来了自动生成卡片数据没了卡片自动消失完全不需要手写循环创建控件。Window.Resources !-- 状态数字转颜色合格绿色、超差橙色、停机红色 -- converters:StatusToBrushConverter x:KeyStatusToBrush / !-- 单台设备的看板卡片模板 -- DataTemplate DataType{x:Type models:DeviceStatus} Border CornerRadius4 BorderBrush#333 BorderThickness1 Background#1E1E1E Margin4 Padding12 Width220 StackPanel TextBlock Text{Binding DeviceName} FontSize18 Foreground#EEE / TextBlock Text{Binding CurrentValue, StringFormat{}{0:F2}} FontSize32 FontWeightBold Foreground{Binding State, Converter{StaticResource StatusToBrush}} / TextBlock Text{Binding UpdateTime, StringFormat更新于 {0:HH:mm:ss}} FontSize12 Foreground#888 / /StackPanel /Border /DataTemplate /Window.Resources ItemsControl x:NameDeviceCardContainer ItemsSource{Binding Devices} ScrollViewer.HorizontalScrollBarVisibilityDisabled ItemsControl.ItemsPanel ItemsPanelTemplate WrapPanel / /ItemsPanelTemplate /ItemsControl.ItemsPanel /ItemsControl这里最关键的是 Foreground 绑定了State经过值转换器映射成颜色。值转换器返回 Brush 时注意——如果不实现冻结Freeze高频刷新下会反复创建画刷对象给 GC 增加压力。更稳妥的做法是让转换器返回一个静态画刷实例或者直接把画刷定义为 Window 资源转换器按状态查字典返回。ItemsControl 遇到几百个点位时默认的 StackPanel 布局会一次性把全部元素布局到位这在 WPF 虚拟化下是最大的性能坑。如果你的看板点位超过 200 个把 ItemsPanel 换成 VirtualizingStackPanel并且给 ItemsControl 设置VirtualizingPanel.IsVirtualizingTrue否则切页或滚动时会明显掉帧。4.2 状态灯与告警闪烁值转换器加 DoubleAnimation电子看板上最常见的视觉元素是状态灯——设备运行绿灯、待机黄灯、故障红灯闪烁。状态灯的闪烁不能靠后台线程反复改属性那会让 UI 线程疲于奔命。正确做法是用 WPF 的 DoubleAnimation 对 Opacity 做无限循环动画触发条件由数据绑定控制。Ellipse Width16 Height16 RadiusX8 RadiusY8 Ellipse.Style Style TargetTypeEllipse Setter PropertyFill Value#28A745 / Setter PropertyOpacity Value1 / Style.Triggers !-- 故障状态启动闪烁 -- DataTrigger Binding{Binding State} ValueFault DataTrigger.EnterActions BeginStoryboard Storyboard DoubleAnimation Storyboard.TargetPropertyOpacity From1 To0.2 Duration0:0:0.6 AutoReverseTrue RepeatBehaviorForever / /Storyboard /BeginStoryboard /DataTrigger.EnterActions DataTrigger.ExitActions StopStoryboard / /DataTrigger.ExitActions /DataTrigger /Style.Triggers /Style /Ellipse.Style /Ellipse这段 XAML 的写法有两个讲究。其一VisualStateManager 方案在这里不如 Style.Triggers 直接因为看板的告警状态是数据驱动的DataTrigger 天然匹配这个语义。其二EnterActions 里启动的 Storyboard 必须在 ExitActions 里显式停止否则状态从故障恢复成正常后动画还在后台跑着Opacity 卡在某个半透明值上。这是实际项目里最隐蔽的界面“假死”来源。业务侧切换状态只需要一行DeviceState Fault闪烁动画自动开始。反过来说动画结束前 UI 线程不要做耗时操作否则 Storyboard 的时间线会卡顿看板上的闪烁会变成“一顿一顿”的。4.3 HandyControl 与自定义控件的取舍WPF 大屏项目里要不要引第三方控件库取决于界面复杂度。HandyControl 提供的日期选择器、抽屉、通知弹窗在管理后台里很香但大屏首页 80% 的界面是自绘图表和状态卡片它的价值主要体现在侧边栏和设置页。如果项目周期紧我一般引 HandyControl 处理交互控件看板主体用自绘控件保证性能和视觉统一。注意引第三方库的时候要把主题资源和样式字典合并到 App.xaml 里否则全局样式不生效部分控件会呈现出默认的 Windows 样式和自绘大屏风格冲突。看板上真正的图表趋势曲线、柱状图、饼图WPF 自带的控件画不了。你有几条路用 LiveCharts2 这种开源图表库自己用 DrawingVisual 画或者把图表区域嵌一个 WebView 用 ECharts。我的选择是数据量大、更新频繁的趋势图用 DrawingVisual 自绘固定样式、交互少的统计图用 LiveCharts2。自绘的代码量确实大但性能天花板最高——几千个点的实时趋势线用 ECharts 在 WebView 里跑反而更容易卡。5. 大屏看板避坑指南卡顿、跨线程、内存泄漏的现场复盘5.1 现象DispatcherTimer 刷新一多UI 就假死现象用 DispatcherTimer 每 500 毫秒刷新一次看板数据界面在点位超过 100 个后开始卡顿鼠标移动都不跟手严重时整个屏幕“白掉”几秒。原因DispatcherTimer 的回调执行在 UI 线程上。它每隔 500ms 触发一次如果回调里做了数据库查询、文件读取或复杂计算UI 线程被这些操作占住渲染和输入响应全部排队。更糟的是回调里如果还调用了Thread.Sleep整个看板直接无响应。解决把 DispatcherTimer 换成后台采集线程加 Channel 推送的模式UI 侧只做属性赋值。用一个高频 Channel 接实时数据UI 线程用await foreach消费消费循环里绝不写文件、绝不查数据库。如果确实需要定时刷新——比如每分钟拉一次汇总数据——把定时器放后台线程回调里只发消息让 ViewModel 在同步上下文里更新属性。5.2 现象后台线程修改 ObservableCollection 直接抛异常现象后台线程往 ObservableCollection 里 Add运行时抛异常界面直接崩溃。异常信息很明确“跨线程操作无效应用程序以外的其他线程无权访问它。”原因ObservableCollection 的集合变更通知默认是在修改线程上触发的WPF 不允许非 UI 线程直接操作绑定到界面的集合。很多人第一反应是用Dispatcher.Invoke包裹 Add这在低频场景下管用但高频更新时 Dispatcher.Invoke 是同步阻塞的后台线程会被 UI 响应速度拖住反过来恶化卡顿。解决不要在后台线程碰 ObservableCollection。正确姿势是后台线程把数据写到 ConcurrentQueue 或 ChannelUI 线程在 Dispatcher 的定时回调里成批把数据搬进 ObservableCollection每次搬运用BeginInit/EndInit包裹最后再做一次手动刷新。批量插入时用AddRange扩展方法一次性加入避免每加一条触发一次 CollectionChanged。5.3 现象DataGrid 滚动卡成幻灯片现象看板的报警历史表格数据量过万切换筛选条件后 DataGrid 滚动一顿一顿CPU 占用居高不下。原因DataGrid 默认开启了 UI 虚拟化但一旦启用行分组、列宽自动调整或某些第三方样式虚拟化会被悄悄关掉另一个常见原因是行高未固定DataGrid 为计算滚动范围需要测量所有行的高度。解决一是确认VirtualizingPanel.IsVirtualizingTrue和VirtualizingPanel.VirtualizationModeRecycling两个属性都在 DataGrid 上显式设置二是给 DataGrid 设置固定的 RowHeight再把EnableRowVirtualizationTrue打上三是不在 DataGrid 的 CellTemplate 里放复杂控件状态图标用 TextBlock 加字体图标替代。处理完这三项万行数据滚动基本能回到 60 帧。5.4 现象看板挂一晚上内存涨几百兆现象看板连续运行 12 小时后任务管理器里内存占用从 300MB 涨到 800MB第二天早上界面明显迟钝。原因最常见的是事件订阅未注销。后台采集服务抛 DataReceived 事件ViewModel 订阅了这个事件但窗口关闭时没有退订——窗口对象被事件源强引用永远无法被 GC 回收。每次重新登录或切换看板页旧窗口和它的整个对象图都堆在内存里。解决所有订阅的 IDisposable 都要在关闭时释放。具体做法是ViewModel 实现 IDisposable在 Dispose 里退订所有事件、释放 Channel、取消 CancellationTokenSourceMainWindow 的 Closed 事件里调用 DataContext 的 Dispose。养成习惯后每加一个事件订阅就顺手在 Dispose 里写一行退订一劳永逸。5.5 现象数据刷新一瞬间控件闪烁现象后台数据更新后看板上的数字跳动、颜色闪烁像是画面抖了一下尤其在低配工控机上更明显。原因属性变更通知太频繁UI 来不及批量渲染或者布局在更新过程中被反复触发了尺寸变化WPF 把布局周期拖满了。解决给 UI 容器设置SnapsToDevicePixelsTrue和UseLayoutRoundingTrue减少因为像素对齐引起的重绘涉及实时数值的 TextBlock 不要在 StringFormat 里做复杂格式化前端只负责显示格式化放 ViewModel 侧高频变化的属性单独建一个 ViewModel 属性避免一个对象整体刷新所有字段。6. 千点实时刷新验证给看板做一次可量化的体检看板交付前最该做的一件事是用模拟数据源压一遍实时刷新链路验证 UI 的响应能力和内存曲线。常见做法是写一个模拟采集器按固定频率往 Channel 里灌数据用 Stopwatch 测量 UI 从收到数据到渲染完成的时间差。// MockDataInjection.cs public static async Task RunAsync(ChannelServiceDataPoint channel, int pointCount, int intervalMs, CancellationToken ct) { var devices Enumerable.Range(1, pointCount) .Select(i $Device-{i:000}) .ToArray(); var sw new System.Diagnostics.Stopwatch(); var rng new Random(42); while (!ct.IsCancellationRequested) { sw.Restart(); foreach (var device in devices) { var dp new DataPoint(device, Temperature, Math.Round(80 rng.NextDouble() * 20, 2), DateTime.Now); await channel.PublishAsync(dp, ct); } sw.Stop(); // 打印每秒推送的点数和消耗时间 Console.WriteLine($Push {devices.Length} points in {sw.ElapsedMilliseconds} ms); await Task.Delay(intervalMs, ct); } }压测时重点看三组数推送消耗时间生产者侧吞吐、UI 消费循环耗时消费者侧延迟、后台任务内存曲线。推送耗时超过 50ms 说明 Channel 容量或消费者速度不匹配消费循环单次超过 30ms 说明绑定链路里有重负载操作内存曲线如果持续阶梯式上涨而不是锯齿波动说明有对象没被释放。用后置的性能日志记录这三个指标连续跑 24 小时比验收时看一眼界面靠谱得多。我自己做过的几套看板交付时都有一套验收基线单机 500 个点位、1 秒刷新间隔CPU 占用不超过 25%内存稳定在 700MB 以内界面切换无卡顿。达不到这个基线不进验收流程。老实说大多数看板项目的翻车都不是需求太复杂而是对 WPF 的绑定机制、线程模型和渲染管线的理解不到位——这些坑每一个都真实存在避开了你的看板就能稳稳挂在车间里跑一年。希望这篇笔记能帮你少走几段弯路。本文还有配套的精品资源点击获取