地图手势缩放缓冲 (Map Gesture Zoom Buffering)

2026-08-18 暂无评论

为什么 PC 滚轮缩放卡顿，而手机双指捏合却跟手？ 核心不是事件本身，而是引擎怎么消费高频输入：连续变换有没有缓冲、重活（瓦片加载/重绘）有没有被推迟到定格时才提交。

现象（本项目实证）

校园导航 navi/index.html（BMapGL WebGL，frontend/public/navi/）：

输入	引擎行为	体感
手机捏合 `enablePinchToZoom`	手势中只做矩阵连续缩放，松手才定级 commit	跟手
电脑滚轮 `enableScrollWheelZoom`	每个 wheel 事件 = 一次离散 `setZoom`（切级+拉瓦片+重绘）	连续卡顿

实测结论：日间/夜间同样卡、程度相近 —— 排除深色 CSS filter 归因；根因在滚轮路径无缓冲。对比官方地图站点（非 API）拖拽缩放丝滑。

两条渲染路径

捏合（touch pinch）＝「橡皮筋 + 松手定级」
手势期间不切级，只算两指间距比例，作为连续矩阵（scale+translate）作用在已合成好的地图层上。每帧仅一次 GPU 合成：不换级、不拉瓦片、不重排。真正花钱的「换级 + 加载新级瓦片」推迟到 touchend 一次性 commit。99% 的手势时间是「拉伸一张图」，成本恒定且低。

滚轮（wheel）＝「每格一次离散提交」
enableScrollWheelZoom(true) 把每次 wheel 事件映射成一次 setZoom(z±1)——完整的分级提交。滚轮物理特性：快速一滚在极短时间打出一串事件（高分滚轮一个齿可发 3–5 个）。每个事件都是一次：

相机/zoom 动画重算
跨界 → 加载并解析新一级瓦片（网络 + 解码 + 重绘，异步高成本）
触发 zoomstart/zoomend 回调（可能再叠加相机操作，如 zoomend 里 setCenter 回拽）

当事件到来速度 > 单次 commit 成本，事件排队，每级渲染一半就被下一级打断 → 连续「半成品帧」→ 卡。

官网（官方地图站点）为什么不卡

滚轮当连续输入：累加 deltaY 成小数级目标，镜头用一次 transform 动画滑向目标；只有跨过整数级（或滚动停止）才 commit 加载瓦片。
滚动期间不触发 API/瓦片加载：快速手势只不断移动目标，每帧仍是单次 GPU 变换；新级瓦片在定格瞬间才后台加载。
瓦片加载是异步高成本，若每事件都触发必然追不上输入速度；把重活合并到「定格瞬间」一次做，中间用廉价变换填充，体感即顺滑。

一句话：官网把滚轮也走成了捏合那条「先连续变换、后定级提交」的路径。

可迁移原则（工程判断）

高频连续输入（wheel / drag / pinch）驱动离散重资产（切级 + 加载瓦片）时，不能 1:1 把事件映射成重活。
拆两层：
- 连续变换层：CSS/GPU transform，每帧可做，成本恒定。
- commit 层：定级 + 加载 + 重绘，只在手势结束 / 空闲阈值（如 150ms）后触发一次。
同类模式：列表惯性滚动、分页防抖、输入 debounce —— 都是「廉价反馈填满高频输入，重活合并到静止」。

适用边界（WebGL 地图陷阱）

「CSS 连续变换层」对WebGL 地图不适用：WebGL 已渲染画面只覆盖当前视野，用外层 DOM 的 transform: scale/translate 伪造缩放/平移会露出空白区（拖拽把整块图拖走、视野外是空的），而且一次 setZoom 定级时会与 CSS 变换叠加成 k × 2^zoom 的双重放大跳变。

对 WebGL 地图引擎（如百度 BMapGL、高德 2.0、Mapbox GL）：移动/缩放必须交给 SDK 相机，配合关闭动画立即生效——BMapGL 为 setZoom(zoom, { noAnimation: true, zoomCenter: geoPoint })，其中 zoomCenter 原生支持「以某点为基点缩放」。卡顿根因常是 SDK 的 setZoom 默认带缩放动画，高频连续调用时动画互相打断（真正的卡顿来源），而不是 CSS 因素。