我们生活在这个孤独的蓝色星球,无论经历怎样的欢欣与苦痛,在这世界上你永远不是孤身一人,有爱、有梦、有朋友,还有这么美好的世界!
本节继续讲解Android中的IPC方式,在上一节IPC机制-Android中的IPC方式一-Bundle、文件共享、Messenger、AIDL当中我们已经讲解了如何使用Bundle、文件共享、Messenger以及AIDL来完成跨进程间通信,未阅读该节的读者,不妨进去瞧瞧。
那么,接下来我将继续为大家讲解上节未完成的内容。
使用ContentProvider
ContentProvider是Android中提供的专门用于不同应用间进行数据共享的方式,从这一点来看,它天生就适合进程间通信。和Messenger一样,ContentProvider的底层实现同样也是Binder,由此可见,Binder在Android系统中是何等的重要。
ContentProvider虽然使用起来很简单,但它的细节还是相当多,比如CRUD操作,防止SQL注入和权限控制等。在本节中,不对ContentProvider的使用细节以及工作机制进行详细分析,在这里只介绍采用ContentProvider进行跨进程通信的主要流程,至于使用细节和内部工作机制请阅读。
系统预置了许多ContentProvider,比如通讯录信息,日程表信息等,要跨进程访问这些信息,只需要通过ContentProvider的query、update、insert和delete方法即可。接下来,我们实现一个自定义的ContentProvider,并演示如何在其他应用中获取ContentProvider中的数据从而实现进程间通信这一目的。
首先,创建一个类继承自ContentProvider,同时实现其6个抽象方法:onCreate、query、update、insert、delete和getType。其中,onCreate代表ContentProvider的创建,在该方法中做一些初始化工作;getType用来返回一个Uri请求所对应的MIME类型(媒体类型),比如图片、视频等,如果我们的应用不关注这个选项,可以直接在这个方法中返回null或者 /;剩下的四个方法对应于CRUD操作。根据Binder的工作原理,这6个方法均运行在ContentProvider的进程中,除了onCreate有系统回调并运行在主线程里,其他5个方法均由外界回调并运行在Binder线程池中。
ContentProvider主要以表格的形式来组织数据,并且可以包含多个表,对于每个表格来说,它们都具有行和列的层次性,行往往对应一条记录,而列对应一条记录中的一个字段,这点和数据很类似。除了表格的形式,ContentProvider还支持文件数据,比如图片、视频等。文件数据和表格数据的结构不同,因此处理这类数据时可以在ContentProvider中返回文件的句柄给外界从而让文件来访问ContentProvider中的文件信息。Android系统中所提供的MediaStore功能就是文件类型的ContentProvider。虽然ContentProvider的底层数据看起来很像一个SQLite数据库,但是ContentProvider对底层的数据存储方式没有任何要求,我们既可以使用SQLite数据库,也可以使用普通的文件,甚至可以采用内存中的一个对象来进行数据的存储,这一点在这里有介绍哦~
下面看一个最简单的示例:
首先,创建一个类(BookProvider)继承自ContentProvider,同时实现其6个抽象方法:
|
|
记得在清单文件中进行注册哦~因为ContentProvider也是四大组件之一。
|
|
其中android:authorities是ContentProvider的唯一标识,通过这个属性外部应用就可以访问我们的BookProvider,因此,android:authorities必须是唯一的,这里建议读者在命名的时候加上包名前缀。为了演示进程间通信,我们让BookProvider运行在独立的进程中并给它添加了权限,这样外界应用如果想访问BookProvider,就必须声明“com.zaenlove.PROVIDER”这个权限。ContentProvider的权限可以细分为读权限和写权限,分别对应android:readPermission和android:writePermission属性,如果分别声明了读权限和写权限,那么外界应用也必须依次声明相应的权限才可以进行读/写操作,否则外界应用会异常终止。
注册了ContentProvider以后,我们就可以在外部应用中访问它了,为了方便演示,这里仍然选择在同一个应用的其他进程中去访问这个BookProvider,至于在单独的应用中去访问这个BookProvider和同一个应用中访问的效果是一样的(注意要声明对应权限)。
|
|
在上面的代码中,我们通过ContentResolver对象的query方法去查询BookProvider中的数据,其中“content://com.zaenlove.book.provider”唯一标识了BookProvider,而这个标识正是我们前面为BookProvider的android:authorities属性所指定的值。
运行程序,查看log:
从上面的log可以看出,BookProvider中的query方法被调用了三次,并且这三次调用不在同一个线程中。可以看出,它们运行在一个Binder线程中,前面提到update、insert和delete方法同样也运行在Binder线程中。另外,onCreate运行在main线程中,也就是UI线程,所以我们不能在onCreate中做耗时的操作。
到这里,整个ContentProvider的流程我们已经跑通了。接下来,在上面的基础上,我们继续完善BookProvider,从而使其能够对外部应用提供数据。现在外部应用可以通过BookProvider来访问图书信息,为了更好地演示ContentProvider的使用,用户还可以通过BookProvider访问到用户信息。为了完成上述功能,我们需要一个数据库来管理图书和用户信息,这个数据库不难实现,代码如下:
|
|
上述代码是一个简单的数据库的实现,我们借助SQLiteOpenHelper来管理数据库的创建、升级和降级。下面通过BookProvider向外界提供上述数据库中的信息了。我们知道,ContentProvider通过Uri来区分外界要访问的数据集合,在本例中支持外界对BookProvider中的book表和user表进行访问,为了知道外界要访问的是哪个表,我们需要为它们定义单独的Uri和Uri_Code,并将Uri和对应的Uri_Code相关联,我们可以使用UriMatcher的addUri方法将Uri和Uri_Code关联到一起。这样,当外界请求访问BookProvider时,我们就可以根据请求的Uri来得到Uri_Code,有了Uri_Code我们就可以知道外界想要访问哪个表,然后就可以进行相应的数据操作了,具体代码如下所示:
|
|
从上面代码可以看出,我们分别为book表和user表指定了Uri,分别为 “content://com.zaenlove.book.provider/book” 和 “content://com.zaenlove.book.provider/user”,这两个Uri所关联的Uri_Code分别为0和1。这个关联过程是通过下面的语句来完成的:
|
|
将Uri和Uri_Code管理之后,我们就可以通过如下方式来获取外界所要访问的数据源,根据Uri先取出Uri_Code,根据Uri_Code再得到数据表的名称,知道了外界要访问额表,接下来就可以响应外界的增删改查请求了。
|
|
接着,我们就可以实现query、update、insert、delete方法了。如下是query方法的实现,首先我们要从Uri中取出外界要访问的表的名称,然后根据外界传递的查询参数就可以进行数据库的查询操作了。
|
|
另外三个方法的实现思想和query是类似的,只有一点不同,那就是update、insert和delete方法会引起数据源的改变,这个时候我们需要通过ContentResolver的notifyChange方法来通知外界当前ContentProvider中的数据已经发生了改变。要观察一个ContentProvider中的数据改变情况,可以通过ContentResolver的registerContentObserver方法来注册观察者,通过unregisterContentObserver方法来解除观察者。对于这三个方法,这里不再详细解释了,下面是BookProvider的完整代码:
|
|
需要注意的是,query、update、insert、delete四大方法是存在多线程并发访问的,因此方法内部要做好线程同步。在本例中,由于采用的SQLite并且只有一个SQLiteDatabase的连接,所以可以正确应对多线程的情况。具体原因是SQLiteDatabase内部对数据库的操作是有同步处理的,但是如果通过多个SQLiteDatabase对象来操作数据库就无法保证线程同步,因为SQLiteDatabase对象之间无法进行线程同步。如果ContentProvider的底层数据集是一块内存的话,比如是List,在这种情况下同List的遍历、插入、删除操作就需要进行线程同步,否则就会引起并发错误,这点是尤其需要注意的。到这里BookProvider已经实现完了,接着我们在外部访问一下它。
|
|
运行程序,查看log:
由于ProviderActivity和BookProvider运行在两个不同的进程中,因此,这也构成了进程间的通信。ContentProvider除了支持对数据源的增删改查这四个操作,还支持自定义调用,这个过程是通过ContentProvider的Call方法和ContentResolver的Call方法来完成的。
关于使用ContentProvider来进行IPC就介绍到这里,不过ContentProvider都在后续的Blog中还会进一步的讲解,主要包括细节问题和工作原理。敬请期待!
使用Socket
下面我们来讲解使用Socket来实现进程间的通信。Socekt也称为“套接字”,是网络通信中的概念,它分为流式套接字和用户数据报套接字两种,分别对应于网络的传输控制层中的TCP和UDP协议。TCP协议是面向连接的协议,提供稳定的双向通信功能,TCP连接的建立需要经过“三次握手”才能完成,为了提供稳定的数据传输功能,其本身提供了超时重传机制,因此具有很高的稳定性;而UDP是无连接的,提供不稳定的单向通信功能,当然UDP也可以实现双向通信功能。在性能上,UDP具有更好的效率,其缺点是不保证数据一定能够正确传输,尤其是在网络拥塞的情况下。
接下来,我们演示一个跨进程的聊天程序,两个进程可以通过Socket来实现信息的传输,Socket本身可以支持传输任意字节流,这里为了简单起见,仅仅传输文本信息。
使用Socket来进行通信,有两点需要注意,首先需要声明权限:
其次要注意不能在主线程中访问网络,因为这会导致我们的程序无法在Android4.0及其以上的设备中运行,会抛出这个异常:android.os.NetworkOnMainThreadException。而且进行网络操作很可能是耗时的,如果放在主线程中会影响程序的响应效率,从这方面来说也不应该在主线程中访问网络。
下面就开始设计我们的聊天程序了,首先在远程Service建立一个TCP服务,然后在主界面中连接TCP服务,连接上了以后,就可以给服务端发消息。对于我们发送的每一条文本消息,服务端都会随机地回应我们一句话,为了更好地展示Socket的工作机制,在服务端我们做了处理,使其能够和多个客户端同时建立连接并相应。
先看一下服务端的设计,当Service启动时,会在线程中建立TCP服务,这里监听的是8688端口,然后就可以等待客户端的连接请求。当有客户端连接时,就会生成一个新的Socket,通过每次新创建的Socket就可以分别和不同的客户端通信了。服务端每收到一次客户端的消息就会随机回复一句话给客户端。当客户端断开连接时,服务端这边也会相应的关闭对应Socket并结束通话线程,这点是如何做到的呢?方法有很多,这里是通过判断服务端输入流的返回值来确定的,当客户端断开连接后,服务端这边的输入流就会返回null,这个时候我们就知道客户端退出了。服务端的示例代码如下:
|
|
接着看一下客户端,客户端Activity启动时,会在onCreate中开启一个线程去连接服务端Socket,至于为什么用线程在前面已经做了介绍。为了确定能够连接成功,这里采用了超时重连的策略,每次连接失败后都会重新建立尝试建立连接。当然为了降低重试机制的开销,我们加入了休眠机制,即每次重试的时间间隔为1000毫秒。
|
|
服务端连接成功后,就可以和服务端进行通信了。下面的代码在线程中通过while循环不断地去读取服务端发送过来的消息,同时当Activity退出时,就退出循环并终止线程。
|
|
同时,当Activity退出时,还要关闭当前的Socket,如下所示:
|
|
接着是发送消息的过程,代码如下所示:
|
|
客户端完整代码如下:
|
|
上述就是通过Socket来进行进程间通信的实例,除了采用TCP套接字,还可以采用UDP套接字。另外,上面的例子仅仅是一个示例,实际上通过Socket不仅仅能实现进程间的通信,还可以实现设备间的通信,当然前提是这些设备之间的IP地址互相可见,这里就不再深究了。
运行上述程序,查看效果: