Assets singletons and reference cycles - swift

Question

I currently have an Assets singleton class that provides me access to textures, sounds, and music. As my partner and I are going through the memory management stage of our project we have realized that we may have a serious leak being created, and based on my use of Xcode instruments our biggest issue may center around this singleton class. While there are certainly other leaks present, we have noticed that when moving between map screen and game screen back and forth, there is a fairly steady increase of ~100 mb, which appears to correspond to our 11 map assets. With that context, my question is this:
Would the code below create a retain cycle, and if so, can it be managed with the existence of the singleton class, or ought we break this thing up s.t. texture atlases are held separately?
func transitionToMapScreen()
{
//I hope this isn't necessary eventually, but we were trying to ensure all game textures and emitters were deallocated
Assets.sharedInstance.deallocateGameAssets()
gameScene = GameScene()
Assets.sharedInstance.preloadMap
{
[unowned self] in
let mapScene = MapScreen(fileNamed: "MapScreen")!
mapScene.preCreate()
mapScene.scaleMode = self.scaleMode
// Transition with a fade animation
let reveal = SKTransition.fade(withDuration: 2.0)
let fadeMusic = SKAction.run
{
Assets.sharedInstance.bgmTitlePlayer?.setVolume(1.0, fadeDuration: 1.0)
Assets.sharedInstance.bgmTitlePlayer?.play()
Assets.sharedInstance.bgmGamePlayer?.setVolume(0.0, fadeDuration: 1.0)
}
let stopGameMusic = SKAction.run
{
Assets.sharedInstance.bgmGamePlayer?.stop()
}
let transitionAction = SKAction.run
{
self.view?.presentScene(mapScene, transition: reveal)
}
self.run(SKAction.sequence([SKAction.wait(forDuration: 1.0), fadeMusic, SKAction.group([stopGameMusic, transitionAction])]))
} // end Assets.sharedInstance.preloadMap completion block*/
}
From what I understand about retain cycles in Swift, isn't this creating a self reference to the Assets class and creating a memory leak? And could this explain the behavior of our map assets being retained in memory? And if so, what is the proper method of managing this?

Answer 1

I wanted to post this here for those who might be looking for an answer to a similar problem related to hunting down retain cycles to explain memory growth issues. First, thanks very much to all those who helped me halt my neurons' random frantic attempts to find retain cycles where there were none (or were not ones big enough to matter). Now:
First, retain cycles are scary, sure, but using instruments to find them and then managing as Apple recommends since Swift 4.2 is appropriate:
something()
{
[weak self] in
guard let self = self else { return }
self.whatever()
}
I've seen some people argue that you should determine whether unowned or weak makes sense -- this honestly takes the guesswork out and is much easier. I did find unowned crashes are rare anyway at least for us, but I won't opine on your app, and this solves things. Now, then, once you have cleaned house:
We discovered that our memory growth issues stemmed not from our asset singleton class inherently but rather the sheer size of our texture atlases and corresponding overlapping usage of those atlases. I cannot recommend this discussion enough: How does SKTexture caching and reuse work in SpriteKit?. That will explain conceptually the issues you might face with atlases better than I can.
Summarily, however: SpriteKit manages the allocation of your texture atlases, and accordingly you must understand that if you have a very large atlas that is frequently loaded it may not manage it as you expect (I still don't have enough detail to describe that in a better way, but as I said please reference the discussion above as well as Apple's developer guide on SKTextureAtlas: https://developer.apple.com/documentation/spritekit/sktextureatlas).
Now, related to that Apple discussion, I noted this line, which I think really ought to be bolded and in red: "SpriteKit implicitly loads an atlas when one of the atlas's textures is accessed." This was critical to solving what I think was our underlying issue: we had a few places where we accessed textures in the atlas via a single instance for some reason -- you must recognize that in the case of a large atlas SpriteKit will then load your entire massive atlas into memory. So I no longer take lightly Apple's note to manage your atlas sizes. Atlases are meant for assets that are always used together and are going to be drawn together. Loading disparate assets into an atlas was our mistake. We are reorganizing how we manage these accordingly.