AssetManager and Screen lifecycle: where should reference counting and unloading live?

Answer

The screen that loads a set of assets should own the decision to unload them, but this decision must be mediated by a central coordinator (e.g., a ScreenManager) that knows which screens are active and whether any retrieved asset references are still in use.

Confirmed facts from libGDX 1.12.x

• AssetManager uses internal reference counting: each load() increments, each unload() decrements; the native GPU resource is disposed only when the count reaches zero.
• Multiple calls to get() for the same asset path return the same instance without increasing the reference count.
• Calling Texture.dispose() manually on an asset obtained via get() while the manager still holds a reference corrupts the count and can cause OpenGL errors.
• AssetManager.dispose() should be invoked once at application shutdown, not during screen transitions.

Recommended steps for your setup

1. Use two AssetManager instances:
   • Persistent manager – holds UI skin, fonts, and any assets that stay alive for the whole game.
   • Level manager – holds assets that are specific to a level or screen group.
2. In each Screen’s show() method, load only the level‑specific assets you need via the level manager’s load().
3. In the same screen’s hide() (or dispose()) call the level manager’s unload() for the exact asset descriptors you loaded in show(). Do not call dispose() on the returned Texture objects.
4. Never mix manual Texture.dispose() with AssetManager.unload() on the same resource.
5. If you store references to assets retrieved via get() beyond the screen’s lifetime (e.g., in a sprite pool or UI cache), you must defer unloading until all such references are released. This is where a coordinator comes in:
• The coordinator tracks which screens are currently active and which asset paths they have loaded.
• Before allowing a level manager’s unload(), the coordinator checks that no active screen (or cached pool) still holds a reference to that asset.
• If a reference exists, the unload is postponed; otherwise it proceeds.

Missing diagnostic detail

Do you retain any Texture (or other asset) references obtained from AssetManager.get() after the screen that loaded them has been hidden or disposed? If the answer is “yes”, you need the coordinator pattern described above; if you never keep such references beyond the screen’s lifetime, the simple screen‑owned load/unload in show()/hide() is sufficient.

Verification (optional)

// Pseudocode for a quick test
levelManager.load('level1/texture.atlas', TextureAtlas.class);
TextureAtlas atlas = levelManager.get('level1/texture.atlas');
// Simulate another screen holding a reference
SpritePool.shared.add(atlas.findRegion('hero'));
// Now call unload from the first screen
levelManager.unload('level1/texture.atlas'); // Should be deferred if coordinator is used