直接进入正题。前阵子接了个移动端手势交互的功能要在相机预览画面里做双指缩放、双指旋转、长按拖拽这些操作。功能写起来不算难但调试过程真是把我折磨得够呛——每次改一个参数都要打包到真机装包、打开、复现、看日志一个来回就是几分钟。后来我决定在Unity Editor里把多点触控这件事彻底解决掉于是就有了这篇文章。这里说的旧式Input系统就是咱们常年用的Input.GetTouch、Input.touches这一套不是新Input System那个自带Touchscreen模拟反而简单很多。我会分享一套基于旧式Input的Editor模拟方案包括整体思路、完整代码、状态机设计还有我踩过的那些坑希望能让看这篇文章的人少走点弯路。1. 为什么要在Editor里模拟多点触控1.1 移动端手势调试的典型困境先说说我遇到的具体场景。项目用Unity 2021旧式Input系统核心交互是双指捏合缩放和双指旋转这两个手势都依赖Input.touchCount 2来判断。在PC上开发时鼠标只有一个指针位置也没有触摸相位TouchPhase的概念所以Input.touchCount永远是0手势代码根本不进分支。常规做法是打印日志到手机上看或者接Device Simulator之类的外部工具。但Device Simulator解决的是屏幕适配模拟它并不直接模拟触摸输入还有些第三方插件能注入触摸事件但多数依赖新Input System或者需要打包后通过数据线回传配置成本不低。我就想要一个最朴素的方案在Editor的Play Mode下用鼠标键盘模拟出多点触摸的事件流让我的手势代码像在真机上一样跑起来。这套方案适合谁如果你正在用旧式Input开发移动端手势、UI拖拽、地图缩放这类功能又不希望每次验证都打包真机那下面这套思路可以直接抄作业。它不需要额外的SDK也不需要新Input System纯C#就能完成。1.2 旧式Input系统的触摸数据模型要模拟就得先搞明白我们要模拟的是什么。旧式Input系统里触摸输入以Touch结构体的数组形式暴露通过Input.touches获取每帧更新。Touch结构体的关键字段有这些fingerId手指的唯一ID。从0开始手指按下时分配抬起后这个ID可能被复用。position触摸位置屏幕像素坐标原点在屏幕左下角。deltaPosition相对于上一帧的位置变化量手势识别主要靠它判断移动方向。deltaTime从上一帧到当前帧的时间差。phase触摸相位有Began、Moved、Stationary、Ended、Canceled五种。tapCount点击次数用于区分单击、双击。radius、pressure触摸面积和压力一般用得少。这里最重要的就是phase的状态流转。一个真实的手指从接触屏幕到离开会经历Began - Moved/Stationary - Ended这个过程。如果你的代码里写了if (touch.phase TouchPhase.Began)那模拟器就必须在某一帧准确给出Began否则逻辑永远走不到。很多所谓的模拟方案只是把鼠标位置塞进去相位处理得一塌糊涂导致手势代码判断混乱。另一个容易忽略的点是deltaPosition。Unity的手势识别库比如自己写的缩放逻辑依赖deltaPosition来计算两指间距的变化量如果你的模拟器每帧都手抖或者坐标跳动识别出来的缩放系数就会很奇怪。所以模拟的核心不只是“给一个触摸点”而是要完整模拟出一个触摸点的生命周期。2. 整体方案设计2.1 核心思路做一层可替换的输入访问层既然旧式Input在Editor下无法直接注入触摸数据那就换个思路不直接碰Input类而是在项目代码和Input之间插一层“输入访问层”。业务逻辑不直接调Input.touchCount、Input.GetTouch而是调我们自定义的接口。在真机上这个接口内部转发给Input类在Editor里它转发给模拟器。这个思路其实很朴素但它是整套方案的地基。好处有三点一是业务代码完全无感手势识别逻辑不用改二是模拟器只在Editor下生效打包后自动关掉不影响真机行为三是如果以后项目迁移到新Input System只需要改这一层的内部实现所有手势代码不用动。实际编码时我建议把这一层做成静态类命名空间和项目名匹配即可。不要用单例MonoBehaviour来做因为静态类在场景切换、加载顺序上更可控也不会因为某个场景忘记挂组件导致空引用。2.2 为什么不建议直接去改Input类有人可能会想能不能用反射直接往Input内部塞触摸数据我试过结论是不要这么做。旧式Input的数据源在Unity引擎的C原生层C#这边拿到的只是一个只读镜像。反射可以拿到一些内部方法但那些方法大多没有文档Unity版本一升级就崩而且安卓、iOS、Editor各平台内部实现还不同维护成本极高。还有人说可以伪造一个和Input同名的类放到程序集前面让编译器优先引用。这个做法更危险因为它会污染全局命名空间而且Unity的脚本编译顺序是分程序集的UnityEngine.Input在UnityEngine.CoreModule里优先级比用户脚本高得多实际根本替换不了。所以老老实实做输入访问层是性价比最高的方案。它看起来没有“黑科技”那么炫酷但不会半夜被线上bug叫醒。2.3 模拟器结构概览模拟器整体分成三层模拟手指管理层负责创建、销毁、更新虚拟手指的状态每根手指有独立的ID、位置、相位。输入映射层把鼠标键盘操作翻译成手指操作。比如鼠标左键当成第一根手指按住Ctrl时鼠标左键当成第二根手指。兼容读取层对外暴露和Input类似的API比如TouchCount、GetTouch(int index)。整体流程是每一帧先读鼠标键盘状态更新所有虚拟手指的位置和相位生成Touch结构体列表然后让访问层从这个列表里读数据。这个设计的优势在设计时就体现出来了鼠标键盘映射规则是可配置的以后想换成用触控板、用游戏手柄模拟都只需要改映射层不用动上层代码。3. 从零实现一个多点触控模拟器3.1 模拟手指的基础数据结构首先定义虚拟手指的类。它不是一个MonoBehaviour就是一个纯C#类用来管理一根“虚拟手指”的状态。public class SimulatedFinger { public int fingerId; public Vector2 position; public Vector2 previousPosition; public TouchPhase phase; public float beganTime; public int tapCount; public bool isActive; }这里每个字段都有实际意义。fingerId必须稳定在手指按下的整个生命周期内不能变否则手势代码里以fingerId为key的字典会频繁重建。previousPosition用来计算deltaPosition它记录的应该是上一帧的位置而不是上一帧之前的位置。beganTime是按下时刻的时间戳用于判断双击。tapCount则标记这根手指在当前点击序列里是第几次点击。在模拟器主体里我用一个ListSimulatedFinger来管理所有手指再用一个字典Dictionaryint, SimulatedFinger实现按ID快速查找。3.2 手指状态机从Began到Ended状态机是这一步的核心。我直接用一个Update循环推进所有虚拟手指的状态逻辑是检测到“按下”事件时如果当前没有对应fingerId的活跃手指就创建一个新的SimulatedFingerphase设为Began并追加到列表。在后续帧中如果位置发生了变化就把phase设为Moved如果位置没变化设为Stationary。检测到“抬起”事件时把phase设为Ended但不要立刻从列表里移除——因为Input系统在Ended这一帧依然会返回这根手指的数据手势代码还能在Ended阶段做收尾处理比如识别单击、判断拖拽结束。正确做法是保留一帧到下一帧再彻底移除。这个“延迟一帧移除”的细节特别重要。我之前就是直接把手指从列表里删了结果点击手势的Ended分支永远进不去后来加了一帧才正常。Canceled相位在模拟器里比较特殊通常出现在手机来电、系统手势打断的场景Editor里模拟不出来可以留空或者直接等同于Ended。状态机的完整代码大概是这样的public void UpdateFinger(SimulatedFinger finger, Vector2 currentPos, bool isPressed) { if (isPressed) { if (!finger.isActive) { finger.isActive true; finger.phase TouchPhase.Began; finger.position currentPos; finger.previousPosition currentPos; finger.beganTime Time.unscaledTime; } else { finger.previousPosition finger.position; finger.position currentPos; finger.phase (currentPos - finger.previousPosition).sqrMagnitude 0.0001f ? TouchPhase.Moved : TouchPhase.Stationary; } } else if (finger.isActive) { finger.phase TouchPhase.Ended; // 不立刻移出列表保留这一帧供上层读取 } }这里位移判断阈值用了sqrMagnitude 0.0001f对应约0.01像素的距离基本可以忽略鼠标的微小抖动又不会漏掉真实的移动。3.3 用鼠标加键盘映射多路触摸输入映射层的设计目标是使用鼠标模拟第一根手指同时按住一个键盘修饰键时鼠标模拟第二根甚至第三根手指。我的映射规则是这样的鼠标左键 第一根手指。Ctrl 鼠标左键 第二根手指用于双指手势。Alt 鼠标左键 第三根手指用于三指手势虽然不常用但留着扩展。Shift 鼠标左键 第四根手指。这个映射方案在实际操作中有一个大坑在Windows上Ctrl键和Alt键会触发编辑器菜单的快捷键。比如在Game视图里按Ctrl鼠标左键可能会触发“放大视图”之类的操作。解决方案是在模拟器初始化时把编辑器快捷键临时屏蔽或者在检测到映射组合时优先处理防止事件继续传递给编辑器。这块在后面的“常见坑”里我会细说。映射层的实现思路是每帧检查键盘状态决定当前有几根“手指”处于按下状态然后逐根调用UpdateFinger。void UpdateMappedInput() { bool finger1 Input.GetMouseButton(0); bool finger2 Input.GetMouseButton(0) Input.GetKey(KeyCode.LeftControl); bool finger3 Input.GetMouseButton(0) Input.GetKey(KeyCode.LeftAlt); bool finger4 Input.GetMouseButton(0) Input.GetKey(KeyCode.LeftShift); Vector2 mousePos Input.mousePosition; UpdateFinger(0, mousePos, finger1); UpdateFinger(1, mousePos, finger2); UpdateFinger(2, mousePos, finger3); UpdateFinger(3, mousePos, finger4); }注意finger2的判定里同时包含了Input.GetMouseButton(0)意思是如果不按住鼠标左键那么单单按Ctrl不会产生第二根手指。这样做是为了避免抬起鼠标时第二根手指还悬空。双指手势模拟的标准动作是先按住Ctrl不松再按住鼠标左键这时候两根手指同时处于活跃状态然后同时移动鼠标就会产生两指同步移动的效果两指之间的相对位置是固定的。如果你需要模拟两指靠拢或分开捏合就需要让两个虚拟手指的位置不再完全等于鼠标位置而是以鼠标位置为中心根据某个变量比如滚轮或特定按键来动态调整两指的间距。这个我在后面会补充实现。3.4 坐标转换与Editor视图适配触摸坐标用的是屏幕像素坐标左下角为原点x向右增加y向上增加。而Unity Editor的Game视图如果开启了“Scale”或者其他UI缩放模式鼠标在Game视图内的坐标和Input.mousePosition可能对不上尤其是在设置了Canvas的屏幕适配之后。最稳妥的做法是直接使用Input.mousePosition作为模拟触摸位置不经过任何UI坐标转换。因为Input.mousePosition返回的本身就是屏幕坐标在Game视图里它就是最终游戏的屏幕分辨率坐标和你真机上Touch.position拿到的是同一套坐标系。如果你的UI是Screen Space - Overlay模式直接在自适应逻辑里用Screen.width和Screen.height换算即可。这里有一个之前坑过我的地方如果用Event.current.mousePosition去取鼠标位置拿到的坐标是GUI坐标原点在左上角y向下增加和Input.mousePosition正好y轴相反。所以一定不要用事件系统的鼠标坐标去填充触摸位置必须用Input.mousePosition。3.5 提供与Input兼容的读取接口为了让业务代码零改动我封装了一个静态类TouchInput接口命名尽量贴近Unity原生的Inputpublic static class TouchInput { public static bool simulateInEditor true; public static int touchCount { get { #if UNITY_EDITOR if (simulateInEditor Application.isPlaying) return TouchSimulator.Instance.touchCount; #endif return Input.touchCount; } } public static Touch GetTouch(int index) { #if UNITY_EDITOR if (simulateInEditor Application.isPlaying) return TouchSimulator.Instance.GetTouch(index); #endif return Input.GetTouch(index); } }业务代码只需要把原来的Input.touchCount替换成TouchInput.touchCount把Input.GetTouch(i)替换成TouchInput.GetTouch(i)就完成了改造。用宏UNITY_EDITOR包裹之后真机打包时这段模拟逻辑会被编译器裁剪掉完全不影响性能。这里有一个取舍为什么不直接用Application.isEditor代替UNITY_EDITORApplication.isEditor是运行时判断在真机上也会被编译进去虽然一般情况不影响但宏在编译期就直接干掉代码最干净。3.6 在场景里挂载与真机代码共存模拟器本体我建议做成一个MonoBehaviour放在一个常驻场景或脚本里自动创建。我采用的是“静态运行时自动创建”的模式public class TouchSimulator : MonoBehaviour { public static TouchSimulator Instance { get; private set; } [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)] static void AutoCreate() { #if UNITY_EDITOR if (Application.isPlaying) { var go new GameObject([TouchSimulator]); DontDestroyOnLoad(go); Instance go.AddComponentTouchSimulator(); } #endif } void Update() { // 内部状态更新 } }这样写的好处是策划拖个场景进去不需要额外挂组件模拟器自己就启动了。DontDestroyOnLoad保证切场景时不会丢失状态。真机上宏被剔除这个类等同于不存在。在真机代码共存方面只有一点需要注意手势代码不要同时既读TouchInput又读Input否则两边的触摸数据可能对不上导致状态错乱。建议在项目规范里强制要求所有触摸读取统一走TouchInput。4. 常见坑与排查实录4.1 编辑器快捷键和鼠标事件冲突印象最深的坑就是Ctrl和Alt键的编辑器快捷键冲突。在Windows上按住Ctrl键时鼠标在Scene视图或Game视图里可能会变成框选、复制等操作在Mac上Ctrl左键还会被系统识别为右键。我的解决办法是双管齐下一是在游戏运行时自动切换编辑器快捷键状态这个可以用EditorApplication的lockReloadAssemblies和ExecuteMenuItem操作但更简单的是在模拟器初始化时提示开发者将Game视图的鼠标操作模式改为“Normal”。二是在代码里明确要求模拟器只在Game视图获得焦点时才生效避免鼠标在Scene视图操作时误触。void OnGUI() { if (Event.current.type EventType.KeyDown (Event.current.keyCode KeyCode.LeftControl || Event.current.keyCode KeyCode.LeftAlt)) { Event.current.Use(); // 吃掉事件防止传给编辑器 } }注意OnGUI的Use()只对GUI事件有效Input类读键盘状态不受影响。这个小技巧可以让模拟器在Game视图下更稳定地工作。4.2 模拟触摸的deltaTime和tapCount不准真机上Touch.deltaTime表示当前帧和上一帧之间的时间间隔手势识别里经常用它来做速度计算比如惯性滑动。模拟器里如果直接用Time.deltaTime在Editor下可能表现正常但如果发生了断点调试deltaTime会变得非常大导致手势速度突变。我的处理方式是虚拟手指自己维护一个deltaTime每帧用Time.unscaledDeltaTime来更新而且加一个上限钳制超过0.1秒就按0.1秒算防止断点恢复后第一帧出现离谱值。tapCount的判定则需要记录上次Ended的时间和位置。如果这次Began离上次Ended的时间小于0.3秒且位置偏移小于一定像素就累加tapCount否则重置为1。这个阈值和真机接近但Editor下鼠标点击通常比手指触碰更快所以实际体验下来0.35秒更舒适。4.3 切窗口、切分辨率导致坐标错位在编辑器里调整Game视图大小或者运行中修改Screen.SetResolution屏幕坐标会变。模拟器如果缓存了上一帧的屏幕宽高就会出现坐标越界或拉伸变形。这个问题在真机上不明显因为真机屏幕物理尺寸固定但Editor里很常见。我的建议是模拟器每帧都读取当前Screen.width和Screen.height不做缓存。同时如果发现屏幕尺寸发生变化立即把所有活跃手指的相位置为Ended清空模拟状态防止手势代码拿着一个过期的坐标硬算。4.4 Phase跳变Moved乱飞、Ended不触发跳变问题多半出在“上一帧位置”没有正确保存。如果你没有在UpdateFinger里把previousPosition finger.position放在position currentPos之前那么deltaPosition算出来永远是0手势代码会认为手指没动。还有一个非常隐蔽的坑属性Input.mousePosition在Editor下如果勾选了“Run In Background”当鼠标移出Game视图时它依然会返回最后一个位置。这时候模拟器会认为手指还停留在原地产生Stationary相位但其实物理上手指已经“断了”。我在模拟器里加了一个判断当鼠标移出Game视图边界时直接强制所有手指进入Ended状态。4.5 真机与Editor表现不一致的常见现象模拟器毕竟是模拟和真机的差距主要体现在三点一是真机的触摸采样率远高于鼠标通常鼠标一帧只产生一个移动事件而真机在快速滑动时一帧内可能有两个甚至更多的触摸点二是真机有触摸预测算法Unity会预判手指的下一位置来降低延迟Editor里没有三是真机的pressure、radius数据是真实的鼠标模拟永远给一个默认值。所以我的建议是模拟器用于逻辑开发、UI调参、手势状态机调试但性能测试、精细手势体验、压力感应相关功能还是得上真机。这不是模拟器不行而是物理上限决定的。你在Editor里把手指识别逻辑跑通了真机上最多调调阈值不会出现方向性的大改。5. 实测效果与一些心得这套方案在我的项目里用了大概三周主要用来调试相机的双指缩放和双指旋转。实际操作下来最舒服的一点是迭代速度改完脚本切回UnityPlay Mode里立刻就能试不需要任何打包等待。几个关键心得很明确一是输入访问层越早引入越好如果项目刚开始阶段就定义好TouchInput后面替换成本基本为零等整个项目都已经写满Input.GetTouch再来改那才是真的痛苦。二是模拟器的配置项比如修饰键、点击时间窗口最好做成可序列化字段直接在Inspector里调而不是改代码这样策划同学也能自己试手势。三是给模拟器加一个Debug绘制功能在Game视图用OnGUI把当前模拟的触摸点和相位画出来调试状态机时会直观很多。最后再分享一个小技巧。我在模拟三指手势的时候发现用两个修饰键加鼠标左键操作起来非常别扭因为人的手就两只。后来我改成用鼠标左键W键模拟第二根手指用鼠标左键E键模拟第三根手指按键就在左手边上操作起来顺很多。映射键位这事儿没有标准答案你觉得怎么顺手怎么来但一定要避免和Unity编辑器自带快捷键重了不然会边调试边被切窗口气得拍桌子。