CN103902390B

CN103902390B - 基于Android的应用层的进程间通信方法及基础应用通信系统

Info

Publication number: CN103902390B
Application number: CN201410090696.1A
Authority: CN
Inventors: 郭尚锋; 吕伟龙
Original assignee: Shenzhen Skyworth RGB Electronics Co Ltd
Current assignee: Shenzhen Skyworth RGB Electronics Co Ltd
Priority date: 2014-03-12
Filing date: 2014-03-12
Publication date: 2017-04-19
Anticipated expiration: 2034-03-12
Also published as: CN103902390A; AU2014386583A1; AU2014386583B2; AU2014386583B8; AU2014386583A8; US20160344846A1; WO2015135221A1; US9923992B2

Abstract

本发明公开了一种基于Android的应用层的进程间通信方法及基础应用通信系统，按照客户机/服务器的通信模式，创建系统级应用和用户应用相互通信的框架封装Application，并虚拟为客户机端；创建守护进程IPCService，并虚拟为服务器端；通过Application向IPCService注册绑定，实现各个Application的互相通信。采用本发明的方案，在各个应用进行进程间通信时，可以快速安全地建立起自己的一套通信机制，不仅各系统应用的通信更加方便，而且让系统具有了简单性和开放性，可以简便地融合第三方应用，也极大方便了自由开发者在系统平台上开发应用，既丰富了系统平台的应用，也可以降低应用开发成本。

Description

基于Android的应用层的进程间通信方法及基础应用通信系统

【技术领域】

本发明涉及数据通信领域，特别涉及一种基于Android的应用通信技术。

【背景技术】

随着科技的迅猛发展,以智能手机为代表的Android设备如雨后春笋般迅速发展壮大。Android系统自推出以来,就以明显的优势逐渐扩大市场份额,在国内，Android系统的应用已不仅局限于手机产业,几年来其迅速扩张到相邻领域,例如平板电脑、车载系统、电视STB、智能电器、智能会议系统等。

但是对于采用Android系统的各个开发厂商和互联网企业而言，不能仅仅满足于在Android的原生系统上开发出各种各样的应用，还需要深层次地定制带有自己特色的Android系统；尤其对于各大电视厂商来说，独具特色的系统显得非常重要，而且也可以快速适应芯片的迭代和更新。那么，如何定制和创建一套上层开发可用的系统，成了各大厂商开发的首要任务和难题。

要创建一套基于Android的系统级应用，或者说需要定制一套有自己特色的Android系统，那么不可避免要用到进程间通信等通信方法。众所周知，在Android系统上，各个应用的通信方法无非两种，Binder机制和SOCKET通信机制。当前，大多数电视厂商都采用了单一的Binder机制或SOCKET机制，甚至广播机制。但是这些做法都有一定的缺陷，不能完全满足一个基于可开放平台的系统要求。

采用SOCKET机制之后，可以降低各个资源模块的耦合性，独立的模块可以实现独立的资源接口，这样可以在某个模块崩溃之后，系统仍然可以正常运行。但是，由于SOCKET接口的通用性，导致其传输效率低，开销大，不适合用来多进程之间的相互实时通信，更适合不同机器间的数据传输和通信。同时，采用了SOCKET机制之后，由于每个模块都需要一个端口号，才能互相通信，这样在第三方应用集成进来的时候，需要分配端口号，各个系统应用如果需要和第三方应用通信，还得先后去各个应用的端口号之后才能通信，很大程度上阻碍了软件平台的开发和丰富的第三方应用的接入。所以采用SOCKET机制来建立系统级应用的机制存在明显缺陷。

而采用Binder机制之后，由于单一的采用Binder机制和AIDL的调用方式，上层应用为了可以正常调用到所有可用的资源接口，将所有的模块功能捆绑在了一个service进程上，这样就导致了一个问题，系统的耦合性太强，如果核心提供资源接口的Service进程挂掉，那么整个系统将不能运作，给用户带来很大的不便，用户体验较差。

