本申请涉及计算机
技术领域：
：，尤其涉及一种条目列表获取请求处理方法及装置。
背景技术：
：：随着计算机技术和互联网技术的迅速发展，各类应用层出不穷，给人们的生活带来了极大便利。应用可以采用丰富的信息展现方式向用户展现各类信息，对于用条目表示的信息，一般采用条目列表的形式进行展现，比如，商品条目列表、文章条目列表、消息条目列表等。受限于通信通道容量和处理时间要求，不便于一次获取到包含全部条目的条目列表并展现，而是需要分次获取并展现，其中，每次获取的条目列表包含一批至多预定数量的条目。进一步地，每次还要向用户提示是否存在更多条目以供下次获取。在现有技术中，用户每次可以通过在相应的页面上执行特定操作，向服务端发送条目列表获取请求。所述特定操作可以是上拉操作、或下拉操作、或对诸如“查看更多”等按钮控件的点击操作，等等。服务端每次接收到用户的条目列表获取请求时，会执行以下至少两次数据库操作：第一次，从数据库获取下一批至多预定数量的条目；第二次，从数据库获取所述下一批条目以及下一批条目之后的所有条目的总数量统计值，并判断该总数量统计值是否大于预定数量，以确定在所述下一批条目之后是否还存在更多条目以供下次获取。执行这两次数据库操作后，服务端可以将获取的条目以条目列表的形式向用户返回，以及向用户提示是否存在更多条目。但是，由于上述两次数据库操作中的第二次涉及的统计操作耗时较多，则服务端对用户的条目列表获取请求的处理过程耗时较多，导致对用户响应速度较慢。技术实现要素：本申请实施例提供一种条目列表获取请求处理方法及装置，用以解决现有技术中服务端对用户的条目列表获取请求的处理过程耗时较多，导致对用户响应速度较慢的问题。本申请实施例采用下述技术方案：本申请实施例提供的一种条目列表获取请求处理方法，包括：接收用户的条目列表获取请求，所述待获取的条目列表所包含的条目数量为第一数量；根据所述条目列表获取请求，向数据库查询第二数量的条目，所述第二数量大于所述第一数量；根据所述数据库响应于所述查询而返回的条目，向所述用户返回所述条目列表，以及向所述用户提示是否存在更多条目。本申请实施例提供的一种条目列表获取请求处理装置，包括：接收模块，接收用户的条目列表获取请求，待获取的所述条目列表所包含的条目数量为第一数量；查询模块，根据所述条目列表获取请求，向数据库查询第二数量的条目，所述第二数量大于所述第一数量；返回模块，根据所述数据库响应于所述查询而返回的条目，向所述用户返回所述条目列表，以及向所述用户提示是否存在更多条目。本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：在对用户的条目列表获取请求的处理过程中，无需进行现有技术中耗时较多的数据库统计操作，只需进行一次数据库查询操作即可，可以减少服务端对用户的条目列表获取请求的处理过程的耗时，进而可以提高对用户的响应速度，因此，可以部分或全部地解决现有技术中的问题。附图说明此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1为现有技术中的一种条目列表展示示意图；图2为本申请实施例提供的一种条目列表获取请求处理方法的流程示意图；图3为本申请实施例提供的一种实际应用场景下，现有技术的条目列表获取请求处理多端交互过程示意图；图4为本申请实施例提供的一种实际应用场景下，本申请的方案的条目列表获取请求处理多端交互过程示意图；图5为本申请实施例提供的一种条目列表获取请求处理装置的结构示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。如前所述，
背景技术：
：中对现有技术中的问题进行了简单说明。为了更直观地理解该问题，在介绍本申请的方案之前，先举例对现有技术中的问题进行更详细的说明。图1为现有技术中的一种条目列表展示示意图。假定用户是通过执行下拉操作，向服务端发送条目列表获取请求的，比如，对于触摸屏设备，用户可以将用于展现条目列表的页面向下拖拽一段距离后放手(也即，执行下拉操作)，终端在检测到用户的下拉操作后，向服务端发送用户的条目列表获取请求。假定每次获取的条目列表包含至多m条条目。图1中示出了在用户执行了某一次下拉操作后，终端获取并展现的条目列表，可以看到，该条目列表包含了第n条目到第n+m-1条目，共计m条条目。图1中的“查看更多”按钮控件是根据服务端对于是否存在更多条目的提示所渲染展现的。若在当前展现的条目后还存在更多条目，则终端可以渲染展现“查看更多”按钮控件，反之，则终端可以渲染展现“无更多条目”按钮控件。进一步地，用户还可以通过在图1的条目列表上再次执行下拉操作，或者，对“查看更多”按钮控件执行点击操作，触发下一次请求条目列表的过程开始，服务端相应地可以从数据库获取并返回从第n+m条目开始的，至多m条新条目。为了使终端获取到并展示图1中条目列表。服务端主要执行了以下两次数据库操作：第一次，从数据库获取下一批至多预定数量的条目。具体地，服务端向数据库查询从第n条目开始的至多m条条目。使用的SQL语句常常如下：“select*fromxx_tablewherestartRow>＝nlimitm”；第二次，从数据库获取所述下一批条目以及下一批条目之后的所有条目的总数量统计值。具体地，确定数据库中从第n条目开始直至结束的条目总数量，用于判断是否存在更多条目以供下次获取，以便于后续向用户提示。使用的SQL语句常常如下：“selectcount(*)fromxx_tablewherestartRow>＝n”；其中，在以上的两个SQL语句中，“xx_table”表示数据库用于存储条目的数据表，每条条目分别是该数据表中的一条记录，“startRow”表示条目的序号。但是，上述两次数据库操作中的第二次涉及的统计操作耗时较多(第二个SQL语句的执行过程耗时较多)，则服务端对用户的条目列表获取请求的处理过程耗时较多，导致对用户的下拉操作响应速度较慢。上面对现有技术进行了详细分析，下面开始介绍本申请的方案，以及对本申请的方案如何解决现有技术中的问题进行说明。图2为本申请实施例提供的一种条目列表获取请求处理方法的流程示意图。图2中的流程的执行主体可以是服务端或终端。服务端或终端对应的设备包括但不限于：个人计算机、大中型计算机、计算机集群、手机、平板电脑、智能手表、车载移动台。执行主体并不构成对本申请的限定，为了便于描述，以下主要以执行主体是服务端为例进行说明。图2中的流程可以包括以下步骤：S201：接收用户的条目列表获取请求，待获取的所述条目列表所包含的条目数量为第一数量。在本申请实施例中，条目列表是应用中常见的一种信息展现形式，条目列表初始时保存在服务端的数据库中，当用户在终端上使用应用，需要查看条目列表时，可以通过终端，向应用的服务端发送条目列表获取请求，通过终端与服务端的交互，以及服务端的相应处理，终端可以为用户展现服务端响应于用户的请求所返回的条目列表。本申请对条目列表包含的条目的具体内容并不做限定，可以商品信息、消息、文章等等。需要说明的是，本申请实施例中待获取的所述条目列表”指：用户通过一次条目列表获取请求，可以获取到的一定数量(也即，步骤S201中所述的“第一数量”；在现有技术的例子中，第一数量为m，当然，在实际应用中，第一数量也可以小于m)的条目所构成的列表。进一步地，用户通过多次条目列表获取请求，可以相应地获取到多个条目列表。终端可以将用户已获取到的多个条目列表构成一个长列表并向用户展现，或者，终端也可以将所述多个条目列表相互独立地分别向用户展现。在本申请实施例中，条目列表获取请求可以是基于用户的特定操作发送的，所述特定操作可以是：上拉操作、或下拉操作、或与按钮控件的交互操作(点击、长按等)，等等。S202：根据所述条目列表获取请求，向数据库查询第二数量的条目，所述第二数量大于所述第一数量。在本申请实施例中，服务端在接收到用户的条目列表获取请求后，不是像现有技术那样去向数据库查询第一数量的条目，而是向数据库查询第二数量的条目。也即，服务端尝试获取比第一数量更多的条目。这样的话，服务端仅通过一次数据库操作，就能够获取到用户本次的条目列表获取请求所对应的各条目，而且又能够确定本次获取后数据库中是否还存在更多条目以供下次获取。相比于现有技术中需要执行两次数据库操作，可以降低服务端对用户的条目列表获取请求处理过程的耗时。在本申请实施例中，对于用户已获取的条目，一般会缓存或者持久化保存在终端，若用户想要查看已获取的条目，无需依赖服务端；而对于用户尚未获取的条目，用户则需要向服务端请求获取。因此，用户发送的条目列表获取请求所对应的条目(也即，用户通过该条目列表获取请求想要获取的条目)应当是用户尚未获取的条目。需要说明的是，在实际应用中也有例外，比如，假定用户已获取并缓存在终端的条目被删除了，则若用户再想要查看这些条目，仍需要向服务端请求获取，在这种情况下，用户发送的条目列表获取请求所对应的条目也可以是用户已获取过的条目。S203：根据所述数据库响应于所述查询而返回的条目，向所述用户返回所述条目列表，以及向所述用户提示是否存在更多条目。在本申请实施例中，若用户是通过终端发送条目列表获取请求的，则终端即可以代表用户。在这种情况下，向所述用户返回所述条目列表，以及向所述用户提示是否存在更多条目，即是：向所述终端返回所述条目列表，以及向所述终端提示是否存在更多条目。在本申请实施例中，服务端向用户返回的条目列表中包含多少条目，以及提示是否存在更多条目，均可以取决于数据库响应于步骤S202中查询所返回的条目(可以简称为：数据库返回的条目)。若数据库返回的条目除去属于所述条目列表的部分，还有剩余的条目，则可以认为存在更多条目，若没有剩余的条目，可以认为不存在更多条目。需要说明的是，在不同的应用场景下，可以给本申请实施例中所述的“更多条目”赋予不同的定义。以下列举几种定义作为示例，在具体实施本申请的方案时可以根据实际情况选用其中的一种或多种。所述的“更多条目”可以指：当前存在于数据库中，但用户尚未获取的条目；也可以指：用户虽已获取但终端当前并未展现给用户的条目；也可以指：用户尚未获取但通过下一次请求即能够获取到的条目；等等。在本申请实施例中，“向所述用户提示是否存在更多条目”的具体实施方式可以多种。比如，服务端可以向用户返回直观的提示信息(比如，返回提示文本等、提示图片等)，终端直接向用户展现该提示信息；服务端也可以向用户返回非直观的提示信息，终端根据非直观的提示信息(比如，表明是否存在更多条目的标识位、或标识字段等标识信息)，生成直观的提示信息(比如，渲染出“查看更多”的按钮控件等)再向用户展现；等等。通过上述方法，在对用户的条目列表获取请求的处理过程中，无需进行现有技术中耗时较多的数据库统计操作，只需进行一次数据库查询操作即可，可以减少服务端对用户的条目列表获取请求的处理过程的耗时，进而可以提高对用户的响应速度，因此，可以部分或全部地解决现有技术中的问题。不仅如此，由于减少了数据库操作的次数，因此，也可以减少数据库的资源消耗，减少对数据库的压力。对于用户而言，相比于采用现有技术，采用本申请的方案可以使得用户有如下直观的感受：服务端对于用户在请求获取条目列表所执行的下拉操作、或上拉操作、或对“查看更多”按钮控件的点击操作等特定操作的响应速度提高，终端可以更快地向用户展现用户请求获取的条目列表，用户体验较好。基于上述方法，本申请实施例还提供了上述方法的一些具体实施方案，以及扩展方案，下面进行说明。在本申请实施例中，根据前面的分析可知，一般地，对于步骤S202，根据所述条目列表获取请求，向数据库查询第二数量的条目，具体可以包括：根据所述条目列表获取请求，向数据库中查询所述用户尚未获取的、第二数量的条目。具体的查询方式可以取决于数据库具体是如何存储各条目的。为了便于理解，下面列举两种具体的查询方式作为示例。第一种查询方式。假定数据库会基于用户每次的请求，动态地对各条目的存储位置进行调整，使得用户尚未获取的条目与用户已获取的条目分别存储于不同的数据表中，则服务端可以在用于存储用户尚未获取的条目的数据表中，随机地或顺序地查询出第二数量的条目。第二种查询方式。假定数据库中存储的各条目具有预定顺序(比如，各条目的序号从小到大的顺序，第n条目的序号即为n)，用户也是按照每次也是基于该顺序，请求获取条目列表的，则服务端可以基于该顺序向数据库中查询所述用户尚未获取的、第二数量的条目。在这种情况下，所述用户尚未获取的条目可以为：顺序位于特定条目之前的条目(可以对应于用户从后往前请求获取条目的场景，比如，用户往前翻看历史消息列表等)，或位于所述特定条目之后的条目(可以对应于用户从前往后请求获取条目的场景，比如，用户往后翻看最新帖子列表等)；其中，所述特定条目可以是根据所述条目列表获取请求确定的。一般地，所述特定条目可以是用户在本次发送条目列表获取请求前最新获取到的一条条目。条目列表获取请求中可以包含用于表明哪条条目是所述特定条目的信息，比如，包含一个条目的序号，则该序号对应的条目即为所述特定条目。需要说明的是，无论上面列举的哪种方式，都可以仅通过一次数据库操作(比如，执行一个SQL语句)实现。以上面列举的第二种查询方式为例。在现有技术中的例子的场景下，若采用第二种查询方式，假定用户尚未获取的条目包括：顺序位于特定条目之前的条目，则具体可以采用诸如以下的SQL语句向数据库查询：“select*fromxx_tablewherestartRow>＝nlimitm+x”；其中，第n-1条目为所述特定条目，x不小于1，则m+x为第二数量。进一步地，在实际应用中，也不一定要从特定条目开始查询，只要保证查询的条目中包括所述用户尚未获取的、第二数量的条目即可，比如，也可以采用诸如以下的SQL语句向数据库查询：“select*fromxx_tablewherestartRow>＝n-ylimitm+x”；其中，第n-1条目为所述特定条目，x-y>＝1，则m+x-y为第二数量。在本申请实施例中，虽然在步骤S202中向数据库查询第二数量的条目，但是数据库未必就能够返回第二数量的条目，根据数据库返回的条目数量的不同，步骤S203的具体实施方式可能有所不同。步骤S203中包含有“返回条目列表”和“提示是否存在更多条目”这两个子步骤，本申请对这两个子步骤的执行顺序并不做限定，可以是同时执行的，也可以是先后执行的。下面分别对这两个步骤进一步地说明。在本申请实施例中，对于步骤S203，根据所述数据库响应于所述查询而返回的条目，向所述用户返回所述条目列表，具体可以包括：确定所述数据库响应于所述查询返回的条目的总数量；判断所述总数量是否大于所述第一数量；若是，向所述用户返回包含所述数据库响应于所述查询而返回的全部条目中第一数量的条目的条目列表；否则，向所述用户返回包含所述数据库响应于所述查询而返回的全部条目的条目列表。仍沿用上例说明，假定从所述特定条目开始查询，判断数据库返回的条目的总数量是否m；若是，对于数据库本次返回的各条目，可以将包含第n条目至第n+m-1条目(共计m条条目)的条目列表返回给用户，除此之外的条目可以不返回给用户；否则，向用户返回包含数据库本次返回的全部条目的条目列表。需要说明的是，数据库在返回条目时，条目可以是已经包含在条目列表中的，在这种情况下，数据库是通过返回条目列表而返回条目的。在本申请实施例中，对于步骤S203，根据所述数据库响应于所述查询而返回的条目，向所述用户提示是否存在更多条目，具体可以包括：确定所述数据库响应于所述查询而返回的条目的总数量；判断所述总数量是否大于所述第一数量；若是，向所述用户提示存在更多条目；否则，向所述用户提示不存在更多条目。在实际应用中，服务端一般可以通过返回一个布尔型字段作为标识信息，向用户提示是否存在更多条目。比如，当该布尔型字段等于1时，可以表示存在更多条目，当该布尔型字段等于0时，可以表示不存在更多条目。在本申请实施例中，为了减少服务端与用户的交互次数，服务端可以将是否存在更多条目的提示和数据库返回的条目列表，这两部分待返回的内容，包含在同一个结构体实例中，通过一次交互将该结构体实例返回给用户。例如，在实际应用中，该结构体实例对应的结构体可以如下所示：其中，“Result”为该结构体，“items”要返回的条目列表，“hasMore”为该布尔型字段。进一步地，终端可以根据服务端返回的布尔型字段，更直观地向用户提示是否存在更多条目。比如，当该布尔型字段等于1，可以渲染展示“查看更多”按钮控件，则用户可以通过点击该按钮控件进行下一次的条目列表请求，当该布尔型字段不等于1，可以渲染展示诸如“不存在更多”的提示信息。以上对本申请的方案进行了详细的说明。为了帮助读者更直观地了解现有技术和本申请的方案的区别，本申请实施例还分别提供了一种实际应用场景下，现有技术与本申请的方案分别的条目列表获取请求处理多端交互示意图，如图3、图4所示。图3为本申请实施例提供的一种实际应用场景下，现有技术的条目列表获取请求处理多端交互过程示意图。图3中的交互过程可以包括以下步骤：用户在终端上展现条目列表的页面上执行上拉操作，已请求查看更多条目，其中，终端当前最新展现的条目为第n-1条目；终端检测到用户的上拉操作后，向服务端发送条目列表获取请求，已请求获取第n条目开始的至多m条条目；服务端根据接收到的条目列表获取请求，向数据库查询第n条目开始的至多m条条目；数据库响应于服务端的查询，向服务端返回包含至多m条条目的条目列表；服务端统计查询数据库中第n条目开始的条目总数量；数据库返回统计出的条目总数量；服务端判断条目总数量是否大于m，若是，则确定存在更多条目可供用户下一次下拉查看，否则，确定不存在更多条目可供用户下一次下拉查看；服务端向终端返回(也即，向用户返回)查询到的条目列表，以及返回用于提示是否存在更多条目的布尔型字段；终端渲染展现服务端返回的条目列表；若存在更多条目，展现“查看更多”按钮控件，若不存在更多条目，展现“无更多内容”按钮控件。图4为本申请实施例提供的一种实际应用场景下，本申请的方案的条目列表获取请求处理多端交互过程示意图。图4中的交互过程可以包括以下步骤：用户在终端上展现条目列表的页面上执行上拉操作，已请求查看更多条目，其中，终端当前最新展现的条目为第n-1条目；终端检测到用户的上拉操作后，向服务端发送条目列表获取请求，已请求获取第n条目开始的至多m+1条条目；服务端根据接收到的条目列表获取请求，向数据库查询第n条目开始的至多m+1条条目；数据库响应于服务端的查询，向服务端返回包含至多m+1条条目的条目列表；服务端判断数据库返回的条目的总数量是否大于m，若是，则确定存在更多条目可供用户下一次下拉查看，否则，确定不存在更多条目可供用户下一次下拉查看；服务端若判断总数量大于m(具体为m+1)，则剔除最后1条条目，剩余的用于返回给终端，若判断总数量不大于m，则全部用于返回给终端。服务端向终端返回(也即，向用户返回)查询到的包含至多m条条目的条目列表，以及返回用于提示是否存在更多条目的布尔型字段；终端渲染展现服务端返回的条目列表；若存在更多条目，展现“查看更多”按钮控件，若不存在更多条目，展现“无更多内容”按钮控件。通过图3和图4的交互流程可以看到，本申请的方案相比于现有技术，减少了一次数据库操作，因此，可以提高对用户的响应速度，减少数据库的资源消耗。上面主要是以服务端作为执行主体，执行图1中的流程的。在实际应用中，也可以以终端作为执行主体，执行图1中的流程，在这种情况下，可以由终端直接和数据库进行交互，以获取条目列表和是否存在更多条目的提示。以上为本申请实施例提供的一种条目列表获取请求处理方法，基于同样的思路，本申请实施例还提供相应的装置，如图5所示。图5为本申请实施例提供的一种条目列表获取请求处理装置的结构示意图，包括：接收模块501，接收用户的条目列表获取请求，所述条目列表包含至多第一数量的条目；查询模块502，根据所述条目列表获取请求，向数据库查询第二数量的条目，所述第二数量大于所述第一数量；返回模块503，根据所述数据库响应于所述查询而返回的条目，向所述用户返回所述条目列表，以及向所述用户提示是否存在更多条目。可选地，查询模块502，根据所述条目列表获取请求，向数据库中查询所述用户尚未获取的、第二数量的条目。可选地，各所述条目具有预定顺序，所述用户尚未获取的条目为：顺序位于特定条目之前的条目，或位于所述特定条目之后的条目；其中，所述特定条目是根据所述条目列表获取请求确定的。可选地，返回模块503，确定所述数据库响应于所述查询而返回的条目的总数量；判断所述总数量是否大于所述第一数量；若是，向所述用户返回包含所述数据库响应于所述查询而返回的全部条目中第一数量的条目的条目列表；否则，向所述用户返回包含所述数据库响应于所述查询而返回的全部条目的条目列表。可选地，返回模块503，向所述用户返回标识信息，所述标识信息用于向所述用户提示是否存在更多条目。可选地，返回模块503，确定所述数据库响应于所述查询而返回的条目的总数量；判断所述总数量是否大于所述第一数量；若是，向所述用户提示存在更多条目；否则，向所述用户提示不存在更多条目。可选地，所述条目列表获取请求是基于所述用户的以下至少一种操作发送的：上拉操作；下拉操作；与按钮控件的交互操作。图5中的装置具体可以位于服务端或终端上。本申请提供的装置是与本申请提供的方法一一对应的，因此，所述装置也具有与所述方法类似的有益技术效果，由于上面已经对所述方法的有益技术效果进行了详细说明，因此，这里不再赘述所述装置的有益技术效果。本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。当前第1页1 2 3 当前第1页1 2 3