处理JNI ERROR (app bug): accessed stale local reference 0xbc00021报错
2016-04-26 21:59
417 查看
最近接sdk出现一个jni的报错,并且根据机型并不是必现类型的bug,查了好多资料,并未解决问题。
网上流传的说法比较可信的是,再android的4.0版本之后,静态变量会有可能被释放,这个是可能的,但出现的情况非常少,并不像自己的真机包出现问题那么频繁。
关于android的java回收,研究下来,应该是当系统资源非常少的时候,会选择性地释放一些资源,用来减少压力,而Activty应该下属的对象有可能被回收,在应用恢复的时候,再通过Application重建对象,以前的版本静态变量是不可能被回收,而4.0以后的版本,则在极端的情况下,会回收静态变量。
然而实际测试下来,就算数据释放,造成应用无法恢复,大多android系统也会自行切换重启应用,以避免错误,所以由静态变量引发的异常应该少之又少。
最后通过跟踪和日志,发现在jni里(cocos2dx目前使用4.0版本),当一个string参数被传入nil值,则该对象为一个野指针,因此在某些情况下并不会造成崩溃,所以比较难发现这类问题。
因此,解决该问题,还是先检查传入参数是否正常,类型是否匹配,是否存在空值,作为第一优先,jni内部,没有对此做保护判断,因此就会产生一些难以捉摸的bug。
JNI ERROR (app bug): accessed stale local reference 0xbc00021
网上流传的说法比较可信的是,再android的4.0版本之后,静态变量会有可能被释放,这个是可能的,但出现的情况非常少,并不像自己的真机包出现问题那么频繁。
关于android的java回收,研究下来,应该是当系统资源非常少的时候,会选择性地释放一些资源,用来减少压力,而Activty应该下属的对象有可能被回收,在应用恢复的时候,再通过Application重建对象,以前的版本静态变量是不可能被回收,而4.0以后的版本,则在极端的情况下,会回收静态变量。
然而实际测试下来,就算数据释放,造成应用无法恢复,大多android系统也会自行切换重启应用,以避免错误,所以由静态变量引发的异常应该少之又少。
最后通过跟踪和日志,发现在jni里(cocos2dx目前使用4.0版本),当一个string参数被传入nil值,则该对象为一个野指针,因此在某些情况下并不会造成崩溃,所以比较难发现这类问题。
因此,解决该问题,还是先检查传入参数是否正常,类型是否匹配,是否存在空值,作为第一优先,jni内部,没有对此做保护判断,因此就会产生一些难以捉摸的bug。
相关文章推荐
- 使用C++实现JNI接口需要注意的事项
- Android IPC进程间通讯机制
- Android Manifest 用法
- [转载]Activity中ConfigChanges属性的用法
- Android之获取手机上的图片和视频缩略图thumbnails
- Android之使用Http协议实现文件上传功能
- Android学习笔记(二九):嵌入浏览器
- android string.xml文件中的整型和string型代替
- i-jetty环境搭配与编译
- android之定时器AlarmManager
- android wifi 无线调试
- Android Native 绘图方法
- Android java 与 javascript互访(相互调用)的方法例子
- android 代码实现控件之间的间距
- android FragmentPagerAdapter的“标准”配置
- Android"解决"onTouch和onClick的冲突问题