.NET MAUI与YOLO跨平台目标检测实践：一套代码搞定工业上位机

近两年做工业视觉项目，我一直在找一个能统一Windows工控机和移动端巡检设备的方案。以前要么在PC上用WPF写死一套上位机，要么在Android上单独开发一个App，两套代码完全割裂，升级和联调都要维护两份。后来把.NET MAUI和YOLO（You Only Look Once）深度学习模型结合起来做了一套跨端目标检测上位机，Windows、Android、macOS一套代码跑通，实时检测、分类、可视化都在一个框架里完成，工业质检、安防巡检、移动溯源这三个场景我都实际跑过，这篇文章就把整个落地过程、技术选型逻辑和踩过的坑一次说清楚。

1. 为什么把YOLO和MAUI组合在一起：先理解这套方案解决的真实问题

1.1 标题背后的场景痛点：一张上位机要覆盖多个环境

先说工业质检。产线上的上位机一般是Windows工控机，挂着工业相机，检测产品缺陷。这种场景对帧率要求不一定极高，但要求视觉结果稳定、可视化界面能随时给操作员反馈。另一边的安防巡检和移动溯源，巡检员手里拿的是Android平板或者手机，需要在户外、车间里走动，对着设备扫码或拍照片，实时调用模型做检测。问题来了：团队只有一个，WinForms、WPF、安卓原生各写一版，训练好的YOLO模型在每个平台上都要单独接入一次，检测逻辑、界面逻辑分叉越来越大。

.NET MAUI解决的是“跨端UI”这一层，YOLO解决的是“跨平台推理”这一层，组合起来就是一个统一的跨端视觉检测平台。MAUI项目里，业务逻辑用C#写一遍，UI层用XAML写一遍，发布目标直接选Windows和Android，代码复用率能做到90%以上。YOLO模型统一导出成ONNX格式，通过ONNX Runtime在各个端上加载推理，模型只要训练一次，部署到任何平台都不需要重写推理逻辑。

拿移动溯源来说，用户拿着手机对着产品批次号、条码区域或者外观特征拍照，界面上要实时框出目标并显示分类和置信度。这个场景在PC上做出来没什么难度，但放到Android低端平板上，既要保证30帧左右的流畅度，又要让界面布局在横竖屏切换时不乱，靠两套代码来回同步，迭代一次要出双倍工作量。MAUI加YOLO这个组合，本质上就是把“视觉能力”和“界面能力”做成一套可复制的底座，剩下的就是按场景填业务逻辑。

1.2 MAUI与YOLO的互补关系：UI框架与推理引擎的职责边界

.NET MAUI是一个UI框架，它本身不负责模型推理，也不负责图像处理，它的职责是提供跨端的页面、布局、生命周期管理和平台能力调用。YOLO是一个目标检测算法系列，训练好的权重文件通过ONNX或TensorFlow Lite等格式导出，在运行时由推理引擎加载执行。这两者之间的桥接，就是C#里调用ONNX Runtime的Native API。

我在项目里把整个架构分成三层：

• 采集层：负责从摄像头、文件、网络流获取图像帧，统一封装成IFrameSource接口。Windows上用MediaCapture，Android上用CameraView或者自采集SurfaceTexture，这一层对上层隐藏平台差异。
• 推理层：负责加载ONNX模型，执行预处理、推理、后处理，输出检测框、类别、置信度。这一层完全跨平台复用，不依赖MAUI的UI组件。
• 展示层：MAUI的XAML页面，负责把推理结果叠加到图像上，显示实时帧率、设备状态、检测统计。

这个分工的好处是，YOLO版本更新了，只需要替换导出模型和推理层的解析逻辑，UI层和采集层基本不动；反过来，UI要改版，推理层完全不受影响。我实际迭代中，YOLOv5换到YOLOv8，只改了一个后处理解析类，页面代码一行没动。

1.3 技术可行性的核心判断：推理延迟和内存占用能不能接受

