Appearance
一张图手势交互体系
这篇不是“手势列表”，而是一套车载地图交互系统的工程案例：输入识别、策略分发、地图状态、相机锚点、跨端协议和渲染时机必须一起设计。
手势策略8 类
关键收益0 帧拖拽
资料来源3 份飞书文档
背景
一张图的核心体验由手势驱动：拖拽移动地图、双指缩放、单/双指点击缩放、惯性甩图、无操作回正、俯仰角控制、LD/SD 切换。难点不在于识别某个手势，而在于 Unity、Android 原生层、XMapEngine、相机状态和地图锚点同时参与一次交互。
飞书资料里有三类信息：一类是手势梳理，一类是接口 + 策略 + 管理器改造方案，一类是 FingerGestures 与 Unity Legacy Input 的技术选型对比。合在一起看，手势系统实际是 XMapEngine 架构重构的一条主线。
问题
| 问题 | 现象 | 工程风险 |
|---|---|---|
| 输入源不统一 | Android 与 Unity 各有识别链路 | 同一手势在不同端行为不一致 |
| 状态依赖隐式 | 手势直接影响相机、高度、比例尺、锚点 | 修一个交互容易牵动全局 |
| 渲染时机错位 | Update 处理输入，渲染晚一帧 | 拖拽跟手感差，出现错 1 帧 |
| 场景切换复杂 | LD、SD、SR、泊车场景有不同约束 | 回自车、切换、缩放容易跳变 |
设计
手势系统按四层拆分：
| 层级 | 责任 |
|---|---|
| 输入层 | FingerGestures / Unity Legacy Input / Android 原生手势识别 |
| 策略层 | 单指拖拽、双指缩放、点击缩放、惯性、回正、俯仰角等策略 |
| 状态层 | XGestureCtrl、LDGestureRoot、XMapState、比例尺、相机锚点 |
| 渲染层 | XMap、MasterDisplay、相机节点、地图节点和自车节点 |
关键不是把所有逻辑塞进一个手势类，而是把“输入是什么”“状态怎么变”“画面何时更新”分开。
text
Touch Input
-> Gesture Recognizer
-> Gesture Strategy
-> XGestureCtrl / LDGestureRoot
-> XMapState / Anchor
-> Camera / Map Node
-> Render Frame技术选型
飞书对比文档里把 FingerGestures 和 Unity Legacy Input 按车机应用做了拆解。公开结论可以抽象成：
| 维度 | FingerGestures | Unity Legacy Input |
|---|---|---|
| 复杂手势 | 内置识别能力强，适合多指和组合手势 | 更底层，需要自己封装 |
| 可控性 | 抽象更高，改行为要理解插件机制 | 可控但开发成本更高 |
| 车机适配 | 适合快速建立复杂交互 | 适合做兜底或轻量场景 |
| 风险 | 插件版本和项目耦合 | 手写逻辑容易分散 |
最终策略不是二选一，而是让业务层只依赖统一手势接口，底层识别实现可以替换。
核心手势
| 手势 | 关键处理 |
|---|---|
| 单指拖拽 | 屏幕坐标转墨卡托，再转 Unity 世界坐标，更新地图锚点 |
| 双指缩放 | 缩放中心对齐地图中心，避免缩放偏位 |
| 单指双击缩放 | 点击点作为缩放中心，进入动画过渡 |
| 双指单击缩放 | 与普通缩放区分优先级，避免误触 |
| 惯性甩图 | 根据离手速度做衰减，手感参数可调 |
| 无操作回正 | 超时进入 XMapCorrectAnimation，回到稳定视角 |
| 俯仰角控制 | 受场景和 pitch 区间约束，避免与缩放冲突 |
| 回自车 | start / ing / end 显式状态化，降低抖动 |
0 帧拖拽
旧问题的本质是时序错位：手势输入在当前帧改变状态，但地图移动和相机渲染没有在同一个时机对齐，于是视觉上慢一拍。解决方式是把 LD 地图移动统一放到 LateUpdate 对齐手势结果，让输入、状态和渲染同帧收敛。
这类问题不能只看“识别到了没有”，要按帧拆开：
- 输入事件进入。
- 手势策略计算位移。
- 锚点状态更新。
- 相机和地图节点更新。
- 渲染提交。
任何一步晚一帧，用户感知都是“拖不动”或“黏手”。
产出
- 手势全量支持表。
- FingerGestures / Unity Legacy Input 选型结论。
- XGestureCtrl 和 LDGestureRoot 的职责边界。
- 拖拽 0 帧延迟时序。
- 手势与相机、锚点、地图状态的关系图。
可复用方法论
- 交互系统要按“输入、策略、状态、渲染”拆，不要按类名堆。
- 手势冲突要显式定义优先级，不能靠回调触发顺序碰运气。
- 车载地图的缩放、拖拽和回自车，本质都是相机和锚点问题。
- 体验问题要按帧分析，尤其是 Update / LateUpdate / Render 的边界。
复盘
原页面只列了手势清单，没体现系统复杂度。接入飞书资料后，这篇现在能支撑两种阅读：对外能看到交互系统能力，对内能作为后续补图和补代码索引的骨架。
公开版深化
案例定位
一张图手势交互体系不是孤立笔记，而是引擎架构能力下的一个可复用案例。它服务于“小鹏一张图 / SR 手势交互”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
这篇不是“手势列表”，而是一套车载地图交互系统的工程案例：输入识别、策略分发、地图状态、相机锚点、跨端协议和渲染时机必须一起设计。
这篇文章已经覆盖 背景、问题、设计、技术选型、核心手势、0 帧拖拽。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 3 份飞书手势资料汇总
- 8 类手势策略化
- 拖拽错 1 帧到 0 帧
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
一张图手势交互体系不是孤立笔记，而是引擎架构能力下的一个可复用案例。它服务于“小鹏一张图 / SR 手势交互”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
这篇不是“手势列表”，而是一套车载地图交互系统的工程案例：输入识别、策略分发、地图状态、相机锚点、跨端协议和渲染时机必须一起设计。
这篇文章已经覆盖 背景、问题、设计、技术选型、核心手势、0 帧拖拽。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 3 份飞书手势资料汇总
- 8 类手势策略化
- 拖拽错 1 帧到 0 帧
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。
公开版深化
案例定位
一张图手势交互体系不是孤立笔记，而是引擎架构能力下的一个可复用案例。它服务于“小鹏一张图 / SR 手势交互”这条主线，公开版重点保留问题抽象、工程取舍和可复用方法，不暴露内部系统细节。
关键问题
这篇不是“手势列表”，而是一套车载地图交互系统的工程案例：输入识别、策略分发、地图状态、相机锚点、跨端协议和渲染时机必须一起设计。
这篇文章已经覆盖 背景、问题、设计、技术选型、核心手势、0 帧拖拽。后续阅读时应重点看三件事：问题如何被定义，方案如何在约束下落地，以及哪些经验可以迁移到下一次类似项目。
企业级产出
| 产出 | 公开表达 |
|---|---|
| 问题定义 | 用用户体验、性能、稳定性或交付效率描述影响 |
| 技术方案 | 保留架构、流程、算法和工具链层面的抽象 |
| 指标证据 | 只使用页面已有数字或经过脱敏审查的量级 |
| 复用方法 | 沉淀为 SOP、检查清单、图谱关系或后续案例链接 |
指标与证据
- 3 份飞书手势资料汇总
- 8 类手势策略化
- 拖拽错 1 帧到 0 帧
复盘结论
这个案例的核心价值，是把一次具体工程处理沉淀成可检索、可复盘、可继续扩展的技术资产。没有公开证据支撑的细节继续留在私有材料池，不进入线上页面。