视图融合方法、装置、设备及存储介质

技术领域

本申请涉及视图技术领域，尤其涉及一种视图融合方法、装置、设备及存储介质。

背景技术

在智能座舱开发生产实际中，存在大量的多应用程序的业务UI同界面嵌套展示的情况。

针对这种情况的解决方案一般有两种：一种是使用aosp(Android Open SourceProject)原生的App Widget Service技术，但是存在严重的视图开发限制，比如动画效果限制、UI开发技术限制等。另一种是使用插件化技术通过path class loader加载其他应用程序的视图，但是存在对主体应用程序很大的侵入性，比如会损耗主体应用程序的性能以及波及主体应用程序安全性风险等。

可见，亟需一种视图融合方案满足同界面嵌套展示需求并可以克服现有解决方案存在的缺陷。

发明内容

本申请提供一种视图融合方法、装置、设备及存储介质，用于提供一种视图融合解决方案满足应用程序的UI界面嵌套展示的需求且可以克服现有技术存在的缺陷。

第一方面，本申请提供一种视图融合方法，应用于扩展服务系统，所述扩展服务系统提供视图绑定服务；所述方法，包括：

接收第一应用程序上报的视图融合请求，所述视图融合请求用于指示所述第一应用程序请求融合第二应用程序的视图；

响应所述视图融合请求为所述第一应用程序注册视图表面，并将所述视图表面传输至所述第二应用程序的进程，使得所述第二应用程序将所述视图表面作为绘制区域得到目标视图。

在一种可能的设计中，所述视图融合方法，还包括：

接收所述第一应用程序于所述目标视图检测到的触摸操作对应的触摸事件；

分发所述触摸事件至所述第二应用程序的进程，使得所述第二应用程序处理所述触摸事件。

在一种可能的设计中，在接收第一应用程序上报的视图融合请求之前，还包括：

继承安卓系统原生服务，并使用接口定义语言将自身binder地址通过binder驱动开放，以使得所述扩展服务系统具备跨进程通讯能力；

将所述视图绑定服务注册至所述安卓系统的系统服务器中以进行预加载，使得所述扩展服务系统与所述安卓系统同步启动。

在一种可能的设计中，所述目标视图是所述第二应用程序将所述视图表面作为所述绘制区域使用预设视图开发框架进行UI开发以及使用预设渲染框架对所述绘制区域进行视图渲染得到。

在一种可能的设计中，所述扩展服务系统应用于车机的车载娱乐信息系统。

在一种可能的设计中，所述第一应用程序或所述第二应用程序包括运行于所述车机的任意可运行应用程序。

第二方面，本申请提供一种视图融合装置，应用于扩展服务系统，所述扩展服务系统提供视图绑定服务；所述装置，包括：

接收模块，用于接收第一应用程序上报的视图融合请求，所述视图融合请求用于指示所述第一应用程序请求融合第二应用程序的视图；

融合模块，用于响应所述视图融合请求为所述第一应用程序注册视图表面，并将所述视图表面传输至所述第二应用程序的进程，使得所述第二应用程序将所述视图表面作为绘制区域得到目标视图。

在一种可能的设计中，所述视图融合装置，还包括：事件分发模块；

所述接收模块，还用于接收所述第一应用程序于所述目标视图检测到的触摸操作对应的触摸事件；

所述事件分发模块，用于分发所述触摸事件至所述第二应用程序的进程，使得所述第二应用程序处理所述触摸事件。

在一种可能的设计中，所述视图融合装置，还包括：系统构建模块；所述系统构建模块，用于：

继承安卓系统原生服务，并使用接口定义语言将自身binder地址通过binder驱动开放，以使得所述扩展服务系统具备跨进程通讯能力；

将所述视图绑定服务注册至所述安卓系统的系统服务器中以进行预加载，使得所述扩展服务系统与所述安卓系统同步启动。

在一种可能的设计中，所述目标视图是所述第二应用程序将所述视图表面作为所述绘制区域使用预设视图开发框架进行UI开发以及使用预设渲染框架对所述绘制区域进行视图渲染得到。

在一种可能的设计中，所述扩展服务系统应用于车机的车载娱乐信息系统。

在一种可能的设计中，所述第一应用程序或所述第二应用程序包括运行于所述车机的任意可运行应用程序。

第三方面，本申请提供一种车机设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现第一方面中所提供的任意一种可能的视图融合方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第一方面中所提供的任意一种可能的视图融合方法。

第五方面，本申请提供一种计算机程序产品，包括计算机执行指令，该计算机执行指令被处理器执行时用于实现第一方面中所提供的任意一种可能的视图融合方法。

本申请提供一种视图融合方法、装置、设备及存储介质，该视图融合方法应用于扩展服务系统，扩展服务系统提供视图绑定服务。首先接收第一应用程序上报的视图融合请求，其中，视图融合请求用于指示第一应用程序请求融合第二应用程序的视图，然后响应视图融合请求为第一应用程序注册视图表面，并将视图表面传输至第二应用程序的进程，使得第二应用程序将视图表面作为绘制区域得到目标视图，从而达到将第二应用程序视图融合于第一应用程序的视图融合效果。与现有技术相比，目标视图由第二应用程序的进程将视图表面作为绘制区域完成，因此本申请实现的跨进程的视图融合，能够在减小主体应用程序也即第一应用程序的性能损耗和安全性的情况下，还可以解决安卓原生技术对视图开发限制的问题，具有广泛适应性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的一种视图融合方法的流程示意图；

图3为本申请实施例提供的另一种视图融合方法的流程示意图；

图4为本申请实施例提供的扩展服务系统的架构示意图；

图5为本申请实施例提供的一种视图融合装置的结构示意图；

图6为本申请实施例提供的另一种视图融合装置的结构示意图；

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的方法和装置的例子。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在智能座舱开发生产实际中，存在大量的多应用程序的业务UI同界面嵌套展示的情况。目前解决方案一般有两种：一种是使用aosp(Android Open Source Project)原生的App Widget Service技术，但是存在严重的视图开发限制，比如动画效果限制、UI开发技术限制等。另一种是使用插件化技术通过path class loader加载其他应用程序的视图，但是存在对主体应用程序很大的侵入性，比如会损耗主体应用程序的性能以及主体应用程序的安全性风险等。可见，亟需一种视图融合方案满足同界面嵌套展示需求并可以克服现有解决方案存在的缺陷。

针对现有技术中存在的上述问题，本申请提供一种视图融合方法、装置、设备及存储介质。本申请提供的视图融合方法的发明构思在于：构建的扩展服务系统提供视图绑定服务，具备跨进程通讯能力，因此，其可以接收主体程序统称为第一应用程序的视图融合请求，响应该视图融合请求为第一应用程序注册视图表面(Surface)，进而可以传输该视图表面至第二应用程序的进程，第二应用程序即为第一应用程序想要融合其视图的应用程序，然后由第二应用程序将视图表面作为绘制区域得到目标视图，达到将第二应用程序的目标视图绘制在第一应用程序窗口的效果，实现视图融合。与现有技术相比，视图表面(Surface)作为几乎所有主流安卓(Android)视图开发技术(比如AndroidView、AndroidCompose、flutter等)的视图绘制媒介，在技术选择理论上没有瓶颈，因此可以避免现有技术中使用App Widget开发技术的动画以及开发技术选择限制等缺陷。此外，视图表面(Surface)是能够序列化传输的，当其被传输其他进程，例如第二应用程序的进程后，对应进程可以以其作为绘制区域，将视图效果跨进程绘制，从而避免主体程序例如第一应用程序与需要融合的应用程序例如第二应用程序处于一个进程运行，基于此则可以避免额外损耗主体应用程序进程的性能消耗，主体应用程序的进程也不会被融合的应用程序即第二应用程序的安全风险波及。

以下，对本申请实施例的示例性应用场景进行介绍。

图1为本申请实施例提供的一种应用场景示意图，如图1所示，扩展服务系统100配置于车辆200，例如可以配置于车辆200的车载娱乐信息系统(Infotainment Head Unit，IHU)，可以提供视图绑定服务(Surface Bind Service)。扩展服务系统100通过执行本申请实施例提供的视图融合方法可以将第二应用程序302的视图绘制在第一应用程序301的窗口，达到第二应用程序302与第一应用程序301的视图融合。与现有技术相比，本申请实施例提供的视图融合方法实现跨进程的视图融合，可以在减小主体应用程序也即第一应用程序301的性能损耗和安全性的情况下，还可以解决安卓原生技术对视图开发限制的问题，具有广泛适应性。

其中，第一应用程序301和第二应用程序302可以为车辆200中可运行的任意应用程序，对于第一应用程序301和第二应用程序302的具体内容不作限定。扩展服务系统100可以运行于车辆200的微控制单元(Microcontroller Unit，MCU)等电子设备中以执行本申请实施例提供视图融合方法，本申请实施例对于该电子设备的设备类型不作限定。另外，本申请实例对于车辆200亦不做限定，例如其可以为纯电动汽车、混动汽车、燃油汽车，亦或是船只等具有多应用程序视图融合需求的相应设备。

需要说明的是，上述应用场景仅仅是示意性的，本申请实施例提供的视图融合方法、装置、设备及存储介质包括但不仅限于上述各应用场景。

图2为本申请实施例提供的一种视图融合方法的流程示意图。如图2所示，该视图融合方法可以应用于扩展服务系统，其中扩展服务系统提供视图绑定服务。如图2所示，本申请实施例提供的视图融合方法，包括：

S101：接收第一应用程序上报的视图融合请求。

其中，视图融合请求用于指示第一应用程序请求融合第二应用程序的视图。

当第一应用程序具有添加其他应用程序例如第二应用程序的视图于自身窗口的意图时，第一应用程序向扩展服务系统上报自身的视图融合请求，相应地，扩展服务系统接收第一应用程序上报的视图融合请求。

其中，该视图融合请求则用于指示第一应用程序请求融合第二应用程序的视图，也即于请求在第一应用程序的窗口显示第二应用程序的视图。

S102：响应视图融合请求为第一应用程序注册视图表面。

扩展服务系统为提前配置好的，可以提供视图绑定服务，具备跨进程通讯能力，也即进程分离能力。其中，进程分离能力是指代码编译时分离、代码运行时分离的开发能力。因此，扩展服务系统接收到视图融合请求则响应视图融合请求为第一应用程序注册一个视图表面，也即Surface。

由于Surface可以作为几乎所有主流安卓视图开发技术的视图绘制媒介，故而，通过为第一应用程序注册Surface，并基于其具备的跨进程通讯能力将该Surface传输至第二应用程序的进程，将Surface作为绘制区域也即视图绘制媒介绘制对应视图，则在技术选择理论上没有瓶颈，从而可以避免现有技术中使用aosp原生的App Widget Service开发技术的动画以及开发技术选择等限制，可以克服现有技术第一种解决方案存在的缺陷。

S103：将视图表面传输至第二应用程序的进程，使得第二应用程序将视图表面作为绘制区域得到目标视图。

扩展服务系统将视图表面传输给第二应用程序的进程。第二应用程序接收到该视图表面后，可以将视图表面作为绘制区域将视图效果跨进程绘制从而得到目标视图。

视图表面(Surface)是能够序列化传输的，将其传输到其他进程后，对应进程可以以其作为绘制区域，将视图效果跨进程绘制。该特性则避免了Surface的主体应用程序即第一应用程序与需要融合的应用程序即第二应用程序渲染逻辑在一个进程运行，从而就可以避免额外损耗主体应用程序进程的性能消耗，主体应用程序进程也不会被需要融合的应用程序的安全风险波及，故而可以克服现有技术中第二种解决方案存在的缺陷。

在一种可能的设计中，第二应用程序将视图表面作为绘制区域得到目标视图的可能实现方式包括：

将视图表面作为绘制区域使用预设视图开发框架进行UI开发。其中，预设视图开发框架可以例如AndroidView、Android Compose或者Flutter等任意UI开发框架。例如，AndroidView作为预设视图开发框架时，在进行绘图的生命周期中，替换画板canvas为主体应用程序传递过来的视图表面(Surface)生成的画板进行UI开发；Android Compose作为预设视图开发框架时，基于Compose View开发，Compose View可以采用与AndroidView相同的方式进行UI开发；Flutter可直接在引擎中使用视图表面(Surface)，通过JNI传递。

使用上述任意一种预设视图开发框架进行UI开发之后，可以通过使用预设渲染框架对绘制区域进行视图渲染以得到目标视图。预设渲染框架可以例如Skia、Opengl等渲染引擎。例如，Skia是Android中的图像渲染库，可渲染2d图像；3D效果渲染可以依赖Opengl完成，其中Opengl为一种跨平台的3D图形绘制规范接口。

通过上述描述可见，第二应用程序接收到视图表面，可以采用例如AndroidView、Android Compose或者Flutter等任意UI开发框架进行UI开发，以及使用Skia、Opengl等渲染引擎针对Surface进行自定义的视图渲染，从而在减小主体应用程序性能损耗和安全性的情况下，还可以解决安卓原生技术存在的比如动画效果限制、UI开发技术限制等视图开发限制问题，从而达到较好技术效果。

本申请实施例提供的视图融合方应用于扩展服务系统，扩展服务系统提供视图绑定服务。首先接收第一应用程序上报的视图融合请求，其中，视图融合请求用于指示第一应用程序请求融合第二应用程序的视图，然后响应视图融合请求为第一应用程序注册视图表面，并将视图表面传输至第二应用程序的进程，使得第二应用程序将视图表面作为绘制区域得到目标视图，从而实现将第二应用程序视图融合于第一应用程序的视图融合效果。与现有技术相比，目标视图由第二应用程序的进程将视图表面作为绘制区域完成，因此本申请实现的跨进程的视图融合，能够在减小主体应用程序也即第一应用程序的性能损耗和安全性的情况下，还可以解决安卓原生技术对视图开发限制的问题，具有广泛适应性。

图3为本申请实施例提供的另一种视图融合方法的流程示意图，如图3所示，本申请实施例提供的视图融合方法，包括：

S201：继承安卓系统原生服务，并使用接口定义语言将自身binder地址通过binder驱动开放，使得扩展服务系统具备跨进程通讯能力。

扩展服务系统继承安卓系统的原生服务，并进一步使用接口定义语言(aidl)的跨进程通讯技术，将自身binder地址通过binder驱动开放出去，构建扩展服务系统的跨进程通讯能力，例如图4所示构建第一应用程序和第二应用程序之间的跨进程通讯能力。可选地，还可以提供对应binder的获取方式。

在一些实施例中，安卓系统的原生服务包括但不限于安卓系统中设置的原生应用程序接口(Application Program Interface，API)、多个原生应用程序以及每个应用程序所对应的多个进程及其上运行的各应用服务服务。

S202：将视图绑定服务注册至安卓系统的系统服务器中以进行预加载，使得扩展服务系统与安卓系统同步启动。

继续参照图4所示，将视图绑定服务(Surface Bind Service)注册到安卓系统的系统服务器(System Server)中进行预加载，构建扩展服务系统为系统级的服务，从而视图绑定服务会随着安卓系统启动时被拉起，也就是扩展服务系统与安卓系统同步启动。

S203：接收第一应用程序上报的视图融合请求。

其中，视图融合请求用于指示第一应用程序请求融合第二应用程序的视图。

S204：响应视图融合请求为第一应用程序注册视图表面。

S205：将视图表面传输至第二应用程序的进程，使得第二应用程序将视图表面作为绘制区域得到目标视图。

步骤S203至步骤S205的可能实现方式、原理及技术效果与步骤S101至步骤S103的可能实现方式、原理及技术效果相类似，详细内容可参考前述描述，在此不再赘述。

进一步地，得到的目标视图用于车机进行人机交互，也就是，用户可以对目标视图进行触摸操作，以在第一应用程序的窗口向第二应用程序发起触摸事件，故而，本申请实施例还包括如下步骤：

S206：接收第一应用程序于目标视图检测到的触摸操作对应的触摸事件。

目标视图显示于第一应用程序的窗口，当用户于第一应用程序的窗口对目标视图进行触摸操作，第一应用程序检测该触摸操作对应的触摸事件，并上报该触摸操作对应触摸事件至扩展服务系统，扩展服务系统则接收第一应用程序于目标视图检测到的该触摸操作对应的触摸事件。

S207：分发触摸事件至第二应用程序的进程，使得第二应用程序处理触摸事件。

扩展服务系统将用户对目标视图进行触摸操作对应的触摸事件序列化传递到第二应用程序的进程，也即将触摸事件分发至第二应用程序的进程，第二应用程序的进程接收该触摸事件，并实现对触摸事件的逻辑处理，从而实现视图融合时跨进程的触摸事件处理，触摸事件的处理不额外影响第一应用程序进程的性能损耗和安全性。

可以理解的是，目标视图的视图展示效果会跟随触摸事件的处理同步地发生变化，例如采用预测视图开发框架进行UI开发以及采用预设渲染框架进行视图渲染等，本申请实施例对于目标视图的视图展示效果的具体内容不作限定。

本申请实施例提供的视图融合方法，首先构建系统级的扩展服务系统，并使其具有跨进程通讯能力以具有提供视图绑定服务能力，在此基础上，当第一应用程序需要添加其他应用程序的视图时，向扩展服务系统上报视图融合请求，扩展服务系统响应视图融合请求为第一应用程序注册视图表面，并序列号传输视图表面至第一应用程序需要添加的该其他应用程序的进程，使得该其他应用程序将视图表面作为绘制区域绘制视图得到目标视图，从而将该其他应用程序的视图绘制到第一应用程序的窗口，实现视图融合效果。并且用户可以于第一应用程序的窗口对第一应用程序所融合的其他应用程序进行触摸操作，第一应用程序检测触摸操作对应触摸事件并将触摸事件上报给扩展服务系统，扩展服务系统分发触摸事件至该其他应用程序，使得该其他应用程序处理触摸事件。同时，目标视图可以同步视图展示效果。本申请实施例提供的视图融合方法与现有技术相比，目标视图由第一应用程序需要融合的该其他应用程序例如第二应用程序的进程将第一应用程序注册的视图表面作为绘制区域完成，从而可以实现跨进程的视图融合，并且能够在减小主体应用程序也即第一应用程序的性能损耗和安全性的情况下，还可以解决安卓原生技术对视图开发限制的问题，具有广泛适应性。

另外需要说明的是，对于开发者而言，对扩展服务系统的视图绑定服务(SurfaceBind Service)功能的实现可以通过构建Surface Bind SDK工具包完成。其中，构建Surface Bind SDK工具包的具体实现如下：

1、封装链接Surface Bind Service方式，通过Surface Bind Service开放的服务链接方式绑定服务；

2、封装注册视图表面Surface方式，可以通过工具为主体应用程序生成视图表面Surface；

3、封装视图表面Surface生命周期回调，可回调主体应用程序视图表面Surface的生命周期；

4、封装触摸事件传递过程，可回调用户对目标视图进行触摸操作发起的触摸事件。

上述仅是从开发者角度说明构建Surface Bind SDK工具包的可能方式，但对于视图绑定服务的实现不仅限于上述构建Surface Bind SDK工具包的方式。

图5为本申请实施例提供的一种视图融合装置的结构示意图，该视图融合装置可应用于扩展服务系统，扩展服务系统提供视图绑定服务。如图5所示，本申请实施例提供的视图融合装置400，包括：

接收模块401，用于接收第一应用程序上报的视图融合请求，视图融合请求用于指示第一应用程序请求融合第二应用程序的视图；

融合模块402，用于响应视图融合请求为第一应用程序注册视图表面，并将视图表面传输至第二应用程序的进程，使得第二应用程序将视图表面作为绘制区域得到目标视图。

在图5基础上，图6为本申请实施例提供的另一种视图融合装置的结构示意图。如图6所示，本申请实施例提供的视图融合装置400，还包括：事件分发模块403；

其中，接收模块401，还用于接收第一应用程序于目标视图检测到的触摸操作对应的触摸事件；

事件分发模块402，用于分发触摸事件至第二应用程序的进程，使得第二应用程序处理触摸事件。

在一种可能的设计中，视图融合装置400，还包括：系统构建模块，该系统构建模块，用于：

继承安卓系统原生服务，并使用接口定义语言将自身binder地址通过binder驱动开放，以使得扩展服务系统具备跨进程通讯能力；

将视图绑定服务注册至安卓系统的系统服务器中以进行预加载，使得扩展服务系统与安卓系统同步启动。

在一种可能的设计中，目标视图是第二应用程序将视图表面作为绘制区域使用预设视图开发框架进行UI开发以及使用预设渲染框架对绘制区域进行视图渲染得到。

在一种可能的设计中，扩展服务系统应用于车机的车载娱乐信息系统。

在一种可能的设计中，第一应用程序或第二应用程序包括运行于车机的任意可运行应用程序。

本申请实施例提供的视图融合装置，可以执行上述方法实施例中视图融合方法的相应步骤，其实现原理和技术效果类似，在此不再赘述。

图7为本申请实施例提供的一种电子设备的结构示意图，如图7所示，该电子设备500可以包括：处理器501，以及与处理器501通信连接的存储器502。

存储器502，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机执行指令。

存储器502可能包含高速RAM存储器，也可能还包括非易失性存储器(NoN-volatile memory)，例如至少一个磁盘存储器。

处理器501用于执行存储器502存储的计算机执行指令，以实现上述各实施例提供的视图融合方法。

其中，处理器501可能是一个中央处理器(Central Processing Unit，简称为CPU)，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。

可选地，存储器502既可以是独立的，也可以跟处理器501集成在一起。当存储器502是独立于处理器501之外的器件时，电子设备500，还可以包括：

总线503，用于连接处理器501以及存储器502。总线可以是工业标准体系结构(industry standard architecture，简称为ISA)总线、外部设备互连(peripheralcomponent，PCI)总线或扩展工业标准体系结构(extended industry standardarchitecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器502和处理器501集成在一块芯片上实现，则存储器502和处理器501可以通过内部接口完成通信。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccessMemory)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有计算机执行指令，计算机执行指令用于上述实施例中方法的各步骤。

本申请还提供了一种计算机程序产品，包括计算机执行指令，该计算机指令被处理器执行时实现上述实施例中方法的各步骤。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。