HowTo - Using XCode Instruments to test your iOS app

HopscotchHopscotch Member, PRO Posts: 2,782
edited February 2015 in Working with GS (Mac)

If you have a memory intensive game, it is good practice to use Instruments to analyse how your game behaves on different devices.

The rule of thumb says that your game should not load more than 50% of available memory in game data and images. The reason for this is that it needs room to shuffle and reorganise memory as assets get swapped out of memory.

Steps 1 and 2 are also useful for those who would like to know how to load an adhoc build on their device.

Step 1 - Generating your game

Publish your game to GameSalad, then generate and sign your game.

Make sure to only use a "Development Profile" to sign your game. Adhoc profiles will not be recognised by Instruments.

Step 2 - Loading your game on your device

Connect your mobile device to your Mac and open the Device Browser from XCode

In Devices, select your connected mobile device, then find your signed game and drag it to the Installed Applications list.

Step 3 - Launch Instruments

Start Instruments from the XCode menu

When the main screen of Instruments is displayed, select "Allocations" as the template.

Step 4 - Selecting your device and game

Once the Instruments panel is loaded, you need to first select your mobile device and then the game your wish to analyse.
Do not have the game running at this time.

Step 5 - Testing

To start testing, press the record button in Instruments. This will automatically launch your game on the device and start collecting statistics.

What to look at

Apart from the mesmerising graph, it is important to keep an eye on the "Persistent Bytes" and "#Persistent" columns.

The "Persistent Bytes" column shows the memory really needed by your game at that given moment.

The "#Persistent" column shows the memory that is actually used, both by necessary data and data that is waiting to be released or swapped out. This is the number that will crash your game if it grows too big in relation to device memory. It is important to note that your game needs to leave a large portion of memory free for other system purposes. Therefore the rule of thumb "only use 50% of available memory".

What you can do

If the "#Persistent" column grows much larger than the "Persistent Bytes" column, then it is an indication that something is not well. It may be due to memory leaks, which is out of our hands.

(pre GS v 0.14)

It may also be that your images are too large, making the swapping out of images from memory problematic, even leading to the game crashing. Memory gets fragmented as images get loaded and unloaded. If there is no room to load needed images, memory needs to be reshuffled, leading to lag in the game.

Thus, avoid large images if you can. Break them into smaller sections and assemble them on the scene. It is easier playing tetris with 1x1 blocks that 16x16 blocks. Both for your device and you.

(post GS v 0.14)

From this version onward, we will not have to worry about the size of individual images any more. The new rendering engine will produce a sprite sheet of all of our images. Each sprite will have 64x64 pixel dimensions.

Instead if the old maxim of keeping image dimensions at factors of two, we now should just try to keep our image dimensions multiples of 64 pixels.

MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects

www.APPFORMATIVE.com

Comments

Sign In or Register to comment.

© Vanilla Keystone Theme 2025