说实话，线上事故这种东西，就像悬在头顶的达摩克利斯之剑，平时风平浪静，一旦掉下来那就是天崩地裂。Zui近我们就因为Lottie动画库踩了一个大坑，导致线上OOM崩溃频发。起初我们以为是简单的图片资源过大，结果顺着源码一路摸下去，才发现事情远没有表面那么简单。今天我就把这起事故的来龙去脉，以及我们是如何通过阅读源码找到“真凶”的过程，毫无保留地分享出来。

一、 暴风雨前的宁静：惨案现场还原

事情发生在一月初。那时候需求刚上线，因为触发动画的场景比较少，一切kan起来dou岁月静好。直到1月7号，业务方开始大规模推广这个动画功Neng，监控报警群里的消息瞬间炸了锅。短短两天后台统计到的OOM崩溃次数竟然超过了1000+。

我们迅速去抓取崩溃机型的特征，发现一个非常有意思的现象：所有的崩溃全部集中在Android 8.0及以下的机型上。这让我们心里稍微有了点底，至少不是全量崩溃，大概率是跟低版本系统的内存回收机制有关，或者是某种特定的兼容性问题。

为了复现问题，我翻出了压箱底的那台华为老古董机器。三个动画轮番轰炸，果然没几下应用就闪退了。打开Android Studio的Profile工具抓了一份内存快照，kan到那个数字的时候，我差点没拿稳手机。

1.1 触目惊心的内存占用

数据显示，单个动画加载进内存后竟然占用了大约86MB的空间！你想想，Ru果用户在页面里快速切换，连续加载三个动画，那内存占用岂不是直接飙升到200MB以上？对于一些低内存的老机型来说这简直就是灭顶之灾，天dou要塌了。

第一反应肯定是图片太大了。大家dou知道，Lottie动画本质上就是一堆JSON配合图片资源。我们解压了动画资源包，发现里面包含了几十张图片。Android系统默认使用ARGB_8888格式来解码位图，这意味着每个像素点要占用4个字节。

粗略算了一笔账：假设图片的宽高尺寸比较大，乘以4字节，单张Bitmap占用4M左右，几十张图叠在一起，这体积自然就上去了。于是我们尝试手动裁剪图片资源，把尺寸缩小，图片数量也砍掉了一半。经过这一轮优化，单个动画的内存占用确实降下来了Profile显示单张Bitmap大概只占2M左右。

但是故事并没有结束。在测试机上跑了几轮，发现虽然概率降低了但在低版本机器上依然会偶发OOM。这说明，我们只是治标，还没治本。真正的“雷”，还在源码深处埋着。

二、 顺藤摸瓜：源码里的“双胞胎”疑云

既然资源优化到了极限还是崩，那就只Neng从代码逻辑里找原因了。我们开始仔细研读Lottie加载网络动画的流程。通常，我们的用法是这样的：

// 预加载动画资源
LottieCompositionFactory.fromUrl
// 视图绑定动画资源
LottieAnimationView.setAnimationFromUrl
// 播放动画
LottieAnimationView.playAnimation

这套流程kan起来丝般顺滑，既不用增加包体积，又Neng利用缓存提升体验。但问题恰恰出在这个“缓存”上。

我们点进 LottieAnimationView 的源码，发现它内部的各种 setAnimation 重载方法，Zui终dou会把请求转发给 LottieCompositionFactory。比如 setAnimationFromUrl Zui终会走到 fromUrl 这个静态方法。

2.1 线程池与任务提交

先kan一眼 LottieTask 的构造函数。Lottie为了不阻塞主线程，内部维护了一个线程池来处理解析任务。

// 线程池定义
public static Executor EXECUTOR = Executors.newCachedThreadPool);
public LottieTask {
  this;
}
// 构造函数内部直接扔进线程池执行
@RestrictTo
LottieTask {
  EXECUTOR.execute);
}

这里没什么毛病，标准的异步操作。接着kan LottieCompositionFactory.fromUrl Zuo了什么。

public static LottieTask fromUrl {
  return cache -> {
    // 发起网络请求
    LottieResult result = L.networkFetcher.fetchSync;
    // 请求完成后尝试写入缓存
    if  != null) {
      LottieCompositionCache.getInstance.put);
    }
    return result;
  }, null);
}

这里有一个 cache 方法，它负责检查内存缓存。Ru果命中了直接返回；Ru果没有命中，就创建一个新的 LottieTask 去执行加载逻辑，Zui后把结果放进 LottieCompositionCache。

2.2 真相浮现：Key的冲突

为了搞清楚内存里到底存了什么我们在分析内存Dump时发现了一个极其诡异的现象：在 LottieCompositionCache 的 cache 这个Map里同一个动画资源竟然出现了两个Key！

虽然这两个Key对应的Value是同一个 LottieComposition 对象，但是Key的重复本身就hen让人费解。这就像是你家里只有一个人，却办了两张身份证，虽然人还是那个人，但系统维护索引的开销和逻辑上的混乱是显而易见的。

带着这个疑问，我们深入到了 NetworkFetcher 的 fetchSync 方法里。这个方法负责处理网络流，并将其转换为文件流或Zip流。

private LottieResult fromZipStream
    throws IOException {
  if  {
    return LottieCompositionFactory.fromZipStreamSync, null);
  }
  File file = networkCache.writeTempCacheFile;
  // 注意这里！这里直接把 url 作为了 cacheKey
  return LottieCompositionFactory.fromZipStreamSync), url);
}

kan到那个注释了吗？在 fromZipStream 的深处，它直接使用了原始的URL作为缓存Key。

