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);

第一个render语句需要0.6 - 1 second来渲染。第二个围绕1 millisecond。

位图很大：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游戏在游戏细分之间都有“加载...”页面的原因）
将图像从图形模块的格式更改为实际屏幕的颜色深度（例如RGB格式具有24位颜色，但LCD显示器通常具有18或20位颜色深度。图形卡必须转换图像并且通常会引入抖动以模拟其他颜色）

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

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

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

缩小GIF的大小可以显着降低内存使用量，这将减少Android将帧推入图形模块所需的时间以及编译成纹理的成本。缺点是你可能没有权限修改图形。

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

平铺在my answer to a similar question中讨论。以Google Earth为最极端的例子 - 它使用地球上每个区域的瓷砖（以任何给定的分辨率）。要仅渲染您感兴趣的位，Google地球必须仅加载要显示的切片。因为瓷砖很小，所以它们加载速度很快。但是，在你的情况下你可能有一个GIF动画，所以这不会起作用。平铺动画可能不实用，或者可能导致人工制品或图像部分渲染延迟。

Answer 2

看起来您正在尝试使用包含所有帧的大位图来绘制动画。如果是这种情况，那么缩小图像可能不适合你。

但是，如果图像中有n个离散帧，那么为什么不在加载图像时创建n个位图并在应用加载时将它们存储在ArrayList<Bitmap>中？这样，您可以预渲染图像，而不必担心渲染时切片图像。

在渲染时，您可以将当前位图替换为您想要绘制的位图，也可以draw the image in place without scaling（比使用缩放绘制快得多）。

这可能会占用更多内存，但可能会提供明显的加速。

<强>更新：为什么它如此缓慢。 Java图形真的很愚蠢。我的猜测是，在第一个例子（长的一个）中，当它看到区域是相同的比例时，它会遍历整个大图像，每当它找到一个在给定区域内的像素时，它就会在目的地区域。

在快速抽奖中，我猜测它会看到刻度不同然后向后：对于目标区域中的每个像素，它会找出原始图像中要引用的像素，并相应地混合到该正方形中。

由于目标区域中的像素数量要少得多，因此算法要快得多。

Java.Graphics非常糟糕。你有没有看过其他的第三方图像处理库？

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

2 个答案: