lottie.js实战指南：从AE导出JSON到前端动画性能优化

1. 项目概述与核心价值

1.1 为什么我最终选择了lottie.js

坦白说，最早我在项目里做动画，第一反应还是用GIF或者序列帧。但做前端时间久了，你会发现GIF的坑实在太深：尺寸大得离谱，一帧一帧全是像素，颜色一多就出现锯齿和噪点，放大缩小还会糊。序列帧就更难受了，一张雪碧图动辄几兆，每次动效迭代都要重新切图，设计师改个颜色，前端就得跟着重跑一遍导出流程。后来被逼着认真看了lottie.js，才意识到这类JSON动画方案真正解决了团队协作里的一个大问题——它让设计师和开发者的工作流彻底解耦了。

Lottie是Airbnb开源的一套跨平台动画方案，核心思路是把Adobe After Effects里做好的动画，通过Bodymovin插件导出成一个JSON文件，然后由各端SDK负责解析和渲染。前端用的就是lottie-web库（就是我们常说的lottie.js），它通过SVG、Canvas或HTML5三种模式把这个JSON渲染成真实的动画效果。好处是显而易见的：动画文件极小（往往只有同效果GIF的十分之一甚至更少）、矢量化缩放不糊、可以随时改颜色改速度改透明度，还能在运行时动态替换某一部分元素。

这篇文章适合谁看？如果你是前端开发，想在Web项目里接入轻量级动画，或者一直被GIF体积、动画性能困扰；又或者你是设计师，想了解导出的JSON动画在开发侧怎么落地、有哪些坑——那这篇内容会很对胃口。我会从设计源文件到前端接入，把整个流程的关键节点、参数配置、性能优化和踩坑实录都过一遍。

1.2 这套方案到底解决了什么问题

先说结论，lottie.js最核心的价值就三个词：轻量、可控、跨端一致。

轻量，是指文件体积。一段3秒的复杂MG动画，如果做成GIF可能要5到8MB，做成视频又会有解码器兼容性问题，而lottie的JSON文件通常在几十KB到几百KB之间。因为JSON记录的是矢量图形的绘制指令、关键帧变换、缓动曲线这些“数据”，而不是一帧帧的像素。类似你用SVG和PNG对比，数据驱动和位图存储，本质上不在一个量级。

可控，是指运行时能力。动画的播放、暂停、跳转到某一帧、设置播放速度、循环模式、监听事件，全部通过实例方法就能搞定。你甚至能把动画进度条和一个滚动事件绑定，做滚动驱动的交互动效，这在传统GIF里想都不敢想。

跨端一致，是指同一份JSON在Web、iOS、Android、Flutter上渲染效果基本一致。因为规范统一，解析逻辑各端实现思路相近，设计师在AE里看到什么样，各端基本就是什么样。这避免了过去那种“iOS一个实现、Android一个实现、Web又一个实现”的万国造局面。

不过要泼一盆冷水——lottie.js不是万能的。它对AE特性的支持有边界，比如部分内置特效、特定粒子插件、复杂表达式，导出时会出问题或者被降级。方案选型前，一定要先搞清楚你的动画是不是在合理使用范围内，不然做到一半发现某个效果渲染不出来，返工成本非常高。

2. JSON动画文件的获取与准备

2.1 从AE导出JSON的标准流程

要拿到lottie能用的JSON动画，正统路径是AE + Bodymovin插件。我按实际操作的顺序拆一遍：

第一步，安装Bodymovin插件。在Adobe官网的插件市场或Github releases里都能找到，注意选择匹配你AE版本的安装包。目前主流AE版本（2022及之后）基本都兼容。装完以后，打开AE会看到“窗口-扩展”下多出Bodymovin的入口，没有就去“首选项-常规-允许脚本写入文件”里把开关打开，这是新手最容易卡住的地方。

