Do not do anything wrong with Android to cause memory leakage

InAndroidContext can perform many operations, but the main function is to load and access resources. There are two kinds of context in Android, one is application context and the other is activity context. Generally, activity context is transmitted between different types and methods, for example, oncreate of an activity.

Java code:

1. Protected void oncreate (bundle state ){
2. Super. oncreate (State );
3. Textview label = new textview (this); // pass context to view Control
4. Label. settext ("leaks are bad ");
5. Setcontentview (Label );
6. }

Passing the activity context to the view means that the view has a reference pointing to the activity and then referencing the resources occupied by the activity: View hierachy and resource.

In this way, if the context memory leaks, a lot of memory will be leaked.

This vulnerability indicates that GC cannot recycle activity memory.

Leaking an entire activity is an easy task.

When the screen rotates, the system destroys the current activity, saves the status information, and creates a new one.

For example, if we write an application that needs to load a large image, we do not want to destroy the image and reload it every time we rotate the screen. The simple idea of implementing this requirement is to define a static drawable, so that the activity class creation and destruction is always stored in the memory.

Implementation is similar:

Java code:

1. Public class myactivity extends activity {
2. Private Static drawable sbackground;
3. Protected void oncreate (bundle state ){
4. Super. oncreate (State );
5. Textview label = new textview (this );
6. Label. settext ("leaks are bad ");
7. If (sbackground = NULL ){
8. Sbackground = getdrawable (R. drawable. large_bitmap );
9. }
10. Label. setbackgrounddrawable (sbackground); // drawable attached to a view
11. Setcontentview (Label );
12. }
13. }

This program looks very simple, but it has a big problem. When the screen is rotated, there will be a leak (that is, the GC cannot destroy the activity ). As we said earlier, the system will pin the screen when it rotates.
Destroys the current activity. However, when drawable is associated with the view, drawable saves the view reference, that is, sbackground
The label references are saved, while the label stores the reference of the activity. Since drawable cannot be destroyed
Both references and indirect references cannot be destroyed, so that the system cannot destroy the current activity, resulting in Memory leakage. GC is powerless for this type of Memory leakage.

To avoid Memory leakage, you can avoid the lifetime of any object in the activity from being longer than that of the activity.
The reference of the activity causes the activity to fail to be destroyed normally. We can use application context. Application
Context is associated with the life cycle of the application and has nothing to do with the life cycle of the activity.Application ContextYou can useContext. getapplicationcontextOrActivity. getapplicationMethod.

To avoid Memory leakage related to context, remember the following points:

1. Do not make an object with a long life cycle reference the activity context. That is, ensure that the object that references the activity has the same life cycle as the activity itself.

2. For objects with a long life cycle, you can use application context.

3. Avoid non-static internal classes and try to use static classes to avoid lifecycle issues. Pay attention to the lifecycle changes caused by internal class references to external objects.