1. 项目缘起与整体设计思路1.1 为什么选择 Avalonia 做工业上位机做过工业上位机的人都知道这个领域长期被 WinForms 和 WPF 统治。WinForms 上手快但界面老旧WPF 界面表现力强但绑定微软生态跨平台基本没戏。我这次接到的需求是给一条产线做设备监控面板客户现场环境很杂一部分工控机是 Windows 10 LTSC还有几台新采购的国产化 Linux 终端另外还有工程师希望能在 Mac 上跑一份用于调试。如果继续用 WPFLinux 和 Mac 这两块直接出局。Avalonia 就成了那个“既要又要”的答案。它基于 .NETAPI 设计大量借鉴 WPFXAML 语法、依赖属性、样式系统、数据绑定这些概念几乎可以平移过来我原来写 WPF 的经验基本没浪费。更关键的是它原生支持 Windows、Linux、macOS甚至能往移动端和 WebAssembly 方向延伸。对于工业监控面板这种“一套逻辑多端部署”的场景Avalonia 的跨平台能力是实打实的降本。这里要澄清一个常见误区很多人把 Avalonia 当成“WPF 的跨平台复刻”其实两者在渲染层差别很大。WPF 依赖 DirectXAvalonia 自研了一套渲染引擎默认走 Skia这意味着它在没有独显的工控机上也能靠软件渲染跑起来虽然性能会打折但至少不会白屏。这一点在工业现场特别重要因为很多嵌入式工控机的显卡驱动一言难尽。1.2 监控面板的核心需求拆解在动手之前我把需求拆成了四块这个拆解过程直接决定了后面的技术选型。第一块是数据采集。产线上有 PLC、温控器、变频器、称重仪表它们大多支持 Modbus TCP 协议通过以太网口暴露寄存器。我需要以固定周期轮询这些寄存器把原始数据读回来。第二块是数据解析与映射。Modbus 读回来的是 16 位寄存器数组需要根据设备手册把寄存器地址映射成有物理意义的量温度、转速、重量、状态字。这里面涉及字节序、数据类型int16、uint16、float32、位标志的转换是最容易出错的地方。第三块是界面呈现。操作工需要看到实时数值、趋势曲线、设备状态灯、报警列表。界面要够大够清晰刷新要跟得上不能卡顿。第四块是稳定性与容错。工业现场网络抖动、设备掉线是常态程序不能因为一次读取超时就崩溃要有重连机制、超时处理、异常日志。这四块里第一块和第四块是“踩坑重灾区”第二块是“隐蔽 bug 重灾区”第三块反而是相对可控的。我后面会重点讲前两块。1.3 技术栈选型与理由最终确定的技术栈是这样的层次选型理由UI 框架Avalonia 11.x跨平台XAML 生态成熟运行时.NET 8LTS 版本性能与稳定性兼顾MVVMCommunityToolkit.Mvvm源生成器写法简洁减少样板代码Modbus 库NModbus老牌库API 直观社区资料多图表LiveChartsCore.SkiaSharpView.Avalonia与 Avalonia 集成好性能可接受日志Serilog结构化日志方便现场排查这里重点说两个选型决策。为什么用 NModbus 而不是自己撸协议Modbus TCP 协议本身不复杂但自己实现要处理 TCP 粘包、事务标识匹配、异常码解析、超时重传工作量不小且容易埋雷。NModbus 这些细节都处理好了我只需要关注业务逻辑。为什么用 CommunityToolkit.Mvvm 而不是 ReactiveUIReactiveUI 功能强大但学习曲线陡团队里其他人接手成本高。CommunityToolkit 的[ObservableProperty]和[RelayCommand]源生成器写法几乎零学习成本适合工业项目这种“稳定优先、人员流动大”的场景。提示Avalonia 版本迭代较快11.x 相比 0.10.x 在 API 上有不少破坏性变更。选库时务必确认第三方库明确支持你用的 Avalonia 大版本否则会出现“编译通过但运行时找不到资源”的诡异问题。2. Modbus TCP 通信层的核心细节与实操要点2.1 Modbus TCP 协议要点速览在写代码之前得先把协议本身搞清楚否则踩坑都不知道坑在哪。Modbus TCP 的报文结构比 RTU 简单因为它去掉了 CRC 校验改由 TCP 层保证完整性。一个典型的请求报文长这样[事务标识 2字节][协议标识 2字节][长度 2字节][单元标识 1字节][功能码 1字节][数据 N字节]事务标识Transaction ID是重点。客户端每发一个请求就递增一次服务端响应时会原样带回这个标识。客户端靠它来匹配“这个响应是回给哪个请求的”。如果你并发发多个请求事务标识处理不当就会出现“响应串台”——A 请求收到了 B 请求的数据。这是新手最容易踩的坑之一。协议标识固定为 0长度字段表示后面还有多少字节。单元标识在纯 TCP 场景下通常填 1 或者 0xFF但如果你的设备挂在网关后面这个字段就有意义了它对应网关后面的从站地址。功能码方面监控面板最常用的是这几个0x03 读保持寄存器读设备参数、实时数据最常用0x04 读输入寄存器读只读的测量值0x01 读线圈读开关状态0x02 读离散输入读只读的开关状态0x06 写单个寄存器下发设定值0x10 写多个寄存器批量下发2.2 寄存器地址映射的坑这是整个项目里最隐蔽的坑没有之一。Modbus 的地址体系有两套协议地址和PLC 地址。协议地址从 0 开始PLC 地址从 1 开始而且不同厂商的文档写法五花八门。举个真实例子。某温控器手册上写“当前温度40001”这是 PLC 地址表示法40001 里的 4 表示保持寄存器后面的 0001 是序号。实际发请求时协议地址应该是 0。如果你直接拿 40001 去发请求读回来的就是完全不相干的数据而且不会报错只是数值不对——这种 bug 最难查。我整理了一个对照表建议直接贴在工位上手册写法寄存器类型协议地址计算00001-09999线圈地址 - 110001-19999离散输入地址 - 1000130001-39999输入寄存器地址 - 3000140001-49999保持寄存器地址 - 40001注意有些厂商文档直接给的就是协议地址从 0 开始这时候千万别再减 1。判断方法看文档里有没有出现 40001 这种五位数地址有就是 PLC 地址表示法没有就大概率是协议地址。拿不准的时候用 Modbus 调试工具先手动读一次验证。2.3 数据类型与字节序处理读回来的是 16 位寄存器但实际物理量可能是 32 位浮点、32 位整数甚至 64 位。一个 32 位数据占两个连续寄存器这就涉及字节序和字序两个维度。字节序是单个寄存器内部两个字节的顺序字序是两个寄存器之间的顺序。Modbus 标准规定大端Big-Endian但实际设备五花八门。常见组合有四种ABCD大端字节序 大端字序标准CDAB大端字节序 小端字序字交换BADC小端字节序 大端字序字节交换DCBA小端字节序 小端字序全交换我遇到的那台称重仪表就是 CDAB读出来的重量一直是天文数字查了半天才发现是字序问题。处理代码大概长这样// 假设读回两个寄存器 regs[0] 和 regs[1] // 标准 ABCD byte[] bytes new byte[4]; bytes[0] (byte)(regs[0] 8); bytes[1] (byte)(regs[0] 0xFF); bytes[2] (byte)(regs[1] 8); bytes[3] (byte)(regs[1] 0xFF); float value BitConverter.ToSingle(bytes.Reverse().ToArray(), 0); // 注意平台字节序这段代码里有个隐藏陷阱BitConverter依赖运行平台的字节序。x86/x64 是小端所以要先Reverse再转换。如果哪天跑在 ARM 大端平台上虽然少见这段逻辑就错了。更稳妥的做法是用BinaryPrimitives显式指定字节序using System.Buffers.Binary; Spanbyte buffer stackalloc byte[4]; BinaryPrimitives.WriteUInt16BigEndian(buffer, regs[0]); BinaryPrimitives.WriteUInt16BigEndian(buffer[2..], regs[1]); // 此时 buffer 是标准 ABCD 大端 float value BinaryPrimitives.ReadSingleBigEndian(buffer);这样写不依赖平台逻辑清晰推荐。2.4 轮询策略与并发控制监控面板要同时读几十上百个寄存器怎么组织轮询是个学问。我一开始图省事每个数据点开一个Task独立轮询结果设备直接被打爆——Modbus 从站的处理能力有限并发请求一多就丢包或者返回异常码。后来改成分组轮询 串行发送。把同一设备、地址连续的寄存器合并成一次读取请求比如读 40001-40010 这 10 个寄存器一次请求就能搞定而不是发 10 次。然后对同一设备的请求串行化用一个SemaphoreSlim(1,1)保证同一时刻只有一个请求在飞。private readonly SemaphoreSlim _deviceLock new(1, 1); public async Taskushort[] ReadHoldingRegistersAsync(byte slaveId, ushort start, ushort count) { await _deviceLock.WaitAsync(); try { return await _master.ReadHoldingRegistersAsync(slaveId, start, count); } finally { _deviceLock.Release(); } }轮询周期也要讲究。不是所有数据都需要 100ms 刷新。温度这种慢变量 1 秒读一次足够转速、位置这种快变量才需要高频。我按数据变化速率分了三个优先级高频 200ms、中频 1s、低频 5s分别用不同的定时器驱动整体网络负载降了一大半。3. Avalonia 界面层与 MVVM 实操3.1 项目结构与 MVVM 落地Avalonia 项目的目录结构我习惯这样组织Project/ ├── Models/ # 数据模型如 DeviceData、AlarmItem ├── Services/ # ModbusService、LogService ├── ViewModels/ # MainViewModel、DeviceViewModel ├── Views/ # MainWindow.axaml、DevicePanel.axaml ├── Converters/ # 值转换器 └── Assets/ # 图标、样式资源MVVM 的核心是 ViewModel 不引用任何 UI 类型。我见过有人图方便在 ViewModel 里直接new TextBox()这样测试没法写跨平台也容易出问题。CommunityToolkit.Mvvm 的源生成器让 ViewModel 写起来很清爽public partial class DeviceViewModel : ObservableObject { [ObservableProperty] private float _temperature; [ObservableProperty] private bool _isOnline; [RelayCommand] private async Task RefreshAsync() { // 刷新逻辑 } }[ObservableProperty]会自动生成Temperature属性并在 setter 里触发PropertyChanged。注意字段名要用小写或者下划线开头生成器会自动转成帕斯卡命名。这个细节文档里写得不算显眼我第一次用的时候字段名写成大写结果属性没生成编译报错找了好久。3.2 数据绑定的性能陷阱工业面板上动辄几百个绑定如果每个绑定都走完整的PropertyChanged通知链UI 线程会被拖垮。我实测过一个场景200 个数据点每秒刷新一次界面直接卡成幻灯片。优化手段有几个。第一是减少绑定数量能用ItemsControl 数据模板的就不要手写一堆控件。第二是用CompiledBindingAvalonia 11 支持编译时绑定比反射绑定快很多TextBlock Text{CompiledBinding Temperature, StringFormat{}{0:F1}°C} /第三是控制刷新频率。Modbus 读回来可能是 200ms 一次但界面没必要跟着 200ms 刷。我在 ViewModel 里加了一层节流数据先存到字段UI 刷新用单独的 500ms 定时器统一触发。这样既保证了数据新鲜度又不会让 UI 线程过载。提示Avalonia 的绑定默认是弱引用但如果你在 ViewModel 里订阅了事件却没取消订阅照样会内存泄漏。工业程序要 7x24 运行这种泄漏累积几天就会出问题。养成在OnDetachedFromVisualTree或者 ViewModel 的Dispose里清理订阅的习惯。3.3 跨平台字体与 DPI 适配这个坑我在 Linux 终端上栽过。Windows 上跑得好好的界面部署到 Linux 后中文全变成方块。原因是 Linux 发行版默认没装中文字体Avalonia 找不到就渲染成豆腐块。解决办法是在应用启动时显式指定字体或者把字体文件打包进程序// App.axaml.cs public override void Initialize() { AvaloniaXamlLoader.Load(this); FontManager.Current.AddFontCollection(new EmbeddedFontCollection( new Uri(fonts:MyFonts, UriKind.Absolute), new Uri(avares://MyApp/Assets/Fonts, UriKind.Absolute))); }然后在样式里指定FontFamily。字体文件建议用开源的中文字体体积小、授权清晰。DPI 适配是另一个坑。工控机有的接 1080P 显示器有的接 4K 大屏缩放比例不一样。Avalonia 默认会跟随系统 DPI但如果你用了固定像素尺寸的控件在高 DPI 下就会显得特别小。正确做法是用相对单位或者用LayoutTransform做缩放。我在主窗口加了一个缩放系数绑定操作工可以根据现场屏幕大小自己调。3.4 图表控件的选型与性能趋势曲线是监控面板的刚需。我对比了几个方案方案优点缺点LiveChartsCore与 Avalonia 集成好API 现代大数据量下性能一般ScottPlot性能强适合科学绘图Avalonia 集成需要额外适配自绘 Canvas性能可控开发量大功能少最终选了 LiveChartsCore因为它的 Avalonia 包是官方维护的省心。但用的时候要注意不要每次数据更新都重建 Series。正确做法是初始化时创建好 Series更新时只改数据集合并且用ObservableCollection或者实现了INotifyCollectionChanged的集合。数据点数量也要控制。我一开始把历史数据全塞进曲线几千个点界面直接卡死。后来改成滑动窗口只保留最近 300 个点超出就移除最旧的。对于趋势观察来说300 个点足够看出变化趋势了。4. 常见问题与排查技巧实录4.1 连接层面的典型故障问题一连接建立成功但读数据超时。这种情况十有八九是单元标识Slave ID填错了。有些设备不校验 Slave ID填什么都回有些设备严格校验填错就静默丢弃。排查方法是用 Modbus 调试工具逐个试 Slave ID从 1 试到 255看哪个能正常响应。问题二读几轮之后突然全部超时。这通常是设备端的连接数限制或者 TCP 连接被中间网络设备回收了。Modbus TCP 的长连接在某些交换机上会被静默断开客户端却不知道。解决办法是加心跳检测定期读一个固定寄存器连续失败就主动断开重连。问题三数据偶尔错乱。如果排除了字节序问题那大概率是并发导致的响应串台。检查你的代码有没有在同一个连接上并发发请求。NModbus 的ModbusIpMaster不是线程安全的必须加锁。我整理了一个排查速查表现象可能原因排查方向连接超时IP/端口错、防火墙ping 通不通telnet 端口读数据超时Slave ID 错、地址越界用调试工具验证数据全为 0地址映射错核对协议地址计算数据为天文数字字节序/字序错尝试四种字节序组合偶发数据错乱并发串台检查是否加锁运行几小时后断连连接被回收加心跳和重连4.2 界面层面的典型故障问题一界面卡顿。先看是不是绑定太多或者刷新太频繁。用 Avalonia 的诊断工具看渲染帧率如果低于 30fps 就要优化。常见优化点减少绑定、用编译绑定、控制刷新频率、虚拟化长列表。问题二内存持续增长。工业程序要长期运行内存泄漏是致命的。重点检查事件订阅有没有取消、定时器有没有释放、大对象有没有及时置空。我习惯在程序里加一个内存监控超过阈值就记日志方便定位。问题三Linux 下界面错位。多半是字体或者 DPI 问题。先确认字体加载正常再检查缩放设置。Avalonia 在不同平台上的默认渲染行为有差异必要时针对平台做条件编译。4.3 现场部署的独家经验工业现场部署和开发环境完全是两码事。分享几条血泪教训。第一日志一定要落盘。现场出问题工程师不可能连调试器。Serilog 配置成按天滚动保留 30 天日志级别默认 Information出问题时可以临时调到 Debug。日志路径要可配置因为有些工控机的 C 盘是写保护的。第二配置要外置。设备 IP、寄存器地址、轮询周期这些千万别硬编码。我用 JSON 配置文件程序启动时读取界面上提供配置入口。这样现场调整参数不用重新编译。第三要有“安全模式”。如果 Modbus 连接失败界面不能白屏或者崩溃要显示明确的错误提示和重连按钮。操作工看到“设备离线正在重连”比看到一堆异常堆栈要安心得多。第四考虑断电恢复。工控机可能突然断电程序要能处理配置文件损坏的情况。我的做法是配置写入用“临时文件 原子替换”避免写一半断电导致配置全丢。提示现场调试时随身带一个 USB 转网口和一根网线。很多工控机只有一个网口接了设备就没法接调试电脑。有个备用网口能省很多事。5. 一些补充的技术细节5.1 异步与 UI 线程的配合Modbus 读取是 IO 操作必须异步否则会阻塞 UI 线程。但异步回调回来的时候可能不在 UI 线程上直接更新绑定属性会抛异常。正确做法是用Dispatcher.UIThread.InvokeAsync切回 UI 线程var data await _modbusService.ReadAsync(); await Dispatcher.UIThread.InvokeAsync(() { Temperature data.Temperature; });CommunityToolkit.Mvvm 在 Avalonia 里有个便利之处如果你在 UI 线程上调用[RelayCommand]标记的异步方法它默认会切回 UI 线程更新属性。但如果是后台定时器触发的更新就得手动切。这个区别要分清楚否则会出现“有时候正常有时候报错”的诡异现象。5.2 断线重连的状态机设计重连逻辑不要写成简单的while(true)循环那样容易失控。我设计了一个简单的状态机Connected正常读取Degraded连续失败 3 次进入降级降低轮询频率Disconnected连续失败 10 次断开连接启动重连定时器Reconnecting尝试重连成功则回到 Connected失败则退避重试退避策略用指数退避第一次 1 秒第二次 2 秒第三次 4 秒最大 30 秒。这样既不会频繁骚扰设备又能在设备恢复后快速重连。5.3 数据缓存与历史查询监控面板除了实时数据往往还要看历史趋势。我的做法是实时数据存内存环形缓冲区历史数据定时落盘到 SQLite。查询时先查内存内存没有的再查数据库。SQLite 在工业场景下足够用单文件、零配置、跨平台比装个 MySQL 省事多了。写入频率要注意不要每条数据都写盘那样 IO 压力大。我按 1 分钟聚合一次存平均值、最大值、最小值既省空间又够用。6. 最后聊几句实在的这个项目从立项到现场验收大概花了六周其中通信层调试占了一半时间。回过头看Modbus TCP 本身不难难的是各种设备的“方言”和现场环境的不可控。Avalonia 作为 UI 框架整体表现超出预期跨平台能力确实省了大事但生态成熟度相比 WPF 还有差距遇到问题查资料要有耐心。如果你也准备用 Avalonia 做工业项目我的建议是先把通信层做扎实用单元测试覆盖各种字节序和异常场景界面层不要追求花哨稳定清晰压倒一切现场部署前一定要在真实设备上跑够 72 小时很多问题只有长时间运行才会暴露。踩过的坑基本都写在这了希望能帮你少走点弯路。工业软件这行稳字当头共勉。
