C#跨平台移动工业监控：从TCP Socket到MVVM的完整实现-平芜编程栈

工业监控终端过去多数固定在中控室或工控机旁边，现场问题往往要回到大屏前才能确认。要做移动跨平台工业监控，C# 是一条很自然的技术路线，因为不少工厂已有的数据采集和上位机代码都是 C# 写的。移动化之后，巡检人员可以直接在手机上查看温度、压力、转速和设备状态，异常发生时也能第一时间收到反馈。如果你正在做与 B1151 类似的课题，下面这套设计可以当作一个可运行的起点。

这篇文章以一个最小闭环为主线：先用 C# 写一个模拟设备数据源，通过 TCP 定时推送温度数据；再用 Xamarin.Forms 写一个跨平台移动端 App，完成连接、接收、解析、展示、告警和断线重连。读完这份实践后，你可以把同一套思路迁移到 PLC、扫码枪、相机 SDK、MQTT 等更复杂的工业接入场景。

1. 移动跨平台工业监控应用的需求边界与技术选型

1.1 需求边界：移动监控不是简单把桌面端缩小

工业监控应用的核心需求通常包括五类：

实时数据查看：温度、压力、液位、转速等过程量按秒级或毫秒级刷新。
设备状态展示：运行、停机、故障、维护等状态需要直观可见。
告警提醒：数据越限、设备异常时主动通知相关人员。
历史查询：查看趋势曲线、报表和操作记录。
远程操作：启动、停止、参数写入等控制类操作，且必须有权限校验。

桌面端上位机通常屏幕大、电源稳定、网络固定，可以在一个界面放几十个变量。移动端则完全不同：手机屏幕小、网络会抖动、系统会限制后台运行，导致移动监控不是把上位机界面缩小，而是需要重新设计信息的展示密度、交互方式和通信策略。

在设计阶段就要想清楚三个问题：

移动端需要展示哪些数据，不需要展示哪些数据。
网络不稳定或断线时，App 应该表现成什么样。
告警是在设备端判断，还是在服务端判断，还是移动端自行判断。

这些边界决定后续架构和数据流的设计方向。

1.2 为什么选择 C# 跨平台方案

C# 跨平台移动开发主要对应 Xamarin.Forms 和 .NET MAUI 两条路线。选择它，不是因为跨平台技术本身有多热门，而是因为它和很多工厂已有的 C# 技术栈高度重合。

方案	技术栈	适合场景	需要重点考虑的问题
C# 跨平台	C# + XAML	已有 C# 上位机、采集服务，团队熟悉 C#	需要学习 XAML 和 MVVM，包体相对较大
原生 Android + 原生 iOS	Kotlin + Swift	追求最强系统特性和极致性能	双端各写一套，维护成本高
Web / 混合方案	HTML / JS	展示型应用，不需要强后台能力	硬件访问受限，离线体验和推送较弱
Flutter	Dart	UI 要求高且统一	与 C# 服务端代码难以复用

C# 上位机开发中的委托、事件、Socket、串口通讯、字节解析经验，在移动端基本可以原样迁移。比如桌面端写过一个SerialPort.DataReceived事件处理程序，到了移动端只是把串口换成 TcpClient，处理逻辑依然是“收到字节 → 解析协议 → 触发事件 → 更新界面”。

需要特别明确一点：移动端不会直接去连接底层 PLC 或串口设备。跨平台移动系统对蓝牙、串口、USB 外设的支持差异很大，典型做法是让移动端连接一个服务层，服务层再去和设备通信。这样移动端协议栈保持稳定，服务层负责适配各种设备。

1.3 这篇文章的落点：一个可复现的最小闭环

为了让整个设计可学习、可复现，文章采用一个最小闭环作为主线：

模拟数据源(TcpListener) ↓ 以 \n 结尾的 JSON 帧 移动端 Socket 客户端 ↓ 事件 ViewModel ↓ 数据绑定 UI 实时展示

