android开发艺术探索笔记--第二章：IPC机制（上）

参考网址：Android开发艺术探索——第二章：IPC机制（上）

一.Android IPC简介

IPC是Inter-Process Communication的缩写，含义是进程间通信或者跨进程通信，是指两个进程间进行数据交互的一个过程。
线程：CPU调度的最小单元，是一种有限的系统资源。
进程：在PC和移动设备上指一个程序或者一个应用，可以包含多个线程。
Android里面主线程也叫UI线程，在UI线程里才能操作界面元素。
android中进程间通信方式：Binder、Socket
ContentProvider：也是进程间通信的一种，不过被系统封装了细节。

二.Android中的多进程模式

1.开启多进程模式

通过给四大组件指定android:process属性，我们可以轻易的开启多进程模式
我们无法给一个线程或者实体类指定其运行时所在的进程

除了在DDMS中可以查看进程，我们还可以通过shell命令来查看
adb shell ps 或者 adb shell ps | grep com.liuguilin.multiprocesssample
进程以”：“开头的属于当前应用的私有进程
进程名不以”：“开头的进程属于全局进程

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

2.多进程模式的运行机制

一般来说，使用多进程会造成如下几方面的问题：

• 1.静态成员和单例模式完全失效
• 2.线程同步机制完全失效。-----既然都不是一块内存了，那么不管是锁对象还是锁全局类都无法保证线程同步，因为不同进程锁都不是同一个对象。
• 3.SharedPreferences的可靠性下降。------SharedPreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，这是因为SharedPreferences底层是通过读/写XML文件来实现的，并发写显然是可能出问题的，甚至并发读/写都有可能出问题
• 4.Application会多次创建。-----运行在同一个进程中的组件是属于同一个虚拟机和同一个Application的，同理，运行在不同进程中的组件是属于两个不同的虚拟机和Application的

三.IPC基础概念

1.Serializable

实现Serializable 的方法如下：

1. implements Serializable ；
2. private static final long serialVersionUID = 8711368828010083044L;—这个开发者可以自己定义，或者eclipse生成；
   如果不定义serialVersionUID会有如下影响：
   1.对类的序列化没有影响，对类的反序列化有影响，可能会导致反序列化失败；
   2.反序列化失败后，程序会报crash
   以下两点需要特别提一下：
   首先静态成员变量属于类不属于对象，所以不会参与序列化过程；
   其次用transient关键字标记的成员变量不参与序列化过程；
   另外，系统的默认序列化过程也是可以改变的，通过实现如下 writeObject和readObject两个方法即可重写；

2.Parcelable

/**
 * Created by lgl on 16/9/24.
 */

public class User implements Parcelable {

public int userId;
public String userName;
public boolean isMale;

public Book book;

public User(int userId, String userName, boolean isMale) {
    this.userId = userId;
    this.userName = userName;
    this.isMale = isMale;
}


@Override
public int describeContents() {
    return 0;
}


@Override
public void writeToParcel(Parcel dest, int flags) {
    dest.writeInt(userId);
    dest.writeString(userName);
    dest.writeByte((byte) (isMale ? 1 : 0));
}


public static final Creator CREATOR = new Creator() {
    @Override
    public User createFromParcel(Parcel in) {
        return new User(in);
    }

    @Override
    public User[] newArray(int size) {
        return new User[size];
    }
};


protected User(Parcel in) {
    userId = in.readInt();
    userName = in.readString();
    isMale = in.readByte() != 0;
}

}

read方法来完成反序列化过程
序列化功能由writeToParcel方法来完成
内容描述功能由describeContents方法来完成，几乎在所有情况下这个方法都应该返回0，仅当当前对象中存在文件描述符时，此方法返回1。
List和Map也可以序列化，前提是它们里面的每个元素都是可以序列化
两者之间的区别：
Serializable是Java中的序列化接口，其使用起来简单但是开销很大，序列化和反序列化过程需要大量I/O操作。
而Parcelable是Andrord中的序列化方式，因此更适合用在Android平台上，它的缺点就是使用起来稍微麻烦点，但是它的效率很高，这是Android推荐的序列化方式，因此我们要首选Parcelatle
Parcelable主要用在内存序列化上，通过Parcelable将对象序列化到存储设备中或者将对象序列化后通过网络传输也都是可以的，但是这个过程会稍显复杂，因此在这两种情况下建议大家使用Serializabie.以上就是Parcelable和Serializable的区别。

3.Binder

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

/**
 * Created by lgl on 16/9/24.
 */
public class Book implements Parcelable {

public int bookId;
public String bookName;

public Book(int bookId, String bookName) {
this.bookId = bookId;
this.bookName = bookName;
}


protected Book(Parcel in) {
bookId = in.readInt();
bookName = in.readString();
}

@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(bookId);
dest.writeString(bookName);
}

@Override
public int describeContents() {
return 0;
}

public static final Creator CREATOR = new Creator() {
@Override
public Book createFromParcel(Parcel in) {
return new Book(in);
}

@Override
public Book[] newArray(int size) {
return new Book[size];
}
};
}

Book.aidl
// Book.aidl.aidl
package com.liuguilin.multiprocesssample;

// Declare any non-default types here with import statements

parcelable Book;

IBookManager.aidl

 // IBookManager.aidl
package com.liuguilin.multiprocesssample;

// Declare any non-default types here with import statements

interface IBookManager {

ListgetBookList();
void addBook(in Book book);
}

• DESCRIPTOR

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

• asInterface(android.os.IBinder obj)

用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的，如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy

• asBinder

此方法用于返回当前Binder对象

• onTransact

这个方法运行在服务端的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。该方法的原型为public Boolean onTransact (int code,android.os.Pareel data,android.os.Pareel reply,int fiags)，服务端通过code可以确定客户端所请求的目标方法是什么，接着从data中取出目标方法所需要的参数（如果目标方法中有参数的话），然后执行目标方法，当目标方法执行完毕后，就向reply中写入返回值（如果目标方法有返回值的话），onTransact方法的执行过程就是这样的。需要注意的是，如果此方法返回false,那么客户端的请求会失败，因此我们可以利用这个特性来做权限验证，毕竟我们也不希望随便一个进程都能远程调用我们的服务。

• Proxy#getBookList
• Proxy#addBook
  这个方法运行在客户端，当客户端远程调用此方法时，它的内部实现是这样的：首先创建该方法所需要的输入型Parcel对象_data、输出型Parcel对象_reply和返回值对象List然后把该方法的参数信息写入_data中（如果有参数的话)：接着调用transact方法来发起RPC（远程过程调用)请求，同时当前线程挂起；然后服务端的onTransact方法会被调用。直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果；最后返回_reply中的数据。

两点还是需要额外说明一下，首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务器进程返回数据，所以如果一个远程方法是很耗时的，那么不能再UI线程中发起此远程请求，其次，由于服务器的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该给出一个Binder的工作机制图

AIDL文件的本质是系统为我们提供了一种快速实现Binder的工具
可以手动实现Binder，不用AIDL参与
Binder中提供了两个配对的方法linkTopeath和unlinkTopeath，通过 linkToDeath我们可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，这个时候我们就可以重新发起连接请求从而恢复连接。
首先，声明一个Deathleciient对象、Deathleciient是一个接口，其内部只有一个方法binderDied，我们需要实现这个方法，当Binder死亡的时候，系统就会回调binderDied方法，然后我们就可以移出之前绑定的binder代理并重新绑定远程服务；

 private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {
        @Override
        public void binderDied() {
            if(mBookManager == null){
                return;
            }
            mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
            mBookManager = null;
            //这个可以重新绑定远程service
        }
    };

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

mService= IMessageBoxManager.Stub.asInterface(binder);
binder.linkToDeath(mDeathRecipient,0);

其次linkToDeath的第二个参数为标记位，我们直接设置为0即可；
另外。通过Binder的方法isBinderAlive也可以判断Binder是否死亡