The process of the server may stop abnormally. At this time, the binder obtained by the client is invalid, so it is necessary to set a monitor for the obtained binder, that is, linkToDeath (an anonymous inner class that implements the interface); then call unlinkToDeath( ), after which service rebinding can be performed
When registering client listeners for the server, the Listener interface used by the client should be defined as an AIDL interface. Common interfaces cannot cross processes. The server collection uses RemoteCallBackList.
When the client calls the method of the server, the calling thread of the server is blocked. Pay attention to the processing in the non-UI thread. Similarly, when the server calls the update method of the client through the listener, it will also be blocked. The server should also call the non-UI thread.
Usually, when using AIDL to bind a service, because the service is cross-process, it is bindService instead of startService. The life cycle methods of the bound service are onCreate, onBind, onUnBind, onDestroy, and the life cycle depends on the context that initiates the binding. , and startService needs to call stopService, otherwise the service will not die unless the process stops
The principle of AIDL communication is roughly that if it is not cross-process, asInterface returns the binder instance itself (that is, the abstract class instance we implemented); if it is cross-process, it returns the internal proxy class instance proxy, and then when the corresponding method is called, in fact It is to first call onTransact to complete some initialization, then complete the object serialization and write to the memory, and then call the transact deserialization to restore the object, and then call the final method to complete the writing. If it is reading, the process is that transact reads and writes the sequence first. After the transact is executed in onTransact, it is deserialized and restored, and then the message is returned.
By the way, broadcast and the problem that non-UI threads cannot update the UI
In many programming, UI updates are single-threaded. It seems that multi-threading has the risk of potential deadlock, but it is not very clear. But imagine, assuming that multiple threads can update the UI, the screen will be spent, then synchronization must be performed, and the performance of a large number of synchronizations will definitely drop a lot at high concurrency.
As for why broadcasting does not recommend onRecive to start a thread, the reason is that broadcasting is "prosperity and annihilation". Once broadcasting is an independent process, then the process of broadcasting execution ends and the process dies, and the sub-threads owned will die even if the execution is not completed. But if the broadcast and the main thread are the same process, it is not impossible for him to start the child thread.
About Provider's grantUriPermission attribute
Using Provider, you can specify the access permissions as permission (global read and write), writePerission (write only), readPermission (read only). When accessing the provider, you must use use-permission to apply for permission. If there is an application that has not applied for it, what should you do if you want to access it? ? You can use grantUriPermission=true in the provider, and the default is false; it means that it is allowed to temporarily grant the corresponding permission to the visitor. Through Intent.setFlag, it is used when calling an application that accesses this provider with Intent, and granting the permission