《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 断线重连机制