2

プロファイルの情報は次のとおりです-> Xcodeでリークし、クラッシュする前にiPad 2で約21分12秒間実行しました。

ライブ バイト ---- 5.45 MB

生活 ---- 13547

一時的 ---- 3845036

全体のバイト -- 720.31 MB

アプリがデバイスで実行されている場合、アプリがクラッシュし、コンソールに受信メモリ警告が表示されます。

私はそれがどのように機能するかよくわかりません。

しかし、アプリがデバイスで 21 分間実行され、この実行中に全体で約 720 MB のメモリを使用しているにもかかわらず、ライブ バイトが 7.0 MB を超えないかどうか教えてください。

アプリがライブ バイトとして 3.25 MB を使用して開始し、この実行中にライブ バイトで 5.45 MB になることを受け入れます。ライブ バイトがこのように増加する方法はよくわかりません。

しかし、私の質問は次のとおりです。

デバイスで実行中にクラッシュするほど悪いアプリですか?

または

私は他の問題に直面していますか？

4

1 に答える 1

5

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 :) ).

于 2013-01-28T14:50:48.527 に答える