模拟数据源每 2 秒推送一条温度数据。移动端连接后持续接收，解析成数据点，刷新温度卡片。当温度超过阈值时，界面进入告警状态。整个过程覆盖连接、接收、解析、绑定、告警五个核心环节，也包含半包处理、跨线程更新、断线重连这些工业现场一定会遇到的问题。

2. 三层通信模型：把设备数据从现场送到手机屏幕

2.1 设备层、服务层、移动端各自负责什么

工业监控最怕“什么都想自己干”。如果移动端既要做协议解析，又要处理设备差异，还要保证多个厂家设备的兼容性，工作量会迅速失控。典型的设计是三层模型。

层级	职责	常见技术
设备层	PLC、传感器、仪表、扫码枪、相机，负责产生原始数据	Modbus TCP、FINS UDP、OPC UA、厂家 SDK
服务层	采集、缓存、协议转换、数据推送、鉴权控制	C# 上位机、边缘网关、MQTT Broker
移动端	实时展示、告警、查询、操作入口	Xamarin.Forms / .NET MAUI

服务层承担两个重要职责：一是把不同设备的协议统一成一种内部数据格式，二是把移动端与复杂的工业协议隔离。这样，设备换了协议，服务层做适配，移动端几乎不用改。

2.2 通信方式对比：TCP Socket、HTTP、WebSocket、MQTT

移动端与服务层之间的通信方式，直接影响实时性、弱网表现和开发复杂度。

方式	实时性	典型场景	注意事项
TCP Socket	高	局域网内专有协议采集，延迟低	需要自己处理粘包/半包、心跳、断线重连
HTTP 轮询	低到中	查询类接口，周期请求	实时性差，频繁请求浪费流量
WebSocket	高	双向高频推送，适合界面实时刷新	服务端需要支持 WebSocket
MQTT	高	弱网、多设备、需要离线消息	需要引入 Broker，设计主题和 QoS

这个 Demo 选择 TCP Socket，有两点考虑：

一是 TCP 最接近工业现场。很多 PLC 和采集网关都提供 TCP 服务，理解 TCP 的流式传输特性，是后面做任何工业通讯的基础。二是 TCP 能直观地把“字节流 → 帧 → 对象”的链路讲清楚，而这些知识在 Modbus、FINS 等协议里同样适用。

如果目标是弱网环境下的大规模设备接入，生产环境更推荐 MQTT。移动端订阅主题，设备数据由服务层发布，断线后可以保留消息，补收功能比裸 TCP 容易实现。

2.3 最小 Demo 的数据流设计

定义一个最简单的 JSON 帧，作为服务层与移动端的统一数据格式：

{"tag":"temperature","value":63.5,"time":"2025-01-01 10:22:33","alarm":false}

字段说明：

字段	含义	示例
tag	数据点位标识	temperature
value	数值	63.5
time	采集时间	2025-01-01 10:22:33
alarm	是否越限告警	false

帧与帧之间用换行符\n分隔。为什么用换行符？因为 JSON 本身包含{、"、:等字符，不能用这些字符作为边界，而换行符在 JSON 中可以通过转义避免冲突，适合学习阶段使用。生产环境更推荐“定长头部 + 长度字段 + 正文”的帧结构，容错性更强。

3. 环境准备与跨平台项目骨架搭建

3.1 IDE、SDK 和运行时要求

开始写代码前，先确认开发环境。不同框架版本对应的工具链差异较大，落地前要以自己机器的实际版本为准。

环境项	说明
Visual Studio	安装“使用 .NET 的移动开发”工作负载（Xamarin），或对应 .NET MAUI 工作负载
.NET SDK	根据项目目标框架安装，建议保持与模板一致
Android SDK / 模拟器	Android 开发和调试必需
Xcode（仅 iOS）	macOS 环境编译 iOS 包时需要
真机	Android / iOS 手机或平板，联调验证必备

学习环境的建议：优先使用 Android 模拟器跑通流程，成本最低。等到需要测试后台推送、电量消耗、网络切换时，再用真机验证。iOS 编译必须在 macOS 上完成，如果只有 Windows 机器，可以先把 Android 端跑通。

3.2 三个项目的划分

一个容易犯的错误是把所有代码都塞进移动 App 项目。更好的做法是拆分出共享核心库，让网络通讯、协议解析、数据模型独立于 UI。

IndustrialMonitor/ ├── DeviceSimulator/ │ ├── DeviceSimulator.csproj │ └── Program.cs ├── MobileApp/ │ ├── MobileApp.csproj │ └── Views/MainPage.xaml └── IndustrialMonitor.Core/ ├── IndustrialMonitor.Core.csproj ├── Networking/DeviceDataClient.cs ├── Protocols/DeviceDataPointParser.cs └── Models/DeviceDataPoint.cs

DeviceSimulator：模拟设备数据源，独立的控制台程序。
MobileApp：Xamarin.Forms 跨平台 UI 项目，负责页面和绑定。
IndustrialMonitor.Core：共享类库，存放网络客户端、协议解析和数据模型。

共享库的好处是，协议解析和网络客户端可以脱离 UI 单独测试。你可以在单元测试项目里直接构造一包数据，验证解析逻辑是否正确，而不需要启动手机。

3.3 权限配置：Android 网络权限与 iOS ATS

移动端访问局域网 TCP 服务，必须先配置网络权限，否则连接会静默失败。

Android 在AndroidManifest.xml中加入：

<uses-permission android:name="android.permission.INTERNET" />

如果是调试阶段访问局域网明文服务，还需要根据 Android 版本检查网络安全配置。从 Android 9 开始，默认禁止明文流量，开发阶段可以临时允许，生产环境必须基于 HTTPS 或 TLS 重新评估。

iOS 端需要关注 App Transport Security（ATS）。ATS 默认阻止不安全的 HTTP 连接。调试局域网 TCP 时，可以在Info.plist中做临时例外配置：

<key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <false/> <key>NSExceptionDomains</key> <dict> <key>192.168.1.0</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> </dict> </dict> </dict>

注意，这个配置只用于开发联调，不应直接搬到生产包。生产环境的域名、证书和网络策略要单独设计。

4. 先做一个模拟数据源，再写移动端通讯层

4.1 模拟设备数据源：TcpListener 定时推送

先写服务端模拟器。它的作用是：监听 9000 端口，每 2 秒向连接的客户端推送一条温度 JSON 帧。

using System.Net; using System.Net.Sockets; using System.Text; class DeviceSimulator { static async Task Main() { var listener = new TcpListener(IPAddress.Any, 9000); listener.Start(); Console.WriteLine("模拟设备数据源已启动，监听端口 9000"); while (true) { var client = await listener.AcceptTcpClientAsync(); Console.WriteLine($"客户端接入: {client.Client.RemoteEndPoint}"); _ = HandleClientAsync(client); } } static async Task HandleClientAsync(TcpClient client) { using (client) { var stream = client.GetStream(); while (client.Connected) { double value = Random.Shared.Next(20, 90); string frame = $"{{\"tag\":\"temperature\",\"value\":{value:F1},\"time\":\"{DateTime.Now:HH:mm:ss}\",\"alarm\":{value > 70}}}"; byte[] bytes = Encoding.UTF8.GetBytes(frame + "\n"); await stream.WriteAsync(bytes); await Task.Delay(2000); } } } }

关键点有三个：

使用AcceptTcpClientAsync接收客户端，每个客户端用独立任务处理，避免多个移动端接入时互相阻塞。
每条数据帧以\n结尾，模拟一个最简单的帧边界。
使用Encoding.UTF8编码文本。如果现场设备使用 ASCII 或 GBK，解析端要同步调整编码，否则中文和特殊字符会乱码。

运行这个控制台程序，看到模拟设备数据源已启动，监听端口 9000说明服务端就绪。

4.2 移动端 Socket 客户端封装

移动端通讯层的核心类DeviceDataClient负责三件事：建立连接、接收数据、上报状态。

public class DeviceDataClient { public event Action<string> DataReceived; public event Action<bool> ConnectionChanged; private readonly string _host; private readonly int _port; private TcpClient _client; public DeviceDataClient(string host, int port) { _host = host; _port = port; } public async Task ConnectAsync() { try { _client = new TcpClient(); await _client.ConnectAsync(_host, _port); ConnectionChanged?.Invoke(true); _ = ReceiveLoopAsync(_client); } catch (Exception ex) { Console.WriteLine($"连接失败: {ex.Message}"); ConnectionChanged?.Invoke(false); } } private async Task ReceiveLoopAsync(TcpClient client) { var buffer = new byte[4096]; try { var stream = client.GetStream(); while (client.Connected) { int read = await stream.ReadAsync(buffer, 0, buffer.Length); if (read <= 0) break; string chunk = Encoding.UTF8.GetString(buffer, 0, read); ProcessChunk(chunk); } } catch (Exception ex) { Console.WriteLine($"接收异常: {ex.Message}"); } finally { ConnectionChanged?.Invoke(false); } } private void ProcessChunk(string chunk) { // 半包/粘包处理，下一节实现 } }

这段代码体现了 C# 事件机制的主要用法：通讯线程只负责收发字节，不关心界面怎么展示。ViewModel 订阅DataReceived事件，收到数据后再决定如何更新 UI，这样通讯层可以独立测试，也方便日后替换成其他通信方式。

4.3 协议帧、byte[] 与结构体的关系

网络传输的底层是字节流，不是字符串。C# 里最直接的载体是byte[]。从TcpClient.GetStream().ReadAsync读到的数据，必须先转换成字符串，再解析成对象。

工业协议解析常用两种方式：

文本协议：每一帧是 ASCII 字符串，用分隔符或换行符切分，可读性好。
二进制协议：每一帧由定长头部和正文组成，比如 Modbus TCP 的 MBAP 头部，包含事务标识、协议标识、长度字段和单元标识。

二进制协议解析时，需要按偏移地址读取字节，并用BitConverter或BinaryPrimitives转换大小端。比如 Modbus 读取一个保持寄存器，返回的是两个字节，实际值可能是高位在前，也可能是低位在前，解析错误会导致数值完全不对。

帧经过解析后，存放在结构体或类中。这里定义一个数据点结构体：

public struct DeviceDataPoint { public string Tag { get; set; } public double Value { get; set; } public DateTime Time { get; set; } public bool Alarm { get; set; } }

对应解析函数：

public static DeviceDataPoint Parse(string line) { using var doc = System.Text.Json.JsonDocument.Parse(line); var root = doc.RootElement; return new DeviceDataPoint { Tag = root.GetProperty("tag").GetString(), Value = root.GetProperty("value").GetDouble(), Time = DateTime.Parse(root.GetProperty("time").GetString()), Alarm = root.GetProperty("alarm").GetBoolean() }; }

使用JsonDocument解析而不是直接反序列化成类，是为了减少反射开销。在移动端高频接收数据时，每帧只做一次解析，性能影响不大；但如果是几百个点位高频刷新，解析方式的差异就会明显体现出来。

4.4 半包/粘包问题要先解决，否则解析一定出错

TCP 是流式协议，没有天然的消息边界。一次WriteAsync发送的数据，可能被拆成多次ReadAsync接收，称为半包；也可能和下一帧数据连在一起到达，称为粘包。如果每次收到字节就直接JsonDocument.Parse，会出现偶发的解析异常。

正确的做法是引入缓冲区，把新数据追加到缓冲区，然后循环查找帧结束符，切出完整的一行再处理。

private readonly StringBuilder _buffer = new StringBuilder(); private void ProcessChunk(string chunk) { _buffer.Append(chunk); while (true) { int newlineIndex = _buffer.ToString().IndexOf('\n'); if (newlineIndex < 0) break; string line = _buffer.ToString(0, newlineIndex).Trim(); _buffer.Remove(0, newlineIndex + 1); if (line.Length > 0) { DataReceived?.Invoke(line); } } }

调用Trim是为了去掉可能残存的\r字符。在 Windows 上如果服务端发送\r\n，解析端只按\n切分，就会留下\r导致 JSON 解析失败。

注意：不要只在正常流程下测试解析逻辑。要专门构造“一帧大报文”“多帧连续发送”“半帧 + 半帧”三种情况，确认缓冲区切分逻辑是健壮的。

4.5 用委托和事件把数据从通讯线程推给 ViewModel

通讯层的事件已经定义好，接下来在 ViewModel 中订阅。这里会遇到 C# 工业开发中最常见的线程问题：网络线程是后台线程，UI 更新必须在主线程。

private void OnDataReceived(string line) { var point = DeviceDataPointParser.Parse(line); MainThread.BeginInvokeOnMainThread(() => { Temperature = $"{point.Value:F1} °C"; IsAlarm = point.Alarm; }); }

使用MainThread.BeginInvokeOnMainThread把 UI 更新操作切回主线程。如果不切换，Xamarin.Forms 在部分平台会抛出跨线程异常，另一些平台上则表现为界面不刷新，问题更难定位。

5. 用 MVVM 绑定实时数据，完成监控页面

5.1 ViewModel 基类与属性通知

MVVM 模式下，ViewModel 通过INotifyPropertyChanged通知界面属性变化。先定义一个基类：

public abstract class BindableBase : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; protected bool SetProperty<T>( ref T field, T value, [CallerMemberName] string propertyName = null) { if (EqualityComparer<T>.Default.Equals(field, value)) return false; field = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); return true; } }

SetProperty里先比较再赋值，可以避免每次收到数据都触发界面刷新。在温度值没有变化时，不重复刷新 UI，可以减少绘制开销。

5.2 MainViewModel 设计

监控页面只需要几个属性：温度、设备连接状态、告警状态、连接命令。

public class MainViewModel : BindableBase { private readonly string _host = "192.168.1.100"; private readonly int _port = 9000; private DeviceDataClient _client; private string _temperature = "--"; private string _deviceStatus = "未连接"; private bool _isAlarm; public string Temperature { get => _temperature; set => SetProperty(ref _temperature, value); } public string DeviceStatus { get => _deviceStatus; set => SetProperty(ref _deviceStatus, value); } public bool IsAlarm { get => _isAlarm; set { if (SetProperty(ref _isAlarm, value)) { OnPropertyChanged(nameof(StatusColor)); } } } public Color StatusColor => IsAlarm ? Color.FromArgb("#D32F2F") : Color.FromArgb("#388E3C"); public ICommand ConnectCommand => new Command(async () => await StartClientAsync()); private async Task StartClientAsync() { if (_client != null) return; _client = new DeviceDataClient(_host, _port); _client.DataReceived += OnDataReceived; _client.ConnectionChanged += OnConnectionChanged; await _client.ConnectAsync(); } private void OnDataReceived(string line) { var point = DeviceDataPointParser.Parse(line); MainThread.BeginInvokeOnMainThread(() => { Temperature = $"{point.Value:F1} °C"; IsAlarm = point.Alarm; DeviceStatus = point.Alarm ? "告警" : "已连接"; }); } private void OnConnectionChanged(bool connected) { MainThread.BeginInvokeOnMainThread(() => { DeviceStatus = connected ? "已连接" : "连接断开"; }); } }

这里要区分两件容易混淆的事：界面层检测变量变化，和业务层检测变量变化。

界面层检测变化，靠的是INotifyPropertyChanged。属性值变，界面跟着变。
业务层检测变化，靠的是数据到达后的阈值判断。告警逻辑不能在界面里做，应该放在服务端或 ViewModel 的数据处理里，这样即使 UI 没打开，告警规则依然生效。

在上面的代码里，模拟器已经在帧内写好了alarm字段，移动端只是读取并展示。实际项目中，告警阈值可能由服务端下发，移动端仍然只负责展示结果。

5.3 实时数据卡片与告警高亮

页面的 XAML 保持简洁：

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="MobileApp.Views.MainPage"> <ContentPage.Content> <StackLayout Padding="20" Spacing="20"> <Frame BorderColor="#CCCCCC" CornerRadius="8"> <StackLayout> <Label Text="当前温度" FontSize="14" TextColor="#666666"/> <Label Text="{Binding Temperature}" FontSize="40" TextColor="{Binding StatusColor}"/> </StackLayout> </Frame> <Label Text="{Binding DeviceStatus}" HorizontalOptions="Center" TextColor="#333333"/> <Button Text="连接服务" Command="{Binding ConnectCommand}" BackgroundColor="#1976D2" TextColor="White"/> </StackLayout> </ContentPage.Content> </ContentPage>

温度超过阈值时，StatusColor从绿色变成红色，用户一眼就能看到异常。在实际车间环境里，还可以把告警颜色和声音震动结合起来，但颜色的优先级是最高的，因为现场嘈杂时不一定能听到声音。

页面构造函数中需要设置绑定上下文：

public MainPage() { InitializeComponent(); BindingContext = new MainViewModel(); }

忘记设置BindingContext是新手最容易遇到的问题。设置了文本绑定但页面没有设置数据源，界面就会一直显示默认值。

6. 联调验证：抓包、日志和断点要配合使用

6.1 分步运行

联调按三个步骤走，每步确认无误后再进入下一步。

第一步，运行模拟数据源。确认控制台显示监听端口已启动。

第二步，启动 Android 模拟器或真机。注意到一个问题：模拟器里的127.0.0.1指向模拟器自身，不是开发机。要访问开发机上的模拟数据源，需要填局域网 IP，或者在 Android 模拟器上用10.0.2.2映射宿主机。

第三步，在 App 中点击“连接服务”。预期现象是模拟数据源控制台出现客户端接入，App 温度标签每 2 秒刷新一次。

6.2 用抓包工具确认通信内容

当程序不能正常工作，而且日志没有明显线索时，要使用抓包工具确认网络层发生了什么。

抓包的重点看三件事：

TCP 三次握手是否完成。
数据帧是否完整到达。
连接是否被异常重置。

在开发机上用 Wireshark 抓包时，过滤条件可以写tcp.port == 9000。如果能看到稳定的数据包流量，说明服务端发送正常；如果客户端连不上，要查看是否存在 TCP SYN 重传，或端口被防火墙拦截。

抓包工具在生产现场可能受到网络权限限制。更通用的做法是在通讯层打结构化日志，输出连接成功、数据帧原文、异常堆栈。至少保证日志里有时间和关键字，否则排查排错时无从下手。

6.3 预期运行结果与异常现象

检查点	预期	异常形态
模拟数据源控制台	每 2 秒输出一条温度帧	无输出、端口冲突、进程被占用
App 连接状态	变为“已连接”	一直“未连接”，或点击后无反应
温度标签	按 2 秒周期刷新	数值不变、偶尔跳变、显示异常值
告警状态	温度大于 70 时显示告警色	阈值判断不生效，或颜色刷新延迟

有一点需要反复强调：联调时不要只看“程序没有崩溃”，还要验证数据的输入、输出、异常分支和日志是否符合预期。比如把温度调到超过阈值，确认告警状态切换了；把服务端停掉，确认 App 能感知断开并进入重连逻辑。

7. 工业现场常见问题与排查路径

7.1 连接失败：权限、IP、端口和防火墙

现象：点击“连接服务”后，设备状态一直停留在“未连接”。

排查按以下顺序进行：

确认模拟数据源已经启动，并且监听的端口是 9000。
确认手机和开发机在同一个局域网网段。
确认代码里填的不是127.0.0.1。移动端连接的是远端电脑，不是本机。
检查 Android 的INTERNET权限是否已在 Manifest 中声明。
检查开发机防火墙是否放行 9000 端口。
用抓包工具确认 TCP SYN 报文是否发出、是否有响应。

常见原因是防火墙拦截。Windows 上第一次运行 TcpListener 时，系统会弹出防火墙授权窗口，如果点了取消，后续连接就会被静默丢弃。

注意：生产环境的连接问题要区分两种场景：一种是网络根本不通，另一种是服务进程已经异常退出。前者抓包能看出来，后者要看进程状态和日志。

7.2 半包/粘包导致 JSON 解析失败

现象：程序偶尔抛出JsonException，或者有两条数据连在一起显示。

原因：TCP 是流式协议，没有消息边界。直接对ReadAsync读到的字符串做JsonDocument.Parse，迟早会遇到半包或粘包。

解决方案：维护StringBuilder缓冲区，先追加再按换行符切分。具体代码参考 4.4 节。

预防建议：

不要只用“每 2 秒一条数据”的频率测试。
构造一帧很大的报文，再构造多条小报文连续发送。
如果协议允许，使用“头部长度字段 + 正文”的结构，比分隔符更可靠。

7.3 UI 不刷新与跨线程更新

现象：模拟数据源正常输出，但界面温度一直不变。

排查路径：

在OnDataReceived里加断点，确认事件有没有触发。
确认BindingContext是否绑定了 MainViewModel。
确认更新属性时是否切到了主线程。
检查绑定路径是否写错，比如 XAML 里写成了{Binding Temperature}，但 ViewModel 属性名是CurrentTemperature。

很多情况下，问题不是出在 UI 框架，而是事件根本没有被订阅，或者属性名不一致。先加日志确认事件链路，再怀疑 UI 框架。

7.4 断线重连、内存增长与后台限制

现象：现场网络波动后 App 无法恢复；长时间运行后出现卡顿。

原因主要有四类：

ReceiveLoopAsync异常退出后，没有触发有效的重连机制。
DataReceived事件被多次订阅，导致同一个数据帧被处理多次。
缓冲区无限增长，长时间运行后内存升高。
Android 和 iOS 对后台 Socket 连接有限制，锁屏或切后台后连接可能被系统回收。

处理方式：

用CancellationToken控制重连循环，设置最大重试次数。
在页面销毁时取消事件订阅，避免重复订阅。
给缓冲区设置最大长度，超过阈值清理或断开。
生产环境考虑前台服务或系统推送能力，但要在了解各平台规则后再设计。

7.5 排查顺序与速查表

工业现场排查问题，建议按“输入 → 路径 → 配置 → 日志 → 工具”的顺序推进：

现象	优先检查	次要检查	处理建议
连接失败	服务进程、网络连通性	权限、防火墙、IP 端口	用 telnet 或 nc 测试端口
解析失败	日志原文、帧边界	编码、大小端	按帧切分，补全半包处理
UI 不刷新	事件是否触发	BindingContext、主线程	加调试日志，确认链路
经常断开	网络稳定性	心跳、后台限制	增加心跳，限制重连频率
内存增长	事件订阅次数	缓冲区清理	检查订阅生命周期，设置缓冲上限

这些条目应该作为开发完成前的自测清单，而不是出了问题再临时翻。

8. 从 Demo 到生产环境：工程化扩展与实践清单

8.1 安全基线：连接凭证与数据保护

Demo 里 IP 和端口直接写在代码中，这种方法只适合学习。生产环境必须解决三个安全问题：

不硬编码连接凭证。IP、端口、账号、密码应从配置中心或环境变量读取。
传输层加密。局域网可以选 TLS，公网必须使用证书验证。
控制指令必须鉴权。移动端触发设备启动、停止等操作时，服务端要校验用户身份和权限，并记录审计日志。

日志中不要打印密码、Token 和完整报文。工业现场数据可能是商业机密，日志脱敏应该作为代码审查的一项基本要求。

8.2 协议升级方向：WebSocket 和 MQTT

当系统从单机 Demo 发展到多车间、多设备时，裸 TCP 的维护成本会上升。核心问题是缺少统一的心跳、订阅、离线消息和权限控制。

推荐按以下方向演进：

WebSocket：当页面需要双向高频交互，且服务端已经是 HTTP 服务时，优先选择。
MQTT：当设备数量多、网络弱、需要离线消息时，MQTT 提供现成的主题订阅和 QoS 机制。
OPC UA：当设备层需要标准化建模时，服务层接入 OPC UA，移动端仍通过 WebSocket 或 MQTT 获取数据。

移动端协议栈保持稳定，升级发生在服务层。这是本文设计的核心原则之一。

8.3 设备接入扩展：PLC、扫码枪、相机 SDK 的接入思路

C# 上位机开发中，常见的设备接入包括 Modbus TCP、FINS UDP、串口扫码枪、工业相机 SDK 等。这些设备协议完全不一样，但接入思路是统一的：设备差异收敛在服务层，对外输出统一数据格式。

设备类型	常见协议	服务层处理方式	移动端关注点
PLC	Modbus TCP、FINS UDP	轮询或订阅采集，转换为统一 JSON 帧	点位标识、单位、告警阈值
扫码枪	串口、USB HID、网络	监听触发事件，输出条码数据	条码与工单、物料关联
工业相机	厂家 SDK	图像采集、视觉识别结果回调	展示结果和图片，确认状态

具体到移动端，不建议直接在 App 中集成相机 SDK 或串口扫码枪驱动，原因是平台兼容性差、设备供应商 SDK 更新频繁。正确做法是让服务层完成驱动和采集，移动端只接收已经加工好的结果。

8.4 从 Demo 到生产的可复用检查清单

发布到生产环境前，把下面这张清单逐项过一遍：

检查项	是否完成	说明
协议设计	有帧边界、超时、心跳、重连策略	不能用 Demo 里的换行符直接上生产
网络容错	连接超时、断线重连、缓冲区上限	防止异常网络拖垮 App
数据正确性	大小端、编码、单位、精度已验证	数值错误比界面卡顿更危险
界面刷新	MVVM 绑定正确，UI 更新在主线程	杜绝跨线程异常
安全配置	凭证不硬编码、传输加密、控制鉴权	生产环境必须覆盖
日志	连接、数据、异常、操作都有日志	日志要有时间戳和事件类型
监控	内存、CPU、连接数、后台状态	长时间运行不能内存上涨
回滚	配置化发布，支持版本回退	避免一次故障导致整个系统不可用

把这条清单保存下来，每个项目发布前都对照检查一遍，可以帮助你降低把 Demo 直接搬到生产环境的风险。

移动跨平台工业监控应用的核心并不是把界面搬到手机上，而是让数据链路稳定、可观测、可恢复。这个设计里最值得记住的判断是：先把协议、连接和解析做对，再谈界面和扩展。如果你的项目也要接入 PLC、扫码枪或相机，可以在服务层把这些设备统一转换成一种内部协议，移动端只面向这一种内部协议开发。下一步建议做三件事：给通讯层补上心跳和自动重连，把可变的 IP 和阈值从配置读取，再为协议解析写几个单元测试。这样，一个 Demo 就能逐步长成一个可以运维的工业监控应用。