How can you do Android development if you don’t even understand Context?

Activity mActivity =new Activity()

As an Android developer, I wonder if you have ever thought about this question: can an Activity be created new? Android application development uses the JAVA language, and Activity is essentially an object. What is wrong with the above writing? I guess many people can't explain it clearly. Android programs are not like Java programs. You can just create a class and write a main() method to run them. The Android application model is a component-based application design pattern. The operation of components requires a complete Android engineering environment. In this environment, system components such as Activity and Service can work normally. These components cannot use the ordinary Java object creation method. You can create instances by just creating a new one. Instead, they must have their own context environment, which is the Context we are discussing here. It can be said that Context is a core functional class that maintains the normal operation of various components in Android programs.

What is Context?

The Chinese translation of Context is: context; context; background; environment. In development, we often call it "context", so what does this "context" mean? In language, we can understand it as context, and in program, we can understand it as an environment where the current object is located in the program, a process of interacting with the system. For example, in WeChat chat, the "environment" at this time refers to the chat interface and related data requests and transmissions. Context is involved in operations such as loading resources, starting Activity, obtaining system services, and creating View.

So what exactly is Context? An Activity is a Context, and a Service is also a Context. Android programmers abstract "scenes" into Context classes. They believe that every interaction between the user and the operating system is a scene, such as making a phone call or sending a text message. These are scenes with an interface. There are also some scenes without an interface, such as services running in the background. An application can be considered a work environment, and users will switch to different scenes in this environment. This is like a front desk secretary. She may need to receive guests, print documents, or answer customer calls, and these are called different scenes. The front desk secretary can be called an application.

How to understand Context vividly

The above concepts use a popular understanding method, understanding Context as "context" or "scene". If you still find it abstract and difficult to understand, here I give a metaphor that may not be very appropriate, hoping to help everyone understand: an Android application can be understood as a movie or a TV series. The four major components of Activity, Service, Broadcast Receiver, and Content Provider are like the four protagonists in this play: Hu Ge, Huo Jianhua, Shishi, and Baby. They were determined by the crew (system) from the beginning, and the whole play was led by these four leading actors, so these four protagonists are not just anyone (new an object) on the street. With actors, of course there must be a camera to shoot, and they must pass the play to the audience through the lens (Context), which corresponds to the four major components (four protagonists) must work in the Context environment (camera lens). What about Button, TextView, LinearLayout? They are like supporting roles or extras in this play. They are obviously not so important. Any passerby can play them (you can create a new object), but they also have to face the camera (work in the Context environment). So Button mButton = new Button (Context) is OK. Although it is not very appropriate, it is still easy to understand. I hope it helps.

Context in the source code

 /**
 * Interface to   global information about an application environment. This is  
 * an abstract class whose implementation is provided by  
 * the Android system.
 * allows access to application-specific resources and classes, as well as  
 * up-calls for application- level operations such as launching activities,
 * broadcasting and receiving intents, etc.
 */
 public abstract class Context {
 /**
     * File creation mode: the default mode, where the created file can only  
     * be accessed by the calling application ( or   all applications share the
 * same user ID).
     * <a href= "http://www.jobbole.com/members/[email protected]" > @see</a> #MODE_WORLD_READABLE
     * <a href= "http://www.jobbole.com/members/[email protected]" > @see</a> #MODE_WORLD_WRITEABLE
 */
 public   static final int MODE_PRIVATE = 0x0000; 
  
 public   static final int MODE_WORLD_WRITEABLE = 0x0002; 
  
 public   static final int MODE_APPEND = 0x8000; 
  
 public   static final int MODE_MULTI_PROCESS = 0x0004; 
  
 .
 .
 .
 }

The comments in the source code explain Context like this: Context provides an interface for global information about the application environment. It is an abstract class whose implementation is provided by the Android system. It allows access to resources and types that are characterized by applications, and is a context that governs some resources (application environment variables, etc.). In other words, it describes the information of an application environment (i.e., context); it is an abstract class, and Android provides a specific implementation class for this abstract class; through it we can obtain the resources and classes of the application (including application-level operations, such as starting an Activity, sending a broadcast, accepting an Intent, etc.). Since Context is an abstract class above, it must have its implementation class. We can use the IDE to view its subclasses in the Context source code and eventually get the following figure:

Context.png

The Context class itself is a pure abstract class, which has two specific implementation subclasses: ContextImpl and ContextWrapper. The ContextWrapper class, as its name suggests, is just a wrapper. The ContextWrapper constructor must contain a real Context reference. At the same time, ContextWrapper provides attachBaseContext() to specify the real Context object in the ContextWrapper object. Calling the ContextWrapper method will be redirected to the real Context object it contains. The ContextThemeWrapper class, as its name suggests, contains interfaces related to themes. The theme here refers to the theme specified for the Application element or Activity element through android:theme in AndroidManifest.xml. Of course, only Activity needs a theme, and Service does not need a theme, because Service is a background scene without an interface, so Service directly inherits from ContextWrapper, and the same is true for Application. The ContextImpl class truly implements all functions in Context. The various Context class methods called in the application are all implemented from this class. In one sentence, the two subclasses of Context have clear division of labor, ContextImpl is the specific implementation class of Context, and ContextWrapper is the wrapper class of Context. Although Activity, Application, and Service all inherit from ContextWrapper (Activity inherits from ContextWrapper's subclass ContextThemeWrapper), they all create ContextImpl objects during their initialization, and ContextImpl implements the methods in Context.

An application has several Contexts

In fact, this question itself is meaningless. The key lies in the understanding of Context. From the above relationship diagram, we can already get the answer. The specific implementation subclasses of Context in the application are: Activity, Service, Application. Then the number of Context = the number of Activities + the number of Services + 1. Of course, if you are careful enough, you may have questions: We often talk about the four major components, why are there only Activities and Services holding Context here, and what about Broadcast Receiver and Content Provider? Broadcast Receiver and Content Provider are not subclasses of Context. The Context they hold is passed from other places, so it is not counted in the total number of Context. The above relationship diagram also tells us from another aspect how lofty the status of the Context class is in the entire Android system, because it is obvious that Activity, Service, and Application are all its subclasses, and its status and role are self-evident.

What Context Can Do

What functions can Context achieve? There are too many. Context is needed to pop up Toast, start Activity, start Service, send broadcasts, operate database, etc.

 TextView tv = new TextView(getContext()); 
  
 ListAdapter adapter = new SimpleCursorAdapter(getApplicationContext(), ...); 
  
 AudioManager am = (AudioManager)getContext().getSystemService(Context.AUDIO_SERVICE);getApplicationContext().getSharedPreferences( name , mode); 
  
 getApplicationContext().getContentResolver().query(uri, ...); 
  
 getContext().getResources().getDisplayMetrics().widthPixels * 5 / 8; 
  
 getContext().startActivity(intent); 
  
 getContext().startService(intent); 
  
 getContext().sendBroadcast(intent);

Context Scope

Although Context is very powerful, you cannot do whatever you want with just a Context instance. There are still some rules and restrictions on its use. Since the specific instance of Context is implemented by the ContextImpl class, in most scenarios, the three types of Context, Activity, Service and Application, can be used universally. However, there are several special scenarios, such as starting an Activity and popping up a Dialog. For security reasons, Android does not allow Activities or Dialogs to appear out of thin air. The launch of an Activity must be based on another Activity, which is the return stack formed in this way. The Dialog must pop up on an Activity (unless it is a System Alert type Dialog), so in this scenario, we can only use the Activity type Context, otherwise there will be an error.

Context scope.png

From the above figure, we can see that the Context held by Activity has the widest scope and can do everything. Because Activity inherits from ContextThemeWrapper, and Application and Service inherit from ContextWrapper, it is obvious that ContextThemeWrapper has done some operations on the basis of ContextWrapper to make Activity more powerful. I will not post the source code for analysis here. Those who are interested can check the source code by themselves. I will not explain YES and NO in the above figure in detail. Here I will talk about two usage scenarios that are not recommended for Application and Service in the above figure.

1: If we use ApplicationContext to start an Activity with LaunchMode of standard, we will get an error android.util.AndroidRuntimeException: Calling startActivity from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want? This is because non-Activity type Context does not have a so-called task stack, so the Activity to be started cannot find the stack. The solution to this problem is to specify the FLAG_ACTIVITY_NEW_TASK flag for the Activity to be started, so that a new task stack will be created for it when it is started, and the Activity is started in singleTask mode. All this method of using Application to start Activity is not recommended, Service is the same as Application.

2: It is also legal to inflate the layout in Application and Service, but the system default theme style will be used. If you customize some styles, they may not be used. Therefore, this method is not recommended.

To sum up in one sentence: Anything related to UI should be handled using Activity as Context; for other operations, Service, Activity, Application and other instances can also be used. Of course, pay attention to holding Context references to prevent memory leaks.

How to get Context

Usually we want to get the Context object, there are four main methods:

1: View.getContext, returns the Context object of the current View object, usually the Activity object currently being displayed.

2: Activity.getApplicationContext, get the Context object of the (application) process where the current Activity is located. Usually when we use the Context object, we should give priority to this global process Context.

3: ContextWrapper.getBaseContext(): This method is used to obtain the Context before a ContextWrapper is decorated. This method is not often used in actual development and is not recommended.

4: Activity.this returns the current Activity instance. If it is a UI control, you need to use Activity as the Context object, but the default Toast can actually use ApplicationContext.

getApplication() and getApplicationContext()

As mentioned above, getApplicationContext is used to obtain the current Application object. I wonder if you have thought of getApplication(). What is the difference between these two methods? I believe this question will stump many developers.

getApplication()&getApplicationContext().png

Programs don't lie. Through the above code, we can print out that the memory addresses of the two are the same, which seems to be the same object. In fact, this result is also easy to understand, because as mentioned earlier, Application itself is a Context, so the result obtained by getting getApplicationContext() here is the instance of Application itself. So the question is, since the results of these two methods are the same, why does Android provide two methods with duplicate functions?

In fact, there is a big difference in the scope of these two methods. The semantics of the getApplication() method are very strong, and you can tell at a glance that it is used to obtain the Application instance, but this method can only be called in Activities and Services. So perhaps in most cases we use Application in Activities or Services, but if you want to get the Application instance in some other scenarios, such as BroadcastReceiver, you can use the getApplicationContext() method.

 publicclassMyReceiverextendsBroadcastReceiver{ 
  
 @Override
 publicvoidonReceive(Contextcontext,Intentintent){
 ApplicationmyApp=(Application)context.getApplicationContext(); 
  
 } 
  
 }

Memory leak caused by Context

However, Context cannot be used randomly. Improper use may cause memory leaks. The following examples show two incorrect reference methods.

Wrong singleton pattern

 public class Singleton {
    private static Singleton instance;
 private Context mContext; 
  
    private Singleton(Context context) {
        this.mContext = context;
 } 
  
 public   static Singleton getInstance(Context context) {
        if (instance == null ) {
            instance = new Singleton(context);
 }
 return instance;
 }
 }

This is a non-thread-safe singleton pattern. As a static object, instance has a longer life cycle than ordinary objects, including Activity. If Activity A uses getInstance to obtain the instance object and passes in this, the resident Singleton in memory saves the Activity A object you passed in and always holds it. Even if the Activity is destroyed, it cannot be GCed because its reference still exists in a Singleton, which leads to memory leaks.

View holds a reference to Activity

 public class MainActivity extends Activity {
    private static Drawable mDrawable; 
  
 @Override
    protected void onCreate(Bundle saveInstanceState) {
        super.onCreate(saveInstanceState);
        setContentView(R.layout.activity_main);
        ImageView iv = new ImageView(this);
        mDrawable = getResources().getDrawable(R.drawable.ic_launcher);
        iv.setImageDrawable(mDrawable);
 }
 }

There is a static Drawable object. When ImageView sets this Drawable, ImageView saves a reference to mDrawable, and the this passed in by ImageView is the mContext of MainActivity. Because the mDrawable modified by static is resident in memory, MainActivity is its indirect reference. When MainActivity is destroyed, it cannot be GCed, so a memory leak occurs.

Using Context Correctly

Generally, memory leaks caused by Context are almost always caused by the failure of destruction when Context is destroyed because of being referenced. The Context object of Application can be understood as existing with the process, so we summarize the correct posture for using Context:

1: When the Application Context can handle it and the object has a long life cycle, the Application Context is used first.

2: Do not allow objects whose lifecycle is longer than that of the Activity to hold references to the Activity.

3: Try not to use non-static inner classes in Activity, because non-static inner classes will implicitly hold references to outer class instances. If you use static inner classes, hold the outer instance reference as a weak reference.

Summarize

In short, Context plays an important role in the Android system. It can do almost anything, but you can't use it as you want. Be careful of memory problems caused by improper use. If you still have questions or want to know more, you can watch my video course: