I am trying to understand the benefits of memory consumption by an android application. One direct affect of consuming more memory is that the app crashes more often with OutOfMemoryError. But if my app rarely fails with OutOfMemoryError, is there a benefit in spending time on trying to reduce the memory consumption further ?
Avoiding leaks is not as easy as it seems. For example when user changes a configuration resulting the activity to get recreated, your memory consumption becomes almost 2 times due to the leaking activity if of course you have leaks.
The reason you should keep the ram usage as low as you can is about the free part of heap you can get which of course will reduce battery consumption and you can perform tasks on a larger scale. Lets assume you need to crop an image that user requested; this will usually get done by splitting the job into separate chunks and do it in a background thread while showing user a progress. In this example you can bite a larger size of the ram per each chunk and get the job done faster resulting in a happier end-user.
There are plenty other reasons as so to keep your ram usage at a lower level often ends up with more satisfied users.
Related
I'm sorry for asking this duplicate question. But as you can see in that link the topic is saying one thing but the content is about something else.
I'm not asking how to manage or how to monitor the memory, just want to know how much memory usage you call a memory friendly app. And from what range you consider as using too much memory.
Thank you
Short Answer: As low as possible.
Long Answer: To allow multiple running processes, Android sets a hard limit on the heap size alloted for each app. The exact heap size limit varies between devices based on how much RAM the device has available overall. If your app has reached the heap capacity and tries to allocate more memory, the system throws an OutOfMemoryError, and to avoid running out of memory, you can to query the system to determine how much heap space you have available on the current device.
You can query the system for this figure by calling getMemoryInfo(), which provides information about the device's current memory status, including available memory, total memory, and the memory threshold—the memory level at which the system begins to kill processes.
For more details, see this
https://developer.android.com/topic/performance/memory
I was investigating the memory consumption of my android app. Immediately after app startup, I clicked 'Dump Java Heap' and the first class on the list is FinalizerReference (java.lang.ref). It has over 800 instances and consume more than 70% of the total memory comsumption.
I understand it is for garbage collection. Unlikely it is because of memory leak since it was captured right after app startup without switching to another view. I did not do any heavy processing during startup, apart from reading something from the shared preference.
Possible Memory leak through FinalizerReference
From this post, I tried to look on the referent field of the FinalizerReference, but it appears to be something that beyond my understanding e.g. Matrix, Canvas, Render Node. It sounds like UI components for me.
Here is my question:
Is there any way/tool for me to further debug the root cause of memory comsumption.
Is this something that I need to worry, or it is just the normal behavior of android memory management.
A better tool would be useful, but only because it should show that the reported Retained Size of ~33 MB for FinalizerReference is not real memory consumption, just massive multiple counting of the same small amount of memory by the Memory Profiler. The Shallow Size of ~28 kB is important, but negligible. The way I investigated this (using Memory Profiler) is detailed in my answer to my own similar question.
You should not worry about FinalizerReference, at least not based on what you show here. You may need to worry about Memory Profiler, due to the meaningless Retained Size it reports for this class. I regard its calculation as a bug, and I filed this issue.
As I researched, Android allocates limit memory for each process, maybe range from 16MB to 24MB for each one. Here is reference
Nevertheless when I view memory usage for one application in setting, I often see one normal application costs hundred megabytes for memory (on one process). There is a conflict here that I cannot understand.
Thanks :)
NDK code can use more system RAM than can a single Dalvik/ART process. Also, the app might be using more than one process, or it might be using android:largeHeap to request an above-normal heap size.
Sometimes we encounter the memory issues,such as the OOM problems.And We inevitably have to manage the memory.Android has set a limit to the memory used bye each app.The maximum limit probably is the 32Min the early versions of android,such as 1.5,1.6,2.1.
Android of v4.0 has exceeded this limit.We can set android:largeHeap to "true" in the AndroidManifest,so the app could increase the memory limit.
I'm develeping the wallpaper app.The app can show many pictures in high definition.But the memory used by the app always reach the limit of more than 60M in the android of 720p, about 100M in the android of 1080p.
The overuse of memory is unacceptable for me.And I'm looking for the means to resolve it all the time.
My friends,How much memory your app will take up when you develop your app during debugging or running?Is there a memory-manage mechanism in the code?Look forward to your reply.
The amount of memory used by bitmaps is based on what's in the bitmap, not the size of the file. There's a few things you can do to reduce the footprint of the bitmap being loaded in to memory, which, in turn will reduce the amount of memory your app is using.
There's a great talk here from Google I/O for memory management that will help and another that will help you check to see if you have any memory leaks as well.
Also, note that if you use Bitmap.Config.RGB_565 you can half the amount of memory that the Bitmap is using (each pixel value is stored in 2 bytes instead of 4)
I'm not sure what the memory limitations on Android applications are exactly, but let's say I run a query against SQLite and the result set is very large; too large to fit in whatever memory is allocated for my application. Will the application crash? I wonder if there's some trickiness that goes on in the Cursor class, with it maybe not retrieving all results at once? I don't really understand how Cursor works underneath.
Side effects of large memory consumption.
It may give OutOfMemoryError while reading data.
Because of too large memory consumption, it will increase CPU usage because of which battery will start draining out and if it goes beyond some limit (which I don't know) then Android system may kill your process or your application also might get crashed.