7

我有以下代码。

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

    }

我希望读取图像和设置位图需要一些时间，但是渲染它的一个小区域不应该花费这么长时间（而且神秘地它只是第一次渲染调用）。

如何避免第一次渲染需要这么长时间？

注意：它与缩放无关（我相信）。

4

2 回答 2

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 像素区域中位于顶层之后。

在我对类似问题的回答中讨论了平铺）。以谷歌地球作为最极端的例子 - 这对地球上的每个区域都使用瓷砖（在任何给定的分辨率下）。要仅渲染您感兴趣的部分，Google 地球必须仅加载要显示的图块。因为图块很小，所以它们加载速度很快。但是，在您的情况下，您可能有一个 GIF 动画，所以这是行不通的。平铺动画可能不实用，或者可能导致图像部分渲染出现伪影或延迟。

于 2013-05-15T02:47:32.003 回答
0

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

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

在渲染时，您可以将当前位图替换为您要绘制的位图，或者您可以在不缩放的情况下将图像绘制到位（比使用缩放绘制要快得多）。

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

更新：为什么它这么慢。Java 图形真的很笨。我的猜测是，在第一个示例（长示例）中，当它看到区域具有相同的比例时，它会遍历整个大图像，并且每当找到该给定区域中的像素时，它就会将其绘制在目的地地区。

在快速绘制中，我的猜测是它看到比例不同，然后向后执行：对于目标区域中的每个像素，它会找出原始图像中要引用的像素，并相应地混合到那个正方形中。

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

Java.Graphics 真的很糟糕。您是否查看过其他 3rd 方图像处理库？

于 2013-05-12T19:14:13.870 回答