dotLottie vs JSON——为什么需要新格式
原始 Bodymovin JSON 的局限
Lottie 生态基于 Airbnb 2017 年开源 Bodymovin 时的 JSON 格式发展了数年。这个格式很轻量，但在实际生产中暴露了几个问题：
问题一：资源散落
如果动画里用了位图或字体，Bodymovin 会把它们放到 JSON 同级的 images/ 和 fonts/ 子目录。部署时必须手动保持相对路径一致——很容易漏文件或路径写错。
问题二：单动画单文件
一个 JSON 文件只能描述一段动画。如果你需要一个组件的"正常/悬停/按下/禁用"四种状态切换，要么四个独立 JSON（部署四套文件），要么把四段动画硬塞进一个 JSON（播放时手动跳帧）。两种方式都不理想。
问题三：没有交互定义
JSON 只描述"这个动画怎么播"——什么时候开始、什么时候结束、关键帧是什么。但"用户点击后从 A 状态切到 B 状态"这种交互逻辑不在 JSON 格式里，必须在开发端手动写。
问题四：没有数据绑定
动画里的颜色、文字、位置都是硬编码值。要适配多品牌或动态数据，需要在开发端写 ValueCallback 运行时改——不是类型安全、也不直观。
dotLottie 解决了什么
dotLottie 格式本质上是一个 ZIP 压缩包，.lottie 后缀，里面有标准结构：
| 能力 | 原始 JSON | dotLottie |
|---|---|---|
| 多段动画打包 | ❌ 一个文件一段 | ✅ 一个文件多段动画 |
| 关联资源（图片/字体） | ❌ 散落子目录 | ✅ 打包进 ZIP |
| 主题皮肤 | ❌ 手动改 JSON | ✅ themes/ 目录 |
| 状态机交互 | ❌ 开发端手写 | ✅ state_machines.json |
| Motion Tokens 数据绑定 | ❌ ValueCallback | ✅ manifest 里定义 tokens |
| 文件体积 | 20~50KB | 4~10KB（压缩约 80%） |
文件大小对比
| 格式 | 典型 Loading 动画 | 备注 |
|---|---|---|
| Bodymovin JSON | 35KB | 原始 |
| 优化 JSON | 12KB | LottieFiles 在线优化 |
| dotLottie (.lottie) | 5KB | ZIP 压缩 + 打包 |
| GIF | 400KB | 同等复杂度 |
dotLottie 的优势是在保持矢量质量的前提下，文件体积接近 GIF 的 1/80。
dotLottie 是官方格式吗
是的。dotLottie 由 LottieFiles 推出，但已经被 Airbnb 的 Lottie 官方仓库接受——lottie-web、lottie-android、lottie-ios 都在逐步增加 dotLottie 的原生支持。开源规范在 dotlottie.io 上可以查看，Apache 2.0 协议。
切换成本
| 场景 | 切换难度 |
|---|---|
| 只用 JSON 的简单项目 | 无需切换，继续用 JSON 就行 |
| 有多动画打包需求 | 低——Creator 或 LottieFiles 一键导出 dotLottie |
| 需要交互状态机 | 中——设计端用 Creator 定义状态机，开发端换 dotLottie 播放器 |
| 需要多品牌适配 | 中——用 Motion Tokens 暴露属性，开发端绑定值 |
dotLottie 不是 JSON 的替代品——它是 JSON 的超集打包格式。每个 dotLottie 文件里包含一个或多个标准 Bodymovin JSON，所以内容上没有断裂。