【发明内容】

本发明的主要目的是：提供一种基于Android的应用通信方案。

为此，首先，本发明提出一种基于Android的应用层的进程间通信方法，创建系统级应用和用户应用相互通信的框架封装Application，并虚拟为客户机端；创建守护进程IPCService，用于进程间通信服务，并虚拟为服务器端；所述Application向IPCService注册绑定，各个所述Application通过所述IPCService实现各个应用的互相通信。

其次，本发明提出了一种基于Android的基础应用通信系统，包括：

Application，为系统级应用和用户应用相互通信的框架封装，虚拟为客户机端；

守护进程IPCService，用于进程间通信服务，虚拟为服务器端；

所述Application向IPCService注册绑定，各个所述Application通过所述IPCService实现各个应用的互相通信。

再次，本发明提出了一种智能终端，应用上述的基于Android的应用层的进程间通信方法或基础应用通信系统，实现各个Application的互相通信。

同时，本发明提出一种智能电视终端，固化有上述的基于Android的基础应用通信系统。

最后，本发明提出了一种电子数据载体，存储有用于实现上述的基于Android的应用层的进程间通信方法的计算机程序。

本发明Android应用的通信方案，由具体的应用和一个守护进程组成，在Android系统各个应用进行进程间通信时，可以快速安全地建立起自己的一套通信机制，不仅各系统应用的通信更加方便，而且让系统具有了简单性和开放性，可以简单方便的融合第三方应用，也极大方便了自由开发者在系统平台上开发应用，这样既丰富了系统平台的应用，也可以降低应用开发成本。

本发明基于Android应用的通信方案，在Android系统上各个应用间快速安全地建立起自己的一套通信机制，并且实现了不仅各个应用进程间的通信，更可以精准到应用的某个Activity或者Service，让进程间通信不再那么神秘和应用困难。而且，基于本方案实现的通信系统上开发应用会显得非常简单，并且可以实现应用不再是独立的一个Android应用，可以形成一个体系，一个套件的形式展现给用户，更简洁有序，用户体验不会感觉到应用很多、很杂乱。

【附图说明】

图1本发明的基础应用通信系统的系统通信概要图；

图2本发明中Binder机制示意图；

图3本发明实施例中Application绑定IPCService服务的流程；

图4本发明实施例的注册机制示意图；

图5本发明实施例的数据包结构示意图；

图6本发明实施例的接收数据流程示意图;

图7本发明实施例的发送数据流程示意图;

图8本发明实施例的Activity和Service的通信流程图。

【具体实施方式】

下面通过具体的实施例并结合附图对本发明作进一步详细的描述。

技术名词解释：Application主要指某个具体的应用或者Android的Application对象，本申请中，主要指系统级（即能在其上开发用户应用的基础应用）应用和用户应用相互通信的框架封装。

Application层，泛指应用层，包含Application和IPCService。

IPCService，守护进程，用于进程间通信服务。

Activity Android应用程序组件，提供一个屏幕，用户可以用来交互。

Service服务，Android组件之一，没有用户界面的在后台运行执行耗时操作的应用组件。

ServiceManager服务管理，Android的重要进程，用于管理系统中的Service。

本发明采用C/S（Client/Server，客户机/服务器）的通信模式，总体框架请参阅图1的系统通信概要图，由Application和IPCService两部分组成，通过Application向IPCService注册，然后实现各个Application互相通信的过程。

实施例一：

本例的基于Android的应用层的进程间通信方法,通过创建一个基于Android的基础应用（泛指所有系统应用和用户应用）通信系统来实现，包括：

首先，创建系统级（即能在其上开发用户应用的基础应用）应用和用户应用相互通信的框架封装应用Application，实现绑定服务、保存对象、发送数据、接收数据等主要重要步骤。

1.绑定服务，主要指Application层在Activity和Service在oncreated()(7个与生命周期有关的函数之一，是activity第一次启动时被执行的，主要是初始化一些变量)的时候，向ServiceManager发送申请IPCService服务的请求，请结合图2和图3所示，利用了Android的Binder机制；

