我目前正在使用这本书"学习LibGdx游戏开发,第二版"作为编程时的参考书,我偶然发现了他们对Asset Management类的实现。他们使用单身模式来实现它,这是我真正没有经验的东西。在所有屏幕中只有一个这个Manager类的实例,它将在游戏关闭时处理。因此,从我(相当缺乏经验)的pov中我会同意作者单身人士是有道理的,因为这样我就不必将它传递给我需要它的每个班级。但是我也听说他们得到了有点坏名声所以我想我会问这里。在LibGdx中为Asset Management类使用单例模式是否有意义?
答案 0 :(得分:3)
这里不断有人问为什么他们的纹理被破坏了,而且总是因为他们试图使用静态引用或单例作为他们的资产。但是你知道如何确保你处理所有一次性用品并且在重新开启游戏时总是加载新的实例,那么它应该没问题。
任何实现Disposable的东西必须在它超出范围或游戏关闭之前处理掉。如果您使用AssetManager加载了某些东西,那么仅处理AssetManager实例就足够了,该实例将间接处理它加载的所有内容。
顶级ApplicationListener类的dispose
方法是应用程序的保证退出点,您必须确保在此方法结束时处置游戏中任何位置的所有一次性用品。
create
方法意味着你有一个新的游戏实例,所以你不应该尝试重用对Disposables的任何静态引用。
许多人遇到此问题的原因是单身人员经常是懒人加载,所以第一次重新加载游戏时,资产管理器实例不会被重新创建(因为即使游戏活动退出,Android应用程序也会保持活力,所以静态引用存在)。
答案 1 :(得分:2)
如果您正在学习libGDX游戏开发,那么使用单例(或其他static
资源)是您真正应该避免的事情。
如果你没有正确管理和理解static
变量的生命周期(懒惰的初始化,就像单身人士常用的那样是不正确管理它们的一个很好的例子)那么你最终可能会使用不再有效的资源或具有您可能不期望的值的资源。这是因为静态可能比你的应用程序更长。当然,你可以解决这个问题,但这是你在学习时真正不想处理的问题。
但更重要的是,这是一个糟糕的结构(面向对象设计)的良好迹象。您不需要访问那么多类中的资源来证明单例的合理性。您通常只需要访问例如资源。您的Screen
实施。
答案 2 :(得分:0)
单独使用静态字段
public class YourGameClass implements ApplicationListener
{
public static AssetManager assetMgr;
}
会更简单,更容易。只需在游戏准备就绪时分配(例如create
方法),然后按YourGameClass.assetMgr
引用它。当您的应用程序即将死亡时(例如在dispose
中) - 将其丢弃。
简单。由于您只有一个YourGameClass
实例,因此您不会遇到麻烦。