Android IPC机制(进程间通信)

一、 什么是IPC?

IPC,全称Inter-Process Communication,字面意思就是进程间通信或者跨进程通信。那什么是进程呢?它和线程有什么暧昧的关系?
进程是系统进行资源分配和调度的基本单位,是操作系统结构的基础;早期表现为一个程序,现在可以看作线程的容器。线程是CPU调度的最小单位。�一个进程可以包含一个或者多个线程,进程向系统申请资源,线程使用进程拥有的资源。
IPC不是Android所独有的,是现代操作系统都存在的机制,对于Android来说。它是一种基于Linux内核的移动OS,他的进程通信方式不仅仅包含信号量、套接字、管道等等,还包括了Android独有的、特色的Binder机制。

二、 为什么需要多进程?应用场景...

谈到IPC的使用场景就必须提到多进程,只有面对多进程这种场景下,才需要考虑多进程通信,这是很好理解的。至于一个应用使用多进程的原因,这个可能很多,辟如有些模块由于特殊原因需要运行在独立的进程;又或者为了加大一个应用可使用的内存,通过多进程的方式申请多份内存空间。还有一个情况需要使用IPC,那就是多个应用之间进行数据共享,使用ContentProvider去查询数据时也是一种进程通讯,只是对我们来说透明化了,无法感知到。

三、 Android如何开启多进程模式?

我们可以通过给四大组件在AndroidMenifest.xml指定指定 android:process属性,亦或是在JNI层fork一个新进程,别无他法,过程看似轻松简单,却暗藏杀机,如何抵消多进程带来的负面影响?

这里有个示例:

<activity
         android:name="com.ryg.chapter_2.MainActivity"
         android:configChanges="orientation|screenSize"
         android:label="@string/app_name"
         android:launchMode="standard" >
        <intent-filter>
                <action  android:name="android.intent.action.MAIN"  />
                <category  android:name="android.intent.category.LAUNCHER"  />
         </intent-filter>
     </activity
    <activity
         android:name="com.ryg.chapter_2.SecondActivity"
         android:configChanges="screenLayout"
         android:label="@string/app_name"
         android:process=":remote"  />
    <activity
         android:name="com.ryg.chapter_2.ThirdActivity"
         android:configChanges="screenLayout"
         android:label="@string/app_name"
         android:process="com.ryg.chapter_2.remote"  /> 

眼尖的人都发现了两个android:process属性的值不一样,这意味在他们会在3个不同进程内运行。通过DDMS或者命令adb shell ps 观察。进程名看起来没有什么区别,其实它们是有区别的,进程名以“:”开头的进程会属于当前应用的私有进程,其他应用组件不能通过shareUID的方式让其在同一进程中运行,相反,就是全局进程,可以被共享。
ShareUID的方式需要两个应用拥有相同的UID以及相同的签名才可以,在这种情况下,不管他们是否跑在统一进程,他们可以互相访问对方的私有数据,譬如data目录、组件信息等等,如果是的话,那么它们还能共享内存数据,看起来就是一个应用的不同部分。

四、 奇怪现象(哎呀,奇怪了。这个值怎么变了~)

有的Android开发者会选择在Application或者静态类中储存可变的属性,静态亦或是非静态的,当你开启多进程模式,你会发现你的世界不再简单如旧。

一般来说,使用多进程会造成如下几方面的问题:
**(1) 静态成员和单例模式完全失效。 **
**(2) 线程同步机制完全失效。 **
**(3) SharedPreferences 的可靠性下降。 **
(4) Application会多次创建。

我们知道Android为每一个应用分配了一个独立的虚拟机,或者说为每个进程都分配一个独立的虚拟机,不同的虚拟机在内存分配上有不同的地址空间,这就导致在不同的虚拟机中访问同一个类的对象会产生多份副本。既然不是同一块内存了,那就算是使用了进程锁也会失效,因为进程锁也是不同内存对象。SharedPreferences虽然最终写入XML文件,但也有利用内存机制进行加速,在不同进程下,并发写入,也会出现问题。在开启多进程模式下,一般认为Application是程序的入口而不应该变化,但可以通过打印进程名称,得知Application会启动多次,因此用于存储公共信息并不可靠。

五、 IPC基础概念

Serializable接口、Parcelable接口以及Binder,只有熟悉这三方面的内容后,我们才能更好地理解跨进程通信的各种方式。Serializable和Parcelable接口可以完成对象的序列化过程,当我们需要通过Intent和Binder传输数据时就需要使用Parcelable或者Serializable。

1.如何使用Serializable来完成对象的序列化。

想让一个对象实现序列化,只需要这个类实现Serializable接口并声明一个serialVersionUID即可,实现起来非常简单,几乎所有工作都被系统自动完成了。如何进行对象的序列化和反序列化也非常简单,只需要采用ObjectOutputStream和ObjectInputStream即可轻松实现。

/**
 * @ClassName ObjectUtil
 * @Description 对可序列对象BASE64字符串化
 * @author K.W.
 * @date 2013年9月19日 上午2:10:53
 */
public class ObjectUtil {
    public static String getBASE64String(Object obj) {
        if(obj==null){
            return null;
        }
        ByteArrayOutputStream toByte = new ByteArrayOutputStream();
        ObjectOutputStream oos;
        try {
            oos = new ObjectOutputStream(toByte);
            oos.writeObject(obj);
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        // 对byte[]进行Base64编码
        return Base64.encode(toByte.toByteArray());
    }
    
    public static Object getObject(String base64String) {
        byte[] base64Bytes;
        try {
            base64Bytes = Base64.decodeToByteArray(base64String);
            ByteArrayInputStream bais = new ByteArrayInputStream(base64Bytes);
            ObjectInputStream ois = new ObjectInputStream(bais);
            return ois.readObject();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return null;
    }
}

2.Android中如何使用Parcelable进行序列化操作

Parcelable 方法说明

Implements Parcelable的时候需要实现内部的方法:

1).writeToParcel 将对象数据序列化成一个Parcel对象(序列化之后成为Parcel对象.以便Parcel容器取出数据)

2).重写describeContents方法,默认值为0

3).Public static final Parcelable.Creator<T>CREATOR (将Parcel容器中的数据转换成对象数据) 同时需要实现两个方法:
  3.1 CreateFromParcel(从Parcel容器中取出数据并进行转换.)
  3.2 newArray(int size)返回对象数据的大小

public class Book implements Parcelable{
 private String bookName;
 private String author;
 private int publishDate;
  
 public Book(){
   
 }
  
 public String getBookName(){
  return bookName;
 }
  
 public void setBookName(String bookName){
  this.bookName = bookName;
 }
  
 public String getAuthor(){
  return author;
 }
  
 public void setAuthor(String author){
  this.author = author;
 }
  
 public int getPublishDate(){
  return publishDate;
 }
  
 public void setPublishDate(int publishDate){
  this.publishDate = publishDate;
 }
  
 @Override
 public int describeContents(){
  return 0;
 }
  
 @Override
 public void writeToParcel(Parcel out, int flags){
  out.writeString(bookName);
  out.writeString(author);
  out.writeInt(publishDate);
 }
  
 public static final Parcelable.Creator<Book> CREATOR = new Creator<Book>(){
   
     @Override
  public Book[] newArray(int size){
   return new Book[size];
  }
   
  @Override
  public Book createFromParcel(Parcel in){
   return new Book(in);
  }
 };
  
 public Book(Parcel in){
  //如果元素数据是list类型的时候需要: lits = new ArrayList<?> in.readList(list); 
  //否则会出现空指针异常.并且读出和写入的数据类型必须相同.如果不想对部分关键字进行序列化,可以使用transient关键字来修饰以及static修饰.
  bookName = in.readString();
  author = in.readString();
  publishDate = in.readInt();
 }
}

3.Parcelable与Serializable的性能比较

首先Parcelable的性能要强于Serializable的原因我需要简单的阐述一下

1). 在内存的使用中,前者在性能方面要强于后者

2). 后者在序列化操作的时候会产生大量的临时变量,(原因是使用了反射机制)从而导致GC的频繁调用,因此在性能上会稍微逊色

3). Parcelable是以Ibinder作为信息载体的.在内存上的开销比较小,因此在内存之间进行数据传递的时候,Android推荐使用Parcelable,既然是内存方面比价有优势,那么自然就要优先选择.

