Hi,

I've been trying to put together a surfaceview 2d game, however I've got to a point where it OutOfMemories VM etc when I'm adding new sprites. My sprites (some static, some anim strips) are held in separate pngs in the res folders.

Some of the posts around the subject suggest that loading numerous small images chomps through memory at a rate of knots. My entire folder of sprites comes to 1.5Mb over 90+ images.

I've had the idea to load all the images in on one big png spritemap and just us rects to handle all the drawing. Ironically, although the combined spritemap file is larger than the sum of all the smaller files, it loads in fine.

My thoughts were to use an unscaled spritemap then derive scaling from a calculation based on canvas size and adjust destination rect accordingly.

Does this have any chance of working? Is it extremely bad practice or am I approaching it from a completely wrong direction.

Any help would be most appreciated.

Regards,


Kinnerton

Perhaps profile your app first to learn where the actual problems are occurring. You can do this by using the ddms tool and hitting the 2nd button from the left to dump an hprof file or use the Debug static methods to programmaticly dump an hprof file. Then use the hprof-conv tool:
http://developer.android.com/guide/deve ... -conv.html

Load two comparison (before and after) init or major resource allocations and then perhaps a 3rd or 4th snapshot during runtime and evaluate where your problems are. Until you do this you are grasping at straws so to speak and only working with assumptions which can easily turn out to be wrong. You may be doing something inefficiently elsewhere, etc.

I use YourKit for my Java profiler. For a free one I've read that MAT is good too, but I've not used it:
http://www.eclipse.org/mat/

So I definitely advise you get a real picture of what is going on before optimizing the wrong part of your app.

MichaelEGR wrote:Perhaps profile your app first to learn where the actual problems are occurring. You can do this by using the ddms tool and hitting the 2nd button from the left to dump an hprof file or use the Debug static methods to programmaticly dump an hprof file. Then use the hprof-conv tool:
http://developer.android.com/guide/deve ... -conv.html

Load two comparison (before and after) init or major resource allocations and then perhaps a 3rd or 4th snapshot during runtime and evaluate where your problems are. Until you do this you are grasping at straws so to speak and only working with assumptions which can easily turn out to be wrong. You may be doing something inefficiently elsewhere, etc.

I use YourKit for my Java profiler. For a free one I've read that MAT is good too, but I've not used it:
http://www.eclipse.org/mat/

So I definitely advise you get a real picture of what is going on before optimizing the wrong part of your app.

Thanks Michael,

I'll definitely check out those links.

I take it hprof and logcat results are different.

I'm new to both Java and Android - so am soaking up as much good-practice as I can find!

I had come across MAT before - but it looked like it was more for non-android Java apps. I'll have another look.

Looking around a bit further it looks like I've been loading in the bigger background images expensively with alpha - but as you say, this may simply be a red herring.

Time to roll my sleeves up!

Cheers,

Kinnerton

I take it hprof and logcat results are different.
I'm new to both Java and Android - so am soaking up as much good-practice as I can find!
I had come across MAT before - but it looked like it was more for non-android Java apps. I'll have another look.

Welcome to Android & Java dev!

Yeah.. The hprof is a profile of the heap and CPU status of the virtual machine whereas logcat is just the debug / text output from the app. The hprof dumped from Android is Dalvik specific, but the hprof-conv tool will convert it to a standard Java format which can be opened by profilers that work with the J2SE / JVM. So you can use pretty much any Java profiler to open them and debug like you would for the desktop / J2SE. It's a little annoying because it's a rather offline process. I don't use Eclipse, so I don't know if there is better integration there with the SDK integration Android plugin.

If you dump hprofs from ddms you need to set you app as debuggable in the AndroidManifest.xml file and also add this permission:
<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />

That is because ddms temporarily writes the hprof file to external storage before copying it over to your dev box.

In most profilers you can compare two hprof snapshots and view retained and new memory allocations between the snapshots, but remember to run hprof-conv on each file first. This is very handy to find allocation points and memory leaks. Until you do this it's like trying to find a needle in a hay stack and just blind guessing on things to change in your code.

Time to roll my sleeves up!

Indeed. Once you have a better view on what your app is doing and get the profiler snapshot comparisons working it very well could provide the aha moment. It's not particularly a smooth / easy process with Android, but I've been able to drill down just like a J2SE / normal Java app in a profiler and find / fix tough problems that are not so visible just looking at the code. It's also rather handy in debugging the Activity lifecycle and making sure data is not retained and thus Activities orphaned, but taking up space for the app that is still running. One of the bigger Java faux pauxs is the dangling listener. Not saying that is your problem, but this kind of thing is easily visible when comparing hprof snapshots.