Android Camera 内存问题剖析(1)，2024年最新字节跳动社招面试记录

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

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

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

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

本文通过一类 Android 机型上相机拍摄过程中的 native 内存 OOM 的问题展开，借助内存快照裁剪回捞和 Native 内存监控工具的赋能，来深入剖析此类问题。

背景

---

Raphael 是西瓜视频 Android 团队开发的一款 native 内存监控工具，在字节跳动内部产品（如西瓜、抖音、头条等）上广泛用于监控 native 内存泄漏问题。在抖音 7.8.0-8.3.0 上搜集到大量因虚拟内存触顶而 crash 的内存日志现场（如 pthread_create、GL error、EGL_BAD_ALLOC），其中 60%以上都是 camera 相关的内存泄漏，占整体 crash 的 15%以上（Java & Native）。同时也收到 OPPO 等厂商反馈抖音 app 在其新机型上 native crash 比其他机型高了 3 倍以上，分析厂商提供的日志发现基本都是虚拟内存触顶导致的 carsh，这其中 80%以上都有 camera 相关的内存分配失败的日志。

问题

---

通过对 native 内存监控搜集到的日志进行堆栈聚合和 so 级的内存占用统计，可以发现截止到 OOM 时工具拦截到的 native 内存总量已经达到了 1.3G 左右（32 位下应用可直接使用的 native 内存上限约 2G），这其中占比最大的是 CameraMetaData 对象间接引用的内存，native 内存泄漏十分严重。

由于 native 内存分配的频率过高，获取 Java 层堆栈又比较耗时，在拦截 native 内存分配时并不适合直接频繁抓取 Java 堆栈。Native 内存不同于 Java 内存，单从拦截到的数据很难直观给出结论。通常对于内存等资源不合理使用导致的资源不足而引发的问题都很难归因，从拦截到的数据来看，CameraMetaData 所引用的内存最大，嫌疑也最大，基于此决定剖析一下这个问题

初步分析

---

分析 native 内存的分配和释放

通过拦截到的堆栈可以看出，CameraMetaData 的创建堆栈的上层是 Java 调用，最终在 native 层进行的内存分配（boot-framework.oat & libandroid_runtime.so）。CameraMetaData 对象有两部分内存，对象本身 & mBuffer 指向的 camera_metadata_t 所引用的内存；通过源码可知，每个 CameraMetadata 对象的 mBuffer 所指向的 camera_metadata_t 是独立的，彼此是不重叠的。

既然工具能拦截到这么多的未释放的内存分配，一定是因为这些内存的释放逻辑出问题导致的，我们需要优先调查清楚 CameraMetadata.mBuffer 的释放逻辑。通过分析 CameraMetadata.cpp 的源码可知，CameraMetadata::release()并未释放 mBuffer 所指向的内存，而是把 mBuffer 所指向的内存赋值给了另一个 CameraMetadata 对象；CameraMetadata::clear()是真释放，而 clear 的调用有两个场景：一个是在 camera_metadata_t 复用时，另一个是 CameraMetadata 对象析构时。

前述结论可知 CameraMetadata.mBuffer 所指向的 camera_metadata_t 是彼此独立的。通过工具拦截到的堆栈和分配数量猜测，Native OOM 时内存中一定存在大量的 CameraMetadata 实例。C++对象的析构通常是调用 delete 来实现的，AOSP 里想搜索哪里 delete 了一个 CameraMetaData 对象是很难的，因为很难知道 delete 时的变量名。根据一个基本的 C++编程规范，内存通常在哪里创建的，应该就在那里释放，我们全局搜索 new CameraMetaData 字符串就可以很轻松的发现 CameraMetaData 对象的创建和释放均是在[/frameworks/base/core/jni/android_hardware_camera2_CameraMetadata.cpp]

