Replicating no. of sprites without letting the app to slow down and crash

Question

Is it possible that if I'm making a a simple drag-n-drop game, does making a new sprite via constructor with texture as a parameter makes the game slower and depletes more memory until it crashes or does making a new texture via constructor cause the memory to go slow? I'm on a revision for the new drag-n-drop puzzle game where the only goal is to stack the most no. of objects as you can before it falls off the platform. Is it a good idea to create another sprite with texture as a parameter every time a player drag-n-drop another object?

Here's the start of the dry run looked like and I set it to debug mode so that the platform is completely block the pit to test the replication test.

Afterwards, when it reaches from hundreds to thousands, this will be like this and the game gets slower.

When the game crashes, here's the result via Logcat:

12-11 16:38:53.953: E/AudioTrack(25701): AudioFlinger could not create track, status: -22
12-11 16:38:53.953: E/SoundPool(25701): Error creating AudioTrack
12-11 16:38:53.993: D/dalvikvm(25701): GC_EXPLICIT freed 947K, 14% free 14414K/16672K, paused 2ms+4ms, total 96ms
12-11 16:39:16.363: E/AudioTrack(25701): AudioFlinger could not create track, status: -22
12-11 16:39:16.363: E/SoundPool(25701): Error creating AudioTrack
12-11 16:39:16.433: D/dalvikvm(25701): GC_FOR_ALLOC freed 2120K, 15% free 14418K/16848K, paused 47ms, total 47ms

By the way, I'm using BodyEditor library for Box2D program and rendering, a physics engine.

Answer 1

The use of keyword new results in costly allocation to heap memory during play.

On mobile apps (not only!), you should always pre-allocate your maximum number of objects, and assign them to an object pool. During initialisation, create an object pool consisting of say, 200 objects. Whenever a object is to be created or destroyed, you simply take one from the pool, or put it back into the pool, respectively. The pool is simply a list holding references to existing, unused objects. In some implementations, it's a class wrapping that list and providing pool access methods.

This pooling approach should apply to your box2d objects and your graphics objects like Sprite; for that matter, any object which is used to compose your "Fruit" entities.

Answer 2

You should be able to create a lot more sprites than you've currently got, as long as you don't create a new Texture each time.

From your pictures, you seem to use textures more than once, so you should be able to have something like:

// In some class that manages sprite textures
Texture blueSquareSmiley = new Texture(...);
Texture yellowSquareX = new Texture(...);

// Then where you create your sprites
for(... 1000 times ...) {
    Sprite aBlueSquareSmiley = new Sprite(blueSquareSmiley);
    world.addSprite(aBlueSquareSmiley);
}

That's how you should be able to manage your textures.

Based on your Logcat, it looks like either the Audio system can't allocate something (could be some other application though) or perhaps the is GC being busy (though it is freeing stuff on the order of 1MB which isn't much).