Measures against asset bundle memory leaks that occur in the Addressables system

The Asset Bundle memory leak that occurs in the Addressables system is a serious technical bug that frequently occurs during actual device testing and rendering pipeline expansion. A solution to a bug where dynamically loaded assets using the Addressable Asset System are not released from memory and accumulate.

Specific symptoms of the problem

When you first start the game, it runs smoothly, but as you repeatedly clear and retry stages, or open the gacha screen for different characters over and over again, your smartphone will gradually become erratic, and the app will eventually be forcefully terminated by the OS.

Real world example: A problem in which you rent a hotel room (memory), but do not return the key to the front desk (Release) even after the trip is over, and all the rooms are filled with "imaginary guests (residual memory)", making it impossible for new guests to stay

Every time I rent (load) an asset, the key is left stuck in the hotel room, and the system continues to misunderstand that there are guests in the hotel room even though no one is using it. The code enforces the rule of always returning the key to the front desk when checking out (Release), and the empty room is thoroughly cleaned (garbage collection) for the next asset.

Assumed causes and detailed mechanism

I dynamically loaded assets into memory by calling `Addressables.LoadAssetAsync` or `Addressables.InstantiateAsync` in Addressables, but since I did not call the corresponding `Addressables.Release` after use, the "reference counter (RefCount)" in memory did not decrease, and asset bundle memory area remains in VRAM forever.

Solution approach and optimization procedure

Strictly manage the life cycle of assets in C# code, and make sure to call `Addressables.Release` without exception, using the `AsyncOperationHandle` obtained at load time and the instance body as arguments, when the object is destroyed or at the moment of scene transition.