滚动视差动画的数学原理与性能友好的实现方式

一、那些让页面"会呼吸"的视差效果，是怎么被 scroll 事件拖垮的

2017 年，一个奢饰品电商的首页因为 4 层视差滚动在 iPhone 7 上跑出 8 FPS，转化率暴跌 40%。产品认为是视觉稿的问题，设计认为是前端没优化好，前端觉得 iPhone 7 就该淘汰。最后性能剖析的结论让所有人沉默：scroll事件回调中调用了三次getBoundingClientRect()，触发强制同步布局（Forced Synchronous Layout），加上 4 层元素的top属性重绘——单一帧的渲染耗时突破 200ms。

视差动画的数学非常简单——把滚动位置映射为元素的位移、透明度或缩放比率。真正难的是"让映射结果在 60fps 下平滑呈现"。CSS 的transform提供了合成器级别的动画管道，但在scroll事件里用 JavaScript 手动更新transform，等于把高性能管道接到了一根漏水的破水管上。

本文的意图是：把视差滚动的数学拆干净——理解位置映射的线性与非线性的适用场景——然后把实现方案从"能用"推到"不卡"。

二、视差的数学本质与浏览器的渲染性能模型

视差效果的定义可以形式化为一个函数：

$$P(y) = y \times k$$

其中 $y$ 是窗口的滚动偏移量，$k$ 是视差系数。当 $k = 1$ 时元素随页面自然滚动；$k = 0$ 时元素固定在原位（position: sticky 的极限情形）；$k < 0$ 时元素反向滚动。$k$ 取值范围在实践中通常是 $[-0.5, 0.5]$，超出这个范围会产生严重的视觉割裂感。

但"视觉自然"的视差往往不是线性的。人眼期待的视差是：元素在进入视口时加速，在视口中心区域保持稳定，然后在滚出视口时再次加速。这种非线性行为需要用缓动函数来建模，常用的有：

• ease-out 视差：元素在靠近视口顶部时快速下降，接近视口底部时趋于静止。适合 Hero 区域的标题层。
• ease-in-out 视差：元素在视口边界快速移动，中心区域相对静止。适合卡片或画廊项目。
• 弹性视差：在基础位移上叠加阻尼振荡，产生"惯性回弹"效果。适合品牌页面的视觉点缀。

下面这张 Mermaid 图解释了三种实现方案在浏览器渲染管道中的位置差异：

flowchart TB subgraph 浏览器渲染帧流程 A["Scroll 事件触发"] --> B["JavaScript<br/>执行回调"] B --> C["Style Recalculate<br/>样式重算"] C --> D["Layout<br/>布局重排"] D --> E["Paint<br/>重绘"] E --> F["Composite<br/>合成"] end subgraph 方案A["方案 A: JS 直接操作 top/left"] B --> G["element.style.top = y * k"] G -.->|"强制 Layout"| D end subgraph 方案B["方案 B: JS 操作 transform + rAF"] H["requestAnimationFrame<br/>中更新 transform"] -.->|"跳过 Layout & Paint"| F B --> H end subgraph 方案C["方案 C: CSS scroll-driven animations"] I["animation-timeline: scroll()"] -.->|"浏览器原生优化<br/>跳过 JS 线程"| F end

方案 A 的致命缺陷在于：修改top属性会触发 Layout（因为top影响文档流中其他元素的位置），继而引起 Paint 和 Composite 两个阶段的级联重算。每一帧都 Layout = 每一帧都 16ms+。

方案 B 将位移挂载在transform: translateY()上，后者只影响 Composite 阶段。配合requestAnimationFrame在渲染帧之间插入更新，避免了 Layout 和 Paint。但scroll事件本身仍在主线程触发，高频率的scroll回调仍可能产生一定的 CPU 负载。

方案 C 是 2024 年之后的利器：CSS Scroll-driven Animations。通过animation-timeline: scroll()将动画时间轴直接绑定到滚动容器的偏移量，整个动画管线都在合成器线程运行，既不触发 JS 也不占用主线程。但目前 Firefox 和 Safari 的支持尚不完全（Safari 17.2+ 支持）。

三、三套生产级视差方案

