简介面向需要融合 Unity3D 与 WPF 打造三维交互桌面应用的开发人员这套资源提供了从 Unity 项目搭建、内容导出到 WPF 宿主集成的完整示例代码与工程文件。资源共 140 个文件包含 32 个 C# 脚本、23 个 DLL 运行库、11 个 PDB 调试文件、6 个 EXE 程序及 XAML 界面、配置文件等压缩包约 49.44MB。目前已有 937 人学习使用适合具备一定 C# 与 Unity 基础、希望掌握嵌入式渲染通信与交互控制的开发者。包内覆盖 Unity 工程导出配置、WPF 窗体宿主控件封装、双向通信调用、场景加载与资源管理等多个关键环节可直接对照源码理解嵌入集成流程、排查兼容问题并快速迁移到自有项目中。 上个月我把一个设备监控上位机的三维场景从独立Unity窗口改成了嵌入WPF主界面前后折腾了将近一周。原以为这事就是把Unity窗口塞进WPF这么简单真正动手才发现窗口句柄获取、边框样式、DPI缩放、输入焦点、跨进程通信这些细节一个都不能省漏掉任何一个都会在交付后被现场环境教做人。这篇文章不只讲Unity3D嵌入WPF怎么实现更会把我踩过的坑和最后定型的方案完整交代清楚为什么选子进程加窗口重嵌而不是进程内加载Unity端构建参数怎么配WPF端HwndHost怎么写两边怎么通过TCP回环把指令和状态对齐。适合正在做工业上位机、数字孪生、CAD模型三维预览这类项目的朋友参考也适合刚接触WPF和Unity互嵌、想知道从哪下手的同学。1. 为什么会走到Unity3D嵌入WPF这一步1.1 上位机场景里WPF和Unity各自擅长什么做工业上位机的朋友应该都有体会WPF这套东西做复杂业务界面、数据绑定、表格表单、图表曲线——像LiveCharts、OxyPlot——效率是真的高配合Prism和MVVM可以把界面逻辑理得很清楚。设备树用TreeView、参数面板用PropertyGrid、联动命令走命令绑定这些在WPF里都是成熟套路团队上手也快。但你要是想在WPF里直接搞一个带材质、带光照、能实时旋转的设备三维场景就会非常痛苦。WPF本身没有3D场景编辑器模型导入、材质、动画、拾取全要自己造轮子造到一半基本就放弃了。反过来Unity做三维场景是强项材质球、PBR资源、光照烘焙、碰撞拾取都是现成的可Unity的UGUI做工业软件的复杂表单、多级菜单、报表体验又差了一截。所以两者结合是自然选择WPF做主壳负责界面、数据、业务逻辑Unity做渲染视口把设备状态用三维方式呈现出来。我这里接到的需求就是典型的三维可视化上位机左侧设备树中间三维场景右侧参数面板底部实时曲线。整个界面框架、设备管理与数据采集都在WPF里Unity只干一件事——把设备当前状态渲染出来。1.2 三种主流嵌入方案我为什么选了子进程当前能用的方案大致三条路我在选型时做了个对比方案原理优点缺点适合场景WindowsFormsHost嵌套WPF里放WindowsFormsHost里面用WinForms Panel再SetParent把Unity窗口挂进去实现最快十几行代码就能出效果Airspace空域问题多WPF控件无法覆盖在上方弹窗和悬浮元素会被遮挡内部工具、快速验证HwndHost自建承载自己写HwndHost子类创建容器窗口把Unity窗口重嵌进去生命周期可控消息处理灵活能作为控件融入布局需要处理窗口样式、尺寸同步、进程退出等细节正式产品进程内加载UnityPlayer.dll直接调用UnityPlayer的导出接口在WPF进程内跑Unity通信延迟最低可共享内存接口非公开Unity升级后兼容性风险高调试成本大特殊高性能场景我最后选了第二个HwndHost加子进程。原因是工业上位机对稳定性要求太高子进程方案里Unity和WPF是两个独立进程Unity崩了WPF主程序还能弹提示、做自愈不至于整个上位机跟着一起死掉。进程内加载虽然通信爽但Unity官方并没有公开承诺这个接口长期稳定产品要维护好几年的话这个风险不值得冒。我在.NET Framework 4.7.2和.NET 8两个目标上都验证过这套架构HwndHost的行为基本一致。2. Unity端的工程准备构建参数和启动方式2.1 PlayerSettings里不能省的三处配置先打开Unity工程Edit → Project Settings → Player按下面配Fullscreen Mode必须选Windowed。嵌入场景里我们不需要Unity自己开全屏窗口这个窗口最终会被WPF接管。Run In Background必须勾选。不勾的话只要Unity窗口不是前台窗口——嵌入后就必然不是——游戏循环就会暂停画面直接卡住这个坑我一开始就踩了。Resizable Window勾不勾都行反正嵌入后尺寸由父窗口的MoveWindow控制但建议勾上避免某些版本在切换时出问题。另外建议把启动分辨率设成和WPF窗口的加载区域接近比如1280x720。这样Unity初始化时的后台缓冲不至于太离谱后面再被强制缩放时画面表现也更稳。2.2 用命令行参数让它裸奔出来Unity构建出来的exe支持一些命令行参数嵌入场景最有用的是这几个HmiScene.exe -popupwindow -screen-width 1280 -screen-height 720-popupwindow会让Unity以无边框窗口方式启动省得我们后续还要去改WS_CAPTION样式。-screen-width和-screen-height可以在不重新构建工程的情况下调整启动分辨率调试时极其好用。这里有个细节很多人会忽略启动子进程时WorkingDirectory必须设置成exe所在目录。Unity构建产物是通过相对路径去找同名_Data文件夹的如果用默认工作目录启动Unity会直接白屏或者弹错误框。下面这行代码能省掉你半天排查时间var psi new ProcessStartInfo { FileName unityExePath, Arguments -popupwindow -screen-width 1280 -screen-height 720, WorkingDirectory Path.GetDirectoryName(unityExePath), UseShellExecute false };2.3 模型是怎么从SolidWorks进来的三维场景里的设备模型很多是从SolidWorks这类CAD软件导出的。我这边定型的流程是SolidWorks里另存为STL或OBJ在Unity里导入后挂上PBR材质球调整表现。这样绕开了直接在Unity里读原生CAD格式的兼容性问题整个过程最稳网上能下到的PBR材质资产包也基本都是通用格式直接能用。两个必须注意的点。第一坐标系习惯不一样。很多CAD建模软件的导出流程模型进Unity后朝向是躺着的通常需要在根节点绕X轴旋转-90度摆正如果出现左右镜像检查一下FBX导入设置里的坐标轴转换。这个没有统一结论和导出插件有关但先转一次看看是标准排查动作。第二单位问题。SolidWorks默认毫米Unity默认米导入时不处理缩放一个几米高的设备会变成几千米摄像机直接穿模。用STL/OBJ中转时我习惯在导入设置里把Scale Factor设为0.001或者导出时直接选毫米转米二选一别两个都做。3. WPF侧HwndHost承载核心实现一次说清3.1 为什么用HwndHost而不是WindowsFormsHost很多教程上来就是WindowsFormsHost一把梭。WindowsFormsHost的问题是空域限制它是基于Win32窗口的画中画WPF的非窗口元素没法覆盖在它上面。你的界面里如果在三维视口上弹悬浮窗、做动画、放ToolTip这些WPF元素会被WindowsFormsHost吞掉显示不出来或者变成一块黑。HwndHost也有空域问题但它是WPF原生提供的承载机制消息、尺寸、生命周期都是自己控制出了问题好排查。而且HwndHost可以做成一个控件用DependencyProperty绑定Unity场景路径在MVVM下用起来很顺手。3.2 HwndHost核心代码从创建容器到重嵌Unity窗口直接上我最终定型的简化版本SetParent、MoveWindow、CreateWindowEx这几个是user32的P/Invoke网上声明遍地都是我就不占篇幅了public class UnityHost : HwndHost { private Process _unityProcess; private IntPtr _unityHwnd IntPtr.Zero; private IntPtr _containerHwnd IntPtr.Zero; protected override HandleRef BuildWindowCore(HandleRef hwndParent) { // 1. 创建一个WS_CHILD容器窗口作为Unity窗口的父窗口 _containerHwnd CreateWindowEx(0, static, , WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS, 0, 0, 0, 0, hwndParent.Handle, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero); // 2. 启动Unity子进程 StartUnityProcess(); // 3. 找到Unity窗口句柄并重嵌到容器 _unityHwnd WaitForUnityWindow(_unityProcess); SetParent(_unityHwnd, _containerHwnd); // 4. 去边框填满容器 RemoveCaption(_unityHwnd); MoveWindow(_unityHwnd, 0, 0, 100, 100, true); return new HandleRef(this, _containerHwnd); } protected override void DestroyWindowCore(HandleRef hwnd) { if (_unityProcess ! null !_unityProcess.HasExited) { _unityProcess.CloseMainWindow(); if (!_unityProcess.WaitForExit(3000)) _unityProcess.Kill(); } _unityProcess?.Dispose(); } }三个关键点展开讲。第一为什么要先创建一个容器窗口再SetParent因为HwndHost需要一个有效的子窗口句柄作为自己的核心窗口直接拿Unity窗口当核心窗口会出各种怪问题布局系统不知道这个窗口的真实尺寸、WM_SIZE处理错乱、销毁时序也难控制。套一层容器HwndHost管容器容器管Unity窗口职责分明。第二WaitForUnityWindow不能用Process.MainWindowHandle一把梭。Unity启动时有Splash界面MainWindowHandle可能拿到的是启动画面的窗口或者干脆是0。稳妥做法是按窗口标题轮询FindWindow找不到就Sleep 100毫秒重试最多等5秒超时说明Unity启动失败。我还会在重嵌时判断SetParent返回值失败了要能打出日志不然现场排查会两眼一抹黑。第三MoveWindow时不要直接把宽高写成容器当前大小。在BuildWindowCore阶段布局还没完成ActualWidth/ActualHeight可能是0。我的做法是先MoveWindow一个初始尺寸占位真正的尺寸同步交给WM_SIZE处理。3.3 尺寸同步布局变了Unity窗口要跟着走在HwndHost的WndProc里处理WM_SIZE把Unity窗口拉满protected override IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled) { if (msg WM_SIZE) { int width (short)(lParam.ToInt64() 0xFFFF); int height (short)((lParam.ToInt64() 16) 0xFFFF); if (_unityHwnd ! IntPtr.Zero) MoveWindow(_unityHwnd, 0, 0, width, height, true); } return base.WndProc(hwnd, msg, wParam, lParam, ref handled); }这里有个容易踩的细节lParam低16位是宽度高16位是高度但高度是有符号的直接(int)(lParam.ToInt64() 16)会把负数变成65535这种大数必须先用short转换再取值。这种位运算的小问题在32位和64位进程下表现还不一样调试时特别迷惑人。3.4 关闭和清理优雅退出比Kill重要DestroyWindowCore里先调CloseMainWindow这会触发Unity的OnApplicationQuit让Unity侧做存档、断线通知这些收尾工作3秒没退出再Kill兜底。真实生产环境里我还会在Window.Unloaded事件里一并处理防止窗口关闭时序和HwndHost销毁时序不一致导致Unity变成孤儿进程一直挂在后台。4. 指令与状态WPF和Unity之间的消息通道4.1 通道选型回环TCP是最省心的跨进程通信有几种选择Windows消息PostMessage只能传整数和字符串传JSON还要自己组包而且Unity那边得接子类化窗口的消息钩子麻烦命名管道比TCP多一点配置成本。我用的是127.0.0.1回环TCP一个TcpListener一个TcpClient几行代码就能跑通数据结构化用JSON两边都是字符串收发调试时还能用抓包工具直接看报文。为什么是WPF做Server、Unity做Client因为WPF是主程序Unity是被管理的一方。Unity启动后主动连过来WPF就能感知它的存活状态反过来让WPF去连UnityUnity一旦重启连接关系就全乱了。4.2 下行WPF把指令发给Unity协议格式很简单一行一条JSON{cmd: setState, deviceId: 12, state: running} {cmd: setParam, deviceId: 12, param: temperature, value: 75.5}WPF侧在ViewModel里组装字符串通过TcpClient写入。注意写入要加换行符作为帧分隔符Unity侧的StreamReader.ReadLine刚好能一行一行读。Unity侧接收逻辑也不复杂一个后台线程ReadLine读到内容后压入带锁的Queue在主线程Update里消费。千万别在后台线程里直接动GameObject和场景Unity大部分API不是线程安全的直接调会随机崩溃这种崩溃还特别难复现。4.3 上行Unity把事件回报给WPF三维场景里的设备被点击、状态动画播完、场景加载完成这些都要由Unity主动报给WPF{evt: deviceClicked, deviceId: 12} {evt: sceneReady}WPF收到后用Dispatcher.BeginInvoke切回UI线程再更新ViewModel。这里有个顺序细节如果用户点了场景里的一个设备Unity的点击事件先到WPF的高亮逻辑最好等Unity把摄像机聚焦动画播完再刷新状态不然会出现状态栏先变、画面后动的割裂感。所以我在协议里加了个ack字段让Unity播完动画再发事件把时序压力放在事件源一侧。4.4 心跳与断线自愈协议里加了heartbeatUnity每5秒发一次{evt:heartbeat}WPF侧用一个定时器检查超过15秒没收到就认为Unity场景卡死或崩溃。这时候弹出占位提示并自动重启Unity进程新进程启动后重新连接TCP重新上报sceneReadyWPF这边重新挂载状态。这套机制在交付后救了我好几次——现场显卡驱动的坑、长时间运行内存泄漏的坑都会让Unity进程静默死掉有了自愈用户基本无感知。5. 生产环境实测焦点、DPI、黑屏这些坑怎么填5.1 焦点嵌入后键盘鼠标抢不过主窗口Unity窗口被SetParent嵌入后鼠标点击基本能命中但键盘输入经常还是留在WPF这边场景里的快捷键和文本输入就失灵了。处理分两步Unity侧脚本自行处理所有交互鼠标点击事件通常没问题WPF侧在PreviewMouseDown里检测鼠标落在UnityHost区域时主动调SetFocus把键盘焦点交给Unity窗口。我实测下来鼠标点击后再SetFocus是最自然的不会误伤正常界面操作。5.2 DPI缩放别让Unity画面变成糊的WPF在.NET Framework 4.7以上默认跟随系统DPI一旦用户把显示缩放调成125%、150%嵌入的Unity窗口的坐标和尺寸就会出现偏差画面要么模糊要么被裁切。根因是WPF和Unity两个进程的DPI Awareness设置不一致导致系统给出的窗口尺寸不在同一个坐标系里。我的处理方式是在app.manifest里把WPF进程也声明成和Unity一致的DPI感知级别然后在WM_DPICHANGED里根据新的缩放比重新MoveWindow。如果项目工期紧最省事的方案是WPF进程不做PerMonitorV2全部走系统DPI虽然跨屏显示时会拉伸但至少不会出现嵌入式窗口和主界面脱节这种一眼假的问题。5.3 黑屏与合成问题最小化还原、窗口遮挡黑屏问题我遇到过三种来源。一是Unity窗口最小化后再还原交换链没有自动重建画面卡在最后一帧或直接黑掉处理办法是在WPF的StateChanged事件里检测到恢复后调ShowWindowAsync(_unityHwnd, SW_RESTORE)再MoveWindow一次。二是WPF窗口设置了AllowsTransparencyTrue再配合HwndHost会导致子窗口的透明合成失效画面出现黑块这个特性用不了就果断关。三是显卡驱动切换导致子进程渲染上下文失效这类问题没有通用解法只能靠心跳自愈兜底。5.4 帧率控制与资源占用嵌入场景里Unity默认跑满帧率非常浪费。我在Unity侧做了分级场景无交互时Application.targetFrameRate设为15有操作或动画播放时切到60工业监控场景完全够用。另外vSyncCount设为0不让Unity的垂直同步去跟Unity窗口对齐嵌入场景里垂直同步反而会引入额外延迟。还要留意显存。WPF主程序本身会用一些GPU资源Unity再占一块现场机器如果只有核显建议Unity侧质量等级调低一档抗锯齿开2x就够了工业场景的观感差距不大但帧率稳很多。5.5 子进程崩溃后的恢复表现最后梳理一遍崩溃恢复的完整链路WPF定时器发现心跳超时标记UnityHost为异常显示三维场景加载失败正在恢复的占位面板Kill残留进程重新启动Unity并等待新窗口句柄新进程连上TCP后重新订阅事件。整套流程控制在8秒内用户基本只看到画面闪了一下。这套东西从需求下来到上线中间推倒重来了一次最终定型的就是上面这套架构。每次Unity进程崩掉又被自动拉起来的时刻我都会想如果当初图省事用WindowsFormsHost或者进程内加载现在大概率还在给客户擦屁股。工程和demo之间的距离往往就是这些万一出事怎么办的考虑。本文还有配套的精品资源点击获取 Unity3D嵌入WPF完整指南：HwndHost子进程方案与填坑实录
简介面向需要融合 Unity3D 与 WPF 打造三维交互桌面应用的开发人员这套资源提供了从 Unity 项目搭建、内容导出到 WPF 宿主集成的完整示例代码与工程文件。资源共 140 个文件包含 32 个 C# 脚本、23 个 DLL 运行库、11 个 PDB 调试文件、6 个 EXE 程序及 XAML 界面、配置文件等压缩包约 49.44MB。目前已有 937 人学习使用适合具备一定 C# 与 Unity 基础、希望掌握嵌入式渲染通信与交互控制的开发者。包内覆盖 Unity 工程导出配置、WPF 窗体宿主控件封装、双向通信调用、场景加载与资源管理等多个关键环节可直接对照源码理解嵌入集成流程、排查兼容问题并快速迁移到自有项目中。 上个月我把一个设备监控上位机的三维场景从独立Unity窗口改成了嵌入WPF主界面前后折腾了将近一周。原以为这事就是把Unity窗口塞进WPF这么简单真正动手才发现窗口句柄获取、边框样式、DPI缩放、输入焦点、跨进程通信这些细节一个都不能省漏掉任何一个都会在交付后被现场环境教做人。这篇文章不只讲Unity3D嵌入WPF怎么实现更会把我踩过的坑和最后定型的方案完整交代清楚为什么选子进程加窗口重嵌而不是进程内加载Unity端构建参数怎么配WPF端HwndHost怎么写两边怎么通过TCP回环把指令和状态对齐。适合正在做工业上位机、数字孪生、CAD模型三维预览这类项目的朋友参考也适合刚接触WPF和Unity互嵌、想知道从哪下手的同学。1. 为什么会走到Unity3D嵌入WPF这一步1.1 上位机场景里WPF和Unity各自擅长什么做工业上位机的朋友应该都有体会WPF这套东西做复杂业务界面、数据绑定、表格表单、图表曲线——像LiveCharts、OxyPlot——效率是真的高配合Prism和MVVM可以把界面逻辑理得很清楚。设备树用TreeView、参数面板用PropertyGrid、联动命令走命令绑定这些在WPF里都是成熟套路团队上手也快。但你要是想在WPF里直接搞一个带材质、带光照、能实时旋转的设备三维场景就会非常痛苦。WPF本身没有3D场景编辑器模型导入、材质、动画、拾取全要自己造轮子造到一半基本就放弃了。反过来Unity做三维场景是强项材质球、PBR资源、光照烘焙、碰撞拾取都是现成的可Unity的UGUI做工业软件的复杂表单、多级菜单、报表体验又差了一截。所以两者结合是自然选择WPF做主壳负责界面、数据、业务逻辑Unity做渲染视口把设备状态用三维方式呈现出来。我这里接到的需求就是典型的三维可视化上位机左侧设备树中间三维场景右侧参数面板底部实时曲线。整个界面框架、设备管理与数据采集都在WPF里Unity只干一件事——把设备当前状态渲染出来。1.2 三种主流嵌入方案我为什么选了子进程当前能用的方案大致三条路我在选型时做了个对比方案原理优点缺点适合场景WindowsFormsHost嵌套WPF里放WindowsFormsHost里面用WinForms Panel再SetParent把Unity窗口挂进去实现最快十几行代码就能出效果Airspace空域问题多WPF控件无法覆盖在上方弹窗和悬浮元素会被遮挡内部工具、快速验证HwndHost自建承载自己写HwndHost子类创建容器窗口把Unity窗口重嵌进去生命周期可控消息处理灵活能作为控件融入布局需要处理窗口样式、尺寸同步、进程退出等细节正式产品进程内加载UnityPlayer.dll直接调用UnityPlayer的导出接口在WPF进程内跑Unity通信延迟最低可共享内存接口非公开Unity升级后兼容性风险高调试成本大特殊高性能场景我最后选了第二个HwndHost加子进程。原因是工业上位机对稳定性要求太高子进程方案里Unity和WPF是两个独立进程Unity崩了WPF主程序还能弹提示、做自愈不至于整个上位机跟着一起死掉。进程内加载虽然通信爽但Unity官方并没有公开承诺这个接口长期稳定产品要维护好几年的话这个风险不值得冒。我在.NET Framework 4.7.2和.NET 8两个目标上都验证过这套架构HwndHost的行为基本一致。2. Unity端的工程准备构建参数和启动方式2.1 PlayerSettings里不能省的三处配置先打开Unity工程Edit → Project Settings → Player按下面配Fullscreen Mode必须选Windowed。嵌入场景里我们不需要Unity自己开全屏窗口这个窗口最终会被WPF接管。Run In Background必须勾选。不勾的话只要Unity窗口不是前台窗口——嵌入后就必然不是——游戏循环就会暂停画面直接卡住这个坑我一开始就踩了。Resizable Window勾不勾都行反正嵌入后尺寸由父窗口的MoveWindow控制但建议勾上避免某些版本在切换时出问题。另外建议把启动分辨率设成和WPF窗口的加载区域接近比如1280x720。这样Unity初始化时的后台缓冲不至于太离谱后面再被强制缩放时画面表现也更稳。2.2 用命令行参数让它裸奔出来Unity构建出来的exe支持一些命令行参数嵌入场景最有用的是这几个HmiScene.exe -popupwindow -screen-width 1280 -screen-height 720-popupwindow会让Unity以无边框窗口方式启动省得我们后续还要去改WS_CAPTION样式。-screen-width和-screen-height可以在不重新构建工程的情况下调整启动分辨率调试时极其好用。这里有个细节很多人会忽略启动子进程时WorkingDirectory必须设置成exe所在目录。Unity构建产物是通过相对路径去找同名_Data文件夹的如果用默认工作目录启动Unity会直接白屏或者弹错误框。下面这行代码能省掉你半天排查时间var psi new ProcessStartInfo { FileName unityExePath, Arguments -popupwindow -screen-width 1280 -screen-height 720, WorkingDirectory Path.GetDirectoryName(unityExePath), UseShellExecute false };2.3 模型是怎么从SolidWorks进来的三维场景里的设备模型很多是从SolidWorks这类CAD软件导出的。我这边定型的流程是SolidWorks里另存为STL或OBJ在Unity里导入后挂上PBR材质球调整表现。这样绕开了直接在Unity里读原生CAD格式的兼容性问题整个过程最稳网上能下到的PBR材质资产包也基本都是通用格式直接能用。两个必须注意的点。第一坐标系习惯不一样。很多CAD建模软件的导出流程模型进Unity后朝向是躺着的通常需要在根节点绕X轴旋转-90度摆正如果出现左右镜像检查一下FBX导入设置里的坐标轴转换。这个没有统一结论和导出插件有关但先转一次看看是标准排查动作。第二单位问题。SolidWorks默认毫米Unity默认米导入时不处理缩放一个几米高的设备会变成几千米摄像机直接穿模。用STL/OBJ中转时我习惯在导入设置里把Scale Factor设为0.001或者导出时直接选毫米转米二选一别两个都做。3. WPF侧HwndHost承载核心实现一次说清3.1 为什么用HwndHost而不是WindowsFormsHost很多教程上来就是WindowsFormsHost一把梭。WindowsFormsHost的问题是空域限制它是基于Win32窗口的画中画WPF的非窗口元素没法覆盖在它上面。你的界面里如果在三维视口上弹悬浮窗、做动画、放ToolTip这些WPF元素会被WindowsFormsHost吞掉显示不出来或者变成一块黑。HwndHost也有空域问题但它是WPF原生提供的承载机制消息、尺寸、生命周期都是自己控制出了问题好排查。而且HwndHost可以做成一个控件用DependencyProperty绑定Unity场景路径在MVVM下用起来很顺手。3.2 HwndHost核心代码从创建容器到重嵌Unity窗口直接上我最终定型的简化版本SetParent、MoveWindow、CreateWindowEx这几个是user32的P/Invoke网上声明遍地都是我就不占篇幅了public class UnityHost : HwndHost { private Process _unityProcess; private IntPtr _unityHwnd IntPtr.Zero; private IntPtr _containerHwnd IntPtr.Zero; protected override HandleRef BuildWindowCore(HandleRef hwndParent) { // 1. 创建一个WS_CHILD容器窗口作为Unity窗口的父窗口 _containerHwnd CreateWindowEx(0, static, , WS_CHILD | WS_VISIBLE | WS_CLIPSIBLINGS, 0, 0, 0, 0, hwndParent.Handle, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero); // 2. 启动Unity子进程 StartUnityProcess(); // 3. 找到Unity窗口句柄并重嵌到容器 _unityHwnd WaitForUnityWindow(_unityProcess); SetParent(_unityHwnd, _containerHwnd); // 4. 去边框填满容器 RemoveCaption(_unityHwnd); MoveWindow(_unityHwnd, 0, 0, 100, 100, true); return new HandleRef(this, _containerHwnd); } protected override void DestroyWindowCore(HandleRef hwnd) { if (_unityProcess ! null !_unityProcess.HasExited) { _unityProcess.CloseMainWindow(); if (!_unityProcess.WaitForExit(3000)) _unityProcess.Kill(); } _unityProcess?.Dispose(); } }三个关键点展开讲。第一为什么要先创建一个容器窗口再SetParent因为HwndHost需要一个有效的子窗口句柄作为自己的核心窗口直接拿Unity窗口当核心窗口会出各种怪问题布局系统不知道这个窗口的真实尺寸、WM_SIZE处理错乱、销毁时序也难控制。套一层容器HwndHost管容器容器管Unity窗口职责分明。第二WaitForUnityWindow不能用Process.MainWindowHandle一把梭。Unity启动时有Splash界面MainWindowHandle可能拿到的是启动画面的窗口或者干脆是0。稳妥做法是按窗口标题轮询FindWindow找不到就Sleep 100毫秒重试最多等5秒超时说明Unity启动失败。我还会在重嵌时判断SetParent返回值失败了要能打出日志不然现场排查会两眼一抹黑。第三MoveWindow时不要直接把宽高写成容器当前大小。在BuildWindowCore阶段布局还没完成ActualWidth/ActualHeight可能是0。我的做法是先MoveWindow一个初始尺寸占位真正的尺寸同步交给WM_SIZE处理。3.3 尺寸同步布局变了Unity窗口要跟着走在HwndHost的WndProc里处理WM_SIZE把Unity窗口拉满protected override IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled) { if (msg WM_SIZE) { int width (short)(lParam.ToInt64() 0xFFFF); int height (short)((lParam.ToInt64() 16) 0xFFFF); if (_unityHwnd ! IntPtr.Zero) MoveWindow(_unityHwnd, 0, 0, width, height, true); } return base.WndProc(hwnd, msg, wParam, lParam, ref handled); }这里有个容易踩的细节lParam低16位是宽度高16位是高度但高度是有符号的直接(int)(lParam.ToInt64() 16)会把负数变成65535这种大数必须先用short转换再取值。这种位运算的小问题在32位和64位进程下表现还不一样调试时特别迷惑人。3.4 关闭和清理优雅退出比Kill重要DestroyWindowCore里先调CloseMainWindow这会触发Unity的OnApplicationQuit让Unity侧做存档、断线通知这些收尾工作3秒没退出再Kill兜底。真实生产环境里我还会在Window.Unloaded事件里一并处理防止窗口关闭时序和HwndHost销毁时序不一致导致Unity变成孤儿进程一直挂在后台。4. 指令与状态WPF和Unity之间的消息通道4.1 通道选型回环TCP是最省心的跨进程通信有几种选择Windows消息PostMessage只能传整数和字符串传JSON还要自己组包而且Unity那边得接子类化窗口的消息钩子麻烦命名管道比TCP多一点配置成本。我用的是127.0.0.1回环TCP一个TcpListener一个TcpClient几行代码就能跑通数据结构化用JSON两边都是字符串收发调试时还能用抓包工具直接看报文。为什么是WPF做Server、Unity做Client因为WPF是主程序Unity是被管理的一方。Unity启动后主动连过来WPF就能感知它的存活状态反过来让WPF去连UnityUnity一旦重启连接关系就全乱了。4.2 下行WPF把指令发给Unity协议格式很简单一行一条JSON{cmd: setState, deviceId: 12, state: running} {cmd: setParam, deviceId: 12, param: temperature, value: 75.5}WPF侧在ViewModel里组装字符串通过TcpClient写入。注意写入要加换行符作为帧分隔符Unity侧的StreamReader.ReadLine刚好能一行一行读。Unity侧接收逻辑也不复杂一个后台线程ReadLine读到内容后压入带锁的Queue在主线程Update里消费。千万别在后台线程里直接动GameObject和场景Unity大部分API不是线程安全的直接调会随机崩溃这种崩溃还特别难复现。4.3 上行Unity把事件回报给WPF三维场景里的设备被点击、状态动画播完、场景加载完成这些都要由Unity主动报给WPF{evt: deviceClicked, deviceId: 12} {evt: sceneReady}WPF收到后用Dispatcher.BeginInvoke切回UI线程再更新ViewModel。这里有个顺序细节如果用户点了场景里的一个设备Unity的点击事件先到WPF的高亮逻辑最好等Unity把摄像机聚焦动画播完再刷新状态不然会出现状态栏先变、画面后动的割裂感。所以我在协议里加了个ack字段让Unity播完动画再发事件把时序压力放在事件源一侧。4.4 心跳与断线自愈协议里加了heartbeatUnity每5秒发一次{evt:heartbeat}WPF侧用一个定时器检查超过15秒没收到就认为Unity场景卡死或崩溃。这时候弹出占位提示并自动重启Unity进程新进程启动后重新连接TCP重新上报sceneReadyWPF这边重新挂载状态。这套机制在交付后救了我好几次——现场显卡驱动的坑、长时间运行内存泄漏的坑都会让Unity进程静默死掉有了自愈用户基本无感知。5. 生产环境实测焦点、DPI、黑屏这些坑怎么填5.1 焦点嵌入后键盘鼠标抢不过主窗口Unity窗口被SetParent嵌入后鼠标点击基本能命中但键盘输入经常还是留在WPF这边场景里的快捷键和文本输入就失灵了。处理分两步Unity侧脚本自行处理所有交互鼠标点击事件通常没问题WPF侧在PreviewMouseDown里检测鼠标落在UnityHost区域时主动调SetFocus把键盘焦点交给Unity窗口。我实测下来鼠标点击后再SetFocus是最自然的不会误伤正常界面操作。5.2 DPI缩放别让Unity画面变成糊的WPF在.NET Framework 4.7以上默认跟随系统DPI一旦用户把显示缩放调成125%、150%嵌入的Unity窗口的坐标和尺寸就会出现偏差画面要么模糊要么被裁切。根因是WPF和Unity两个进程的DPI Awareness设置不一致导致系统给出的窗口尺寸不在同一个坐标系里。我的处理方式是在app.manifest里把WPF进程也声明成和Unity一致的DPI感知级别然后在WM_DPICHANGED里根据新的缩放比重新MoveWindow。如果项目工期紧最省事的方案是WPF进程不做PerMonitorV2全部走系统DPI虽然跨屏显示时会拉伸但至少不会出现嵌入式窗口和主界面脱节这种一眼假的问题。5.3 黑屏与合成问题最小化还原、窗口遮挡黑屏问题我遇到过三种来源。一是Unity窗口最小化后再还原交换链没有自动重建画面卡在最后一帧或直接黑掉处理办法是在WPF的StateChanged事件里检测到恢复后调ShowWindowAsync(_unityHwnd, SW_RESTORE)再MoveWindow一次。二是WPF窗口设置了AllowsTransparencyTrue再配合HwndHost会导致子窗口的透明合成失效画面出现黑块这个特性用不了就果断关。三是显卡驱动切换导致子进程渲染上下文失效这类问题没有通用解法只能靠心跳自愈兜底。5.4 帧率控制与资源占用嵌入场景里Unity默认跑满帧率非常浪费。我在Unity侧做了分级场景无交互时Application.targetFrameRate设为15有操作或动画播放时切到60工业监控场景完全够用。另外vSyncCount设为0不让Unity的垂直同步去跟Unity窗口对齐嵌入场景里垂直同步反而会引入额外延迟。还要留意显存。WPF主程序本身会用一些GPU资源Unity再占一块现场机器如果只有核显建议Unity侧质量等级调低一档抗锯齿开2x就够了工业场景的观感差距不大但帧率稳很多。5.5 子进程崩溃后的恢复表现最后梳理一遍崩溃恢复的完整链路WPF定时器发现心跳超时标记UnityHost为异常显示三维场景加载失败正在恢复的占位面板Kill残留进程重新启动Unity并等待新窗口句柄新进程连上TCP后重新订阅事件。整套流程控制在8秒内用户基本只看到画面闪了一下。这套东西从需求下来到上线中间推倒重来了一次最终定型的就是上面这套架构。每次Unity进程崩掉又被自动拉起来的时刻我都会想如果当初图省事用WindowsFormsHost或者进程内加载现在大概率还在给客户擦屁股。工程和demo之间的距离往往就是这些万一出事怎么办的考虑。本文还有配套的精品资源点击获取