做这套方案之前，最大的顾虑是在移动端跑YOLO会不会卡顿。我拿YOLOv8n在几台设备上做了基准测试，输入尺寸640x640，FP32模式下Android端CPU推理大概80毫秒到120毫秒，加上前后处理，单帧总耗时150毫秒左右。对于安防巡检这种场景，2到3帧每秒已经够用。如果换INT8量化模型，推理可以压到40毫秒内，实时性明显提升。

Windows端性能要好很多，桌面级CPU跑FP32大概30毫秒，带独显机器通过CUDA后端可以到10毫秒以下。因为ONNX Runtime提供了多套Execution Provider，代码里只需要初始化时传入不同的Provider配置，Windows上可以用CUDA或DirectML，Android上可以用NNAPI，同一套C#代码拿到了不同端的性能红利。这套方案的可行性结论是：选对模型尺寸和量化策略，MAUI加YOLO在移动端完全跑得动，且能做到可用的实时帧率。

2. 技术选型不纠结：跑YOLO的三种路线和我的最终取舍

2.1 三条路线的横向对比：ONNX Runtime、TensorFlow Lite与ML.NET

在C#生态里做YOLO推理，不是只有一条路。我对比过三种常见方案，各有各的适用场景：

ML.NET虽然封装得友好，但它在Android和iOS上的支持并不完善，跨端的目标检测上位机不太合适。TensorFlow Lite在Android上性能确实不错，尤其是TFLite的Delegate加速做得很成熟，但它在Windows和macOS上几乎没法直接复用同一套代码，需要为桌面端单独接TensorFlow或ONNX，等于又回到双端维护的老路。ONNX Runtime是唯一一个我从头到尾只写一套封装，就能覆盖Windows和Android两个目标平台的方案。

2.2 为什么最终选定ONNX Runtime作为统一推理引擎

ONNX Runtime最打动我的点是它的Execution Provider机制。同一个模型文件，在Windows上挂CUDAExecutionProvider或DirectMLExecutionProvider，在Android上挂NNAPIExecutionProvider，实在不支持就自动回退到CPU。这种分层策略让我的代码里不用写平台分支判断，只需要在初始化时传入一个Provider列表，运行时它会按顺序尝试。

var sessionOptions = new SessionOptions(); sessionOptions.AppendExecutionProvider_DML(); // Windows DirectML加速 sessionOptions.AppendExecutionProvider_CPU(); // 回退CPU var session = new InferenceSession(modelPath, sessionOptions);

上面的代码在Windows上会优先使用DirectML，如果没有支持的GPU就自动落到CPU。Android端对应的是AppendExecutionProvider_NNAPI()，同样不会因为设备不支持而崩溃。这种容错设计对工控现场特别重要，现场设备的硬件水平参差不齐，最怕的就是代码在一台机器上能跑，换一台就报错。

ONNX Runtime的C# API也很干净。输入输出张量的读取方式设计得直观，配合DenseTensor或者直接使用数组，可以避免频繁的数据拷贝。我在Android机器上实测，640x640x3的输入张量，从图像预处理到送入推理会话，耗时在5到10毫秒之间，这个开销完全可接受。

提示：ONNX Runtime NuGet包分多个平台，MAUI项目里全部选上需要的Runtime包即可。注意OnnxRuntime.Maui这个包已停更，直接用官方Microsoft.ML.OnnxRuntime加不同平台的Runtime包组合更稳。

2.3 模型导出与YOLO版本选择：训练环境与部署格式的衔接

YOLO选型要综合考虑精度和端侧性能。在我做的几个项目里，YOLOv8n的体量(约6MB权重)最适合移动端，mAP相比v5s提升明显，但推理时间几乎持平。YOLOv11n目前也发布了，精度更高一些，但生态和踩坑资料还少一点，工业项目我倾向于先选验证充分的版本，追求新版本可以放在预研阶段。

导出ONNX格式的关键命令也很直接，ultralytics的Python环境里一条命令搞定：

yolo export model=yolov8n.pt format=onnx opset=12 simplify=True

设置opset=12是兼容性的关键，太高版本会让老设备上的ONNX Runtime出现算子不支持的问题。simplify=True会做计算图精简，Android上的加载速度和内存占用都能改善。导出后建议用onnxruntime的Python接口做一次精度验证，确认输出和PyTorch原始模型的检测结果一致，再集成到MAUI工程里。

3. 集成过程中的四段关键逻辑：预处理、推理、输出解析、后处理

3.1 图像预处理：Letterbox填充与归一化的细节

YOLO模型的输入图片一般要求正方形，并且像素值归一化到0-1之间。把摄像头来的任意宽高比帧直接拉伸到640x640会让目标变形，检测精度直线下降。正确做法是Letterbox，即等比缩放图片并用灰色填充边缘到目标尺寸。我封装了一个预处理方法：

public static Tensor<float> Preprocess(byte[] sourceImage, int inputWidth, int inputHeight) { // 解码 var bitmap = ImageDecoder.Decode(sourceImage); // 平台实现 int originalWidth = bitmap.Width; int originalHeight = bitmap.Height; // 计算等比缩放比例，取较小值保证整个画面被包含 float ratio = Math.Min((float)inputWidth / originalWidth, (float)inputHeight / originalHeight); int newWidth = (int)(originalWidth * ratio); int newHeight = (int)(originalHeight * ratio); // 计算填充偏移量 int dx = (inputWidth - newWidth) / 2; int dy = (inputHeight - newHeight) / 2; var data = new float[3 * inputWidth * inputHeight]; for (int y = 0; y < inputHeight; y++) { for (int x = 0; x < inputWidth; x++) { int srcX = (int)((x - dx) / ratio); int srcY = (int)((y - dy) / ratio); // 填充区域使用灰色128，归一化后约0.5 float r = 128f, g = 128f, b = 128f; if (srcX >= 0 && srcX < originalWidth && srcY >= 0 && srcY < originalHeight) { var pixel = bitmap.GetPixel(srcX, srcY); b = pixel.B; g = pixel.G; r = pixel.R; } int channelOffset = y * inputWidth + x; data[channelOffset] = r / 255f; data[inputWidth * inputHeight + channelOffset] = g / 255f; data[2 * inputWidth * inputHeight + channelOffset] = b / 255f; } } return new DenseTensor<float>(data, new[] { 1, 3, inputHeight, inputWidth }); }

这里有个工程细节：直接调用GetPixel在Android上性能很糟糕，每像素一次JNI调用会让预处理慢得没法用。所以实际项目里我会用平台SDK的批量像素读取，比如Android的lockCanvas或者CopyPixelsFromBuffer，拿到RGB数组后，整个循环就变成纯内存操作，几百毫秒降到20毫秒以内。

3.2 ONNX Runtime推理：会话初始化和输入输出的C#接入

推理层在MAUI里保持一个单例服务类，所有检测共用同一个InferenceSession实例，避免反复初始化模型。模型加载放在App启动后的异步后台线程中，防止阻塞UI。

public class YoloDetector : IYoloDetector, IDisposable { private InferenceSession _session; private string[] _labels; private int _inputWidth; private int _inputHeight; public event Action<DetectionResult[]> OnDetected; public YoloDetector(string modelPath, string[] labels) { _labels = labels; _session = new InferenceSession(modelPath, new SessionOptions { GraphOptimizationLevel = GraphOptimizationLevel.ORT_ENABLE_ALL }); var inputDim = _session.InputMetadata[0].Dimensions; _inputHeight = inputDim[2]; _inputWidth = inputDim[3]; } public DetectionResult[] Detect(Tensor<float> inputTensor) { var inputs = new List<NamedOnnxValue> { NamedOnnxValue.CreateFromTensor(_session.InputMetadata.Keys.First(), inputTensor) }; using var results = _session.Run(inputs); // 输出解析在这里完成，详见3.3 return ParseOutput(results); } }

注意GraphOptimizationLevel我直接开到了ORT_ENABLE_ALL，ONNX Runtime会做常量折叠、算子融合等优化，实测可以在不改变模型精度的情况下带来10%到20%的推理加速。这个设置在Android和Windows上都安全，不用担心兼容性。

3.3 YOLO输出解析：Tuple输出与Tensor输出的兼容处理

YOLOv5和YOLOv8的输出格式不一样，这是最容易踩坑的地方。YOLOv5的输出是三个不同尺度特征图组成的集合，每个特征图的形状是[1, 3, gridH, gridW, 5+numClasses]，其中3是三个anchor，5是中心坐标、宽高和对象置信度，后面跟着类别得分。YOLOv8把anchor-free和自适应的置信度逻辑合并了，输出只用一个[1, 84, 8400]张量，84对应4个框坐标加80个类别得分，8400是三个尺度总共的候选框数量。

在C#里处理这两种输出，我会定义一个中间结构，统一转换后再做后处理:

public class RawDetection { public float X, Y, Width, Height; // 中心点坐标或左上角坐标，根据版本 public float Confidence; public int ClassId; } private List<RawDetection> ParseYolov5Output(IReadOnlyList<NamedOnnxValue> outputs) { var raw = new List<RawDetection>(); foreach (var output in outputs) { var tensor = output.AsTensor<float>(); var shape = tensor.Dimensions.ToArray(); // shape形如 [1, 3, gridH, gridW, 85] int numAnchors = 3, gridH = shape[2], gridW = shape[3], boxAttrs = (int)shape[4]; for (int a = 0; a < numAnchors; a++) { for (int gy = 0; gy < gridH; gy++) { for (int gx = 0; gx < gridW; gx++) { int offset = a * gridH * gridW * boxAttrs + gy * gridW * boxAttrs + gx * boxAttrs; float objConf = tensor[offset + 4]; if (objConf < 0.25f) continue; // 类别置信度取最大 float bestScore = 0; int bestClass = 0; for (int c = 5; c < boxAttrs; c++) { if (tensor[offset + c] > bestScore) { bestScore = tensor[offset + c]; bestClass = c - 5; } } float score = objConf * bestScore; if (score < 0.45f) continue; raw.Add(new RawDetection { X = (tensor[offset] + gx) / gridW, Y = (tensor[offset + 1] + gy) / gridH, Width = tensor[offset + 2], Height = tensor[offset + 3], Confidence = score, ClassId = bestClass }); } } } } return raw; }

YOLOv8的解析就简单很多，直接把8400个候选框全部遍历，读取坐标和分类得分就行。我建议把这两种解析写成独立的策略类，通过模型导出时烧录的元数据来决定走哪条路径，而不是在代码里硬编码版本号。

3.4 后处理：置信度过滤与NMS的工程实现

YOLO原始输出会有一大堆重叠的候选框，必须做非极大值抑制(NMS)才能得到干净的检测结果。NMS的原理是：先按置信度排序，选最高分的框，删掉所有和它IoU(交并比)超过阈值的重叠框，再重复这个过程。工业场景里漏检比重叠框烦人，所以我IoU阈值一般设在0.5到0.6之间，宁可多保留几个轻微重叠的框，也不要漏掉靠近的物体。

C#实现一份高效NMS并不复杂，关键是避免O(n²)的暴力计算导致卡顿。考虑到YOLOv8n的候选框最多8400个，我做了两个优化：第一，提前按置信度阈值过滤掉大量低分框；第二，排序后只用两层循环，且用HashSet跳过已经保留的候选框下标。实测在Android上处理2800个候选框，整个后处理在3毫秒左右完成。

public static List<DetectionResult> Nms(List<RawDetection> rawDetections, float iouThreshold) { var ordered = rawDetections.OrderByDescending(r => r.Confidence).ToList(); var pickedIndices = new HashSet<int>(); var results = new List<DetectionResult>(); for (int i = 0; i < ordered.Count; i++) { if (pickedIndices.Contains(i)) continue; var candidate = ordered[i]; bool suppressed = false; for (int j = 0; j < ordered.Count; j++) { if (j == i || pickedIndices.Contains(j)) continue; var other = ordered[j]; float iou = ComputeIoU(candidate, other); if (iou > iouThreshold) { suppressed = true; break; } } if (!suppressed) { pickedIndices.Add(i); results.Add(new DetectionResult { BoundingBox = NormalizeBox(candidate), Confidence = candidate.Confidence, ClassId = candidate.ClassId }); } } return results; }

把后处理结束后得到的检测框再按之前Letterbox的ratio和dx、dy映射到原始图像坐标，就能正确地画到界面上。这里有一个很容易忽略的细节：缩放映射时一定要用Letterbox的同一套参数，顺序也要一致，我早期就因为在UI叠加时忘了减填充偏移，画出来的框整体往右下偏了十几像素。

4. 跨端实时视频流与可视化：上位机最接近业务的部分

4.1 摄像头帧源的抽象设计：一套代码采集多端视频

目标检测上位机不只是处理单张图片，绝大多数场景要接实时摄像头流。MAUI里不同平台的摄像头接入方式差异很大，Windows可以用MediaCapture配合SoftwareBitmap，Android则要么用CameraView控件，要么自己处理SurfaceTexture。如果直接把这些逻辑写在页面里，跨端复用就废了。

我的做法是定义IFrameSource接口，页面只依赖它：

public interface IFrameSource { event EventHandler<FrameReadyEventArgs> FrameReady; Task StartAsync(); Task StopAsync(); int FrameWidth { get; } int FrameHeight { get; } }

Windows上用MediaCapture实现一个WindowsCameraFrameSource，Android上用CameraX的ImageAnalysis分析器实现一个AndroidCameraFrameSource。页面里在OnAppearing时调用StartAsync，拿到FrameReady事件里的像素数据就扔给检测服务，UI完全不管摄像头是哪来的。

这样设计后，我在调试阶段还可以写一个FileListFrameSource，直接循环读取文件夹里预先保存的测试图片，模拟摄像头逐帧输出。后端逻辑完全不用区分是真实摄像头还是模拟源，开发和现场联调效率高了很多。

4.2 实时性与功耗的平衡：帧率控制和丢帧逻辑

移动端做实时检测，最忌讳的是每个摄像头帧都送去推理。如果输入帧率是30fps，CPU推理只有10fps，队列里就会堆积帧，延迟越来越大，最后画面和检测结果严重不同步。正确做法是做一个简单的丢失帧机制：每次取最新一帧，丢弃中间积压的旧帧。

我在检测服务内部维护一个Channel<byte[]>，生产端(摄像头)往里面写入最新的图像数据，消费端(推理线程)每次读的时候直接TryRead到只剩最新一个元素。这样即使推理速度跟不上，延迟永远稳定在一帧以内，不会无限堆积。对于工业质检这种实时性要求高的场景，我会分析仪延迟优先策略，宁可偶尔丢帧也要保证框和画面的对齐关系准确。

同时，移动端还应该根据电量或工作模式动态调节推理频率。我做了一个简单的分级：巡检模式下每2帧推理一次，省电模式下每4帧推理一次，并默认在界面上显示当前帧率，方便操作员了解设备状态。

4.3 可视化层的双缓存策略：避免交叉线程UI操作崩溃

MAUI里图像帧和推理结果都要展示到界面上，直接在推理子线程里操作Image控件会导致跨线程调用异常。我的处理是采用双缓存：推理线程把结果写入一个DetectionFrame对象，通过MainThread.BeginInvokeOnMainThread通知UI线程统一刷新。

private async void OnFrameReady(FrameReadyEventArgs e) { var tensor = Preprocess(e.FrameData); var rawDetections = _detector.Detect(tensor); var results = Nms(rawDetections, 0.5f); var snapshot = new DetectionFrameSnapshot { ImageBytes = e.FrameData, Result = results }; MainThread.BeginInvokeOnMainThread(() => { _imageView.IsVisible = true; _imageView.Source = ImageSource.FromStream(() => new MemoryStream(snapshot.ImageBytes)); _canvasView.Invalidate(); // 触发Drawable重绘 }); }

这里要注意：ImageSource.FromStream里的流不能事先释放，否则图像加载不出来，我会用MemoryStream并让UI控件在加载完成后自行释放。叠加检测框我用了GraphicsView的IDrawable接口，在Draw方法里读取最新的检测结果画矩形和标签，这样避免每帧重新生成位图再叠加文字，内存开销小很多。

5. 性能优化、打包部署与实战踩坑记录

5.1 性能优化三板斧：硬件加速、输入尺寸、线程模型

第一板斧是正确使用Execution Provider。Windows工控机如果带NVIDIA显卡，用CUDAExecutionProvider能拿最大的提升；如果不确定目标机器的显卡品牌，用DirectMLExecutionProvider更稳妥，它在AMD和Intel核显上也能工作，不需要装CUDA运行时。

第二板斧是合理选择输入尺寸。YOLOv8n官方支持320、416、640等尺寸，每降低一倍分辨率，推理耗时大概降低三倍。工业质检中如果检测目标较大，320输入完全够用；安防巡检要兼顾小目标召回，就保400或640。我用640输入在Android低端机上跑出接近3fps，换成416后直接到8fps，漏检率没有明显上升，这就是取舍。

第三板斧是优化线程模型。我在预处理、推理、后处理之间使用了异步流水线，每个阶段一个线程，通过Channel衔接。Windows上线程池调度的效率没有问题，Android上则需要把耗时操作限制在少量线程里，避免频繁创建和销毁。实测这个流水线架构在Android上把整体帧延迟从210ms压到了130ms左右，很大一块优化来自并行化而不是引擎本身。

5.2 平台打包时最容易出的问题：Linker裁剪和权限声明

MAUI项目发布到Android和Windows时，有几个坑几乎必踩。第一个是Linker裁剪掉ONNX Runtime的Native库引用，导致运行时找不到DLL或so文件。解决方式是在MAUI项目文件里把ONNX Runtime相关程序集加入TrimmerRootAssembly：

<ItemGroup> <TrimmerRootAssembly Include="Microsoft.ML.OnnxRuntime" /> <TrimmerRootAssembly Include="Microsoft.ML.OnnxRuntime.Managed" /> </ItemGroup>

第二个是Android的Release包默认不包含调试符号，如果代码里依赖InteropServices调用Native代码，建议在Android项目里打开AndroidUseSharedRuntime=false并手动检查so文件是否打进包内。用解压工具看一下APK里的lib/arm64-v8a目录，确认存在onnxruntime.so。

第三个是权限声明。摄像头权限在MAUI的AndroidManifest里要显式配置，CAMERA权限还必须在运行时请求。我在MainPage的OnAppearing里写了一个简单请求封装，避免因为忘记申请权限导致黑屏。

5.3 从Demo到产品：模型迭代、日志与现场校准建议

我强烈建议在把YOLO模型集成进MAUI后，保留一个--model-info调试模式，输出模型的输入尺寸、输出形状、各类别数量，以及每帧各个阶段的耗时统计。这个功能在换模型、换现场设备时能节约大量排查时间，不要等到上线了再追加。

工业场景中还可能遇到光照变化、遮挡、相似背景干扰，这会导致模型在现场的召回率不如测试集。我的做法是：上线前用现场采集的截图批量回放测试，把误检和漏检的图片导出来，带标注再回到训练环境做增量训练。YOLO的增量训练成本很低，迭代一到两轮，现场表现就能明显改善。

另外，不同批次的产品外观差异可能很大，为了不让质检标准忽高忽低，我会在检测结果里加一个“连续帧投票”机制：同一目标连续N帧被检测到且类别一致，才判定为最终结果。这在移动溯源场景中特别好用，能过滤掉因手抖或反光造成的偶发性误检。

6. 一次完整的现场排查案例：从图像发虚到发现预处理Bug

6.1 现象：Android真机检测框偏移，Windows正常

我在某个项目的联调阶段遇到一个怪问题：同样的模型，Windows上检测框精准贴合目标，Android平板上所有框整体向右下方偏移，偏移量还随目标距离变化。第一反应是模型的输入预处理没对齐，但我反复确认了Letterbox参数在跨端代码里是完全一致的，这就很奇怪。

我习惯的做法是先打印每个阶段的中间结果对比两端差异。在Windows端加日志，Android端加日志，分别输出原始图像尺寸、缩放比例、填充偏移量，结果发现两组数据几乎一致。那问题就不在预处理，而可能在目标检测结果映射回原图坐标时的代码路径上。

6.2 定位过程：逐段对比发现平台位图解码的方向差异

最终定位到的是一个非常隐蔽的问题：Android上将位图转RGB数组时，即使使用CopyPixelsFromBuffer，像素行的排列顺序在不同厂商的ROM上也有差异。部分设备返回的是带上下翻转的RGA排列，或者RGB通道顺序不同，导致坐标错位和颜色失真恰好表现为检测框偏移。

修复方式是把平台相关的像素缓冲统一转换到一个标准RGB数组，并额外加一个单元测试，读入一张带固定色块的测试图，校验缓冲转换是否正确。从那以后，我把“像素缓冲层与平台SDK解耦”写进了项目规范，任何新增平台支持必须先在本地跑一遍色块校验再接入推理管线。

6.3 教训总结：跨端项目最先出问题的往往是数据格式不是模型

这个案例给了我一个很重要的经验：MAUI加YOLO这套组合，模型推理本身高度跨平台，但图像从摄像头到模型输入端这段数据链路上，每个平台都可能存在像素格式、通道顺序、行列方向上的微小差异。这些差异在桌面端几乎不会暴露，因为桌面端SDK行为高度标准化，但在Android碎片化环境中非常普遍。

应对方式就是建立从采集到推理到显示全链路的自动化校验。我后来写了一个测试页，预置20张带标准框标注的图片，在每次版本发布前自动跑一轮完整前向流程，检查检测框与人工标注的IoU是否达标。这个校验步骤看起来多此一举，但它在多款真机上帮我提前抓出过至少三次类似的平台差异Bug。

7. 后续可以扩展的方向：模型版本管理、多模型切换与边缘部署

7.1 模型版本管理与热更新

项目跑起来之后，最常被问到的就是模型怎么升级。产品迭代期间，模型权重可能每周都要更新一次，如果每次都要重新发包，不仅流程长，还容易出版本混乱的问题。我建议把ONNX模型文件放到一个可以由服务端下发的位置，App启动时检查模型版本，有新版本则下载到应用沙盒目录再动态加载。

ONNX Runtime的InferenceSession支持从字节流加载模型，这为热更新提供了很大的便利。实现上只需要把模型文件读进MemoryStream，再传给SessionOptions的配置，即可在不重启App的情况下切换新模型。为防止新模型现场表现不佳，我保留一个回滚按钮，可以在诊断页一键切换回上一个模型版本。

7.2 多模型组合与自动场景识别

工业现场有时候一个模型不够用，比如安防巡检要同时检测人员、安全帽、设备状态，质检又要看产品外观缺陷。单个YOLO模型可以训练多类目标共存，但如果类别之间差异太大，多模型组合部署更灵活。我在项目中做了一个简单的路由策略：根据GPS区域或手动选择的作业模式，加载对应类别的模型文件，不同模型独立统计性能，互不干扰。

7.3 从手机端上位机到边缘计算盒子的延伸

这套MAUI加YOLO的代码，其实也很容易平移到边缘计算盒子或工控一体机上。MAUI的Windows输出可以直接跑在边缘计算盒子上，同一个模型文件、同一套代码，性能会比手机好很多。如果把ONNX Runtime的Execution Provider替换成npu或Vulkan相关版本，还能进一步发挥边缘设备的AI算力。对于预算有限的团队，先用一套代码验证全部场景，再针对单一场景做原生性能调优，是个成本效益很高的路线。

自己在实际项目中的体会是，不要一上来就追求大而全的跨端框架和复杂的微服务，先用MAUI加YOLO做成一个能跑通的闭环，把“摄像头到检测框”这条链路的每一环吃透，再逐步扩充场景，比什么都稳妥。另外建议准备三到五台不同品牌的Android测试机，专门跑目标检测的兼容性测试，平台差异这种东西，真机永远比模拟器可靠。