IPC机制---03 IPC基础概念介绍

• IPC基础概念包括三部分：Serializable Parcelable和Binder。前两者为序列号和反序列化接口，可以完成对象的序列化，通过Intent或Binder进行对象数据传递时，或将对象持久到设备上或通过网络传输给其他客户端时，需要实现这两个接口中的一个。

1. Serializable接口
   • java提供的序列化接口，是一个空接口，为对象提供标准的序列化和反序列化操作，实现相当简单。如下所示：
   • 
     
   • 其中，serialVersionUID也不是必须的，不声明这个同样可以实现序列化，只不过将对反序列化产生影响。
   • 通过ObjectOutputStream和ObjectInputStream可以实现对象的序列化和反序列化。反序列化后的对象与之前内容相同，但已不再是同一个对象。
   • serialVersionUID用来辅助系列化和反序列化过程的，原则上序列化后的数据中的serialVersionUID只有和当前类的serialVersionUID相同才能够正常被反序列化。
   • 工作原理：序列化的时候会把当前类的serialVersionUID写入序列化的文件中，当反序列化的时候系统回去检测当前类的serialVersionUID，比对是否一致，如果不一致，就会报错。
   • 一般情况下，我们应该手动指定serialVersionUID的值，比如1L，这样可以很大程度上避免反序列化的失败。
   • 注：静态变量属于类，不属于对象，不会参与序列化
2. Parcelable接口
   • Android提供的序列化接口，实现此接口，也可以通过Intent Binder进行数据传输。
   • Parce内部包装了可序列化的数据，可以在Binder中进行传输，反序列化通过CREATOR完成
   • 序列化通过writeToParcel完成
   • 与Serializable异同
   • • Serializable是java提供的序列化接口，使用简单，但是消耗大，序列化和反序列化都需要进行大量的IO操作
     • Parcelable是android提供的序列化方式，用起来稍微麻烦，不过AS上有工具自动生成，效率高，为android所推荐使用
3. Binder

• • 简介
  • • Android中的一个类，实现了IBinder接口
    • 从IPC角度来说，是进程间通讯的一种方式
    • 是一种虚拟物理设备，驱动为dev/binder，linux本身没有
    • 从AndroidFrame来讲，是连接Manager(ActivityManager)和相应ManagerService的桥梁
    • 从Android应用层来讲，是服务端和客户端进行通讯的媒介，当通过bindService后，服务端返回一个包含了服务端业务逻辑调用的Binder对象，通过这个Binder对象，客户端就可以调用服务端提供的服务和数据，包括普通服务和基于AIDL的服务
  • android开发中，Binder主要用于在Service中，包括AIDL和Messager，其中普通service中的Binder不牵扯线程间通信
  • 以p47为例，在gen目录下，系统根据aidl自动为我们生成java文件，他继承了IIterface接口，同时自己还是个接口
  • • 首先声明了getBookList和addBook两个方法，并且声明了两个整数类型的id来标识这两个方法，用于标识在transact过程中客户端所请求的到底是哪个方法
    • 声明内部类Stub，就是一个Binder，当客户端和服务端位于同一进程时，方法调用不会走跨进程的transact过程，而当两者位于不同进程时，方法调用需要走transact过程，这个逻辑有Stub的内部代理类Proxy来完成
    • 核心实现就是Stub和内部代理类Proxy
  • 字段及方法含义
  • • DESCRIPTOR
    • • Binder的唯一标识，一般用当前Binder的类名表示
    • asInterface
    • • 将服务端的Binder对象转换成客户端所需要的AIDL类型的对象，转换过程区分进程，如果是同一进程，返回Stub对象，反之，返回Stub.Proxy对象
    • asBinder
    • • 返回当前Binder对象
    • onTransact
    • • 运行在服务端的线程池中，当客户端发起跨进程请求时，远程系统会通过系统底层封装后交由此方法处理，接收四个参数，分别为code daye reply flags，服务端通过code确定客户端请求的哪个方法，然后从data中取出目标方法所需要的参数，然后执行目标方法，dang目标方法执行完成后，就想reply中写入数据，前提是又返回的话
      • 此方法返回false的话，说明客户端请求失败，可以利用这个特性来做权限验证
    • Proxy#getBookList
    • • 运行在客户端，当客户端远程调用此方法时，内部首先创建该方法所需要的输入对象data 输出对象reply和返回值对象List。然后调用transact方法来发起RPC(远程过程调用)请求，同时该线程挂起，然后服务端的onTransact方法被调起，直到RPC过程返回后，当前线程继续执行，并从reply中出去返回的数据
  • 扩展
  • • 明白了Binder的工作原理，我们完全可以不提供AIDL文件即可实现Binder，之所以提供是为了方便系统为我们生成代码。
    • AIDL的本质是系统为我们提供了一种快速实现Binder的工具，仅此而已
  • linkToDeath和unlinkToDeath
  • • Binder运行在服务端进程，如果服务端进行由于某种原因异常中止，Binder死亡，会导致我们的调用失败，如给我们再不知道已经断裂的话，就会影响到客户端的功能。 通过linkToDeath给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，就可以重新发起请求连接
    • 声明一个DeathRecipient对象，是一个接口，实现binderDied方法，当Binder死亡的时候，系统就会调用这个方法，