标签:set layer 推荐 ram 大小 系统调用 cto connect inf
debug调试的framework日志信息:
根据日志,进入MediaPlayer的framework层看源码
先从
V/MediaPlayerNative: constructor
V/MediaPlayerNative: setListener
https://android.googlesource.com/platform/frameworks/av/+/master/media/libmedia/mediaplayer.cpp
可以看到这是正常的new了一个C++层的MediaPlayer
以及设置了一个Java层的弱引用给C++层的MediaPlayer监听,目前一切正常
再看后面的日志:
V/MediaPlayerNative: reset
......
V/MediaPlayerNative: setVideoSurfaceTexture
V/MediaPlayerNative: prepareAsync
可以看到这里对MediaPlayer的设置一切正常,没有异常。
包括后面通过url取获取HTTP流,以及获取大小都正常。
再看后面的日志:
V/PlayerBase: baseRelease() piid=679 state=1
......
发现MediaPlayer的父类PlayerBase居然被release了???
可以看到,这是MediaPlayer被系统给GC了。
V/MediaPlayerNative: setListener
disconnect
可以看到,这里是最后C++层的MediaPlayer也做了release
通过debug调试日志,可以分析出问题出在MediaPlayer被JVM的GC调用了finalize。
在调用MediaPlayer的prepareAsync后,开启一个异步延时线程,判断是否prepare成功,如果失败,则将MediaPlayer重置,在设置dataSource后再来一次prepare。
接入AOP框架,拦截MediaPlayer的finalize方法,在被GC系统调用前,记录状态改变。再做后续的重试处理。
考虑到AOP框架的大小,一般都上10M,如果考虑包体大小,可以采纳方案一,否则推荐方案二。
MediaPlayer的prepareAsync不回调onPrepared问题
标签:set layer 推荐 ram 大小 系统调用 cto connect inf
原文地址:https://www.cnblogs.com/diffx/p/11985648.html