iOS 7 Sprite Kit freeing up memory

ID : 274465

viewed : 53

Tags : iosmemory-managementphysicsgame-physicssprite-kitios

Top 5 Answer for iOS 7 Sprite Kit freeing up memory

vote vote


I had a lot of memory problems with Sprite Kit, and I used a tech support ticket to get info, and it may relate here. I was asking whether starting a new SKScene would totally release all the memory the previous one used. I found out this:

The underlying memory allocated by +textureWithImageNamed: may or may not (typically not) be released when switching to new SKScene. You cannot rely on that. iOS releases the memory cached by +textureWithImageNamed: or +imageNamed: when it sees fit, for instance when it detects a low-memory condition.

If you want the memory released as soon as you’re done with the textures, you must avoid using +textureWithImageNamed:/+imageNamed:. An alternative to create SKTextures is to: first create UIImages with +imageWithContentsOfFile:, and then create SKTextures from the resulting UIImage objects by calling SKTexture/+textureWithImage:(UIImage*).

I don't know if this helps here.

vote vote


All of that code is superfluous. Provided that you have no memory leaks or retain cycles in your code, once you release the Sprite Kit view everything will be cleared from memory.

Under the hood Sprite Kit employs a caching mechanism but we have no way of controlling it, nor should we need to if it is properly implemented (which is safe to assume).

If this is not what you're seeing in Instruments, check for retain cycles, leaks. Verify that dealloc of the scene and view does get called. Make sure no strong references to view, scene or other nodes remain in other objects (particularly singletons and global variables).

vote vote


After fighting this for a couple days, the key was in fact: [sceneView presentScene:nil]; Or for Swift: sceneView.presentScene(nil)

which can be done in viewDidDisappear. Without this, your view will hang on to the scene for dear life, even after being dismissed, and continue to chew memory.

vote vote


Swift 3:

In my personal experience I've solved with the help of the Xcode instruments, first of all with the activity monitor that showed me immediatly the huge memory increase, than with allocation and leaks.

But there is also an useful way, the debug console with

deinit {        print("\n THE SCENE \(type(of:self)) WAS REMOVED FROM MEMORY (DEINIT) \n") } 

This is another help to see if deinit was called everytime you want to remove a scene.

You do not ever have strong references to the scene or parent in your classes, if you have anyone you must trasform it to weak like for example:

weak var parentScene:SKScene? 

Same thing for protocol, you could declare it to weak like this example using the property class:

protocol ResumeBtnSelectorDelegate: class {     func didPressResumeBtn(resumeBtn:SKSpriteNode) }  weak var resumeBtnDelegate:ResumeBtnSelectorDelegate? 

ARC do all the work we needed but, if you think you've forgot to write correctly some property (initiliazation, blocks..) I've used also some functions like this for my debug phases :

func cleanScene() {     if let s = self.view?.scene {         NotificationCenter.default.removeObserver(self)         self.children             .forEach {                 $0.removeAllActions()                 $0.removeAllChildren()                 $0.removeFromParent()         }         s.removeAllActions()         s.removeAllChildren()         s.removeFromParent()     } }  override func willMove(from view: SKView) {     cleanScene()     self.removeAllActions()     self.removeAllChildren() } 
vote vote


I had a similar problem like you @user2857148. I would present a VC with:

[self presentViewController:myViewController animated:YES completion:nil]; 

In the @implementation myViewController I had :

- (void)viewDidLayoutSubviews {     // Configure the view.     SKView * skView = (SKView *)self.view;     skView.showsFPS = YES;     skView.showsNodeCount = YES;     self.ballonMGScene = [[MBDBallonMiniGame alloc] initWithSize:skView.bounds.size andBallonImageNames:self.ballonObjectsArray];     self.ballonMGScene.parentVC = self;     self.ballonMGScene.scaleMode = SKSceneScaleModeAspectFill;     self.ballonMGScene.physicsWorld.gravity = CGVectorMake(0, 0);     // Present the scene.     [skView presentScene:self.ballonMGScene]; }  

The problem was in :

self.ballonMGScene.parentVC = self; 

since in :

@interface MBDBallonMiniGame : SKScene <SKPhysicsContactDelegate> 

parentVC was declared with strong :

@property (nonatomic,strong) WBMMiniGameVCTemplate *parentVC; 

Solution 1:

and changing it to :

@property (nonatomic,weak) WBMMiniGameVCTemplate *parentVC; 

solved the problem for me.

Explanation: The reference to the parentVC (myViewController) which was a UIViewController has been stored somewhere. Since this VC had a strong reference to the SKScene , it was stored with it. I even had console output from this SKScene like it was still active. My best quess on why this happened to me was that I have most strong pointers.

Solution 2:

In my myViewController under :

- (void)viewDidDisappear:(BOOL)animated 

I called :

self.ballonMGScene.parentVC = nil; 

On leaving the current VC (myViewController) I set the pointer to nil, removing the memory and everything along with it.

These 2 solutions worked for me. I tested it with the debugger. The memory consumption went up and down correctly.

Hope this helps in understanding the problem and solutions.

Top 3 video Explaining iOS 7 Sprite Kit freeing up memory