1

我的最后一个问题没有得到解答，所以我正在尝试不同的方法。我将许多纹理（256x256 RGBA888）动态加载到内存中，并在需要时丢弃它们。问题是有时当我将纹理上传到OpenGLES 时需要 40-80 毫秒，很少更多。我发现，这个缓慢的时间是在垃圾收集之后。问题是，这GC有时会阻塞GL线程（FPS 下降），有时会阻塞纹理加载器线程（OK）。有没有一种好方法可以不允许GC在GL线程上发生？

System.gc()我尝试在每 1、2、3...n 个纹理被解码后调用纹理加载器线程，并且这GC-ing在GL线程上有效地删除了，但现在纹理加载速度要慢得多，因为该线程必须等待 GC 完成。使“n”更大可以使加载更快，但GC在GL线程上更有可能，因此动画不连贯。

对于在不同线程中解码的位图，是否有某种方法可以GC-ing在线程上删除？GL我不在GL线程上解码/分配任何位图，并且GC-ing仅在加载新纹理时发生。

编辑：应用程序的目标是 android 3.2 和更新版本，还有手机。这发生在手机（HTC One S - 4.0.3）和平板电脑（Nexus 7 - 4.1、Galaxy Tab 2 10.1 - 3.2 和 4.0、Acer Icona A200 - 4.0）上

4

2 回答 2

2

您不能完全禁用垃圾收集，它将由 Dalvik VM 启动，而不会受到您的干扰。

您可以通过使用一些自定义加载纹理来最小化内存分配和释放，例如使用预分配数组来存储源纹理数据等。正如您所提到的，所有纹理都具有相同的尺寸和颜色深度，因此您将需要一个临时缓冲区任何图像的大小相同（256x256x4 = 262144 字节）。

最终，您可以将 OpenGL 代码移动到 JNI C/C++ 代码，以按照您想要的方式管理内存。

于 2012-12-17T13:35:30.813 回答
0

感谢这个视频，有一个简单的解决方案，适用于相同大小的图块并针对 Android 3.0 及更高版本。

BitmapOptions.inBitmap将为每个新图块重用一个Bitmap，因此不再有 furios GC-ing。

于 2013-02-05T11:16:35.660 回答