What is Android Context?
A Context means a scene, and a scene is a process in which we interact with the software. For example, when you use wechat, the scene includes the chat interface, address book, moments of friends, and some data behind it.
So from an Android app’s point of view, what is Context? An Activity is a Context, and a Service is a Context.
An application can be thought of as a dating environment, in which the user switches to different Settings, such as going to a fancy restaurant for dinner, then to the cinema for a movie, and then to XXX. .
The Activity class is really context-based, and the Service class is context-based. In addition to the Context class, activities also implement some other important interfaces. From an architectural design perspective, interface is just some function, while extends is the essence of a class, i.e. an Activity is essentially a Context. The other interfaces implemented simply extend the functionality of the Context, and the extended class is called an Activity or Service.
How many Context objects should there be in an application
We often call Context methods in application development. These methods seem to return some global object, not just an Activity. You might wonder, how many Context objects does an application have? For example, context.getResources () returns the Resource class object for the application, which returns the same Resource object no matter which Activity it is called from.
- An Activity is a Context, and a Service is a Context, so there are as many contexts as there are activities or services in your application.
- Methods such as getResource () return the same global object.
What does Context inheritance look like?
Context itself is a pure abstract class. The ContextWrapper constructor must contain a reference to the actual Context. The ContextWrapper constructor must contain a reference to the actual Context. There is also attachBaseContext () in the ContextWrapper to specify the actual Context object in the ContextWrapper object.
The ContextThemeWrapper contains an interface related to the theme, which is the theme specified for the Application or Activity in androidmanifest.xml via Android: theme.
Only an Activity needs a theme, and the background worker behind a Service doesn’t need to be dressed as brightly, so the Service directly inherits from ContextWrapper.
The ContextImpl class really implements all the functions in the Context, the real eight-pack, and all the methods that we’re calling in the Context class are actually implemented from this class.
When was the Context created?
The ActivityThread class is where each application starts on the client side. The ContextImpl class is created in six places:
- PackageInfo. MakeApplication ()
- PerformLaunchActivity ()
- HandleCreateBackupAgent ()
- HandleCreateService ()
- HandleBindApplication ()
- The attach ()
The attach () method is called only when the Framework process is started, not when the application is running.
Application Context
When the program is first started, the makeApplication () method is called. The specific code is as follows:
ContextImpl appContext = new ContextImpl(); appContext.init(this,null,mActivityThread); . appContext.setOuterContext(app);Copy the code
The Context for the Activity
When an Activity is started, Ams calls the ActivityThread’s scheduleLaunchActivity () method via IPC, which contains two arguments. One is ActivityInfo, which is a data class that implements the Parcelable interface, meaning the object is created by Ams and passed to ActivityThread via IPC. The other is some other parameter.
The scheduleLaunchActivity () method constructs a local ActivityRecord data class based on these two parameters. The ActivityThread creates an ActivityRecord object for each Activity. And use these data objects to manage activities.
HandleLaunchActivity () is then called, followed by performLaunchActivity (), which creates ContextImpl in the following code:
ContextImpl appContext = new ContextImpl();
appContext.init(r.packageInfo,r.token,this);
appContext.setOuterContext(activity);Copy the code
When performLaunchActivity () starts, the r.packageInfo variable is assigned a value. The PackageInfo object of r.packageInfo is the same as the PackageInfo object of Application.
Context for Service
When a Service is started, Ams calls the scheduleCreateService () method of ActivityThread via IPC, which also has two arguments. The first is ServiceInfo, which is a data class that implements a Parcelable interface that is created by AmS and passed inside ActivityThread via IPC. The second is other parameters.
The scheduleCreateService () method uses these two parameters to construct a CreateServiceData data object that ActivityThread creates for each Service it contains. And manage services through these objects.
Then, after executing the handleCreateService () method, create ContextImpl object code as follows:
ContextImpl appContext = new ContextImpl(); appContext.init(packageInfo,null,this); . appContext.setOuterContext(service);Copy the code
The mPackageInfo in the Context of a Service is the same as that in an Activity or Application.
The relationship between these contexts
As you can see from the above, the process for creating a Context object is basically the same, except that different data objects are used for Application, Activity, and Service.
The number of contexts an Application contains should be: Number of contexts = number of Services + number of activities +1, the last 1 is the Application class itself will also correspond to a Context object.
The application contains multiple ContextImpl objects while the internal variable mPackageInfo refers to the same PackageInfo object. This design structure generally means that ContextImpl is a lightweight class and PackageInfo is a heavyweight class. In fact, most of the heavyweight functions in ContextImpl that perform package operations are actually redirected to the corresponding methods of the mPackageInfo object, which actually call the same PackageInfo object.
If you have any questions, please leave a message
Note: The above ideas are from Android Kernel Anatomy.