java - 在这种情况下对生成的 BufferedImage 使用缓存吗？

Question

我正在实现一个棋盘游戏，其中每个玩家都有多个单元，并且每个单元都使用我使用以下方法从文件中读取的通用图像向用户显示。我在应用程序启动时读取了此图像并稍后使用它。

    private static BufferedImage readBufferedImage (String imagePath) {
        try {
            InputStream is = IconManager.class.getClassLoader().getResourceAsStream(imagePath);
            BufferedImage bimage = ImageIO.read(is);
            is.close();
            return bimage;
        } catch (Exception e) {
            return null;
        }
    }

单位因位于该公共(public)图像顶部的各种彩色标记而异。

在我向 JPanel 添加几个 commonImage 之前，标记是使用 float 在 commonImage 顶部的 JLabels 实现的

    //at startup
    ImageIcon commonImage = new ImageIcon(readBufferedImage("image.png"));
    ...
    JPanel panel = new JPanel();
    panel.add(commonImage);
    panel.add(commonImage);

    //located JLabels with token on the top of each commonImage        

但是，现在我想使用 JScrollPane 而不是 JPanel，因此我认为在向用户显示每个 commonImage 之前对每个 commonImage 进行 drawString() 和 drawImage() 是更好的方法。

我大约估计单位数量为 20。所以现在每个单位的每个回合我都需要生成具有各种 token 配置的动态单独的 BufferedImage。

问题是，如果之前已使用相同的配置生成了图像，我是否应该根据 token 配置缓存已生成的 BufferedImages 以从缓存中提取？

Answer 1

您提出的问题取决于几个因素:

1. 从头开始生成图像需要多长时间
2. 检查图像是否之前生成需要多长时间
3. 每张图片有多大
4. 图像被重复使用的概率

因此，如果不充分了解您的应用程序，没有人能够针对每种情况为您提供准确的答案。

一般来说，如果您只是移动代币，那么应该很快就能实现 update和 paintComponent面板的绘制方法。如果您保存基础图像、 token 图像和当前生成的图像(基本上是您建议的)，我预计不会出现性能问题。关键是在您的自定义 update 中更新图像方法，并始终在 paintComponent 中绘制当前结果图像方法。

更新

例如，您可以使用类似于以下的代码缓存当前显示:

private BufferedImage cachedImage;
...

@Override
public void paintComponent(Graphics g){
    //If the image needs to be refreshed draw it to the cache first
    if(cachedImage == null){
        cachedImage = new BufferedImage(getWidth(), getHeight(), BufferedImage.TYPE_4BYTE_ABGR);
        super.paintComponent(cachedImage.getGraphics());
    }

    //Draw the image from cache
    g.drawImage(cachedImage, 0, 0, this);
}

当您想要清除缓存时，在执行更新的方法中，您可以设置 cachedImage = null;

但是在你的情况下，

• 您在 200x200 比例下遇到的任何性能问题都与您正在绘制的绘图数量有关。因为我猜你不关心帧/秒速率，所以我怀疑你会遇到性能问题(你可以收集计时来准确了解绘制需要多长时间 - 我猜不到 100 毫秒)
• 最简单的方法是缓存 token 及其字符串的图像(我假设它们很少更改)，但仍然动态创建 token 的布局。 (在您的情况下，任何其他性能提升都不会那么容易)。
• 缓存先前的屏幕渲染将从本质上破坏 Swing 显示模型(使用它没有多大意义 - 只需自己进行布局即可)。这实际上适用于几乎所有容器的缓存。