4). 在读写数据的时候,Parcelable是在内存中直接进行读写,而Serializable是通过使用IO流的形式将数据读写入在硬盘上.

但是:虽然Parcelable的性能要强于Serializable,但是仍然有特殊的情况需要使用Serializable,而不去使用Parcelable,因为Parcelable无法将数据进行持久化,因此在将数据保存在磁盘的时候,仍然需要使用后者,因为前者无法很好的将数据进行持久化.(原因是在不同的Android版本当中,Parcelable可能会不同,因此数据的持久化方面仍然是使用Serializable)

六、 Binder (AIDL)

Binder 是一个可以很深入的话题,这里不打算深入探究Binder的内部。Android 开发中,Binder主要使用在Service中,包括AIDL和Messager。
我们来新建一个AIDL,体验下这个过程,还是以上面的BOOK为例子,首先建两个aidl文件:Book.aidl、IBookManager.aidl。

// Book.aidl
package com.ajb.kotlintest;
parcelable Book ;

// IBookManager.aidl
package com.ajb.kotlintest;

// Declare any non-default types here with import statements
import com.ajb.kotlintest.Book;
interface IBookManager {
    List<Book> getBookList();
    void addBook(in Book book);
}

build一下就有了java类文件。

package com.ajb.kotlintest;

public interface IBookManager extends android.os.IInterface {
    /**
     * Local-side IPC implementation stub class.
     */
    public static abstract class Stub extends android.os.Binder implements com.ajb.kotlintest.IBookManager {
        private static final java.lang.String DESCRIPTOR = "com.ajb.kotlintest.IBookManager";

        /**
         * Construct the stub at attach it to the interface.
         */
        public Stub() {
            this.attachInterface(this, DESCRIPTOR);
        }

        /**
         * Cast an IBinder object into an com.ajb.kotlintest.IBookManager interface,
         * generating a proxy if needed.
         */
        public static com.ajb.kotlintest.IBookManager asInterface(android.os.IBinder obj) {
            if ((obj == null)) {
                return null;
            }
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
            if (((iin != null) && (iin instanceof com.ajb.kotlintest.IBookManager))) {
                return ((com.ajb.kotlintest.IBookManager) iin);
            }
            return new com.ajb.kotlintest.IBookManager.Stub.Proxy(obj);
        }

        @Override
        public android.os.IBinder asBinder() {
            return this;
        }

        @Override
        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
            switch (code) {
                case INTERFACE_TRANSACTION: {
                    reply.writeString(DESCRIPTOR);
                    return true;
                }
                case TRANSACTION_getBookList: {
                    data.enforceInterface(DESCRIPTOR);
                    java.util.List<com.ajb.kotlintest.Book> _result = this.getBookList();
                    reply.writeNoException();
                    reply.writeTypedList(_result);
                    return true;
                }
                case TRANSACTION_addBook: {
                    data.enforceInterface(DESCRIPTOR);
                    com.ajb.kotlintest.Book _arg0;
                    if ((0 != data.readInt())) {
                        _arg0 = com.ajb.kotlintest.Book.CREATOR.createFromParcel(data);
                    } else {
                        _arg0 = null;
                    }
                    this.addBook(_arg0);
                    reply.writeNoException();
                    return true;
                }
            }
            return super.onTransact(code, data, reply, flags);
        }

        private static class Proxy implements com.ajb.kotlintest.IBookManager {
            private android.os.IBinder mRemote;

            Proxy(android.os.IBinder remote) {
                mRemote = remote;
            }

            @Override
            public android.os.IBinder asBinder() {
                return mRemote;
            }

            public java.lang.String getInterfaceDescriptor() {
                return DESCRIPTOR;
            }

            @Override
            public java.util.List<com.ajb.kotlintest.Book> getBookList() throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                java.util.List<com.ajb.kotlintest.Book> _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    mRemote.transact(Stub.TRANSACTION_getBookList, _data, _reply, 0);
                    _reply.readException();
                    _result = _reply.createTypedArrayList(com.ajb.kotlintest.Book.CREATOR);
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
            }

