Use of Context, use of Context

Use of Context, use of Context

　

1. Context Concept

Context, I believe that no matter the first day of Android development or the development of Android's various old birds, the use of Context must be no stranger ~~ You need Context to participate in loading resources, starting a new Activity, getting system services, getting internal file (folder) paths, and creating View operations. The attention of Context can be seen. You may ask what is Context, Context literal meaning, or scenario, that is, a process of user and operating system operations. For example, if you call, the scenario includes the interface corresponding to the telephone program and the data hidden behind it;

But what is Context in the perspective of the program? From a program perspective, we can have an authoritative answer. Context is an abstract class. We can explain the answer directly by looking at its class structure:

We can see that Activity, Service, and Application are subclasses of Context;

That is to say, from the Android system perspective, Context is a scenario that represents a process of interaction with the operating system. From a program perspective, Context is an abstract class, and Activity, Service, and Application are all implementations of this class.

 

Take a closer look: Activity, Service, and Application are inherited from ContextWrapper, and ContextWrapper contains a base context, which implements the vast majority of methods.

Let's talk so much about it. If we have the ability, we will examine the Context from other perspectives ~

2. Context and ApplicationContext

Do not misunderstand the title. ApplicationContext does not have this class. It should be called the difference between Activity and Application as Context. Well, this is indeed the case. When Context is needed, if this is in Activity, most people directly upload this. When the class is anonymous, this cannot be used, XXXActivity needs to be written. this, many buddies will be lazy, just get a getApplicationContext. Have you ever wondered the difference between XXXActivity. this and getApplicationContext?

XXXActivity and getApplicationContext certainly do not return an object. One is the instance of the current Activity and the other is the Application instance of the project. Since the difference is so obvious, their use cases are certainly different, and disorderly use may cause some problems.

The following describes the issues that need attention when using Context.

 

3. Maintain reference

When writing some classes, such as tool classes, you may compile them into a singleton method. Most of these tool classes need to access resources, that is, Context participation.

In this case, you need to pay attention to the reference problem of Context.

For example:

 

[Java]View plaincopy

1. Package com. mooc. shader. roundimageview;
3. Import android. content. Context;
5. Public class CustomManager
6. {
7. Private static CustomManager sInstance;
8. Private Context mContext;
10. Private CustomManager (Context context)
11. {
12. This. mContext = context;
13. }
15. Public static synchronized CustomManager getInstance (Context context)
16. {
17. If (sInstance = null)
18. {
19. SInstance = new CustomManager (context );
20. }
21. Return sInstance;
22. }
24. // Some methods
25. Private void someOtherMethodNeedContext ()
26. {
28. }
29. }

We should be familiar with the preceding Singleton (please do not care about the efficiency of getInstance) and keep a reference of Context internally;

 

There is no problem with this writing. The problem is that we are not sure about the Context. It is very likely that you directly upload this in an Activity for convenience; in this case, the sInstance in our class is static and strongly referenced, and an Activity is referenced inside it as the Context, that is, as long as our project is alive, there is no way to recycle memory for this Activity. The lifecycle of our Activity is certainly not so long, resulting in Memory leakage.

So how can we avoid such problems?

Some people may say that we can use soft references. Well, if soft references are recycled, are you not afraid of NullPointException.

Modify the above Code:

 

[Java]View plaincopy

1. Public static synchronized CustomManager getInstance (Context context)
2. {
3. If (sInstance = null)
4. {
5. SInstance = new CustomManager (context. getApplicationContext ());
6. }
7. Return sInstance;
8. }

In this way, we solve the memory leakage problem, because we reference an ApplicationContext, which has the same lifecycle as our singleton object.

 

In this case, some people may say, well, we will not be able to use it in the future. Sorry, no. As we have already said above, the difference between Context and Application Context is great. That is to say, their Application scenarios (you can also think of as capabilities) are different, application Context can handle not all scenarios where Activity is Context.

Next we will introduce various Context application scenarios.

4. Application scenarios of Context

 

We can see that some numbers are added to some "NO". In fact, these are actually "YES" in terms of capabilities, but why is it "NO? The following is an explanation:

Number 1: You can start an Activity in these classes, but you need to create a new task. It is generally not recommended.

Number 2: layout inflate is valid in these classes, but the default theme style is used. If you customize some styles, it may not be used.

Number 3: allowed when the consumer er is null. In version 4.2 or later, it is used to obtain the current value of sticky broadcast. (Ignore)

Note: The reason why ContentProvider and BroadcastReceiver are in the preceding table is that there is a context used in their internal methods.

 

Now, let's take a look at the table and focus on Activity and Application. We can see that basically none of the UI-related methods are recommended or applications are unavailable, for example, common dialogs, in addition, the first three operations cannot appear in the Application. In fact, as long as you grasp a point, all operations related to the UI should use Activity as the Context for processing; other operations, such as Service, Activity, Application, and so on can all be done, of course, note the holding of Context references to prevent memory leakage.

5. Summary

Now, the Context analysis is complete. I hope you can consider it a little later. Is it appropriate to use Activity here? Will it cause memory leakage? Is Application work introduced here?