IPC 机制（上）

IPC 机制.png

2.1 Android IPC 简介

IPC 是 Inter-Process Communication 的缩写，含义为进程间通信或者跨进程通信，是指两个进程之间进行数据交换的过程。IPC 不是 Android 中所独有的，任何一个操作系统都有响应的 IPC 机制。

2.2 Android 中的多进程模式

2.2.1 开启多进程模式

在Android中使用多进程只有一种方法，即给四大组件在 AndroidManifest 中指定 android:process 属性。

      
            
                ....

Android Studio 使用 adb 命令（使用 adb 命令需要先配置 adb 环境）查看进程

C:\Users\Administrator.KTS-20160106YSM\Desktop\Chapter5>adb shell ps
...
u0_a94    10485 1256  1407444 52272 SyS_epoll_ 00000000 S kjn.com.chapter5
u0_a94    10508 1256  1405248 50748 SyS_epoll_ 00000000 S kjn.com.chapter5:remote
u0_a94    10525 1256  1405496 52776 SyS_epoll_ 00000000 S kjn.com.chapter5.remote

上述代码有两种命名方式：

:remote： 冒号前面自动加上包名，属于当前应用的私有进程，其他组件不可以和它跑在同一个进程中。
包名.remote ：完整的命名方式，属于全局进程，其他应用通过 ShareUID 方式可以和它跑在同一个进程中。

我们知道 Android 系统会为每一个应用分配一个唯一的 UID，具有相同 UID 的应用才能共享数据，在这种情况下他们可以互相访问对方的似有数据，比如 data 目录、组件信息等。这里要说明的是，两个应用通过 UID 跑在同一个进程中是要求有相同是 ShareUID 和签名才行，跑在同一个进程中，他们还可以共享内存数据，或者说它们看起来就像是一个应用的两个部分。

2.2.2 多进程模式的运行机制
　　新建一个 UserManager 类，这类里只有一个静态成员变量

public class UserManager {
   public static int sUserId = 1;
}

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        UserManager.sUserId = 2;
        Log.d("MainActivity", "UserManage.sUserId=" + UserManager.sUserId);
    }

在 MianActivity 中改变 sUserId 为 2，然后跳转到 SecondActivity 中，并打印 sUserId 的值。

kjn.com.chapter2 D/MainActivity: UserManage.sUserId=2
kjn.com.chapter2:remote D/SecondActivity: UserManage.sUserId=1

上述问题出现的原因是 SecondActivity 运行在一个单独的进程中，Android 会为每一个进程应用分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间，这导致不同的虚拟机在访问同一个类的对象会产生多份副本，上面 UserManage 就是这种情况，在一个进程中修改 sUserId 只会影响当前进程。

所有运行不在不同进程中的四大组件，只要它们之间通过内存来共享数据，都会共享失败，这也是多进程带来的主要影响。一般来说，多进程会造成如下几个方面的问题：

（1）静态成员和单例模式完全失效。
就是上面这个案例。
（2）线程同步机制完全失效。
- 因为不在一块内存上，那么不管是锁对象还是锁全局类都无法包装线程同步，因为不同进程锁的不是同一个对象。
（3）SharedPreferences 的可靠性下降。
因为 SharedPreferences 不支持两个进程同时去执行操作，否则会导致一定几率的数据丢失，这是因为 SharedPreferences 底层是通过读写 XML 文件来实现的，并发写显然是可能出问题的，甚至并发读写都有可能出问题。
（4）Application 会多次创建。
因为当一个组件跑在一个新的进程中的时候，由于系统要在创建新的进程同事分配独立的虚拟机，所以这个过程相当于就是启动一个应用的过程，就会有两个 Application。

系统提供了很多跨进程通信方法，虽然说不能直接地共享内存，我们还可以使用 Intent 来传递数据，共享文件和 SharedPreferences ，基于 Binder 的 Messenger 和 AIDL 以及 Socekt 等等。

2.3 IPC 基础概念介绍

2.3.1 Serializable 接口
　　Serializable 是 Java所提供的一个序列化接口，它是一个空接口，为对象提供标准的序列化和反序列化操作。，具体实现可以参考以下代码：

    //序列化
    User user = new User(0, "jake", true);
    ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("cache.txt"));
    out.writeObject(user);
    out.close();
    //反序列化
    ObjectInputStream in = new ObjectInputStream(new FileInputStream("cache.txt"));
    User newUser = (User) in.readObject();
    in.close();

上述代码演示了采用 Serializable 方式序列化对象的典型过程，只需要把实现 Serializable 接口的 User 对象写到文件中就可以快速回复了，恢复之后的内容是完全一样的。

  private static final long serialVersionUID = 519067123721295773L;

serialVersionUID 的作用是：当序列化对比反序列的 serialVersionUID 一致的时候可以正常的反序列化。如果不指定，系统会计算当前类的 hash 值并赋值给 serialVersionUID，而当前类的有所改变，比如增加或者删除了某些成员变量，那么系统会重新计算当前类的 hash 值然后重新赋值给，反序列化失败这时候系统就会 crash。修改类名和成员变量类型，就算 serialVersionUID 通过了，一样会失败。

尽量手动指定 serialVersionUID （比如 1 L）或者工具按当前目录结构自动生成。

静态成员变量属于类不属于对象，所以不会参与序列化过程
其次用 transient 关键字标记的成员变量不参与序列化过程

2.3.2 Parcelable 接口

Parcel 内部包装了可序列化的数据，可以在 Binder 中自由的传递。序列化功能由 writeToParcel 方法来完成，反序列化功能由 CREATOR 来完成，其内部标明了如何创建序列化对象和数组；内容描述功能由 describeContents 方法来完成。

Parcelable 的方法说明

方法	功能	标记位
createFromParce l (Parcel in)	从序列化后的对象中创建原始对象
newArray(int size)	创建指定长度的原始对象数组
User(Parcel in)	从序列化后的对象中创建原始对象
writeToParcel(Parcel out, int flags)	将当前对象写入序列化结构中，其中 flags 标识有两种值：0或者 1（参见右侧标记位）。为 1 时标识当前对象需要作为返回值返回，不能立即释放资源，几乎所有情况都为 0	PARCELABLE_WRITE_REYURN_VALUE
describeContents()	返回当前对象的内容描述，如果含有文件描述符，返回 1（参见右侧标记），否则返回 0，几乎所有情况都返回 0	CONTENTS_FILE_DESCRIPTOR

Intent、Bundle、Bitmap 等都实现了 Parcelable 接口都可以直接序列化，同时 List 和 map 也可以序列化，前提它们里面每个元素都是可序列化的。

Serializable 是 java 中的序列化接口，使用起来简单但是开销大，序列化和反序列化过程需要大量 I/O 操作。
Parcelable 是Android 的序列化方式，因此适合用在 Android 平台上，缺点是使用起来稍微麻烦，但是它的效率高，因此我们首选 Parcelable。

Parcelable 和 Serializable 都是实现序列化并且都可以用于 Intent 间的数据传递。Parcelable 主要用于内存序列化上，通过 Parcelable 将对象序列化到存储设备中或者将对象序列化后通过网络传输，但这个过程会稍显复杂，因此这两种情况建议大家适用 Serializable 。

2.3.3 Binder

实现 IBinder 接口，主要应用在 Service 中，是客户端和服务端进行通信的媒介，服务端向客户端返回实现了业务接口的 Binder 对象（Service 的 onBind 方法）
是 Android 中一种跨进程通信的方式
可以理解成一个虚拟物理设备，设备驱动为 /dev/binder ?? 此处不理解...
是连接各种 Manager(ActivityManager，WindowManager 等)和相应的 ManagerService 的桥梁

AIDL

AIDL 的流程：

创建一个 Service 和一个 AIDL 接口；
创建一个类继承自 AIDL 接口中的 Stub 类并实现抽象方法
在 Service 的 onBind 方法中返回这个类的对象
客户端绑定服务端 Service，建立链接就可以访问远程服务端的方法了。

AIDL 作为接口定义文件，与普通的接口定义方法有些许不同，然而大致是类似的。

AIDL 支持的类型

基本数据类型
String 和 CharSequence
实现了 Parcelable 接口的对象
AIDL 接口本身的类型
对于集合，AIDL 仅支持两种类型
- ArrayList，且里面的每个元素必须被 AIDL 支持
- HashMap，且里面的每个 key和 value 必须被 AIDL 支持

如果在 AIDL 文件中出现了定义的 Parcelable 对象，需要新建一个与之同名的 AIDL 文件，并声明为 parcelable 类型。

package *.*.*;
parcelable Something;

3.定义业务接口，AIDL 中除了基本类型都要标识方向：in/out/inout，只支持方法，不支持静态常量。

package *.*;
import *.Something; // 即便处于同一个包下，也要 import 语句

interface ISomeManager {

 List getSomethingList();
 void doSomething(in Something sth); 
}

源码分析

Android 开发中，Binder 主要用在 Service 中，包括 AIDL 和 Messager，其中普通 Service中的 Binder 不涉及进程间通信，无法触及 Binder 的核心，而 Messager 的底层其实是 AIDL，所以这里选择用 AIDL 来分析 Binder 的工作机制。

源码链接

image.png

AIDL 类似一个接口类，通过 build 一下 project，构建工具（build-tools 文中的 aidl.exe 程序）会编译出一个类，在 build/generated/source/aidl/debug/ 的路径下，我们找到了 AIDL 文件生成的类 IBookManager.java，下面我们就来阅读这些源码，来一窥究竟。

image.png

public interface IBookManager extends android.os.IInterface {
     public static abstract class Stub extends android.os.Binder implements com.ryg.chapter_2.aidl.IBookManager {
...

代码很长，直接看目录结构（ ctrl + 7 ）

image.png

DESCRIPTOP 是 Binder 的唯一标识，一般用当前 Binder 的类名表示。

 private static final java.lang.String DESCRIPTOR = "com.ryg.chapter_2.aidl.IBookManager";

这里的 Stub 类就是我们要关注的地方，因为它就是 AIDL 的实现类：
首先看它的 asInterface 方法，因为我们要在 ServiceConnection 连接成功后，根据此方法将服务器返回的 Binder 转换为远程业务接口：

 public static com.ryg.chapter_2.aidl.IBookManager asInterface(android.os.IBinder obj) {
            if ((obj == null)) {
                return null;
            }
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
            if (((iin != null) && (iin instanceof com.ryg.chapter_2.aidl.IBookManager))) {
                return ((com.ryg.chapter_2.aidl.IBookManager) iin);
            }
            return new com.ryg.chapter_2.aidl.IBookManager.Stub.Proxy(obj);
        }

语意很清晰，首先拿一个字符串（接口类全名）到本地进程查询（queryLocalInterface），查询不到则说明这是一个跨进程调用；这里运用到了代理模式（Proxy），因为是跨进程，就需要额外的步骤，就是将请求参数和返回值序列化的过程，而单进程就不需要这个步骤了：

@Override
public void addBook(com.ryg.chapter_2.aidl.Book book) 
        throws android.os.RemoteException {
    android.os.Parcel _data = android.os.Parcel.obtain();
    android.os.Parcel _reply = android.os.Parcel.obtain();
    try {
        _data.writeInterfaceToken(DESCRIPTOR);
        if ((book != null)) {
            _data.writeInt(1);
            book.writeToParcel(_data, 0);
        } else {
            _data.writeInt(0);
        }
         /**
           * 客户端发起请求，当前线程阻塞等待返回
           * 所以请求远程服务尽量不要在 UI 线程上发起
           */
        mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0);
        /** 
          * 客户端请求发送出去后
          * 远程请求通过底层封装后回调服务端的 Binder 的 onTransact 方法进行处理
          */
        _reply.readException();
    } finally {
        _reply.recycle();
        _data.recycle();
    }
}

在 public Boolean onTransact(int code，Parcelable data，Parcelable reply，int flags) 方法中，服务端通过 code 知道客户端请求的目标方法，从data中取出所需的参数，调用对应的业务方法，执行完毕后将结果写入到 reply 中。返回 true 意味着请求成功。利用这个特性可以做验证是否有权限调用该服务，见 BookManagerService：

public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
        throws RemoteException {
    // 检测清单是否声明了以下权限
    int check = checkCallingOrSelfPermission(
        "com.ryg.chapter_2.permission.ACCESS_BOOK_SERVICE");
    Log.d(TAG, "check=" + check);
    if (check == PackageManager.PERMISSION_DENIED) {
        return false;
    }
    // 检查应用包名是否以 "com.ryg" 开头
    String packageName = null;
    String[] packages = getPackageManager().getPackagesForUid(
            getCallingUid());
    if (packages != null && packages.length > 0) {
        packageName = packages[0];
    }
    Log.d(TAG, "onTransact: " + packageName);
    if (!packageName.startsWith("com.ryg")) {
        return false;
    }

    return super.onTransact(code, data, reply, flags);
}

清单中定义权限

当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以若果一个远程方法是很耗时的，那么不能在 UI 线程中发起此远程请求；
其次，由于服务端的 Binder 方法运行在 Binder 的线程池中，所以 Binder 方法不管是否耗时都应该采用同步的方式去实现，因为它已经运行在一个线程中了。

Binder 的工作机制

其实我们完全可以不提供 AIDL 文件即可实现 Binder，之所以提供 AIDL 文件，是为了方便系统为我们生产代码，系统根据 AIDL 文件生成 Java 文件的格式是固定的。

Binder两种重要的方法 linkToDeath 和 unlinkToDeath

Binder运行在服务端，如果由于某种服务端异常终止了的话会导致客户端的远程调用失败、所以Binder提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath方法可以给Binder设置一个死亡代理，当Binder死亡的时候客户端就会收到通知，然后就可以重新发起连接从而恢复连接了。

如何给Binder设置死亡代理
1、声明一个DeathRecipient对象、DeathRecipient是一个接口，其内部只有一个方法bindDied，实现这个方法就可以在Binder死亡的时候收到通知了。

private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {
    @Override
    public void binderDied() {
        if (mRemoteBookManager == null) return;
        mRemoteBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0);
        mRemoteBookManager = null;
        // TODO:这里重新绑定远程Service
    }
};

2、在客户端绑定远程服务成功之后，给binder设置死亡代理

mRemoteBookManager.asBinder().linkToDeath(mDeathRecipient, 0);

IPC 机制（上）

2.1 Android IPC 简介

2.2 Android 中的多进程模式

2.3 IPC 基础概念介绍

2.3.3 Binder

AIDL

源码分析

Binder两种重要的方法 linkToDeath 和 unlinkToDeath

你可能感兴趣的:(IPC 机制（上）)