AMS for Android Core Analytics
App and AMS (Systemserver process) and zygote process belong to three separate processes
The app and AMS communicate with the IPC through the binder, and the AMS (Systemserver process) communicates with the zygote through the socket.
Open a Applauncher
Launcher is responsible for the display and control of desktop icons and is essentially an application, just like our app, which is also inherited from the activity
Take a double-click to open an app as an example:
No matter where you click on the icon, it will be called
mLauncher.startActivitySafely(v, appInfo.intent, appInfo);
This method, the last call to Startactivityforresult ()
The Startactivityforresult () is called minstrumentation.execstartactivity ().
Instrumentationinstrumentation, each application has only one instrumentation object, and within each activity there is a reference to that object. Instrumentation can be understood as the steward of the application process, activitythread to create or pause an activity, you need to instrumentation to do the specific action. AMS is the board of Directors, responsible for the command and dispatch, Activitythread is the boss, although said that the family matters themselves, but need to obey the command of AMS, and instrumentation is the boss, responsible for the family's big things, but generally not in the limelight, Listen to the activitythread of the householder. Binder communication between AMS and Activitythread
Minstrumentation.execstartactivity () Next calls this method
Activitymanagernative.getdefault () . startactivity
The Activitymanagernative.getdefault returned here is the Activitymanagerservice remote interface, which is activitymanagerproxy.
Look at Activitymanagerproxy.startactivity (), what is done in this is IPC communication, using Binder object, call Transact (), all the required parameters are encapsulated into parcel object, Send data to AMS for communication.
Activitymanagernative Source:
Public Abstract classActivitymanagernativeextendsBinderImplementsiactivitymanager{//from the class declaration, we can see that activitymanagernative is a subclass of binder and implements the Iactivitymanager interface Static PublicIactivitymanager Getdefault () {returnGdefault.get (); } //gets a Iactivitymanager object through a singleton pattern, which is obtained by Asinterface (b) Private Static FinalSingleton<iactivitymanager> Gdefault =NewSingleton<iactivitymanager>() { protectedIactivitymanager Create () {IBinder B= Servicemanager.getservice ("activity")); if(false) {LOG.V ("Activitymanager", "default service binder =" +b); } Iactivitymanager am=Asinterface (b); if(false) {LOG.V ("Activitymanager", "Default service =" +am); } returnam; } };}//The final return is a Activitymanagerproxy objectStatic Publiciactivitymanager asinterface (IBinder obj) {if(obj = =NULL) { return NULL; } Iactivitymanager in=(Iactivitymanager) obj.querylocalinterface (descriptor); if(In! =NULL) { returnIn ; } //The obj parameter of the binder type in this is stored as a member variable of the Activitymanagerproxy as a mremote member variable, which is responsible for IPC communication return Newactivitymanagerproxy (obj); }}
It is clear that activitymanagernative inherits Binder, which is the binder local object. The Iactivitymanager is a remote interface that represents the functionality that AMS can provide.
Activitymanagerproxy is a remote proxy object for AMS, and activity can invoke methods in the interface provided by AMS through proxy objects.
So the app and AMS communicate with the IPC via binder
AMS communicates to Activitythread
The above explains how activity communicates to AMS,
What if AMS wants to inform Activitythread to do something?
or through binder communication, but changed the other pair, replaced by Applicationthread and Applicationthreadproxy.
Private class extends applicationthreadnative {} Public Abstract class extends Implements iapplicationthread{} class Implements Iapplicationthread {}
After AMS receives the client's request, how does it open an activity?
Can look at the above diagram, basically is the AMS get the activity stack reference, and then add to the stack according to the boot mode, and finally callback Applicationthread to perform the original activity pause
Broadcasting
Why do I need a broadcast
Broadcast is the most common implementation of the operating system framework layer to the Observer pattern (Observer)
A software system often requires that some other object make corresponding changes when the state of an object changes. There are many design options to do this, but in order to make the system easy to reuse, a low-coupling design should be chosen. Reducing the coupling between objects facilitates the reuse of the system, but designers need to enable these low-coupling objects to maintain coordination of actions and ensure a high degree of collaboration. The Observer pattern is the most important of the various design scenarios that satisfy this requirement.
The APIs that are sent by the broadcast are:? sendbroadcast?sendorderbroadcast?sendstickybroadcast? How to listen for broadcasts: How do I use Registerreceiver mode for dynamic registration? Static registration defines the Broadcastreceiver class in Androidmanifest.xml and implements
What kinds of radio are there?
Broadcast has unordered broadcasts, ordered broadcasts, and sticky broadcasts, where sticky broadcasts require broadcast_sticky permissions
Service
What is a service?
Service is one of the components of Android system, and activity,broadcast,conent provider and called Android four components, service is not visible, is no interface, is running in the background, Service typically handles more time-consuming and long-running operations
There are two ways to start a service:
1. StartService is primarily used to start a service to perform background tasks, do not communicate, and stop service use StopService
2. Bindservice The service started by this method can get the status of the service, stop the services using Unbindservice
Android-ams Source Code Analysis