Reprint please indicate source: http://blog.csdn.net/lmj623565791/article/details/40481055, this article from: "Zhang Hongyang's Blog"
Most of the content in this article is translated from: http://www.doubleencore.com/2013/06/context/I have re-organized the content and structure, I suggest you look at the original text as much as possible.
1. Context Concept
In fact, always wanted to write an article about the context, but also afraid of technology and fraught, so reference to some information, today prepared to write out, if there is insufficient, please point out, reference materials will be marked in the eye-catching place.
Context, I believe that whether it is the first day to develop Android, or the development of various kinds of Android, the use of the context must be unfamiliar ~ ~ You load resources, start a new activity, get system services, get internal file (folder) path, When you create a view operation, you need to participate in the context, which shows the common nature of the context. You may ask what is the context,context literal meaning context, or the scene, which is a process of user and operating system operation, such as you call, the scene includes the phone program corresponding interface, and hidden behind the data;
But what is the context in terms of the program? At the point of view of the program, we can have a more authoritative answer, the context is an abstract class, we can directly by looking at its class structure to illustrate the answer:
You can see that activity, Service, application are all sub-categories of the context;
That is, the Android system is an angle to understand: Context is a scenario that represents a process of interacting with the operating system. From the point of view of the program: context is an abstract class, and activity, Service, application, etc. are all an implementation of this class.
Take a closer look: Activity, Service, Application are inherited from Contextwrapper, and contextwrapper internal contains a base context, by this base Context to achieve the vast majority of methods.
First pull so much, have the ability to look at the context from other angles, refueling ~
2. Context and ApplicationContext
Read the title, do not be misunderstood, ApplicationContext does not have this class, in fact, it should be called: Activity and application in the context of the difference. Well, it is true, when we need context, if it is in the activity, most of the direct transfer of this, when in the anonymous inner class, because this can not be used, Need to write xxxactivity.this, many brothers will be lazy, directly to a getapplicationcontext. So have you ever thought about the difference between xxxactivity.this and getapplicationcontext?
Xxxactivity and Getapplicationcontext return is definitely not an object, one is an instance of the current activity, and one is an instance of the project's application. Since the difference is so obvious, then the respective usage scenarios must be different, the use of chaos may bring some problems.
Here's an introduction to the issues you need to be aware of when using the context.
3, the reference of the hold
When you write some classes, such as tool classes, you might write them in a single case, most of which require access to resources, and the need for context involvement.
In this case, you need to be aware of the context reference problem.
For example, the following wording:
[Java]View Plaincopy
- Package Com.mooc.shader.roundimageview;
- Import Android.content.Context;
- Public class Custommanager
- {
- private static Custommanager sinstance;
- private Context Mcontext;
- Private Custommanager (context context)
- {
- This.mcontext = context;
- }
- public static synchronized Custommanager getinstance (context context)
- {
- if (sinstance = = null)
- {
- Sinstance = New Custommanager (context);
- }
- return sinstance;
- }
- //some Methods
- private void Someothermethodneedcontext ()
- {
- }
- }
For the above single case, everyone should be not unfamiliar (please do not care about the efficiency of getinstance), the internal maintained a context of the reference;
This is no problem, the problem is that the context where we can not be sure, a great possibility, you in a certain activity in order to facilitate the direct transmission of this, so the problem is that our class of sinstance is a static and strong reference, An activity is referenced within it as a context, that is, our activity as long as our project is alive, there is no way to do memory recycling. The life cycle of our activity is certainly not that long, so it creates a memory leak.
So, how can we avoid such a problem?
Some people will say, we can soft reference, um, soft reference, if it is recycled, you are not afraid of nullpointexception.
Make the following changes to the above code:
[Java]View Plaincopy
- Public static synchronized Custommanager getinstance (context context)
- {
- if (sinstance = = null)
- {
- Sinstance = New Custommanager (Context.getapplicationcontext ());
- }
- return sinstance;
- }
In this way, we solve the memory leak problem because we are referencing a applicationcontext whose life cycle is consistent with our singleton objects.
In this case, some people may say, say well, then we all will do so in the future, I regret to say, No. As we have said above, the difference between context and application context is very large, that is, their application scenario (which you can also think of as ability) is different, not all scenarios where the activity is context, application The context can be done.
The following is a introduction to various context scenarios.
4, context of the application scenario
It is important to note that some numbers have been added to some of them, but they are actually yes in terms of ability, but why no? One explanation below:
Number 1: Starting the activity is possible in these classes, but a new task needs to be created. Generally not recommended.
Number 2: It is legal to go to layout inflate in these classes, but use the system default theme style If you customize some styles that might not be used.
Number 3: Allowed when receiver is null, in version 4.2 or later, to get the current value of the sticky broadcast. (Can be ignored)
Note: ContentProvider, broadcastreceiver in the above table, because there is a context in its internal method for use.
OK, here we look at the table, focusing on activity and application, you can see that the UI-related methods are not recommended or not to use application, and the first three operations are almost impossible to appear in application. In fact, as long as the grasp of a point, any UI-related, should use Activity as the context to deal with, and some other operations, service,activity,application and other instances can, of course, attention to the context of the holding of references, Prevent memory leaks.
5. Summary
Well, to this, the context of the analysis of the basic completed, I hope everyone in the future use of the process, can be a little consideration, the use of activity here is appropriate? Will it cause a memory leak? Did you pass the application work here?
Because of too much reference content, this text changed to translation ~ ~
Android context context you have to know everything