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等工具，定位內存泄漏點，進行精準優化。
通過以上優化，可以有效降低內存占用，解決長時間播放視頻導致內存溢出的問題。 優化過程需結合實際情況，逐步測試和調整。
