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

骑猪看日落 2022-08-20 02:26 207阅读 0赞

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

1.  Serializable接口
    
     *  java提供的序列化接口，是一个空接口，为对象提供标准的序列化和反序列化操作，实现相当简单。如下所示：
     *  ![Center][]  
        
     *  ![Image 1][]其中，serialVersionUID也不是必须的，不声明这个同样可以实现序列化，只不过将对反序列化产生影响。
     *  通过ObjectOutputStream和ObjectInputStream可以实现对象的序列化和反序列化。反序列化后的对象与之前内容相同，但已不再是同一个对象。
     *  serialVersionUID用来辅助系列化和反序列化过程的，原则上序列化后的数据中的serialVersionUID只有和当前类的serialVersionUID相同才能够正常被反序列化。
     *  工作原理：序列化的时候会把当前类的serialVersionUID写入序列化的文件中，当反序列化的时候系统回去检测当前类的serialVersionUID，比对是否一致，如果不一致，就会报错。
     *  一般情况下，我们应该手动指定serialVersionUID的值，比如1L，这样可以很大程度上避免反序列化的失败。
     *  注：静态变量属于类，不属于对象，不会参与序列化
2.  Parcelable接口
    
     *  Android提供的序列化接口，实现此接口，也可以通过Intent Binder进行数据传输。![Center 1][]
     *  ![Image 1][]Parce内部包装了可序列化的数据，可以在Binder中进行传输，反序列化通过CREATOR完成![Center 2][]
     *  ![Image 1][]序列化通过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死亡的时候，系统就会调用这个方法，

[Center]: /images/20220731/4345c1cedf294563acd49d50ec6b5fed.png
[Image 1]: 
[Center 1]: /images/20220731/68d96ee5ca814a03a0f9b8e4b77bf1c4.png
[Center 2]: /images/20220731/bbe5fc0527424b62bedd7c55974a63df.png