Android Process Communication and android Process Communication

Android Process Communication and android Process Communication

I recently studied the communication between Android processes. It turns out to be used, but it is useless. Let's take a look.

At the beginning, my head was so big. After watching it all night, my head became like this. It scared the baby to go to bed quickly ,,

Drink tea and tell a story before talking about this communication.

(After writing this article, I finally admitted that my writing skills are poor, but I think I did it one by one, so I can't work hard for nothing)

Bytes -----------------------------------------------------------------------------------------------------------------

In other words, I have a buddy who recently came to contact him for a combination, but he now has a girlfriend, so he is very upset and cannot sleep all day, so he wants to ask God what is a good idea, but for the sake of security, he can't go directly to God, and he can't die for five or six times a day. There is no bug in his life. What should we do? Fortunately, there is another creature in the world called the priest, and then he went to the priest.

"Father, I am very upset recently. Could you help me ask God what to do"

"Oh, my son, God is omnipotent. He can solve any problem for us. Let's talk about it"

"I have a girlfriend now, but my ex-girlfriend recently came to me again. Both of them are very nice to me. What should I do ..... (N words are omitted here )"

The priest shouted out of his sleep and said, "God, this person is ill. Two women like him. If you just accept it, you will be done. He is still struggling to choose the one, what should you do"

"Oh, I know about this. Isn't he a good friend named Yang XX? I have tried to make his ex-girlfriend like Yang XX. Haha"

"Son, God has tried to make your ex-girlfriend like someone else. It's a good friend of yours, Yang XX. Do you think so"

..........

The scene turned to the basketball court. I was excited by the cheers of a group of girls and suddenly pulled by one arm.

"XX, do you know what is bothering me recently ?"

I was disturbed by the worship of a girl. "Isn't that the ex-girlfriend? What's wrong"

"Haha, I am going to find God today. God has helped me solve it"

"Oh, how can this problem be solved? You're happy"

"God tried to make my ex-girlfriend like you"

Black in front of my eyes, a burst of blood, "god, slot you X"

My girlfriend is in the dark.

Bytes ---------------------------------------------------------------------------------------------------------------

(I read it again, but this story is really a bit of a bit ....)

Well, forget it. You may feel that this story has nothing to do with the communication between processes, but I still feel quite good ..

Android Process Communication,

　　Why can't cross-process communication be performed directly?

• • Because, for security considerations. In the Android system, the application memory is independent and cannot be accessed from each other. The data of each application is in its own memory.

　　So how to communicate across processes?

• • To achieve cross-process communication, you must find a place that can be accessed by everyone in the public, and use a dark sign to achieve the purpose of communication.

Cross-process communication in Android uses the binder Mechanism.

　　So what is the binder? What is the working principle,

The Binder is actually a piece of memory. It belongs to a driver on the Linux layer, but this driver is not a driver hardware, but a piece of memory. Different applications achieve communication through reading and writing data to a public memory. And communication between applications,

There must be a dark sign (it becomes a hot pot without a dark sign, it's a mess !), Two applications can communicate only when they hold the same ID (AIDL.

I know why it is different. How can I write the specific steps?

Because it is not the focus of this article, please refer to the official development documentation. Now the development documentation is getting more and more detailed. It is estimated that 12-year-olds in the United States can develop a simple application at will. Alas, English.

I know the above, but I still don't know how the binder works,Next we will introduce how the binder works.

In the Android system, the binder Mechanism consists of Client, Server, ServiceManager, and Binder drivers. The Client, Server, and Service Manager run in the user space, and the Binder Driver runs in the kernel space. The Binder driver is a core

Service Manager is a daemon used to manage the Server and provide the Server interface query function to the Client. Developers only need to implement their own Client and Server in the user space. The Client and Server communicate with each other on the infrastructure provided by the Binder driver and ServiceManager.

Working principle of binder:

Binder communication is a client-server communication structure,

1. On the surface, the client directly calls the server by obtaining a proxy interface of the server;

2. In fact, the methods defined in the proxy interface correspond one to one with those defined in the server;

3. When the client calls a method in a proxy interface, the proxy interface method packs the parameters passed by the client into a Parcel object;

4. The proxy interface sends the Parcel to the binder driver in the kernel.

5. The server will read the request data in the binder driver. If it is sent to itself, unpack the Parcel object, process it, and return the result;

6. The entire call process is a synchronization process. During server processing, the client will block

It's easy to understand.

As mentioned above, the Service Manager component is used to manage the Server and provide the Client with the query Server remote interface function. Therefore, the Service Manager must communicate with the Server and Client. However, Service Manager, Client, and

The three servers run in independent processes, so the communication between them is also inter-process communication, and the Binder mechanism is also used for inter-process communication. Therefore, while ServiceManager acts as the daemon of the Binder mechanism, it also acts as the Server

In other words, it is a special Server.

In fact, during normal development, System Services communicate with applications through the Binder Mechanism. Next we will explain in detail the system services and application communication processes, to help you better understand the binder Mechanism.

　　Communication between system services and applications

 

System Service:

1. It is a subclass of the Binder class. Once created, a thread endless loop is enabled to check whether data is written to a certain segment of memory.

2. When it is created, it creates a xxxRemote remote object and stores it in the Binder driver. The xxxRemote remote object can communicate with the xxxService system service.

Application end:

Use context. getSystemService to obtain the xxxServiceProxy object, which references the xxxRemote object. xxxServiceProxy and xxxService share the same API. When xxxServiceProxy is called, xxxServiceProxy calls

XxxRemote and wait for xxxRemote to return. XxxRemote writes data to a certain segment of memory. After writing the data, it starts to monitor the memory area. The Binder driver copies the data written by xxxRemote to the memory area monitored by xxxService, when xxxService is detected

The data is read and processed. After processing, the data is written to this region. Then, the Binder driver copies the data to the memory area monitored by xxxRemote, when xxxRemote finds that there is data in the memory area to read the data in this area and returns the content to xxxServiceProxy. This way

The communication between processes is completed.

Therefore, a system service generates two Binder objects, one is the system service running in the system itself, and the other is the remote object stored in the Binder driver. The difference is that the system service Binder object will enable a thread to listen to messages, the remote object will not, it is running in

The caller's thread.

The client can also create a Binder object by itself instead of using the remote Binder object of the System Service and associate it with the System Service through the Binder driver. In this way, the client can notify the system service at any time, the system service can also notify the client at any time, instead

The System Service mentioned above can only be passively waiting for the client to call.

 

How is the binder operated internally?

The Binder object has its own memory region. When Binder1 wants to send data to Binder2, it will write the data to its memory region and then notify the Binder driver, the Binder driver copies data to the memory zone of Binder2.

Binder2 is notified to read the data. After Binder2 completes reading the data, it will write the data to the memory area of binder2 and then notify the Binder driver, the Binder driver copies the data to the memory area of binder1. This completes

Communication.

If Binder1 is a system service and Binder2 is a remote object of the system service, any application can communicate with binder1. However, the disadvantage is also obvious. It can only be requested by the application.

System Service, the system service cannot contact the application. This method is used for WifiManagerService.

Another way is that Binder1 is a system service, and Binder2 is the Binder object created by the application. After the two are connected through the Binder driver, the application can actively call the system service, system services can also actively call applications

. WindowManagerService adopts this method.

I wrote this blog after reading a lot of materials. If you are interested, go to the workshop.