有趣的无限缓存OOM现象，2024年最新HarmonyOS鸿蒙framework开发书籍

• 单帧decode任务入队列之后立即获取下一帧数据
• 二维码识别成功则停止其他解析任务

2.为了有更大的识别区域，选择对整张拍摄图片进行解码，保证中心框框没对准二维码也能识别到

现象

当时测试反馈，手上一个很古老的 Android 5.0 的机器，打开扫一扫必崩，一看错误栈，是个OOM。

机器找不到了，我就不贴现象的堆栈了（埋在时光里了，懒得挖了）。

排查OOM三板斧

板斧一、 通过一定手段，抓取崩溃时的或者崩溃前的内存快照

咦，一年前的hprof文件还在？确实被我找到了。。。

从图中我们能获得哪些信息？

1. 用户OOM时，byte数组的 java 堆占用是爆炸的
2. 用户OOM时，byte数组里，有大量的 3M 的byte数组
3. 3M的byte 数组是被 zxing 的 DecodeHandler$2 引用的

板斧二、从内存对照出发，大胆猜测找到坏死根源

我们既然知道了 大对象 是被 DecodeHandler$2 引用的，那么 DecodeHandler$2 是个啥呀？

mDecodeExecutor.execute(new Runnable() {
@Override
public void run() {
for (Reader reader : mReaders) {
decodeInternal(data, width, height, reader, fullScreenFrame);
}
}
});

所以稍微转动一下脑瓜子就能知道，必然是堆积了太多的 Runnable，每个Runnable 持有了一个 data 大对象才导致了这个OOM问题。

但是为啥会堆积太多 Runnable 呢？结合一下只有 Android 5.0 机器会OOM，我们大胆猜测一下，就是因为这个机器消费（或者说解码）单张 Bitmap 太慢，同时像上面所说的，我们单帧decode任务入队列之后立即获取下一帧数据并入队下一帧decode 任务，这就导致大对象堆积在了LinkedBlockingDeque中。

OK，到这里原因也清楚了，改掉就完事了。

板斧三、 吃个口香糖舒缓一下心情

呵呵…

解决方案

解决方案其实很简单，从问题出发即可，问题是啥？我生产面包速度是一天10个，一个一斤，但是一天只能吃三斤，那岂不就一天就会多7斤囤货，假如囤货到了100斤地球会毁灭，怎么解决呢？

1. 吃快点，一天吃10斤
2. 少生产点，要么生产个数减少，要么生产单个重量减少，要么二者一起
3. 生产前检查一下吃完没，吃完再生产都来得及，实在不行定个阈值觉得不够吃了再生产嘛。

那么自然而然的就大概知道有哪几种解决办法了：

1. 生产的小点 - 隔几帧插一张全屏帧即可（如果要保留不在框框内也能解码的特性的话）
2. 生产前检查一下吃完没 - 线程池的线程空闲时，才去 enqueue decode 任务
3. 生产单个重量减少 - 限制队列大小
4. blalala

总结

装模作样的总结一下。

这个例子是一年前遇到的，今天想水篇文章又突然想到了这个事就拿来写写，我总结为：线程池调度 + 进阻塞队列单任务数据过大 + 处理任务过慢

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数HarmonyOS鸿蒙开发工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上HarmonyOS鸿蒙开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注鸿蒙获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

79527496)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！