插件加载系统的构建方法、插件加载系统及计算设备与流程

1.本发明涉及计算机技术领域，尤其涉及一种插件加载系统的构建方法、插件加载系统及计算设备。


背景技术：

2.目前，由于传统开发下的单体应用程序，往往随着新的业务开发，和无数次的版本的迭代，导致代码膨胀，对开发人员维护工作难度造成指数级的增长，再去开发一个新功能，就会需要维护之前所有老功能，开发人员在这样的环境下进行开发，高昂的开发成本，以至于到后期重构所有代码。而现有的实现单体应用为采用osgi(open service gateway initiative，面向java的动态模型系统)技术进行插件化动态组合。而基于传统osgi插件开发模式会因为插件层级划分与模块划分问题导致组合软件时引发业务关联逻辑混乱、物理隔离特性丢失等问题。本专利将提出插件层架划分与模块划分的优化方法，最终解决软件关联逻辑混乱、物理隔离特性丢失等问题。
3.现有技术中的c++插件框架分层架构通常采用传统的osgi思想，基于osgi层级划分结构的插件框架包括ctk、cppmicroservices等，其内部指导思想是将service(插件服务)封装在的bundle(插件)内部。基于这种插件框架的插件加载原理示意图参见图1所示。osgi中每个bundle闭包插件层都拥有发布service插件服务的能力，而bundle不但拥有业务逻辑代码闭包，还具有对外提供接口的能力。在加载bundle c时，需要预先加载bundle a、b。而bundle c使用bundlea、b中的接口，bundle c将直接依赖于bundle a、b。
4.以现有插件ctk或cppmicroservices为例，现有插件化技术存在如下缺点：物理隔离丢失导致模块耦合度较高，具体地，由于bundle会依赖service，存在逻辑的强关联，而service定义为与bundle一致的类型，导致后续开发内部耦合度不断叠加。在常用做法中通常将service统一打包为单一动态库，更改内部逻辑源码后，只能重新构建生成动态库，随着动态库业务功能的增加，源码将不断膨胀，导致更改一行代码需要重新编译的时间较长，编译效率低。由于bundle与service闭包为一个插件，扩展service必将改动bundle，导致service的扩展方式不灵活。
5.为此，需要一种插件加载系统的构建方法，以解决现有技术中存在的问题。


技术实现要素：

6.为此，本发明提供一种插件加载系统的构建方法、插件加载系统及计算设备，以解决或至少缓解上面存在的问题。
7.根据本发明的一个方面，提供一种插件加载系统的构建方法，构建一个或多个插件服务，基于一个或多个插件服务构建插件服务层；在所述插件服务层的下层构建一个或多个插件模块，基于一个或多个插件模块形成插件层，其中，插件层的每个插件模块动态链接于所述插件服务层，且所述一个或多个插件模块之间相互隔离；以及在所述插件层的下层构建执行程序，所述执行程序适于加载一个或多个插件模块，以便调用与所述插件模块
动态链接的插件服务层的插件服务。
8.可选地，在根据本发明的插件加载系统的构建方法中，所述插件服务适于发布服务接口，并通过服务接口与一个或多个插件模块通信，以便一个或多个插件模块通过服务接口访问所述服务模块。
9.可选地，在根据本发明的插件加载系统的构建方法中，所述插件服务包括文件读取服务。
10.可选地，在根据本发明的插件加载系统的构建方法中，基于一个或多个插件模块构建插件层的步骤包括：构建核心插件模块，设置所述核心插件模块引用所述文件读取服务；构建发送者插件模块，设置所述发送者插件模块引用所述文件读取服务；构建处理者插件模块，设置所述处理者插件模块引用所述文件读取服务；基于所述核心插件模块、发送者插件模块和处理者插件模块形成插件层。
11.可选地，在根据本发明的插件加载系统的构建方法中，还包括步骤：调用导入接口，以将新的插件服务导入所述插件服务层；调用导出接口，以删除所述插件服务层的插件服务。
12.可选地，在根据本发明的插件加载系统的构建方法中，基于全局服务表来管理插件服务层的插件服务；所述全局服务表中包括一个或多个插件服务函数，每个插件服务函数对应插件服务层的一个插件服务。
13.可选地，在根据本发明的插件加载系统的构建方法中，调用导入接口，以将新的插件服务导入所述插件服务层，包括：调用所述导入接口中的addimporter函数，以便将新的插件服务函数导入所述全局服务表中。
14.可选地，在根据本发明的插件加载系统的构建方法中，调用导出接口，以删除所述插件服务层的插件服务，包括：调用所述导出接口中的delimporter函数，以便删除全局服务表中的插件服务函数。
15.根据本发明的一个方面，提供一种插件加载系统，包括：插件服务层，包括一个或多个插件服务；插件层，布置在所述插件服务层的下层，所述插件层包括一个或多个插件模块，其中，每个插件模块动态链接于所述插件服务层，且所述一个或多个插件模块之间相互隔离；以及执行程序，布置在所述插件层的下层，所述执行程序适于加载一个或多个插件模块，以便调用与所述插件模块动态链接的插件服务层的插件服务。
16.根据本发明的一个方面，提供一种计算设备，包括：至少一个处理器；存储器，存储有程序指令，其中，程序指令被配置为适于由上述至少一个处理器执行，所述程序指令包括用于执行如上所述的插件加载系统的构建方法的指令。
17.根据本发明的一个方面，提供一种存储有程序指令的可读存储介质，当该程序指令被计算设备读取并执行时，使得该计算设备执行如上所述的插件加载系统的构建方法。
18.根据本发明的技术方案，提供了一种插件加载系统的构建方法及其构建的插件加载系统，其中，插件服务与插件模块采用分离式结构并位于不同层级，插件层的每个插件模块依赖于统一的插件服务层，而插件服务层并不依赖插件层。基于这种单向关联的层级关系，使得插件层的每个插件模块可以使用插件服务层的插件服务，而且，各个插件模块之间不存在动态链接的关联关系，实现了各个插件模块之间的物理隔离特性，能够从根源上解决插件隔离丢失的问题。
19.另外，在根据本发明的技术方案实现对插件服务进行分离后，分离后的插件服务为单独的动态库，当需要对插件服务进行扩展时，无需重新编译插件模块，只需构建插件服务，从而实现灵活扩展插件服务，而且，节省了构建时间，提高了构建效率。
20.上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
21.为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。
22.图1示出了现有技术中的插件加载原理示意图；
23.图2示出了根据本发明一个实施例的计算设备200的示意图；
24.图3示出了根据本发明一个实施例的插件加载系统的构建方法300的流程图；
25.图4示出了根据本发明一个实施例的插件加载系统400的示意图；
26.图5示出了对现有技术中的插件进行分离后形成插件服务层和插件层的示意图；以及
27.图6示出了根据本发明一个实施例的插件模块与插件服务分离的结构示意图。
具体实施方式
28.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
29.图2示出了根据本发明一个实施例的计算设备200的示意图。
30.如图2所示，在基本的配置202中，计算设备200典型地包括系统存储器206和一个或者多个处理器204。存储器总线208可以用于在处理器204和系统存储器206之间的通信。
31.取决于期望的配置，处理器204可以是任何类型的处理，包括但不限于：微处理器(up)、微控制器(uc)、数字信息处理器(dsp)或者它们的任何组合。处理器204可以包括诸如一级高速缓存210和二级高速缓存212之类的一个或者多个级别的高速缓存、处理器核心214和寄存器216。示例的处理器核心214可以包括运算逻辑单元(alu)、浮点数单元(fpu)、数字信号处理核心(dsp核心)或者它们的任何组合。示例的存储器控制器218可以与处理器204一起使用，或者在一些实现中，存储器控制器218可以是处理器204的一个内部部分。
32.取决于期望的配置，系统存储器206可以是任意类型的存储器，包括但不限于：易失性存储器(诸如ram)、非易失性存储器(诸如rom、闪存等)或者它们的任何组合。系统存储器206可以包括操作系统220、一个或者多个应用222以及程序数据224。应用222实际上是多条程序指令，其用于指示处理器204执行相应的操作。在一些实施方式中，应用222可以布置
为在操作系统上使得处理器204利用程序数据224进行操作。
33.计算设备200还包括储存设备232，储存设备232包括可移除储存器236和不可移除储存器238。
34.计算设备200还可以包括储存接口总线234。储存接口总线234实现了从储存设备232(例如，可移除储存器236和不可移除储存器238)经由总线/接口控制器230到基本配置202的通信。操作系统220、应用222以及数据224的至少一部分可以存储在可移除储存器236和/或不可移除储存器238上，并且在计算设备200上电或者要执行应用222时，经由储存接口总线234而加载到系统存储器206中，并由一个或者多个处理器204来执行。
35.计算设备200还可以包括有助于从各种接口设备(例如，输出设备242、外设接口244和通信设备246)到基本配置202经由总线/接口控制器230的通信的接口总线240。示例的输出设备242包括图形处理单元248和音频处理单元250。它们可以被配置为有助于经由一个或者多个a/v端口252与诸如显示器或者扬声器之类的各种外部设备进行通信。示例外设接口244可以包括串行接口控制器254和并行接口控制器256，它们可以被配置为有助于经由一个或者多个i/o端口258和诸如输入设备(例如，键盘、鼠标、笔、语音输入设备、触摸输入设备)或者其他外设(例如打印机、扫描仪等)之类的外部设备进行通信。示例的通信设备246可以包括网络控制器260，其可以被布置为便于经由一个或者多个通信端口264与一个或者多个其他计算设备262通过网络通信链路的通信。
36.网络通信链路可以是通信介质的一个示例。通信介质通常可以体现为在诸如载波或者其他传输机制之类的调制数据信号中的计算机可读指令、数据结构、程序模块，并且可以包括任何信息递送介质。“调制数据信号”可以这样的信号，它的数据集中的一个或者多个或者它的改变可以在信号中以编码信息的方式进行。作为非限制性的示例，通信介质可以包括诸如有线网络或者专线网络之类的有线介质，以及诸如声音、射频(rf)、微波、红外(ir)或者其它无线介质在内的各种无线介质。这里使用的术语计算机可读介质可以包括存储介质和通信介质二者。
37.在根据本发明的实施例中，计算设备200被配置为执行根据本发明的插件加载系统的构建方法300。计算设备200的应用中包含用于执行本发明的插件加载系统的构建方法300的多条程序指令，这些程序指令可以指示处理器执行本发明的插件加载系统的构建方法300，以便计算设备200通过执行插件加载系统的构建方法300来构建插件加载系统。
38.图3示出了根据本发明一个实施例的插件加载系统的构建方法300的流程图。方法300适于在计算设备(例如前述计算设备200)中执行。
39.如图3所示，方法300始于步骤s310。
40.在步骤s310中，构建一个或多个插件服务，并基于一个或多个插件服务构建插件服务层。这里，每个插件服务均是独立于插件存在的服务模块，每个插件服务是单独的动态库。
41.需要说明的是，插件服务层也即是插件服务动态库，插件服务层可作为多个插件模块统一的依赖库。
42.如前文所述，现有技术中的插件是耦合度较高的闭包结构，将插件服务封装在插件内部，即，将插件模块与插件服务闭包为一个闭包插件。
43.而根据本发明的技术方案，对闭包插件进行了分离处理，将每个闭包插件内的插
件服务分离出来，成为独立的插件服务，每个插件服务并不依赖于插件。进而，基于多个独立的插件服务来构建形成插件服务层，作为多个插件模块统一的动态依赖库。
44.在步骤s320中，在插件服务层的下层构建一个或多个插件模块，基于一个或多个插件模块形成插件层。这里，插件层的每个插件模块动态链接于插件服务层。也就是说，插件层的每个插件模块基于动态链接的方式依赖于插件服务层。并且，插件层的一个或多个插件模块之间相互隔离，不存在依赖关系。
45.在一种实现方式中，每个插件模块基于osgi动态化模块化系统的规范来构建。每个插件模块均采用动态库物理隔离的模块，使得构建得到的一个或多个插件模块之间实现物理隔离。
46.在步骤s330中，在插件层的下层构建一个或多个执行程序，执行程序可以动态加载一个或多个插件模块，以便调用与插件模块动态链接的插件服务层的插件服务。
47.这样，便基于在上述步骤中构建的插件服务层、依赖于插件服务层的插件层、以及一个或多个执行程序，形成了插件加载系统。
48.应当指出，根据本发明的方法300所构建的插件加载系统400，插件层依赖于插件服务层，而插件服务层并不依赖插件层。基于这种单向关联的层级关系，使得插件层的每个插件模块可以使用插件服务层的一个或多个插件服务。并且，各个插件模块之间不存在动态链接的关联关系，实现了各个插件模块之间的物理隔离特性，并且，保持了原有的插件的功能实现。
49.需要说明的是，分离后的插件服务为单独的动态库，本发明可以以插件服务关联的命名方式来构建插件服务的动态库。
50.在一个实施例中，在步骤s310中所构建的一个或多个插件服务例如包括文件读取服务。在构建文件读取服务的动态库之后，构建一个或多个插件模块、基于一个或多个插件模块来构建插件层包括以下步骤：
51.构建核心插件模块，设置核心插件模块引用文件读取服务。构建发送者插件模块，设置发送者插件模块引用文件读取服务。构建处理者插件模块，设置处理者插件模块引用文件读取服务。基于核心插件模块、发送者插件模块和处理者插件模块形成插件层。这样，能实现所构建的各个插件模块之间相互隔离，并且每个插件模块分别动态链接于所构建的文件读取服务。
52.具体代码可以实现为：
53.add_librarys(fileio-service fileio.h fileio.cpp)//构建文件读取服务动态库；
54.add_librarys(coreplugin coreplugin.h coreplugin.cpp)//构建核心插件；
55.target_link_libraries(senderplugin shared fileio-service)//核心插件引用读取服务，如果核心插件并无fileio.h或者file.cpp的函数调用则此处不需要该行；
56.add_librarys(senderplugin coreplugin.h senderplugin.cpp)//构建发送者插件；
57.target_link_libraries(senderplugin shared fileio-service)//发送者插件引用读取服务；
58.add_librarys(handlerplugin handlerplugin.h handlerplugin.cpp)//构建处
理者插件；
59.target_link_libraries(handlerplugin shared fileio-service)//处理者插件引用读取服务；
60.add_execute(application)//构建执行程序。
61.还需要说明的是，基于上述构建方法，插件服务为单独的动态库，当需要扩展新的插件服务时，通过构建新的插件服务的动态库，将一个或多个插件模块与新的插件服务建立关联，便可以实现对插件服务的扩展。而不需要对插件模块进行更改。
62.图4示出了根据本发明的一个实施例的插件加载系统400的示意图。插件加载系统400驻留在计算设备(例如前述计算设备200)中。如图4所示，插件加载系统400包括插件服务层410、插件层420、一个或多个执行程序430，其中，插件服务层410包括一个或多个插件服务，插件层420包括一个或多个插件模块。插件层420布置在插件服务层410的下层，并且动态链接于插件服务层410。插件层410的每个插件模块动态链接于插件服务层420，并且，一个或多个插件模块之间相互隔离。一个或多个执行程序430布置在插件层420的下层，执行程序430可以加载插件层420的一个或多个插件模块，以便通过插件模块来调用与插件模块动态链接的插件服务层410的插件服务。
63.在一种实现方式中，如图4所示，插件服务层410例如包括serviceb、servicec、serviced和servicee等插件服务。插件层420例如包括bundlea、bundleb、bundlec、bundled、bundlee和bundlef等插件模块。插件层410的每个插件模块可以基于动态链接的方式动态依赖于插件服务层420。
64.可以理解，在该插件加载系统400中，各个插件模块之间并不存在动态链接的关联关系，从而解决了现有技术中的各个插件之间的链式动态库关联问题以及环形节点问题。
65.在一种实现方式中，如图5所示，可以根据本发明的插件加载系统的构建方法，来对图1所示的现有的插件加载方案进行改造，形成图5所示的插件服务层410和插件层420。具体地，通过将每个插件包中的插件服务service分离出来，基于分离出来的service构建插件服务层410，并基于分离出插件服务之后的插件模块来形成插件层420。如图5所示，插件服务层包含servicea和serviceb，插件层包含独立的bundlea、bundleb和bundle c，其中，bundlea、bundleb、bundle c之间实现了物理隔离，不存在动态链接依赖关系。基于这种层级关系，将原有的动态依赖关系(bundle c依赖于bundlea、bundleb)改变为bundle c依赖于servicea、serviceb。
66.根据本发明的实施例，插件服务层的每个插件服务可以发布服务接口，通过服务接口可以与一个或多个插件模块通信，这样，一个或多个插件模块可以通过服务接口来访问插件服务。
67.需要说明的是，根据本发明的插件加载系统的构建方法300所构建的插件加载系统，插件模块与插件服务是分离式结构。本发明所构建的每个插件模块只包括平台特性模块(框架特性模块)，平台特性模块用于发布插件接口。而服务接口是由插件服务层的插件服务来发布，服务接口并不依赖插件的平台特性模块。
68.图6示出了根据本发明一个实施例的插件模块与插件服务分离的结构示意图。如图6所示，在插件服务servicea从一个插件包bundlea分离出来后，依赖于bundlea的bundleb能够访问的服务接口是由servicea进行发布，其不会依赖于bundle a发布的平台
特性模块，也不会存在访问插件接口interface module b的问题，从而实现了物理隔离。
69.而现有技术中的闭包插件包括插件服务以及平台特性模块，插件对外暴露服务接口和插件接口，插件接口依赖于服务接口的主要访问调用为服务接口访问。而在插件a的平台特性模块在随着接口一起对外发布时，意味着其他插件b同样对插件a的插件接口具有相同的访问权利，甚至可以通过源码#define private public进行私有作用域破坏，致使插件a不能实现将插件服务与平台特性模块模块隔离的效果。
70.根据本发明的实施例，通过监听服务导入和服务导出，以便对插件服务层的插件服务进行扩展。具体地，插件服务层提供有导入接口和导出接口，通过调用导入接口可以将一个或多个新的插件服务导入至插件服务层。另外，还可以通过调用导出接口，来删除插件服务层中当前已有的一个或多个插件服务。
71.在一种实现方式中，基于全局服务表来管理插件服务层的插件服务。其中，全局服务表中包括一个或多个插件服务函数，每个插件服务函数分别对应插件服务层的一个插件服务。
72.在对插件服务进行导入或导出时，可以向全局服务表导入插件服务函数来实现对插件服务的导入；相应地，通过删除全局服务表中的插件服务函数来实现对插件服务的导出。
73.在一种实现方式中，导入接口包括addimporter函数，导出接口包括delimporter函数。在调用导入接口时，具体是通过调用导入接口中的addimporter函数，来将新的插件服务函数导入全局服务表中，从而实现通过调用导入接口将新的插件服务导入至插件服务层。
74.在调用导出函数时，具体是通过调用导出接口中的delimporter函数，来删除全局服务表中的插件服务函数，从而实现通过调用导出接口来删除插件服务层中当前已有的插件服务。
75.在一种实现方式中，可以采用宏定义的方式实现插件服务的导入和导出，其中关键代码例如为：
[0076][0077]
以上代码实现为服务抽象接口类与服务标识接口宏，其中abstractservice类为服务抽象类，plugin_service(x)标识abstractservice在构造时，将自己加入全局服务表中。该抽象接口类与服务标识接口宏存在如下的使用方式：
[0078]
class interactiveservice:public abstractservice
[0079]
{q_object
[0080]
plugin_service(interactiveservice)
[0081]
}
[0082]
在一种实现方式中，可以通过以下代码来实现对导入/导出插件服务的监听：
[0083]
#define import_service(x)\
[0084]
nullptr＝＝extensions::pluginserviceglobal::findservice《x》(#x)？\
[0085]
new x(this):extensions::pluginserviceglobal::findservice《x》(#x)；\
[0086]
extensions::pluginserviceglobal::addimporter(#x,this-》metaobject()-》class name())；
[0087]
#define export_service(x)\
[0088]
nullptr＝＝extensions::pluginserviceglobal::findservice《x》(#x)？\
[0089]
0:extensions::pluginserviceglobal::delfreeservice《x》(#x)；\
[0090]
extensions::pluginserviceglobal::delimporter(#x)。
[0091]
其中，在import_service(x)与export_service(x)中，x参数为实现的插件服务函数。
[0092]
在导入接口import_service的宏函数中，使用全局服务表具有的addimporter函数，可以实现添加插件服务函数x到全局服务表中。
[0093]
在导出接口export_service中，使用全局服务表具有的delimporter函数，可以实现从全局服务表中删除插件服务函数x。
[0094]
另外，获取服务对象可以通过调用全局服务表中的访问函数来实现对插件服务的访问，具体代码如下：
[0095]
template《class t＝pluginservice》
[0096]
static t*findservice(const qstring&servicename)
[0097]
{
[0098]
return static_cast《t*》(s_services.value(servicename))；
[0099]
}。
[0100]
根据本发明的插件加载系统的构建方法所构建的插件加载系统，插件服务与插件模块采用分离式结构并位于不同层级，插件层的每个插件模块依赖于统一的插件服务层，而插件服务层并不依赖插件层。基于这种单向关联的层级关系，使得插件层的每个插件模块可以使用插件服务层的插件服务，而且，各个插件模块之间不存在动态链接的关联关系，实现了各个插件模块之间的物理隔离特性，能够从根源上解决插件隔离丢失的问题。
[0101]
另外，在根据本发明的技术方案实现对插件服务进行分离后，分离后的插件服务为单独的动态库，当需要对插件服务进行扩展时，无需重新编译插件模块，只需构建插件服务，从而实现灵活扩展插件服务，而且，节省了构建时间，提高了构建效率。
[0102]
这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如可移动硬盘、u盘、软盘、cd-rom或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践
本发明的设备。
[0103]
在程序代码在可编程计算机上执行的情况下，移动终端一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明的插件加载系统的构建方法。
[0104]
以示例而非限制的方式，可读介质包括可读存储介质和通信介质。可读存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在可读介质的范围之内。
[0105]
在此处所提供的说明书中，算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与本发明的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
[0106]
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0107]
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
[0108]
本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。
[0109]
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0110]
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。
[0111]
此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行
所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。
[0112]
如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。
[0113]
尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的而非限制性的，本发明的范围由所附权利要求书限定。