OutOfMemory Error

OutOfMemoryError is the error which we get all the time. Whenever we get this error we generally think that our bitmap is too large. But the real reason behind this error is because of Memory Leak.

To make sure each app in Android has enough memory, Android system needs to manage memory allocation efficiently. Android runtime triggers Garbage Collection (GC) when memory runs short. The purpose of GC is to reclaim memory by cleaning up objects that are no longer useful. It achieves it in three steps.

• Traverses all object references in memory from GC roots and marks active objects which have references from GC roots.
• All objects which are not marked (garbages) are wiped from memory.
• Rearrange live objects

Whenever unused objects are referenced somehow from reachable objects, GC would mark unused objects as a useful object and therefore would not be able to remove them. This is called a memory leak.

Is Memory Leak Bad?

Let's see the disadvantages of the memory leak:

1. If objects are staying longer than they should, they will occupy valuable resources. Less usable memory would be available when memory leak happens. As a result, Android system will trigger more frequent GC events. GC events are stop-the-world events. It means when GC happens, the rendering of UI and processing of events will stop. Android has a 16ms drawing window. When GC takes long than that, Android starts loosing frames. unused objects are referenced somehow from reachable objects, GC would mark unused objects as a useful object and therefore would not be able to remove them. This is called a memory leak.

2. When your app has memory leaks, it cannot claim memory from unused objects. As a result, it will ask Android system for more memory. But there is a limit. The system will eventually refuse to allocate more memory for your app. When this happens, app user will get an out-of-memory crash.

Now let's find out a way to identify a leak?

There are several ways with the help of which you can identify a leak in your application, few are already inbuilt with the Android Studio. Let's have a look:

1. There is one tool called Leak Canary, it is a very wonderful tool to find out all the leaks in your app.

2. Android Studio itself has a handy tool for detecting memory leaks. Follow the below process:

• Run the app and play around with it.
• In Android Studio -> Android Monitor window -> Memory section, click on Initiate GC button. Then click on Dump Java Heap button.

• When Dump Java Heap button is pressed, 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 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.

So, these are the way to find out the leak in your application. But the best way would be not let it occur. So what are the ways which cause leak to occur? Below are the few ways which can cause a memory leak. These are as follows:

• Leak activity to a static reference.
• Leak activity to a worker thread.
• Leak thread itself.
• We should avoid passing Context objects further that our activity or avoid passing Context objects further that your activity or fragment
• Never store a Context or View in a static variable. This is the first sign of a memory leak.
• Always unregister listeners in your onPause()/ onDestroy() methods. This includes Android listeners, to things such as Location services or display manager services and your own custom listeners.
• Use Context-application (getApplicationContext()) instead of Context from an activity if you can. fragment
• NEVER EVER EVER make/store a Context or View in a static variable. This is the first sign of a memory leak.
• Always unregister listeners in your onPause()/ onDestroy() methods. This includes Android listeners, to things such as Location services or display manager services and your own custom listeners.
• Use Context-application (getApplicationContext()) instead of Context from an activity if you can.