Mim*_*ito 1 android listview background bitmap out-of-memory
我有一个片段,它从Web服务中提取数据并在ListView中显示.我有10个不同的选择器,可以用于行背景.一旦循环就重复背景.
我面临的问题是设备(Galaxy Nexus!)无法处理显示所有这些背景.当我通过setbackgroundResource设置后台时,操作系统不断调用GC来释放内存,这使得ListView滚动非常不稳定.
所以我尝试缓存使用的Drawables.我看到了一个改进,但设备最终会抛出一个OutOfMemory异常因为缓存了多少Drawables.为了举例说明有多少是缓存的,我需要所有10个选择器,每个选择器包含两个drawable,加上第一个和最后一个,因为它们是不同的.这是内存中的24个drawable.
现在,我认为它可能是我正在使用的图像的大小,我需要缩小它们并按比例拉伸,但我不确定这是否会起作用.
有什么建议？我已经花了几天时间在这个不停的工作,并没有找到一个可行/近距离的解决方案.
谢谢
亚当
Mimminito,
您描述的问题困扰着许多Android平台上的开发人员.这样做的原因是,当Google实施View Drawables时,他们必须做出有效的假设,即可能需要保留之前的Drawable.这是因为越来越多的平台上越来越多的应用程序需要这种行为.
最终,有几种方法可以缓解这些问题,但没有一种方法可以解决所有问题.
替换背景时,获取原始背景.如果是Bitmap,recycle()那就是.如果它是Drawable,则将引用设置为null并删除其回调setCallback(当您更改方向或切换活动时,这尤其重要).
图形是消耗最多内存的资源之一.如果您使用的是Drawable或Bitmap,则每个像素使用4个字节.但是,如果必须调整图像大小以便正确显示,那么无论应用程序正在升级还是缩小规模,它实际上都会使用更多.以高分辨率创建图形非常棒,但对于移动设备,您希望将其缩放到您实际要使用的尺寸.
如果您使用大量图形,则可以考虑仅使用那些可见的图形.也就是说,如果你有32个项目,但只有3个可见,只加载3个可见的项目,也许是一些直接邻居.可以为许多标准化控件实现延迟加载.
我建议查看.9.png文件.这些非常适合优化图形.
如果您的按钮有文本,请不要在图形文件上绘制它.允许Android将文本放在图形文件中.它的处理方式大不相同,内存消耗大大减少.虽然它可能不那么美观,但它会提高可靠性(这就是你在这里的原因)
在某些情况下,可能需要使图形为平面位图,而不是压缩格式.这减少了处理器和内存的负载,但是以文件大小为代价.这是因为压缩格式必须在内存中解压缩才能使用,但在文件实际关闭之前不会释放内存.(这甚至不包括用于解压缩它的运行时代码的内存,并且当应用程序必须调整图形大小时甚至更昂贵).
添加一些额外的System.gc()语句可以帮助减轻负载,但它不可靠,因为它只告诉系统它已经为垃圾收集做好了准备.
最后,您可以根据设备的分辨率设置多种尺寸.这是您可以通过您的应用程序传输的信息.这就是我们在本地应用程序中执行多个设备支持的方式.
所有这些建议可能会有所帮助,但它有很多信息.希望我能为您提供足够的实施解决方案以满足您的需求.
希望这会有所帮助,FuzzicalLogic
| 归档时间： |
|
| 查看次数： |
992 次 |
| 最近记录： |