这个问题涉及到Android中的内存。
我的方法:
我有两个活动,A和B。从A中启动B的方法如下:
Intent i = new Intent(A.this, B.class);
startActivity(i);
在B中点击按钮时,我会执行以下操作:
B.this.finish();
- 我在B中重写onDestroy方法,并将所有引用设为null。
- 在A的onResume方法中,我没有分配新的内存。
- 我没有泄漏上下文。
- 我没有使用多个线程。
- 我没有使用服务。
- B中的所有变量都是私有类变量,并且它们在B的onDestroy中全部设置为null。
- B中的ImageView对象在B的onDestroy中背景被设置为null。
- 我确定B被销毁了。
结果:
当我在Activity A中时,堆内存为7.44 MB。然后当我启动B并在B上调用finish(从而返回到A),堆增加了0.16 MB。再次重复此过程,每次堆都会增加0.08 MB。
- 我没有查看堆限制,而是查看已分配的堆。
- 我在B的onDestroy方法的末尾调用System.gc()。
附加信息:
-我使用MAT分析内存分配并尝试找到此泄漏。奇怪的是,Activity B似乎有5个实例。正如它发生的那样,我重复了startActivity/finish过程5次。最底部的条目是Activity,其他条目是活动中的监听器:
这是dominator树的截图。我找不到任何异常或可疑之处。
-我看过关于内存使用(和泄漏)的两个谷歌IO视频。
问题:
无论我做什么,都有可能分配这0.08 MB的堆(并且无法被GC收集)吗?如果不行,有什么可能会导致这种情况?
更新:
我尝试在B中启动Activity而不设置内容视图。这意味着B是一个完全空的活动。结果是,当我多次重新启动活动时,堆内存没有增加。但请注意,这不是解决方案。我必须能够设置内容视图。
scorpiodawg:我尝试在模拟器上运行我的应用程序,但堆仍然增长。很好的尝试。
ntc:我在所有可能的地方将所有出现的“this”更改为“getApplicationContext()”。因为setContentView需要引用布局文件而不是上下文,所以我无法调用setContentView(getApplicationContext())。我取而代之的是在Activity B的onDestroy方法中创建一个空布局文件,并调用setContentView(emptylayout)。但这没有帮助。
我尝试删除所有代码,只调用setContentView(mylayout)。问题仍然存在。然后我从布局XML文件中删除了所有GUI元素。问题仍然存在。唯一剩下的是容器视图,几个嵌套的线性、相对和滚动布局。我尝试删除滚动条中的“android:scrollbarDefaultDelayBeforeFade”属性设置。结果很好,内存泄漏消失了。然后我重新放回了之前删除的所有代码,但没有设置“android:scrollbarDefaultDelayBeforeFade”属性,内存泄漏又出现了。多么奇怪啊!