接这个项目之前我以为Avalonia接Modbus TCP就是个拼积木的活儿UI用现成框架通讯用现成库踩点坑也该是幼儿园级别。真正干下来才知道从选型到现场部署每一步都在替我上强度。事情起因是客户现场有两台工控机一台Windows 7一台Ubuntu要跑同一个运行数据监控面板走Modbus TCP去采集车间里十来台设备的S7-200寄存器数据。为了不在两套代码之间反复横跳我最终选择了Avalonia作为跨平台UI方案后台通信基于NModbus库封装。这篇文章把这段“Avalonia 接 Modbus TCP 工业设备监控面板”过程中踩过的所有坑、做过的取舍、最后沉淀下来的代码套路原原本本写出来给准备走这条路的人当一份避坑参考。1. 选型那点事Avalonia Modbus TCP 到底怎么凑在一起的1.1 为什么没选WPF也没选Web方案最初我也动过WPF的念头毕竟做了七八年C#桌面开发对XAML和MVVM那一套熟得闭眼都能写。但客户一句话就让这条路堵死了工控机里有一台是Ubuntu 22.04WPF在没有Wine的情况下跑不起来我又不想在Linux机器上灌一层Wine来赌运气。Web方案倒是天然跨平台可现场设备屏当客户端浏览器用硬件配置不高打开页面就是几十个仪表盘加三张实时趋势曲线用Chrome渲染还频繁掉帧而且B/S架构需要常驻一个Web服务现场本来就没什么IT人员多一个进程就多一个故障点。所以Web也被我否了。剩下的候选里Qt太贵且C写UI效率低Electron打包体积太重量级。Avalonia恰好卡在中间语法和WPF几乎同源C#技术栈无缝迁移编译产物是原生程序不依赖浏览器渲染性能在工控机上够用。再加上NModbus这类纯C#的Modbus协议库整套技术栈没有一处需要引入C或者第三方运行时。对我来说选型核心逻辑就三条跨平台要稳定开发成本要可控后期维护要简单。Avalonia在这三点上都满足了。1.2 技术栈与整体项目结构从服务层到UI层怎么切分明确了UI框架之后我画了这样一个项目分层实际用下来非常解压Modbus.Core负责NModbus库的二次封装只暴露读寄存器、写线圈、检查连接状态这几个高内聚方法。DeviceService设备管理服务管理所有被采集设备的轮询线程、超时策略和重连逻辑。Models普通数据模型比如设备状态、传感器温度、运行电流这类POCO类不掺任何通知逻辑。ViewModels页面绑定层使用CommunityToolkit.Mvvm把多个设备数据聚合成UI需要的显示模型。ViewsAvalonia的AXAML页面只做控件布局和绑定声明。实际编码时我遵循一个很笨的规矩ViewModel永远不直接拿TcpClient对象后台PollingService照样转UI层不感知协议细节。通信层坏了界面顶多显示超时UI层崩了通信线程继续默默采数不至于整个面板全瘫。依赖注入方面我一开始想用Prism但Avalonia 11对Prism的适配还不够顺手。为了省时间我直接写了一个极简ServiceLocator效果一样还能让代码结构更直白。2. 环境搭建与项目初始化阶段看似简单坑也不少2.1 Avalonia的版本和项目模板陷阱Avalonia踩坑之旅从创建项目模板就开始。一开始我在终端直接跑dotnet new avalonia.app结果提示模板不存在——原来Avalonia的模板包需要单独安装dotnet new install Avalonia.Templates装完模板后我发现还有个avalonia.mvvm模板区别在于是否自带了ViewModel和绑定基础类。如果图省事直接选avalonia.app后面还得自己手动加MVVM包。另一个版本兼容问题更隐蔽Avalonia 11要求.NET SDK 6.0以上但如果你用的是老的.NET SDK编译时会报错告诉你System.Drawing找不到。我是直接用.NET 8构建的建议新项目一律以当前.NET LTS为基准。还有个大坑是XAML编译器的强类型绑定。Avalonia从11开始默认启用了x:CompileBindings在XAML里写{Binding Name}时如果绑定目标的类型没写对编译期不报错运行时数据就是死活不显示。后来我养成了一个习惯所有绑定的DataContext类型都显式声明比如UserControl x:ClassMyApp.Views.MainView xmlnshttps://github.com/avaloniaui x:DataTypevm:MainViewModel这样写至少能保证绑定类型在编译时被检查一遍。2.2 离线安装依赖包我这样备齐了全家桶现场工控机没外网是常态。刚开始我天真地把发布目录整个拷过去结果一运行就报FileNotFoundException提示缺一堆运行时native依赖。后来我学乖了开发机上直接发布成自包含模式dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish/linux64这个命令会把.NET运行时和所有native库都打进发布目录目标机器不需要安装.NET环境。但有一个前置动作很容易被忽略发布前要提前在开发机把项目还原好不然publish会从NuGet现拉包断网就全废。如果非要手动准备NuGet包可以在开发机上dotnet restore完之后把~/.nuget/packages目录下对应包版本的文件拷贝到离线机器的全局包目录。不过说实话这操作太折腾了远不如直接用--self-contained一把梭。我也试过用win-x64发到Windows 7工控机注意Windows 7不支持.NET 8至少得用.NET 6或需要额外打补丁。前提是客户机器装没装补丁最好先用发布版本做一次兼容性测试。2.3 在VS Code里开发Avalonia要装哪些扩展我给客户开发用的机器性能一般不想装那个动辄几十GB的Visual Studio全程都是用VS Code开发的。初期配置有点麻烦但熟悉之后效率也不低。必备扩展是这三款Avalonia for VS Code官方扩展提供AXAML语法高亮、代码补全和预览面板。注意预览功能需要项目能成功构建否则不生效。C# Dev KitC# IntelliSense、调试、项目处理的基础。NuGet Gallery不用来回切命令行直接在编辑器里管理包。VS Code里调试Avalonia有坑dotnet run之后如果XAML有语法错误程序只是闪退但终端里不一定打印错在哪。我一般是先dotnet build看错误列表再单独启动调试。调试时热重载的支持很有限改XAML经常要手动重启进程。后来我干脆把编译和自动重启写成了VS Code的tasks.json一键搞定{ label: Build and Run Avalonia, command: dotnet, args: [run], problemMatcher: $msCompile }虽然不如VS的XAML热重载美滋滋但胜在轻快至少不会因为IDE卡顿而影响调试心情。3. Modbus TCP通信层从“能通”到“稳定通”的距离3.1 使用NModbus库封装Modbus TCP客户端的核心思路Modbus TCP的协议栈本身很轻一个MBAP报文头加一个PDU。用NModbus库能省掉底层组包拆包的麻烦但我们自己的核心封装还是要保证两点一是每次读写前确认连接还在二是多线程访问下不能出现并发读写同一socket的情况。我最终设计了一个极简的ModbusTcpClient类public class ModbusTcpClient : IDisposable { private readonly object _lock new object(); private TcpClient _tcpClient; private IModbusMaster _master; private readonly string _ip; private readonly int _port; private readonly int _timeoutMs; public bool IsConnected _tcpClient?.Client.Connected true; public ModbusTcpClient(string ip, int port 502, int timeoutMs 800) { _ip ip; _port port; _timeoutMs timeoutMs; } private void EnsureConnected() { if (IsConnected) return; _tcpClient?.Dispose(); using var tempClient new TcpClient(); var connectTask tempClient.ConnectAsync(_ip, _port); if (!Task.WaitAny(new[] { connectTask }, _timeoutMs) || !tempClient.Connected) throw new TimeoutException($设备 {_ip}:{_port} 连接超时); _tcpClient tempClient; _tcpClient.ReceiveTimeout _timeoutMs; _tcpClient.SendTimeout _timeoutMs; _master ModbusIpMaster.CreateIp(_tcpClient); } public ushort[] ReadHoldingRegisters(byte slaveId, ushort startAddress, ushort count) { lock (_lock) { EnsureConnected(); return _master.ReadHoldingRegisters(slaveId, startAddress, count); } } public void Dispose() { _tcpClient?.Dispose(); } }这里有个小设计点EnsureConnected()内部用临时的TcpClient去做异步连接然后指定超时时间。因为TcpClient.ConnectAsync在某些设备黑盒的情况下可能卡住很久直接不设超时会让整个轮询线程瘫痪。3.2 字节序与数据类型被高低位倒置坑到怀疑人生通信层代码写完之后第一次现场实验就给我上了一课。我用NModbus读回来一个ushort数组寄存器值像模像样可一和设备屏上的数据对比就发现完全对不上。一个标称温度25.6摄氏度的点位我读出来是65408。排查半天最后发现是寄存器的字节序和浮点数高低字顺序出了问题。Modbus协议本身只规定寄存器地址和字节顺序大端传输但具体的32位浮点数在PLC/仪表内存里拆成两个16位寄存器的顺序不同厂家完全随缘。我在这套设备上遇到的情况是浮点数高16位放在前一个寄存器低16位放在后一个寄存器也就是所谓的大端字序但还有一个第三方仪表偏偏相反。应对办法是把字节序解析逻辑做成可配置项同时在代码里做一个安全转换public static float ReadFloatFromRegisters(ushort[] data, int offset, bool swapWords) { uint rawValue; if (swapWords) rawValue ((uint)data[offset 1] 16) | data[offset]; else rawValue ((uint)data[offset] 16) | data[offset 1]; return BitConverter.UInt32BitsToSingle(rawValue); }后来我把swapWords参数直接放进了点位配置表每一条变量都标注字节序类型。这样现场若换了一台妖怪设备只要改配置不用重新编译。除了浮点字节序还有寄存器地址偏移问题。有的设备实际编程地址是40001但协议报文里的地址是0因为4X开头是功能码决定的直接把PLC上的寄存器编号当成协议地址去读会整体错位。记住一点Modbus TCP报文头里放的是偏移量不是PLC组态软件里显示的正文地址。这个坑在刚接触Modbus的人那里出现频次极高。3.3 超时、重试和断线重连工业通信的命根子设备在车间里掉线是家常便饭不是网线松了就是PLC自己重启了。如果程序没有断线重连面板上就会出现一屏幕的“假数据”操作员拿去当实时值用后果不堪设想。我在通信层封装里做了三层防护读写超时前面代码里我把TcpClient的SendTimeout和ReceiveTimeout统一设成800ms。真实业务场景中这个值再调大也会导致轮询周期拉长调小则可能因为现场网络抖动而误报。我最终采用的是默认800ms如果某台设备比较慢单独调大该设备的超时参数。连接状态检查每次读写前调用EnsureConnected如果连接状态异常直接建立新连接。业务线程不需要关心异常细节。后台重连循环在DeviceService层每一台设备都会维持一个长期的后台任务。当某次读写抛出异常后会标记该设备状态为“离线”并停掉后续任务。后台启动一个指数退避的重连机制private async Task ReconnectLoop(string deviceId, CancellationToken ct) { int retryDelayMs 1000; while (!ct.IsCancellationRequested) { try { await _client.ConnectAsync(ct); _deviceStatus[deviceId] DeviceState.Online; break; } catch { _deviceStatus[deviceId] DeviceState.WaitingRetry; await Task.Delay(retryDelayMs, ct); retryDelayMs Math.Min(retryDelayMs * 2, 30000); } } }指数退避的后两次重试间隔逐渐拉长到30秒上限避免宕机的PLC恢复前就一直高频浪费CPU和网络资源。如果你觉得这套逻辑复杂也可以偷懒直接在每个轮询循环里try-catch重连但不是长久之计。我在项目里还加了一个“连续失败n次才标记离线”的计数器即每台设备连续3次读不到数据才判定掉线单次的延迟或震荡不会导致界面上的状态闪跳。3.4 多设备轮询怎么才能不把UI线程卡死十台设备每台200ms轮询一次如果全部放在UI线程跑界面必卡无疑。我最初的错误在这里把Timer放在了UI层结果UI刷新频率和设备采集频率互相干扰导致一个看似简单的“仪表圆盘走针”都跟PPT似的一卡一卡。后来我改成纯粹的BackgroundService模式一个后台轮询线程负责所有设备的读取UI的DispatcherTimer只负责每500ms从最新设备数据快照中抓一次数值刷新界面。线程间通过一个线程安全的ConcurrentDictionarystring, DeviceSnapshot传递数据完全解耦。多设备采集并发时也给每台设备单独建一个Task。但这里有个细节不能无脑用Task.Factory.StartNew注册超多线程。如果设备数量超过几十台线程上下文切换开销会累加更稳妥的方案是用SemaphoreSlim限制并发数量private readonly SemaphoreSlim _throttle new SemaphoreSlim(4);只允许同屏并发4台设备剩下的排队等信号量既不会饿死性能差的设备也不会因为线程数过多导致CPU被打满。实测10台设备轮询周期稳定在1秒内UI帧率不再有明显掉帧。4. UI层绑定与刷新Avalonia里最折磨人的地方4.1 INotifyPropertyChanged与ObservableCollection的线程陷阱Avalonia虽然支持后台线程直接更新属性不像WPF强制走Dispatcher但ObservableCollection的非UI线程修改依然会翻车。我遇到的现象是后台线程持续往一个ObservableCollection里添加数据界面偶尔报NotSupportedException或者显示的数据突然少一行。这个异常并非每次都稳定复现非常难查。解法也很简单粗暴所有集合的增删改一律丢到Dispatcher线程Dispatcher.UIThread.Post(() { _logRecords.Add(newRecord); });但如果你后台频率太高这种无脑Post会导致UI线程积压大量任务。我最后的优化是缓冲批量提交后台线程收集最近100条记录到List然后用一个AutoResetEvent通知UI线程统一一次性更新到ObservableCollection。界面仅仅在收到通知后执行AddRange逻辑实际刷新开销小很多。对普通属性而言Avalonia的跨线程更新约束比WPF宽松一些但为了好维护我还是统统走Dispatcher.UIThread.Post习惯性的线程安全策略才能避免回归性BUG。4.2 绑定不更新和数据模板失效的排查记录绑定不更新是Avalonia继承XAML风格以来最经典的坑。一开始我手写INotifyPropertyChanged常常因为属性名里一个字母大小写对不上导致UI永久空白。后来换成CommunityToolkit.Mvvm的源生成器问题要不是不用重新编译了才半只脚踩出坑public partial class DeviceStatusViewModel : ObservableObject { [ObservableProperty] private string _deviceName; [ObservableProperty] private bool _isOnline; }使用这个库编译时会自动生成属性通知逻辑避免了手动通知遗漏。但注意如果用了partial属性生成必须在ViewModel类声明上加上partial关键字否则生成器一串都不干活。还有一个数据模板的坑Avalonia的ItemsControl里列表项的样式触发器和WPF写法差异很大。我原本以为DataTrigger能直接平移过来结果在Avalonia 11里这个写法已经变了多数情况下要用Classes.xxx结合样式选择器。例如给不同状态的传感器绑定颜色Ellipse Width14 Height14 Ellipse.Styles Style SelectorEllipse Setter PropertyFill ValueGray / /Style Style SelectorEllipse.isOnline Setter PropertyFill ValueLimeGreen / /Style /Ellipse.Styles /Ellipse然后在ViewModels中维护IsOnline属性用Classes.isOnline{Binding IsOnline}去控制样式触发。这套方案比WPF的DataTrigger简洁但前提是你得知道Avalonia不兼容WPF的DataTrigger写法。我第一次照搬WPF代码时界面空白了整整一下午。4.3 数据可视化仪表盘、趋势图该用什么方案工业监控面板没图表就没灵魂。我调研了半天最后选了LiveChartsCore.SkiaSharpView.Avalonia这是LiveCharts2的Avalonia版本。Skia渲染的好处是跨平台一致性极好Linux下的折线图线条不受Cairo的光栅化差异影响。趋势图初始接入很顺利但踩了个性能坑当数据点从1000个变成10000个时拖动窗口直接明显掉帧。解决办法有两个一是限制显示的点数为N个旧点N个新点二是开启LineSeries的EnableNullSplitting? 不实际上最有用的是禁用默认的动画更新var series new LineSeriesdouble { Values new double[] { ... }, GeometrySize 0, LineSmoothness 0, EnableAnimations false };关闭动画后刷新帧数明显稳定。工业监控本来就不需要花里胡哨的动画实时数据图要的就是直接、清晰、低延迟。如果你不想引入图表库也可以自己用DrawingContext画一条简单折线但涉及到坐标变换、轴刻度、采样率。如果时间紧张那就学我用LiveCharts吧它的坑是暂时爬不完的但至少维护者有在持续更新。5. 部署到现场后的稳定性优化与二次踩坑5.1 自绘控件与Cairo渲染在工控机上的性能差异Avalonia底层的渲染后端分为Skia和Cairo两个版本。Windows上默认Direct2DLinux上则是Skia优先。工控机CPU比较弱如果渲染的是复杂路径、半透明、阴影效果会占用大量CPU资源。我在一个状态页面里放了十几个圆形的仪表表盘每50ms刷新一次软件在客户机上CPU直接上到70%。后来做了以下优化所有仪表盘和装饰元素改用纯Path绘制不到万不得已不用模糊特效。刷新频率从200ms降到1秒但单独拆分出“报警状态”面板以200ms高频刷新。把复杂的仪表盘子页面做成缓存避免无意义的重绘。实测优化后CPU占用降到12%左右界面还是顺畅的。记住在工控机上效率永远是UX的第一前提视觉炫酷不如画面快。这中间还遇到一个和渲染后端相关的问题如果Linux系统缺少fontconfig和libfontconfig1库程序启动时Skia初始化会失败控件全部显示空白。解决办法是在部署文档里明确写出依赖项或者发布前把用到的所有Skia native库塞进输出目录。5.2 跨平台发布时的“缺依赖”和路径问题跨平台发布我踩了两个明确的坑。第一个是依赖缺失。在Windows开发机上用dotnet publish -r linux-x64 --self-contained发布之后拷到Ubuntu上一运行就报DllNotFoundException: libSkiaSharp.so。查了半天发现是SkiaSharp库默认不包含在某些系统缺失的原生依赖里需要手动安装sudo apt install libfontconfig1 libfreetype6 libxcursor1 libxrandr2 libxinerama1 libx11-6如果遇到其他native库缺失可以用ldd查看发布目录下的.so文件依赖情况逐个补齐。第二个是工作目录的问题。我在代码里用了相对路径config/modbus.json加载配置文件正常启动没问题但用systemd服务方式挂后台时当前目录变成了/配置文件直接找不到。后来把所有路径读取都改成基于AppContext.BaseDirectoryvar baseDir AppContext.BaseDirectory; var configPath Path.Combine(baseDir, config, modbus.json);千万要记得不要在程序里依赖Environment.CurrentDirectory因为启动方式一变这个值就变了。5.3 日志与异常兜底现场调试的最后一根救命稻草现场没有Visual Studio没有调试器出问题就只能看日志。我在项目一开头就引入Serilog配置File和Console双输出。日志级别上设备通信相关的记录得非常全包括每次读写的设备ID、寄存器起始地址、成功/失败耗时、异常堆栈。关键所有后台线程都需要包一层try-catch否则一个简单的通信异常可能让整个服务线程静默死亡。比如前面那个重连循环我需要在里面加上异常捕获不至于循环还没跑完就被Exception偷偷中断while (!ct.IsCancellationRequested) { try { await _client.ReadAsync(); } catch (Exception ex) { _logger.Error(ex, Device {Id} read failed, deviceId); await Task.Delay(500, ct); } }此外还有一个“看门狗”机制UI侧用一个秒级心跳显示“最后数据时间”如果超过2秒没有新数据界面自动弹一个大大的黄色“数据超时”提示。这样现场操作员不用看代码光看交互界面就知道设备通讯异常了。日志文件我做了按天滚动保留最近30天方便去现场翻记录定位问题。Serilog的这个配置很便宜值得每个工业项目都标配。这个项目从开发到现场部署最让我感慨的是Avalonia作为一个跨平台UI框架已经很接近WPF的体验了但在第三方生态、工具链、社区示例这些软实力上还得靠实践去填坑Modbus TCP协议本身不难难的是现场设备的随机性和不规范性每个厂家的“特殊癖好”都要靠配置化去兼容。如果你现在正打算搞C# Avalonia Modbus TCP这套组合我的核心建议就一句话把通信层做成完全独立的服务把UI层做成纯展示的壳把所有现场差异全部赶进配置文件。最后再分享一个开发时的小技巧每次dotnet publish都把--self-contained true加进去哪怕只是用于本地测试也能提前暴露大多数native依赖和路径问题别等到现场才追着DllNotFoundException抓耳挠腮。
Avalonia + Modbus TCP 跨平台工业监控面板开发实战与避坑指南
接这个项目之前我以为Avalonia接Modbus TCP就是个拼积木的活儿UI用现成框架通讯用现成库踩点坑也该是幼儿园级别。真正干下来才知道从选型到现场部署每一步都在替我上强度。事情起因是客户现场有两台工控机一台Windows 7一台Ubuntu要跑同一个运行数据监控面板走Modbus TCP去采集车间里十来台设备的S7-200寄存器数据。为了不在两套代码之间反复横跳我最终选择了Avalonia作为跨平台UI方案后台通信基于NModbus库封装。这篇文章把这段“Avalonia 接 Modbus TCP 工业设备监控面板”过程中踩过的所有坑、做过的取舍、最后沉淀下来的代码套路原原本本写出来给准备走这条路的人当一份避坑参考。1. 选型那点事Avalonia Modbus TCP 到底怎么凑在一起的1.1 为什么没选WPF也没选Web方案最初我也动过WPF的念头毕竟做了七八年C#桌面开发对XAML和MVVM那一套熟得闭眼都能写。但客户一句话就让这条路堵死了工控机里有一台是Ubuntu 22.04WPF在没有Wine的情况下跑不起来我又不想在Linux机器上灌一层Wine来赌运气。Web方案倒是天然跨平台可现场设备屏当客户端浏览器用硬件配置不高打开页面就是几十个仪表盘加三张实时趋势曲线用Chrome渲染还频繁掉帧而且B/S架构需要常驻一个Web服务现场本来就没什么IT人员多一个进程就多一个故障点。所以Web也被我否了。剩下的候选里Qt太贵且C写UI效率低Electron打包体积太重量级。Avalonia恰好卡在中间语法和WPF几乎同源C#技术栈无缝迁移编译产物是原生程序不依赖浏览器渲染性能在工控机上够用。再加上NModbus这类纯C#的Modbus协议库整套技术栈没有一处需要引入C或者第三方运行时。对我来说选型核心逻辑就三条跨平台要稳定开发成本要可控后期维护要简单。Avalonia在这三点上都满足了。1.2 技术栈与整体项目结构从服务层到UI层怎么切分明确了UI框架之后我画了这样一个项目分层实际用下来非常解压Modbus.Core负责NModbus库的二次封装只暴露读寄存器、写线圈、检查连接状态这几个高内聚方法。DeviceService设备管理服务管理所有被采集设备的轮询线程、超时策略和重连逻辑。Models普通数据模型比如设备状态、传感器温度、运行电流这类POCO类不掺任何通知逻辑。ViewModels页面绑定层使用CommunityToolkit.Mvvm把多个设备数据聚合成UI需要的显示模型。ViewsAvalonia的AXAML页面只做控件布局和绑定声明。实际编码时我遵循一个很笨的规矩ViewModel永远不直接拿TcpClient对象后台PollingService照样转UI层不感知协议细节。通信层坏了界面顶多显示超时UI层崩了通信线程继续默默采数不至于整个面板全瘫。依赖注入方面我一开始想用Prism但Avalonia 11对Prism的适配还不够顺手。为了省时间我直接写了一个极简ServiceLocator效果一样还能让代码结构更直白。2. 环境搭建与项目初始化阶段看似简单坑也不少2.1 Avalonia的版本和项目模板陷阱Avalonia踩坑之旅从创建项目模板就开始。一开始我在终端直接跑dotnet new avalonia.app结果提示模板不存在——原来Avalonia的模板包需要单独安装dotnet new install Avalonia.Templates装完模板后我发现还有个avalonia.mvvm模板区别在于是否自带了ViewModel和绑定基础类。如果图省事直接选avalonia.app后面还得自己手动加MVVM包。另一个版本兼容问题更隐蔽Avalonia 11要求.NET SDK 6.0以上但如果你用的是老的.NET SDK编译时会报错告诉你System.Drawing找不到。我是直接用.NET 8构建的建议新项目一律以当前.NET LTS为基准。还有个大坑是XAML编译器的强类型绑定。Avalonia从11开始默认启用了x:CompileBindings在XAML里写{Binding Name}时如果绑定目标的类型没写对编译期不报错运行时数据就是死活不显示。后来我养成了一个习惯所有绑定的DataContext类型都显式声明比如UserControl x:ClassMyApp.Views.MainView xmlnshttps://github.com/avaloniaui x:DataTypevm:MainViewModel这样写至少能保证绑定类型在编译时被检查一遍。2.2 离线安装依赖包我这样备齐了全家桶现场工控机没外网是常态。刚开始我天真地把发布目录整个拷过去结果一运行就报FileNotFoundException提示缺一堆运行时native依赖。后来我学乖了开发机上直接发布成自包含模式dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish/linux64这个命令会把.NET运行时和所有native库都打进发布目录目标机器不需要安装.NET环境。但有一个前置动作很容易被忽略发布前要提前在开发机把项目还原好不然publish会从NuGet现拉包断网就全废。如果非要手动准备NuGet包可以在开发机上dotnet restore完之后把~/.nuget/packages目录下对应包版本的文件拷贝到离线机器的全局包目录。不过说实话这操作太折腾了远不如直接用--self-contained一把梭。我也试过用win-x64发到Windows 7工控机注意Windows 7不支持.NET 8至少得用.NET 6或需要额外打补丁。前提是客户机器装没装补丁最好先用发布版本做一次兼容性测试。2.3 在VS Code里开发Avalonia要装哪些扩展我给客户开发用的机器性能一般不想装那个动辄几十GB的Visual Studio全程都是用VS Code开发的。初期配置有点麻烦但熟悉之后效率也不低。必备扩展是这三款Avalonia for VS Code官方扩展提供AXAML语法高亮、代码补全和预览面板。注意预览功能需要项目能成功构建否则不生效。C# Dev KitC# IntelliSense、调试、项目处理的基础。NuGet Gallery不用来回切命令行直接在编辑器里管理包。VS Code里调试Avalonia有坑dotnet run之后如果XAML有语法错误程序只是闪退但终端里不一定打印错在哪。我一般是先dotnet build看错误列表再单独启动调试。调试时热重载的支持很有限改XAML经常要手动重启进程。后来我干脆把编译和自动重启写成了VS Code的tasks.json一键搞定{ label: Build and Run Avalonia, command: dotnet, args: [run], problemMatcher: $msCompile }虽然不如VS的XAML热重载美滋滋但胜在轻快至少不会因为IDE卡顿而影响调试心情。3. Modbus TCP通信层从“能通”到“稳定通”的距离3.1 使用NModbus库封装Modbus TCP客户端的核心思路Modbus TCP的协议栈本身很轻一个MBAP报文头加一个PDU。用NModbus库能省掉底层组包拆包的麻烦但我们自己的核心封装还是要保证两点一是每次读写前确认连接还在二是多线程访问下不能出现并发读写同一socket的情况。我最终设计了一个极简的ModbusTcpClient类public class ModbusTcpClient : IDisposable { private readonly object _lock new object(); private TcpClient _tcpClient; private IModbusMaster _master; private readonly string _ip; private readonly int _port; private readonly int _timeoutMs; public bool IsConnected _tcpClient?.Client.Connected true; public ModbusTcpClient(string ip, int port 502, int timeoutMs 800) { _ip ip; _port port; _timeoutMs timeoutMs; } private void EnsureConnected() { if (IsConnected) return; _tcpClient?.Dispose(); using var tempClient new TcpClient(); var connectTask tempClient.ConnectAsync(_ip, _port); if (!Task.WaitAny(new[] { connectTask }, _timeoutMs) || !tempClient.Connected) throw new TimeoutException($设备 {_ip}:{_port} 连接超时); _tcpClient tempClient; _tcpClient.ReceiveTimeout _timeoutMs; _tcpClient.SendTimeout _timeoutMs; _master ModbusIpMaster.CreateIp(_tcpClient); } public ushort[] ReadHoldingRegisters(byte slaveId, ushort startAddress, ushort count) { lock (_lock) { EnsureConnected(); return _master.ReadHoldingRegisters(slaveId, startAddress, count); } } public void Dispose() { _tcpClient?.Dispose(); } }这里有个小设计点EnsureConnected()内部用临时的TcpClient去做异步连接然后指定超时时间。因为TcpClient.ConnectAsync在某些设备黑盒的情况下可能卡住很久直接不设超时会让整个轮询线程瘫痪。3.2 字节序与数据类型被高低位倒置坑到怀疑人生通信层代码写完之后第一次现场实验就给我上了一课。我用NModbus读回来一个ushort数组寄存器值像模像样可一和设备屏上的数据对比就发现完全对不上。一个标称温度25.6摄氏度的点位我读出来是65408。排查半天最后发现是寄存器的字节序和浮点数高低字顺序出了问题。Modbus协议本身只规定寄存器地址和字节顺序大端传输但具体的32位浮点数在PLC/仪表内存里拆成两个16位寄存器的顺序不同厂家完全随缘。我在这套设备上遇到的情况是浮点数高16位放在前一个寄存器低16位放在后一个寄存器也就是所谓的大端字序但还有一个第三方仪表偏偏相反。应对办法是把字节序解析逻辑做成可配置项同时在代码里做一个安全转换public static float ReadFloatFromRegisters(ushort[] data, int offset, bool swapWords) { uint rawValue; if (swapWords) rawValue ((uint)data[offset 1] 16) | data[offset]; else rawValue ((uint)data[offset] 16) | data[offset 1]; return BitConverter.UInt32BitsToSingle(rawValue); }后来我把swapWords参数直接放进了点位配置表每一条变量都标注字节序类型。这样现场若换了一台妖怪设备只要改配置不用重新编译。除了浮点字节序还有寄存器地址偏移问题。有的设备实际编程地址是40001但协议报文里的地址是0因为4X开头是功能码决定的直接把PLC上的寄存器编号当成协议地址去读会整体错位。记住一点Modbus TCP报文头里放的是偏移量不是PLC组态软件里显示的正文地址。这个坑在刚接触Modbus的人那里出现频次极高。3.3 超时、重试和断线重连工业通信的命根子设备在车间里掉线是家常便饭不是网线松了就是PLC自己重启了。如果程序没有断线重连面板上就会出现一屏幕的“假数据”操作员拿去当实时值用后果不堪设想。我在通信层封装里做了三层防护读写超时前面代码里我把TcpClient的SendTimeout和ReceiveTimeout统一设成800ms。真实业务场景中这个值再调大也会导致轮询周期拉长调小则可能因为现场网络抖动而误报。我最终采用的是默认800ms如果某台设备比较慢单独调大该设备的超时参数。连接状态检查每次读写前调用EnsureConnected如果连接状态异常直接建立新连接。业务线程不需要关心异常细节。后台重连循环在DeviceService层每一台设备都会维持一个长期的后台任务。当某次读写抛出异常后会标记该设备状态为“离线”并停掉后续任务。后台启动一个指数退避的重连机制private async Task ReconnectLoop(string deviceId, CancellationToken ct) { int retryDelayMs 1000; while (!ct.IsCancellationRequested) { try { await _client.ConnectAsync(ct); _deviceStatus[deviceId] DeviceState.Online; break; } catch { _deviceStatus[deviceId] DeviceState.WaitingRetry; await Task.Delay(retryDelayMs, ct); retryDelayMs Math.Min(retryDelayMs * 2, 30000); } } }指数退避的后两次重试间隔逐渐拉长到30秒上限避免宕机的PLC恢复前就一直高频浪费CPU和网络资源。如果你觉得这套逻辑复杂也可以偷懒直接在每个轮询循环里try-catch重连但不是长久之计。我在项目里还加了一个“连续失败n次才标记离线”的计数器即每台设备连续3次读不到数据才判定掉线单次的延迟或震荡不会导致界面上的状态闪跳。3.4 多设备轮询怎么才能不把UI线程卡死十台设备每台200ms轮询一次如果全部放在UI线程跑界面必卡无疑。我最初的错误在这里把Timer放在了UI层结果UI刷新频率和设备采集频率互相干扰导致一个看似简单的“仪表圆盘走针”都跟PPT似的一卡一卡。后来我改成纯粹的BackgroundService模式一个后台轮询线程负责所有设备的读取UI的DispatcherTimer只负责每500ms从最新设备数据快照中抓一次数值刷新界面。线程间通过一个线程安全的ConcurrentDictionarystring, DeviceSnapshot传递数据完全解耦。多设备采集并发时也给每台设备单独建一个Task。但这里有个细节不能无脑用Task.Factory.StartNew注册超多线程。如果设备数量超过几十台线程上下文切换开销会累加更稳妥的方案是用SemaphoreSlim限制并发数量private readonly SemaphoreSlim _throttle new SemaphoreSlim(4);只允许同屏并发4台设备剩下的排队等信号量既不会饿死性能差的设备也不会因为线程数过多导致CPU被打满。实测10台设备轮询周期稳定在1秒内UI帧率不再有明显掉帧。4. UI层绑定与刷新Avalonia里最折磨人的地方4.1 INotifyPropertyChanged与ObservableCollection的线程陷阱Avalonia虽然支持后台线程直接更新属性不像WPF强制走Dispatcher但ObservableCollection的非UI线程修改依然会翻车。我遇到的现象是后台线程持续往一个ObservableCollection里添加数据界面偶尔报NotSupportedException或者显示的数据突然少一行。这个异常并非每次都稳定复现非常难查。解法也很简单粗暴所有集合的增删改一律丢到Dispatcher线程Dispatcher.UIThread.Post(() { _logRecords.Add(newRecord); });但如果你后台频率太高这种无脑Post会导致UI线程积压大量任务。我最后的优化是缓冲批量提交后台线程收集最近100条记录到List然后用一个AutoResetEvent通知UI线程统一一次性更新到ObservableCollection。界面仅仅在收到通知后执行AddRange逻辑实际刷新开销小很多。对普通属性而言Avalonia的跨线程更新约束比WPF宽松一些但为了好维护我还是统统走Dispatcher.UIThread.Post习惯性的线程安全策略才能避免回归性BUG。4.2 绑定不更新和数据模板失效的排查记录绑定不更新是Avalonia继承XAML风格以来最经典的坑。一开始我手写INotifyPropertyChanged常常因为属性名里一个字母大小写对不上导致UI永久空白。后来换成CommunityToolkit.Mvvm的源生成器问题要不是不用重新编译了才半只脚踩出坑public partial class DeviceStatusViewModel : ObservableObject { [ObservableProperty] private string _deviceName; [ObservableProperty] private bool _isOnline; }使用这个库编译时会自动生成属性通知逻辑避免了手动通知遗漏。但注意如果用了partial属性生成必须在ViewModel类声明上加上partial关键字否则生成器一串都不干活。还有一个数据模板的坑Avalonia的ItemsControl里列表项的样式触发器和WPF写法差异很大。我原本以为DataTrigger能直接平移过来结果在Avalonia 11里这个写法已经变了多数情况下要用Classes.xxx结合样式选择器。例如给不同状态的传感器绑定颜色Ellipse Width14 Height14 Ellipse.Styles Style SelectorEllipse Setter PropertyFill ValueGray / /Style Style SelectorEllipse.isOnline Setter PropertyFill ValueLimeGreen / /Style /Ellipse.Styles /Ellipse然后在ViewModels中维护IsOnline属性用Classes.isOnline{Binding IsOnline}去控制样式触发。这套方案比WPF的DataTrigger简洁但前提是你得知道Avalonia不兼容WPF的DataTrigger写法。我第一次照搬WPF代码时界面空白了整整一下午。4.3 数据可视化仪表盘、趋势图该用什么方案工业监控面板没图表就没灵魂。我调研了半天最后选了LiveChartsCore.SkiaSharpView.Avalonia这是LiveCharts2的Avalonia版本。Skia渲染的好处是跨平台一致性极好Linux下的折线图线条不受Cairo的光栅化差异影响。趋势图初始接入很顺利但踩了个性能坑当数据点从1000个变成10000个时拖动窗口直接明显掉帧。解决办法有两个一是限制显示的点数为N个旧点N个新点二是开启LineSeries的EnableNullSplitting? 不实际上最有用的是禁用默认的动画更新var series new LineSeriesdouble { Values new double[] { ... }, GeometrySize 0, LineSmoothness 0, EnableAnimations false };关闭动画后刷新帧数明显稳定。工业监控本来就不需要花里胡哨的动画实时数据图要的就是直接、清晰、低延迟。如果你不想引入图表库也可以自己用DrawingContext画一条简单折线但涉及到坐标变换、轴刻度、采样率。如果时间紧张那就学我用LiveCharts吧它的坑是暂时爬不完的但至少维护者有在持续更新。5. 部署到现场后的稳定性优化与二次踩坑5.1 自绘控件与Cairo渲染在工控机上的性能差异Avalonia底层的渲染后端分为Skia和Cairo两个版本。Windows上默认Direct2DLinux上则是Skia优先。工控机CPU比较弱如果渲染的是复杂路径、半透明、阴影效果会占用大量CPU资源。我在一个状态页面里放了十几个圆形的仪表表盘每50ms刷新一次软件在客户机上CPU直接上到70%。后来做了以下优化所有仪表盘和装饰元素改用纯Path绘制不到万不得已不用模糊特效。刷新频率从200ms降到1秒但单独拆分出“报警状态”面板以200ms高频刷新。把复杂的仪表盘子页面做成缓存避免无意义的重绘。实测优化后CPU占用降到12%左右界面还是顺畅的。记住在工控机上效率永远是UX的第一前提视觉炫酷不如画面快。这中间还遇到一个和渲染后端相关的问题如果Linux系统缺少fontconfig和libfontconfig1库程序启动时Skia初始化会失败控件全部显示空白。解决办法是在部署文档里明确写出依赖项或者发布前把用到的所有Skia native库塞进输出目录。5.2 跨平台发布时的“缺依赖”和路径问题跨平台发布我踩了两个明确的坑。第一个是依赖缺失。在Windows开发机上用dotnet publish -r linux-x64 --self-contained发布之后拷到Ubuntu上一运行就报DllNotFoundException: libSkiaSharp.so。查了半天发现是SkiaSharp库默认不包含在某些系统缺失的原生依赖里需要手动安装sudo apt install libfontconfig1 libfreetype6 libxcursor1 libxrandr2 libxinerama1 libx11-6如果遇到其他native库缺失可以用ldd查看发布目录下的.so文件依赖情况逐个补齐。第二个是工作目录的问题。我在代码里用了相对路径config/modbus.json加载配置文件正常启动没问题但用systemd服务方式挂后台时当前目录变成了/配置文件直接找不到。后来把所有路径读取都改成基于AppContext.BaseDirectoryvar baseDir AppContext.BaseDirectory; var configPath Path.Combine(baseDir, config, modbus.json);千万要记得不要在程序里依赖Environment.CurrentDirectory因为启动方式一变这个值就变了。5.3 日志与异常兜底现场调试的最后一根救命稻草现场没有Visual Studio没有调试器出问题就只能看日志。我在项目一开头就引入Serilog配置File和Console双输出。日志级别上设备通信相关的记录得非常全包括每次读写的设备ID、寄存器起始地址、成功/失败耗时、异常堆栈。关键所有后台线程都需要包一层try-catch否则一个简单的通信异常可能让整个服务线程静默死亡。比如前面那个重连循环我需要在里面加上异常捕获不至于循环还没跑完就被Exception偷偷中断while (!ct.IsCancellationRequested) { try { await _client.ReadAsync(); } catch (Exception ex) { _logger.Error(ex, Device {Id} read failed, deviceId); await Task.Delay(500, ct); } }此外还有一个“看门狗”机制UI侧用一个秒级心跳显示“最后数据时间”如果超过2秒没有新数据界面自动弹一个大大的黄色“数据超时”提示。这样现场操作员不用看代码光看交互界面就知道设备通讯异常了。日志文件我做了按天滚动保留最近30天方便去现场翻记录定位问题。Serilog的这个配置很便宜值得每个工业项目都标配。这个项目从开发到现场部署最让我感慨的是Avalonia作为一个跨平台UI框架已经很接近WPF的体验了但在第三方生态、工具链、社区示例这些软实力上还得靠实践去填坑Modbus TCP协议本身不难难的是现场设备的随机性和不规范性每个厂家的“特殊癖好”都要靠配置化去兼容。如果你现在正打算搞C# Avalonia Modbus TCP这套组合我的核心建议就一句话把通信层做成完全独立的服务把UI层做成纯展示的壳把所有现场差异全部赶进配置文件。最后再分享一个开发时的小技巧每次dotnet publish都把--self-contained true加进去哪怕只是用于本地测试也能提前暴露大多数native依赖和路径问题别等到现场才追着DllNotFoundException抓耳挠腮。
