An analysis of Android Context

A: What is the context?

The explanations in CONTEXT,SDK are as follows: interface to global information on an application environment. This was an abstract class whose implementation are provided by the Android system.it allows access to application-specific Resources and Classes,as well as up-calls for application-level operations such as launching Activities,broadcasting and R Eceiving intents,etc.

A simple summary of three articles:

1. It describes the information of an application's environment, which can be referred to as context.

2. The class is an abstract class, and Android provides a concrete implementation class for that abstract class.

3. Through it we can get the resources and classes of the application, as well as take some application-level actions, such as starting an activity, sending a broadcast, receiving intent.

Second: The inheritance relationship of context abstract class

as we can see, activity,service,application is actually all the sub-class of the context.

Third: Time and number of creation of context instance

Typically, the program creates a context instance in the following three scenarios:

1. When you create a Application object, and the entire app has a application object.

2. When you create a service object

3. When you create an Activity object

From the above, the number of context instances in an application is calculated as:

Total number of context = number of Service + activity + 1 (application corresponding context instance)

Four: How to get context and how to get context globally

because Activity,service itself is a context object, it is very simple to get the context in it, but how do we get out of these classes that are closely related to the context class? Of course there are many ways to get it, but I'm here to share a way to customize a application class to make it easier to manage some of the global state information in the program, such as the context. Create a myapplication that inherits from the application code as follows: (the following code comes from the first line of code)

<span style= "FONT-SIZE:14PX;" >public class Myapplication{private static context context; @overridepublic void OnCreate () {context = Getapplicationcontext ();} public static Context GetContext () {return context;}} </span>

Next we need to tell the system that when the program starts it should initialize the MyApplication instead of the default application class, the operation is very simple, modify the Androidmanifest.xml file <application Content under > tags:

<application    android:name= "com.example.hhw.MyApplication"    ....></appliaction>

after that, you can get it anywhere you want to use the context in the following ways.

<span style= "FONT-SIZE:14PX;" >myapplication.getcontext ();</span>

V: activity,application Context and memory leaks

First, the context of activity and the context of application is certainly not a thing, one is the context of the current activity, its life cycle is limited to this activity, one is the context of the entire application, Its life cycle accompanies the entire program, and because of the context of the activity, misuse of it often results in a memory leak, as shown in the following code:

<span style= "FONT-SIZE:14PX;" >public class Testcontext{private static TestContext testcontext;private Context context;private TestContext ( Context context) {This.context = context;}    public static synchronized TestContext getinstance (context context) {    if (null = = TestContext)    TestContext = new TestContext (context);    return testContext;}    } </span>

It is obvious that textcontext in the above singleton pattern is strongly referencing the static type, and often its life cycle accompanies the entire application, but you pass in the context if an activity, as long as our application is still alive, It has no way of normal recovery, which results in a memory leak. The workaround is simple, the initialization of TestContext is the passed parameter to Context.getapplicationcontext (), because this method obtains the context of the application, so there is no need to worry about memory leaks.

public class Testcontext{private static TestContext testcontext;private context Context;private TestContext (context Context) {This.context = context;}    public static synchronized TestContext getinstance (context context) {    if (null = = TestContext)    TestContext = new TestContext (Context.getapplicationcontext ());    return testContext;}    }

In that case, all the places where you can use the context are replaced with Context.getapplicationcontext (). Unfortunately, this is not possible, because they are not a thing, their application is different, not all the context of the activity of the scene, the context of the application can still, and I summed up a table, Represents the scenario between the two of them:

	Application	Activity
Show a dialog	NO	YES
Layout inflation	NO	YES
Start an activity	NO	YES
Bild to a Service	YES	YES
Send a broadcast	YES	YES
Register Brocastreceiver	YES	YES
Start a service	YES	YES
Load Resource Values	YES	YES

In fact, we can only grasp two principles:

1. The application context is not recommended for any UI-related use.

2. do not allow objects with long life cycles to refer to the activity context, that is, to ensure that the object referencing the activity is the same as the activity itself, if not, consider whether you can use the Applica The context of tion.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

An analysis of Android Context