我有一个 OpenGL Android 应用程序，它使用大量内存来设置复杂的场景，这显然会导致严重的堆碎片。即使不存在内存泄漏，也不可能在不因碎片而耗尽内存的情况下销毁和创建应用程序。 （碎片肯定是问题，而不是泄漏）
这会导致一个主要问题，因为 Android 习惯于在同一个 VM/堆上销毁和创建 Activity，这显然会导致 Activity 崩溃。作为应对这一问题的策略，我使用了以下技术：
@Override
protected void onStop() {
super.onStop();
if(isFinishing()) {
System.runFinalizersOnExit(true);
System.exit(0);
}
}
这确保了当活动完成时，它会导致虚拟机完全关闭，因此下次活动启动时，它会获得一个新的未碎片的堆。
注意：我意识到这不是“Android 方式”，但鉴于垃圾收集器是非压缩的，因此不可能连续重用堆。
这种技术实际上在一般情况下确实有效，但是当活动在非完成模式下被销毁然后重新创建时，它就不起作用了。
有人对如何处理堆的退化有什么好的建议吗？
进一步注意：减少内存消耗也不是真正的选择。该活动实际上并没有使用那么多内存，但堆（和本机堆）似乎很容易碎片化，可能是由于一些大的内存块
碎片几乎总是不良分配模式的结果。大型对象经常被创建和销毁。与可能持续存在的较小对象（或至少具有不同的生命周期）结合在一起，会在堆中创建空洞。
在这种情况下，唯一有效的碎片预防方法是：阻止特定的分配模式。这通常可以通过合并大型对象来完成。如果成功，应用程序将庆幸地以更快的执行速度承认这一点。
@编辑：更具体地回答你的问题：如果应用程序重新启动后堆还不为空，那么堆上还剩下什么？您确认这不是内存泄漏的问题，但这就是看起来的问题。由于您正在使用 OpenGL - 是否有可能一些本机包装器幸存下来，因为 OpenGL 资源尚未正确处置？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
