一、 什么是IPC?
IPC,全称Inter-Process Communication,字面意思就是进程间通信或者跨进程通信。那什么是进程呢?它和线程有什么暧昧的关系?
进程是系统进行资源分配和调度的基本单位,是操作系统结构的基础;早期表现为一个程序,现在可以看作线程的容器。线程是CPU调度的最小单位。�一个进程可以包含一个或者多个线程,进程向系统申请资源,线程使用进程拥有的资源。
IPC不是Android所独有的,是现代操作系统都存在的机制,对于Android来说。它是一种基于Linux内核的移动OS,他的进程通信方式不仅仅包含信号量、套接字、管道等等,还包括了Android独有的、特色的Binder机制。
二、 为什么需要多进程?应用场景...
谈到IPC的使用场景就必须提到多进程,只有面对多进程这种场景下,才需要考虑多进程通信,这是很好理解的。至于一个应用使用多进程的原因,这个可能很多,辟如有些模块由于特殊原因需要运行在独立的进程;又或者为了加大一个应用可使用的内存,通过多进程的方式申请多份内存空间。还有一个情况需要使用IPC,那就是多个应用之间进行数据共享,使用ContentProvider去查询数据时也是一种进程通讯,只是对我们来说透明化了,无法感知到。
三、 Android如何开启多进程模式?
我们可以通过给四大组件在AndroidMenifest.xml指定指定 android:process属性,亦或是在JNI层fork一个新进程,别无他法,过程看似轻松简单,却暗藏杀机,如何抵消多进程带来的负面影响?
这里有个示例:
眼尖的人都发现了两个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进行序列化操作
Implements Parcelable的时候需要实现内部的方法:
1).writeToParcel 将对象数据序列化成一个Parcel对象(序列化之后成为Parcel对象.以便Parcel容器取出数据)
2).重写describeContents方法,默认值为0
3).Public static final Parcelable.Creator
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 CREATOR = new Creator(){
@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 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 _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 getBookList() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.util.List _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 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 mBookList;
public CustomService() {
}
@Override
public IBinder onBind(Intent intent) {
return new BookManagerImpl();
}
private class BookManagerImpl extends IBookManager.Stub {
@Override
public List 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 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,否则它无法向外界提供有效的数据。 如下所示。
注册了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 | 网络数据交换 |