h4l*_*c0n 56 memory android background
我正在研究的项目使用了几个"高分辨率"背景(请注意引号).只是为了进入情境,其中一个是640x935 1.19M PNG文件.据我所知,即使Android将图像作为原始数据解压缩到内存中,这应该是:
640 x 935 x 4bytes = 2.39M
我的项目中存在内存问题,我无法理解,希望有人可以对此事进行阐述.我将列出我正在开发的两个设备以及一些结果.
为了确保这不是次要问题,我在第一次创建活动时没有加载背景,然后当用户按下按钮时,它所做的只是:
findViewById(R.id.completed_block_background).setBackgroundResource(R.drawable.blockbackgroundbottom1);
然后,在进程上使用带有"Update Heap"的DDMS(并且首先强制GC确保这不会成为问题),我得到以下内存结果:
Nexus S:从18M上升到26M(8M差异)
Galaxy Nexus:从28M到39M(11M差异)
因此,正如您所看到的,将理论上2.39M未压缩的图像放入背景实际上会增加8M和11M的内存使用量.有人可以解释为什么这个以及是否有任何解决方案？
我能找到的唯一解决方案是使用位图将分辨率减半或降低通道格式(到目前为止,这就是我所做的,将它们切换为565 RGB,但这会产生一些我无法接受的条带问题).
如果没有什么可以做的话,我也会接受解释为什么会这样.提前致谢.
Com*_*are 112
这就是为什么它使图像如此之大？
嗯,正在发生的事情是,setBackgroundResource(R.drawable.blockbackgroundbottom1)这将导致Android首先完成BitmapFactory.decodeResource()您尝试过的事情,但随后让渲染逻辑缩放图像以将其应用为背景.因此,例如,Galaxy Nexus和Nexus S之间的3MB差异可能反映了版本之间的大小差异(以像素为单位)LinearLayout.
根据屏幕密度,可能还会进行一些重新取样,具体取决于您在资源树中存储此图像的位置.
有没有办法让它以任何方式保持原始图像大小？
关闭袖口,我会首先尝试将其放入res/drawable-nodpi/(以防止任何基于密度的自动重采样),然后手动获取Bitmap通过版本的BitmapFactory.decodeResource()那个BitmapFactory.Options,所以你可以在读入时进行缩放.如果是这样的话.似乎没什么帮助,你可能需要将PNG从可绘制的资源转移到原始资源或资产中,因为Android可能仍会尝试保留图像的未缩放副本.我不认为如果你BitmapFactory.decodeResource()自己直接使用它,但我不能排除它.