Android背景图像内存使用情况
我正在使用的项目使用了几个“高分辨率”的背景（注意引号）。 只是为了进入情况，其中之一是一个640×935 1.19M PNG文件。 据我所知，即使Android将图像解压缩到内存中作为原始数据，应该是：
640×935×4字节= 2.39M
我在我的项目上遇到了内存问题，我不能理解，我希望有人能够对此有所了解。 我将命名两个我正在开发的设备和一些结果。
为了确保这不是第二个问题，我创build了一个活动，在第一次创build时不会加载背景，然后当用户按下button时，所做的只是：
findViewById(R.id.completed_block_background).setBackgroundResource(R.drawable.blockbackgroundbottom1); 然后，在进程上使用“更新堆”的DDMS（并首先强制GC，以确保这不会是一个问题），我得到以下内存结果：
Nexus S：从18M到26M（8M的差距）
Galaxy Nexus：从28M到39M（11M的差距）
所以，正如你所看到的，把理论上的2.39M未压缩的图像放到后台，实际上增加了8M和11M的内存使用量。 有人可以解释这是为什么，如果有任何解决scheme？
我能find的唯一解决scheme是使用位图来减半分辨率或降低通道格式（到目前为止，这是我所做的，将它们切换到565 RGB，但是这造成了一些我不能接受的分段问题）。
我也接受，如果没有什么可以做的，解释为什么会发生这种情况。 提前致谢。
这就是为什么它使图像如此之大？
那么，发生什么事情是setBackgroundResource(R.drawable.blockbackgroundbottom1)将导致Android首先做你试验过的BitmapFactory.decodeResource()东西，但是然后让渲染逻辑缩放图像作为背景。 因此，例如，Galaxy Nexus和Nexus S之间的3MB差异可能反映了LinearLayout的再现之间的大小差异（以像素为单位）。
也可能会根据屏幕密度进行一些重新采样，具体取决于您将此图像存储在资源树中的哪个位置。
有什么办法可以保持原始图像的大小？
closures袖口，我会先尝试把它放在res/drawable-nodpi/ （为了防止任何基于密度的自动重采样），然后通过BitmapFactory.decodeResource()的BitmapFactory.decodeResource()版本手动获取Bitmap您可以在阅读时将其缩小。如果这看起来没什么帮助，那么您可能需要将PNG从可绘制资源中移出，并转换为原始资源或资源，因为Android可能仍会尝试保留未经授权的资源，缩放的图像副本。 我不认为如果你自己直接使用BitmapFactory.decodeResource() ，但是我不能排除它。
