简介：这份资源是一套基于 Unity 引擎与 C# 语言、结合 Lean Touch 插件实现触摸屏物体识别桌的完整项目源码与工程文件，面向需要开发互动式桌面、AR/VR 触控交互的 Unity 开发者。资源以 zip 压缩包形式提供，共 3640 个文件，包含 220 个 C# 脚本、106 个 dll 库、370 个 bin 资源、31 个场景文件、12 个 prefab 预设体以及 shader、材质、贴图等美术与配置资源，包体大小约 24.54MB。目前已有 2442 人学习下载。通过该资源可以学习 Lean Touch 插件的导入与监听器设置、基于 Physics.Raycast 的物体拾取识别、触摸坐标与射线投射的转换逻辑、UI 交互处理及性能优化方法，帮助快速搭建可复用的触摸屏物体识别桌系统。
1. 触摸桌面不只是点按钮：物体识别桌为什么绕不开 Unity 与 C#
把手机、积木、卡片往桌上一放，桌面就能“认出”放的是什么东西，还能跟着手势拖拽、缩放、旋转——这套体验在展厅、互动教育、医疗康复和工业展项里出现得越来越频繁。做这类 Unity 触摸屏物体识别桌，核心技术栈基本固定：Unity 负责渲染和交互，C# 负责业务逻辑与底层通信，触摸屏提供多点触控输入，物体识别则依赖视觉算法或 RFID 等物理标识。换句话说，这不是一个“用 Unity 做个界面”的活，而是要把触摸输入、识别结果、3D 场景三者实时串起来。
我见过不少团队在这个标题上翻车：有的把识别算法跑在服务端，结果触摸屏上交互延迟高到没法用；有的用了第三方识别 SDK，却忽略了 Unity 的坐标系和触摸屏原生坐标系的转换，导致物体放上去，虚拟模型偏移半个桌面的距离。这篇文章我把一套能落地的方案拆开讲：从触摸屏坐标怎么进 Unity，到物体识别用视觉方案还是物理标识方案怎么选，再到 C# 层的数据结构和性能优化，最后是必踩的坑。目标是让你照着搭，能在三天内跑出一个能演示、能交付的原型。
2. 先把输入链路打通：触摸屏坐标到 Unity 世界的三次变换
2.1 为什么不能直接拿 Input.touchPosition 当桌面坐标
Unity 里拿触摸点的标准做法是Input.GetTouch(0).position，这个值是以屏幕像素为单位的 UI 坐标，左下角为原点，y 轴向上。但触摸屏物体识别桌的物理结构是：摄像头或传感器在桌面下方或上方，识别算法给出一组物体的像素坐标，而触摸屏本身可能有独立的触控分辨率。两者如果不做统一，就会出现“手指按在 A 点，识别框却在 B 点”的错位。
常见的触摸屏一体机，触控分辨率和屏幕显示分辨率不一定一致。比如一块 43 寸的电容触摸屏，显示分辨率是 1920x1080，但触控 IC 上报的原始分辨率可能是 32767x32767，系统驱动会做一次线性映射。Unity 拿到的Input.touchPosition已经是映射到显示分辨率之后的值，但仍然是以屏幕左上角为原点的像素坐标。而物体识别算法（比如 OpenCV 或深度学习模型）输出的物体中心点，通常是以图像左上角为原点、以图像像素尺寸为单位的坐标。如果摄像头画面分辨率是 1280x720，而屏幕是 1920x1080，直接从图像坐标映射到屏幕坐标，x 和 y 都要乘一个比例系数，而且 y 轴方向要翻转。
我一般会在 C# 里写一个CoordinateMapper类，专门处理这三套坐标：摄像头图像坐标、屏幕像素坐标、Unity 世界坐标。不要在业务逻辑里到处做坐标换算，否则后面调识别参数和触摸校准时会非常痛苦。
2.2 一个可复用的坐标映射组件：代码与参数说明
using UnityEngine; /// <summary> /// 触摸屏物体识别桌坐标映射器 /// 处理摄像头图像坐标 -> 屏幕像素坐标 -> Unity世界坐标 的变换 /// </summary> public class CoordinateMapper : MonoBehaviour { [Header("摄像头参数")] public Vector2 cameraResolution = new Vector2(1280f, 720f); [Header("屏幕显示参数")] public Vector2 screenResolution = new Vector2(1920f, 1080f); [Header("Unity桌面区域")] // 桌面在Unity世界中的矩形区域，单位：米 public Vector2 desktopWorldSize = new Vector2(1.2f, 0.8f); public Vector2 desktopWorldCenter = Vector2.zero; /// <summary> /// 将摄像头图像坐标（左上角原点，y向下）转为屏幕像素坐标（左下角原点，y向上） /// </summary> public Vector2 CameraImageToScreenPixel(Vector2 cameraPos) { float normalizedX = cameraPos.x / cameraResolution.x; // 图像坐标y向下，屏幕坐标y向上，需要翻转 float normalizedY = 1f - (cameraPos.y / cameraResolution.y); float screenX = normalizedX * screenResolution.x; float screenY = normalizedY * screenResolution.y; return new Vector2(screenX, screenY); } /// <summary> /// 将屏幕像素坐标转为Unity世界坐标 /// </summary> public Vector2 ScreenPixelToWorld(Vector2 screenPos) { float normalizedX = screenPos.x / screenResolution.x; float normalizedY = screenPos.y / screenResolution.y; float worldX = desktopWorldCenter.x + (normalizedX - 0.5f) * desktopWorldSize.x; float worldY = desktopWorldCenter.y + (normalizedY - 0.5f) * desktopWorldSize.y; return new Vector2(worldX, worldY); } /// <summary> /// 摄像头图像坐标直接转Unity世界坐标，一步到位 /// </summary> public Vector2 CameraImageToWorld(Vector2 cameraPos) { Vector2 screenPixel = CameraImageToScreenPixel(cameraPos); return ScreenPixelToWorld(screenPixel); } }这段代码解决的是“识别算法给的坐标”和“Unity 场景里物体位置”的关系。逻辑分两层：先把摄像头图像坐标归一化到 0~1，再映射到屏幕像素；然后把屏幕像素归一化，映射到 Unity 世界坐标。两个步骤分开写的好处是，你可以随时检查是哪一层出了问题。比如触摸屏显示正常但物体位置偏移，就要怀疑是cameraResolution和实际视频流分辨率不匹配；如果连手指触摸都不准，那要查的是触摸屏驱动校准，而不是这段代码。
参数设置上有两个容易被忽略的细节。第一，cameraResolution必须填实际视频流的分辨率，不是摄像头的最大分辨率。很多 USB 摄像头在 Unity 里通过WebCamTexture拿到的分辨率默认是 640x480，而你设了 1280x720，映射必然错位。第二，desktopWorldSize和实际桌面物体放置区域的物理尺寸要对上。如果桌面上物体识别有效区域是 1.2 米 x 0.8 米，就按这个填，识别到的物体才能和真实桌面一一对应。
2.3 多点触摸与物体拖拽：识别框和手指的配合
物体识别桌的交互不只是“放上去识别”，更多的场景是“识别出来后用手指拖拽、旋转”。这里有一个关键问题：识别算法给的是物体中心点和轮廓，但手指触摸给的是触点。C# 里要把这两者关联起来，我常用的做法是做一个TouchObjectBinder脚本，每一帧检测是否有触摸点落在某个已识别物体的包围盒内，如果有就把这个触摸点的 ID 和物体绑定，直到该触摸点抬起。
using System.Collections.Generic; using UnityEngine; public class TouchObjectBinder : MonoBehaviour { public float touchRadius = 100f; // 屏幕像素单位，触摸点命中物体的判定半径 private Dictionary<int, RecognizedObject> _bindingMap = new Dictionary<int, RecognizedObject>(); void Update() { // 先处理新按下的触摸 for (int i = 0; i < Input.touchCount; i++) { Touch touch = Input.GetTouch(i); if (touch.phase == TouchPhase.Began) { TryBindObject(touch.fingerId, touch.position); } else if (touch.phase == TouchPhase.Ended || touch.phase == TouchPhase.Canceled) { _bindingMap.Remove(touch.fingerId); } else if (touch.phase == TouchPhase.Moved) { if (_bindingMap.ContainsKey(touch.fingerId)) { RecognizedObject obj = _bindingMap[touch.fingerId]; obj.transform.position = Camera.main.ScreenToWorldPoint( new Vector3(touch.position.x, touch.position.y, 10f)); } } } } private void TryBindObject(int fingerId, Vector2 touchPos) { // 遍历当前所有已识别物体，找到距离最近且小于touchRadius的 RecognizedObject[] allObjects = FindObjectsOfType<RecognizedObject>(); RecognizedObject nearest = null; float minDist = float.MaxValue; foreach (RecognizedObject obj in allObjects) { Vector3 screenPos = Camera.main.WorldToScreenPoint(obj.transform.position); float dist = Vector2.Distance(touchPos, screenPos); if (dist < touchRadius && dist < minDist) { minDist = dist; nearest = obj; } } if (nearest != null) { _bindingMap[fingerId] = nearest; } } }这段代码的逻辑核心是fingerId的绑定关系。Unity 的多点触摸里，每个触摸点从按下到抬起都有独立的fingerId，用字典维护绑定关系，能避免两根手指同时操作两个物体时互相干扰。touchRadius的取值要看屏幕尺寸和物体在屏幕上显示的大小，43 寸屏、1080p 分辨率下我一般取 80~120 像素，太小了用户不容易点中，太大了会跟旁边物体误绑定。
注意ScreenToWorldPoint的 z 值。桌面场景里的识别物体通常在 XY 平面上，如果相机的视角是正交俯视，z 传 10f 或任意正值都能正确换算，因为正交相机不看深度；如果用透视相机，这个 z 值必须等于物体所在平面到相机的距离，不然算出来的世界坐标会偏。这个坑我踩过，在透视相机下传了 0 值，物体全跑到相机位置附近去了。
3. 物体识别方案选型：视觉算法、RFID 还是两者的混搭
3.1 纯视觉识别：从 OpenCV 模板匹配到轻量级分类模型
物体识别桌最“通用”的方案是纯视觉。摄像头架在桌面正上方，俯拍整个桌面，识别算法在图像里找到目标物体并输出类别和位置。对开发 Unity 的团队来说，最常见的落地路径是 OpenCV 的模板匹配加轮廓检测，适合识别形状规则、纹理清晰的物体，比如积木块、数字卡片、动物卡片。
模板匹配的原理很简单：把每个要识别的物体拍一张模板图，在摄像头实时画面里滑动匹配，找到相似度最高的位置。OpenCV 的matchTemplate配合minMaxLoc能拿到匹配位置和分数。但这个方案的短板也很明显：光照一变、物体稍微旋转、部分遮挡，匹配分数立刻掉下来。所以做产品的团队一般不会只靠模板匹配，而是用轮廓特征或轻量级分类模型。
如果物体是印刷卡片，我建议用 ArUco 码或 AprilTag 辅助识别。在卡片角落打印一个码，识别算法先找码，再根据码的 ID 和位姿推算卡片的类型和朝向。这样做同时解决了“识别是什么”和“识别在哪、朝向哪”两个问题。OpenCV 的aruco模块在 C# 里可以通过 OpenCVSharp 或 Unity 的 OpenCV for Unity 插件调用，性能足够跑实时。
识别到物体后，需要把结果传给 C# 层。视觉算法如果跑在 PC 上，可以直接在同一个进程里用 C# 调用 OpenCVSharp，省去通信开销；如果跑在独立的边缘设备或 Android 平板上，就要走 TCP、UDP 或共享内存。我做过一个方案里摄像头在桌面上方，算法跑在独立的 Mini PC 上，通过 UDP 把“物体 ID + 中心点像素坐标 + 旋转角度”广播给 Unity 客户端，单包小于 100 字节，延迟在 5ms 以内。
3.2 RFID 与 Near-Field 方案的取舍：什么时候别用视觉
视觉方案不是万能的。有些物体外形极其相似，只是内部数据不同，比如不同药品的瓶子、不同批次的零件；有些场景要求识别结果不受遮挡影响，比如手盖住了物体的一半；有些场景的光照条件不可控，比如户外互动装置。这时候视觉方案的准确率和稳定性都会出问题，RFID 就成了更务实的选择。
RFID 识别桌的典型架构是：桌面下方或边缘埋一圈 RFID 天线，每个被识别的物体底部贴一个 RFID 标签，标签里写入物体 ID。C# 通过串口或 USB 连接 RFID 读写器，读写器上报标签 ID 和信号强度，Unity 根据标签 ID 在场景里生成对应模型。这个方案的好处是识别几乎不受光照和遮挡影响，误识别率极低，坏处是你需要给每个实体物体贴标签，而且 RFID 天线有感应区域，物体要放在特定范围内才能读到。
如果你做的是几十种物体以内的互动桌，视觉方案更灵活，因为实体物体不需要预埋任何东西；如果物体种类超过一百种，或者物体之间长得非常像，RFID 的稳定性会让你少掉很多头发。还有一条中间路线：视觉负责粗定位，RFID 负责精确身份确认。比如摄像头判断物体的大致位置，RFID 读数确认这个位置上的具体标签 ID，两者在 C# 层做融合。
3.3 算法进程与 Unity 的通信协议设计
无论视觉还是 RFID，识别数据进 Unity 都需要一个清晰的数据结构。C# 和算法进程之间的通信，我推荐用 JSON over UDP。UDP 虽然不保证送达，但识别桌场景在局域网内丢包率极低，而且它的延迟比 TCP 的 Nagle 算法和重传机制稳定得多。你要是用 TCP，万一算法进程卡了一下，积压的数据包会让 Unity 端出现“物体位置瞬移”的诡异表现。
using System; using System.Net; using System.Net.Sockets; using System.Text; using UnityEngine; [Serializable] public class RecognitionResult { public int objectId; public float x; // 归一化坐标 0~1，左上角原点 public float y; // 归一化坐标 0~1，左上角原点 public float rotation; // 度 public float confidence; // 0~1 } public class RecognitionUdpReceiver : MonoBehaviour { public int listenPort = 29001; private UdpClient _udpClient; private RecognitionResult[] _latestResults = new RecognitionResult[0]; void Start() { _udpClient = new UdpClient(listenPort); _udpClient.BeginReceive(OnReceive, null); } private void OnReceive(IAsyncResult ar) { IPEndPoint remoteEndPoint = new IPEndPoint(IPAddress.Any, 0); byte[] data = _udpClient.EndReceive(ar, ref remoteEndPoint); string json = Encoding.UTF8.GetString(data); try { _latestResults = JsonHelper.FromJsonArray<RecognitionResult>(json); } catch (Exception e) { Debug.LogWarning("识别结果解析失败: " + e.Message); } _udpClient.BeginReceive(OnReceive, null); } void Update() { // 在Unity主线程中消费_latestResults foreach (RecognitionResult result in _latestResults) { // 用CoordinateMapper转成世界坐标并更新对应物体 } } void OnDestroy() { _udpClient.Close(); } }这里有个重要的 C# 陷阱：UdpClient.BeginReceive的回调是异步线程，不能在里面直接操作 Unity 的 Transform 或 GameObject，否则 Unity 会报UnityException: get_transform can only be called from the main thread。我的做法是回调里只解析数据并存入字段，Update主线程里再消费。上面代码里的JsonHelper.FromJsonArray是因为 Unity 自带的JsonUtility不支持直接解析 JSON 数组，需要包一层 wrapper 或者用第三方库如 Newtonsoft.Json。
通信协议的数据字段里，confidence这个参数很多团队会忽略。实际做产品时，它不只是拿来显示“识别置信度”，更关键的是用来做防抖：如果连续几帧的confidence都低于阈值，就判定物体已被移走或遮挡，Unity 端隐藏对应的虚拟模型。阈值我一般设在 0.6 到 0.7 之间，低于 0.6 的识别结果基本都是误检，直接丢弃比展示出来更稳妥。
4. C# 业务层架构：从识别结果到桌面交互的粘合层怎么组织
4.1 不要把所有逻辑堆在 MonoBehaviour 里
很多从教程起步的开发者习惯把识别结果处理、物体生成、拖拽逻辑全写在一个脚本的Update里。在物体识别桌这种场景下，物体数量可能有几十个，加上触控、特效、音效，单个脚本会膨胀到上千行，调试和维护都很痛苦。用 C# 面向对象的方式拆一层，会让整个项目清晰很多。
我一般会拆成四层：
第一层是数据模型层，定义RecognizedObject类，包含物体 ID、显示名称、Prefab 引用、当前的识别置信度、绑定的触摸 ID 等。第二层是识别数据接入层，就是前面写的 UDP 接收器，只负责解析和缓存识别结果。第三层是对象管理服务层，一个ObjectSpawnManager单例或可注入的服务类，负责根据识别结果创建、更新、销毁场景里的物体。第四层是交互控制层，处理触摸拖拽、旋转、缩放。
using UnityEngine; public class RecognizedObject : MonoBehaviour { public int objectId; public string displayName; public float confidence; public bool isActive = true; private Vector3 _targetPosition; private Quaternion _targetRotation; public void UpdateFromRecognition(Vector3 worldPos, float angle, float newConfidence) { _targetPosition = worldPos; _targetRotation = Quaternion.Euler(0f, 0f, angle); confidence = newConfidence; } void Update() { // 平滑跟随识别结果，避免位置跳变 transform.position = Vector3.Lerp(transform.position, _targetPosition, 0.15f); transform.rotation = Quaternion.Slerp(transform.rotation, _targetRotation, 0.15f); } }Vector3.Lerp的插值系数 0.15 是经验值。系数太小物体移动有拖影感，太大则会显得生硬。识别算法的帧率在 15~30FPS 时，0.10~0.20 之间都会有不错的效果；如果算法在 60FPS 以上，可以适当调到 0.3 左右。这个参数要留出来方便调整，不同算法帧率下最优值差异挺大。
这里的UpdateFromRecognition是给识别数据层调用的，不直接改transform.position，而是先存目标位置，在Update里做平滑。为什么这么做？因为识别算法输出的坐标是带抖动的，物体静止时中心点也可能有正负几像素的波动，直接赋值会导致虚拟模型在桌面上高频颤动。用 Lerp 做一个低通滤波，视觉上会舒服得多。
4.2 对象池：物体反复出现和消失时防止 GC 卡顿
识别桌的典型交互是用户拿走一个物体，再放回来，再拿走。每次识别结果里新增一个物体就去Instantiate，消失就Destroy，这在短时间内反复发生会让 Unity 的 GC（垃圾回收）压力很大。对象池是解决这个问题的标准手段。
using System.Collections.Generic; using UnityEngine; public class ObjectPool : MonoBehaviour { public GameObject prefab; public int prewarmCount = 10; private Queue<GameObject> _pool = new Queue<GameObject>(); void Start() { for (int i = 0; i < prewarmCount; i++) { GameObject obj = Instantiate(prefab, transform); obj.SetActive(false); _pool.Enqueue(obj); } } public GameObject Get() { if (_pool.Count > 0) { GameObject obj = _pool.Dequeue(); obj.SetActive(true); return obj; } else { return Instantiate(prefab, transform); } } public void Return(GameObject obj) { obj.SetActive(false); _pool.Enqueue(obj); } }对象池的prewarmCount等于桌面上可能出现的最多物体数量。这个值要根据玩法定：如果桌面上最多同时放 20 个识别物，就预创建 20 个；如果评估不了，可以设一个比实际需求多 30% 的冗余值。池子的物体都挂在空节点ObjectPool下，场景层级会干净很多。
真正要注意的是：从池子里取出的物体，OnEnable时要做状态重置。比如一个物体曾经被旋转过角度、缩放过大，重新放到桌面上时应该恢复默认。我习惯在RecognizedObject里加一个ResetState()方法，在ObjectPool.Get()返回前调用。不然会出现回到桌上的物体悬空在之前被拖拽的位置、尺寸放大缩小不一致的怪象。
4.3 识别生命周期管理：出现、消失、持续存在三种状态
识别桌和普通点击交互最大的不同是物体有“存在性”的概念。视觉算法并不是每帧都能稳定检测到所有物体，可能某物体被手短暂遮挡了 0.5 秒，算法没输出，Unity 端就把模型隐藏了，用户体验就是物体闪了一下消失又出现。这需要一套生命周期管理：LostTimer机制来判断物体是真的被拿走，还是暂时被遮挡或被误检遗漏。
具体做法是为每个已识别的物体记录lastSeenTime。每帧更新时，如果在新的识别结果里找到了这个物体，就更新lastSeenTime并刷新状态；如果没找到，不立即隐藏，而是等一个延迟时间（比如 1.5 秒）后再隐藏。超过延迟时间仍未出现，才判定物体已离桌。这个延迟时间的设置要权衡：设太短，手晃动一下就闪；设太长，物体被拿走了一分多钟，虚拟模型还挂在那儿，很尴尬。室内互动场景 1.2~2 秒是安全区间。
C# 实现时我习惯写一个RecognitionTracker类，内部维护Dictionary<int, TrackedObjectState>，每个状态包含物体引用、lastSeenTime、pendingRemovalTime。每一帧按上面的规则更新状态，到期未见的物体才回收到对象池。这套逻辑直接解决了多物体、低帧率识别场景下最常见的“幽灵物体”问题。
5. 避坑排查：识别桌项目里 4 个高频翻车现场与解决方案
5.1 现象：手指触摸和识别物体位置对不上，越往边缘偏得越多
这是识别桌项目里出现频率最高的问题。原因基本出在坐标映射的线性假设上。很多廉价电容触摸屏的边缘存在非线性畸变，触摸 IC 给出的坐标在中心区域是准的，越靠近边缘偏差越大。另外摄像头的镜头如果是广角镜头或鱼眼镜头，画面边缘畸变更严重，直接用线性映射当然会偏。
解决分两步。第一步，如果用的是广角镜头，先在算法侧做去畸变处理，OpenCV 里用cv2.undistort配合标定得到的畸变系数k1, k2, p1, p2。第二步，在 Unity 侧做触摸校准：让用户在屏幕上依次点几个已知位置的点，记录触摸上报值和实际显示值的偏差，用二次多项式拟合修正。这个校准文件可以序列化成 JSON 存到Application.persistentDataPath下，每次启动时读取。不要用 PlayerPrefs 存，校准数据量大而且结构复杂，JSON 文件更合适。
5.2 现象：物体放上去反应慢，识别结果要 1 秒以上才更新
识别桌的“反应慢”往往不是摄像头的帧率问题，而是识别算法本身的处理耗时。模板匹配在 1080p 画面下做全图搜索一次可能要 100~300ms，再加上客户端的显示同步，就感觉特别拖沓。
解决思路是缩小识别区域，而不是降低识别频率。因为物体只会出现在桌面范围内，摄像头画面里桌面以外的区域对识别没有任何意义，截掉反而能提升精度。另一个办法是降低摄像头实际处理的分辨率。物体识别不是拍照，720p 甚至 540p 足够识别大尺寸的积木或卡片，将图像缩小到原来的 1/4，处理时间能降到 30ms 以内。我做过一个项目里，识别算法原跑 1080p 需要 200ms，降到 720p 后只需要 60ms，准确率几乎没变化。
5.3 现象：Unity 里物体抖动厉害，像得了帕金森
抖动主要来自三方面：识别算法输出坐标的随机波动、相机硬件噪声、以及代码里直接赋值。前面说的 Lerp 平滑能解决一部分，但如果物体是静止的，Lerp 只是让它在目标位置附近无限逼近，仍然会有微小的残差抖动。
我的做法是加一个死区阈值：当目标位置和当前位置的距离小于0.005f米（5 毫米）时，直接让物体停在当前位置，不再做插值。这个阈值对应到物理桌面上是非常小的距离，视觉上完全察觉不到，但它能消除绝大多数静止状态的微抖。另外，如果识别算法支持输出多帧平均值或卡尔曼滤波，建议在算法侧就做，不要再依赖 Unity 端弥补。我把低调放到算法侧，把 Unity 端的 Lerp 保留作为最后的平滑兜底。
5.4 现象：物体识别正确，但拖拽起来不跟手，有滞后感
识别桌的拖拽和 UI 按钮的拖拽体验要求不一样。UI 拖拽是即时响应的，因为触点坐标就是手指位置；但物体识别桌的拖拽，是“手指碰到虚拟模型”然后将模型移动到触摸点。滞后的根源是触摸事件的处理顺序：默认情况下，物体模型的位置更新在Update里执行，但触摸事件读取也在同一帧的同一阶段，如果识别结果的更新把模型移到了别处，触摸坐标和模型位置就产生了偏离。
解决方法是把拖拽逻辑放到LateUpdate里执行。LateUpdate在所有Update执行完之后才跑，此时所有识别结果和模型位置都已更新完毕，触摸坐标再覆盖到模型位置上就不会产生帧内冲突。同时，拖拽期间要暂停识别结果的坐标回写。我在RecognizedObject里加了一个isDragging标志，拖拽中UpdateFromRecognition只更新 ID 和置信度，不更新位置，等手指抬起后恢复。这个细节不处理，就会出现手指拖着模型，模型还在被识别结果往回拽的拉锯感。
6. 进阶落地技巧：识别结果的置信度滤波与多桌联动扩展
项目跑通基础流程以后，再往下做就要考虑识别稳定性和系统架构的扩展。置信度滤波是最值得优先做的：不要单帧判定，而是用滑动窗口。我常用的做法是记录每个物体最近 5 帧的置信度，只有当超过 3 帧的置信度大于阈值时才确认这个物体“有效”。这样能过滤掉摄像头画面里一闪而过的干扰物，比如手影、反光点。同时把滤波后的置信度显示在 UI 上，调试时能直观地看到算法在什么条件下会丢帧，比对着日志猜高效得多。
多桌联动是这类项目商业化常见的需求：一个展厅里放三张识别桌，每张桌上识别不同物体，但内容要投射到同一块大屏或同一个 Unity 场景里。这时不要每张桌子单独跑一个 Unity 实例，而是每张桌子的客户端只做输入采集和识别，将结果汇总到一个主控 Unity 实例。通信协议可以沿用前面提到的 JSON over UDP，只是在数据字段里加一个tableId。主控端按tableId分容器管理物体，每张桌子的识别结果互不干扰。这样加一张桌子，只需要配置新桌子的tableId和网络地址，主控端代码一行都不用改。
最后一个调试技巧我一定会集成到项目里：在 Unity 场景中加一个 Debug 面板，实时显示当前收到的识别结果数量、每帧置信度均值、坐标映射偏差值。这个面板在开发阶段默认开启，交付时通过 PlayerPrefs 或启动参数关闭。依赖日志输出做调试在识别桌项目里非常低效，因为问题往往出现在视觉上可感知但日志里不可见的地方——物体歪了 2 厘米、模型抖了一下、触摸晚了一帧。可视化调试面板能把这些瞬态问题变成可观察、可复现的现象，省下的调试时间远超写面板的时间。做识别桌这几年我最大的体会是：调试工具和识别算法本身一样重要。希望这套从坐标映射到生命周期管理再到排错的方法，能让你少走几段我走过的弯路。
本文还有配套的精品资源，点击获取
