但是,如果您从资源的角度来看这(意味着jpeg或png图像),则说它们是“ 16位”或“ 32位”是毫无意义的. JPEG是一种颜色表示形式,通常您可以将其扩展为32位,但也可以将其解压缩为16位(并且在执行此操作时可能希望抖动以使其看起来不错). PNG可以根据图像存储很多表示形式,并且通常会选择最佳的表示形式.此外,在打包期间,aapt会遍历所有PNG图像,并将它们重新压缩为尽可能小的最终图像,因此,如果可以,它甚至可以使用调色板表示.

因此,存储图像的方式并不重要.重要的是在运行时将其解压缩时创建的位图.这里有一些一般规则：

>如果图像具有Alpha,则需要将其解压缩为完整的32位.
>如果帧缓冲区和表面为32位,则应将图像解压缩为32位.
>如果图像没有Alpha,则可能是888(32位)或565(16位).挑选要使用的东西很棘手.

从历史上看,我们在平台上使用的设备具有16位屏幕,因此我们不得不处理其带来的复杂性.主要问题是在内存使用与渲染性能与质量之间取得平衡.对于内存使用和渲染性能,最好使用16位…但是,对于许多图像,如果图像没有抖动,则将出现色带.

在哪里进行抖动也很棘手：理想情况下,您会在生成原始图像的过程中进行抖动处理,但这限制了您可以执行的操作(不进行缩放,这意味着不使用9色块).另一方面,您可以在渲染时执行此操作,但这意味着您需要将图像加载为32位,并在每次将其绘制到屏幕时进行抖动处理.这提供了最大的灵活性,但具有更多的内存和性能影响.

现在在实践中,这实际上对于平台来说是一个罕见的问题-因为几乎所有用作9补丁等图像都具有透明度,无论如何它们都需要以32位加载,因此它不会太大渲染时会抖动.

这一切都要做的是：

>如果图像具有透明度,请不要担心,它将以32位加载.
>如果您的图片没有透明度,则需要：

>确定是否抖动原始图像.这将在16位屏幕上提供更好的质量(与性能关键渲染代码相比,抖动效果更好),但不会充分利用32位屏幕.
>让平台决定要做什么.对于16位和32位屏幕,这都将提供良好的结果,但是您不想缩放图像.
>自己加载图像,并显式控制API以确定使用哪种格式以及何时(或是否)抖动.