java - 渲染大 Bitmap 的小区域非常耗时

Question

我有以下代码。

this.getGame().getGraphics().drawBitmap(Assets.playScreen_LaserBeamAnimation, new Rect(0, 0, 100, 750), new Rect(0, 0, 100, 750), null);
this.getGame().getGraphics().drawBitmap(Assets.playScreen_LaserBeamAnimation, new Rect(0, 200, 10, 800), new Rect(0, 0, 200, 600), null);

第一个渲染语句需要大约 0.6 - 1 秒 来渲染。 第二个大约 1 毫秒。

Bitmap 很大:968 KB 并加载了以下代码:

public Bitmap readAssetsBitmap(String filename) throws IOException {
        try {
            BitmapFactory.Options options = new BitmapFactory.Options(); 
            options.inPurgeable = true;
            Bitmap bitmap = BitmapFactory.decodeStream(assets.open(filename), null, options);
            if(bitmap == null) {
                WSLog.d(Game.GAME_ENGINE_TAG, this,"File cannot be opened: It's value is null");
                throw new IOException("File cannot be opened: It's value is null");
            }
            else {
                WSLog.d(Game.GAME_ENGINE_TAG, this,"File successfully read: " + filename);
                return bitmap;
            }
        } 
        catch (IOException e) {
            WSLog.d(Game.GAME_ENGINE_TAG, this,"File cannot be opened: " + e.getMessage());
            throw new IOException("File cannot be opened: " + e.getMessage());
        }

    }

我希望读取图像和设置 Bitmap 需要一些时间，但是渲染它的一小块区域应该不会花这么长时间(神秘的是它只是第一个渲染调用)。

如何避免第一次渲染花费这么长时间？

注意:它不必对缩放做任何事情(我相信)。

Answer 1

TL;DR 加载和渲染图形实际上是一组相对昂贵的(内部)操作，首先加载到内存中，然后在首次渲染到屏幕时加载到 ARM CPU 的图形模块中。此外，动画 GIF 被扩展为一组图像，每个动画帧对应一个图像，这使得它比您想象的要大得多。要提高速度，您可以考虑减小动画大小(像素和帧数)，或强制 GIF 提前进入图形内存以避免第一帧停顿。

---

Android 必须在内部做很多事情来渲染游戏图形，尤其是当您有 GIF 动画时:

• 从(相对较慢的)RAM 加载图像
• 解压文件
• 将 256 色模型映射到 RGBA 空间
• 从 GIF 文件中的图像增量生成动画的每一帧
• 创建一个带有计时器的线程以在 GIF 的不同帧之间切换

现在我们在 CPU 内存中有了一个图像(实际上是一组帧)。请注意，具有很多帧的非常小的 GIF 可能会在内存中变得非常大 - Android 必须为 GIF 中的每个帧提供一个全尺寸图像。此外，256 位颜色模型在内部扩展为 RGBA，因此每个像素有 4 个字节。

以 GIF(128x128 像素)为例，上面有一个小形状动画(32x32 像素)。让我们进一步假设您在动画中有 100 个步骤——这可能是 10k 左右，具体取决于背景的简单程度。然而，在内存中扩展，动画中的每一帧是 4x128x128 = 64kB。你有 100 帧，所以你的内存大小是 6MB。

下一步:

• 如果使用 3D，我们必须将图像编译成图形模块的内部纹理格式
• 将数据流式传输到图形内存中(这需要很长时间 - 这就是为什么大多数 3D 游戏在游戏 fragment 之间都有那些“正在加载...”页面的原因)
• 将图像从图形模块的格式更改为实际屏幕的颜色深度(例如 RGB 格式具有 24 位颜色，但 LCD 显示器通常具有 18 或 20 位颜色深度。显卡必须转换图像并且通常会引入抖动来模拟额外的颜色)

一旦将图像(实际上是一堆帧)加载到图形模块中，事情就会变得很快。

好的，那你能做些什么呢？以下是一些建议:

• 减小 GIF 的像素大小，或减少动画中的帧数
• 预加载
• 如果图片很大就平铺

减小 GIF 的大小 可以显着减少内存使用，这将减少 Android 将帧推送到图形模块所需的时间以及编译为纹理的成本。缺点是您可能无权修改图形。

预加载 通过在游戏加载阶段强制渲染，将图像更早地推送到图形模块中。图像可能在屏幕外(将窗口设置为隐藏)或通过设置低 Z 顺序或在 1 像素区域中位于顶层之后。

Tiling 在 my answer to a similar question 中讨论).以谷歌地球作为最极端的例子——它为地球上的每个区域使用瓦片(在任何给定的分辨率下)。为了仅呈现您感兴趣的部分，Google 地球必须仅加载要显示的图 block 。因为图 block 很小，所以加载速度很快。但是，在您的情况下，您可能有一个 GIF 动画，所以这是行不通的。平铺动画可能不切实际，或者可能导致图像的渲染部分出现伪像或延迟。