★ FEATURED ARTICLE 简介一套基于WPF、OpencvSharp与C#开发的仿Visionmaster通用视觉框架采用流程图式拖拉拽编排包含完整可编译源码。面向视觉工程师、上位机开发者及工业自动化从业者插件式设计支持按需扩展功能适合学习MVVM分层架构并快速落地实际项目。资源包共2000个文件以434个C#源代码、693个JSON配置为主搭配XAML界面、xml配置、dll依赖库及工程文件压缩包大小335.39MB已有117人学习下载。框架按Views、ViewModel、Models、Service四层组织界面、数据、存储与功能操作清晰分离内置深度学习、AI检测、线程、延时、跳转等插件模块可从空项目开始搭建视觉流程也可直接导入开发环境编译运行。全套源码开源既可用于理解工业视觉软件的整体设计思路也能直接二次开发复用为自定义视觉框架代码注释与目录结构完整适合作为上位机视觉项目的起步模板。1. 从VisionMaster到WPF为什么我会想复刻一个拖拉拽视觉框架用过海康VisionMaster的工程师都知道把算子拖进流程框、连几根线一套视觉检测就搭出来了。但真到要把它嵌进自己的上位机、写个自定义算法或者做特殊UI时就会撞到黑匣子的天花板——接口够用但看不到内部链条改起来总觉得使不上劲。所以我自己的选择是用WPF做界面、OpenCvSharp做图像处理、C#做整体调度仿照VisionMaster的交互逻辑从零写一套拖拉拽的通用视觉框架。这套源码把流程编辑、算子执行、参数配置、结果输出都拆开放在工程里解压后能直接编译运行。它适合三类人想研究视觉软件架构的要做视觉上位机集成的以及不愿被商业软件锁死、想自己扩展算子和算法的工程师。它解决的不是“能不能跑”而是“能不能改、能不能嵌入产线”。2. 框架的整体架构解决方案结构、流程引擎与数据流设计2.1 解决方案结构主程序、核心类库与算子插件解压源码后先别急着按F5。我会花十分钟把.sln的结构和项目依赖看一遍搞清楚哪个工程是框架本体、哪个是扩展入口。这套源码通常拆成四到五个项目下面列的是我在实际工程里最常见的划分方式也符合这套框架的定位工程名常见命名职责关键类型App.WPF主程序负责菜单、工具栏、流程设计器、属性面板MainWindow, FlowDesignerControlFramework.Core流程引擎、节点定义、端口、连接、执行上下文FlowNode, FlowConnection, FlowEngineFramework.Operators内置算子图像读写、灰度、阈值、轮廓查找等ImageLoaderNode, ThresholdNodeFramework.UtilsMat与BitmapSource互转、路径处理、日志等辅助功能MatConverter, PathHelper依赖关系通常是App.WPF 引用 Core 和 OperatorsOperators 引用 CoreUtils 被前三者共用。这样划分的核心目的是把流程引擎与具体算法解耦。你在二次开发时如果只写新算子可以不动主程序如果改流程调度逻辑也只在Framework.Core里改不会影响算子库。对于一套通用视觉框架来说这个边界比“早点跑起来”更重要。在Core工程里最关键的类型是FlowNode。它决定了整套框架的扩展方式。我习惯把它简化成下面这段代码public class FlowNode { public string Id { get; set; } // 节点唯一标识保存文件时用 public string TypeName { get; set; } // 用于反射创建实例 public string DisplayName { get; set; } // 界面上显示的名称 public double X { get; set; } // 画布中的横坐标 public double Y { get; set; } // 画布中的纵坐标 public Dictionarystring, string Parameters { get; set; } new(); public ListPort InputPorts { get; set; } new(); public ListPort OutputPorts { get; set; } new(); }Id 在新建节点时用Guid生成用来在连接线上引用节点。TypeName 保存的是算子类的全名比如“Framework.Operators.ThresholdNode”打开流程文件时通过反射创建实例。X、Y 用于恢复节点在画布上的位置。Parameters 是一个字符串字典所有参数都以字符串形式保存这样JSON序列化最简单但代价是需要做类型转换。端口列表表示这个节点能接受哪些输入、能输出哪些数据。端口在很多工程里也叫“Pin”。一个端口至少包含端口名、数据类型、方向。Core里通常用抽象类或标记接口来定义public class Port { public string Id { get; set; } public string Name { get; set; } // 端口显示名 public Type DataType { get; set; } // 例如 typeof(Mat) public PortDirection Direction { get; set; } } public enum PortDirection { Input, Output }这样在做连接时就能做类型检查如果输出Mat的端口连到输入阈值的端口上框架可以直接拒绝并标红。很多人第一次写类似框架时会图省事把所有数据都塞到一个全局变量里但流程一复杂全局变量就成了交叉污染的源头。端口式数据流才是仿VisionMaster的核心后面会详细解释。2.2 拖拉拽的底层实现逻辑节点连接与流程执行引擎流程设计的本质是在画布上维护一个有向图。节点是顶点连接线是边。执行流程时从没有输入的源节点开始按拓扑顺序依次执行每个节点。以“图像读取→灰度化→二值化→轮廓查找”为例引擎必须保证灰度化在图像读取之后执行。拿到源码后我会先找FlowEngine类看它的Execute方法是怎么写的。核心部分通常长这样public void Execute() { var order TopologicalSort(); // 返回按依赖顺序排好的节点列表 foreach (var node in order) { PrepareInputs(node); // 从连接中收集上游输出 node.Execute(); // 调用算子执行 CollectOutputs(node); // 把节点输出缓存到上下文 } }TopologicalSort 要做的不仅是排序还要检测环路。如果流程存在环引擎必须提前报错否则会死循环。PrepareInputs 根据当前节点的InputPorts找到对应连接的上游节点输出端口把数据从上下文取出来赋值给节点的输入属性。CollectOutputs 把节点的输出数据写回上下文供下游读取。但工业视觉流程经常会遇到一个节点需要等待多个输入就绪的情况比如“模板匹配”节点要同时接收图像和模板数据。这时候线性遍历就不够了更通用的是事件驱动的调度器每个节点维护一个就绪计数器当所有输入端口都收到数据后节点才被加入执行队列。简单实现可以用邻接表加入度计数本质是DAG拓扑排序的变体。为了便于存储和交换流程文件通常保存为JSON。下面是一个包含三个节点的极简流程{ nodes: [ { id: n1, type: imageLoader, displayName: 读取图像, x: 100, y: 100, parameters: { filePath: D:/samples/gear.png } }, { id: n2, type: grayScale, displayName: 灰度化, x: 280, y: 100, parameters: {} }, { id: n3, type: threshold, displayName: 二值化, x: 460, y: 100, parameters: { thresh: 120, maxValue: 255 } } ], connections: [ { from: n1, fromPort: out, to: n2, toPort: in }, { from: n2, fromPort: out, to: n3, toPort: in } ] }加载流程文件时框架先反序列化节点列表再用反射创建算子实例最后建立连接。注意连接里引用的是节点Id而不是对象引用否则序列化会无限递归。保存和加载这个环节也藏着不少坑后面有一章专门讲。2.3 算子之间的数据交互Mat、Region与结果缓冲节点间传递的数据类型是什么在视觉框架里最常见的是图像Mat、轮廓Region、数值结果长度、面积、角度。如果每个连接直接引用上游对象那么上游节点执行下一次流程时复用同一块Mat下游指针就会指向被修改的数据。所以大多数框架会在引擎层提供一个“执行上下文”用拷贝或缓冲的方式传递数据。简化版实现可以是这样public class NodeExecutionContext { public Dictionarystring, object Inputs { get; } public Dictionarystring, object Outputs { get; } public T GetInputT(string portName) { if (Inputs.TryGetValue(portName, out var value) value is T typed) return typed; return default; } public void SetOutput(string portName, object value) { Outputs[portName] value; } }每个节点执行前引擎把已经就绪的输入数据填入Inputs执行后引擎把Outputs写回上下文。下游节点的输入来源不是“直接引用”上游输出而是从上下文按端口名拷贝。这里对于Mat来说拷贝只是浅拷贝底层像素数据依然是共享的。所以一旦需要长时间保留图像最好主动调用Clone()。我在自己的工程里一般是这么处理的每次流程运行新建一个独立的NodeExecutionContext每个节点在Execute内部对需要异步保留的Mat调用Clone()。另外还可以在上下文中记录数据类型用泛型或Type检查来避免把轮廓数据当成Mat传给下一个算子。这个类型检查做在连接时比做在运行时更友好因为用户拖线时就能看出问题。数据交互还有一个细分问题算子的输入到底支持单输入还是多输入VisionMaster里很多算子支持多路图像输入。框架中端口列表本身就支持多个输入端口引擎在事件驱动模式下会等待所有输入端口都产生数据后才执行这样就天然支持“多输入汇合”。汇合时要注意输入顺序端口名做区分否则不同图像数据可能传错位置。3. 上手运行与自定义算子从零搭一个“定位测量”流程3.1 环境准备与首次编译.NET版本与OpenCvSharp包在跑这套源码之前先确认你的开发环境。我用的Visual Studio 2022目标框架根据工程配置可能是.NET 6或.NET 8建议先打开.csproj看TargetFramework。如果电脑上没装对应版本的.NET SDK编译时会提示找不到运行时。OpenCvSharp这一块源码里一般通过NuGet引用两个包PackageReference IncludeOpenCvSharp4 Version4.* / PackageReference IncludeOpenCvSharp4.runtime.win Version4.* /第一个是C#接口层第二个是OpenCV的原生运行库。注意OpenCvSharp4.runtime.win只包含Windows的x64和x86版本如果要部署到Linux工控机需要换成OpenCvSharp4.runtime.ubuntu这类包。源码标题说“开箱即用”但到了新机器上还是建议先做一次NuGet还原确保所有程序集版本一致。另一个容易忽略的问题是OpenCvSharp的原生DLL有时不会被自动复制到输出目录。如果编译后运行提示“无法加载OpenCvSharpNative.dll”你需要检查bin目录下是否有opencv_videoio_ffmpeg*.dll、opencv_core*.dll这些文件。没有的话在csproj里加一行CopyLocalLockFileAssembliestrue/CopyLocalLockFileAssemblies这样能让引用的原生包也被复制出来。如果你还不放心可以在主程序启动时强制校验OpenCvSharp版本号避免“本来能跑换了台电脑就不能跑”的尴尬。3.2 拖出第一个流程加载图像、灰度化、二值化与轮廓测量环境准备好之后就可以开始玩内置算子了。这套框架的界面和VisionMaster类似左侧是工具箱中间是流程设计画布右边是参数面板和输出面板。以下是一个最简单的定位与测量流程我建议你照着搭一遍先跑通再改逻辑。从工具箱把“图像读取”拖到画布在参数面板里选择一张测试图片。推荐先用500×500左右的灰度图图像显示快一些。再拖入“灰度化”。如果原图本来就是灰度图这个算子可以跳过但为了流程完整还是加上。拖入“二值化”。设定阈值120最大灰度255二值化类型选Binary。拖入“轮廓查找”。模式选List方法选Simple。拖入“轮廓测量”。选择要测量的轮廓索引比如0号。按顺序把相邻节点连接起来图像读取的输出连到灰度化的输入灰度化输出连到二值化输入以此类推。点击“运行”按钮。右侧输出面板会显示轮廓数量、最大轮廓面积或长度。下面是这个流程的JSON配置片段引擎加载后和你在画布上拖出来的一模一样{ nodes: [ {id:a1,type:imageLoader,displayName:读取图像,x:50,y:50,parameters:{filePath:C:/test.png}}, {id:a2,type:grayScale,displayName:灰度化,x:250,y:50,parameters:{}}, {id:a3,type:threshold,displayName:二值化,x:450,y:50,parameters:{thresh:120,maxValue:255,thresholdType:Binary}}, {id:a4,type:findContours,displayName:轮廓查找,x:650,y:50,parameters:{mode:List,method:Simple}}, {id:a5,type:measureContour,displayName:轮廓测量,x:850,y:50,parameters:{index:0}} ], connections: [ {from:a1,fromPort:out,to:a2,toPort:in}, {from:a2,fromPort:out,to:a3,toPort:in}, {from:a3,fromPort:out,to:a4,toPort:in}, {from:a4,fromPort:out,to:a5,toPort:in} ] }如果你运行后发现轮廓测量节点报“输入不是有效轮廓”多半是前面二值化阈值太低背景噪声也被当成轮廓。可以先把阈值拉到150或者加入一个“高斯模糊”算子做预处理。这也是拖拽流程的好处随时插入一个节点不用改主程序代码。3.3 自定义算子继承、输入输出声明与参数面板绑定内置算子跑通后你一定会想加自己的算法。自定义算子并不难核心是继承框架定义好的基类并声明输入输出端口。以我写的一个“自适应阈值”算子为例using OpenCvSharp; namespace Framework.CustomOperators { public class AdaptiveThresholdNode : NodeBase { [NodeInput(Source, typeof(Mat))] public Mat Source { get; set; } [NodeOutput(Result, typeof(Mat))] public Mat Result { get; set; } [NodeParameter(BlockSize, 3, 255, 15)] public int BlockSize { get; set; } [NodeParameter(Constant, -10.0, 10.0, 2.0)] public double Constant { get; set; } public override void Execute() { if (Source null) return; Result new Mat(); Cv2.AdaptiveThreshold(Source, Result, 255, AdaptiveThresholdTypes.GaussianC, ThresholdTypes.Binary, BlockSize, Constant); } } }NodeBase是核心工程提供的抽象类至少定义了Execute和端口初始化方法。NodeInput、NodeOutput特性用来描述端口框架在拖拽连接时通过反射读取这些特性自动生成端口。NodeParameter特性描述的是参数面板上一个参数的取值范围和默认值参数含义分别是显示名、最小值、最大值、默认值。所以你在属性面板看到的滑块、输入框其实是框架根据特性反射生成的控件。我把自定义算子编译成单独DLL后放到框架的“Operators”文件夹主程序启动时扫描该文件夹并加载所有继承NodeBase的类。这样既不影响主程序又能让不同项目共享同一套算子库。需要注意NodeBase的Execute方法里不要直接操作UI。如果有进度回显需求通过事件或消息总线抛出让主程序去订阅否则多线程执行时很容易出现跨线程访问异常。4. 避坑指南二次开发与运行时的5个高频问题4.1 UI线程卡死与图像内存暴涨现象拖拽节点时界面掉帧运行几次流程后内存从几百MB涨到2GB最后出现OutOfMemory。原因主线程直接执行了耗时的Cv2算子图像转换后的BitmapSource没有及时释放每个节点输出都保留了一份Mat缓存。解决办法分两步。所有耗时的流程执行要么放到后台线程要么在耗时超过阈值时用Task.Run。但注意WPF控件只能由主线程访问所以结果返回后要用Dispatcher.Invoke更新UI。另一个是每次流程执行后主动清理节点缓存。我给流程执行上下文实现了IDisposable释放所有Mat资源并在界面切换流程时强制调用GC。public void RunFlowInBackground() { Task.Run(() { try { _engine.Execute(); } finally { App.Current.Dispatcher.Invoke(() { var image _engine.GetResultMat(final); PreviewImage.Source MatConverter.ToBitmapSource(image.Clone()); }); } }); }Task.Run把引擎执行放到线程池避免阻塞UI。finally里的Dispatcher.Invoke确保完成后回到主线程更新图像。注意GetResult返回的Mat不要被跨线程释放否则UI图像会变绿块。这里用Clone()复制一份给UI原始Mat可以随上下文释放。4.2 高分屏DPI缩放导致拖拽坐标对不准现象在4K屏、150%缩放下把节点拖到某个位置松手后节点却“跳”到另一个位置连线也歪了。原因WPF默认使用设备无关单位而鼠标e.GetPosition返回的坐标已经经过系统缩放但画布的渲染坐标没有同步换算导致偏移。解决办法在流程设计器的根容器里用PresentationSource获取DPI缩放系数并把鼠标坐标除以这个系数后再赋值。常见做法是在Canvas上重写OnPreviewMouseDownprivate Point GetLogicalPoint(MouseEventArgs e) { var source PresentationSource.FromVisual(this); var transform source.CompositionTarget.TransformFromDevice; return source.CompositionTarget.TransformToDevice.Transform(e.GetPosition(this)); }这段代码把设备像素坐标转换成WPF的逻辑坐标。注意如果Canvas外面还有ScrollViewer还需要把ScrollViewer的平移量叠加进去否则滚动画布后拖拽依然对不准。最简单的测试方法把系统DPI调到125%然后拖一个节点绕一圈看节点是否紧紧跟随鼠标。4.3 OpenCvSharp的Mat与BitmapSource互转出现图像颠倒或色偏现象图像显示出来上下颠倒或者蓝红通道互换。原因OpenCvSharp的Mat默认是BGR三通道而WPF的BitmapSource通常要求BGRA格式Cv2.ImRead用IMREAD_COLOR读取时本身就是BGR如果直接转成Bgra32就会错位。解决我封装了一个统一转换函数把像素数据复制到托管数组再构造BitmapSource避免引用Mat内部内存。public static BitmapSource ToBitmapSource(Mat mat) { if (mat null) return null; if (mat.Type() ! MatType.CV_8UC3) { var temp new Mat(); Cv2.CvtColor(mat, temp, ColorConversionCodes.GRAY2BGRA); mat temp; } var image new WriteableBitmap( mat.Width, mat.Height, 96, 96, PixelFormats.Bgra32, null); image.WritePixels(new Int32Rect(0, 0, mat.Width, mat.Height), mat.Data, (int)mat.Total() * mat.ElemSize(), mat.Step()); return image; }这个函数先确保Mat是CV_8UC3格式再转成BGRA用mat.Data直接拷贝像素。注意mat.Data指向非托管内存转换完成后不能立即释放Mat要等WritePixels调用结束。如果你在循环里批量转换还要额外注意每帧图像的步长和字节数避免数据错位。4.4 多线程执行时算子之间的数据竞争现象两个流程并行跑或者同一流程中有两个分支同时处理图像偶尔出现“输入图像变成花屏”或结果错乱。原因共享的FlowContext被多个线程读写或者不同分支的算子复用同一个Mat实例。解决为每一次流程运行创建一个独立的FlowContext实例不要使用静态缓存分支汇合点要等待所有输入完成。可以用C#的Task.WhenAll或信号量实现。简化的汇合等待var branchTasks new ListTask(); foreach (var branch in branches) branchTasks.Add(Task.Run(() ExecuteBranch(branch))); await Task.WhenAll(branchTasks);关键是每条分支使用不同的局部变量不修改共享的FlowContext。所有共享变量在读取时用lock或volatile保护。另外OpenCvSharp的Mat不是线程安全的同一个Mat多线程只读可以一旦有写入就会出问题。所以在我自己的框架里凡是可能被并发访问的Mat都在分支内部先Clone一份。4.5 流程文件保存后再打开参数丢失或连接断开现象调好一套流程保存为JSON第二天打开发现部分算子的阈值、ROI坐标都变成了默认值甚至连接线消失。原因很多模板保存时只序列化了节点的公共属性但ROI、区域等参数存在没有被序列化的私有类中或者是反序列化时节点Id发生了变化连接线引用的Id找不到原节点。解决确保保存的是节点实例的完整状态而不是界面上的临时状态。建议在FlowNode里增加一个SchemaVersion字段public int SchemaVersion { get; set; } 1;加载时如果版本号不匹配用工厂方法做兼容转换。所有参数统一放在Parameters字典中序列化时转成字符串避免类型丢失。连接线恢复前先用Dictionarystring, FlowNode按Id索引所有节点再逐条建立连接。如果打开后出现参数丢失先检查参数名是否写错再检查SchemaVersion是否变了。5. 从框架到项目接入相机、PLC与部署现场的边界5.1 相机采图让图像源从文件变成实时帧这套源码默认的图像读取算子读的是本地文件路径。真实产线上图像来源通常是GigE相机或USB工业相机。接入思路很简单写一个自定义算子内部封装相机SDK在Execute时把最新一帧返回。以海康MVS为例底层SDK是CC#调用SDK需要处理回调函数。框架里不需要关心SDK细节只需要在回调里把Image指针拷贝到Mat。我在工程里的做法public class CameraCaptureNode : NodeBase { [NodeOutput(Image, typeof(Mat))] public Mat Image { get; set; } private IntPtr _framePtr; public override void Execute() { _framePtr CameraLib.GetLatestFramePtr(); if (_framePtr IntPtr.Zero) return; var mat new Mat(rows: Height, cols: Width, MatType.CV_8UC3); Cv2.CopyTo(mat, ...); // 实际拷贝需按SDK像素格式处理 Image mat.Clone(); } }注意相机回调线程不能直接操作WPF控件所以Execute也必须由非UI线程调用。引擎如果跑在后台线程就没问题如果你直接在UI线程点“运行”按钮这个算子会造成卡顿。我的习惯是把按钮点击事件都指向同一个RunBackground方法引擎整体放到Task.Run里避免阻塞。5.2 与PLC联动用触发信号启动流程把结果写回在产线上视觉系统往往不是独立工作的。PLC会在工件到位后给触发信号视觉程序跑完再回传OK/NG。这个逻辑在框架内可以用“通信节点”实现。最简单的方式是让流程开始节点监听一个外部触发端口。比如Modbus触发节点读一个寄存器有信号才执行下游流程。结果节点再写回PLC。一个简化版实现public class ModbusTriggerNode : NodeBase { [NodeOutput(Signal, typeof(bool))] public bool Signal { get; set; } public override void Execute() { Signal ModbusClient.ReadCoil(0x01, 0); if (Signal) { // 通知下游执行 } } }注意这个Execute本身是一次轮询不能阻塞太久。需要把Modbus的超时时间设置为几十毫秒而不是默认的无限等待否则流程执行周期会被拖长达不到产线节拍。另一个重要点是触发后的数据同步当PLC发出信号后框架可能在后台执行流程此时WPF界面上显示的结果要实时刷新要防止PLC信号多次触发导致重复运行。5.3 部署到工控机前的三个检查清单框架在开发电脑上能跑不代表能顺利部署到现场工控机。我列三条容易翻车的点打包前逐一确认。第一目标平台。工控机如果是老的Intel Atom可能只支持x86而OpenCvSharp的runtime.win同时有x64和x86。建议直接在解决方案里把目标平台改成x64除非你的相机SDK只支持x86。两者混用很容易在加载OpenCvSharp时崩溃。第二外部DLL依赖。除了OpenCvSharp相机SDK、Modbus通信库也会带一堆DLL。发布时用dotnet publish输出目录会有大量文件不要只拷贝exe。最好用单文件发布排除未包含的原生库然后手动把OpenCvSharp和相机SDK的DLL放到同一目录。我吃过一次亏现场工控机没装VC运行库程序启动直接无窗口退出后来把所有运行库都随包带过去才解决。第三流程文件的路径。凡是参数里写了“D:/...”的路径换一台机器大概率失效。我习惯在引擎里做路径归一化如果参数是绝对路径则尝试把工作目录下的相对路径优先否则就报错并提示。流程文件本身也复制到exe所在目录的Config子目录这样最少依赖外部路径。部署前在无网环境测试一遍确认所有依赖都在本地才算真正“开箱即用”。6. 把流程执行日志变成调试利器一个我反复在用的技巧框架跑起来容易但流程出问题要定位难。早期我在自己写的视觉框架里遇到“上一个节点输出没问题下一个节点却拿不到数据”这种问题只能靠打断点一次一次重跑。后来我加了一个节点执行日志服务把每个算子执行的开始、结束、耗时、异常都记录下来定位效率提高了一个数量级。实现思路很简单在FlowEngine里加一个事件或委托每个节点执行前后调用它。我写了一个Logger类public class FlowExecutionLogger { private readonly Stopwatch _sw new(); public event Actionstring OnLog; public void BeforeNode(FlowNode node) { _sw.Restart(); OnLog?.Invoke(${DateTime.Now:HH:mm:ss.fff} 进入 [{node.DisplayName}]); } public void AfterNode(FlowNode node, long elapsedMs) { OnLog?.Invoke(${DateTime.Now:HH:mm:ss.fff} 完成 [{node.DisplayName}] 用时 {elapsedMs} ms); } public void NodeFailed(FlowNode node, Exception ex) { OnLog?.Invoke(${DateTime.Now:HH:mm:ss.fff} 节点 [{node.DisplayName}] 异常{ex.Message}); } }然后在FlowEngine.Execute方法里给每个节点包一层try-catch_logger.BeforeNode(node); try { node.Execute(); _logger.AfterNode(node, _sw.ElapsedMilliseconds); } catch (Exception ex) { _logger.NodeFailed(node, ex); throw; }日志输出到哪里我一般接到主界面的LogListView同时写入带日期的文本文件。关键是输出“耗时”和“节点名称”这两个字段能快速暴露哪个算子是性能瓶颈。有一次我排查一个流程单次执行要1.5秒从日志看到“轮廓查找”耗时1.2秒后来把轮廓检索模式从Simple换External直接降到0.3秒。没有日志我不会想到去怀疑这个算子。另外每个节点执行结束时我会把输出数据的摘要也写进日志。比如输出的是Mat记录尺寸和通道数输出的是轮廓记录数量。这样数据传递是否正确一目了然。private string Summarize(object value) { if (value is Mat mat) return $Mat({mat.Width}x{mat.Height}, {mat.Channels()}ch); if (value is System.Collections.IEnumerable list) return ${list.Castobject().Count()} items; return value?.ToString() ?? null; }多线程场景下日志要加锁避免不同流程交叉写入。我用lock实现保持框架轻量。从那以后我每次搭新流程都会先开启日志眼睛看着算子的耗时和输出类型很多问题一眼就看穿了。这个习惯一直保留到现在甚至给客户做远程支持时也会让他们把日志发给我往往不用一分钟就能定位问题。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
