Android study notes 23 -------------- role of the basic concepts of Android Context

Context literally indicates the Context, which is located in the android. content. Context of the framework package. In fact, this class is of the LONG type, similar to the Handle in Win32,
Many methods need to use Context to identify the caller's instance. For example, the first parameter of Toast is Context, which is usually replaced by this in the Activity,
This indicates that the caller's instance is Activity. When the onClick (View view) method of a button is used, an error is reported when this method is used, so we may use
ActivityName. this is mainly because the classes that implement Context mainly have several models unique to Android, such as Activity, Service, and BroadcastReceiver.

Generally, Context instances are implemented by various services. For example, the getSystemService (String) method is required for SensorManager during instantiation.
It must be executed by the Context instance, and there are some private file system I/O such as openFileInput and common Toast makeText methods.

In android, context can perform many operations, but the main function is to load and access resources. There are two types of context in android, one is application context,

One is activity context, which is usually transmitted between various types and methods.

For example

Activity

OnCreate:

Protected void onCreate (Bundle state)

{

Super. onCreate (state );

TextView label = new TextView (this );

// Pass context to view control

Label. setText ("Leaks are bad ");

SetContentView (label );

}

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 be recycled.

Activity memory. Leaking an entire activity is an easy task. When the screen rotates, the system will destroy the current activity and save it.

Status information, and then create a new one. For example, if we write an application that needs to load a large image, we do not want to sell it every time the screen is rotated.

Destroy the image and reload it. The simple idea of implementing this requirement is to define a static Drawable, so that the Activity class is always saved after creation and destruction.

.

Implementation is similar:

Public class myactivity extends Activity

{

Privatestatic Drawable sBackground;

Protectedvoid onCreate (Bundle state)

{

Super. onCreate (state );

TextView label = new TextView (this );

Label. setText ("Leaks are bad ");

If (sBackground = null)

{

SBackground = getDrawable (R. drawable. large_bitmap );

}

Label. setBackgroundDrawable (sBackground );

// Drawable attached to a view setContentView (label );

}

}

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 just now, the screen turns

The system will destroy the current activity. However, when drawable is associated with the view, drawable saves the view reference, that is, sBackground saves

Label, while label stores the reference of activity. Since drawable cannot be destroyed, neither the referenced nor indirectly referenced by it can be destroyed, so that the system does not

Method To destroy the current activity, resulting in Memory leakage. Gc is powerless for this type of Memory leakage. The method to avoid this memory leakage is to avoid

The lifecycle of any object in the activity is longer than that of the activity. This prevents the activity from being destroyed due to its reference to the activity. 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 context can be obtained through Context. getApplicationContext or Activity. getApplication. Avoid context problems

Memory leakage, remember the following points: 1. Do not make the object with a long life cycle reference activity context, that is, ensure that the object that references the activity and the activity

The lifecycle is the same. 2. For objects with long lifecycles, you can use application context3. avoid non-static internal classes and try to use static classes to avoid

No lifecycle issues. Pay attention to the lifecycle changes caused by internal class reference to external objects.

 

From running snails