            @Override
            public void addBook(com.ajb.kotlintest.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);
                    }
                    mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0);
                    _reply.readException();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
            }
        }

        static final int TRANSACTION_getBookList = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
        static final int TRANSACTION_addBook = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
    }

    public java.util.List<com.ajb.kotlintest.Book> getBookList() throws android.os.RemoteException;

    public void addBook(com.ajb.kotlintest.Book book) throws android.os.RemoteException;
}

上述代码是系统生成的,它继承了IInterface这个接口,同时它自己也还是个接口,所有可以在Binder中传输的接口都需要继承IInterface接口。首先,它声明了两个方法getBookList和addBook,显然这就是我们在IBookManager.aidl中所声明的方法,同时它还声明了两个整型的id分别用于标识这两个方法,这两个id用于标识在transact过程中客户端所请求的到底是哪个方法。接着,它声明了一个内部类Stub,这个Stub就是一个Binder类,当客户端和服务端都位于同一个进程时,方法调用不会走跨进程的transact过程,而当两者位于不同进程时,方法调用需要走transact过程,这个逻辑由Stub的内部代理类Proxy来完成。这么来看,IBookManager这个接口的确很简单,但是我们也应该认识到,这个接口的核心实现就是它的内部类Stub和Stub的内部代理类Proxy,下面详细介绍针对这两个类的每个方法的含义。

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

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

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

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

Proxy#addBook
这个方法运行在客户端,它的执行过程和getBookList是一样的,addBook没有返回值,所以它不需要从_reply中取出返回值。

在服务端需要创建一个 BookManagerImpl 的对象并在 Service 的 onBind 方法中返回即可。以下就是一个服务端的典型实现。

//服务器端
public class CustomService extends Service {
    private List<Book> mBookList;

    public CustomService() {

    }

    @Override
    public IBinder onBind(Intent intent) {
        return new BookManagerImpl();
    }

    private class BookManagerImpl extends IBookManager.Stub {
        @Override
        public List<Book> getBookList() throws RemoteException {
            synchronized (mBookList) {
                return mBookList;
            }
        }

        @Override
        public void addBook(Book book) throws RemoteException {
            synchronized (mBookList) {
                if (!mBookList.contains(book)) {
                    mBookList.add(book);
                }
            }
        }

        @Override
        public void linkToDeath(DeathRecipient recipient, int flags) {
            super.linkToDeath(recipient, flags);
        }

        @Override
        public boolean unlinkToDeath(DeathRecipient recipient, int flags) {
            return super.unlinkToDeath(recipient, flags);
        }
    }
}

Binder有两个很重要的方法linkToDeath和unlinkToDeath。

Binder运行在服务端进程,如果服务端进程由于某种原因异常终止,这个时候我们到服务端的Binder连接断裂(称之为Binder死亡),会导致我们的远程调用失败。更为关键的是,如果我们不知道Binder连接已经断裂,那么客户端的功能就会受到影响。

为了解决这个问题,Binder中提供了两个配对的方法linkToDeath和unlinkToDeath,通过linkToDeath我们可以给Binder设置一个死亡代理,当Binder死亡时,我们就会收到通知,这个时候我们就可以重新发起连接请求从而恢复连接。那么到底如何给Binder设置死亡代理呢?也很简单。

首先,声明一个DeathRecipient对象。DeathRecipient是一个接口,其内部只有一个方法binderDied,我们需要实现这个方法,当Binder死亡的时候,系统就会回调binderDied方法,然后我们就可以移出之前绑定的binder代理并重新绑定远程服务。

//客户端(Activity)内
        private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {  
  
        @Override  
        public void binderDied() {  
            // TODO Auto-generated method stub  
            if (mBookManager == null)  
                return;  
            mBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0);  
            mBookManager = null;  
            // TODO:重新绑定远程服务
       bindService(new Intent("com.ajb.kotlintest.CustomService").
          setPackage("com.ajb.kotlintest"), conn, BIND_AUTO_CREATE);  


        }  
    };  
      
    private ServiceConnection conn = new ServiceConnection() {  
  
        @Override  
        public void onServiceDisconnected(ComponentName name) {  
  
        }  
  
        @Override  
        public void onServiceConnected(ComponentName name, IBinder service) {  
            mBookManager = IBookManager.Stub.asInterface(service);  
            try {  
                service.linkToDeath(mDeathRecipient, 0);  
                Toast.makeText(getApplicationContext(), mBookManager.getName(),  
                        Toast.LENGTH_LONG).show();  
            } catch (RemoteException e) {  
                // TODO Auto-generated catch block  
                e.printStackTrace();  
            }  
        }  
    }; 
//然后在onCreate先bindService一次,由上面处理重绑。

这样我们就能简单的传递信息了,但是这其中还有一些坑我们没遇到过,通过IBinder在服务端与客户端之间传递自定义对象,自定义对象需要实现Parcelable接口,就是说他们是在序列化和反序列化之间运作,服务端与客户端之间传递的对象并不是同一个对象。

5.Listener 在Binder中使用

虽然说多次,跨进程传输客户端的对象会在服务端生成不同的对象,但是生成的对象有一个共同点,就是它们底层的Binder对象是同一个,RemoteCallbackList利用这一特性,在解除注册Listener时,找到和注册时一样Binder对象的listener进行删除。RemoteCallbackList 当客户端死亡,它自动解除客户端持有的 listener,而且由于其线程同步的特性,不需要额外的线程同步工作。

添加注册和解注册的办法。

// IBookManager.aidl
package com.ajb.kotlintest;

// Declare any non-default types here with import statements
import com.ajb.kotlintest.Book;
interface IBookManager {
    List<Book> getBookList();
    void addBook(in Book book);
    void registerListener( IOnNewBookArrivedListener listener);
    void unregisterListener( IOnNewBookArrivedListener listener);
}

在Service中,添加相关实现代码

private RemoteCallbackList< IOnNewBookArrivedListener> mListenerList = new RemoteCallbackList< IOnNewBookArrivedListener>(); 

@Override 
public void registerListener( IOnNewBookArrivedListener listener) 
                                           throws RemoteException {
    mListenerList. register( listener);
 }

@Override 
public void unregisterListener( IOnNewBookArrivedListener listener) 
                                           throws RemoteException { 
    mListenerList. unregister( listener); 
};

利用这些就可以在新书到来之时,通知需要知道的监听者,不需要时就解除注册即可。

七、 ContentProvider

创建一个自定义的ContentProvider很简单,只需要继承ContentProvider类并实现六个抽象方法即可:onCreate、query、update、insert、delete和getType。

onCreate
代表ContentProvider的创建,一般来说我们需要做一些初始化工作;

