java - 使 Asset Manager 成为单例

Question

我目前在编程时使用“Learning LibGdx Game Development, Second Edition”一书作为参考书，我偶然发现了他们对资产管理类的实现。他们使用单例模式来实现它，我真的没有经验。这个 Manager 类在所有屏幕中只有一个实例，并且会在游戏关闭时被释放。所以从我（相当缺乏经验）的观点来看，我同意作者的观点，单身是有道理的，因为这样我就不必把它传递给我需要它的每个班级。但是我也听说他们得到了一点名声不好，所以我想我会在这里问。对 LibGdx 中的资产管理类使用单例模式是否有意义？

Answer 1

这里经常有人问为什么他们的纹理被破坏了，结果总是他们试图对他们的资产使用静态引用或单例。但是，如果您了解如何确保在重新打开游戏时处理所有一次性物品并始终加载新实例，那么应该没问题。

任何实现 Disposable 的东西都必须在它超出范围或游戏关闭之前被处理掉。如果您使用 AssetManager 加载了某些内容，那么仅处置 AssetManager 实例就足够了，该实例将间接处置它加载的所有内容。

您的顶级 ApplicationListener 类的dispose方法是您应用程序的保证退出点，您必须确保游戏中任何位置的所有一次性用品都在此方法结束时被释放。

该create方法意味着您有一个新的游戏实例，因此此时您不应尝试重用对 Disposables 的任何静态引用。

许多人对此有疑问的原因是单例通常是延迟加载的，因此第一次重新加载游戏时，不会重新创建资产管理器实例（因为即使游戏 Activity 退出，Android 应用程序也经常保持活动状态，因此是静态的引用继续存在）。

Answer 2

如果您正在学习 libGDX 游戏开发，那么static您确实应该避免使用单例（或其他资源）。

如果您没有正确管理和理解static变量的生命周期（通常与单例一起使用的延迟初始化是未正确管理它们的一个很好的例子），那么您最终可能会使用不再有效或具有价值的资源你可能没想到。这是因为静态数据可能比您的应用程序寿命更长。当然你可以解决这个问题，但这是你在学习时真的不想处理的问题。

但更重要的是，它很好地表明了结构不好（面向对象设计）。您不需要访问那么多类中的资源来证明单例的合理性。您通常只需要访问资源，例如您的Screen实现。

Answer 3

一个单独的静态场像

public class YourGameClass implements ApplicationListener
{
    public static AssetManager assetMgr;
}

会更简单，更容易。只需在游戏准备就绪时分配它（如在create方法中），并通过YourGameClass.assetMgr. 当您的应用程序即将终止时（例如在 中dispose） - 将其丢弃。

简单的。由于您只有一个 的实例YourGameClass，因此您不会遇到任何麻烦。