第二步，把设计好的动效用AE的图形图层、形状图层、文字图层做出来。记住一个核心原则：能用形状图层实现，就不要用素材图层；能用关键帧控制，就不要写复杂表达式；能拆成独立图层，就不要把所有内容揉在一层里。因为lottie导出的底层逻辑就是按图层、按属性递归序列化，图层结构越规整，导出越稳定，后续在前端做动态属性替换也越简单。

第三步，选中要导出的合成，打开Bodymovin窗口，选择需要导出的合成，设置输出路径和文件名（后缀.json），点Render。插件会把合成内容解析成JSON数据，写入本地文件。

导出完成后，你拿到的是一个纯JSON文件。这时候建议用官方预览工具lottie-player或lottiefiles.com在线预览页面先跑一遍，确认动效和AE里是一致的。我习惯的做法是先在网页上快速验证，再进项目集成，因为如果直接在项目里发现问题，排查链路会拉长，很难分辨是导出问题还是代码问题。

2.2 JSON文件结构拆解：你面对的不是黑盒

很多前端拿到JSON文件以后，就当它是“魔法数据”，直接往lottie里一塞就完事。但一旦动画出了问题，或者你想做动态修改，不了解JSON结构就寸步难行。所以我强烈建议你至少把一个lottie的JSON文件打开看一遍，核心字段并不多。

一个典型的JSON对象包含以下关键节点：

• v：Bodymovin插件的版本号，解析时会做兼容判断。
• fr：动画的帧率，比如60表示每秒60帧。
• ip、op：动画的起始帧和结束帧，决定了动画的总时长（(op - ip) / fr秒）。
• w、h：设计稿的画布宽高，单位是像素。
• assets：引用的外部资源，比如图片、预合成的数据。
• layers：图层数组，每个图层有id、类型（shape/text/image等）、变换信息、内容信息。
• markers：可以打标记点，用于事件分发或者跳转定位。

举个实际例子，如果我想在运行时把动画里的某个文字从“你好”改成“Hello”，我需要在JSON里找到对应的文字图层（通常是t类型的图层），然后定位它的d.k属性（关键帧内容），修改里面的值。lottie.js在读取时其实会维护一个内部的图层对象映射，你完全可以通过animation.renderer.elements的路径去定位图层，然后修改属性后调用animation.renderer.renderFrame()让画面刷新。

官方API里还有一个更省事的方式：animation.addEventListener('DOMLoaded', callback)，在DOM渲染完成后，通过document.querySelector找到对应元素直接改DOM内容，然后触发animation.goToAndStop(当前帧, true)重新渲染。这个做文案动态替换特别方便。

2.3 没有AE时怎么应急

不是所有人都有AE的环境。有时候设计师只给了一个lottie文件的网址，或者你只是想快速做个页面动效，并不想跟AE打交道。这里有几个替代方案：

第一种，用现成的lottie动画库。网站比如lottiefiles.com提供大量免费动画，支持直接下载JSON，很多都是高星作品，质量和性能都经过验证。做临时活动页或者MVP项目，直接挑一个合适的，比自己从零做快得多。

第二种，用SVG转换工具。lottie本质上是矢量动画格式，如果项目里的动效比较简单（平移、旋转、缩放、透明度变化），可以考虑直接把SVG animate元素转成lottie。不过说实话，这类自动转换工具的效果差强人意，复杂一点就崩，应急可以，生产环境不建议。

第三种，自己手写JSON。如果你想彻底搞懂这个格式，完全可以手写一个简单的lottie JSON。一个只有形状层的动画，核心结构不到20行。比如画一个红色的圆，让它从左移动到右：

code复制{
  "v": "5.7.4",
  "fr": 30,
  "ip": 0,
  "op": 60,
  "w": 500,
  "h": 500,
  "layers": [
    {
      "ddd": 0,
      "ind": 1,
      "ty": 4,
      "nm": "圆",
      "sr": 1,
      "ks": {
        "p": {
          "a": 0,
          "k": [
            { "t": 0, "s": [100, 250], "e": [400, 250] }
          ]
        }
      },
      "shapes": [
        {
          "ty": "el",
          "p": { "a": 0, "k": [0, 0] },
          "s": { "a": 0, "k": [100, 100] }
        },
        {
          "ty": "fl",
          "c": { "a": 0, "k": [1, 0, 0, 1] }
        }
      ]
    }
  ]
}

这种手写经验，对调试和理解工作原理帮助极大。你在控制台查看这个JSON结构时，会真正理解lottie是在用数据描述图形，而不是在存储图片。

3. lottie.js核心API与播放控制详解

3.1 引入与基本用法

引入lottie-web的方式有三种：直接CDN、npm安装、ES模块引入。以npm方式为例：

bash复制npm install lottie-web

然后在项目里引入：

javascript复制import lottie from 'lottie-web';

const animation = lottie.loadAnimation({
  container: document.getElementById('animation-container'),
  renderer: 'svg',
  loop: true,
  autoplay: true,
  path: '/animations/data.json'
});

这里每个参数都很关键：

• container：动画渲染的容器DOM，必须有明确的宽度和高度，否则动画会显示异常，甚至直接不渲染。
• renderer：渲染模式，svg、canvas、html三选一。这是性能策略的重要分水岭，后面专门讲。
• loop：是否循环播放，布尔值。
• autoplay：是否自动播放，布尔值。
• path：JSON文件的路径。这里是URL，所以可以指向CDN。
• animationData：如果你已经通过接口拿到了JSON对象，这里可以直接传入对象，而不需要指定path，避免重复请求。

实际项目里，我通常优先用animationData直接传JSON对象，因为动画数据很可能跟业务数据一起从后端接口返回，避免一次额外的GET请求。特别是接口已经下发了一堆配置信息的时候，多请求一次动画文件，就是多一次网络往返，移动端尤其不划算。

3.2 实例方法：播放控制全谱

loadAnimation返回的是一个AnimationItem实例，它封装了几乎所有你需要的方法。我把常用的按使用频率列一下：

• play()：从当前帧开始播放。
• pause()：在当前帧暂停，再调用play()会从暂停位置继续。
• stop()：停止播放，回到起始帧，且自动解除循环状态（注意这点，stop后必须重新调用play才会再次启动）。
• goToAndStop(value, isFrame)：跳到指定位置并停住。value可以是帧数（isFrame为true），也可以是时间（isFrame为false）。
• goToAndPlay(value, isFrame)：跳到指定位置并开始播放。
• setSpeed(speed)：设置播放速度倍率，2就是两倍速，0.5就是半速。
• setDirection(direction)：设置播放方向，1正向，-1反向。
• destroy()：销毁实例，释放内存，在组件卸载时一定要调用。
• playSegments(segments, forceFlag)：播放指定片段，比如[[0, 30], [60, 90]]，可以连续播多个片段，forceFlag为true时立即跳转。

这里有个特别容易踩坑的点：destroy()没有调用。在SPA项目里，如果每次进入页面都loadAnimation，离开时不destroy，实例会一直挂着，监听器也不会移除，内存蹭蹭往上涨，最后页面会越来越卡。我在项目里就吃过亏，动画列表页连续切换几十次之后，浏览器标签页直接崩溃。

3.3 事件监听：让动画和业务联动

动画不是孤立运行的，它需要和业务交互结合。lottie.js提供了事件系统，核心事件包括：

javascript复制animation.addEventListener('DOMLoaded', () => {
  // DOM渲染完成，此时才能操作内部DOM/SVG元素
});

animation.addEventListener('complete', () => {
  // 单次播放完成，循环模式下不会触发
});

animation.addEventListener('loopComplete', () => {
  // 每次循环结束触发
});

animation.addEventListener('enterFrame', (event) => {
  // 进入每一帧都会触发，参数里带有当前帧号和总帧数
});

enterFrame是这个事件系统里最有价值的一个。你可以用它实现“播放进度条”逻辑：监听每一帧，把进度实时同步到UI上。比如引导页动画播放的同时，底部进度条同步增长：

javascript复制animation.addEventListener('enterFrame', () => {
  const frame = animation.currentFrame;
  const totalFrames = animation.totalFrames;
  progressBar.style.width = (frame / totalFrames * 100) + '%';
});