S11.IPCService申请创建Binder的实体：首先，IPCService在自己的进程中向Binder驱动申请创建一个IPCService的Binder的实体；

S12.Binder驱动创建IPCService的服务：Binder驱动为IPCService创建为了内核中的IPCService的Binder实体节点以及Binder的引用，实际上是通知ServiceManager注册一个叫做IPCService的服务，用于进程间通信服务；

S13.关联查找表：ServiceManager收到数据包之后，从中取出IPCService的名字和引用，填入一张查找表中；

S14.Application申请并获得IPCService的绑定服务：Application向ServiceManager发起申请IPCService服务的请求，那么ServiceManager就可以在查找表中找到IPCService的引用，IPCService把Binder引用返回给Application。

2.保存对象，如图4注册机制中的虚线框中所示，Application层在绑定服务成功之后，将各个继承自SkyActivity和SkyService的实例对象保存在一张对应表中，以便接收数据的时候可以分发到各个具体的Activity和Service对象。通过保存具体的实例对象，就可以准确传输数据到指定应用的指定Activity和指定Service中，实现了精准传输通信的逻辑结构。

本例采用的两张表：具体来说就是，每个Application都保存了一张对应表，该表是自身Service和Activity的集合；而IPCService的查找表，一个通信平台一个，保存该平台的所有Application的引用等。这在现有技术的方案中是完全没有的。现有技术中，Android自身虽然可以实现Activity到Activity或者Service的通信，但是其缺点过于明显，实现的是进程对进程的通信，采用进程对进程的一张表，如果一个进程中有多个service和activity，就没法实现具体到哪个service或者activity的通信，故只能实现点对点之间的通信，通信的数据只能是基本类型的数据结构（int,String,List等）；而本例保存了具体的实例对象后，相当于将所有的应用置于了一个通信平台，不仅仅是点对点，还可以多个点之间互相通信。

现有技术中，利用Binder在进程间通信，限定了返回的引用必须是IBinder，应用Application A如果要和应用Application B通信，就得保存Application B的IBinder,Application A如果还要同Application C通信，那么Application A也得保存ApplicationC的IBinder，Application A要通信的点越多，导致Application A需要绑定的次数也越多，保存的引用也越多，并且这些Application之间如果要互相通信，那么每个应用都得保存一份除自身之外的所有引用，非常繁琐复杂。并且受Binder机制的接口约束，通信数据的结构也局限于Android通信的基本数据结构，基本都是采用String进行通信。

Binder机制的核心就是两个进程或者两个组件的通信，采用本案的封装和利用后，可以面向一个平台，并且大大减少了上层应用开发的复杂性，但同时又实现了上层应用的多点互相通信。本案直接采用字节流之后，用户就可采用任何数据结构，只需要确保通信的双方可以正常序列化和反序列化即可，并且Java的很多复杂数据结构也支持字节序列化和反序列化，大大减少了数据结构向String转换的性能消耗。

3.发送数据，由Application将要通信的数据封装成如图5所示的数据结构中，主要由包头header和数据体body组成，header主要包括了发送方身份信息from、发送目的地to、通信命令cmd、优先级priority、回复needack等字段；body主要是消息的字节流；header的各个字段的含义如下：

3.1.from，主要包含发送数据方的包名，Activity或者Service名，由Application层自动组装和获取，具体的使用者可以不用关心；

3.2.to，主要指数据要发送到某个包中的某个Activity或者Service，由具体实现发送命令的使用者传递参数；

3.3.cmd，主要是双方用来通信的协议，代表某一协商好的含义，具体为一个字符串；

3.4.priority，主要是指命令的优先级，在IPCService处理命令的时候区分优先级；

3.5.needack，是否需要立即回复的标识，表示该命令是否需要立即返回一个result(通信的一个标签)；

