Android的背景图片的内存使用情况 [英] Android background image memory usage

查看:179
本文介绍了Android的背景图片的内存使用情况的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我工作的项目使用了几个高分辨率的背景(注意引号)。刚进入的情况下,其中之一是一640x935 1.19M PNG文件。据我所知,即使Android的DECOM presses图像到内存中的原始数据,这应该是:

640×935 x 4字节= 2.39M

我有我的项目的内存问题,我不能真正理解,我希望有人能够说明这个问题的一些情况。我的名字,我开发的一些结果两个设备。

要确保这是不是我做了一个活动不会加载后台首次创建时一个次要问题,然后,当用户presses一个按钮,它的作用是:

<$p$p><$c$c>findViewById(R.id.completed_block_background).setBackgroundResource(R.drawable.blockbackgroundbottom1);

然后,使用的过程中DDMS与更新堆(与第一次迫使GC,以确保这不会是一个问题),我得到了以下内存结果:

的Nexus S:从18M去26M(8M差)

Galaxy Nexus的:从28M去39M(11M差)

所以,你可以看到,把那theorically 2.39M uncom pressed形象到背景实际上增加8M和11M的内存使用情况。一个人能解释这是为什么,如果有什么解决办法?

我已经能够找到使用位图减半分辨率或降低声道格式的唯一解决方案(到目前为止,这是我做了什么,切换他们565 RGB,但是这使得一些条纹问题,这是我不能接受)。

我也能接受,如果没有什么可以做的,为什么发生这种情况的解释。先谢谢了。

解决方案
  

这就是为什么它使图像这么大?

那么,什么情况是, setBackgroundResource(R.drawable.blockbackgroundbottom1)将会使机器人先做 BitmapFactory.de codeResource()的事情你有尝试,但都呈现逻辑的规模,将其应用作为背景图像。因此,例如,Galaxy Nexus的和Nexus S之间的差异3MB可能反映的大小差异,以像素为单位的引渡的的LinearLayout

之间

此外,还可能会出现一些重采样将基于屏幕像素密度,这取决于您在其中存储这个形象在你的资源树。

  

有没有什么办法让它保持原始图像的尺寸以任何方式?

即兴,我先试试把它放在 RES /绘制-nodpi / (以prevent任何自动基于密度的重采样),然后手动得到在位图通过 BitmapFactory.de $的C $ cResource(),是以版的 BitmapFactory.Options ,这样你就可以得到它的规模,因为它正在被读入。如果这样做似乎没有多大帮助,您可能需要移动PNG出可绘制资源到原始资源或资产,由于Android还是会抱着试试看到图像的未缩放副本。我不认为它会如果使用 BitmapFactory.de codeResource()直接自己,但我不能排除这种可能性。

The project I'm working on uses several "high resolution" backgrounds (note the quotes). Just to get into situation, one of them is a 640x935 1.19M PNG file. As far as I know, even if Android decompresses images into memory as raw data this should be:

640 x 935 x 4bytes = 2.39M

I'm having memory issues on my project which I cannot really understand and I hope someone can shed some light on this matter. I'll name two devices that I am developing in and some of the results.

To make sure this wasn't a secondary problem I made an activity not load the background when first created and then, when the user presses a button, all it does is:

findViewById(R.id.completed_block_background).setBackgroundResource(R.drawable.blockbackgroundbottom1);

Then, using DDMS with "Update Heap" on the process (and first forcing GC to make sure this won't be a problem), I'm getting the following memory results:

Nexus S: Going from 18M to 26M (8M difference)

Galaxy Nexus: Going from 28M to 39M (11M difference)

So, as you can see, putting that theorically 2.39M uncompressed image into the background actually increases 8M and 11M in memory usage. Can someone explain why is this and if there is any solution?

The only solution I have been able to find is using bitmaps to halve resolution or to lower the channel format (so far this is what I have done, switched them to 565 RGB, but this makes some banding problems which I cannot accept).

I would also accept, in case there's nothing that can be done, an explanation of why this is happening. Thanks in advance.

解决方案

Is that why it's making the image so big?

Well, what's happening is that setBackgroundResource(R.drawable.blockbackgroundbottom1) is going to cause Android to first do the BitmapFactory.decodeResource() thing you that experimented with, but then have the rendering logic scale the image to apply it as a background. So, for example, the 3MB difference between the Galaxy Nexus and the Nexus S probably reflects the size difference, in pixels, between the renditions of the LinearLayout.

There may also be some resampling going on based on screen density, depending upon where you have stored this image in your resource tree.

Is there any way to make it keep the original image size in any way?

Off the cuff, I would first try putting it in res/drawable-nodpi/ (to prevent any automatic density-based resampling), then manually get the Bitmap via the version of BitmapFactory.decodeResource() that takes the BitmapFactory.Options, so you can get it scaled as it is being read in. If that does not seem to help much, you may need to move the PNG out of drawable resources and into a raw resource or assets, as Android might still try holding onto an un-scaled copy of the image. I don't think that it will if you use BitmapFactory.decodeResource() directly yourself, but I cannot rule it out.

这篇关于Android的背景图片的内存使用情况的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