I have two problems:
1.What is trigger conditions of LOW_MEMORY and OUT_OF_MEMORY in android memory automatic cleaning mechanism?
I check the reference LOW_MEMORY is done automatically every once in a while, and OUT_OF_MEMORY is conducted in system out of memory. Is this right? If it is right, is the recovery of memory strategy the same？
2.What conditions perform memory of the recovery in android task manager？
The detail condition is testing phone memory 512; the user available memory is 230. The visual inspection is 50M. It can trigger the memory recall in 20M. That is to say 50M and 20M are the stable memory. But sometimes it has not the trigger recycle when the memory less than 3M.
Is the trigger recycle need special condition? Where the trigger recycle code should be put?
In android is each application has fixed memory limit.. it change from device to device... for ex if phone memory is 512.. and app memory will be 30 to 50 mb if your app cross using this memory it will get crash...
onLowMemory is the method in the activity.. it notifier when memory is low... it is like warning .. OUT_OF_MEMORY is exception which you cant handle(catch)..
OUT_OF_MEMORY exception max raise normally when we deal with bitmap...
Garbage collector is available in android also but when we deal with bitmaps it may fail in some cases.. for bitmap we are responsible to recycle..
Related
I'd like to know some simple code that allows for freeing used memory that is no longer needed, in a similar way as a lot of memory freeing apps do.
Yes, I'm aware that this shouldn't be neccesary because Android manages memory on its own, but it looks like what's causing a non desired behavior in my app is having a lot of opened app occupying memory, so I think this is worthwhile to try, and check if the error happens any longer.
Could anyone hand me such a code? I'm not able to find any.
What I gather from the article is that you don't need to do anything to reclaim memory, but you can make garbage collection happen quicker and at specific times. What this means to me is that any arrays, Lists, large objects, etc. should be set to null when you are done with it. Granted, this should be done automatically when you leave a method or a View, but in case you are in a long running loop or staying on a page with lots of data hanging around, you can clean it up a little faster.
The Android Runtime (ART) and Dalvik virtual machine use paging and memory-mapping (mmapping) to manage memory. This means that any memory an app modifies—whether by allocating new objects or touching mmapped pages—remains resident in RAM and cannot be paged out. The only way to release memory from an app is to release object references that the app holds, making the memory available to the garbage collector. That is with one exception: any files mmapped in without modification, such as code, can be paged out of RAM if the system wants to use that memory elsewhere.
https://developer.android.com/topic/performance/memory-overview
You can also check your memory usage to see if that's really the problem. This is linked in the article above, but I thought I'd pop it out so it's easier to notice.
https://developer.android.com/reference/android/app/ActivityManager.html#getMemoryClass()
I am planning to hunt any memory leak in my Android App. After searching through different blogs, it seems like MAT is a good tool for that.
Before proceeding further, I just want to make something clear. When I check allocated heap memory in memory monitor tab of android studio, i can see the allocated memory increases by ~1 MB (from 16MB of initial allocation) each time I rotate my device. This, most probably suggests some leaks.
However in the process, at any stage, whenever I click on Garbage Collection button in memory minitor window to force GC, the allocated memory comes down to near the initial stage 16MB+ (sometimes requires 2 back to back click when allocated memory expands beyond 30 MB).
My question is, does this behavior suggests that I don't have any leaks due to strong references? If GC can collect those extra chunks, how important is that to check the issue?
I have some memory problems about my android appwiget,
(It's small toy appwidget based drawable animation repeat)
So I watched my memory viewer in Android Studio.
I found my app's memory increased at initial time, but when it doesn't enough memory it automatically release some memory.
I want to know what android function make this.
Can I control this release function with java code?
*I tested at real device android ver 4.42
You are talking about Garbage Collection, which is the process of removing from the memory the objects that are no longer required. You can have a good idea of how it works in Java here.
In Android (and Java in general) you can suggest the virtual machine to do it with the System.gc() call. Note, though, that it:
Indicates to the VM that it would be a good time to run the garbage collector. Note that this is a hint only. There is no guarantee that the garbage collector will actually be run.
What is the difference between the heap usage (Allocated) we can see in the Elipse Memory Analysis Tool (in the DDMS view) and the memory usage size for the same App shown here on the Android device?:
Settings->Apps->Running
Even though I aggressively tried to preserve memory by making objects null as soon as they weren't needed, the latter number (memory usage size on Running apps screen) only kept increasing and my app finally crashed due to OutOfMemoryError. However, the former showed me that I was well within a reasonable size. I was also calling System.gc() a lot. Is there a difference between the two? Why the discrepancy? Any ideas on how I can solve this problem?
The biggest difference between the two that I know of is the scope of garbage collection.
Normal garbage collection, including System.gc(), collects a bit of garbage, then stops. It is not a complete sweep of the heap to get rid of everything. That is to try to minimize the CPU impact of garbage collection.
The heap dump prepared for MAT, though, effectively a complete GC.
Your symptoms suggest that you are allocating memory faster than GC can reclaim it. The primary solution for this is to try to allocate less memory, or allocate it less frequently. For example, where possible, reuse objects, bitmap buffers, and the like, instead of trying to let GC clean the old stuff and allocating new stuff as you go.
It sounds like you have a memory leak somewhere in your application if the memory is never released. This means that somewhere you are maintaining a strong reference to a large object which is being recreated (like an Activity or Bitmap) which is why calling System.gc() is making no difference.
I suggest watching the following on memory management in android from google IO 2011. It lets you know how to use the eclipse memory analyser tool which is incredibly useful for debugging this sort of error
my android application works well but it's performance(speed) is slow. In my logcat i saw frequent garbage collection operation like
11-02 15:07:20.647: DEBUG/dalvikvm(12571): GC freed 295 objects / 38448 bytes in 93ms
Is this the reason for low performance?? How can i improve my applications performance???
anybody please help
If you use the emulator don't worry - it is slow by itself. GC is not responcible for this i think, 93 ms is time you won't even notice. So try your application at the real phone and if there are preformance issues - use the profiler.
Your application performance in terms of user interface and memory is quite related.
In this case 93ms means that your device could be dropping about 6 frames in the ideal scenario. If the GC is executed often this could be a problem.
The Android ART/Dalvik virtual machine is a version of the Java Virtual Machine where the Garbage Collector implementation is based on generations. This means that your application process has a heap associated separated by different generations where the GC is going to act once a generation is full. You can think of these generations as buckets or arrays of memory.
Once a generation is full the Android virtual machine will start the garbage collector process. As the Android virtual machine can not collect and fragment your application heap while the app process is running the garbage collector event will stop all the threads in your app while the garbage collector is working. That's why your application can be dropping frames if the app garbage collector is invoked so repeatedly.
Here you have an example:
Last week I discovered my app was leaking memory. I discovered this because after 20 minutes using my app I noticed the UI was performing really slow. Closing/opening an activity or scrolling a RecyclerView was really slow. After monitoring some of my users in production using http://flowup.io/ I found this:
The frame time was really really high and the frames per second really really low. You can see that some frames needed about 2 seconds to render :S.
Trying to figure it out what was causing this bad frame time/fps I discovered I had a memory issue as you can see here:
Even when the average memory consumption was close to the 15MB at the same time the app was dropping frames.
That's how I discovered the UI issue. I had a memory leak in my app causing a lot of garbage collector events and that's was causing the bad UI performance because the Android VM had to stop my app to collect memory every single frame.
Looking at the code I had a leak inside a custom view because I was not unregistering a listener registered into a Android Choreographer instance. After releasing the fix, everything became normal :)
If your app is dropping frames due to a memory issue you should review two common errors:
Review if your app is allocating objects inside a method invoked multiple times per second. An example could be creating new instances of an object inside a onDraw custom view method.
Review if your app is registering an instance into the Android SDK but not releasing it. Registering a listener into a bus event could also be possible leak.
Disclaimer: The tool I've been using to monitor my app is under development. I have access to this tool because I'm one of the developers :) If you want access to this tool we will release a beta version soon! You can join in our web site: http://flowup.io/.
If you want to use different tools you can use: traveview, dmtracedump, systrace or the Andorid performance monitor integrated into Android Studio. But remember that this tools will monitor your connected device and not the rest of your user devices or Android OS installations.