Memory Management

  ... discussions about development with the GLES2 branch of AndEngine.

Re: Memory Management

Postby e.r. » Sat Jun 15, 2013 1:26 am

Going back to the main subject, although the following might be a bit of a high level research but it is worth sharing the results:

RealMayo wrote:So to be clear, that new statistic represents the maximum heap size that the device can handle? And are heap size limitations related to a combination of available ram and available hard drive space for the purpose of establishing virtual memory?


Yes, The heap size is set by the manufacturer, the low end devices has a low heap size that cannot handle loading large texture. The heap is allocated per app and the AE app gets its own. So Independently from the RAM or the available space, a device with low heap cannot handle large texture atlas.

Test: My two low end device and HTC CHACHA (480X320 and 512RAM , 20 Mbytes heap size) and a GIO (480X320 and 278RAM and 64 Mbytes heap size), the GIO manages to run my new game while as the CHACHA with higher RAM capacity fails to pass the loading resources. (Loading HD textures to stress test it)
I reproduce the start crash in the emulator (512RAM and 480X320) by simply starting with a heap size of 64 and decreasing the value, on 32 Mbytes the app failed to start.

So mainly, I can be 90% sure that the heap size is a valid metric, the 10% of uncertainty is left because the GIO has an adreno GPU , but the emulator also failed to start on my laptop's GPU
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby RealMayo » Sat Jun 15, 2013 5:48 am

Thanks for getting us back on topic :D
Good research! Keep the information coming!
And if you ever figure out how to properly unload font/text, then definitely let everybody know ;) :)
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby Ungaze » Sat Jun 15, 2013 8:07 am

Yep nice find.

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
  2. int memoryClass = am.getMemoryClass();
  3. Log.d("potato", "memoryClass:" + Integer.toString(memoryClass));
  4.  
Parsed in 0.011 seconds, using GeSHi 1.0.8.4


So this piece of code is probably a must if you want to filter out crappy phones(running it before loading resources). And it would be more concrete if someone could test it on devices with different heap sizes but same(almost) GPU.
User avatar
Ungaze
 
Posts: 409
Joined: Fri Jul 06, 2012 10:53 am

Re: Memory Management

Postby e.r. » Sat Jun 15, 2013 8:38 am

TypeFace Memory leak solution was actually mentioned in the link I posted, and all the other solutions that I found are all based on static classes and HashTable (Of course this is in case the app contains multiple activity, in case of a single activity just create a single instance and use it all over), the thing is that the class is static and the forum is filled with posts that do not recommend the use of Statics especially with textures, dunno in the case of typface. Here it is:

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. package com.epollomes.BalloonsFlee;
  2.  
  3. import java.util.Hashtable;
  4.  
  5. import android.content.Context;
  6. import android.graphics.Typeface;
  7. import android.util.Log;
  8.  
  9. public class Typefaces {
  10.  
  11.         private static final String TAG = "Typefaces";
  12.  
  13.         private static final Hashtable<String, Typeface> cache = new Hashtable<String, Typeface>();
  14.  
  15.         public static Typeface get(Context c, String assetPath) {
  16.                 synchronized (cache) {
  17.                         if (!cache.containsKey(assetPath)) {
  18.                                 try {
  19.                                         Typeface t = Typeface.createFromAsset(c.getAssets(), assetPath);
  20.                                         cache.put(assetPath, t);
  21.                                 } catch (Exception e) {
  22.                                         Log.e(TAG, "Could not get typeface '" + assetPath + "' because " + e.getMessage());
  23.                                         return null;
  24.                                 }
  25.                         }
  26.                         return cache.get(assetPath);
  27.                 }
  28.         }
  29.  
  30. }
  31.  
  32.  
Parsed in 0.012 seconds, using GeSHi 1.0.8.4


I tested it as much as I could and took the risk and put it into production. So far no decrease in the review or any new support email . If any Java expert can diagnose it and explain if the static here is good or not...
What I noticed is that when you monitor the memory when doing this, is that the typefaces ( I have three in Balloon Flee ), are created in each activity as needed, but then they are reused, somehow if you stay on one activity that does not use the other typeface, the typeface is removed after a while ( I thing after GC call ) but then when you go back to that activity, the typeface is recreated and inserted in the hash table, but all the time there is one typeface for each font which is good.

I still have leaks somewhere, but I decided not to invest anymore time as the leaks are reduced a lot.

My personal lesson learned is that single activity multiple scenes is the best approach, even if you want to free memory on your own, but you can then go total control freak over it ;)
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby Mathew » Sat Jun 15, 2013 10:56 am

What way do you use to determinate heap size of your application and currently allocated heap size? Well I am asking because I am now bit confused, that some member`s games heap size is so large in compare to mine (I should be happy, but I am not sure now if my information is correct now) Because, in my quite big game my heap size is kept on 19.883 MB and allocated jumps between 12-14 MB while jumping between certain parts of the game.

Are you using that much textures in your games? Well for my current game I tend to use around 2-4 atlases with max size of 1024x1024 with top quality texture settings that`s why I am wondering how comes when I see 50-90 MB heap size.

I am using android built in heap analyser, so eighter I should be happy that my memory usage is relatively wrong or afraid that those details are not properly analysed?

Image
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby e.r. » Sat Jun 15, 2013 5:27 pm

@Mathew
The values that I was reading when I first started the (With basically 0 knowledge, basically new to java/android ) memory profiling research thing was the total size of the heap ( Native + Dalvik ), And i mentioned that in my PS previously.
What you see in eclipse console is the Dalvik heap size only. And yeah most games have heap max allocated below 20 MBytes, So you are safe.

I use the following command "adb shell dumpsys meminfo package.name" on the command prompt, it gives all the info related to memory allocation, basically using the eclipse DDMS profiler I would have never found the typeface leak ! since it was detected by the number of lines the typeface is mentioned in the bottom. The thing is that it spits a lot of info that is really complicated related to linux kernel/ shared memory/ . . .others beyond my understanding.

This article is really usefull http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android/2299813#2299813, but better read it after a good sleep time, a a good cup of coffee.

Let me know if something still not clear, so that we can fix the info in the thread
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby Mathew » Sat Jun 15, 2013 5:52 pm

Thanks e.r, I will have deeper look to make sure I am fine. And yes I am not only reeling on DDMS profiler, MAT is just a need.

Indeed, that`s command is really useful, already spotted one, fortunately little leak, plus sum of dalvik and native heap is around 25MB but still need to stress test it a lot.
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby e.r. » Sat Jun 15, 2013 9:02 pm

Anyone knows if we can create like a table on the forum where each one can fill a line in it? I am thinking of something like:

Column A : Devices Type - Manufacturer
Column B : Resolution
Column C : HEAP - Via the above formula

This would be epic-ally useful, especially that it is impossible for indies to own more than a couple of devices. So every member can contribute the values of their exclusive device... a quick search I couldn't find such a list. What do you think?
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby Mathew » Sat Jun 15, 2013 9:36 pm

Indeed would be great, maybe even expand it with more informations, but I am almost sure its not currently possible with this forum, it would probably need third party plugin, or we might create little website (or ask nicolas to upload it on andengine subdomain) to do it.
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby RealMayo » Sat Jun 15, 2013 9:55 pm

I know of a website that could host something like that...
http://www.matim-dev.com/
;) :P
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

PreviousNext

Return to GLES2

Who is online

Users browsing this forum: No registered users and 99 guests