3

I have a pretty simple game that is out on the Market right now. It is a simple text-based game, no 2d or 3d graphics involved. It uses properly-sized pngs for backgrounds. Other than that, it is purely text based.

There is nothing cpu or graphic intensive about the game, but it averages about 25mb of memory usage. In comparison, most apps that are even more cpu intensive average about 18mb.

In mobile applications, every megabyte counts, so what can I do to properly reduce memory usage in my app? I know this may be a vague question, but I will be glad to elaborate if at all needed.

Thank you

Bert B.
  • 579
  • 2
  • 12
  • 26
  • Would probably need to see some code for this. – Mike D Aug 18 '11 at 19:50
  • The basis of the game is that you press a button and new text appears on the screen. The button calls a method that grabs text from a text file and displays it. There isn't much to it, which is why the usage of 25mb of memory is confusing to me. – Bert B. Aug 18 '11 at 19:53

4 Answers4

12

All components of the same application run in the same process and thread. The memory usage of service may be as big as the usage of whole application.

Try to run service in a separate process will fix this problem.

add android:process=":yourname" into AndroidManifest.xml like below:

<service android:name=".MyService" android:process=":yourname"> </service>

In my case, the memory usage of a simple service changes from 12MB to 3MB.

ishitcno1
  • 713
  • 9
  • 10
1

The first thing you should do is grab a memory dump from your app when the memory usage is high and use Eclipse Memory Analyzer to work out what is actually consuming the memory.

EDIT: These links may be helpful:

Android ==> Memory Analysing ==> Eclipse memory analyzer?

http://www.vogella.de/articles/EclipseMemoryAnalyser/article.html

Community
  • 1
  • 1
Ian Newson
  • 7,679
  • 2
  • 47
  • 80
  • I will try this out. I have never used this before, let alone in an Android environment. – Bert B. Aug 18 '11 at 20:04
  • So I got a heap dump. I am just not sure what is considered "normal" for suspected memory leaks. My first suspected one says: 2,367 instances of "java.lang.Class", loaded by "" occupy 890,944 (35.89%) bytes. And the second one says "7,774 instances of "java.lang.String", loaded by "" occupy 488,864 (19.69%) bytes." – Bert B. Aug 18 '11 at 20:46
0

To reduce memory you could possible have some of the graphics downloaded from a application server. Maybe some text documents, or png files you are using. You could actually have majority of your resources installed after the application is installed from a application server such Amazon s3

EDIT:

If you are using String buffer, think it might be to do with a performance optimisation of the StringBuffer toString() method.

The Sun javadoc says the following:

This method can be coded so as to create a new String object without allocating new memory to hold a copy of the character sequence. Instead, the string can share the memory used by the string buffer. Any subsequent operation that alters the content or capacity of the string buffer must then make a copy of the internal buffer at that time. This strategy is effective for reducing the amount of memory allocated by a string concatenation operation when it is implemented using a string buffer.

Because you maybe re-using the StringBuffer with the setLength(0) it might be keeping a reference to all the Strings it's created with toString().

Replace:

.setLength(0);

with:

"Your String buffer" = new StringBuffer();

and see if that resolves it. I don't think this will be any more overhead since in both cases you'll need to create a new char[] array, since in the first case the array is being used by the String created with toString().

Also, you should consider using a StringBuilder as they are preferred to StringBuffer.

Check here

yoshi24
  • 3,147
  • 8
  • 45
  • 62
  • So downloading the background files from a website would actually use less memory than just having them packaged in the .apk? It really only uses about 3 different background images ranging from 180KB to 350KB each. And that's for HDPI screens. – Bert B. Aug 18 '11 at 19:55
  • Hmmm....Are you using any cache for the app, or any type of temporary or long term storage? Such as SQLite? – yoshi24 Aug 18 '11 at 19:57
  • No cache or SQLite. However, you bring up a good point. In order to retrieve the lines of text from the text file, I use an instance of BufferedReader and InputStream. Would those use a considerable amount of memory? – Bert B. Aug 18 '11 at 20:02
  • Yes, Refer to my edit. I dont know if everything i stated is the case with your app. Since i cant see any code. But refer to the link in the bottom of my edit. And also read the Quote from the Java doc – yoshi24 Aug 18 '11 at 20:06
  • It may be that every time you use toString() for the StringBuffer, The application may be holding in memory the reference to that string. – yoshi24 Aug 18 '11 at 20:07
  • I am almost certain it have something to do with your StringBuffer() and toString()'s – yoshi24 Aug 18 '11 at 20:17
0

If the content of your images includes any repeating sections you could split them in to several images and use them as tiles.

Nine patches could be used to do this easily, assuming your images adhere to the nine patch format.

Ian Newson
  • 7,679
  • 2
  • 47
  • 80
  • I have thought about changing my background into a 9patch format, but the current layout and design I have is not very repetitive unfortunately. – Bert B. Aug 18 '11 at 19:56