服务端5月30日 23:22
React Native 中如何正确接入 Lottie 动画？在 React Native 里接入 Lottie，核心不是把组件渲染出来，而是把安装、资源路径、播放控制和性能边界都处理好。很多项目第一次接入能跑，后面却在 Android 缺资源、iOS 没 pod、列表卡顿、远程 JSON 加载失败上反复踩坑。建议把 Lottie 当成一种需要生命周期管理的原生视图，而不是普通图片组件。
## 安装和基础配置
常规项目先安装 `lottie-react-native`，iOS 再执行 Pod 安装。Expo 项目要确认 SDK 版本支持的 Lottie 版本，不要随意升级到不匹配的包。动画 JSON 可以用本地 `require`，也可以远程加载；稳定性优先的启动页、支付成功、空状态动画，建议随包发布。
```bash
npm install lottie-react-native
cd ios && pod install
```
```tsx
import LottieView from 'lottie-react-native';
import { useEffect, useRef } from 'react';
export function LoadingLottie() {
const ref = useRef<LottieView>(null);
useEffect(() => {
ref.current?.play();
return () => ref.current?.reset();
}, []);
return (
<LottieView
ref={ref}
source={require('./assets/loading.json')}
autoPlay={false}
loop
style={{ width: 120, height: 120 }}
/>
);
}
```
## 播放控制要跟页面状态绑定
`autoPlay` 很方便，但复杂页面不建议到处开。更稳的方式是用 `ref` 控制 `play`、`pause`、`reset`，并在页面不可见、弹窗关闭或列表项离屏时暂停。进度联动可以用 `progress`，但频繁从 JS 更新 progress 会有成本，手势场景要特别留意掉帧。
```tsx
function ResultAnimation({ active }: { active: boolean }) {
const ref = useRef<LottieView>(null);
useEffect(() => {
if (active) ref.current?.play(0, 60);
else ref.current?.pause();
}, [active]);
return <LottieView ref={ref} source={require('./success.json')} loop={false} />;
}
```
## Android 和 iOS 的边界不完全一样
Android 更容易遇到硬件加速、图片资源目录和低端机掉帧问题；iOS 更常见的是 Pod、版本兼容和资源打包问题。不要把一端验证通过当成全端通过，尤其是包含渐变、遮罩、文本图层的动画。上线前至少用一台低端 Android 和一台旧 iPhone 跑真实页面，不要只看模拟器。
## 推荐的组件封装
业务里可以封一层轻量组件，把尺寸、循环、错误降级和播放时机收口。这样设计更新动画时，页面不用到处改参数；如果某个版本播放器有兼容问题，也能集中降级。封装不要太厚，保留 `source`、`loop`、`onAnimationFinish` 这类常用能力即可。
```tsx
type Props = { source: object; active: boolean; size?: number };
export function AppLottie({ source, active, size = 120 }: Props) {
const ref = useRef<LottieView>(null);
useEffect(() => { active ? ref.current?.play() : ref.current?.pause(); }, [active]);
return <LottieView ref={ref} source={source} style={{ width: size, height: size }} />;
}
```
## 远程加载要有降级和缓存
如果业务必须远程下发 JSON，至少要准备加载中占位、失败静态图和版本缓存。接口返回后不要直接相信内容可播放，可以先校验 `fr`、`op`、`layers` 等关键字段，再交给 LottieView。否则一次错误配置就可能让页面出现空白区域，用户不会知道这是动画资源坏了，只会觉得页面没做好。
缓存也要有边界。运营动画可以短缓存，关键流程动画最好随 App 版本固定，避免服务端改动影响老客户端。需要灰度时，可以把动画版本号写进配置，出现兼容问题时回滚到上一个 JSON，而不是临时发版。
## 追问
### 本地 JSON 和远程 JSON 应该怎么选？
本地 JSON 稳定、首屏可控，适合关键流程和无网也要展示的动画。远程 JSON 灵活，适合运营活动、节日皮肤和可灰度替换的内容，但要处理加载失败、缓存和版本回滚。取舍在于更新频率和可靠性：越关键越本地，越运营越远程。踩坑点是远程 JSON 改了字段后旧 App 播放器不兼容，结果线上动画直接空白。
### `autoPlay` 和手动 `play()` 有什么区别？
`autoPlay` 会在组件挂载后自动开始，写法简单，适合单个静态页面。手动 `play()` 可以跟页面焦点、弹窗状态、接口完成时机绑定，更适合真实业务。边界是如果组件频繁挂载卸载，`autoPlay` 可能导致动画重复从头播放，看起来像闪烁。复杂页面里宁愿多写几行生命周期控制，也不要让动画自己乱跑。
### React Native 列表里使用 Lottie 为什么容易卡？
列表滚动时，LottieView 作为原生视图创建成本不低，多个动画同时播放会叠加解析和绘制压力。更稳的做法是默认显示静态首帧，只有选中、曝光或需要强调的 item 才播放。FlatList 参数也要控制窗口大小和初始渲染数量。取舍是视觉动感少一点，但滚动不会被动画拖垮。
### 动态换色应该改 JSON 还是用 `colorFilters`？
如果只有少量主题色，设计导出多份 JSON 最稳，测试成本低。需要运行时跟随品牌色或暗黑模式时，可以用 `colorFilters`，但前提是图层 keypath 命名稳定。踩坑是设计改了图层名，客户端过滤器失效却不报错。边界是渐变、图片、预合成里的颜色不一定能被简单过滤器覆盖。
### 动画不显示时应该按什么顺序排查？
先确认 JSON 能在 LottieFiles 或设计工具里正常预览，再看 RN 资源路径、包版本和平台构建日志。Android 缺图片时检查资源目录，iOS 异常时先确认 `pod install` 和 clean build。然后再排查样式尺寸，因为 `width/height` 为 0 也会让你误以为动画坏了。不要一开始就重装依赖，很多问题其实只是路径或容器尺寸。标签
Lottie
Lottie 是一个流行的开源库，用于在移动设备、Web 和其他平台上渲染高质量的动画。这些动画由 Adobe After Effects 制作并导出为 JSON 格式，然后利用 Lottie 轻松地嵌入到任何应用或网站中。Lottie 是由 Airbnb 设计团队开发的，它使设计师和开发者能够在不牺牲性能和质量的情况下，使用简单的动画文件在多个平台上实现复杂的动画效果。
服务端5月30日 23:22
Lottie JSON 文件里每个字段到底表示什么？Lottie JSON 可以理解成一份“动画说明书”：顶层描述画布和时间轴，`layers` 描述图层，`ks` 描述变换属性，`shapes` 描述矢量形状，`assets` 描述图片或预合成资源。真正排查问题时，不需要背完整规范，但要能看懂几个关键字段，否则遇到动画不显示、颜色改不了、体积异常时只能反复让设计重新导出。
## 顶层字段先看时间和画布
常见顶层字段包括 `v`、`fr`、`ip`、`op`、`w`、`h`、`assets` 和 `layers`。`fr` 是帧率，`ip/op` 是起止帧，动画时长通常可以用 `(op - ip) / fr` 估算。`w/h` 是设计画布，不等于组件最终显示尺寸，但会影响缩放比例和裁切判断。
```json
{
"v": "5.10.2",
"fr": 30,
"ip": 0,
"op": 90,
"w": 375,
"h": 240,
"assets": [],
"layers": []
}
```
## layers 是排查的入口
`layers` 数组决定动画由哪些图层组成。`ty` 表示图层类型，常见的 `4` 是形状图层，`2` 是图片图层，`0` 是预合成，`1` 是文本。每个图层通常有 `ip/op` 控制它何时出现，`ks` 控制位置、缩放、旋转和透明度。遇到某一段动画消失，先看对应图层的起止帧和透明度，不要急着怀疑播放器。
```json
{
"ty": 4,
"nm": "check-icon",
"ip": 0,
"op": 60,
"ks": {
"p": { "a": 0, "k": [120, 80, 0] },
"s": { "a": 0, "k": [100, 100, 100] },
"o": { "a": 1, "k": [{ "t": 0, "s": [0] }, { "t": 10, "s": [100] }] }
}
}
```
## shapes 和 assets 决定复杂度
形状图层里的 `shapes` 会包含路径、填充、描边、组和变换。路径点越多、遮罩越多、渐变越复杂，运行时计算越重。`assets` 则存图片、预合成等资源，图片路径通常由 `u` 和 `p` 拼出来。生产环境要确认这些资源能被打包或上传到 CDN，否则 JSON 正常，动画却缺图。
如果要做自动检查，可以先抽取几个字段，统计图层数量、图片数量和关键帧属性数量。这个脚本不替代真机测试，但能在代码评审阶段拦下一部分明显过重的动画。
```js
function inspectLottie(data) {
return {
frameRate: data.fr,
duration: (data.op - data.ip) / data.fr,
layers: data.layers?.length ?? 0,
assets: data.assets?.length ?? 0
};
}
```
## 不要把 JSON 当成稳定业务协议
虽然 Lottie JSON 是文本格式，但它首先是动画导出产物，不适合让业务代码深度依赖内部层级。比如今天图层叫 `button-bg`，设计明天合并预合成后路径就变了，客户端按 keypath 改色可能立刻失效。更稳的方式是只读取少量稳定元信息，把主题色、文案、播放区间这类业务配置放在自己的配置文件里。
排查线上问题时也要保留原始 JSON 和压缩后 JSON。压缩工具可能会改字段顺序、删除名称或合并路径，体积变小了，但可调试性会下降。团队如果需要运行时换色或按图层埋点，就不要在构建阶段把所有 `nm` 字段都删掉。
## 追问
### 为什么同一个 Lottie JSON 在不同端表现不一致？
因为 Lottie 是规范加运行时实现，不是所有 AE 能做出的效果都能被各端完整支持。Web、iOS、Android 对遮罩、表达式、渐变、文本和某些混合模式的支持存在差异。取舍上，跨端业务动画应少用高级特效，多用基础形状和透明度变化。踩坑最多的是设计在 AE 里看着正常，导出后某端把效果直接忽略了。
### `ks` 里的 `a: 0` 和 `a: 1` 有什么区别？
`a: 0` 表示这个属性是静态值，`k` 里直接放当前值；`a: 1` 表示它有关键帧，`k` 会变成关键帧数组。排查性能时，有关键帧的属性越多，运行时插值计算越多。边界是关键帧不是坏事，动画本来就靠它，只是不要让每个小装饰都做复杂路径变形。读 JSON 时先看 `p/s/r/o` 这些变换属性，效率最高。
### 修改 JSON 里的颜色安全吗？
简单填充色通常可以改，比如 `fl.c.k` 里的 RGBA 数组，但并不总是安全。颜色可能被渐变、透明度、预合成或命名层级影响，直接全局替换很容易误伤。更稳的做法是让设计给关键图层命名，再在运行时用 `keypath` 或导出多套主题文件。取舍是动态换色更灵活，但对图层命名和测试要求更高。
### 图片资源应该内联 base64 还是外部文件？
内联 base64 部署简单，少一次资源路径配置，但会让 JSON 变大，也让缓存粒度变差。外部图片更适合 CDN、WebP 压缩和多动画复用，但需要处理路径、打包和离线缓存。移动端项目通常更推荐把图片作为本地资源随包发布，Web 项目则看首屏策略和缓存命中率。边界是很小且只用一次的图标可以内联，大图和复用资源不要内联。
### 如何快速判断一个 JSON 是否可能有性能问题？
先看文件体积、`layers` 数量、路径点数量、是否有大量 `masksProperties`、`ef` 和图片资源。再估算时长和帧率，长动画加 60fps 通常要谨慎。这个判断不是最终结论，但能帮助你决定是先找设计减图层，还是先改客户端播放策略。踩坑是只看压缩后大小，忽略未压缩 JSON 在解析时仍然很重。服务端5月30日 23:22
Lottie 动画卡顿时应该从哪些地方优化？Lottie 性能优化不要一上来就改代码，先看它到底慢在哪里：是 JSON 太大、路径太复杂、同时播放太多，还是列表滚动时反复挂载。Lottie 本质上是把 After Effects 导出的描述数据交给运行时逐帧解释，文件越复杂，解析、布局、绘制和内存压力都会上来。比较稳的做法是先减设计稿复杂度，再做加载和播放策略，最后才调平台参数。
## 先把 JSON 变轻
最有效的优化往往发生在导出前。减少形状图层、合并静态元素、避免大量遮罩和表达式，比在客户端包一层缓存更可靠。帧率也要按场景取舍：启动页或按钮反馈用 24/30fps 通常够用，只有大面积流体动画才值得保留 60fps。图片资源不要直接塞进 base64，体积会膨胀，也不利于 CDN 和本地缓存。
```json
{
"fr": 30,
"ip": 0,
"op": 72,
"assets": [{ "id": "image_0", "u": "images/", "p": "logo.webp" }]
}
```
## 播放策略比参数更重要
页面里能不自动播放就不要自动播放，尤其是列表、Tab 首页和弹窗背景动画。可见时播放、离屏暂停、只循环关键动画，通常比盲目开启硬件加速更稳。React 或 React Native 里还要避免父组件重渲染导致 LottieView 反复创建，动画数据最好静态 require 或 memo 化。
```tsx
const source = require('./success.json');
export function SuccessLottie({ visible }: { visible: boolean }) {
const ref = useRef<LottieView>(null);
useEffect(() => {
visible ? ref.current?.play() : ref.current?.pause();
}, [visible]);
return <LottieView ref={ref} source={source} loop={false} autoPlay={false} />;
}
```
## 如何定位真正的瓶颈
先用网络面板看 JSON 下载和解析耗时，再用性能工具观察掉帧发生在进入页面、开始播放还是滚动过程中。如果首次进入慢，多半是体积、远程加载和解析问题；如果播放中掉帧，多半是路径、遮罩、渐变或同时播放数量问题；如果滚动时卡，重点看挂载数量和可见区域播放策略。
团队里最好给 Lottie 建一个简单准入标准：文件大小、图层数量、最长时长、是否使用图片、是否有低端机实测。标准不需要复杂，但要能在设计交付前发现问题。否则每次都等开发接入后才说卡，返工成本会很高。
## 交付前要和设计约定清楚
Lottie 优化不应该只由开发兜底。设计交付时最好同时给出预览文件、目标尺寸、是否循环、是否允许降级成静态图，以及用到的字体和图片资源。开发侧则反馈真机帧率、首屏加载耗时和内存变化。这个协作看起来麻烦，但能避免动画上线前一天才发现某个遮罩在 Android 上不支持。
还有一个容易忽略的点是结束态。很多动画播放完要停在最后一帧，如果 JSON 的 `op` 多留了空白帧，用户会看到短暂停顿；如果循环动画首尾没有对齐，又会出现明显跳帧。这类问题不靠性能参数解决，只能回到时间轴调整。
## 追问
### Lottie 文件越小就一定越流畅吗？
不一定，文件大小只影响下载和解析的一部分成本。一个 80KB 但包含大量路径变形、遮罩和渐变的动画，可能比一个 200KB 的图片序列更吃 CPU。优化时要区分网络体积和渲染复杂度，前者靠压缩和缓存，后者要回到 AE 图层和路径数量。踩坑点是只盯 gzip 后大小，结果低端 Android 还是掉帧。
### Canvas、SVG 和原生渲染应该怎么选？
Web 端小图标、需要 DOM 可访问性或调试时，SVG 更直观；大面积、路径多、频繁播放的动画，Canvas 往往更省。React Native 里主要依赖原生 Lottie 渲染，重点不是选 SVG/Canvas，而是控制同时播放数量和资源释放。取舍在于清晰度、可交互性和性能，不能只看某个 renderer 的平均帧率。边界是动画如果依赖 AE 的高级效果，换渲染模式也可能不支持。
### 硬件加速是不是总应该打开？
不是。硬件加速能减少部分绘制压力，但也可能增加纹理内存，多个大尺寸动画同时播放时反而更容易抖。Android 上可以对全屏复杂动画尝试 `renderMode=HARDWARE`，但小图标或静态结束态未必需要。实践里要按设备分层测试，尤其关注低端机、弱网首次加载和页面切后台再回来。不要把硬件加速当成万能开关。
### 列表里每个 item 都有 Lottie 怎么办？
列表中最常见的坑是每个 item 都 `autoPlay`，滚动时动画创建和销毁叠在一起，JS 线程和 UI 线程都会被打满。更好的方案是只让当前可见或被选中的 item 播放，其余显示首帧或静态图。FlatList 还要配合 `windowSize`、`removeClippedSubviews`、`initialNumToRender` 控制挂载数量。取舍是交互反馈会变克制，但滚动体验会明显稳定。
### 什么时候应该放弃 Lottie，改用视频或静态图？
如果动画包含大量粒子、模糊、阴影、3D、长时间渐变背景，Lottie 不一定是合适载体。它适合矢量、短时、可缩放的 UI 动效，不适合把复杂视频效果硬转成 JSON。边界判断很简单：优化后仍然掉帧、JSON 难以维护、设计还要大量 AE 特效时，可以换 MP4/WebM 或首帧静态图。性能优化不是坚持某个技术，而是让用户少等、少卡、少耗电。服务端5月30日 22:56
如何在 Web 项目里稳定集成 Lottie 动画？Web 项目里接 Lottie，看起来只是引入一个 JSON，实际要同时处理加载、渲染器、生命周期、降级和性能。很多页面一开始播放很顺，等营销活动上线、多个动画同时进首屏，就会出现掉帧、内存泄漏或移动端白屏。比较稳的做法是：先确定动画用途，再选接入方式，最后把播放控制和销毁逻辑写进组件生命周期里。
## 先选接入方式
如果只是运营页放一个循环动画，`<lottie-player>` 上手最快，HTML 里声明 src、loop、autoplay 就能跑，适合低代码页面或非复杂交互。缺点是可控性有限，深度定制和精细事件管理不如直接用 lottie-web。React、Vue、Angular 项目里，如果动画要和按钮点击、滚动进度、表单状态联动，建议直接封装 lottie-web；这样能拿到实例，控制 play、pause、stop、goToAndStop、setSpeed 和 destroy。
安装时用 npm 包比直接挂 CDN 更可控，版本也能锁住。动画 JSON 可以放 public 目录走 URL，也可以作为模块 import 进来。前者适合大文件和 CDN 缓存，后者适合小动画、构建时一起校验；边界是不要把很多大型 JSON 全部打进首屏 bundle，否则还没播放动画，页面 JS 就先变重了。
```jsx
import { useEffect, useRef } from 'react'
import lottie from 'lottie-web'
export function LottieBox({ path, loop = true }) {
const el = useRef(null)
useEffect(() => {
if (!el.current) return
const anim = lottie.loadAnimation({
container: el.current,
renderer: 'svg',
loop,
autoplay: true,
path
})
return () => anim.destroy()
}, [path, loop])
return <div ref={el} aria-hidden="true" />
}
```
## 渲染器不是随便选
lottie-web 常见渲染器有 svg、canvas 和 html。SVG 清晰、可缩放、方便调试，也适合图层不太多的图标和插画动画；Canvas 对大量元素或频繁变化更友好，但不如 SVG 容易被 CSS 精细控制。HTML 渲染器使用场景较少，除非你明确知道它解决了什么问题，否则不要默认选它。
如果动画需要响应式尺寸，容器用 CSS 控制宽高，实例创建后在 resize 时调用 `animation.resize()`。如果页面里有多个 Lottie，别让它们全部 autoplay；进入视口再加载，离开视口暂停，通常比事后抱怨“Lottie 性能差”有效得多。对于装饰动画，还要考虑 `prefers-reduced-motion`，用户系统设置减少动态效果时，应停用自动播放或改成静态图。
```js
const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches
const observer = new IntersectionObserver(([entry]) => {
if (entry.isIntersecting && !reduceMotion) animation.play()
else animation.pause()
})
observer.observe(container)
```
## 加载失败和降级要提前设计
线上最常见的问题不是 API 不会用，而是 JSON 路径 404、跨域配置缺失、图片资源没一起上传、组件卸载后实例还在跑。接入时至少监听 `data_failed`，并给容器准备一张静态 fallback。动画文件走 CDN 时，缓存时间可以长一点，但文件名最好带 hash；如果同名文件被替换，用户本地缓存旧 JSON，前端代码却按新结构控制帧，问题会很隐蔽。
颜色和文案动态修改也要克制。直接改 JSON 内部结构可以做到，但它依赖 AE 导出的层级和 keypath，一旦设计师重命名图层就会失效。更稳的方式是把需要变体的动画提前拆好，或约定图层命名规范，再用测试覆盖关键路径。
## 追问
### 用 lottie-web 还是 LottieFiles Player 更好？
如果只是展示动画，LottieFiles Player 简洁，交给内容同学维护也方便。需要和业务状态联动时，lottie-web 更合适，因为实例 API 更直接，生命周期也更可控。取舍点是开发成本和控制能力：越靠近业务逻辑，越不该把控制权藏在 Web Component 里。踩坑是先用 Player 快速上线，后面要按滚动进度控制帧，结果又重写一遍。
### SVG 和 Canvas 渲染器怎么选？
SVG 适合小型、清晰、可缩放的动效，比如图标、空状态、按钮反馈。Canvas 更适合图层多、变化频繁的动画，但它不方便逐个节点用 CSS 控制，也要注意高清屏缩放。边界是不要凭感觉选，拿同一份 JSON 在目标机型上测 FPS 和内存。常见坑是桌面浏览器 SVG 很顺，低端 Android 同时播放三个后就明显卡顿。
### Lottie 动画应该打进 bundle 还是放 CDN？
小而关键的动画可以随包引入，构建能发现 JSON 是否存在，离线体验也更简单。大文件、运营素材和可替换动画更适合放 CDN，通过 path 加载并设置缓存。取舍在首屏体积和发布灵活性之间：bundle 稳但重，CDN 灵活但要处理网络失败。踩坑是把十几个活动动画 import 到首页，用户还没看到它们就先下载了几 MB 的 JS。
### 组件卸载时为什么一定要 destroy？
Lottie 实例会持有 DOM、定时器、事件监听和渲染状态，单页应用路由切换后如果不销毁，内存会慢慢涨。暂停只能停播放，不等于释放资源；真正离开页面或组件时应该调用 `destroy()`。边界是弹窗临时隐藏可以 pause，组件永久卸载才 destroy。很多“页面越用越卡”的问题，最后都能追到没有清理动画实例。
### 怎么给不支持或不想看动画的用户降级？
最简单的降级是一张同尺寸静态图，加载失败、减少动态效果、低性能设备都可以显示它。复杂业务也可以降级成 CSS transition，但不要为了还原 Lottie 再写一套复杂动画。取舍是体验一致性和维护成本：静态图不酷，但稳定、便宜、可预测。踩坑是只在网速好、设备新的环境测试，线上遇到弱网时容器空白，用户以为页面没加载完。服务端5月30日 22:56
如何从 After Effects 正确导出 Lottie 动画？做 Lottie 最容易踩的坑，不在导出按钮，而在 AE 项目一开始就没按 Lottie 的边界来做。Lottie 本质是把 After Effects 动画转成 JSON，再由 Web、iOS 或 Android 的运行时解释播放；它擅长矢量形状、基础变换、遮罩和简单透明度，不擅长大量 AE 特效、复杂表达式、3D 摄像机和高分辨率位图。所以正确流程不是“动画做完再试着导出”，而是从建合成、画图层、加关键帧开始就把兼容性和性能算进去。
## 从项目设置开始控制边界
新建合成时先确认目标端：移动端图标动效通常用 300 到 600px 的正方形合成，落地页首屏动画可以按实际容器比例做，但不要直接套 1920×1080。帧率建议 30fps，只有对运动细节特别敏感的品牌动画才考虑 60fps；帧率越高，JSON 里的关键帧越密，低端机解析压力越明显。时长也要克制，加载动效 1 到 3 秒，说明性动画 5 到 8 秒通常够用。
安装 Bodymovin 后，在 AE 的 Window > Extensions 打开面板。导出前先把素材整理干净：图层命名不要用奇怪符号，预合成层级不要套太深，没用的隐藏层、参考层、测试图层都删掉。位图能不用就不用，必须用图片时压缩到实际显示尺寸，并确认导出包会包含 images 文件夹，否则前端只拿到 JSON 会丢图。
## 动画制作时优先用 Lottie 友好的属性
最稳的是形状图层加基础属性：Position、Scale、Rotation、Opacity、Path、Trim Paths、Fill、Stroke。这些属性在 lottie-web 和移动端运行时里支持更成熟，跨端表现也更一致。文本图层要谨慎，如果目标端没有对应字体，最终会出现换行、字重或位置偏移；需要完全一致时，可以把文字转成形状，但代价是文件变大、后续改文案不方便。
常见做法是先把 AI 或 Figma 里的矢量拆成清晰分组，再在 AE 里转成 Shape Layer。不要把一个复杂 SVG 全部塞进单个图层，后期调动画会很痛苦；也不要拆成几十上百层同时动，浏览器渲染会卡。比较稳的取舍是：需要独立运动的元素单独成层，只作为静态装饰的元素合并成组。
```js
// 导出前可按这个方向检查，不是 AE 脚本
const lottieChecklist = {
fps: 30,
duration: '<= 8s',
preferred: ['shape', 'position', 'scale', 'rotation', 'opacity', 'trim paths'],
avoid: ['3d layer', 'camera', 'heavy effects', 'unsupported expressions'],
image: 'use only when vector is too expensive'
}
```
## 用 Bodymovin 导出并验证
在 Bodymovin 面板里刷新合成，选择要导出的 Composition，设置输出路径后点击 Render。一般建议关闭 Demo HTML、开启压缩，先不要勾太多实验选项；如果动画依赖图片，确认 Assets 路径正确。导出后不要直接交付，先把 JSON 上传到 LottieFiles Preview 或本地 lottie-web 页面里看一遍，重点检查图层缺失、遮罩方向、透明度、缓动节奏和文件体积。
如果预览和 AE 不一致，先回 AE 查 unsupported features，而不是让前端硬调。Lottie 的问题往往不是“代码没写对”，而是 JSON 里根本没有 AE 某个效果的等价表达。最终交付时最好同时给出 JSON、图片资源、建议尺寸、是否循环、背景是否透明、期望播放触发时机，这些信息能减少很多联调误会。
## 追问
### 为什么 AE 里正常，导出成 Lottie 后效果丢了？
因为 Bodymovin 不是录屏工具，它只会把支持的图层和属性翻译成 JSON。模糊、粒子、部分混合模式、复杂表达式、3D 摄像机这类效果经常无法完整转换。取舍上，如果必须百分百还原复杂视觉，视频或 APNG 可能更稳；如果要小体积、可交互、可换色，才更适合 Lottie。踩坑点是设计师最后一天才导出测试，发现核心效果不支持时已经没有重做时间。
### 文字要保留为文本图层，还是转成形状？
保留文本的好处是 JSON 较小，也方便以后换文案，但它依赖运行环境字体，跨端一致性差。转成形状后视觉更稳定，缺点是路径数量增加，文件会变大，动态改字也基本不可行。边界是品牌 Logo、固定标题可以转形状，运营文案、国际化内容不建议这么做。常见坑是中文字体在 Web 上没有加载成功，AE 里一行字到浏览器里变成两行。
### 什么时候该用图片，不该强行全矢量？
简单图标、线条、几何图形优先矢量，缩放清晰，也容易改颜色。复杂插画如果路径点特别多，矢量 JSON 反而会比压缩图片更重，播放时还更吃 CPU。取舍标准可以看实际包体和帧率：同样视觉下，哪个更小、更稳就用哪个。踩坑是为了“保持矢量”把几千个路径点塞进 Lottie，结果首屏动画比一张 WebP 还卡。
### 导出文件多大算合理？
没有绝对数字，但用于按钮、空状态、加载反馈的 Lottie，通常应控制在几十 KB 到两三百 KB。首屏大动画可以更大，但要配合懒加载、缓存和降级图。边界在于 Lottie 是运行时解析 JSON，不是浏览器原生视频解码，文件越复杂越容易把主线程拖慢。不要只看 JSON 体积，还要在目标设备上看掉帧、发热和首次播放延迟。前端5月27日 18:25
Lottie 支持哪些动画类型和效果？## Lottie 到底支持哪些动画类型和效果？
Lottie 是 Airbnb 开源的跨平台动画渲染库，能将 After Effects 导出的 JSON 文件在 Web、iOS、Android 等平台上高效播放。但 Lottie 并不支持 AE 的所有特性——了解它的能力边界，才能在设计和开发中少走弯路。
## 基础变换动画
基础变换是 Lottie 支持最完整的动画类型，涵盖图层的四个核心属性：
- **位置（Position）**：控制图层在画布上的 X/Y/Z 坐标，支持多关键帧和贝塞尔曲线插值。这是最常用的动画属性，从元素位移到弹跳效果都依赖它。
- **缩放（Scale）**：控制图层的 X/Y/Z 缩放比例，100 表示原始尺寸。可以实现放大、缩小、拉伸等效果。
- **旋转（Rotation）**：控制图层绕锚点旋转的角度，支持 0-360 度及更多圈数。常用于图标旋转、指针转动等场景。
- **不透明度（Opacity）**：控制图层的透明度，0 为完全透明，100 为完全不透明。淡入淡出是最典型的应用。
这四个属性是 Lottie 动画的基石，所有平台均完整支持，且性能开销极小。
## 形状动画
Lottie 对矢量形状的动画支持非常丰富：
- **路径变形（Path Animation）**：通过关键帧插值路径的顶点（v）、入贝塞尔手柄（i）、出贝塞尔手柄（o），实现形状之间的平滑变形。这是 Lottie 最强大的动画能力之一，液体变形、图标切换等效果都靠它实现。
- **圆角矩形（Rectangle）**：支持尺寸和圆角半径的动画，圆角从 0 变到正值可以实现从方到圆的过渡。
- **椭圆（Ellipse）**：支持尺寸动画，可以实现圆形呼吸、椭圆拉伸等效果。
- **星形和多边形（Polystar）**：支持点数、外径、内径等属性的动画，可以实现星形旋转展开等效果。
- **修剪路径（Trim Path）**：这是经常被忽略但非常实用的功能——可以控制路径的起止百分比，实现描边绘制、进度条、环形加载等效果。
## 填充与描边动画
颜色是 Lottie 动画的重要组成部分：
- **填充颜色（Fill）**：对形状的内部颜色做动画，支持纯色和关键帧颜色过渡。比如按钮从灰色变绿色表示启用状态。
- **描边颜色（Stroke）**：对形状的边框颜色做动画，同时支持描边宽度的动画。
- **渐变填充（Gradient Fill）**：支持线性和径向渐变，可以动画化渐变的色标位置和颜色值，实现流光、极光等视觉效果。
- **渐变描边（Gradient Stroke）**：与渐变填充类似，应用于描边。
- **不透明度动画**：填充和描边各自支持独立的不透明度属性，可以实现颜色的淡入淡出。
## 遮罩与蒙版
遮罩是 Lottie 中实现复杂视觉效果的常用手段：
- **遮罩路径（Mask Path）**：用一条路径定义可见区域，支持 Add、Subtract、Intersect、Difference 等多种混合模式。通过动画化遮罩路径，可以实现擦除、揭幕、窗口移动等效果。
- **遮罩不透明度（Mask Opacity）**：控制遮罩本身的透明度，实现渐变遮罩效果。
- **遮罩扩展（Mask Expansion）**：扩展或收缩遮罩的边缘，常配合其他属性做平滑过渡。
注意：Lottie 支持 Alpha 遮罩和 Alpha 反转遮罩，但不支持 Luma 遮罩。
## 轨道遮罩（Track Matte）
轨道遮罩是将一个图层的 Alpha 通道作为另一个图层的遮罩：
- **Alpha Matte**：用上方图层的 Alpha 通道遮罩下方图层，实现文字内嵌图片、文字揭示动画等效果。
- **Alpha Inverted Matte**：反转 Alpha 通道的遮罩效果。
轨道遮罩在文字动画和图标动画中应用非常广泛，主流平台均支持，但部分浏览器在 Canvas 渲染模式下可能有兼容性问题。
## 父子层级（Parenting）
Lottie 支持图层之间的父子关系——子图层继承父图层的所有变换属性。这意味着：
- 移动父图层时，子图层会跟随移动。
- 旋转父图层时，子图层会围绕父图层的锚点旋转。
- 一个图层只能有一个父图层，但一个父图层可以有多个子图层。
父子层级是构建复杂动画结构的基础，比如人物骨骼动画、机械联动效果都依赖它。
## 预合成（Precomposition）
预合成相当于"动画中的动画"——将多个图层打包成一个独立的合成，然后在主合成中作为一个图层使用。Lottie 完整支持预合成，这意味着：
- 可以将复杂的动画逻辑封装在预合成中，保持主时间轴清晰。
- 预合成可以嵌套使用，支持多层级的合成结构。
- 预合成内部的时间线独立于主时间线，可以通过时间重映射控制播放。
## 文本动画
Lottie 对文本的支持有一定限制，但基本功能可用：
- **文本内容**：支持静态文本显示，包括字体、字号、对齐方式、行高、字间距等属性。
- **文本动画**：可以通过逐字（Per-character）动画实现打字机效果、文字逐字飞入等。
- **文本颜色**：支持填充颜色的动画。
需要注意：Lottie 对文本动画的支持不如 After Effects 原生丰富，复杂的文本动画器（如 Range Selector）支持有限。中文字体需要确保客户端已安装对应字体，或使用图片替代方案。
## 3D 变换
Lottie 支持基本的 3D 变换属性：
- **X 轴旋转（Rotation X）**：绕 X 轴旋转，实现前后翻转效果。
- **Y 轴旋转（Rotation Y）**：绕 Y 轴旋转，实现左右翻转效果。
- **Z 轴旋转（Rotation Z）**：即普通 2D 旋转。
- **3D 位置**：支持 Z 轴位置属性。
但要注意，Lottie 的 3D 是伪 3D——它不包含真正的 3D 渲染管线，没有光影、透视网格等效果。3D 变换本质上是对 2D 图层做仿射变换的模拟。
## 时间重映射（Time Remapping）
时间重映射允许你对预合成的播放时间做动画控制：
- 可以加速、减速、倒放预合成内的动画。
- 可以实现动画暂停后再继续播放的效果。
- 配合表达式可以实现循环播放（但表达式支持有限，建议用关键帧实现）。
这是制作交互式动画的关键功能——比如用户点击时，动画从特定帧开始播放。
## 缓动函数（Easing）
Lottie 完整支持 After Effects 的关键帧缓动：
- **贝塞尔缓动**：通过入贝塞尔手柄（i）和出贝塞尔手柄（o）定义自定义缓动曲线，对应 CSS 的 `cubic-bezier()`。
- **线性（Linear）**：匀速变化。
- **定格（Hold）**：关键帧之间不做插值，直接跳变，实现逐帧动画效果。
- **空间贝塞尔（Spatial Bezier）**：控制位置关键帧在空间中的运动路径曲线。
缓动函数对动画的质感影响极大——同样的关键帧，不同的缓动曲线会产生完全不同的视觉感受。
## Lottie 不支持的重要特性
了解不支持的特性同样重要，避免在设计阶段做无用功：
- **After Effects 表达式（Expressions）**：Lottie 不支持 AE 表达式。`wiggle()`、`loopOut()` 等表达式在导出后不会生效，必须转化为关键帧。
- **效果菜单中的滤镜**：高斯模糊、阴影、发光等 AE 内置效果不支持。如需模糊效果，可在设计时直接制作模糊状态的图层。
- **混合模式（Blend Modes）**：除正常模式外，叠加、正片叠底等混合模式不支持。
- **Luma 遮罩**：仅支持 Alpha 遮罩，不支持基于亮度的遮罩。
- **3D 图层和摄像机**：支持 3D 变换属性，但不支持 3D 图层、摄像机和灯光。
- **视频图层和音频图层**：Lottie 只处理矢量动画，不支持嵌入视频和音频。
- **部分文本动画器**：Range Selector 等高级文本动画功能支持有限。
## dotLottie 新特性（2025-2026）
Lottie 生态正在快速发展，dotLottie 格式带来了新能力：
- **状态机（State Machines）**：在动画文件中定义交互逻辑，无需编写代码即可实现点击切换、悬停响应等交互。支持 Web、iOS、Android 原生 SDK。
- **主题变量（Theming）**：通过变量替换动画中的颜色和文本，同一动画可适配不同品牌主题。
- **多动画打包**：一个 dotLottie 文件可包含多个动画，减少网络请求。
- **AI 动画生成**：Lottie Creator 已集成 AI 工具，可直接生成 Lottie 动画。
## 实际开发建议
在实际项目中使用 Lottie 动画，有几个关键点值得注意：
**渲染器选择**：Web 端 lottie-web 提供三种渲染器——SVG 兼容性最好，Canvas 性能更优，HTML 适合简单动画。复杂动画建议优先 SVG，动画元素超过 100 个时考虑 Canvas。
**性能优化**：避免单个动画文件过大，超过 100KB 的 JSON 文件应考虑拆分。减少图层数量和关键帧密度，善用预合成复用动画。
**设计协作**：设计师应在 AE 中全程使用 Lottie 支持的特性，用 Bodymovin 插件边做边预览，避免最终导出时才发现特性不支持。LottieFiles 提供的在线预览工具可以快速验证动画兼容性。
**交互控制**：通过 lottie-web 的 API 可以控制动画的播放、暂停、跳帧、速度和方向。结合 State Machines 可以实现更复杂的交互逻辑，减少前端编码量。
Lottie 的核心价值在于让设计师和开发者各司其职——设计师在 AE 中创作动画，开发者只需加载 JSON 文件即可还原，零偏差的动画交付大幅提升了协作效率。掌握 Lottie 支持和不支持的特性清单，才能在设计和开发之间建立清晰的契约。前端5月27日 18:25
Lottie 动画开发常见问题有哪些？Lottie 动画看着简单，实际开发中踩坑不少——动画白屏、列表卡顿、iOS 上好好的到 Android 就变样、颜色怎么都改不对。下面按实际遇到频率从高到低，把每个问题的根因和解决办法讲清楚。
## 动画不显示或渲染异常
白屏是最常见的问题，三个原因挨个排查：
1. **JSON 文件问题**：路径写错或文件损坏。打开浏览器 Network 面板看请求状态码，200 说明文件拿到了，4xx 就是路径问题
2. **容器没设尺寸**：Lottie 需要一个有明确宽高的 DOM 容器，`width: 0` 的 div 不会报错但什么都看不到
3. **AE 不支持的特性**：3D 图层、合并路径、部分表达式（wiggle 最典型）导出后会丢失或异常。用 bodymovin 插件的预览功能逐段检查，wiggle 表达式必须烘焙成关键帧再导出
```javascript
animation.addEventListener('data_failed', () => {
container.innerHTML = '<img src="fallback.png" alt="fallback">';
});
```
加载失败必须有降级，留白是最差的体验。
## 性能卡顿与内存泄漏
SVG 渲染画质好但帧率不稳，Canvas 渲染器在移动端和列表场景下表现更稳定。关键数据：带 mask 或 matte 的动画会额外创建 2-3 个 bitmap，放在 RecyclerView 里会直接触发内存抖动——列表场景要么去掉遮罩，要么别用 Lottie。
```javascript
lottie.loadAnimation({
renderer: 'canvas',
rendererSettings: { clearCanvas: false, progressiveLoad: true }
});
```
离屏动画必须暂停。用 IntersectionObserver 做可见性控制，不可见时 `pause()`，回到视口再 `play()`。低端设备直接降级成静态图，比卡顿强一百倍。
内存泄漏是另一个高频坑：组件卸载时没调 `destroy()`、事件监听没移除，这两个都做了才不会泄漏。
```javascript
useEffect(() => {
const anim = lottie.loadAnimation({ container: ref.current, renderer: 'svg', loop: true, autoplay: true, path: 'anim.json' });
return () => { anim.destroy(); anim = null; };
}, []);
```
## 跨平台渲染不一致
同一份 JSON 在 Web/iOS/Android 上效果可能不同。常见差异：
| 问题 | 原因 | 解决 |
|------|------|------|
| 渐变填充丢失 | 中文 AE 环境下字段名不匹配 | 切英文语言环境导出 |
| 字体渲染差异 | 各端字体引擎不同 | 转轮廓后导出 |
| 缓动曲线偏差 | 浮点精度实现不同 | 简化缓动，避免极值 |
设计阶段就对照 Lottie 官方 Supported Features 列表确认，比开发完再返工成本低得多。iOS 要求 9.0+，Android 需要开启 `vectorDrawables.useSupportLibrary` 并用 lottie-android 6.0.0 以上版本。
## 资源加载优化与动态颜色
大体积 JSON 加载慢的解决方案：LottieFiles 在线优化器压缩文件、CDN 分发、Service Worker 缓存二次加载。小程序里全屏动画模糊的问题，需要按设备像素比缩放 canvas 尺寸。
动态改颜色用 `setColorFilter`，按图层 keypath 指定替换，比直接改 JSON 数据靠谱。颜色格式必须是 RGBA 数组（0-1 范围），十六进制不行。
```javascript
animation.setColorFilter([{ keypath: 'icon_layer', color: 'rgba(255,80,0,1)' }]);
// 十六进制转 Lottie 颜色数组
function hexToLottieColor(hex) {
return [parseInt(hex.slice(1,3),16)/255, parseInt(hex.slice(3,5),16)/255, parseInt(hex.slice(5,7),16)/255, 1];
}
```
循环播放别只设 `loop: true`，用 `loopComplete` 事件控制次数、`complete` 事件手动重播，灵活得多。路径动画闪烁的问题，确保每个关键帧的锚点数量和走向一致就行。前端5月27日 18:25
Lottie 动画库的工作原理是什么？Lottie 是 Airbnb 开源的动画渲染库，核心思路是把 After Effects 动画导出为 JSON，然后在客户端用原生绘图 API 实时渲染——不走 GIF、不走视频，走的是矢量绘制。
设计师在 AE 里做好动画，装一个 Bodymovin 插件点导出，拿到的 JSON 文件直接丢进项目，几行代码就能播动画。JSON 里存的是图层数据、关键帧、路径信息，Lottie 库负责解析这些数据，在 iOS 上用 Core Animation 渲染，Android 上用 Canvas，Web 上用 SVG 或 Canvas。所以同一份动画文件，三端表现一致。
具体来说，渲染过程分三步：先解析 JSON 构建数据模型（Android 上叫 LottieComposition），然后根据当前播放时间用插值算法算出每一帧各属性的中间值，最后把图层按顺序叠加绘制到画布上——类似 PS 的图层叠加原理，底层依赖 Canvas 的 save/restore 机制。
相比 GIF 和视频，Lottie 的优势很明显：文件体积小得多（一个复杂动画可能就几 KB 的 JSON，而同等效果的 GIF 通常要几百 KB），矢量绘制支持无限缩放不失真，而且可以通过代码控制播放进度、速度、暂停，甚至动态修改颜色和文字内容——这些 GIF 做不到。
但 Lottie 不是万能的。它只支持 AE 中的一部分特性，像粒子效果、3D 摄像机、某些混合模式就不支持。动画越复杂，JSON 文件越大，低端设备上解析也会变慢。另外 Lottie 的版本兼容性也是个坑——不同平台的 Lottie 库版本对 JSON 特性的支持程度不一样，设计师在 AE 里用了一个遮罩效果，iOS 能正常渲染，Android 可能就显示异常。
## 追问
### Lottie 和 GIF/MP4 动画有什么区别？
| 对比项 | Lottie | GIF | MP4 |
|--------|--------|-----|-----|
| 文件体积 | 极小（KB 级） | 大（百 KB~MB） | 较大 |
| 缩放 | 矢量，无损 | 位图，模糊 | 位图，模糊 |
| 交互控制 | 代码控制播放/暂停/速度 | 仅播放 | 播放/暂停 |
| 动态修改 | 支持改颜色/文字 | 不支持 | 不支持 |
| 透明背景 | 原生支持 | 需要处理 | 不方便 |
| 渲染方式 | 原生矢量绘制 | 位图逐帧 | 硬件解码 |
### Bodymovin 导出的 JSON 文件结构是什么样的？
大致分三层：最外层是动画元信息（版本号、宽高、帧率、inPoint/outPoint 标记起止帧），中间是图层列表（每个图层对应 AE 中的一个图层，包含变换属性、遮罩、效果等），最内层是关键帧数据（每个可动画属性在不同时间点的值，用贝塞尔曲线描述缓动）。渲染时 Lottie 从外到内逐层解析，用插值算法算出当前帧的属性值，再绘制到画布上。
### 实际项目里用过吗？遇到过什么坑？
踩过两个典型的坑。一是跨平台渲染不一致——设计稿在 LottieFiles 预览看着正常，跑在低端 Android 机上遮罩就出问题了，后来发现是那个 Android Lottie 版本不支持该遮罩类型，降级 AE 效果才解决。二是 JSON 文件体积——有个动画导出来 200KB+，首屏加载就卡了一下，后来用 Lottie 的缓存策略预加载才缓解。所以实际项目中一定要在目标设备上测试渲染效果，别只在预览页看。
### Lottie 的动态属性修改怎么用？
Lottie 支持在运行时修改动画中的颜色、文字、图片等属性，这个功能叫 Dynamic Properties。Android 上通过 addValueCallback 指定某个图层的某个属性在每一帧的值，iOS 上用 LOTValueDelegate。常见场景是换肤——同一套动画，深色模式下调色板一换就行，不用导出两份 JSON。但要注意，动态修改只对 Lottie 支持的属性类型有效，自定义效果和表达式是改不了的。
### Lottie 性能优化有哪些手段？
几个实用的：开启硬件加速（Android 上 setLayerType）、用 LottieComposition 缓存避免重复解析、控制帧率（没必要 60fps 的动画降到 30fps 能省一半开销）、预加载关键动画。另外 Lottie 现在也支持 dotLottie 格式，是 JSON 的 zip 压缩版本，体积更小加载更快。如果动画包含图片资源，dotLottie 还能把图片一起打包，避免资源管理混乱。前端5月27日 18:23
Lottie 动画与其他动画技术相比有哪些区别和优势？## 为什么前端团队越来越倾向用 Lottie？
先说一个现实问题：一个 3 秒的加载动画，GIF 做出来可能 2MB，PNG 序列帧可能 5MB，而 Lottie 的 JSON 文件往往只要 20KB。这不是压缩算法的魔法，而是根本性的技术路线差异——Lottie 存储的是动画指令而非像素帧。
Lottie 由 Airbnb 开源，它的核心思路是：设计师在 After Effects 中完成动画创作，通过 Bodymovin 插件导出为 JSON，客户端用 Lottie 库解析 JSON 并实时渲染。这意味着动画从"图片播放"变成了"代码执行"，带来了后续一系列优势。
## Lottie 与 GIF：代际差距
GIF 是 1987 年诞生的格式，它的动画原理就是快速翻页——把一帧帧位图拼在一起循环播放。这决定了它的所有短板：
- **体积大**：一个 3 秒循环的 loading 动画，GIF 通常在 500KB～2MB 之间，同样效果 Lottie 只要 10～50KB
- **画质差**：GIF 只支持 256 色，透明通道只有 1 位（要么全透明要么不透明），边缘永远有锯齿
- **不可控**：没法暂停、没法调速、没法倒放，只能傻循环
Lottie 是矢量渲染，无限缩放不失真，支持完整的 Alpha 通道。文件存储的是路径和关键帧数据，不是像素。唯一 GIF 还有存在价值的场景是表情包和邮件内嵌——因为 Lottie 需要 JavaScript 运行时，邮件客户端不支持。
## Lottie 与 PNG 序列帧：内存杀手
PNG 序列帧是游戏开发中的传统方案：把每一帧导出为一张 PNG，然后按时间线依次切换。效果可控，但代价极高：
- 一个 60 帧、分辨率为 1080p 的动画，序列帧总大小轻松超过 10MB
- 所有帧图片需要一次性加载到内存，内存峰值极高，移动端尤其敏感
- 缩放失真，适配多分辨率需要导出多套素材
Lottie 只需要一份 JSON 文件，渲染时实时计算矢量路径，内存占用是序列帧方案的零头。如果动画需要适配不同分辨率，Lottie 天然支持，序列帧则需要 1x/2x/3x 三套资源。
## Lottie 与视频（MP4/WebM）：交互性的分水岭
视频在"展示型"场景下表现不错——流式加载、硬件解码、画质可以很高。但视频和 Lottie 的本质区别在于：
- **视频是预渲染的**：播放什么就是什么，运行时无法改颜色、改文字、改任何元素
- **控制能力有限**：虽然能暂停和 seek，但没法动态响应业务逻辑
- **透明通道支持差**：WebM 虽然支持透明，但兼容性堪忧；MP4 不支持透明
实际案例：一个活动的 loading 动画需要根据不同城市显示不同文案。用视频得为每个城市导出一个文件，用 Lottie 只需运行时替换文本图层即可。这就是声明式动画和预渲染视频的核心差距。
## Lottie 与 CSS 动画：分工不同
CSS 动画做简单交互——hover 渐变、弹跳、淡入淡出——非常顺手，性能也极好（只操作 transform 和 opacity 时走 GPU 合成层）。但它的上限很明显：
- **复杂路径动画写不动**：贝塞尔曲线变形、形状补间、粒子效果，CSS 基本无能为力
- **跨端一致性差**：同样的 animation，Chrome 和 Safari 的渲染细节可能有差异
- **设计师无法直接参与**：动画参数全靠开发者手写，和设计稿之间有二次转译损耗
Lottie 把动画的创作权还给设计师，开发者只需要 `lottie.loadAnimation()` 一行调用。两者不是替代关系，而是分工：CSS 处理 UI 微交互，Lottie 处理视觉级动画。
## Lottie 与 Canvas / SVG 动画：维护成本的天平
Canvas 动画和 SVG 动画都能实现高复杂度的效果，但开发成本完全不同：
- **Canvas**：需要手写 requestAnimationFrame 循环，管理渲染管线，手动处理 DPI 适配和性能优化。几秒的动画可能需要数百行代码，后期维护是噩梦
- **SVG 动画**：SMIL 或 CSS 驱动，Web 端可用，但跨平台支持差（Android 对 SVG 动画支持有限），复杂动画的 SVG 代码可读性极低
Lottie 在 Web 端底层可以选择 SVG 或 Canvas 渲染器，但上层 API 完全一致。开发者不需要关心渲染细节，只管加载 JSON。维护成本从"维护动画代码"降级为"替换一个 JSON 文件"。
## Lottie 与原生动画：性能的天花板
iOS 的 Core Animation 和 Android 的 Animator 是各自平台上的性能天花板——直接操作图层的 GPU 渲染管线，没有中间层。Lottie 在渲染性能上确实不如原生动画：
- Lottie 的 JSON 解析和图层树构建有额外开销
- 复杂动画帧率可能比原生低 5～10fps
- 大型动画（数百个图层）在低端机上可能出现掉帧
但原生动画的开发成本极高：一个复杂动画需要分别给 iOS 和 Android 写两套实现，设计师的效果只能靠开发者手动还原。Lottie 牺牲一点极限性能，换来了跨平台一致性和 10 倍的开发效率提升。在绝大多数业务场景下，这点性能差距用户根本感知不到。
## Lottie 与 Three.js / WebGL：不同维度
Three.js 和 WebGL 做 3D 动画和复杂视觉特效，这是 Lottie 完全不涉及的领域。Lottie 专注 2D 矢量动画，Three.js/WebGL 专注 3D 和 GPU 着色器效果。两者不存在选择困难，需求类型天然不同。
## Lottie 与 FLIP 动画：不同用途
FLIP（First-Last-Invert-Play）是一种布局过渡动画技巧，用于实现元素位置变化的丝滑过渡——比如列表重排、卡片展开。它和 Lottie 解决的是完全不同的问题：Lottie 是预定义的独立动画，FLIP 是运行时计算的过渡动画。两者经常配合使用。
## 怎么选？一张表说清楚
| 技术 | 文件体积 | 渲染质量 | 交互能力 | 跨平台 | 开发效率 | 典型场景 |
|------|---------|---------|---------|--------|---------|---------|
| Lottie | 极小 | 矢量无损 | 强 | 好 | 高 | 品牌动画、icon 动效、loading |
| GIF | 大 | 位图有损 | 无 | 好 | 低 | 表情包、邮件内嵌 |
| PNG 序列帧 | 最大 | 位图 | 弱 | 好 | 低 | 游戏帧动画 |
| 视频 | 中 | 高保真 | 弱 | 好 | 中 | 产品演示、引导视频 |
| CSS 动画 | 代码量 | 好 | 中 | 一般 | 高 | UI 微交互、hover 效果 |
| Canvas 动画 | 代码量 | 位图 | 强 | 好 | 低 | 数据可视化、游戏 |
| SVG 动画 | 较小 | 矢量无损 | 中 | 差 | 中 | Web 端简单动画 |
| 原生动画 | 代码量 | 最优 | 强 | 差 | 低 | 性能敏感的核心交互动画 |
选择的核心逻辑：如果动画是设计师创作的视觉内容（icon 动效、品牌动画、loading），选 Lottie；如果是开发者实现的交互反馈（hover、过渡），选 CSS；如果是 3D 或着色器特效，选 Three.js/WebGL；如果追求极限性能，选原生动画。其他技术基本只在特定场景下作为补充方案。前端5月27日 18:22
Lottie 动画相比 GIF 和视频有哪些性能优势？## Lottie 为什么比 GIF 和视频更轻量？
Lottie 动画基于矢量描述——本质是一份 JSON 文件，记录了路径、关键帧和图层信息，而不是逐帧存储像素。一个 5 秒的加载动画，Lottie 文件通常在 10-50 KB，而同样效果的 GIF 轻松超过 500 KB，视频编码后也在 200 KB 以上。这种差距的根本原因在于信息表达方式不同：Lottie 只描述"怎么画"，GIF 和视频则记录"每帧长什么样"。
实际项目中，Lottie 的体积优势在复杂动画上更明显。Airbnb 开源 Lottie 时公布的案例显示，一个 7 秒的品牌动画导出为 GIF 约 1.2 MB，而 Lottie JSON 仅 28 KB，压缩比超过 40 倍。对于移动端来说，这意味着更小的安装包和更快的资源下载。
## 渲染性能差异从何而来？
Lottie 使用平台的原生绘图 API 渲染：iOS 上走 Core Animation，Android 上走 Canvas，Web 上走 SVG 或 Canvas。这意味着动画帧由 GPU 直接绘制，和系统 UI 共享硬件加速通道。
GIF 则完全不同。GIF 需要先解码每一帧的像素数据，再提交给显示系统。解码过程消耗 CPU，且 GIF 格式本身不支持硬件加速。在低端 Android 设备上，同时播放两三个 GIF 就能明显感受到帧率下降。
PNG 序列帧的渲染路径和 GIF 类似，但内存压力更大——每帧都是一张完整图片，30 帧 1080p 的动画就需要同时持有 30 张位图。视频虽然依赖硬件解码器，但解码后的帧缓冲同样占用内存，而且视频解码的初始化延迟比 Lottie 高出几个数量级。
## 内存占用：为什么 Lottie 更省？
内存占用的差异源于数据存储方式。Lottie 在内存中只保存动画的描述数据（路径节点、关键帧参数），渲染时按需实时计算当前帧的画面。一个典型 Lottie 动画的运行时内存开销在 1-5 MB。
GIF 和 PNG 序列帧则需要预先解码并缓存帧数据。一张 1080×1920 的 RGBA 位图占约 8 MB 内存，30 帧动画如果全量缓存就需要 240 MB。实际播放器通常会做帧缓存优化，但即使只缓存 3-5 帧，内存占用也远高于 Lottie。
视频的内存模型介于两者之间，硬件解码器会维护自己的帧缓冲区，通常占用 10-30 MB，但加上解码器本身的上下文开销，整体并不比 Lottie 优越。
## 交互控制能力对比
这是 Lottie 区别于其他方案的关键优势之一。Lottie 提供了完整的播放控制 API：
- **播放控制**：play、pause、resume、stop
- **进度控制**：setProgress(0.0~1.0)，可以精确跳转到任意帧
- **速度调节**：setSpeed()，支持倍速和反向播放
- **循环模式**：支持单次、循环、往返等模式
- **事件监听**：可以监听动画开始、结束、取消、重复等事件
GIF 只能循环播放，无法暂停、调速或跳帧。PNG 序列帧需要自己实现帧管理器才能获得类似控制能力。视频虽然有基本播放控制，但进度跳转不够精确，且无法在运行时修改动画内容。
Lottie 还支持运行时动态修改动画属性——改变颜色、替换文字、隐藏图层，这些是 GIF 和视频完全做不到的。比如一个加载动画，可以根据主题色动态切换旋转圆环的颜色，而不需要为每种主题准备一份动画文件。
## 响应式与分辨率适配
Lottie 动画是矢量图形，任意缩放都不失真。同一份 JSON 文件，在 320px 宽的手机和 2560px 的桌面显示器上都能清晰显示，不需要准备 @2x、@3x 等多套资源。
GIF、PNG 序列帧和视频都是位图格式，在高分辨率屏幕上放大就会模糊。要适配不同 DPI，就得导出多个版本，进一步增加包体积。对于需要全屏展示的动画效果，这个矛盾尤其突出。
## 加载速度的实际差距
Lottie 的加载流程是：下载 JSON → 解析 → 渲染。JSON 文件小，下载快；解析是轻量的文本操作；渲染走原生 API，首帧出现很快。在实际项目中，一个 50 KB 的 Lottie 动画从发起请求到首帧展示，通常在 100-200 ms 内完成（本地缓存场景下更快）。
GIF 需要下载完整文件后才能开始解码播放，且文件体积大导致下载时间长。PNG 序列帧更慢，需要下载每一帧图片。视频虽然支持流媒体加载，但解码器初始化本身就有 200-500 ms 的冷启动延迟，不适合做轻量级的 UI 动画。
## 性能优化的实战建议
在实际项目中使用 Lottie，有几个优化点值得关注：
**缓存策略**：对已加载的 LottieComposition 做内存缓存，避免重复解析同一份 JSON。Android 上 Lottie 默认提供了 LottieCache，iOS 上可以自己用 NSCache 实现。
**列表场景控制**：在 RecyclerView 或 UITableView 中，务必在视图回收时暂停动画、复用时重新播放。同时在列表中避免同时播放超过 3 个 Lottie 动画，否则低端设备的帧率会明显下降。
**动画设计约束**：和设计师协商，控制遮罩（Mask）和蒙版（Matte）的使用数量——这两个特性在 Lottie 渲染时需要额外的离屏绘制 pass，是性能瓶颈的常见来源。一个动画中超过 3 个遮罩层就要考虑简化。
**按需加载**：对于非首屏的动画，使用 Lottie 的 lazy loading 特性，等视图可见时再触发加载，而不是页面初始化时全部加载。
**硬件加速**：确保动画所在的 View 开启了硬件加速。在 Android 上，可以在 View 层级通过 setLayerType 确认；在 Web 上，确保 SVG 渲染模式没有被强制降级。
Lottie 在 UI 动画场景下的性能优势是明确的：更小的文件体积、更低的内存占用、更快的加载速度和更灵活的交互控制。但也要注意它不是万能的——对于复杂的粒子效果、3D 变换或摄影级画面，视频仍然是更合适的选择。选型时根据具体场景权衡，才能发挥各方案的最大价值。