现在让我们回到外层的 fromUrl。在Lottie的源码逻辑里外层传入的 cacheKey 往往会被处理成类似 "url_" + url 的格式。

于是悲剧发生了：

第一次缓存在 fromUrl 的 cache 方法回调里代码执行了 LottieCompositionCache.getInstance.put。这里的Key是经过包装的，比如 "url_http://..."。

第二次缓存在解析Zip流的内部逻辑 fromZipStreamSyncInternal 中，Ru果检测到 cacheKey 不为空，它又会执行一次 put。而在 fromZipStream 的调用链中，传入的却是原始的 url。

private static LottieResult fromZipStreamSyncInternal {
  // ... 解析过程 ...
  // 缓存解析完成的 composition
  if  {
    // 这里又存了一次！
    LottieCompositionCache.getInstance.put;
  }
  return new LottieResult<>;
}

结果就是LottieCompositionCache 里同时存在了两个Key指向同一个对象。虽然对象本身没多一份，但在低版本设备上，这种引用关系的混乱，加上缓存策略的不当，极有可Neng导致内存无法及时释放。我们查阅了Zui新的Lottie源码，发现这个问题依然存在甚至还在GitHub上提了Issue。

三、 图片解析的“隐形”放大镜

除了缓存Key的问题，我们在源码里还发现了一个关于图片处理的细节。在 fromZipStreamSyncInternal 中，Lottie会解析Zip包里的图片：

} else if  || entryName.contains || ...) {
  String splitName = entryName.split;
  String name = splitName;
  // 直接解码流
  images.put);
}

这kan起来hen正常，但紧接着下面有一段逻辑：

// 对上面解析完的图片按 json 文件描述的宽高进行裁剪
for ) {
  LottieImageAsset imageAsset = findImageAssetForFileName);
  if  {
    // Ru果图片尺寸大于JSON中定义的尺寸，会进行缩放
    imageAsset.setBitmap, imageAsset.getWidth, imageAsset.getHeight));
  }
}

这段代码的意思是虽然设计师给的图片可Nenghen大，但Ru果JSON文件里定义的显示尺寸hen小，Lottie会帮你把Bitmap缩放到合适的大小。

但是！这里有个坑。BitmapFactory.decodeStream 在解码时Ru果原始图片非常大，即便你后来把它缩放到500x500，在解码的那一瞬间，内存依然需要分配给原始大尺寸的空间。虽然GC会回收，但在高并发或瞬间加载多个动画时这个瞬间的内存峰值足以压垮低版本设备。

这也解释了为什么我们手动裁剪图片资源后内存占用下降明显。因为源头变小了解码时的峰值也低了。

四、 终极解决方案：亡羊补牢，为时未晚

找到了原因，解决起来就有的放矢了。我们制定了一套组合拳，专门对付这个吃内存的怪兽。

4.1 资源层面的瘦身

也是Zui直接的，继续压缩资源。不仅仅是裁剪尺寸，还要检查JSON里引用的图片是否真的dou有用。我们把动画里的图片数量从几十张砍到了十几张，并且严格控制每张图的物理尺寸。经过这一步，单个动画的内存占用稳定在了一个可接受的范围。

4.2 代码层面的降级策略

针对Android 8.0及以下的机型，我们决定采取“一刀切”的策略——禁用Lottie的内存缓存。

Lottie提供了一个API setCacheComposition

/**
 * Ru果设置为true，所有未来的Compositiondou会被缓存，下次加载就不需要解析了。
 * 默认为true。
 */
public void setCacheComposition {
  this.cacheComposition = cacheComposition;
}

我们在初始化动画的地方，根据系统版本Zuo了判断：

if  {
    lottieAnimationView.setCacheComposition
}

这样一来虽然低版本机型每次播放dou要重新解析JSON和图片，牺牲了一点点CPU性Neng和流畅度，但换来了内存的绝对安全。毕竟应用崩了流畅度再好也没用。

4.3 主动出击：监听系统回调

对于Android 8.0及以上的机型，虽然内存管理机制好hen多，但我们也不敢掉以轻心。为了防止极端情况下的OOM，我们在Application或者BaseActivity里注册了 ComponentCallbacks2，监听系统的内存 trimming 事件。

private val componentCallback = object: ComponentCallbacks2 {
    override fun onConfigurationChanged {
    }
    override fun onLowMemory {
        V5Logger.e
        // 系统内存不足，主动清理Lottie缓存
        LottieCompositionFactory.clearCache
    }
    override fun onTrimMemory {
        if  {
            V5Logger.e
            // 内存紧张级别较高，清理缓存
            LottieCompositionFactory.clearCache
        }
    }
}

当系统发出“内存告急”的信号时我们第一时间调用 LottieCompositionFactory.clearCache，把 LottieCompositionCache 里的东西统统清空，给系统腾出宝贵的内存空间。

五、 ：源码面前没有秘密

经过这一番折腾，线上OOM的崩溃率终于降到了零点几以下老机型也Neng流畅运行动画了。这次事故给我们敲响了警钟：动画这种比较吃内存的操作，真的不Neng盲目相信开源库的“默认配置”。

hen多时候，源码就是Zui好的文档。遇到问题，不要只在网上搜StackOverflow，沉下心来读一读源码，往往Neng发现意想不到的细节。就像这次Lottie的双重缓存Key问题，Ru果不kan源码，可Neng永远dou猜不到是这么个低级但隐蔽的Bug导致的。

正确的使用方式，加上对源码的深刻理解，才Neng达到Zui完美的效果。毕竟在代码的世界里源码面前是没有秘密的。希望大家在以后开发中，Neng避开这些坑，写出geng健壮的代码！

---