Game Development Reference
In-Depth Information
CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
Keep an eye on these log messages. If you notice that the dealloc log message is
never sent when you switch from one scene to another, that's a huge warning sign. In
that case, you're leaking the whole scene, not freeing its memory. It's extremely un-
likely when using ARC, but it can still happen—for example, if you assign the scene to
a custom class's property, such as a view controller or singleton whose lifetime isn't
tied to cocos2d scenes. In that case, the scene might be replaced but not removed from
memory because the custom class still has a reference to the scene. You're most likely
to run into this issue when assigning node objects as delegates for UIKit classes, like
Game Center. Be extra careful to set any delegate to nil before replacing the scene.
One thing you should never do is add a node as a child to the scene graph and then pass
this node to another node which then keeps a reference to it. Retain cycles—where ob-
ject A holds on to object B while object B itself holds a reference to object A—are still
possible with ARC. In these cases, neither object lets go of the other, keeping them in
memory until the app is closed.
Use cocos2d's methods to access node objects instead. As long as you let cocos2d
worry about managing the memory of nodes, you'll be fine.
Pushing and Popping Scenes
With regard to changing scenes, the pushScene and popScene methods of Director
can be useful tools. They run the new scene without removing the old scene from
memory. If you think of your scenes as sheets of paper, pushing a scene means a new
sheet of paper is added on top of the currently visible one. The paper underneath stays
in place and in memory, unlike in replacing scenes. For each pushed scenes, you then
need to call popScene (like removing the topmost sheet of paper) until only the ini-
tial scene is left.
The idea is to make changing scenes faster. But there's the conundrum: if your scenes
are lightweight enough to share memory with each other, they'll load fast anyway. And
if they're complex and thus slow to load, chances are they take away each other's pre-
cious memory—and memory usage can quickly climb to a critical level.
Search Nedrilad ::

Custom Search