《Android 开发艺术探索》读后笔记 ---- 第二章

• 进程开头以：开头的是当前应用的私有进程，其他应用的无法与他跑在同一个进程中
• 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 断线重连机制