也可以用addEventListener('segmentStart', callback)监听播放到某个片段时触发埋点。比如品牌动画里，logo出现的那一瞬间上报一个数据，用来统计用户是否完整观看了动画。

4. 性能优化与方案取舍

4.1 渲染模式：SVG、Canvas、HTML怎么选

lottie.js支持三种渲染模式，选错了性能表现天差地别。我按实际场景推荐：

SVG模式（默认）：用SVG节点描述矢量图形，DOM节点数和动画复杂度成正比。优点是清晰度最高、CSS可操作性强（可以改任意元素的颜色和样式）、调试方便（直接看DOM）。缺点是动画太复杂时，DOM节点数量巨大，CPU和内存都受不了。适合动效复杂度中等、对清晰度要求高的场景。

Canvas模式：把所有东西绘制在一个canvas上，没有大量DOM节点，性能表现更稳定，尤其适合复杂动画、需要大量实例同时播放的场景。缺点是失去了DOM可操作性，想改单个元素样式就不方便。另外在高DPI屏幕上要注意清晰度，需要手动处理缩放。

HTML模式：用CSS属性（transform、opacity等）来实现动画。性能最高，因为CSS动画走的是合成线程，不占主线程。但局限很大：只能实现部分简单特性（位移动画、缩放、旋转、透明度等），复杂的形状绘制和蒙版基本不支持。适合做简单的入场退场动效。

我的选型经验是这样的：

• 一般页面点缀动画、引导动画、图标动画，优先SVG。
• 同时播放多个动画、长动画、动画列表页，优先Canvas。
• 只做简单的展示过渡，优先HTML。
• 移动端低端机上，Canvas往往比SVG流畅得多，因为在低端Android机型上大SVG的布局计算和绘制开销非常可观。

4.2 播放性能的三个关键指标

做动画性能调优，要看三个核心指标：

首帧渲染时间：用户看到动画第一帧的时间。lottie加载JSON后需要解析和构建渲染树，这个阶段是同步的，数据越大费时越长。优化办法是，把JSON加载解析放到空闲时间处理，或者用lottie.setLocationHref()配合预加载数据，减少解析阻塞时间。另外可以给容器先设置一个和动画首帧接近的占位背景色，避免出现白屏跳动感。

运行帧率（FPS）：动画播放时的实际渲染帧率。可以用animation.addEventListener('enterFrame')配合performance.now()自己统计，或者用Chrome DevTools的Rendering里的FPS meter直接看。如果掉到30FPS以下，说明动画复杂度超标或者渲染模式选错了。

内存占用：lottie实例占用的内存。在Chrome Task Manager里看标签页的内存变化，或者在代码里用performance.memory（仅Chrome支持）采样。如果内存持续增长，大概率是实例没销毁、事件监听泄漏或者JSON里有大图资源。

4.3 实战中的性能优化手段

第一招，降低帧率。如果动画不要求60帧流畅感（很多2D动画用30帧看起来也差别不大），可以在AE导出设置里把合成帧率从60改成30，JSON里的fr字段会从60变为30，但动画时长不变。关键帧数量减少，渲染压力直接减半。这招在移动端效果极其明显。

第二招，压缩JSON。lottie的JSON文件本身就是文本格式，压缩空间不小。后端可以开启gzip传输，前端也可以用压缩库对JSON关键字段做精简，去掉多余空白和不必要的字段。我见过一个动画JSON原始大小是800KB，gzip后变成150KB，加载速度提升非常明显。

第三招，使用lottie.setQuality()或配置渲染参数。lottie-web在新版本API里提供了渲染质量的设置项，比如SVG渲染器里可以做简化路径的处理。

第四招，合并动画实例。如果页面上有多个独立的lottie动画，可以考虑把它们合并成一个合成导出。因为每个实例都会创建独立的渲染器和事件循环，实例多了开销是线性叠加的。合并成一个实例后，内部图层之间互相独立，渲染模型统一，性能好很多。

第五招，使用IntersectionObserver做懒加载。动画不在可视区域时，不初始化实例；进入可视区域再加载。给动画容器加一个简单的懒加载封装：

javascript复制function lazyLoadAnimation(container, options) {
  let animation = null;
  const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting) {
      animation = lottie.loadAnimation({ container, ...options });
      observer.disconnect();
    }
  });
  observer.observe(container);
  return {
    destroy() {
      observer.disconnect();
      if (animation) animation.destroy();
    }
  };
}

我实际用这个方案优化过一个活动页，首屏动画加载耗时从1.2秒降到300毫秒，性能部门的预算直接达标。

4.4 字体与图片资源的处理

lottie动画里如果用了文字图层，JSON里会记录字体信息。前端加载时需要保证对应字体可用，否则文字会退化显示为默认字体，观感差别很大。解决方案有几种：

• 把文字转成形状图层（在AE里右键图层-创建形状），这样导出的是路径数据，不依赖字体，但缺点是文字内容无法在运行时动态修改。
• 上传自定义字体到CDN，在项目中用@font-face声明，确保动画容器内的文字能正确使用该字体。
• 使用lottie的rendererSettings配置，在加载时设置fontFamily等参数。

图片资源同理。如果AE里用了位图素材，导出时会被BASE64编码内嵌到JSON里，JSON文件体积会暴涨。这时候最好的做法是在导出设置里把图片标记为外部资源，让Bodymovin生成一个images/文件夹，图片单独存放，然后在加载时通过lottie.loadAnimation的assetsPath参数指定图片的基准路径。这样JSON文件保持轻量，图片也可以走CDN。

5. 常见问题与排查技巧实录

5.1 动画加载失败或白屏

症状：页面打开，动画区域空白，控制台没有任何报错。

排查步骤：

第一步，先确认JSON地址能不能正常访问。直接在浏览器地址栏打开JSON的URL，如果返回的是JSON内容，说明网络没问题；如果是404或500，那问题出在路径或服务端，跟lottie无关。

第二步，用官方在线播放器验证JSON文件本身是否是合法的lottie文件。拖进lottiefiles官网的播放器里看一眼，如果官方播放器也播不了，说明是JSON文件的问题，要回到AE重新导出。

第三步，检查容器尺寸。lottie渲染出的动画，宽度和高度会按JSON里w和h字段等比适配，但容器如果没有设定明确尺寸，可能被CSS压缩成0×0，所以就“白屏”了。给容器设个显式高度，比如height: 300px，基本能解决。

注意：lottie不会主动撑开容器高度，它只会填充容器尺寸。这是新手最最容易犯的错。

5.2 动画播放卡顿、掉帧严重

症状：动画能播，但肉眼可见掉帧，CPU占用率高。

原因和解决：

先分析JSON复杂度。用Chrome DevTools的Performance面板录制一段动画播放过程，看长任务和Scripting耗时。如果Scripting时间占比极高，说明SVG解析和元素操作压力大，优先换成Canvas渲染模式。

再看是不是多个lottie实例同时播放。页面上同时有5个动画实例，每个都在跑独立的RAF循环，卡顿很正常。解决思路是合并实例，或者错峰播放（非可视区域暂停）。

最后看是不是绘制了超大SVG画布。JSON里的w和h字段是设计稿尺寸，如果以很大的CSS尺寸显示（比如全屏），SVG的绘制面积巨大，性能急剧下降。优化方案是控制动画的显示尺寸，不要无脑全屏放大，必要时可以加上高斯模糊或降采样等视觉手段来掩盖细节丢失。

5.3 使用React/Vue生命周期时动画不显示

这个问题非常有代表性。在React组件里，如果直接在componentDidMount或useEffect里loadAnimation，偶尔会遇到动画不显示的情况。根因在于生命周期里容器DOM还没完成挂载，或者后来被React重新渲染覆盖了。

我的做法是，把lottie实例的创建放到requestAnimationFrame或setTimeout 0里，确保DOM稳定后执行。同时注意在卸载时调用lottie.destroy()，并取消未完成的RAF引用。

在Vue里也是一样的思路。我在一个Vue2项目中封装过组件，核心逻辑是mounted中创建实例，beforeDestroy中销毁，并监听数据变化重新加载动画：

vue复制<template>
  <div ref="container"></div>
</template>

<script>
import lottie from 'lottie-web';

export default {
  props: {
    animationData: Object
  },
  mounted() {
    this.initAnimation();
  },
  methods: {
    initAnimation() {
      this.lottieInstance = lottie.loadAnimation({
        container: this.$refs.container,
        renderer: 'svg',
        loop: true,
        autoplay: true,
        animationData: this.animationData
      });
    }
  },
  beforeDestroy() {
    if (this.lottieInstance) {
      this.lottieInstance.destroy();
      this.lottieInstance = null;
    }
  }
};
</script>

5.4 如何实现动画循环播放指定片段

有个场景很常见：引导页动画先播一段“入场+主展示”，然后循环播放主展示部分，不需要重新走入场。

实现方式是用playSegments：

javascript复制animation.addEventListener('DOMLoaded', () => {
  // 先播0到60帧（入场）
  animation.playSegments([0, 60], false);
  animation.addEventListener('segmentStart', () => {
    // 播放到60帧结束时，切换到60-150帧循环
    animation.playSegments([60, 150], true);
  });
});

playSegments的第二个参数forceFlag很关键：当为false时，如果当前正在播放同一个片段，不会重新触发；为true时强制跳转并播放。

5.5 动态修改动画里的颜色和文案

这个操作在品牌定制、主题换肤场景里非常常用。我的实现思路分三种：

第一种，修改CSS变量。如果动画是SVG模式，那么所有形状都是DOM节点，可以用CSS变量控制颜色。前提是设计师在AE里用了固定的纯色，并且你提前约定好颜色的类名或DOM结构。我在加载完成后通过document.querySelectorAll修改对应元素的fill或color属性。

第二种，直接改JSON数据。加载前先深拷贝一份JSON对象，修改对应图层属性，再传给animationData。这适合需要批量修改颜色且不想依赖DOM结构的情况。但要注意，修改完后的JSON要保证结构合法，否则lottie解析会报错。

第三种，利用lottie的renderer暴露的接口。在实例化后，通过animation.renderer.elements拿到内部图层对象，直接修改其数据属性并调用animation.renderer.renderFrame()刷新。这个方法比较底层，要对lottie内部结构熟悉才能用，弄不好容易破坏内部状态，我平时用得不多。

5.6 常见问题速查表

5.7 独家避坑清单

下面这些坑我是实打实踩过的，每个都花了不少时间排查。

坑一：SVG模式下动画没有设置preserveAspectRatio属性，导致高宽比异常。

lottie默认的rendererSettings里的preserveAspectRatio默认是xMidYMid meet，动画等比缩放。但如果你的容器是100%宽、100%高，动画内容可能被上下留白或裁切。可以显式设置：

javascript复制lottie.loadAnimation({
  ...
  rendererSettings: {
    preserveAspectRatio: 'xMidYMid slice'
  }
});

坑二：动画加载完成前就去操作内部元素，报错或找不到元素。

一定要等DOMLoaded事件触发后再操作内部DOM。我见过有人直接用setTimeout 500去querySelector，网络慢一点就挂了，或者拿到的是null。用事件回调是最可靠的。

坑三：多次loadAnimation同一个容器，导致多个实例重叠渲染。

同一个容器DOM上重复创建实例，不会自动覆盖旧的，而是会渲染多个动画层级，视觉上表现为画面错乱或异常闪烁。解决办法是在加载前先调用lottie.destroy()或者检查容器是否已有实例。

坑四：setSpeed在移动端低端机上加速播放时掉帧。

这跟浏览器性能有关，不是lottie的Bug。低端机加速播放意味着每帧的处理压力也同步放大。如果业务必须加速，考虑降低动画复杂度和分辨率。

坑五：JSON文件中包含大段无效数据，加载慢。

有些Bodymovin版本导出时会在assets里附带一些未引用的预合成数据，实际上没用到，但文件体积白白变大。可以用JSON工具分析一下assets数据有没有被引用，没有的话手动剔除。

6. 项目落地体验与扩展思路

6.1 从零到一的项目落地记录

我之前做过一个积分商城的引导页，用了lottie.js做主视觉动画。需求是一段约4秒的入口动画：品牌logo从放大至恢复正常，然后一个钱包图标旋转入场，最后引导文案逐字显现。设计在AE里做好后，导出的JSON大小是180KB，gzip后约50KB。

我当时的接入方案是：

1. 设计提供JSON文件后，先用官方播放器预览确认效果。
2. 项目里封装一个Lottie组件，统一管理加载、播放事件和销毁逻辑。
3. 首屏用懒加载，动画区域进入视口后再初始化。
4. 使用SVG渲染（该动效复杂度中等，SVG清晰度最好）。
5. 播放完成后，在complete事件里隐藏动画容器，显示后续内容，避免动画循环干扰浏览。

整个接入耗时不到半天，后来设计调整了两次动画（改颜色、改文案），我只在JSON文件里改了对应字段，前端代码一行没动，项目如期上线。

6.2 扩展到更多场景

lottie.js能做的事情，远不止页面装饰动画。我实际验证过能落地的场景还有很多：

品牌倒计时：用动画呈现倒计时数字，配合进出场缓动，比纯CSS做出来细腻得多。

数据可视化动效：用lottie做图表入口的微动效，比如柱状图增长动画、饼图展开动画，比手写Canvas的复杂度低得多。

加载指示器：自定义的loading动画。用Fragment缓存JSON，在应用启动时提前解析，后续加载loading页面时几乎瞬间出动画。

滚动驱动的叙事页面：用lottie的goToAndStop结合滚动位置，控制一个长动画的播放进度，实现翻页叙事效果。实现方式很简单，监听scroll事件，计算滚动百分比，然后调用goToAndStop(百分比 * totalFrames, true)，动画就跟随滚动了。这个效果在很多品牌官网和产品介绍页里很常见，一帧帧地跟着用户滚动播放，体验极好。

6.3 踩过坑后对lottie生态的几点思考

lottie.js最大的价值不是“播放动画”，而是它建立了一个生产-消费的标准化链路。设计师在AE里产出，前端只需接入一个JSON，中间环节的可变因素被压到了最低。这个思路，其实很像视频行业从逐帧存储（Filmstrip）演进到编码压缩（H.264）的路径——用计算换存储、用数据换取可塑性和可控性。

但从工具链角度看，lottie仍有不少痛点。第一，Bodymovin插件版本和lottie-web的兼容性需要严格对齐，不同版本之间偶有解析差异；第二，AE里90%的常用动效都能支持，但总有10%的高级特性会出错，需要设计师配合规避；第三，社区的资料和最佳实践相对分散，遇到问题往往要翻GitHub issues。

如果你准备在团队里规模化使用lottie，我的建议是：约定一份《AE动效设计规范》，明确哪些效果可用、哪些不可用、图层怎么命名、输出格式怎么设置。这份规范能让设计师和开发者在问题发生前就对齐边界。好的工具流程，一定是靠规则约束跑起来，而不是靠临时救火。

另外，如果你负责的页面需要做性能预算，把lottie动画文件算进去，设定500KB为红线（gzip后）。超过这个值，就该和设计师商量简化动效，或者考虑是不是有部分位图素材可以替换成矢量路径。动画再好，页面也还是要能秒开。

最后再分享一个小技巧：lottie的JSON文件其实是一个纯数据文件，你完全可以把它放在版本管理里，和代码一起走评审和发布流程。不要把它丢到某个临时图片文件夹里不管，否则下次想修改时，很难找到对应的源文件是哪个版本。我们在团队里用git管理JSON文件的同时，约定文件名带上设计源文件的版本号（比如onboarding_v3.json），这样回溯起来非常清晰。