- 进程开头以:开头的是当前应用的私有进程,其他应用的无法与他跑在同一个进程中
- messgener 的底层实现方式为aidl的方式
- 调用方通过rpc调用远程请求会将当前线程进行挂起,一直等到服务端返回数据
- 服务端的binder方法是运行在binder的线程池中的,所以不管如何binder方法必须使用同步。
- 调用端binder调用的回调结果将会在当前线程中实现,服务端的binder实现是在binder的线程池中调用某个线程来实现的
- aidl文件不是实现binder的必需品可以由自己手写完成
- ibinder对象有一个linktodeath 设置服务端死亡代理等待服务端死亡回调
- 尽量避免进行进程间通信
- 进程间通信,使用bundle intent直接传递数据,使用文件进行通信(sp)、messenger、
-- sp的实现包含了缓存策略导致多进行读写会发生消息的不可靠问题
-- messager客服端可以接受来之服务器端的消息,只需要在sendmessage的时候讲客服端的messager设置在replyto 即可,相当于写信时将自己的地址告诉对方,希望对方按照这个地址回信,messager 是行
-- aidl中对象的跨进程传输本质上就是序列与反序列化的过程,貌似同一个对象其实在两个进程中是不同的对象,由于这个原因导致回调在方法在aidl中解绑会导致解绑失败,因为解绑的listener不是同一个对象,解决方案为使用remotecallbacklist,remotecallbacklist不是一个list,内部实现方式为arraymap,key为binder value为callback,beginBroadcost和finishbroadcost要配对使用,哪怕致死获取一个size
-- 避免在客服端的ui线程中调用binder的方法,避免anr同理,服务端也应该避免在ui线程中调用binder的方法,避免anr
-- binder将会意外死亡,有两种调用解决方案,第一种onservicedisconnected 和bindtodeth 这两个的区别在于回调的线程不同,一个在主线程,一个在binder线程池
contentprovider 的crud方法存在大量的多线程并发访问,需要做好线程同步
socket 中tcp和udp tcp本身提供了超时重传机制
binder pool 当有很多的aidl要求时,使用自定义binderpool 使用countdownlatch 将异步方法改为同步方法 在bindtodeath 断线重连机制