Android ListView 行背景导致 OutOfMemory 问题

Question

我有一个 fragment ，它从网络服务中提取数据并将其显示在 ListView 中。我有 10 个不同的选择器可用于行背景。一旦循环，背景就会重复。

我面临的问题是设备(Galaxy Nexus!)无法处理显示所有这些背景。当我通过 setbackgroundResource 设置背景时，操作系统不断调用 GC 以释放内存，这使得 ListView 滚动非常不稳定。

所以我尝试缓存使用的 Drawables。我看到了改进，但设备最终会抛出一个 OutOfMemory 异常，原因是缓存了多少 Drawable。举例说明有多少被缓存，我需要所有 10 个选择器，每个选择器包含两个可绘制对象，加上第一个和最后一个，因为它们是不同的。这是内存中的 24 个可绘制对象。

现在，我想这可能是我正在使用的图像的大小，我需要缩小它们并按比例拉伸(stretch)，但我不确定这是否可行。

有什么建议吗？我花了几天时间不停地研究这个问题，但还没有找到可行/关闭的解决方案。

谢谢

亚当

Answer 1

米米尼托，

您描述的问题困扰着 Android 平台上的许多开发人员。这样做的原因是，当谷歌实现 View Drawables 时，他们不得不做出一个有效的假设，即之前的 Drawable 可能需要保留。这是因为越来越多的平台上越来越多的应用程序需要这种行为。

最终，有多种方法可以缓解这些问题，但没有一个包罗万象的解决方案。

1. 替换背景时，获取原始背景。如果它是位图，recycle() 它。如果它是一个 Drawable，将引用设置为 null 并通过 setCallback 移除其回调(这在您改变方向或切换 Activity 时尤为重要)。

2. 图形是最消耗内存的资源之一。如果您使用的是 Drawable 或 Bitmap，则每个像素使用 4 个字节。但是，如果必须调整图像大小才能正确显示，那么无论应用程序是放大还是缩小，它实际上都会使用更多。以高分辨率创建图形很棒，但对于移动设备，您希望将其缩放到您实际要使用的尺寸。

3. 如果您要使用大量图形，您可以考虑仅使用那些将可见的图形。也就是说，如果您有 32 个项目，但只有 3 个是可见的，则只加载可见的 3 个，也许还有一些直接的邻居。可以为许多标准化控件实现延迟加载。

4. 我建议查看 .9.png 文件。这些非常适合优化图形。

5. 如果您的按钮有文本，请不要将其绘制在图形文件上。允许 Android 将文本放置在图形文件上。它的处理方式大不相同，并且内存消耗大大减少。虽然它可能不那么美观，但它会增加可靠性(这就是你在这里的原因)

6. 在某些情况下，可能希望图形是平面位图，而不是压缩格式。这减少了处理器和内存的负载，但以文件大小为代价。这是因为压缩格式必须在内存中解压缩才能使用，但在文件实际关闭之前内存不会被释放。 (这甚至不包括用于解压缩它的运行时代码的内存，而且当应用程序必须调整图形大小时，成本甚至更高)。

7. 放入一些额外的 System.gc() 语句可以帮助减轻负载，但它并不可靠，因为它只是告诉系统它已准备好尽早进行垃圾回收。

8. 最后，您可以根据设备的分辨率设置多种尺寸。这是您可以通过您的应用程序传输的信息。这就是我们必须在本地应用程序中实现多设备支持的方式。

所有这些建议都可能有所帮助，但信息量很大。希望我已经为您提供了足够的信息来实现满足您需求的解决方案。

希望对您有所帮助，模糊逻辑