通过 android_hardware_camera2_CameraMetadata.cpp 里的注册清单可以看到与这些函数关联的 Java 层 class 是android/hardware/camera2/impl/CameraMetadataNative，CameraMetadata_close 函数在 Java 对应的是 nativeClose 函数。可以进一步发现 CameraMetaDataNative 里 nativeClose 函数是在 close 函数里调用的，而 close 函数又是在 finalize 函数调用的。

通过上述分析可知只有在 CameraMetaDataNative 对象执行 finalize 方法时才会回收与之对应的 native 内存，而 finalize 方法又是在 FinalizerDaemon 线程里执行的，猜测到如果发生了上述堆栈的 native OOM，Java 层一定存在大量还没有执行 finalize 方法的 CameraMetaDataNative 对象。

排查 Java 堆现场

幸运的是我们通过内存快照裁剪工具（Tailor）轻松拿到了大量这类 native OOM 时对应的 Java 堆内存快照文件。这些内存快照文件完美证实了之前的猜想，当发生这类 native OOM 时 Java 层的确存在大量的 CameraMetadataNative 对象。以下图为例，这些 CameraMetadataNative 对象里除 6 个被其他代码引用外，其余对象全部在 FinalizerDaemon 线程的队列里，等待执行 finalize 方法。同时，快照里有 6658 个对象，只有大约 600+对象的 mMetadataPtr 是等于 0 的，说明这部分对象对应的 Native 内存需要在 finalize 时释放，这跟工具拦截的数据是完全匹配的，也间接验证了 Native 内存监控的正确性和可靠性

深入分析

---

排查 Finalize 执行

虽然上述分析验证了问题，也证实了之前的猜想，但仍未找到导致此类问题的深层次原因，对于最终解决此类问题也仍然束手无策。为什么会有这么多的 CameraMetadataNative 对象等待执行 finalize 方法或许是下一步的调查方向。做过 Java 稳定性治理的同学应该都知道一类很有名的 TimeoutException 异常，这类异常的根本原因是 finalize 执行超时导致的，这个 case 会不会是某个对象的 finalize 执行超时导致的？

结合 FinalizerDaemon 的源码可以看到，每执行一个对象的 finalize 方法时，都会通过finalizingObject属性记录当前的对象。如果真的是 finalize 超时导致的，一定存在 finalizingObject 属性不为空的现场。我们在遍历完所有相关内存快照里的 FinalizerDaemon 线程状态后发现，这些现场的 finalizingObject 属性均为空。这个结果很意外，似乎并不是某个对象的 finalize 方法执行超时导致的。

通过分析finalizingReference = (FinalizerReference<?>)queue.remove() 发现这行代码后面的逻辑并没有对  finalizingReference 判空，说明这个地方一定不会返回空。既然不为空， queue.remove() 只能 block 等待，这个 ReferenceQueue.java 的源码也证实了猜想。

源码显示 goToSleep 是个同步方法，可能会 block。但遍历所有相关快照发现所有的 needToWork 属性均是 false，证明已经走过（只有FinalizerWatchdogDaemon.INSTANCE.goToSleep() 会置为 false，而且这个函数是 private 的，只在 FinalizerDaemon 线程里调用），所以 block 在这里的可能性几乎没有。

其实 block 在这里的原因通常是因为只有在 GC 时才会将需要执行 finalize 的对象加入到 FinalizerDaemon 的队列里。如果一段时间内没有 GC，且队列就为空时，上面的 remove 会一直 block，直到 GC 后才有对象加入到这个队列里。巧合的是我们在发生这类 native OOM 时会通过 Tailor 主动 dump Java 堆的内存快照，而 dump 快照时会触发 GC & suspend，这个最终导致大量的 CameraMetadataNative 对象被同时加入到 FinalizerDaemon.queue 的队列里。

尾声

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。 整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

最后想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

• 思维脑图
  
• 性能优化学习笔记
  
  

• 性能优化视频
  
  当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

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

系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）**
[外链图片转存中…(img-BJ9F8oIc-1713643055218)]

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