MediaCodec解码视频导致内存溢出及解决方案
本文分析使用MediaCodec解码播放视频时，长时间播放后内存溢出导致应用崩溃或重启的问题，并提出相应的优化策略。
问题背景：视频播放流程为：调用播放方法后，后台回调解码后的帧数据，前端进行处理和渲染。代码涉及Call.java（C层通信）、PlayerView.java（自定义播放View）和GLRenderer.java（渲染）。核心问题是长时间播放导致内存持续增长，最终导致应用崩溃。
问题分析：
Call.java使用HashMap和LinkedBlockingQueue存储解码帧数据。decodeMap以资源ID为键，每个资源对应一个容量为50的队列。虽然使用了对象池synchronizedPool复用MediaBean对象，但内存问题依然存在。关键在于，即使offer方法添加失败，也仅移除队列头部元素，并未真正释放内存。MediaBean中的bytes和codecdata数组的分配方式也存在问题：useByteBuffer为true时，预分配较大数组可能造成浪费；为false时，直接引用外部数组，如果C层持续创建数组，则可能发生内存泄漏。callback_videodecode和callback_directvideodecode中对packet和codecdata长度的限制（1024*500和600字节）过于粗糙，无法有效防止大数据导致的内存溢出。
PlayerView.java中的DecodeThread负责解码和渲染。cacheQueue容量为10，缓存解码失败的帧数据，但解码持续失败会导致队列溢出。mediaCodecDecode方法中，解码成功后释放MediaBean对象，但这并不保证立即回收bytes和codecdata数组占用的内存。DecodeThread线程长时间运行也可能占用大量内存。
GLRenderer.java负责渲染，本身无明显内存泄漏，但依赖于PlayerView提供的帧数据，PlayerView的内存管理问题会间接影响GLRenderer。
优化方案：
-
优化Call.java内存管理： 避免预分配大数组，在MediaBean中使用ByteBuffer，根据实际帧数据大小动态分配内存。移除
bytes和codecdata数组的长度限制，根据实际数据大小分配，并采用更精细的内存分配和释放机制，例如使用更小的缓存队列或更有效的内存管理策略。 -
优化PlayerView.java解码线程： 监控和控制
cacheQueue，避免溢出，考虑使用ArrayBlockingQueue。解码成功后，显式释放MediaBean对象中的ByteBuffer对象。定期检查和清理解码队列，及时释放不再需要的资源。 -
优化DecodeThread循环控制： 计数解码失败次数，超过阈值则停止解码或采取其他错误处理机制。
-
使用内存分析工具： 使用Android Studio自带的内存分析工具或LeakCanary等工具，定位内存泄漏点，进行精准优化。
通过以上优化，可以有效降低内存占用，解决长时间播放视频导致内存溢出的问题。 优化过程需结合实际情况，逐步测试和调整。
