打开相机预览后发现native内存占用飙升，参考字节技术文章得知：
这类 native OOM 的根本原因是：当应用自身的 native 内存本身已处于高水位时，开启相机后，相机服务会持续通过 binder 通信在应用侧创建 CameraMetadataNative 对象，创建 CameraMetadataNative 对象的同时也会在应用侧通过 jni 接口在 native 层创建/复用一块存放 camera_metadata_t 的相对比较大的内存。由于 Java 层的 CameraMetadataNative 对象本身比较小，这种连续创建小对象的行为一定时间内很难触发 Java 层的 GC，导致其间接引用的 native 内存不断上涨，最终触发虚拟内存上限而 crash。
解决思路
问题的原因虽然相对比较简单，但如何解决这类问题还是比较难抉择的。既然是 GC 不及时导致的，一种简单的方案就是在拍摄页周期性触发 GC。但如果 GC 间隔比较小，GC 毕竟是耗时的，GC 过于频繁会严重影响拍摄体验；如果 GC 间隔时间比较长，还是会有大概率重蹈这类 native OOM 的覆辙。
主动触发 GC 的方案很难平衡对性能的影响。其实问题的重点不是 Java 层，而是 Java 对象引用的 native 内存，如果及时主动释放这部分内存就可以从根本上彻底解决此类问题。通过前面的分析可以知道，这部分内存原本是在 GC 时的 finalize 环节回收，但如果提前发现 CameraMetadataNative 不再使用时，主动触发来释放这部分内存就可以一劳永逸。通过分析源码可以发现 CameraMetadataNative 传递到应用层之后后续并未再使用，在应用层使用完 CameraMetadataNative 对象之后，通过反射调用 close 函数即可释放其所引用的 native 内存。
