Memory Leak:

A memory leak happens when memory is allocated but never freed. This means the garbage collector is not able to take out the trash once we are done with the takeout. Many a time we see ANR(Application not responding) dialog while using android apps, lags in our apps, we also see OutOfMemoryError in Android Studio while building apps. All these kinds of stuff happen due to memory leaks. Some objects are not even recognized by the garbage collector as garbage.

Effects of Memory leak

1. Lags in our app

2. Application Not Responding(ANR) dialog

3. OutOfMemory error while building your app.

we can detect Memory leaks using the 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) In Android Studio -> Android Monitor window -> Memory section, click on the Initiate GC button. Then click on the Dump Java Heap button.

c) In Android Studio -> Android Monitor window -> Memory section, click on Initiate GC button. Then click on Dump Java Heap button.
d) Android Studio will open the dumped .hprof file. In the hprof file viewer, there are a couple of ways you can check the memory leak. You can use the Analyzer Tasks tool on the top right corner to detect leaked activities automatically. Or you can switch the view mode to Package Tree View from the top left corner, find the activity which should be destroyed. Check the Total Count of the activity object. If there are 1 or more instances, it means there is a leak.

Garbage Collection:-

Memory utilization on the mobile app has a significant impact on customer experience. If your app creates a lot of objects, then the Android run time (ART) environment will trigger garbage collection (GC) frequently. 

Android garbage collection is an automatic process that removes unused objects from memory. However, frequent garbage collection consumes a lot of CPU, and it will also pause the app. Frequent pauses can jank the app (i.e. stuttering, juddering, or halting).

Thus, you need to understand how many objects your app is creating, how frequently garbage collection is triggered, how much time it takes to complete, and how much memory is reclaimed after every event. All this information is present in the runtime log messages. Whenever a GC event runs, a logline is printed in the runtime log messages. You can view those log lines through logcat.

It will look like this:-

07–01 16:00:44.690: I/art(801): Explicit concurrent mark sweep GC freed 65595(3MB) AllocSpace objects, 9(4MB) LOS objects, 34% free, 38MB/58MB, paused 1.195ms total 87.219ms

How Garbage Collector and Memory leaks are related to each other?

Java automatically garbage collects objects to release memory. Garbage collection means that an object which is not reachable via any live reference can be removed from memory. In this way, the user is not concerned about memory allocation and deallocation. However, sometimes this automatic process fails to free enough memory which results in memory leaks. Memory leaks make your application slow and you can also get out of memory exceptions.

There can be many reasons for memory leaks:-

Let’s talk about these in detail:-
1. Using Inner classes — If you are using an inner class, use this as static because the static class does not need the outer class implicit reference. Using inner class as non-static makes the outer class alive so it is better to avoid it.

2. Using anonymous classes

3. Using context — Use the right context at the right place, like use applicationContext only where it’s required, similarly use activityContext only where it’s required.

4. Using static views or context — Never use static views or context in your context because static keyword thing is always visible and can’t be killed.

5. Unregister the broadcast receiver if you are not using it — Consider this scenario — you need to register a local broadcast receiver in your activity. If you don’t unregister the broadcast receiver, then it still holds a reference to the activity, even if you close the activity.

6. When you pass your activity as a listener to a singleton object or an x-manager instance, make sure you understand what the other object does with the activity instance you passed in. Clear the reference (set the listener to null) if necessary on Activity onDestroy.