java garbage collector, developers need to specifically manage memory allocation, reducing application due to the partial failure led to the collapse, but may not prevent the release of the memory stack tumbled, so write more secure code.
However, there are still a lot of java logic easily lead to memory leaks possible. If you are not careful, it is easy to waste unreleased memory, which results in false memory of light thrown OOM
Memory Leak
- General memory leaks (traditional memory leak): forget the memory allocated by the release caused (Cursor forget to close, etc.)
- Logical memory leak (logical memory leak): When the application no longer need this object, but the object has not yet released all references
If you hold a strong reference to the object, the garbage collector can not reclaim the object in memory
Android, the most easily lead to memory leaks Context, such as Activity of Context, it contains a lot of memory references, such as View Hierarchies and other resources. Once the leak Context, it means that all the objects it points to a leak. android machines with limited memory, too much memory leak easily lead to OOM
Activity.onDestroy () Activity is considered the end of life, it seems the program, it should be destroyed, or the need to recover these Android system memory (activity when the memory is not enough, android will recover invisible)
If Activity.onDestroy () executed, there are still references the stack holding the activity, the garbage collector can not put his mark as recovered memory (result Activity survive outside of its life cycle)
Leading to potential memory leak traps more than two:
- Global process (process-global) of static variables. This disregard application state, holds a strong reference to the activity of things
- In addition to live threads Activity lifecycle. Not emptied strong references to the Activity.
----------------------------------------------------------------------------------------------------------------
Static Activity
Activity static variables defined in the class, the activity currently running instance assigned to the static variables.
If this does not clear the static variable activity at the end of life, it will lead to memory leaks. Because static throughout the life cycle of the application, so the leaked Activity will always exist in the application process will not be garbage collected.
Such codes to avoid static Activity activity;
----------------------------------------------------------------------------------------------------------------
Static Views single embodiment save activity
In a single embodiment, if Activity often used, then stored in memory is a very practical example. However, due to the life cycle of a single case of the life cycle of the application, this will extend the life cycle of Activity (Activity forced to extend the life cycle is very dangerous and unnecessary, in any case can not save a single case of similar objects Activity )
Special case: If a View initialize a lot of resources, but also in a life-cycle activity remains the same, then you can turn it into a static, loaded onto a tree view (View Hierachy), like this, when activity is destroyed, it should be free up resources. (At the time of the destruction should view this static view of view is set to null)
Activity in the incoming call when the Singleton getInstance () method, then when the instance is not released, the Activity will always exist. Thus causing a memory leak.
Can pass context.getApplicationContext () when an incoming context to
static view is not recommended, or should be destroyed when the null set
Inner Classes: strong increase readability, but the cause of memory leaks, is held inside the outer class instance references, such as internal classes held by the Activity object
Solution 1. The inner class into a static inner classes, anonymous inner classes to become a static anonymous inner classes
2. If there is a strong reference Activity of property, the property reference to weak references
3. In the case of business operations, when executed onDestroy Activity, the end of these time-consuming tasks
----------------------------------------------------------------------------------------------------------------
Inner Classes
Suppose there are internal Activity class, this can improve the readability and encapsulation. If we create an inner class, but also holds a reference to a static variable, it is likely that a memory leak (can be destroyed when the blank)
One of the advantages is that the inner class can access external class, is not good, resulting in a memory leak reason is because the inner class to hold an external reference to an instance of the class.
----------------------------------------------------------------------------------------------------------------
Anonymous Classes
Anonymous class also maintains a reference to the outer class. So the memory leak is likely to occur when you define an anonymous Activity in the AsyncTask. When the task execution during overcast fill time-consuming tasks in the background, Activity unfortunately destroyed (user exits, system recovery), which was held AsyncTask Activity instance will not be garbage collected until the end of asynchronous tasks.
----------------------------------------------------------------------------------------------------------------
Handler
Similarly, the definition of anonymous Runnable, perform anonymous Handler. Runnable classes are held inside the outer class implicit reference, it is transmitted to the message queue MessageQueue Handler, the message is not processed until Message, Activity instances will not be destroyed, thus leading to a memory leak.
----------------------------------------------------------------------------------------------------------------
Threads
As long as anonymous instance of the class, whether or not the worker, will hold a reference Activity, leading to memory leaks
----------------------------------------------------------------------------------------------------------------
TimerTask
As long as anonymous instance of the class, whether or not the worker, will hold a reference Activity, leading to memory leaks
----------------------------------------------------------------------------------------------------------------
Sensor Manager
By Context.getSystemService (int name) can obtain system services. These services work in their respective processes, help application processing background tasks, processing hardware interaction. If you need to use these services, you can register listener, which can lead to service held by the Context of references, if not destroyed when the Activity log off the monitor, cause a memory leak
http://tryenough.com/android-momeryleak memory leaks and solutions