16 位图像和 Android 处理
我是否正确地说 16 位图像的解码和绘制速度比 24 或 32 位图像更快？我知道文件大小会更小，但如果位图的绘制速度实际上比转换它们的速度要快，那么就值得付出努力。如果速度更快，我该如何保存 16 位 jpeg 文件？我只在 Photoshop 中找到了保存 16 位位图的选项...即 54 MB。
Am i correct in saying a 16 bit image will be decode and drawn faster than a 24 or 32 bit? I know the file size will be less but if the bitmaps will actually be drawn faster than it would be worth the effort to convert them. If it is faster, how would i go about saving a 16 bit jpeg file? I only found an option in photoshop to save a 16 bit bitmap...which is 54 MB.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我希望您指的是 16 位 RGB 565 格式，是的，它的渲染速度应该比 24 位 RGB 888 或 32 位 RGB 8888 格式更快。您在 Photoshop 中看到的可能与 RGB 565 不同，而是每个组件 16 位的 RGB，它是每个像素 8 位的 RGB 的两倍。
AFAIK JPEG 不支持 16 位格式（每像素 565 或 16 位）。
I hope you mean the 16-bit, RGB 565 format, yes it should be faster to render than a 24-bit RGB 888 or 32-bit RGB 8888 formats. What you saw in photoshop might be not the same as RGB 565, but RGB with 16-bit per component, which doubles a RGB with 8 bits per pixel.
AFAIK JPEG doesn't support 16-bit formats (eiter 565 or 16-bit per pixel).
这取决于。如果您的屏幕（以及绘制到其上的表面）是 16 位，则速度可能会更快；但是，如果它们是 32 位，则 32 位位图可能会更快。
但是，如果您从资源角度（这意味着 jpeg 或 png 图像）来看待此问题，则说它们是“16 位”或“32 位”是相当没有意义的。 JPEG 是一种颜色表示形式，您通常会将其扩展为 32 位，但您也可以解压缩为 16 位（并且可能希望在解压缩时进行抖动以使其看起来不错）。 PNG 可以存储多种表示形式，具体取决于图像，并且通常会选择最好的表示形式。此外，在打包过程中，aapt 会遍历所有 PNG 图像并将它们重新压缩为尽可能小的最终图像，因此如果可以的话，它甚至可能使用调色板表示。
因此，如何存储图像并不重要；重要的是。重要的是在运行时解压缩时创建的位图。这里有一些一般规则：
从历史上看，我们在该平台上使用的设备都具有 16 位屏幕，因此我们必须处理由此带来的复杂情况。主要问题是平衡内存使用与渲染性能与质量。对于内存使用和渲染性能，16 位是最好的...但是，对于许多图像来说，如果图像没有抖动，就会出现色带。
在哪里进行抖动也很棘手：理想情况下，您可以将其作为生成原始图像的一部分来执行，但这限制了您可以用它做的事情（没有缩放，这意味着不使用 9 补丁）。另一方面，您可以在渲染时执行此操作，但这意味着您需要将图像加载为 32 位，并在每次将其绘制到屏幕时进行抖动。这提供了最大的灵活性，但对内存和性能的影响更大。
现在在实践中，这实际上最终成为平台的一个罕见问题——因为几乎所有用作 9 补丁或此类的图像也具有透明度，无论如何它们都需要作为 32 位加载，因此它不会太大渲染时进行抖动处理。
这一切的目的是：
It depends. If your screen (and thus the surfaces drawn to it) are 16 bit, it can be faster; if they are 32 bit, though, a 32 bit bitmap may be faster.
However if you are looking at this in terms of resources -- which means jpeg or png images -- saying they are "16 bit" or "32 bit" is fairly meaningless. JPEG is a color representation that you will typically expand to 32 bit, though you could also decompress to 16 bit (and probably want to dither while doing so for it to look decent). PNG can store in a lot of representations, depending on the image, and generally picks what is best. Moreover, during packaging, aapt runs through all PNG images and re-compressing them into a final image that is as small as possible, so it may even use a paletted representation if it can.
So how you store images does not really matter that much; what matters is the bitmap that is created when decompressing it at runtime. There are some general rules here:
Historically the devices we have worked with on the platform have had 16 bit screens, so we've had to deal with the complications from it. The main issue is balancing memory use vs. rendering performance vs. quality. For memory use and rendering performance, 16 bit is best... however, for many images there will be color banding if there is no dithering of the image.
Where to do that dithering is also tricky: ideally you'd do it as part of generating the original image, but that limits what you can do with it (no scaling, which means no use of 9-patches). On the other side, you could do it when rendering, but that means you need to load the image as 32 bit and dither every time it is drawn to the screen. This gives the most flexibility, but has more memory and performance impact.
Now in practice, this actually ends up being a rare issue for the platform -- because almost all images that are used as 9-patches or such also have transparency, they need to be loaded as 32 bit anyway, so it is not too big a deal to dither when rendering.
What this all boils to do is: