- 1
1. Memory leaks due to static variables
The simplest leak activity is to define a static variable in the activity class and point it to a running activity instance. If the reference is not cleared before the end of the Activity's life cycle, it will leak. Because the Activity's class object is static, once loaded, it will remain in memory while the APP is running, and if the class object is not unloaded, its static members will not be garbage collected.
- 2
2. Memory leaks caused by singleton
Another similar scenario is to implement a singleton pattern for frequently initiated Activity, so that its resident memory allows it to recover quickly.
If we have a very time-consuming View created that stays the same Activity for a different life cycle, implement a singleton pattern for it. Once the View is loaded into the interface, it holds a strong reference to the Context, which is our Activity object.
Since we referenced this View through a static member, we also quoted the activity, so the activity was compromised. So be sure not to assign the loaded View to a static variable, and if you really need to, ensure that it is removed from the view level before the Activity is destroyed.
- 3
3. Memory leaks caused by internal classes
We often define an inner class within the Activity, which can increase encapsulation and readability. But if we create an object of an inner class and hold a reference to the activity through a static variable, then there is also the possibility of an activity leak.
- 4
4. Memory leaks caused by threads
A memory leak can occur when an anonymous Asynctask object is defined within the Activity. If Asynctask is still executing after the activity is destroyed, it will prevent the garbage collector from reclaiming the activity object, causing a memory leak until the end of execution to reclaim activity.
Similarly, the use of Thread and TimerTask can also lead to Activity leaks. As long as they are created through anonymous classes, they also hold strong references to Activity, which can lead to memory leaks, even though they are executed on separate threads.
- 5
Memory leaks due to 5.Handler
Defining an anonymous Runnable object and committing it to Handler can also lead to Activity leaks. The Runnable object indirectly references the activity object that defines it, and it is committed to the MessageQueue of handler, which causes the activity to leak if it is not processed when the activity is destroyed.
- 6
6. Memory leaks due to resource not shutting down
If system services can be obtained through context.getsystemservice, they are responsible for performing some background tasks or providing interfaces for hardware access. If the Context object wants to be notified when an event inside the service occurs, it needs to register itself in the listener for the service. However, this allows the service to hold a reference to the activity, and if the developer forgets to unregister when the activity is destroyed, the activity leaks.
END