Android core analysis 7-in-depth service analysis

Document directory

• 3 processstate and ipcthreadstate

From: http://blog.csdn.net/maxleng/article/details/5504485

 

In-depth Service Analysis

 

In the previous chapter, we analyzed the android IPC architecture and learned some basic concepts and principles of Android service construction. In this chapter, we will analyze Android services in depth. Three services in the android architecture:

• Native service
• Android Service
• Init space services are mainly attribute settings. This IPC is completed using Socket. I will discuss this in another chapter.

The navite service is actually a service completed completely in the C ++ space. It mainly refers to the system initialization at the beginning, through init. RC scripts, such as service manger service, zygote service, Media Service, and ril_demon service.

The android service is a service completed in the JVM space. Although the navite framework is also used, the service entity exists in the android space. Android is a service established during init2 initialization.

1 service essential structure

We start with analyzing the fundamental meaning of the service. The essence of the service is to respond to client requests. To provide services, you must establish a framework for receiving requests, processing requests, and responding to customer service. I think the android service designer will always keep this service's essential block diagram in mind. From the perspective of the program, the service must have a closed loop framework and a request processing framework.

 

 

 

After analyzing the service box clearly, you must understand the following mechanisms and their composition.

(1) Where is the closed loop structure placed?

(2) How do I distribute and manage requests?

(3) How is the processing framework established?

(4) How is the conceptual framework established?

 

 

2 service Basic Framework Analysis

In Android design, native service and Android service adopt the same closed loop framework. This closed loop frame is placed in the C ++ space of native, And the ProcessState@ProcessState.cpp and IPCThreadState@IPCThreadState.cpp classes complete the work.

 

 

 

In the service framework, processstate is a public part. The main framework of this public part is the closed loop framework and the Processing Framework for receiving requests from the binder. We use processsate to represent the service framework. In short:

(1) addservice

(2) establish a closed loop Processing framework.

 

Int main (INT argc, char ** argv)

{

Sp <processstate> proc (processstate: Self ());

Addservice (string16 ("xxx0"), new xxx0service ());

Addservice (string16 ("XXX1"), new xxx1service ());

...

Processstate: Self ()-> startthreadpool ();

Ipcthreadstate: Self ()-> jointhreadpool (); // Closed Loop framework

}

 

 

 

 

 

 

2.1 native service

Native service is a service established through the init. RC Script in the system init stage.

First let's take a look at the establishment process of an example mediaserver@main_mediaserver.cpp.

 

Int main (INT argc, char ** argv)

{

Sp <processstate> proc (processstate: Self ());

Sp <iservicemanager> Sm = defaultservicemanager ();

Logi ("servicemanager: % P", Sm. Get ());

Audioflinger: instantiate ();

Mediaplayerservice: instantiate ();

Cameraservice: instantiate ();

Audiopolicyservice: instantiate ();

Processstate: Self ()-> startthreadpool ();

Ipcthreadstate: Self ()-> jointhreadpool ();

}

 

 

We expand the code down to see the essence of things.

Int main (INT argc, char ** argv)

{

Sp <processstate> proc (processstate: Self ());

Sp <iservicemanager> Sm = defaultservicemanager ();

Defaservicservicemanager ()-> addservice (string16 ("media. audio_flinger"), new audioflinger ());

...

Processstate: Self ()-> startthreadpool ();

Ipcthreadstate: Self ()-> jointhreadpool ();

}

 

(1) The service process establishes a processstate object and registers the object in the context of the process.

(2) create a new audioflinger object and register the object in the Service Manager service.

(3) receive the request, process the request, and respond to the closed loop framework.

 

Android service 2.2

Androids service is a service established during init2 initialization.

All service cycle frameworks of Android are built on systemserver @ (systemserver. Java. The circular structure is not visible in systemserver. Java, but the init2 implementation function is created, a lot of services are created, and addservice is sent to service manager.

Main () @ COM/Android/Server/systemserver

{

Init1 ();

}

Init1 () is implemented in the native space (com_andoird_server_systemserver.cpp ). As soon as we look at this function, we can see that the original Closed Loop Processing Framework is here:

Init1-> system_init () @ system_init.cpp

 

In system_init (), we can see this long-overdue Closed Loop management framework.

{

Call "com/Android/Server/systemserver", "init2"

.....

Processstate: Self ()-> startthreadpool ();

Ipcthreadstate: Self ()-> jointhreadpool ();

}

 

Init2 () @ systemserver. Java sets up all the services to be used in Android:

Entropy Service

Power Manager

Activity Manager

Telephony Registry

Package Manager

Account Manager

Content Manager

System Content Providers

Battery Service

Hardware Service

Alarm Manager

Init Watchdog

Sensor Service

Window Manager

Bluetooth service

Statusbar

Clipboard Service

Input Method Service

Netstat Service

Connectivity Service

Accessibility Manager

Notification Manager

Mount Service

Device storage Monitor

Location Manager

Search Service

Checkin Service

Wallpaper Service

Audio Service

Headset observer

Backup Service

Appwidget Service

3 processstate and ipcthreadstate

 

From a macro perspective, the pocessstate and its ipcthreadstate are in the interface packaging layer between IPC and the kernel. As mentioned in the previous chapter, I will analyze it in more detail. The implementation of the C ++ space related to IPC is completed from the processstate object.

 

 

 

We can draw the following conclusion: no matter how complicated the JVM binder is, we still need to use the C ++ space object processstate to pass the data to the binder driver, the received data is also completed through the processstate object. processstate is the channel required by all binder IPC.

 

 

 

 

 

Processstate is placed in the global variable gprocess. Each process has only one processstate object, which is used to open the driver of the binder device and establish a thread pool. The ipcthreadstate has one thread. The ipcthreadstate instance is registered in the context ancillary data of the Linux thread. It is mainly responsible for the binder Data Reading, writing, and request processing framework. During construction, ipcthreadsate obtains the processsate of the process and records it in its member variable mprocess. Through mprocess, it can obtain the binder handle.

 

3.1 lifecycle of processstate

Since processstate is the basis of binder communication, process must be established before binder communication. The client and server must be created. Because the focus is on the server, the focus is placed on the server. In the Android system, there are c ++ space services and JVM space services. These two types of services are essentially the same, but in different forms, because they are based on processstate, therefore, the difference in form is only manifested in the difference in ontransact callback processing.

 

Native service

We can directly see that using sp <processstate> proc (processstate: Self () to establish a processstate, once processstate is called, and this self registers processsate in the global variable.

 

 

Android Service

We can see the same structure in setting up the android service system_init @ system_init.cpp. One difference is that all android services run in one process: systemsever process.

 

3.2 binder driver packaging @ ipcthreadstate

During processsate construction, use open_binder to open/driver/binder and record the handle in mdriverfd. This handle is not used in processstate. ipcthreadstate is the actual binder device handle, all binder operations are placed in ipcthreadstate:

 

(1) read/write: talkwithdriver () @ ipcthreadstate packages IOCTL (mprocess-> mdriverfd, binder_write_read, & BWR.

(2) request processing: executecommand (...) @ ipcthreadstate

(3) loop structure: jointhreadpool ()

Jointhreadpool ()

{

While (1 ){

Talkwithdriver (...)

...

Executecommand (...)

}

}