Android Application
In the conceptual space provided by Android to developers, application is just a loose characterization concept, and there is not much substantive representation. In actual android space, there is no practical application concept. Even if there is a class called application, this is an application context state, which is a concept of extreme weakening. Application is just a concept of spatial category, and application is the context description of components such as activity and service. Application is not the core concept of Android, but activity is the core concept of Android.
From the android SDK documentation, we know that android applications are generally constructed by the following four components: Activity, broadcast intent aggreger, service ), content provider ). The following figure shows the concept space of Android. These components are attached to the application, and the application will not be established from the very beginning. Instead, the application object will be created only after these components are created and need to be run.
2.1 application process name
Why does it start with the application process name? As the kernel research, we still return to the most essential problem: No matter how the activity, service and other components are designed and run, to provide services, they must be attached to the Linux Process, only by establishing a message loop can components truly operate. How is an activity instance hosting running on a Linux Process? This is what we first want to understand.
In Android:Process = "string.
Allowclearuserdata = ["true" | "false"]
Android: allowtaskreparenting = ["true" | "false"]
Android: backupagent = "string"
...
Android: Label = "string resource"
Android: managespaceactivity = "string"
Android: Name = "string"
Android: Permission = "string"
Android: Persistent = ["true" | "false"]
Android: Process = "string"
Android: restoreanyversion = ["true" | "false"]
Android: taskaffinity = "string"
Android: theme = "resource or theme">
...
It is clearly described in the SDK.
Android: Process
The name of a process where all components of the application shocould run. Each component can override this default by setting its own process attribute.
By default, Android creates a process for an application when the first of its components needs to run. all components then run in that process. the name of the default process matches the package name set by Element.
By setting this attribute to a process name that's shared with another application, you can arrange for components of both applications to run in the same process-but only if the two applications also share a user ID and be signed with the same certificate.
Why do we propose such a definition? Android: process name.
By default, the activity Manager Service creates a process for the application when the first component of the application needs to run. The process name is Android: process = "string" is specified. The default value is the name of the application package. Once a process is created, all the components of the application will run in the process. They are bound to the name specified by Android: process, because they all have the same process name in the same application package, they are all hosted in the same process. The component obtains the application information from the package through classloader.
When actvitiy is created, if no application object exists on the application process end, the system uses makeapplication to create an application object and instantiate "android. app. application.
2.2 activitythread runtime framework
In the analysis, we can see that the actual application process is not the application but the activitythread. We can see from the actual application stack:
Naivestart. Main ()
Zygoteinit. Main
Zygoteinit $ methodandargscall. Run
Method. Invoke
Method. invokenative
Activitythread. Main ()
Logoff. Loop ()
....
Each application uses activitythread. Main () as the entry to go to message loop processing. For a process, we need this closed Processing framework.
Activitiythread is an important concept in the Concept Space of an application. It establishes a framework for running an application process and provides an iactivitythread interface as a communication interface with the activity Manager Service. through this interface, AMS can pass the activity state changes to the activity object of the client.
2.3 establish activitiythread
To facilitate the description, I abbreviated actvitiy Manager service as AMS.
In AMS, the concept of an application is processrecord, and requests are from activity, service... When the activity needs to resume, if the activity-related application process does not exist, am starts the application process.
The binding of AMS to an application process is divided into two parts. The first part is the application process established by AM, and the second part is the application process attach to AM, which establishes a communication channel with AM.
1) create a process: startprocesslocked (processname, appinfo. UID ). This function is called in startsecificactivitylocked.
(1) create a processrecord object app and add the object to mprocessnames. The application object uses the application name and UID to identify itself in mprocessnames. If all the activities in the same package use the default settings, these activities will be hosted in the same process, because the processname in applicationinfo is the same.
The mpidsselflocked Array records the PID. After the application process runs and attach itself to the AM, it finds its own past: processrecord Based on the PID.
2) Android. App. activitythread process startup
After the Android. App. activitythread process is created, it will jump to the main function of activitythread to start running and enter the message loop.
The application process uses thread. Attach () to initiate the AMS attachapplicationlocked call and pass the actvitiythread object and callingpid. Attachapplicationlocked finds the corresponding processrecord instance app in mpidsselflocked Based on the callingpid, and places actvitiythread in APP. thread. In this way, the application process establishes a two-way connection with AMS. Am can use the aidl interface to access the objects of the application process through app. thread.
Through the framework provided by activitythread, the application establishes message loop logoff and handler. From the previous chapters, we know that there are logoff and handler, and the entire system can work.
In order to systematically understand the application creation sequence and the data operations involved, I have provided the application process creation process: