Multiple processes in Android
- Expand the memory used by applications
Adb shell getProp Dalvik.vm. Heapsize Checks the current application memory limit
- Error-prone code can be thrown into a particular process so that a crash in a particular process does not cause all processes in the application to crash.
- push
Push requires message delivery across processes. Aurora push, in essence, is integrated with the push services of various operators. The aurora made a distribution inside.
Multi-process implementation
- binder
- socket
- The Shared memory
Android from security, performance, the final choice of binder. The performance is guaranteed by MMP.
MMP: Memory map. After the memory information of the client process is copied to the kernel, the memory address of the client and that of the server are stored in the same logical address through MMP.
Binader how to use
AIDL, binder, is quite complex to use, and Android provides AIDL to simplify the entire cross-process process for developers to escape trivial and complex syntax.
Application scenarios
- In a Service, a list is maintained and methods are exposed
addBook
Add data to the list. - The Client wants to display the number of lists in the Service.
The phenomenon of
If the service and client are in the same process, binder in onConnect is the binder returned in onBind in service.
onBind()) binder: com.aidldemo.MyService$1@27bd08d currentThread:Thread[main,5,main]
onServiceConnected: binder: com.aidldemo.MyService$1@27bd08d currentThread:Thread[main,5,main]
Copy the code
Binder onConnect in client is a different object than onBind in service if the service is set to a remote Process. The client is a proxy.
onBind()) binder: com.aidldemo.MyService$1@f3115ed currentThread:Thread[main,5,main]
onServiceConnected: binder: android.os.BinderProxy@7537253 currentThread:Thread[main,5,main]
Copy the code
Analysis of the
IBinder Binder’s onServiceConnected(CONNECTED) binder is a server’s interface binder if the service is connected to the binder. Otherwise return to Android.os.binderProxy.
Obviously, there is cross-process capability in BinderProxy.
Then perform IBookManager. Stub. AsInterface (binder) if it is the same process logic, directly through the binder binder logic from the server. If it is not a process, the BinderProxy is thrown into iBookManager.stub.proxy, where the cross-process capability of BinderProxy is utilized for cross-process operations. The addBook logic that I used to call addBook on the client side has been transferred to iBookManager.stub. Proxy.
private static class Proxy implements com.aidldemo.IBookManager { private android.os.IBinder mRemote; Proxy(android.os.IBinder remote) { mRemote = remote; } @Override public android.os.IBinder asBinder() { return mRemote; } public java.lang.String getInterfaceDescriptor() { return DESCRIPTOR; } ```` @Override public void addBook(com.aidldemo.Book book) throws android.os.RemoteException { android.os.Parcel _data = android.os.Parcel.obtain(); android.os.Parcel _reply = android.os.Parcel.obtain(); try { _data.writeInterfaceToken(DESCRIPTOR); if ((book ! = null)) { _data.writeInt(1); book.writeToParcel(_data, 0); } else { _data.writeInt(0); } boolean _status = mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0); if (! _status && getDefaultImpl() ! = null) { getDefaultImpl().addBook(book); return; } _reply.readException(); } finally { _reply.recycle(); _data.recycle(); }}}Copy the code
The above process helps us transfer the addBook process from the client side to the server side.