在Application组装好数据之后，由于绑定服务已经获取到了IPCService的Binder的引用，就可以直接将组装好的数据包发送给IPCService，然后由IPCService处理和转发。而且，本案采用了字节流的形式对数据进行再次编码和压缩，在Application对外开放的通信接口上，应用如果需要通信，直接传递字节流即可；而现有技术大多对外接口都是字符串，或者一种协商好的数据结构，不够通用和灵活。字节是基本的传输单位，用户（也就是采用本通信的使用者）有权决定自身的数据结构和序列化方式，如果采用一种固定的数据结构限定了用户对于序列化等操作的要求；面向用户开放字节流之后，用户就可以自己根据自己的需求决定采用哪种方式序列化，采用哪种方式反序列化，不必限定于非要采用Java的序列化，或者Android的序列化，或者某种自定义的序列化等，让使用者可以采用的数据结构更加多样化，不再局限于基础的数据结构，打破了固定化数据结构的通信模式。

4.接收数据，如图6接收数据机制所示，在Application层接收到数据包以后，会将接收到的数据包丢入一个命令池里面，该命令池是对Java现有线程池的封装，主要实现对于请求的控制处理；该命令池专用来处理接收到的数据包的，有一个线程会不断的从该命令池中取数据包，解析数据包的头部，然后根据具体的Activity名或者Service名，从一开始保存的对应表中查询出具体的Activity实例，然后交给具体的Activity实例去处理具体的数据包。

其次，创建一个守护进程IPCService，作为处理和转发数据包的核心服务，虽然从Android的架构角度来讲处于用户空间，但是对于用户来说是不可见的，用户和使用者不必关心IPCService需要具体处理哪些事务。其主要包含两个功能：

一方面，IPCService管理所有Application提供的服务，即所有Application接收数据的Binder引用；IPCService在管理所有Application服务的同时，保存了所有通信应用的包名，将应用的包名和Binder引用一一对应起来形成一查找表，实现了任何包对包的通信。这样极大方便了第三方应用的集成和开发，因为此时不再局限于已经存在的系统应用的通信，同时将范围大大扩展到了任何采用本框架的应用，不管是自行开发的，还是第三方集成的。

另一方面，IPCService响应所有Application的请求并为之分配对应的服务。IPCService在接收到Application的请求时，根据包名取出所请求的Binder引用，然后调用该Binder的接口，转发数据。

这样就实现了一个发送数据的流程，如图7所示：

假设Application A向Application B发送数据，当IPCService接收到Application A的请求时，处理发送到的数据包的头部，解析出to的对象，也就是Application B，然后从保存的查找表中取出Application B的Binder引用，然后调用Application B的引用，这样数据就发送到了Application B。如果查找表中没有发送到的对象，说明Application B没有启动，就可以直接丢弃数据包，因为所有继承自该套通信机制的应用都会在启动的时候向IPCService发起注册和绑定服务。

采用本方案提出的通信机制之后，Application的请求便于管理，另一方面，只需要Application启动的时候，向IPCService建立连接即可，就可以花费非常少的时间去实现IPCService的功能。

综上所述，本例的基于Android系统级应用的通信方案，由具体的应用和一个守护进程组成，解决了在Android系统上各个应用进行进程间通信的一些弊端，可以快速安全地建立起自己的一套通信机制，并且不仅实现了各个应用进程间的通信，更可以精准到应用的某个Activity或者Service，让进程间通信不再那么神秘和应用困难。最重要的是，在基于本方案实现的通信系统上开发应用会显得非常简单，并且可以实现应用不再是独立的一个Android应用，可以形成一个体系，一个套件的形式展现给用户，让用户不会感觉到应用很多、很杂乱。基于本方案实现的通信系统上，可以让一个独具特色的系统更加具有了简单性、开放性以及非常好的可扩展性，不再是一个单一的系统，而是一个可开放的平台。

实施例二：

依据实施例一的方案，将其具体应用在创维的智能电视操作系统-天赐系统的重构版本中，详细说明如下：

首先，实现一个全局的Application，包含在框架层，并且封装成jar包。编写一个全局的单例模式的MyApplication继承自Application。由于在应用层无法直接对原生Application进行更改，更改也违背了Android开放性和通用性的要求；创建一个继承自Application的MyApplication是为了实现对事物的普通性和特殊性的需求，再次创建的MyApplication既是一个普通的Android应用，但同时又实现了自身对于通信的需求。MyApplication实现通信框架层的封装，主要包含绑定服务、保存对象、发送数据、接收数据等重要步骤。各个步骤的具体实施方案同实施例一所述。如图4，完整地表示了整个Application层通信的处理流程：Activity和Service在OnCreate()的时候，被初始化并被Application保存在一张对应表。假如应用A中有2个Activity，3个Service，那么保存的表对应关系如下所示，该应用所有的Activity和Service均被保存在两个HashMap中，形成一个Application的对应表，包含有该应用所有基础组件的包名和类名(key和value的顺序可以调换）。

该表记录了该进程所有创建的需要通信的Activity和Service；在Activity和Service初始化的时候，Application将自身的实例包名作为参数，向ServiceManager发送申请IPCService服务的请求；ServiceManager在接收到请求之后，将IPCService的引用返回给Application；并且与此同时，IPCService会将绑定者（也就是Application）的引用保存在一张查找表中，该表包括绑定者的包名、提供的服务等信息。如下，一个由包名对应binder应用返回的ICmdReceiver接口实例组成的hashmap<Strng,ICmdReceiver>，形成IPCService中的查找表。

之所以在应用层实现通信框架的封装，是因为在Android基础上，应用程序第一个组件运行时将会为应用创建一个进程，并且首先实例化所指定的Application，此时就会执行绑定IPCService的服务，从而建立Application和IPCService的通信；

然后，实现IPCService的守护进程：

创建一个守护进程的service，提供注册、发送数据的Binder引用，再创建一张保存所有已经注册的Application的Binder查找表，最后根据数据包的包头，从查找表查找获取对应Binder的引用来实现数据转发。

上述步骤实现了基本通信的框架系统，那么对于具体的各个基础应用或者用户应用来说，要做的事情就更简单了，只需要三个简单的步骤，即可实现整个系统各个Activity和Service的通信。

S1，所创建的应用依赖系统框架jar包；

S2，所有需要通信的Activity和Service继承自SkyActivity和SkyService；

S3，在androidmanifest.xml中配置Application选项，其中name后面为框架jar包中Application的路径，如下所示：

通过以上三个简单的步骤，就可以在任意继承自SkyActivity和SkyService的类中处理和收发数据包，并且可以实现阻塞和非阻塞两种调用方式。阻塞调用方式，主要流程是将命令和数据发送到接收方，同时同步等待接收方处理的返回，此时发送方的线程被阻塞，直到调用的返回。非阻塞调用的方式，将命令和数据发送到接收方时，命令先由框架中的线程时处理，发送方不会等待命令的返回；框架中的线程池会根据命令的优先级和时间将线程池中的所有命令按照优先顺序依次交给接收方处理。

综上所述，本例在天赐系统的重构和优化过程中得到了应用，同时本发明提出的方案不仅仅可以应用于电视上，任何一个基于Android的系统都可以采纳本方案进行进程间通信以及系统的深入开发与体系开发。而且，本方案在Android系统通信机制的基础上进行了再次封装和创新，让应用的开发更加简单，也让针对不同平台的应用差异化工作更容易开展，做到了让平台简单化，统一化，应用多元化的目标。总之，本方案实现了系统应用通信的简单性、开放性。

实施例三

本例是一种智能终端，其中内置了实现实施例一中的基于Android的应用层的进程间通信方法或基础应用通信系统的程序，通过启用该程序，可实现智能终端中各个Application的互相通信。实现了系统应用通信的简单性、开放性，易于第三方进行应用开发，实现应用多元化的目标。智能终端包括但并不限于智能电视、智能手机、个人电脑、平板电脑或云系统个人终端等。

实施例四

本例是一种智能电视终端，其中固化有实现实施例一中的基于Android的应用层的进程间通信方法或基础应用通信系统的程序，通过启用该程序，可实现智能终端中各个Application的互相通信。在此基础应用通信系统的基础上，易于第三方进行用户应用开发，实现应用多元化的目标。比如，第三方开发者甚至不用理解该框架，只需要两个步骤即可调用系统的一些接口。比如目前创维天赐系统中的爱奇艺、有朋等第三方应用，可以非常容易和快速地实现不同的应用的同一个云端收藏等功能。

实施例五

本领域技术人员可以理解，上述实施方式中各种方法的全部或部分步骤可以通过计算机程序来指令相关硬件完成。本例是一种计算机可读的电子数据载体，包括但不限于光盘、闪存盘、硬盘和网盘等，其中存储了用于实现实施例一中的基于Android的应用层的进程间通信方法或基础应用通信系统的计算机程序。可以供基于Android的智能终端进行操作系统的个性化升级，也可供第三方进行应用开发。智能终端包括但并不限于智能电视、智能手机、个人电脑、平板电脑或云系统个人终端等。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims

1.一种基于Android的应用层的进程间通信方法，创建系统级应用和用户应用相互通信的框架封装Application，并虚拟为客户机端；创建守护进程PCService，用于进程间通信服务，并虚拟为服务器端；所述Application向守护进程IPCService注册绑定，各个所述Application通过所述守护进程IPCService实现各个应用的互相通信；

所述框架封装Application，实现绑定服务、保存对象、发送数据和接收数据步骤；

所述绑定服务步骤中，所述Application在Activity和Service在oncreated()时，向ServiceManager发送申请守护进程IPCService服务的请求，利用Binder机制，由ServiceManager绑定所述Application和守护进程IPCService之间的服务机制；

所述绑定服务的具体流程包括：

S11.守护进程IPCService在自己的进程中向Binder驱动申请创建一个守护进程IPCService的Binder的实体；

S12.Binder驱动为守护进程IPCService创建成为内核中的守护进程IPCService的Binder实体节点以及Binder的引用，即通知ServiceManager注册一个用于进程间通信服务的守护进程IPCService；

S13.ServiceManager收到数据包之后，从中取出IPCService的名字和引用，填入查找表中；

S14.Application向ServiceManager发起申请守护进程IPCService服务的请求，ServiceManager在所述查找表中找到守护进程IPCService的引用，并把Binder引用返回给Application。

2.如权利要求1所述的应用层的进程间通信方法，其特征是：具体包括：

所述守护进程IPCService，管理所有所述Application服务，保存所有通信应用的包名，将应用的包名和Binder引用一一对应，实现任何包对包的通信；响应所有所述Application的请求并为之分配对应的服务，在接收到所述Application的请求时，根据包名取出所请求的Binder引用，然后调用该Binder的接口，转发数据。

3.如权利要求2所述的应用层的进程间通信方法，其特征是：

所述保存对象步骤中，Application在与守护进程IPCService绑定服务成功之后，将各个继承自某一Activity和某一Service的实例对象保存在对应表中，以便接收数据的时候可以分发到各个具体的Activity和Service对象。

4.如权利要求3所述的应用层的进程间通信方法，其特征是：所述发送数据的具体流程包括：由Application将要通信的数据封装成包括包头header和数据体body的数据结构中；将组装好的数据包发送给守护进程IPCService，然后由守护进程IPCService处理和转发。

5.如权利要求3所述的应用层的进程间通信方法，其特征是：所述接收数据步骤中，Application接收到数据包以后，将接收到的数据包放入一个用于处理接收到的数据包的命令池里，由一个线程从该命令池中取数据包，解析数据包的头部，根据具体的Activity名或者Service名，从所述对应表中查询出具体的Activity实例，然后交给具体的Activity实例去处理具体的数据包。

6.如权利要求1所述的应用层的进程间通信方法，其特征是：Application A向Application B发送数据的具体流程包括：Application A向守护进程IPCService发出服务请求，守护进程IPCService接收到Application A的请求时，处理发送到的数据包的头部，解析出被发送的对象Application B，然后从保存的对应表中取出Application B的Binder引用，调用Application B的引用，数据被发送到了Application B。

7.如权利要求4所述的应用层的进程间通信方法，其特征是：所述包头header包括发送方身份信息、发送目的地、通信命令、优先级、回复字段，

发送方身份信息，包含发送数据方的包名，Activity或者Service名，由应用层自动组装和获取；

发送目的地，指数据要发送到某个包中的某个Activity或者Service，由具体实现发送命令的使用者传递参数；

通信命令，代表某一协商好的、双方用来通信的协议；

优先级，命令的优先级，区分守护进程IPCService处理命令的优先级；回复，是否需要立即回复的标识。

8.一种基于Android的基础应用通信系统，包括：

守护进程IPCService，用于进程间通信服务，虚拟为服务器端；所述Application向守护进程IPCService注册绑定，各个所述Application通过所述守护进程IPCService实现各个应用的互相通信；

所述框架封装Application，用于实现绑定服务、保存对象、发送数据和接收数据步骤；

所述绑定服务步骤中，Application在Activity和Service在oncreated()时，向ServiceManager发送申请IPCService服务的请求，利用Binder机制，由ServiceManager绑定所述Application和IPCService之间的服务机制；

所述绑定服务的具体流程包括：

S12.Binder驱动为守护进程IPCService创建成为内核中的守护进程IPCService的Binder实体节点以及Binder的引用，即通知ServiceManager注册一个用于进程间通信服务、称为守护进程IPCService的服务；

S13.ServiceManager收到数据包之后，从中取出守护进程IPCService的名字和引用，填入查找表中；

9.如权利要求8所述的基础应用通信系统，其特征是：

所述守护进程IPCService，管理所有Application服务，保存所有通信应用的包名，将应用的包名和Binder引用一一对应，实现任何包对包的通信；响应所有Application的请求并为之分配对应的服务，在接收到Application的请求时，根据包名取出所请求的Binder引用，然后调用该Binder的接口，转发数据。

10.如权利要求9所述的基础应用通信系统，其特征是：

11.如权利要求10所述的基础应用通信系统，其特征是：所述发送数据的具体流程包括：由Application将要通信的数据封装成由包头header和数据体body组成的数据结构中；将组装好的数据包发送给守护进程IPCService，然后由守护进程IPCService处理和转发。

12.如权利要求10所述的基础应用通信系统，其特征是：所述接收数据步骤中，Application接收到数据包以后，将接收到的数据包放入一个用于处理接收到的数据包的命令池里，由一个线程从该命令池中取数据包，解析数据包的头部，根据具体的Activity名或者Service名，从所述对应表中查询出具体的Activity实例，然后交给具体的Activity实例去处理具体的数据包。

13.如权利要求8所述的应用通信系统，其特征是：Application A向Application B发送数据的具体流程包括：Application A向守护进程IPCService发出服务请求，守护进程IPCService接收到Application A的请求时，处理发送到的数据包的头部，解析出被发送的对象Application B，然后从保存的对应表中取出Application B的Binder引用，调用Application B的引用，数据被发送到了Application B。

14.如权利要求13所述的基础应用通信系统，其特征是：数据头header包括发送方身份信息、发送目的地、通信命令、优先级、回复字段，

发送方身份信息，包含发送数据方的包名，Activity或者Service名，由Application层自动组装和获取；

通信命令，代表某一协商好的、双方用来通信的协议；

优先级，命令的优先级，区分守护进程IPCService处理命令的优先级；

回复，是否需要立即回复的标识。

15.一种智能终端，应用如权利要求1-7中任一项所述的基于Android的应用层的进程间通信方法，实现各个Application的互相通信。

16.一种智能电视终端，固化有如权利要求8-14中任一项所述的基于Android的基础应用通信系统。