方案 1：基础线性视差（兼容性最好）

/** * 线性视差控制器 * * 通过 requestAnimationFrame 在每帧更新 translateY * 滚动节流交给 rAF 处理（自动与屏幕刷新率同步） * * 适用场景：Hero 背景、品牌介绍页 * 不适用：大量元素同时视差（DOM 数量过多时 rAF 回调开销增大） */ class ParallaxController { private elements: { el: HTMLElement; speed: number }[] = []; private ticking = false; // rAF 防抖标记：避免同一帧内多次更新 /** * 注册需要视差效果的元素 * @param el - 目标 DOM 元素 * @param speed - 视差系数，正数同向、负数反向，推荐范围 [-0.5, 0.5] */ register(el: HTMLElement, speed: number) { this.elements.push({ el, speed }); // will-change 提前创建 GPU 合成层，减少首次滚动的合成开销 el.style.willChange = 'transform'; } /** * 启动滚动监听 * rAF 节流策略：每帧最多更新一次，与屏幕刷新率对齐 */ start() { const onScroll = () => { if (!this.ticking) { this.ticking = true; requestAnimationFrame(() => { const scrollY = window.scrollY; for (const { el, speed } of this.elements) { // 核心计算：translateY = 滚动距离 × 视差系数 // 使用 transform 而非 top，避开 Layout 阶段 const offset = scrollY * speed; el.style.transform = `translateY(${offset}px)`; } this.ticking = false; }); } }; // passive: true 告诉浏览器不会调用 preventDefault // 让浏览器可以提前规划滚动帧，减少延迟 window.addEventListener('scroll', onScroll, { passive: true }); return () => window.removeEventListener('scroll', onScroll); } /** * 销毁所有视差效果，清理 will-change 防止 GPU 显存泄漏 */ destroy() { for (const { el } of this.elements) { el.style.transform = ''; el.style.willChange = ''; } this.elements = []; } } // 使用示例 // const parallax = new ParallaxController(); // parallax.register(document.querySelector('.hero-bg')!, -0.3); // parallax.register(document.querySelector('.hero-title')!, 0.2); // const cleanup = parallax.start();

方案 2：CSS Scroll-driven Animations（性能最优）

/** * 使用 CSS Scroll-driven Animations 实现视差 * * 优势： * - 动画在合成器线程执行，不占用主线程 * - 声明式语法，无需 JavaScript * - 自动与滚动偏移同步，无需手动计算 * * 浏览器支持：Chrome 115+、Edge 115+、Safari 17.2+ * 不支持时降级为静态效果（通过 @supports 检测） */ /* Hero 背景层：反向视差，系数 -0.4 */ @supports (animation-timeline: scroll()) { .parallax-hero-bg { /* 将动画进度绑定到祖先滚动容器的滚动偏移 */ animation: parallax-reverse linear; animation-timeline: scroll(root); /* animation-range 控制动画映射区间： 0px → 100vh 的滚动范围内完整播放 */ animation-range: 0px 100vh; } @keyframes parallax-reverse { from { /* 滚动到顶部：背景向下偏移 20% 视口高度 */ transform: translateY(-20vh); } to { /* 滚动走完 100vh：背景向上偏移 20% 视口高度 总位移差 = 40vh，即 20vh - (-20vh) */ transform: translateY(20vh); } } /* 前景内容层：正向视差但幅度小于滚动速度（缓速效果） */ .parallax-hero-content { animation: parallax-slow linear; animation-timeline: scroll(root); animation-range: 0px 80vh; } @keyframes parallax-slow { from { transform: translateY(0); } to { transform: translateY(-60px); } } /* 淡入效果：元素进入视口时从透明到可见 */ .parallax-fade-in { animation: fade-in linear; animation-timeline: view(); /* view() 表示动画范围基于元素自身的视口可见性 cover 0% = 元素底部刚接触视口顶部 cover 40% = 元素上边界进入视口 40% 位置 */ animation-range: cover 0% cover 40%; } @keyframes fade-in { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } } } /* 不支持 scroll-driven animations 的优雅降级 */ @supports not (animation-timeline: scroll()) { .parallax-hero-bg, .parallax-hero-content, .parallax-fade-in { /* 降级方案：取消动画，保持静态布局 */ animation: none; opacity: 1; transform: none; } }

