OverviewAs an Android developer, I'm afraid the context can rank the previous number in the most used classes of the day. Because context objects are so common in our projects, we are loading resources, starting activities, getting service, sending broadcast, and creating view with context involved. In short, context is an environment that provides a variety of functions, resources, and services for an Android program, and the context resource is only set in the system, because its subclasses (Application,activity,service) differ in how this same resource is handled , so that the context objects exhibit their differences in functionality.
Save Context ReferenceWhen writing a tool class, we often write a singleton pattern that accesses resources in a large way, which means that the context is needed to participate. This will involve the context of the reference problem. For example, the following tool-like notation:
public class Util {
Private context context;
private static Util Util;
Private Util (Context context) {This.context = context; }
public static util getinstance (Context context) { if (Null == util) { synchronized (Util.class) { if (Null == util) { util = new util (context); } } } return util; }} |
In the tool class above, using singleton mode, a context reference is stored internally, and on the face of it there is no problem, but the actual application may cause memory leaks. Because we are not able to determine where the incoming context came from, if it is in an activity, the direct pass in is this, then this util class is a static modifier and strongly refers to the resident memory, It will always hold this activity as a context reference, which will result in the activity being destroyed, and there is no way to reclaim memory. So it creates a memory leak. In order to avoid the above problem, we canThe getinstance method is optimized as follows:
| public static Util getinstance (context context) {if (null = = Util) {synchronized (Util.class) { if (null = = util) {util = new Util (Context.getapplicationcontext ()); }}} return util; } |
The method described above can be understood as referring to the ApplicationContext, whose life cycle is consistent with the Singleton object, as long as the application is still running this context will persist. So when the context of application can be solved, priority is given to usingthe application context, which avoids memory leaks.
Context's application scenarioHowever, the above solution is not omnipotent, when it comes to UI loading operations, initiating activity, etc., when using the application context, the program cannot run. This is mainly because the context represented by activity and application is not the same object, and their respective usage scenarios are different. The following are their respective usage scenarios, which can be compared.
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.
As can be seen from the table above, and UI-related methods are not used application, should use activity as the context to handle, and then with the tool class in the holding of context references, to prevent memory leaks, this can achieve good application results.
Application summary of context in Android