getType
用来返回一个Uri请求所对应的MIME类型(媒体类型),比如图片、视频等,这个媒体类型还是有点复杂的,如果我们的应用不关注这个选项,可以直接在这个方法中返回null或者** “ */* ” **;Android系统所提供的MediaStore功能就是文件类型的ContentProvider,详细实现可以参考MediaStore。

query、update、insert、delete
剩下的四个方法对应于CRUD操作,即实现对数据表的增删改查功能。

根据Binder的工作原理,我们知道这六个方法均运行在ContentProvider的进程中,除了onCreate由系统回调并运行在主线程里,其他五个方法均由外界回调并运行在Binder线程池中。

// DbOpenHelper. java 
public class DbOpenHelper extends SQLiteOpenHelper {
    private static final String DB_NAME = "book_provider. db";
    public static final String BOOK_TABLE_NAME = "book";
    public static final String USER_TALBE_NAME = "user";
    private static final int DB_VERSION = 1; // 图书和用户信息表
    private String CREATE_BOOK_TABLE = "CREATE TABLE IF NOT EXISTS " + BOOK_TABLE_NAME + "(_id INTEGER PRIMARY KEY," + "name TEXT)";
    private String CREATE_USER_TABLE = "CREATE TABLE IF NOT EXISTS " + USER_TALBE_NAME + "(_id INTEGER PRIMARY KEY," + "name TEXT," + "sex INT)";

    public DbOpenHelper(Context context) {
        super(context, DB_NAME, null, DB_VERSION);
    }

    @Override
    public void onCreate(SQLiteDatabase db) {
        db.execSQL(CREATE_BOOK_TABLE);
        db.execSQL(CREATE_USER_TABLE);
    }

    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { // TODO ignored
    }
}

// ContentProvider. java
public class BookProvider extends ContentProvider {
    private static final String TAG = "BookProvider";
    public static final String AUTHORITY = "com.ajb.kotlintest.provider";
    public static final Uri BOOK_CONTENT_URI = Uri.parse(" content://" + AUTHORITY + "/book");
    public static final Uri USER_CONTENT_URI = Uri.parse(" content://" + AUTHORITY + "/user");
    public static final int BOOK_URI_CODE = 0;
    public static final int USER_URI_CODE = 1;
    private static final UriMatcher sUriMatcher = new UriMatcher(UriMatcher.NO_MATCH);

    static {
        //使用 UriMatcher 的 addURI 方法将 Uri 和 Uri_Code 关联到一起
        sUriMatcher.addURI(AUTHORITY, " book", BOOK_URI_CODE);
        sUriMatcher.addURI(AUTHORITY, " user", USER_URI_CODE);
    }

    private Context mContext;
    private SQLiteDatabase mDb;

    @Override
    public boolean onCreate() {
        Log.d(TAG, " onCreate, current thread:" + Thread.currentThread().getName());
        mContext = getContext();
        initProviderData();
        return true;
    }

    private void initProviderData() {
        mDb = new DbOpenHelper(mContext).getWritableDatabase();
        mDb.execSQL(" delete from " + DbOpenHelper.BOOK_TABLE_NAME);
        mDb.execSQL(" delete from " + DbOpenHelper.USER_TALBE_NAME);
//ContentProvider创建时,初始化数据库。注意:这里仅仅是为了演示,实际使用中不推荐在主线程中进行耗时的数据库操作
        mDb.execSQL(" insert into book values( 3,' Android');");
        mDb.execSQL(" insert into book values( 4,' Ios');");
        mDb.execSQL(" insert into book values( 5,' Html5');");
        mDb.execSQL(" insert into user values( 1,' jake', 1);");
        mDb.execSQL(" insert into user values( 2,' jasmine', 0);");
    }

    @Override
    public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
        Log.d(TAG, " query, current thread:" + Thread.currentThread().getName());
        String table = getTableName(uri);
        if (table == null) {
            throw new IllegalArgumentException(" Unsupported URI: " + uri);
        }
        return mDb.query(table, projection, selection, selectionArgs, null, null, sortOrder, null);
    }

    @Override
    public String getType(Uri uri) {
        Log.d(TAG, " getType");
        return null;
    }

    @Override
    public Uri insert(Uri uri, ContentValues values) {
        Log.d(TAG, " insert");
        String table = getTableName(uri);
        if (table == null) {
            throw new IllegalArgumentException(" Unsupported URI: " + uri);
        }
        mDb.insert(table, null, values);
        mContext.getContentResolver().notifyChange(uri, null);
        return uri;
    }

    @Override
    public int delete(Uri uri, String selection, String[] selectionArgs) {
        Log.d(TAG, " delete");
        String table = getTableName(uri);
        if (table == null) {
            throw new IllegalArgumentException(" Unsupported URI: " + uri);
        }
        int count = mDb.delete(table, selection, selectionArgs);
        if (count > 0) {
            getContext().getContentResolver().notifyChange(uri, null);
        }
        return count;
    }

    @Override
    public int update(Uri uri, ContentValues values, String selection, String[]
            selectionArgs) {
        Log.d(TAG, " update");
        String table = getTableName(uri);
        if (table == null) {
            throw new IllegalArgumentException(" Unsupported URI: " + uri);
        }
        int row = mDb.update(table, values, selection, selectionArgs);
        if (row > 0) {
            getContext().getContentResolver().notifyChange(uri, null);
        }
        return row;
    }

    private String getTableName(Uri uri) {
        String tableName = null;
        switch (sUriMatcher.match(uri)) {
            case BOOK_URI_CODE:
                tableName = DbOpenHelper.BOOK_TABLE_NAME;
                break;
            case USER_URI_CODE:
                tableName = DbOpenHelper.USER_TALBE_NAME;
                break;
            default:
                break;
        }
        return tableName;
    }
}

ContentProvider 通过 Uri 来区分外界要访问的的数据集合,为了知道外界要访问的是哪个表,我们需要为它们定义单独的 Uri 和 Uri_Code ,并将 Uri 和对应的 Uri_Code 相关联,我们可以使用 UriMatcher 的 addURI 方法将 Uri 和 Uri_Code 关联到一起。这样,当外界请求访问 BookProvider 时,我们就可以根据请求的 Uri 来得到 Uri_Code ,有了 Uri_Code 我们就可以知道外界想要访问哪个表,然后就可以进行相应的数据操作了,

接着我们需要注册这个 BookProvider,否则它无法向外界提供有效的数据。 如下所示。

<provider 
        android:name = ".provider.BookProvider" 
        android:authorities = "com.ajb.kotlintest.provider" 
        android:permission = "com.ajb.kotlintest.PROVIDER" 
        android:process = ":provider" />

注册了ContentProvider以后,我们就可以在外部应用中访问它了。

注意点:android:authorities 必须是唯一的,这里建议加上包名前缀。android:process让BookProvider运行在独立的进程中并给它添加了权限,这样外界应用如果想访问BookProvider,就必须声明“com.ajb.kotlin.PROVIDER”这个权限。ContentProvider的权限还可以细分为读权限和写权限,分别对应android:readPermission和android:writePermission属性,如果分别声明了读权限和写权限,那么外界应用也必须依次声明相应的权限才可以进行读/写操作,否则外界应用会异常终止。

八、Messenger

Messenger 的使用方法很简单,它对 AIDL 做了封装,使得我们可以更简便地进行进程间通信。同时,由于它一次处理一个请求,因此在服务端我们不用考虑线程同步的问题,这是因为服务端中不存在并发执行的情形。

public class MessengerService extends Service {
    private static final String TAG = "MessengerService";

    private static class MessengerHandler extends Handler {
        private static final int MSG_FROM_CLIENT = 1000;

        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case MSG_FROM_CLIENT:
                    Log.i(TAG, " receive msg from Client:" + msg.getData().getString(" msg"));
                    break;
                default:
                    super.handleMessage(msg);
            }
        }
    }

    private final Messenger mMessenger = new Messenger(new MessengerHandler());

    @Override
    public IBinder onBind(Intent intent) {
        return mMessenger.getBinder();
    }
}

关于 Messenger的介绍就这么多,更详细的资料请查看相关网络资料。

九、 Socket

我们也可以通过 Socket 来实现进程间的通信。 Socket 也称为“套接字”,它分为流式套接字( TCP 协议)和用户数据报套接字( UDP 协议)两种。

TCP 协议是面向连接的协议,提供稳定的双向通信功能, TCP 连接的建立需要经过“三次握手”才能完成,为了提供稳定的数据传输功能,其本身提供了超时重传机制,因此具有很高的稳定性;

而 UDP 是无连接的,提供不稳定的单向通信功能,当然 UDP 也可以实现双向通信功能。在性能上, UDP 具有更好的效率,其缺点是不保证数据一定能够正确传输,尤其是在网络拥塞的情况下。关于 TCP 和 UDP 的介绍就这么多,更详细的资料请查看相关网络资料。

至此,Android IPC机制的介绍暂告一段落了。

名称 优点 缺点 适用场景
Bundle 简单易用 只能传输Bundle支持的数据类型 四大组件间的进程间通信
文件共享 简单易用 不适合高并发场景,并且无法做到进程间即时通信 无并发访问情形,交换简单的数据实时性不高的场景
AIDL 功能强大,支持一对多并发通信,支持实时通信 使用稍复杂,需要处理好线程同步 一对多通信且有RPC需求
Messenger 功能一般,支持一对多串行通信,支持实时通信 不能很处理高并发清醒,不支持RPC,数据通过Message进行传输,因此只能传输Bundle支持的数据类型 低并发的一对多即时通信,无RPC需求,或者无需返回结果的RPC需求
ContentProvider 在数据源访问方面功能强大,支持一对多并发数据共享,可通过Call方法扩展其他操作 可以理解为受约束的AIDL,主要提供数据源的CRUD操作 一对多的进程间数据共享
Socket 功能请打,可以通过网络传输字节流,支持一对多并发实时通信 实现细节稍微有点烦琐,不支持直接的RPC 网络数据交换

推荐阅读更多精彩内容