Android IPC（一）Serializable、Parcelable与Binder机制

开启多进程

AndroidMenifest.xml中给四大组件指定android:peocess属性。

  • 进程名以:开头的进程属于当前应用的私有进程，其他应用的组件不可以和它跑在同一个进程中。
  • 完整命名方式（全局进程），其他应用通过shareUID方式可以和它跑在同一进程中。

多进程产生的问题

  1. 静态成员和单例模式完全失效。
  2. 线程同步机制完全失效。
  3. SharePreferences的可靠性下降。
  4. Application会多次创建。

IPC基础

Serializable接口

Serializable是Java所提供的一个序列化接口，它是一个空接口，为对象提供标准的序列化和反序列化操作。

想让一个对象实现序列化，只需要实现Serializable接口并指明一个serialVersionUID即可，实际上，甚至这个serialVersionUID也不是必须的，我们不需要声明这个UID同样也可以实现序列化，但是这将会对反序列化过程产生影响，具体什么影响后面在介绍。

    public class User implements Serializable {
        private static final long serialVersionUID = XXXXL;
        ....
    }

通过Serializable方式来实现对象的序列化，实现起来非常简单，几乎所有的工作都被系统自动完成了。如何进行对象的序列化和反序列化也非常简单，只需要采用ObjectOutputStream和ObjectInputStream即可轻松实现。

    //序列化过程
    User user=new User(0,"amao",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(user);
    in.close();

serialVersionUID的意义

UID的详细工作机制是这样的：序列化的时候系统会把当前类的UID写入序列化的文件中（也可能是其他中介），当反序列化的时候系统会去检测文件中的UID，看它是否和当前类的UID一致，如果一致就说明序列化的类的版本和当前类的版本是相同的，这个时候可以反序列化成功；否则就说明当前类和序列化的类相比发生了某些变化，比如成员变量的数量，类型可能发生改变，这个时候无法正常序列化，回报UID不同的错误。

一般来说，我们应该手动指定UID的值，这样在序列化和反序列化是两者的UID是相同，可以正常的进行反序列化。如果不手动指定UID，当你增加或删除某些成员变量的时候，那么系统会重新计算当前类的hash值并把它赋予给UID，这个时候当前的UID就和反序列化的UID就不同了，于是反序列化失败，程序crash掉了，但指定了就不会crash。当然，如果类的结构发生的改变，比如修改了类名，修改了成语变量的类型，这个时候尽管UID是一致的，反序列化还是会失败，因为类的结构有毁灭性的改变，根本无法从来版本的数据中还原出一个新的类结构对象。

最后，以几两点需要特别提一下

  • 反序列化获取的对象与之前的对象数据完全一样，但是它们并不是同一个对象。
  • 静态成员变量属于类不属于对象，所以不参加序列化过程
  • 用transient关键字标记的成员变量不参与序列化过程。

Parcelable接口

Parcelable同样也是一个接口，通过Parcelable我们同样可以实现对象的序列化，而且远比Serializable高效，不够其过程就要复杂点了。


Parcelable

我们只要点击 Add Parcelable Implementation，AS会自动帮我们实现其方法，如下

public class Person implements Parcelable {

    private int id;
    private String name;
    private boolean sex;

    private Class cls;


    protected Person(Parcel in) {
        id = in.readInt();
        name = in.readString();
        sex = in.readByte() != 0;
        cls = in.readParcelable(Class.class.getClassLoader());
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeInt(id);
        dest.writeString(name);
        dest.writeByte((byte) (sex ? 1 : 0));
        dest.writeParcelable(cls, flags);
    }

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

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

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

Parcel内部包装了可序列化的数据，可在Binder中传输，在上面代码中，我们可以看出，序列化过程需要实现序列化、反序列化和内容描述。

  • writeToParcel完成序列化 ，通过Parcel的一系列write方法完成；

  • CREATOR完成反序列化，内部标明了如何创建序列化对象和数组，通过Parcel的一系列read方法来完成反序列过程；

  • describeContents完成内容描述，几乎所有的情况下都返回0，仅当当前对象中存在文件描述符时，该方法返回1。

  • 在Persion（Parcel in）中，因为Class是另外一个可序列化的对象，所以它的反序列化过程需要传递当前线程的上下文加载器，否则会报无法找到类的错误。

其实Android系统有很多实现了Parcelable接口的类，如Intent、Bundle、Bitmap等等，我们可以直接序列化它们，如果List和Map中的元素都是可序列化的，那List和Map也是可以序列化的。

Serializable和Parcelable的区别

最大的区别就是存储媒介的不同：
Serializable使用IO读写存储在硬盘上;
Parcelable是直接在内存中读写，内存的读写速度远大于IO读写，所以Parcelable高效。

  • 在使用内存时，Parcelable比Serializable性能高，推荐使用Parcelable;
  • Serializable在序列化时会产生大量的临时变量，会引起频繁的GC；
  • Parcelable不能使用在要将数据存储在磁盘上的情况，因为Parcleable不能很好的保证数据的持续性在外界有变化的情况下，尽管Serializable效率低点，也不提倡使用，但在这种情况下，还是建议使用Serializable。

Binder

Binder从不同角度上的定义：

  • 直观来说，Binder是Android中的一个类，它实现了IBinder接口；
  • 从IPC角度来说，Binder是Android中的一种跨进程通信方式，该通信方式在Linux中没有；
  • 从Android Framework角度来说，Binder是ServiceManager连接各种Manager和相应ManagerService的桥梁；
  • 从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据了。

Binder机制具体有两层含义：

  • Binder是一种跨进程通信（IPC，Inter-Process Communication）的手段；
  • Binder是一种远程过程调用（RPC，Remote Procedure Call）的手段。

Binder主要使用在Service中，包括AIDL和Messenger（Messenger的底层其实是AIDL）。

AIDL

AIDL：Android Interface Definition Language，安卓接口定义语言。

Android系统中的进程之间不能共享内存，因此，需要提供一些机制在不同进程之间进行数据通信。

通俗地讲，AIDL为我们提供一种快速实现Binder的工具。

AIDL文件代码如下：

// Book.aidl  
package com.cooffee.studypro.aidl;  
  
parcelable Book;  

// IBookManager.aidl  
package com.cooffee.studypro.aidl;  
  
import com.cooffee.studypro.aidl.Book;  
interface IBookManager {  
    List<Book> getBookList();  
    void addBook(in Book book);  
}

系统自动帮我们生成IBookManager接口的java代码文件(gen目录下)，代码结构如下：


interface IBookManager extends IInterface {  
      
        abstract class Stub implements IBookManager {  
            asInterface() {...};  
            asBinder() {...};  
            onTransact() {...};  
              
            abstract class Proxy implements IBookManager {  
                asBinder() {...};  
                getInterfaceDescriptor() {...};  
                getBookList() {...};  
                addBook() {...};  
            }  
        }  
      
    getBookList();  // 抽象方法  
    addBook();      // 抽象方法  
      
    // 两个方法标记ID的声明...  
}

IBookManager接口的核心是它的内部类Stub和Stub的内部代理类Proxy。
下面详细介绍针对这两个类的每个方法的定义：

  • DESCRIPTOR
    Binder的唯一标识，一般用当前Binder的类名标识，比如“com.example.aidl.IBookManager”。

  • asInterface(android.os.IBinder obj)将服务器端的Binder对象转换成客户端所需的AIDL接口类型的对象。

该转换过程是区分进程的：

如果客户端和服务端位于统一进程，此方法返回服务端的Stub对象本身；

否则返回的是系统封装的Stub.proxy对象。

  • asBinder()用于返回当前Binder对象。

  • onTransact()此方法运行在服务器端的Binder线程池，当客户端发起跨进程请求时，远程请求会通过系统低层封装后交由次方法来处理。

  • Proxy#getBookList:

此方法运行在客户端，当客户端远程调用此方法时，其内部实现如下：

  1. 创建该方法的输入型Parcel对象_data、输出型Parcel对象_reply和返回值对象List;
  2. 把该方法的参数信息写入_data（如果有参数）；
  3. 调用transact方法来发起RPC（远程过程调用）请求，同时当前线程挂起；
  4. 服务器端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果；
  5. 返回reply中的数据。
  • Proxy#addBook执行过程与getBookList过程相同，但是该方法没有返回值。

说明一下：

  1. 当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是耗时的，不能在UI线程发起此远程请求

  2. 由于服务端的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方式实现，因为它已经运行在一个线程中了。

Binder

Binder死亡代理

Binder运行在服务端进程中，如果服务端进程由于某种原因异常终止，这个时候我们到服务端的Binder连接断裂（称之为Binder死亡），会导致我们的远程调用失败。而且我们不知道Binder连接是什么时候断裂的，那么客户端的功能会受到影响。

Binder提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath我们可以为Binder设置一个死亡代理，当Binder死亡时，我们会收到通知，这个时候我们就可以重新发起连接请求从而恢复连接。

首先，声明一个DeathRecipient对象。DeathRecipient是一个接口，其内部只有一个方法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;  
        // TODO: 重新绑定远程service  
    }  
};

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

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

其中linkToDeath的第二个参数是个标记位，我们直接设为0即可。

另外，Binder的方法isBinderAlive也可以判断Binder是否死亡。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 201,924评论 5赞 474
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 84,781评论 2赞 378
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 148,813评论 0赞 335
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,264评论 1赞 272
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,273评论 5赞 363
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,383评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,800评论 3赞 393
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,482评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,673评论 1赞 295
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,497评论 2赞 318
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,545评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,240评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,802评论 3赞 304
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,866评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,101评论 1赞 258
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,673评论 2赞 348
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,245评论 2赞 341