方案 3：Intersection Observer 触发型（细粒度控制）

/** * 基于 Intersection Observer 的视差触发器 * * 与 scroll 事件方案的区别： * - 只在元素进入/离开视口时触发回调（而非每一帧） * - 适合仅在特定区间内需要视差效果的场景 * - observer 回调在微任务队列执行，不阻塞渲染 */ class ObserverParallax { private observer: IntersectionObserver; constructor() { this.observer = new IntersectionObserver( (entries) => { for (const entry of entries) { if (entry.isIntersecting) { // 元素进入视口：开始视差 const el = entry.target as HTMLElement; const speed = parseFloat(el.dataset.parallaxSpeed || '0.2'); const ratio = entry.intersectionRatio; // 可见比例 0-1 // 根据可见比例计算位移 const offset = (1 - ratio) * el.offsetHeight * speed; el.style.transform = `translateY(${offset}px)`; } } }, { // threshold 数组：在 0%, 25%, 50%, 75%, 100% 可见时各触发一次 // 产生平滑的阶梯式更新 threshold: [0, 0.25, 0.5, 0.75, 1], } ); } observe(el: HTMLElement) { this.observer.observe(el); } disconnect() { this.observer.disconnect(); } }

四、边界场景与性能权衡

多层视差的 GPU 合成层累积。每设置一个will-change: transform或transform: translateZ(0)，浏览器就会为该元素创建一个独立的 GPU 合成层。单个合成层的纹理内存约占宽×高×4 字节（RGBA），一张 375×812 的移动端全屏图约 1.2MB 纹理。4 层全屏视差 = 4.8MB 额外 GPU 显存。在可用显存低于 512MB 的低端 Android 设备上，超过 6 层全屏视差就会出现纹理内存溢出，触发浏览器的"层压缩"机制——重新在主线程绘制，反而比不用视差更慢。建议全屏视差不超过 3 层，小面积元素不受此限制。

passive: true不是银弹。虽然passive: true避免了touchstart事件的默认行为阻塞，但scroll事件的回调执行本身仍在主线程。如果scroll回调中有复杂计算（如getBoundingClientRect、offsetHeight），60fps 下半数以上的帧预算会被它吃掉。重度视差场景（超过 10 个元素同时响应滚动）应使用 CSS Scroll-driven Animations 或将计算迁移到 Web Worker（postMessage 传递滚动位置，Worker 中批量计算位移，主线程只负责写transform）。

视频背景上的视差层。<video>元素的合成在 GPU 的视频解码器中完成，其在合成器层的处理路径不同于<img>。在视频上叠加视差图层时（比如品牌首页的"视频 + 悬浮文案"），mix-blend-mode与视频的组合会强制创建额外的合成 pass。标准的优化策略：将视频的filter和transform限制在最小范围，叠加层使用position: absolute+pointer-events: none保持独立合成。

五、总结

1. 视差动画的数学核心是将滚动偏移映射为元素位移：$P(y) = y \times k$，$k \in [-0.5, 0.5]$。
2. 非线性视差（ease-out / ease-in-out / 弹性）比线性更具"自然视觉感"，但计算成本更高。
3. 直接修改top/left触发 Layout → Paint → Composite 三级重算，是性能灾难。
4. transform: translateY()+requestAnimationFrame跳过 Layout 和 Paint，仅触发 Composite。
5. CSS Scroll-driven Animations（animation-timeline: scroll()）在合成器线程运行，性能最优。
6. 每个will-change: transform创建一个 GPU 合成层，移动端全屏层 > 3 时注意显存上限。
7. passive: true仅减少事件阻塞无法降低 callback 执行开销，重度视差应 offline to Worker。
8. Intersection Observer + threshold 阶梯触发适合"仅在某区间有视差"的细粒度场景。
9. 视频背景 + 视差层的合成处理路径不同于静态图，注意限制附加的 filter 和 mix-blend-mode。
10. 降级策略：用@supports (animation-timeline: scroll())检测，不支持时回退 JS 方案或取消视差。