android LOG 中提示Out of memory ！！！！！

Question

补充一点，每次报错的时候都是打开Activity的时候

Answer 1

基本上我的所有图片都是在XML中很少动态的去修改，图片也很小的，一般都不超过几十K

Answer 2

你应该又几百k的图片被加载了吧？android设计规范种也有说到不建议讲图片设计的过大，对于背景图片建议使用.9格式化，不知道是否可以帮到你。

Answer 3

我的背景图片比较大一点有100多K其它的也就几K，十几K，可能整个界面加起来有200-300多K吧，就这么点图片，基本上所有的图片都是在XML中设定好了，JAVA不是有自动的垃圾回收么，每一次销毁Activity的时候我都还调用了System.gc()垃圾回收一下的

Answer 4

你是使用bitmap么？这个要手动释放资System.gc();只能释放Java部分的，bitmap要调用recycle()释放资源。

Answer 5

基本上我都没有用bitmap，有背景的地方都是在XML设置好了，动态修改控件背景的很少，都是调用ImageView的setBackgroundResource，直接设定背景图片

Answer 6

其实有时候真的没必要把很大分辨率的图片按照32位解码来作为背景图啥的，可以根据屏幕大小 压缩解码，另外可以解码成RGB565，这样可以减少很多内存，而基本没影响显示效果。

Answer 7

System.gc() 只是对系统提出一个建议，虚拟机在没有耗尽内存的情况下是可能不会调用它的。 毕竟调用一次也是有性能消耗的。

Answer 8

其实调用了gc() 也不是说系统会立刻清理内存的，只是你给它安排了一个任务，啥时候执行就看系统自己的调度了。
但是不建议频繁调用这个gc接口。基本没什么用

Answer 9

其实调用了gc() 也不是说系统会立刻清理内存的，只是你给它安排了一个任务，啥时候执行就看系统自己的调度了。
但是不建议频繁调用这个gc接口。基本没什么用是，楼主也真有耐心，反复开启关闭半个小时。

Answer 10

楼主的 更新图形的 线程 在关闭的时候作了什么处理呢？是不是每次打开Activity都新开一个线程，就是说 半个小时过去了 你的程序里新开了很多个线程在同时执行。

Answer 11

我的线程其实做的更新ImageView中的图片很少了，线程关闭是的时候肯定就没有再有更新了，还有就是每一次关闭Activity的时候我的线程都是退出了的，所以说同时开了很多线程执行是不存在的，不过后续我会多测试看看，因为我的Activity中还有一个视频播放器在播放视频，我看看是不是这里的影响，没有办法有这个业务逻辑， 我就必须这样去测试，谢谢指点

Answer 12

坚强的小小名字好喜感呀，看到小小就想起了DOTA里面的小小

Answer 13

我的线程其实做的更新ImageView中的图片很少了，线程关闭是的时候肯定就没有再有更新了，还有就是每一次关闭Activity的时候我的线程都是退出了的，所以说同时开了很多线程执行是不存在的，不过后续我会多测试看看，因为我的Activity中还有一个视频播放器在播放视频，我看看是不是这里的影响，没有办法有这个业务逻辑， 我就必须这样去测试，谢谢指点all right.

Answer 14

其实调用了gc() 也不是说系统会立刻清理内存的，只是你给它安排了一个任务，啥时候执行就看系统自己的调度了。
但是不建议频繁调用这个gc接口。基本没什么用贴一下自己在DDMS中测试的数据第一张是在频繁切图的时候的数据，当Free只有2M的时候再继续关闭Activity,然后再打开Activity的时候就容易报OOM错误，如果Free只有2M左右暂停关闭再打开的动作，一直等待几分钟。那么DDMS中的FREE就有明显的变化，增多了，如第二张图所示，%USED也会减少，有点不明白的时候data object一直都没有减少，最开始只有50，000左右，一直涨到途中所示，没有明显的下降

Answer 15

我的线程其实做的更新ImageView中的图片很少了，线程关闭是的时候肯定就没有再有更新了，还有就是每一次关闭Activity的时候我的线程都是退出了的，所以说同时开了很多线程执行是不存在的，不过后续我会多测试看看，因为我的Activity中还有一个视频播放器在播放视频，我看看是不是这里的影响，没有办法有这个业务逻辑， 我就必须这样去测试，谢谢指点all right.

Answer 16

坚强的小小名字好喜感呀，看到小小就想起了DOTA里面的小小嘿嘿，同道中人呐~

Answer 17

有没有可能存在对bitmap的静态(static)类型的引用？

Answer 18

有没有可能存在对bitmap的静态(static)类型的引用？
这样可能导致gc机制不能及时释放内存

Answer 19

我的线程其实做的更新ImageView中的图片很少了，线程关闭是的时候肯定就没有再有更新了，还有就是每一次关闭Activity的时候我的线程都是退出了的，所以说同时开了很多线程执行是不存在的，不过后续我会多测试看看，因为我的Activity中还有一个视频播放器在播放视频，我看看是不是这里的影响，没有办法有这个业务逻辑， 我就必须这样去测试，谢谢指点all right.贴一下自己在DDMS中测试的数据第一张是在频繁切图的时候的数据，当Free只有2M的时候再继续关闭Activity,然后再打开Activity的时候就容易报OOM错误，如果Free只有2M左右暂停关闭再打开的动作，一直等待几分钟。那么DDMS中的FREE就有明显的变化，增多了，如第二张图所示，%USED也会减少，有点不明白的时候data object一直都没有减少，最开始只有50，000左右，一直涨到途中所示，没有明显的下降，贴图已经回了阁下了

Answer 20

有没有可能存在对bitmap的静态(static)类型的引用？
静态类型的引用？没有，我的所有图片资源都没有声明是静态类型的，还有就是XML文件中android:background="@drawable/ipad_xxxx_bg"
这样直接设定控件背景算不算？

Answer 21

贴一张出现OOM的时候DUMP出的文件，用MAT分析的
按照
1.点击文件上面的Histogram会打开一个视图.2.在class name那一栏最底部, 会有一行Total**** 然后右击选项ExpandAll.3. 点击Shadow Heap排序, 最顶层的就是泄露最多的地方.4.右击某个calss选择ListObjects->incoming reference.5.然后就可以看到在哪些地方有些路, 逐个排查对应的代码.此方法排上面的就是最有可能泄露的地方
到了这一步就不知道怎么查看了
右键选择java.lang.String ListObjects->incoming reference
如下所示完全不知道怎么查看，跟自己的程序联系起来了

Answer 22

有没有可能存在对bitmap的静态(static)类型的引用？
静态类型的引用？没有，我的所有图片资源都没有声明是静态类型的，还有就是XML文件中android:background="@drawable/ipad_xxxx_bg"
这样直接设定控件背景算不算？这个不算静态引用

Answer 23

有没有可能存在对bitmap的静态(static)类型的引用？
静态类型的引用？没有，我的所有图片资源都没有声明是静态类型的，还有就是XML文件中android:background="@drawable/ipad_xxxx_bg"
这样直接设定控件背景算不算？这个不算静态引用
有没有可能存在对bitmap的静态(static)类型的引用？
静态类型的引用？没有，我的所有图片资源都没有声明是静态类型的，还有就是XML文件中android:background="@drawable/ipad_xxxx_bg"
这样直接设定控件背景算不算？这个不算静态引用用过MAT来分析没有，我用了，但是看不太明白，上面有我的切图，麻烦看看

Answer 24

其他问题不知道。
但是 System.gc() 这个是通知系统回收，但是并不是立即回收。