requestAnimationFrame 实现流畅惯性滚动算法

本文深入剖析了如何利用 requestAnimationFrame 实现真正流畅、符合物理直觉的惯性滚动，明确指出 rAF 仅是调度工具，核心在于手动构建基于时间差（deltaTime）的 velocity-position 物理模型：通过指数衰减模拟真实阻尼、用线性回归精准估算 touchend 初速度、并以弹性势能思想优化越界回弹，避免卡顿、抖动和失速等常见陷阱——所有细节都直指“每一帧可预测”这一丝滑体验的本质。

requestAnimationFrame 本身不提供物理计算，只负责调度

很多人误以为 requestAnimationFrame 能“自动”实现惯性滚动，其实它只是浏览器提供的高优先级、与屏幕刷新率同步的回调机制。真正决定滚动是否丝滑、是否符合物理直觉的，是每次回调中你写的位移更新逻辑——尤其是速度衰减模型和边界处理。

常见错误现象：requestAnimationFrame 调用正常，但滚动停不住、突然卡顿、回弹过猛或越过边界后抖动。这些问题几乎都出在物理模型没闭环，而非帧调度本身。

• 必须自己维护 velocity（当前速度）、position（当前滚动位置）、lastTime（上一帧时间戳）三个核心状态
• 不能用固定步长（如每次 +2px），必须基于真实时间差（deltaTime = currentTime - lastTime）做线性插值
• 推荐用指数衰减： velocity *= Math.pow(0.96, deltaTime / 16)，比线性衰减更接近真实阻尼感

如何用 position + velocity + easing 构建最小物理滚动循环

一个可运行的惯性滚动循环，关键不在“有多炫”，而在“每帧是否可预测”。下面是最简可靠结构：

let position = 0;
let velocity = 0;
let lastTime = 0;
<p>function scrollLoop(timestamp) {
if (!lastTime) lastTime = timestamp;
const deltaTime = Math.min(timestamp - lastTime, 32); // 防止单帧过大
lastTime = timestamp;</p><p>// 物理更新：位置 += 速度 × 时间，速度 × 阻尼
position += velocity <em> (deltaTime / 16);
velocity </em>= Math.pow(0.95, deltaTime / 16);</p><p>// 边界约束（以容器 scrollTop 为例）
const minPos = 0;
const maxPos = container.scrollHeight - container.clientHeight;
if (position < minPos) {
position = minPos;
velocity <em>= -0.3; // 微弱反弹，避免粘滞
}
if (position > maxPos) {
position = maxPos;
velocity </em>= -0.3;
}</p><p>container.scrollTop = Math.round(position);</p><p>if (Math.abs(velocity) > 0.05) {
requestAnimationFrame(scrollLoop);
}
}</p>

注意：Math.pow(0.95, deltaTime / 16) 是关键——它让衰减率与帧率无关。如果直接写 velocity *= 0.95，在 30fps 下会比 60fps 慢一倍衰减，手感完全不同。

为什么 touchend 后立刻启动 rAF 容易失速？

移动端最常踩的坑：在 touchend 事件里直接读取最后一次 touches[0].clientY 算速度，但这时手指已离屏，采样点稀疏且滞后。结果是估算的初速度偏低，滚动几帧就停了。

• 正确做法：在 touchmove 过程中持续记录最近 3–4 个时间戳和位置，用线性回归或加权平均算瞬时速度
• 必须用 event.touches（不是 event.changedTouches），否则多指操作下会丢数据
• 初速度单位要统一：建议转成 px/ms，后续所有物理计算才可对齐时间步长
• 别忘了清除之前的 requestAnimationFrame ID，否则可能多个循环并发打架

滚动越界回弹时，requestAnimationFrame 的精度陷阱

当 position 超出 minPos/maxPos，直接设为边界值并反转速度，看似合理，但会导致视觉跳变。因为下一帧的 position 计算仍基于旧 velocity，而人眼对连续帧中的位置突变极其敏感。

更稳的做法是引入弹性势能模拟：

// 越界后不硬设 position，而是施加反向力
if (position  maxPos) {
  const over = position - maxPos;
  velocity -= over * 0.05;
  position = maxPos;
}

这个小修正会让回弹有渐进感。但要注意：系数 0.05 必须配合你的阻尼系数（前面的 0.95）调优，否则可能震荡发散。实际项目中，这些参数往往需要真机反复试出来，模拟器的触控延迟会掩盖问题。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~