Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to listen to GC events in Android

Is there anyway we can monitor GC events as they happens in Android?

In Java, I believe we can listen to the events http://www.fasterj.com/articles/gcnotifs.shtml But java.lang.management APIs are not available in Android.

like image 577
Prakash Avatar asked Oct 29 '14 17:10

Prakash


People also ask

How does garbage collection works in Android?

Garbage collection A managed memory environment, like the ART or Dalvik virtual machine, keeps track of each memory allocation. Once it determines that a piece of memory is no longer being used by the program, it frees it back to the heap, without any intervention from the programmer.

When garbage collector runs in Android?

An object is indirectly accessible if it's referenced by a field in another (directly or indirectly) accessible object. An accessible object is claimed to be live. Conversely, an object which isn't live is garbage. To explain the mark-and-sweep algorithm, there are two phases, we need to understand both of those first.

How to do garbage collection Android Studio?

a) First, build your program and run it on your device. b) Open that activity which you want to test whether it's leaking your activity or not. c) In Android Studio -> Android Monitor window -> Memory section, click on Initiate GC button. Then click on Dump Java Heap button.

Can you manually call the garbage collector Android?

Generally speaking, in the presence of a garbage collector, it is never good practice to manually call the GC. A GC is organized around heuristic algorithms which work best when left to their own devices. Calling the GC manually often decreases performance.


2 Answers

Why you want this listener. If you simply want to know if your app is running out of memory just check this:

Release memory as memory becomes tight

During any stage of your app's lifecycle, the onTrimMemory() callback also tells you when the overall device memory is getting low. You should respond by further releasing resources based on the following memory levels delivered by onTrimMemory():

  • TRIM_MEMORY_RUNNING_MODERATE Your app is running and not considered killable, but the device is running low on memory and the system is actively killing processes in the LRU cache.
  • TRIM_MEMORY_RUNNING_LOW Your app is running and not considered killable, but the device is running much lower on memory so you should release unused resources to improve system performance (which directly impacts your app's performance).
  • TRIM_MEMORY_RUNNING_CRITICAL Your app is still running, but the system has already killed most of the processes in the LRU cache, so you should release all non-critical resources now. If the system cannot reclaim sufficient amounts of RAM, it will clear all of the LRU cache and begin killing processes that the system prefers to keep alive, such as those hosting a running service. Also, when your app process is currently cached, you may receive one of the following levels from onTrimMemory():

  • TRIM_MEMORY_BACKGROUND The system is running low on memory and your process is near the beginning of the LRU list. Although your app process is not at a high risk of being killed, the system may already be killing processes in the LRU cache. You should release resources that are easy to recover so your process will remain in the list and resume quickly when the user returns to your app.

  • TRIM_MEMORY_MODERATE The system is running low on memory and your process is near the middle of the LRU list. If the system becomes further constrained for memory, there's a chance your process will be killed.
  • TRIM_MEMORY_COMPLETE The system is running low on memory and your process is one of the first to be killed if the system does not recover memory now. You should release everything that's not critical to resuming your app state. Because the onTrimMemory() callback was added in API level 14, you can use the onLowMemory() callback as a fallback for older versions, which is roughly equivalent to the TRIM_MEMORY_COMPLETE event.

Here is the reference link https://developer.android.com/training/articles/memory.html

like image 104
Suhail Mehta Avatar answered Sep 29 '22 02:09

Suhail Mehta


Okay, it will be different for both dalvik and art..

basically you can instruct adb shell to record the GC events in a trace file..

art: https://source.android.com/devices/tech/dalvik/gc-debug.html

It might even be the same adb commands for both art and dalvik.

The memory monitor tool plugs into this when it displays that graphical chart of memory for you in android studio.

Progammatically, probably is harder..look at how FB did their performance tooling as I believe that they are doing the GC event counts from the native C/C++ side and collating them in a flatbuffer for their java side profiling tool code to access..

like image 34
Fred Grott Avatar answered Sep 29 '22 03:09

Fred Grott