Search code examples
cocos2d-iphone

Memory warnings in Cocos2d/Box2d apps on device (iPhone/iPad)


Here's the info of profile->leaks in Xcode and I ran it on iPad 2 for about 21 mins 12 seconds before crashing.

live Bytes ---- 5.45 MB

Living ---- 13547

Transitory ---- 3845036

overall Bytes -- 720.31 MB

When the app is running on device, the app crashes printing Received Memory Warning in Console.

I'm not very sure of how it works.

But please tell me if an app runs for 21 minutes on a device, uses an overall of around 720 MB memory in total during this run, yet live bytes never go beyond 7.0 MB.

I accept that the app starts by using 3.25 MB as live bytes & it goes to 5.45 MB on live bytes during this run & I'm not pretty sure how live bytes go on increasing like this.

But my question is:

Is it an app bad enough to produce crashes while running on device?

Or

Am I facing some other problem?


Solution

  • You probably are leaving tons of sprites in the CCTextureCache singleton. Everytime you create a CCSprite, the texture is cached (silently) so that the next time you refer to it, the loading and presentation will be faster (much faster). Run the allocations profiling in simulator (see two pics below):

    THIS RUN IN DEVICE

    and

    This run in simulator

    The top image is from allocations profiling on device. Max memory 4.4 Mb.

    The bottom image is the same app, the SAME gameplay sequence, while profiling in the simulator (peaks at around 78 Mb). By running in simulator, i can see in the allocations the memory used by my sprites. In the device, this memory is not accounted for by the allocations tool.

    You are looking for trends and discrete big jumps. If you never come back down, you are probably leaving behind unused sprites. In my case, i choose to free specific resources from the textures at specific point in the game's execution. Here is an example from the appController

    - (void)applicationDidReceiveMemoryWarning:(UIApplication *)application {
        MPLOGERROR(@"Before purge");
        [[CCTextureCache sharedTextureCache] dumpCachedTextureInfo];
    
        [CCAnimationCache purgeSharedAnimationCache];
        [[CCSpriteFrameCache sharedSpriteFrameCache] removeSpriteFrames];
        [[CCDirector sharedDirector] purgeCachedData];
    
        MPLOGERROR(@"%After purge");
        [[CCTextureCache sharedTextureCache] dumpCachedTextureInfo];
    
    }  
    

    This is last ditch, brute force cleanout. But you can remove specific textures at different point during game play without impacting the 'perceived' responsiveness of the app. Caches are generally sound in principle, but can become rapidly tricky in the face of constrained resources. Learn about it, experiment, and eventually you will find the right mix of 'what stays/what goes' for smooth application performance.

    ps. although the simulator is fine for certain tests, dont use its 'performance' as a benchmark. Simulator performance is meaningless when it comes to graphics, it does not use your computer's GPU (and that is why you see the graphic memory allocation :) ).