The bug is reported by someone else, I have no idea the steps, but got the meminfo dumped, and the hprof file.
It seems the Graphics taking about 1G bytes.... From the android doc, it says Graphics is
Memory used for graphics buffer queues to display pixels to the
screen, including GL surfaces, GL textures, and so on. (Note that this
is memory shared with the CPU, not dedicated GPU memory.)
So how app caused taking so much graphics buffer, does because app have hold some bitmaps I dont know?
The memory leak shown by the hprof file is much less than 1G bytes.
Any clues about the Graphics high memory comsumption?
Related
I want to allocate 4.5GB to my openCL program in android phone wiht 8GB memory.
But I found the memory size from CL_DEVICE_GLOBAL_MEM_SIZE is much lower than the device memory size.
There is only 3.63GB in a phone with 8GB memory ,and there is only 1.3GB in a phone with 3GB memory.
Is there any way to break the limit?
You might want to consider the use of zero copy buffers. Map buffers without copy overhead and un-map buffers that are not in use. This way you are still limited to CL_DEVICE_GLOBAL_MEM_SIZE bytes of memory but unused buffers won’t take up space.
Arm has an OpenCL extension which allows direct memory import into OpenCL: https://www.khronos.org/registry/OpenCL/extensions/arm/cl_arm_import_memory.txt
When I used Android profiler I noticed that graphics were Taking a lot of memory (169 mb) which was making the app extremely slow , and I though that it was caused by Bitmaps so I deleted all the bitmaps in the app and tried again..
and I noticed that graphics were still taking up 60 - 100 mb of RAM , and I would like to know what can cause Memory Drain other than Bitmaps?
(My App uses google Maps if that helps)
Graphics: Memory used for graphics buffer queues to display pixels to the screen, including GL surfaces, GL textures, and so on. (Note that this is memory shared with the CPU, not dedicated GPU memory.)
https://developer.android.com/studio/profile/memory-profiler.html
I've developed a game with libgdx. I've tried to keep memory consumption as low as possible by doing the following:
Use Pooling where possible.
Limit SpriteBatch's size
When I run the game on my phone (Nexus 5x) from Android Studio, my game runs smoothly and it seems that memory consumption is indeed reasonable: The memory consumption is usually under 23MB (I see this via the memory monitor). However, when I go to the memory tab on my phone (Settings --> Memory --> Memory used by apps) I see the following:
A shocking "Maximum memory use" of 1.2 GB for my game. Way above any other app.
My question(s):
What does this number mean? Does this mean that at one point my game took up 1.2 GB of the RAM?
How can that be if the memory monitor never showed a consumption of over 25MB?
Seeing that the game does run smoothly should I try to get this number down? If yes, how can I do this?
You're mixing up native memory (RAM, as shown on the screenshot) and VM memory.
In the memory monitor, you only see the heap (so the memory that was allocated for the VM on which your app is running), but not the actual RAM. This maximum heap size is limited by the system (see e.g. https://stackoverflow.com/a/9940415/1096567 for examples).
Libgdx is using OpenGL via a JNI and is therefore also using the RAM directly.
To investigate your RAM usage in general you need other tools than the Memory Monitor, see e.g.:
How do I discover memory usage of my application in Android?
I don't know your app, but 1.2GB seems a bit high. If you're not using Texture Atlases & the Texture Packer, it's probably a good place to start optimizing. Also be sure to dispose all Disposables (like BitmapFont). Here is a detailed list.
I'm working on an Android app using Open GL ES 2.0. I'm confused about memory management in Open GL.
My questions are:
How much memory is available to the Open GL hardware? Clearly it's going to vary from device to device.
How can I find out how much memory is in use and how
much is left?
What happens if I exceed the memory limits?
What techniques should I be using to unload data not currently being displayed?
I presume I'm going to have to implement some kind of system to unload textures that are not currently in use on an LRU basis, but I'd like some idea of what criteria to use for this.
The app silently dies at some point and I suspect it is because I'm using too much graphics memory.
Currently I'm never unloading textures and I seem to be able to load quite a few - testing on a Nexus 7 I have been able to load 134 1024x1024 RGBA textures, which I calculate to be over 500MB. I presume once the textures have been loaded into graphics memory they take up less space, but that's still a lot, and clearly I have to manage that but I'd like some tips on how to start.
Simply use gles glDeleteTextures
If you run out of memory you will gen GL_OUT_OF_MEMORY error probably. Another thing is to monitor memory usage in Android.
android memory: How do I discover memory usage of my application in Android?
See here an interesting question for opengl: how to manage memory with texture in opengl?
I noticed that on my Galaxy Nexus that android.content.res.Resources is allocating about 11MB. I discovered this as I was in the process of profiling things using DDMS and the "Dump HPROF file" option. So, I spent two hours trying to see if the allocation was due to something in my code or supporting libraries. I removed all my data, a ton of classes, all my libraries, and saw no change. After placing a breakpoint in my code at the beginning of the onCreate() method of the activity, it showed that the 11MB allocation is already present.
After being thoroughly confused, I decided to connect my rooted Nook Color running CM7 to see what it was reporting for initial memory usage for the exact same application. The worst case memory "Problem Suspect" reported by the MAT weighs in at a mere 896KB.
Is ICS that top-heavy? Am I missing something here? As far as I can tell, my application is functioning correctly, but having the heap usage indicate 97% full has me worried about potential failures.
If it helps, MAT was indicating that the primary objects consuming all the memory were Bitmaps, BitmapDrawables, and NinePatchDrawables. I don't understand where these allocations are coming from.
Pre-Honeycomb (<3.0), Bitmaps were allocated in native heap and did not appear in Dalvik heap dumps as shown by Eclipse MAT, etc. This native allocation still contributed towards maximum Dalvik heap limits for an application, and still caused garbage collection to run at approximately the correct time when approaching a low memory situation. This usage can be measured with Debug.getNativeHeapAllocatedSize().
Since Android 3.0 (including ICS), it now allocates the pixel data for Bitmaps in normal byte arrays in Dalvik heap. The practical effects of this are better/simplified garbage collection behaviour for Bitmaps (since they can be treated in a more orthodox way) and the ability to track Bitmap allocations in Dalvik heap dumps.
I do not think the actual memory usage for a particular application is significantly different between pre-Honeycomb and more recent releases, and that this is just a matter of an alternative accounting practice.
Memory Analysis for Android
BitMaps in Android