Profile
- Multi-process concepts and common considerations for multiple processes
- IPC Basics: Android Serialization and binder
- Several common ways of communicating across processes: Bundles pass data through intent, file sharing, ContentProvider, Binder-based aidl and Messenger, and sockets.
- Binder Connection Pool
- Advantages and disadvantages of various inter-process communication modes and their application scenarios
IPC is the abbreviation for inter-process communication , meaning inter-process communication or cross-process communication , refers to the process of data exchange between two processes.
Threads are the smallest unit of CPU scheduling, and threads are a limited system resource. A process generally refers to an execution unit that refers to a program or an application on a PC or mobile device. A process can contain multiple threads, so processes and threads are included with the included relationship. In the simplest case, there can only be one thread in a process, that is, the main course, which is also called the UI thread in Android.
IPC is not unique to Android, and any operating system requires an appropriate IPC mechanism, such as the ability to communicate between processes through the Clipboard on Windows. Android is a Linux kernel-based mobile operating system, its inter-process communication mode does not fully inherit from Linux, it has its own interprocess communication mode.
1. Multi-process mode in Android
By assigning the Android:processs property to the four components to enable the multi-process mode, we cannot assign a thread or an entity class the process in which it is running.
<android:name= ". Secondactivity " android:process=": Remote "/>< Android:name= ". Thirdactivity " android:process=" Com.example.remote "/>
Applying the default process is the current package name, which specifies the process for each of the two activity, which means that two new processes are added to the current application. Assuming that the current application package name is Com.ipc.example, the secondactivity process is Com.ipc.example.remote, ":" means to enclose the current package name in front of the current process name, and ":" The beginning of the process belongs to the currently applied private process, and other applied components cannot run in the same process as it. Processes that do not start with ":" are global processes, such as specifying the process where thirdactivity is a global process.
2. operating mechanism of multi-process mode
New Usermanager class:
public class Usermanager {public static int suserid = 1;}
In mainactivity, change the value of sUserID to 2, because mainactivity is applying the default process, secondactivity in the specified process, Printing the value of sUserID in Secondactivity will find that the sUserID value does not change, or 1.
The reason for this is that secondactivity runs in a separate process, Android allocates a separate virtual machine for each application, or allocates a separate virtual machine for each process, and different virtual machines have different address spaces in memory. This results in a multi-minute copy of the same object being accessed in different virtual machines. In the example above, mainactivity modifies the value of sUserID only affects the current process and does not have any effect on other processes.
All four components running in different processes will fail as long as they need to share data through memory. In general, multiple processes can cause the following problems:
- Static members and Singleton modes are completely invalidated
- The thread synchronization mechanism is completely invalidated (not the same process, the lock is not the same object, so thread synchronization cannot be guaranteed regardless of the lock object or the lock global Class)
- Reduced reliability of Sharepreferences
- Application will be created multiple times (in application's OnCreate () printing the current process name confirms that the same app is under different processes and application is created multiple times. This also illustrates that in multi-process mode, components of different processes do have separate virtual machines, application, and memory space.
3. Serializable and Parcelable interface
Serializable and Parcelable can complete the serialization of an object, which needs to be serialized when we need to transfer data through intent and binder, and serializable is an empty interface provided by Java. Provides standard serialization and deserialization operations for objects. The use of simple but serialization and deserialization will do a lot of I/O Read and write operations, memory overhead.
Parcelable is a serialization method in Android that is slightly more complex to use, but highly efficient.
4. IPC Mode in Android:
4.1: using Bundles
Three of the four components (Activity, Service, Receiver) are supported to pass bundle data in intent, because the bundle implements the Parcelable interface, so it can be conveniently transferred between different processes.
4.2: using file sharing
File sharing is also a good way of inter-process communication, two of processes by reading and writing the same file to exchange data, such as a process to write data to a file, B process by reading this file to obtain data. However, this approach is also limited, such as the problem of concurrent read and write will cause the data we read is not up-to-date, so to avoid the occurrence of concurrent read or write, or consider using thread synchronization to limit the read and write operations of multiple threads. Based on this problem, file sharing is a good way to communicate between processes that require low data synchronization.
4.3: using Messenger
Messenger is a lightweight IPC scheme whose underlying implementation is Aidl, where messenger can pass message objects in different processes, and the data that we need to pass into the message can easily be passed between processes.
Messenger is simple to use because it processes a request at a time, so there is no problem with thread synchronization on the server. Messenger implementation of interprocess communication can be divided into the following steps, divided into the server and the client.
- Server-side processes
You first need to create a new service on the server to handle the client-initiated request, creating a handler and using it to create a Messenger object, and then returning the binder at the bottom of the Messenger object in the Services Onbind.
- Client process
In the client process, the service is bound to the server, and after the binding is successful, a messenger is created with the IBinder object returned by the server, through which Messenger can send a message of type messages to the server.
Register the service so that it runs in a separate process, configured in Androidmanifest.xml:
Log logs:
Data passing in Messenger must put the data in a message, and Messenger and message implement the Parcelable interface, so they can be transferred across processes. The above example only describes how to accept requests sent from the client on the server side, but sometimes it needs to respond to the client. Whenever a message is sent to the client, the server automatically replies with a "auto-reply from the server: Message received". If the customer needs to be able to respond to the client, then, like the server, the client needs to create a new Messenger and pass the Messenger object through the ReplyTo parameter of the message to the server. The server can respond to the client with this ReplyTo parameter.
Modified service-Side code:
Modified Client code:
4.4: using Aidl
Messenger is a serial processing of client requests, if there are a large number of requests sent to the server at the same time, the server can still only one processing, when Messenger is not appropriate, and the role of Messenger is to deliver messages, and can only pass the data type supported by the bundle, many times need to call the service-side method across processes, this time can be practical aidl to implement the cross-process method call. Aidl is also the underlying implementation of Messenger, so Messenger is inherently aidl, but the system is encapsulated. The practical aidl process of interprocess communication is divided into two aspects of service side and client, and the following are described below:
- Service side
The server will first create a service to listen to the client's connection request, then create a aidl file to expose the interface to the client in this aidl file, and finally implement the Aidl interface in the service
- Client
The client is going to do something a little simpler, first bind the service side of the server, bind the server back to the binder after the successful binding object to the type of the Aidl interface, and then you can call the method in Aidl
- Creation of the Aidl interface
Detailed reference: https://www.zhihu.com/question/21581761Note that if a custom Parcelable object is used in the Aidl file, you must create a new Aidl file with the same name and declare it as the parcelable type. We used the Bookentity class in the code above, so we had to create bookentity.aidl and then define bookentity as the parcelable type.
Run in standalone process:
<service Android:name= ". Service. Bookmanagerservice " android:process=" Com.ipc.example.remote "/>
This is a complete use of aidl to achieve interprocess communication, but far from complete, the complexity of aidl is much more than that.
Cond.....
Sample Link: Https://github.com/NullUsera/IPC
Android IPC mechanism full parse < one >