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；如果追求极限性能，选原生动画。其他技术基本只在特定场景下作为补充方案。