CN110727720A - 列表显示及查询方法、装置、存储介质和计算机设备 - Google Patents

Abstract

本申请涉及一种列表显示及查询方法、装置、存储介质和计算机设备，列表显示方法包括：当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值；当所述第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自所述服务器的压缩包；对所述压缩包解压缩，获得更新的全量列表条目和所述第二哈希值；根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值；将更新的全量列表条目进行分页显示。本申请提供的方案可以提高列表显示效率。

Description

列表显示及查询方法、装置、存储介质和计算机设备

技术领域

本申请涉及计算机技术领域，特别是涉及一种列表显示及查询方法、装置、存储介质和计算机设备。

背景技术

列表是一种页面内容展示样式，可以使多种信息得到有序结构化展示。越来越多的应用通过列表将用户可能需求的数据提供给用户。比如，社区类应用中的好友粉丝列表、访问记录列表、步数排行列表、通讯录列表等。列表中各数据条目的排列顺序可以发生变化。比如，好友列表中好友排序根据好友的在线状态以及与用户的社交频度不同而不断变化。

目前，应用对列表的加载方式主要是：应用向服务端发送分页查询请求，服务端根据分页查询请求所记录的页码从数据库查询对应那一页的列表条目返回给应用显示。这种方式虽然可以实现列表条目的分页显示，但由于列表条目在数据库中的存储顺序不断变化，使应用在加载每个分页时均需对当前分页与前一分页中的列表条目进行去重，增大了应用的数据处理负担，对列表显示效率造成影响。

发明内容

基于此，有必要针对分页查询影响列表显示效率的技术问题，提供一种列表显示及查询方法、装置、存储介质和计算机设备。

一种列表显示方法，包括：

当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值；

当所述第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自所述服务器的压缩包；

对所述压缩包解压缩，获得更新的全量列表条目和所述第二哈希值；

根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值；

将更新的全量列表条目进行分页显示。

一种列表显示装置，所述装置包括：

数据更新确认模块，用于当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值；当所述第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自所述服务器的压缩包；

全量数据获取模块，用于对所述压缩包解压缩，获得更新的全量列表条目和所述第二哈希值；根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值；

数据分页显示模块，用于将更新的全量列表条目进行分页显示。

一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述列表显示方法的步骤。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述列表显示的方法的步骤。

上述列表显示方法、装置、计算机可读存储介质和计算机设备，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，终端可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用数据处理负担，提高应用性能，间接提高列表显示效率。

一种列表查询方法，包括：

根据终端的数据查询请求，查询符合所述数据查询条件的全量列表条目；所述数据查询请求携带了所述终端本地所缓存的全量列表条目的第一哈希值；

获取与查询到的全量列表条目所对应的第二哈希值；

当所述第二哈希值与所述第一哈希值不一致时，对查询到的全量列表条目及所述第二哈希值打包压缩，得到压缩包；

将所述压缩包返回至所述终端，使所述终端根据所述压缩包记录的更新的全量列表条目和所述第二哈希值对本地所缓存的全量列表条目及所述第一哈希值更新，并分页显示更新的全量列表条目。

一种列表查询装置，所述装置包括：

数据标识比对模块，用于根据终端的数据查询请求，查询符合所述数据查询条件的全量列表条目；所述数据查询请求携带了所述终端本地所缓存的全量列表条目的第一哈希值；获取与查询到的全量列表条目所对应的第二哈希值；

全量数据压缩模块，用于当所述第二哈希值与所述第一哈希值不一致时，对查询到的全量列表条目及所述第二哈希值打包压缩，得到压缩包；

全量数据发送模块，用于将所述压缩包返回至所述终端，使所述终端根据所述压缩包记录的更新的全量列表条目和所述第二哈希值对本地所缓存的全量列表条目及所述第一哈希值更新，并分页显示更新的全量列表条目。

一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述列表查询方法的步骤。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述列表查询的方法的步骤。

上述列表查询方法、装置、计算机可读存储介质和计算机设备，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，终端可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用数据处理负担，提高应用性能，间接提高列表显示效率。

附图说明

图1为一个实施例中列表显示及查询方法的应用环境图；

图2为一个实施例中列表显示方法的流程示意图；

图3为一个实施例中获取来自服务器的压缩包步骤的流程示意图；

图4为一个实施例中展示有好友消息列表的页面示意图；

图5为一个实施例中好友消息列表显示方法的交互时序图；

图6为一个具体的实施例中列表显示方法的流程示意图；

图7为一个实施例中列表显示方法的流程示意图；

图8为另一个实施例中列表显示及查询方法的应用环境图；

图9为一个实施例中基于全量列表条目生成的压缩包的数据结构示意图；

图10为一个具体的实施例中列表查询方法的流程示意图；

图11为一个实施例中列表显示装置的结构框图；

图12为一个实施例中列表查询装置的结构框图；

图13为一个实施例中计算机设备的结构框图；

图14为另一个实施例中计算机设备的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

图1为一个实施例中列表显示及查询方法的应用环境图。参照图1，该列表显示方法应用于列表显示系统。该列表显示系统包括终端110和服务器120。终端110和服务器120通过网络连接。终端110上运行了社区类应用。社区类应用是指能够为用户提供某种生活服务的应用，如社交应用、游戏应用、支付应用、新闻应用等。社区类应用能够以列表的方式展示页面数据。服务器120是为社区类应用提供服务的后台服务器。服务器120部署了数据库，用于存储列表数据。终端110具体可以是台式终端或移动终端，移动终端具体可以手机、平板电脑、笔记本电脑等中的至少一种。服务器120可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

如图2所示，在一个实施例中，提供了一种列表显示方法。本实施例主要以该方法应用于上述图1中的终端110来举例说明。参照图2，该列表显示方法具体包括如下步骤：

S202，当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值。

其中，列表是社区类应用中对页面数据的一种展示样式，以表格为容器装载多个数据项。列表条目是指列表中的一个数据项。每个数据项具体可以包括文本、图片、语音、视频或控件等数据元素中的至少一种。比如，好友消息列表所展示的每个列表条目可以是每个好友的头像、昵称、在线状态、最后时间发送或接收的会话消息等用户数据；好友动态列表所展示的不同列表条目可以是同一好友发布的不同动态记录，或不同好友发布的动态记录等；步数排行列表所展示的列表条目可以是登录用户及其一个或多个好友的运动步数、步数排名、点赞数量等数据；商品列表所展示的不同列表条目可以是每个商品的名称、缩略图、价格、已售数量、购买链接等。

列表中的多个列表条目按照一定的线性顺序排列存储在数据库中。不同应用场景中的列表以及对列表条目进行排序的依据不同。比如，好友列表中多个好友的用户数据可以按照好友的在线状态排序；步数排行列表中多个用户的运动数据可以按照运动步数的大小降序排列。用户可以基于终端上的社区类应用对自己的列表条目数据进行配置变更。终端将变更后的列表条目发送至服务器，使服务器根据变更后的列表条目对数据库中所存储的相应用户的列表条目进行更新。

触发列表查询的操作可以是在社区类应用中进入列表页面的操作、在列表页面中增加列表条目的操作或按照预设时间频率自动触发的列表页面刷新操作等。列表页面是以列表的方式展示页面数据的页面。

具体地，当发生了列表查询的触发操作时，终端获取查询字段、确定用户触发的列表查询操作所指向列表的列表标识，并从本地缓存中读取该列表所对应的全量列表条目的第一哈希值。查询字段是指用于指示服务器进行数据查询的条件信息，具体可以是用户在触发列表查询操作时输入在应用页面的，也可以终端根据用户触发的列表查询操作自动获取的默认字段。默认字段是指预先指定的查询相应列表条目所需的字段信息，如用户标识等。用户标识是指能够唯一标识社区类应用当前登录用户的信息，如用户账号、手机号、邮箱等。列表标识是能够唯一标识一个列表的信息，具体可以是社区类应用为列表分配的编号等。终端本地所缓存的全量列表条目对应的第一哈希值是上一次触发列表查询且服务器上全量列表条目发生更新时从服务器查询到的。

S204，当第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自服务器的压缩包。

其中，全量列表条目是指数据库中符合数据查询条件的全部列表条目。哈希值(hash value)是服务器基于MD5(Message-Digest Algorithm，信息摘要算法)对全量列表条目进行哈希运算得到的结果值。MD5是一种密码散列函数，可以产生出一个128位(16字节)的哈希值，用于确保全量列表条目传输前后的完整一致性。哈希值能够唯一标识全量列表条目。如上文，服务器中所存储的每个列表所对应列表条目的排序或内容等可能时刻在发生变化，从而服务器在不同时刻计算得到的同一列表标识对应的全量列表条目的哈希值是不同的。为了描述方便，将终端本地缓存基于上一次数据查询请求从服务器拉取到的全量列表条目的哈希值记作第一哈希值；将服务器根据本次数据查询请求对查询到的全量列表条目进行哈希运算得到的哈希值记作第二哈希值。

在一个实施例中，当第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自服务器的压缩包包括：根据触发列表查询的操作，向服务器发起数据查询请求；数据查询请求携带了查询字段及第一哈希值；使服务器获取与查询字段相匹配的目标的全量列表条目对应的第二哈希值；接收服务器在第一哈希值与第二哈希值不一致时返回的通过对目标的全量列表条目进行打包压缩而生成的压缩包。

具体地，终端根据查询字段、列表查询操作所指向列表的列表标识以及读取到的第一哈希值向服务器发起本次的数据查询请求。服务器根据本次的数据查询请求，在数据库与列表标识所对应数据表中查询与查询字段相匹配的全部列表条目。查询到的有序排序的全部列表条目即为全量列表条目。比如，在好友查询场景中，服务器根据好友消息列表查询请求，在数据库中存储有每个用户标识所关联的不同列表的列表标识，以及每个列表标识对应列表的每个列表条目。服务器根据本次的数据查询请求，在数据库中查询与用户标识以及列表标识对应的全量列表条目。比如，列表标识对应好友消息列表，则服务器查询与用户标识所关联的好友标识，在查询每个好友标识所关联的与列表标识相匹配的列表条目。查询到的全部列表条目即为全量列表条目，不同列表条目按照好友在线状态或者用户设定的其他排序条件排列。

进一步地，服务器计算查询到的全量列表条目的第二哈希值，并比较第二哈希值与本次数据查询请求所携带的第一哈希值是否一致。当第二哈希值与第一哈希值不一致时，服务器对查询到的全量列表条目进行压缩，并对第二哈希值和压缩后的全量列表条目进行打包，生成压缩包。服务器将压缩包返回至终端，以响应终端发起的本次数据查询请求。

S206，对压缩包解压缩，获得更新的全量列表条目和第二哈希值。

具体地，终端对拉取到的压缩包进行解析，得到第二哈希值和压缩后的全量列表条目。终端按照服务器所采用的压缩算法相反的逻辑对压缩后的全量列表条目进行解压缩，得到更新的全量列表条目。

S208，根据解压缩得到的全量列表条目和第二哈希值，更新本地所缓存的全量列表条目及对应的第一哈希值。

具体地，终端对拉取到的压缩包进行解析，得到第二哈希值和压缩后的全量列表条目。终端对压缩后的全量列表条目进行解压缩，得到更新的全量列表条目。当终端拉取到更新的全量列表条目后，及时对本地缓存的上一次从服务器拉取的全量列表条目删除，将第二哈希值以及更新的全量列表条目存储至本地缓存。

S210，将更新的全量列表条目进行分页显示。

其中，分页显示是将从服务器查询到的全量列表条目分成一段一段来显示的方式。也就是说，在每个分页展示一段列表条目，每段列表条目的数量不少于一个。在本申请提供的实施例中社区类应用采用分页显示的方式实现页面加载。当用户在社区类应用触发了列表查询操作时，终端可以确定列表查询所指向列表需要在每个分页显示的列表条目的数量PageSize，以及当前需要展示的分页所对应的分页标识CurrentPageID。分页标识可以是终端为每个分页分配的编号等，用于表征具体是第几个分页。每个分页显示的列表条目的数量PageSize可以是预先配置在社区类应用的代码文件中的。不同列表在每个分页显示的列表条目的数量PageSize可以不同，具体可以根据单个列表条目的数据量等因素设定。

具体地，终端根据列表查询所指向列表需要在每个分页显示的列表条目的数量PageSize，以及本地缓存中的全量列表条目的数量，可以确定需要展示的分页的总数量。当本地缓存中的全量列表条目的数量超过列表查询所指向列表需要在每个分页显示的列表条目的数量PageSize时，终端根据列表查询所指向列表需要在每个分页显示的列表条目的数量PageSize，将本地缓存中的全量列表条目划分为多段，并根据需要展示的分页的总数量为有序排列的多段列表条目依次进行编号，以确定每段列表条目对应的分页标识。

终端根据当前所需展示分页的分页标识CurrentPageID，从本地缓存中拉取相应一段列表条目进行展示，实现该分页的加载。当用户触发了翻页操作时，终端根据用户触发的翻页操作，重新确定当前所需展示分页的分页标识CurrentPageID，根据重新确定的分页标识从本地缓存中拉取相应一段列表条目进行展示，实现翻页操作所指向的分页的加载。

上述列表显示方法，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，终端可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用的数据处理负担，提高应用性能，间接提高列表显示效率。

在一个实施例中，参考图3，图3示出了一个实施例中获取来自服务器的压缩包的流程示意图。如图3所示，获取来自服务器的压缩包包括：

S302，获取每个分页需要显示的列表条目的数量。

S304，根据数量及本地所缓存的全量列表条目中单个列表条目的数据量，确定分页传输本地所缓存的全量列表条目的第一数据量。

其中，单个列表条目的数据量(以下称单位数据量)具体可以是全量列表条目的数据量的平均值，中位数或最大值等。单位数据量可以是终端根据本地缓存的全量列表条目估算得到的。为了描述方便，将单个分页需要显示的列表条目的数据量记作第一数据量，将压缩后的全量列表条目的数据量记作第二数据量。

具体地，终端根据列表查询所指向列表需要在每个分页显示的列表条目的数量PageSize，以及本地缓存中的单个列表条目的单位数据量，计算单个分页需要显示的列表条目的第一数据量。比如，假设分页显示时单个分页需要显示的列表条目的数量PageSize为50，单个列表条目的数据量为10MB，则单个分页需要显示的列表条目的第一数据量为500MB。也就是说，若终端采用传统分页查询的方式从服务器查询列表条目，则服务器每次向终端传输的列表条目的第一数据量为500MB。

在一个实施例中，终端也可以将列表查询所指向列表需要在每个分页显示的列表条目的数量PageSize发送至服务器，由服务器结合数据库所存储的单个列表条目的单位数据量，计算单个分页需要显示的列表条目的第一数据量。

S306，接收服务器在全量传输所存储全量列表条目的第二数据量超过第一数据量时，并行传输的根据第一数据量对所存储全量列表条目进行打包压缩生成的多个压缩包。

具体地，服务器根据预设压缩方式的压缩比例，计算根据数据查询请求所查询到的全量列表条目的第二数据量。比如，压缩前全量列表条目的数据量为8000MB，压缩比例为10:1，则压缩后全量列表条目的第二数据量为800MB。服务器根据第一数据量以及根据数据查询请求所查询到的全量列表条目的第二数据量，确定生成压缩包的数量。当第二数据量小于或等于第一数据量时，服务器按照预设压缩方式对查询到的全量列表进行压缩后发送至终端。

当第二数据量大于第一数据量时，服务器根据第一数据量将全量列表条目划分为多个区间列表条目。服务器按照预设压缩方式分别对每个区间列表条目进行打包压缩，生成每个区间列表条目对应的压缩包。单个压缩包所容纳的列表条目的数据量不超过第一数据量。比如，当第一数据量为500MB、第二数据量为800MB时，服务器可以基于全量列表条目生成数据量分别为500MB和300MB的两个压缩包。服务器调用与区间列表条目数量对应的线程，将多个压缩包并行传输至终端。

在一个实施例中，在根据第一数据量对全量列表条目进行划分时，服务器根据网络环境确定对第一数据量的调整因子。调整因子是大于零并小于一的数值。调整因子的大小与当前网络环境的传输速度负相关。服务器可以预存多种网络传输速度区间与调整因子的对应关系。根据该对应关系及当前网络传输速度，确定当前的调整因子。服务器根据第一数据量及调整因子确定每个压缩包的目标数据量。比如，在上述举例中，当调整因子为0.8时，目标数据量为500*0.8＝400MB，则服务器可以基于全量列表条目生成两个数据量均为400MB的压缩包。

在本实施例中，确定采用分页传输时单次需要传输的第一数据量是，当根据第一数据量确定生成的压缩包的数量，能够保证每个压缩包的数据量不查过第一数据量，进而采用本实施例提供的全量查询的方式实现列表显示，在免去了终端进行数据处理以及频繁与服务器进行数据交互的数据处理负担的同时，可以保持与分页查询相当的查询请求响应效率。

在一个实施例中，当与查询字段相匹配的列表条目的数量确定时，目标的全量列表条目包括与查询字段相匹配的全部列表条目。

其中，根据所包含列表条目的数量和数据量不同，可以将列表区分为多种类型：列表条目数量确定且数据量确定的列表(以下称确定型列表)、列表条目数据不确定但数据量确定的列表(以下称半确定型列表)、列表条目数量不确定且数据量不确定的列表(以下称不确定型列表)等。需要说明的是，本申请的实施例中，列表条目数量确定是指列表条目的数量可以确定，并非指列表条目数量固定不变。列表条目数据量确定是指列表中每条列表条目的数据量与预设数据量的差值均小于阈值，即列表中每条列表条目的数据量均与预设数据量相差不大。

比如，好友消息列表中列表条目的数量可以根据用户所关注的好友的数量而确定，不同好友的列表条目所包含的数据元素相同，数据量相近，属于确定型列表。商品列表中列表条目的数量与服务器查询到的符合用户所设定查询条件的商品数量有关，难以确定；但每个商品对应列表条目所包含的数据元素相同，数据量相近，属于半确定型列表。好友动态列表中每个好友所发布动态记录的数量及内容均不确定，从而列表条目的数量及数据量均不确定，属于不确定型列表。

具体地，不同类型的列表，全量列表条目可以是数据库中所存储的与列表标识所对应的不同列表条目。服务器根据数据查询请求携带的列表标识确定列表类型。在好友查询场景中，当列表类型为确定型列表时，服务器将与查询字段相匹配的全部列表条目确定为全量列表条目。比如，在好友查询场景中，全量列表条目包括用户标识对应的全部关联用户产生的列表条目确定为需要查询的全量列表条目。关联用户是指与用户标识所对应登录用户具有关联关系的用户，如好友或粉丝等。好友消息列表中每个好友对应有一个列表条目，好友消息列表对应的全量列表条目可以是登录用户所关注的全部好友对应的列表条目。

参考图4，图4示出了一个实施例中展示有好友消息列表的页面示意图。如图3所示，用户通过触发应用底部不同的菜单项可以进入不同的页面。当触发了“聊天”菜单项时，终端打开用于展示好友消息列表的页面。好友消息列表属于确定型列表，每个好友对应有一个列表条目。比如，A0用户基于应用关注了100个好友A1-A100，则服务器将数据库中A0-A100每个用户对应的列表条目作为全量列表条目压缩发送至终端。

在本实施例中，针对不同类型的列表灵活采用不同的全量列表条目查询方式，当查询字段相匹配的列表条目的数量以及数据量均可以确定时，则与查询字段相匹配的全部列表条目的数据量是有限可控的，从而可以将查询到的与查询字段相匹配的全部列表条目确定为全量列表条目，减少因全量列表条目数据量过大对列表显示效率造成影响，在面对数据去重处理的同时能够很好的兼顾数据查询效率。

在一个实施例中，当与查询字段相匹配的列表条目的数量不确定时，目标的全量列表条目包括在第一哈希值生成时间至第二哈希值生成时间期间所产生的与查询字段相匹配的列表条目。

其中，哈希值生成时间是指服务器基于接收到的数据查询请求进行全量列表条目查询，并生成所查询到的全量列表条目的哈希值的时间。第一哈希值生成时间是用户上一次触发数据查询请求的时间。第二哈希值生成时间是用户本次触发数据查询请求的时间。

具体地，如上文，与查询字段相匹配的列表条目的数量不确定的列表可能是半确定型列表，也可能是不确定型列表。当列表标识所对应的列表为半确定型列表时，全量列表条目可以是数据库中存储的与列表标识对应的目标数量的排序靠前的列表条目。目标数量可以是预设数量，如50等。比如，在商品选购场景中，服务器根据数据查询请求所携带的商品名称、筛选条件等查询字段在数据库中查询商品名称所对应的商品的列表条目，并按照价格、销量等筛选条件对查询到的列表条目进行筛选排序，当查询到的列表条目的数量超过预设数量时，可以将排序靠前的预设数量商品的列表条目确定为全量列表条目。当查询到的列表条目的数量小于预设数量时，直接将查询到的全部列表条目确定为全量列表条目。

当列表标识所对应的列表为不确定型列表时，全量列表条目可以是数据库中在目标时段所产生的与查询字段相匹配的列表条目。目标时段是指用户上一次触发数据查询请求至本次触发数据查询请求所对应的时间段。比如，新闻列表需要展示的不同新闻记录，在数据库中按照发布时间排列。假设用户A在时间t0、t1和t2一次触发了新闻列表的数据查询请求，则服务器将t0至t1时间段发布的新闻记录作为响应t1时刻触发的数据查询请求的全量列表条目，将t1至t2时间段发布的新闻记录作为响应t2时刻触发的数据查询请求的全量列表条目。

需要说明的是，当采用本实施例提供的方式确定不确定型列表所对应的全量列表条目时，服务器计算上一次向终端返回的全量列表条目以及当前数据库所存储的全量列表条目的验证哈希值。当验证哈希值与上一次向终端返回的全量列表条目所对应第一哈希值不一致时，服务器对当前数据库所存储的全量列表条目进行压缩，将压缩后全量列表条目以及当前数据库所存储的全量列表条目所对应第二哈希值发送至终端。比如，在上述举例中，当在时间t2接收到终端触发的新闻列表的数据查询请求时，服务器计算t1至t2时间段发布的新闻记录对应的第二哈希值A，计算t0至t2时间段发布的新闻记录对应的验证哈希值B，当验证哈希值B与t0至t1时间段发布的新闻记录对应的第二哈希值C不一致时，服务器将t1至t2时间段发布的新闻记录及第二哈希值A打包压缩发送至终端。

在一个实施例中，当列表标识所对应的列表为不确定型列表时，全量列表条目也可以是数据库中存储的与列表标识对应的目标数据量所对应数量的列表条目。目标数据量是全量列表条目的数据量阈值，具体可以是预设值。服务器根据目标数据量在查询到的列表条目中筛选排序靠前的多个列表条目，筛选得到的列表条目的总数据量不超过目标数据量。比如，好友动态列表需要展示的不同好友发布的动态记录，在数据库中按照发布时间排列。当目标数据量为1000MB时，若从第1条动态记录至第20条动态记录的全部动态记录的总数据量为980MB，从第1条动态记录至第21条动态记录的全部动态记录的总数据量为1020MB，则取前20条动态记录作为全量列表条目返回至终端。

在本实施例中，针对不同类型的列表灵活采用不同的全量列表条目查询方式，当查询字段相匹配的列表条目的数量不可确定时，则与查询字段相匹配的全部列表条目的数据量是不可控的，从而可以根据查询时间对查询到的全部列表条目进行筛选，仅将在第一哈希值生成时间至第二哈希值生成时间期间所产生的与查询字段相匹配的列表条目确定为全量列表条目，减少因全量列表条目数据量过大对列表显示效率造成影响，在面对数据去重处理的同时能够很好的兼顾数据查询效率。

在一个实施例中，当第一哈希值生成时间至第二哈希值生成时间的时间长度超过预设时长时，目标的全量列表条目包括在第二哈希值生成时间之前预设时长内所产生的与查询字段相匹配的列表条目。

其中，预设时长T是指预先设置的用于限制全量列表条目数据量的时间长度值，如2小时等。在第二哈希值生成时间之前预设时长的时间段是以当前时间为结束时间，以预设时长为时间长度的时间段。比如，当第二哈希值生成时间为t2时，在第二哈希值生成时间之前预设时长的时间段是t2-T至t2时间段。

具体地，若用户在上一次触发列表查询后较长时间后才触发了本地列表查询，则自第一哈希值生成时间至第二哈希值生成时间的时间间隔较长。当基于第一哈希值生成时间和第二哈希值生成时间确定不确定型列表所对应的全量列表条目时，服务器比较第一哈希值生成时间至第二哈希值生成时间的时间长度是否超过预设时长。若是，服务器将在第二哈希值生成时间之前预设时长的时间段内产生的列表条目确定为全量列表条目。通过限缩作为全量列表条目的生成时间范围，可以将全量列表条目的数据量限定在较小数据量范围内，以保证较高的列表查询效率。

在本实施例中，针对不同类型的列表灵活采用不同的全量列表条目查询方式，当查询字段相匹配的列表条目的数量不可确定时，则与查询字段相匹配的全部列表条目的数据量是不可控的，从而可以根据查询时间对查询到的全部列表条目进行筛选，且在第一哈希值生成时间至第二哈希值生成时间的时长超过预设时长时，通过预设时长进一步限缩全量列表条目，减少因全量列表条目数据量过大对列表显示效率造成影响，在面对数据去重处理的同时能够很好的兼顾数据查询效率。

在一个实施例中，压缩包包括压缩后的更新的全量列表条目与第二哈希值的第一数据长度和；根据解压缩得到的全量列表条目和第二哈希值，更新本地所缓存的全量列表条目及对应的第一哈希值包括：当解压缩得到的全量列表条目和第二哈希值的第二数据长度和等于第一数据长度和时，根据解压缩得到的全量列表条目和第二哈希值，更新本地所缓存的全量列表条目及对应的第一哈希值。

其中，数据长度是指数据所包含字符数量或根据所包含字符数量确定的其他数值。不同数据类型的数据，对应数据长度的计算方式可以不同。全量列表条目所包含的可能是多种类型的数据，在本申请提供的实施例中，服务器将不同类型的数据统一转换为二进制数据。压缩后的全量列表条目的数据长度是指压缩后的全量列表条目所对应二进制数据包含基本元素0和1的数量。可以理解，也可以将不同类型的数据统一转换为其他类型数据，如八进制数据、十六进制数据等，只要能够确定得到全量列表条目及第二哈希值的数据长度即可，对此不作限制。

具体地，终端对压缩包进行解压缩，得到包头和包体。终端对包头进行解析，确定所存储二进制字节流数据的数据长度，记作第一数据长度和。终端对包体进行解析，确定所存储二进制字节流数据的数据长度，记作全量列表条目及第二哈希值对应的第二数据长度和。终端首先比较第一数据长度和与第二数据长度和是否相等。当第一数据长度和与第二数据长度和不相等时，表示压缩包在传输过程中发生了数据丢失等异常，终端再次向服务器发起数据查询请求，自动重新从服务器拉取更新的全量列表条目。只有当第一数据长度和与第二数据长度和相等时，终端基于从包体中解析到的更新的全量列表条目和第二哈希值对本地缓存的全量列表条目和第一哈希值进行更新。

在本实施例中，将压缩得到的全量列表条目和第二哈希值的数据长度和一同发送至终端，便于终端快速对接收到全量列表条目是否完整进行验证，只有在验证通过时才基于接收到的全量列表条目对本地缓存的全量列表条目进行更新，提高了本地缓存的列表条目的准确性，进而提高列表显示准确性。

在一个具体的实施例中，基于本申请提供的列表显示方法可以显示好友消息列表。参考图5，图5示出了一个实施例中好友消息列表显示方法的交互时序图。如图5所示，用户在需要展示好友消息列表的客户端向后台服务器发起好友消息列表查询请求。后台服务器根据列表查询请求携带的用户标识，在数据库中查询用户标识所对应目标用户的所有好友数据。后台服务器计算查询到的全部好友数据的第二哈希值，并对查询到的全部好友数据进行压缩。或者，后台服务器将查询到的全部好友数据发送至其他计算设备，由其他计算机设备计算查询到的全部好友数据的第二哈希值，并对查询到的全部好友数据进行压缩。其他计算机设备将哈希值和压缩后的全部好友数据返回至后台服务器。后台服务器将哈希值和压缩后的全部好友数据分别转化为二进制字节流数据，采用包头存储二进制字节流数据的数据长度，采用包体存储哈希值和压缩后的全部好友数据分别对应的二进制字节流数据，将包含包头和包体的压缩包返回至终端。终端收到了全部的好友数据，无需进行去重，将接收到的全部好友数据缓存至本地自行分页显示即可。

当目标用户通过客户端再次向后台服务器发起好友消息列表查询请求时，将后台服务器下发的哈希值反馈至后台服务器，后台服务器将该哈希值与当前数据库中最新的全部好友数据所对应哈希值进行比较。若终端反馈的哈希值与最新的全部好友数据所对应哈希值不一致，表示好友数据有变化，后台服务器按照上述方式重新向终端返回全部好友数据。若终端反馈的哈希值与最新的全部好友数据所对应哈希值一致，则后台服务器向客户端发送无数据更新的提示，使客户端继续基于本地缓存的全部好友数据显示好友消息列表。

如图6所示，在一个具体的实施例中，列表显示生成方法可应用于图1中终端110，该方法具体包括以下步骤：

S602，当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值。

S604，获取每个分页需要显示的列表条目的数量。

S606，根据数量及本地所缓存的全量列表条目中单个列表条目的数据量，确定分页传输本地所缓存的全量列表条目的第一数据量。

S608，根据触发列表查询的操作，向服务器发起数据查询请求；数据查询请求携带了查询字段、第一数据量及第一哈希值；使服务器获取与查询字段相匹配的目标的全量列表条目对应的第二哈希值。

S610，接收服务器在第一哈希值与第二哈希值不一致，且全量传输所存储全量列表条目的第二数据量超过第一数据量时，并行传输的根据第一数据量对所存储全量列表条目进行打包压缩生成的多个压缩包。压缩包包括压缩后的更新的全量列表条目与第二哈希值的第一数据长度和。

S612，当解压缩得到的全量列表条目和第二哈希值的第二数据长度和等于第一数据长度和时，根据解压缩得到的全量列表条目和第二哈希值，更新本地所缓存的全量列表条目及对应的第一哈希值。

S614，将更新的全量列表条目进行分页显示。

上述列表显示方法，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，终端可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用的数据处理负担，提高应用性能，间接提高列表显示效率。

图2、3及6为一个实施例中列表显示方法的流程示意图。应该理解的是，虽然图2、3及6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2、3及6中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

如图7所示，在一个实施例中，提供了一种列表查询方法。本实施例主要以该方法应用于上述图1中的终端110来举例说明。参照图7，该列表显示方法具体包括如下步骤：

S702，根据终端的数据查询请求，查询符合数据查询条件的全量列表条目；数据查询请求携带了终端本地所缓存的全量列表条目的第一哈希值。

其中，数据查询条件是指用于指示服务器进行数据查询的条件信息，具体可以是用户在触发列表查询操作时输入在应用页面的查询字段，也可以终端根据用户触发的列表查询操作自动获取的默认的查询字段。默认的查询字段是指预先指定的查询相应列表条目所需的字段信息，如用户标识等。

具体地，当发生了列表查询的触发操作时，服务器接收终端发起的数据查询请求。数据查询请求携带了数据查询条件、列表查询操作所指向列表的列表标识以及终端本地缓存的全量列表条目对应的第一哈希值。服务器根据接收到的数据查询请求，在数据库与列表标识所对应数据表中查询符合数据查询条件的全部列表条目。查询到的有序排序的全部列表条目即为全量列表条目。

在一个实施例中，数据查询请求携带了用户标识、列表标识及查询字段；查询符合数据查询条件的全量列表条目包括：根据列表标识确定数据查询请求所指向的列表类型；当列表类型为列表条目数量确定时，确定用户标识对应的全部关联用户；在列表标识对应的数据表中查询每个关联用户与查询字段相匹配的列表条目，将查询到的全部列表条确定为全量列表条目。

在一个实施例中，查询符合数据查询条件的全量列表条目包括：

当列表类型为列表条目数量不确定时，确定上一次收到来自终端的数据查询请求的时间，记作历史查询时间；查询每个关联用户自历史查询时间至当前时间所产生的与查询字段相匹配的列表条目，将查询到的全部列表条确定为全量列表条目。

在一个实施例中，查询每个关联用户自历史查询时间至当前时间所产生的与查询字段相匹配的列表条目包括：计算自历史查询时间至当前时间的第一时长；当第一时长超过预设的第二时长时，查询每个关联用户自当前时间之前第二时长内所产生的与查询字段相匹配的列表条目。

S704，获取与查询到的全量列表条目所对应的第二哈希值。

具体地，服务器计算查询到的全量列表条目的第二哈希值，并比较第二哈希值与本次数据查询请求所携带的第一哈希值是否一致。当第二哈希值与第一哈希值一致时，表明当前服务器上的全量列表条目相对终端上一次从服务器拉取的全量列表条目没有发生更新，则服务器仅向终端返回数据未更新的提示，避免了相同全量列表条目的重复传输，减少数据传输资源的浪费。

在一个实施例中，第二哈希值可以是服务器在全量列表条目发生更新时计算得到。一旦数据库中全量列表条目发生更新，服务器立即对全量列表条目对应的第二哈希值进行更新。如此，每当结合到终端发送的数据查询请求，更新的全量列表条目对应的第二哈希值已计算完毕，服务器只需将最新计算得到的第二哈希值与第一哈希值进行比较，提高数据查询效率，进而有助于提高列表显示效率。

在一个实施例中，服务器定期计算数据库中存储的全量列表条目的第二哈希值，并将第二哈希值与最后一次发送至终端的第一哈希值进行比较。当发现第二哈希值与第一哈希值不同时，服务器主动通知终端进行数据更新。具体地，服务器按照上述方式对更新的全量列表条目进行压缩，将压缩后的更新的全量列表条目及第二哈希值打包发送至终端。终端在接收到压缩包后进行本地缓存更新。这种方式，无需等待终端主动触发数据查询请求才将更新的列表条目发送至终端，而是一旦全量列表条目发生更新，则立即将更新的全量列表条目发送至终端，便于用户及时了解最新的列表条目的数据。

在一个实施例中，参考图8，图8示出了一个实施例中本申请提供的列表显示及查询方法的应用环境图。如图8所示，用户在需要展示好友消息列表的客户端向后台服务器发起好友消息列表查询请求。后台服务器根据列表查询请求携带的用户标识，在数据库中查询用户标识所对应目标用户的所有好友数据。后台服务器将查询到的全部好友数据发送至其他计算设备，由其他计算机设备计算查询到的全部好友数据的第二哈希值，并对查询到的全部好友数据进行压缩。其他计算机设备将哈希值和压缩后的全部好友数据返回至后台服务器。后台服务器将哈希值和压缩后的全部好友数据分别转化为二进制字节流数据，采用包头存储二进制字节流数据的数据长度，采用包体存储哈希值和压缩后的全部好友数据分别对应的二进制字节流数据，将包含包头和包体的压缩包返回至终端。终端收到了全部的好友数据，无需进行去重，将接收到的全部好友数据缓存至本地自行分页显示即可。

S706，当第二哈希值与第一哈希值不一致时，对查询到的全量列表条目及第二哈希值打包压缩，得到压缩包。

具体地，当第二哈希值与第一哈希值不一致时，表明当前服务器上的全量列表条目相对终端上一次从服务器拉取的全量列表条目发生了更新，则服务器基于预设的压缩算法对查询到的全量列表条目进行压缩。所采用的压缩算法具体可以是PKZIP、GZIP、NG、Lempel-Ziv(LZ)、DEFLATE或LZR(LZ-Renau)等。终端对第二哈希值和压缩后的全量列表条目进行打包，生成压缩包。

S708，将压缩包返回至终端，使终端根据压缩包记录的更新的全量列表条目和第二哈希值对本地所缓存的全量列表条目及第一哈希值更新，并分页显示更新的全量列表条目。

具体地，服务器将压缩包返回至终端，以响应终端发起的本次数据查询请求。终端将本地缓存的上一次从服务器拉取的全量列表条目替换为从压缩包解析得到的第二哈希值和更新的全量列表条目。终端根据压缩包进行本地缓存更新以及分页显示的具体限定可参考步骤S208及S210的描述，在此不再赘述。

上述列表查询方法，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用的数据处理负担，提高应用性能，间接提高列表显示效率。

在一个实施例中，获取与查询到的全量列表条目所对应的第二哈希值包括：计算查询到的全量列表条目中每个列表条目对应的哈希值；按照全量列表条目间的排列顺序将多个哈希值记录至中间文件；将中间文件对应的哈希值确定为全量列表条目的第二哈希值。

具体地，服务器基于MD5算法对查询到的每个符合数据查询条件的列表条目分别进行哈希运算，得到每个列表条目对应的哈希值。可以理解，服务器还可以对列表条目进行其他运算得到其他能够唯一标识相应列表条目的信息。服务器将所有列表条目对应的哈希值按照相应列表条目在全量列表条目中的排列顺序依次存储至中间文件。服务器基于MD5算法对中间文件进行哈希运算，生成中间文件对应的哈希值。服务器将中间文件对应的哈希值作为全量列表条目的数据标识。当服务器上的全量列表条目的排列顺序或数据内容发生更新，则对应的哈希值发生变更。

本实施例中，基于有序排列的多个列表条目分别对应的哈希值生成全量列表条目对应的数据标识，可以提高数据标识的标识性。

在一个实施例中，对查询到的全量列表条目及第二哈希值打包压缩，得到压缩包包括：对查询到的全量列表条目进行压缩；计算第二哈希值和压缩后全量列表条目的数据长度和；将数据长度和、第二哈希值及压缩后全量列表条目打包，得到压缩包。

其中，数据长度是指数据所包含字符数量或根据所包含字符数量确定的其他数值。本实施例计算得到的第二哈希值和压缩后全量列表条目的数据长度和即为上文的第一数据长度和。

具体地，服务器将压缩后的全量列表条目以及对应第二哈希值分别转为二进制字节流数据，确定压缩后的全量列表条目所对应二进制字节流数据的第一数据长度以及第二哈希值所对应二进制字节流数据的第二数据长度。服务器对第一数据长度与第二数据长度进行求和，得到压缩后的更新的全量列表条目与第二哈希值的第一数据长度和。服务器将第一数据长度和也转化为二进制字节流数据。服务器将第一数据长度和、压缩后更新的全量列表条目以及第二哈希值分别对应的二进制字节流数据进行打包，得到压缩包。

参考图9，图9示出了一个实施例中基于全量列表条目生成的压缩包的数据结构示意图。如图9所示，压缩包包括包头和包体。其中，包头用于存储第一数据长度和对应的二进制字节流数据。本实施例中第一数据长度和对应二进制字节流数据的数据长度可以是固定的，如4字节等。包体用于存储压缩后更新的全量列表条目以及第二哈希值分别对应的二进制字节流数据。

在本实施例中，将压缩得到的全量列表条目和第二哈希值的数据长度和一同发送至终端，便于终端快速对接收到全量列表条目是否完整进行验证，只有在验证通过时才基于接收到的全量列表条目对本地缓存的全量列表条目进行更新，提高了本地缓存的列表条目的准确性，进而提高列表显示准确性。

在一个实施例中，数据查询请求还携带了终端在每个分页需要显示的列表条目的数量；对查询到的全量列表条目及第二哈希值打包压缩，得到压缩包包括：根据数量及查询到的全量列表条目中单个列表条目的数据量，确定对全量列表条目进行分页传输的第一数据量；根据查询到的全量列表条目对应的数据量及预设压缩方式的压缩比例，确定对全量列表条目进行全量传输的第二数据量；当第二数据量超过第一数据量时，根据第一数据量将查询到的全量列表条目划分为多组列表条目；按照预设压缩方式对每组列表条目进行打包压缩，得到多个压缩包；将压缩包返回至终端包括：将多个压缩包并行传输至终端。

其中，压缩比例(Compression ratio)是数据压缩后的大小与压缩前的大小之比，例如：把100MB的数据压缩后是70MB，压缩比例为70/100*100％＝70％，压缩比例一般是越小越好，但是压缩比例越小，对应的解压时间越长。服务器可以基于不同的压缩算法对更新的全量列表条目进行压缩。不同压缩算法可以实现不同的压缩比例。

具体地，服务器根据预设压缩方式的压缩比例，计算根据数据查询请求所查询到的全量列表条目的第二数据量。可以理解，第二数据量是一次性将全量列表条目传输至终端的数据量，记作对全量列表条目进行全量传输的第二数据量。第一数据量是将单页列表条目传输至终端的数据量，记作对全量列表条目进行分页传输的第一数据量。服务器根据第一数据量以及第二数据量，确定生成压缩包的数量。

当第二数据量大于第一数据量时，服务器根据第一数据量预设压缩方式的压缩比例，确定单个压缩包的目标数据量。比如，假设第一数据量为500MB、压缩比例为10:1，则单个压缩包所能容纳列表条目的目标数据量可以是5000MB。服务器根据目标数据量将全量列表条目划分为多组列表条目。每组列表条目可以记作区间列表条目。

按照预设压缩方式分别对每个区间列表条目进行打包压缩，生成每个区间列表条目对应的压缩包。单个压缩包所容纳的列表条目的数据量不超过目标数据量。每个压缩包的包头均存储有全量列表条目与对应第二哈希值的数据长度和，包体存储压缩后的相应区间列表条目和第二哈希值。服务器调用与区间列表条目数量对应的线程，将多个压缩包并行传输至终端。

在一个实施例中，每个压缩包的包头还记录有对应区间列表条目的数据长度，便于终端根据每个压缩包记录的相应区间列表条目的数据长度快速计算得到对应全量列表条目的数据长度。

在一个实施例中，每个压缩包的包头还记录有对应区间列表条目中第一顺序列表条目和最后顺序列表条目分别在全量列表条目中的顺序。比如，一个压缩包记录的区间列表条目为全量列表条目中第20至30个列表条目，则该压缩包中可通过[20,30]数组等方式记录起始列表条目在全量列表条目中的顺序。如此，便于终端根据接收到的多个压缩包所记录的数组元素是否连续快速验证接收到的全量列表条目是否完整。

在一个实施例中，服务器也可以在查询到更新的列表条目后，按照上述方式对更新的列表条目进行打包压缩，得到全量的压缩包。服务器计算全量的压缩包对应的总数据量。当总数据量超过第一数据量时，服务器将全量的压缩包拆分为多个区间的压缩包。每个区间的压缩包的数据量小于或等于第一数据量。

在本实施例中，确定采用分页传输时单次需要传输的第一数据量是，当根据第一数据量确定生成的压缩包的数量，能够保证每个压缩包的数据量不查过第一数据量，进而采用本实施例提供的全量查询的方式实现列表显示，在免去了终端进行数据处理以及频繁与服务器进行数据交互的数据处理负担的同时，可以保持与分页查询相当的查询请求响应效率。

如图10所示，在一个具体的实施例中，列表显示生成方法可应用于图1中服务器120，该方法具体包括以下步骤：

S1002，根据终端的数据查询请求，查询符合数据查询条件的全量列表条目；数据查询请求携带了终端本地所缓存的全量列表条目的第一哈希值以及终端在每个分页需要显示的列表条目的数量。

S1004，计算查询到的全量列表条目中每个列表条目对应的哈希值。

S1006，按照全量列表条目间的排列顺序将多个哈希值记录至中间文件。

S1008，将中间文件对应的哈希值确定为全量列表条目的第二哈希值。

S1010，当第二哈希值与第一哈希值不一致时，根据数量及查询到的全量列表条目中单个列表条目的数据量，确定对全量列表条目进行分页传输的第一数据量。

S1012，根据查询到的全量列表条目对应的数据量及预设压缩方式的压缩比例，确定对全量列表条目进行全量传输的第二数据量。

S1014，当第二数据量超过第一数据量时，根据第一数据量将查询到的全量列表条目划分为多组列表条目。

S1016，按照预设压缩方式对每组列表条目进行压缩。

S1018，计算第二哈希值和压缩后全量列表条目的数据长度和。

S1020，将数据长度和、第二哈希值及压缩后全量列表条目打包，得到压缩包。

S1022，将压缩包返回至终端，使终端根据压缩包记录的更新的全量列表条目和第二哈希值对本地所缓存的全量列表条目及第一哈希值更新，并分页显示更新的全量列表条目。

针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用的数据处理负担，提高应用性能，间接提高列表显示效率。

上述列表显示方法，服务器增了数据压缩以及哈希值生成的逻辑，采用包头加包体压缩成二进制流的数据交互方式，一次将所有的列表条目数据返回给客户端，同时增加了哈希值比对，减少了终端对列表条目去重以及与服务器频繁交互的数据处理负担，极大地提升了终端系统性能，继而加快了列表显示效率。当社区类应用要对全量列表条目做排序、分析等特殊业务逻辑处理时，若采用传统的分页查询的方式，则需要多次与服务器进行交互，才能查询到全部的列表条目，而本实施例的方案中社区类应用将不再需要进行去重处理，利于对社区类应用进行业务逻辑上的扩展。

图7和10为一个实施例中列表查询方法的流程示意图。应该理解的是，虽然图7和10的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图7和10中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

如图11所示，在一个实施例中，提供了列表显示装置1100，包括数据更新确认模块1102、全量数据获取模块1104和数据分页显示模块1106。

数据更新确认模块1102，用于当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值；当第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自服务器的压缩包。

全量数据获取模块1104，用于对压缩包解压缩，获得更新的全量列表条目和第二哈希值；根据解压缩得到的全量列表条目和第二哈希值，更新本地所缓存的全量列表条目及对应的第一哈希值。

数据分页显示模块1106，用于将更新的全量列表条目进行分页显示。

在一个实施例中，数据更新确认模块1102还用于根据触发列表查询的操作，向服务器发起数据查询请求；数据查询请求携带了查询字段及第一哈希值；使服务器获取与查询字段相匹配的目标的全量列表条目对应的第二哈希值；接收服务器在第一哈希值与第二哈希值不一致时返回的通过对目标的全量列表条目进行打包压缩而生成的压缩包。

在一个实施例中，当与查询字段相匹配的列表条目的数量确定时，目标的全量列表条目包括与查询字段相匹配的全部列表条目。

在一个实施例中，当与查询字段相匹配的列表条目的数量不确定时，目标的全量列表条目包括在第一哈希值生成时间至第二哈希值生成时间期间所产生的与查询字段相匹配的列表条目。

在一个实施例中，当第一哈希值生成时间至第二哈希值生成时间的时间长度超过预设时长时，目标的全量列表条目包括在第二哈希值生成时间之前预设时长内所产生的与查询字段相匹配的列表条目。

在一个实施例中，数据更新确认模块1102还用于获取每个分页需要显示的列表条目的数量；根据数量及本地所缓存的全量列表条目中单个列表条目的数据量，确定分页传输本地所缓存的全量列表条目的第一数据量；接收服务器在全量传输所存储全量列表条目的第二数据量超过第一数据量时，并行传输的根据第一数据量对所存储全量列表条目进行打包压缩生成的多个压缩包。

在一个实施例中，压缩包包括压缩后的更新的全量列表条目与第二哈希值的第一数据长度和；全量数据获取模块1104还用于当解压缩得到的全量列表条目和第二哈希值的第二数据长度和等于第一数据长度和时，根据解压缩得到的全量列表条目和第二哈希值，更新本地所缓存的全量列表条目及对应的第一哈希值。

上述列表显示装置，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，终端可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用数据处理负担，提高应用性能，间接提高列表显示效率。

如图12所示，在一个实施例中，提供了列表查询装置1200，包括数据标识比对模块1202、全量数据压缩模块1204和全量数据发送模块1206。

数据标识比对模块1202，用于根据终端的数据查询请求，查询符合数据查询条件的全量列表条目；数据查询请求携带了终端本地所缓存的全量列表条目的第一哈希值；获取与查询到的全量列表条目所对应的第二哈希值。

全量数据压缩模块1204，用于当第二哈希值与第一哈希值不一致时，对查询到的全量列表条目及第二哈希值打包压缩，得到压缩包。

全量数据发送模块1206，用于将压缩包返回至终端，使终端根据压缩包记录的更新的全量列表条目和第二哈希值对本地所缓存的全量列表条目及第一哈希值更新，并分页显示更新的全量列表条目。

在一个实施例中，数据标识比对模块1202还用于计算查询到的全量列表条目中每个列表条目对应的哈希值；按照全量列表条目间的排列顺序将多个哈希值记录至中间文件；将中间文件对应的哈希值确定为全量列表条目的第二哈希值。

在一个实施例中，全量数据压缩模块1204还用于对查询到的全量列表条目进行压缩；计算第二哈希值和压缩后全量列表条目的数据长度和；将数据长度和、第二哈希值及压缩后全量列表条目打包，得到压缩包。

在一个实施例中，数据查询请求还携带了终端在每个分页需要显示的列表条目的数量；全量数据压缩模块1204还用于根据数量及查询到的全量列表条目中单个列表条目的数据量，确定对全量列表条目进行分页传输的第一数据量；根据查询到的全量列表条目对应的数据量及预设压缩方式的压缩比例，确定对全量列表条目进行全量传输的第二数据量；当第二数据量超过第一数据量时，根据第一数据量将查询到的全量列表条目划分为多组列表条目；按照预设压缩方式对每组列表条目进行打包压缩，得到多个压缩包；全量数据发送模块1206还用于将多个压缩包并行传输至终端。

上述列表查询装置，针对每次查询的全量列表条目生成对应的哈希值，使在触发列表查询后，终端可以首先通过对比本地缓存的全量列表条目对应的第一哈希值与服务器上的全量列表条目对应的第二哈希值是否一致，来对全量列表条目是否发生更新进行确认，只有在发生了更新时，才从服务器拉取更新的全量列表条目，而未发生更新时仅进行了小数据量的第二哈希值的传输，避免了对大数据量的全量列表条目的重复传输，借此也减少了终端对拉取重复全量列表条目的无效等待时间，间接提高列表查询效率。当确定第一哈希值与第二哈希值不一致后，终端一次性从服务器获取包含全部分页需要显示的全量的列表条目的压缩包，通过压缩减少数据传输量可以提高列表查询效率，且由于是一次性查询全量的数据，可以在保证列表查询效率的情况下减少终端与服务器之间的交互次数并免去数据去重的过程，大大降低了应用数据处理负担，提高应用性能，间接提高列表显示效率。

图13示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是图1中的终端110。如图13所示，该计算机设备包括该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、输入装置和显示屏。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现列表显示方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行列表显示方法。计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

在一个实施例中，本申请提供的列表显示装置可以实现为一种计算机程序的形式，计算机程序可在如图13所示的计算机设备上运行。计算机设备的存储器中可存储组成该列表显示装置的各个程序模块，比如，图11所示的数据更新确认模块、全量数据获取模块和数据分页显示模块。各个程序模块构成的计算机程序使得处理器执行本说明书中描述的本申请各个实施例的列表显示方法中的步骤。

例如，图13所示的计算机设备可以通过如图11所示的列表显示装置中的数据更新确认模块执行步骤S202和S204。计算机设备可通过全量数据获取模块执行步骤S206和S208。计算机设备可通过数据分页显示模块执行步骤S210。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述列表显示方法的步骤。此处列表显示方法的步骤可以是上述各个实施例的列表显示方法中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述列表显示方法的步骤。此处列表显示方法的步骤可以是上述各个实施例的列表显示方法中的步骤。

图14示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是图1中的服务器120。如图14所示，该计算机设备包括该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现列表查询方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行列表查询方法。

本领域技术人员可以理解，图13和图14中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，本申请提供的列表查询装置可以实现为一种计算机程序的形式，计算机程序可在如图14所示的计算机设备上运行。计算机设备的存储器中可存储组成该列表查询装置的各个程序模块，比如，图12所示的数据标识比对模块、全量数据压缩模块和全量数据发送模块。各个程序模块构成的计算机程序使得处理器执行本说明书中描述的本申请各个实施例的列表查询方法中的步骤。

例如，图14所示的计算机设备可以通过如图14所示的列表查询装置中的数据标识比对模块执行步骤S702和S704。计算机设备可通过全量数据压缩模块执行步骤S706。计算机设备可通过全量数据发送模块执行步骤S708。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述列表查询方法的步骤。此处列表查询方法的步骤可以是上述各个实施例的列表查询方法中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述列表查询方法的步骤。此处列表查询方法的步骤可以是上述各个实施例的列表查询方法中的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (15)

1.一种列表显示方法，包括：

当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值；

当所述第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自所述服务器的压缩包；

对所述压缩包解压缩，获得更新的全量列表条目和所述第二哈希值；

根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值；

将更新的全量列表条目进行分页显示。

2.根据权利要求1所述的方法，其特征在于，所述当第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自服务器的压缩包包括：

根据触发列表查询的操作，向服务器发起数据查询请求；所述数据查询请求携带了查询字段及所述第一哈希值；使所述服务器获取与所述查询字段相匹配的目标的全量列表条目对应的第二哈希值；

接收所述服务器在所述第一哈希值与所述第二哈希值不一致时返回的通过对所述目标的全量列表条目进行打包压缩而生成的压缩包。

3.根据权利要求2所述的方法，其特征在于，当与所述查询字段相匹配的列表条目的数量确定时，所述目标的全量列表条目包括与所述查询字段相匹配的全部列表条目。

4.根据权利要求2所述的方法，其特征在于，当与所述查询字段相匹配的列表条目的数量不确定时，所述目标的全量列表条目包括在所述第一哈希值生成时间至所述第二哈希值生成时间期间所产生的与所述查询字段相匹配的列表条目。

5.根据权利要求3所述的方法，其特征在于，当所述第一哈希值生成时间至所述第二哈希值生成时间的时间长度超过预设时长时，所述目标的全量列表条目包括在所述第二哈希值生成时间之前预设时长内所产生的与所述查询字段相匹配的列表条目。

6.根据权利要求1所述的方法，其特征在于，所述获取来自所述服务器的压缩包包括：

获取每个分页需要显示的列表条目的数量；

根据所述数量及本地所缓存的全量列表条目中单个列表条目的数据量，确定分页传输本地所缓存的全量列表条目的第一数据量；

接收所述服务器在全量传输所存储全量列表条目的第二数据量超过所述第一数据量时，并行传输的根据所述第一数据量对所存储全量列表条目进行打包压缩生成的多个压缩包。

7.根据权利要求1所述的方法，其特征在于，所述压缩包包括压缩后的更新的全量列表条目与所述第二哈希值的第一数据长度和；

所述根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值包括：

当解压缩得到的全量列表条目和所述第二哈希值的第二数据长度和等于所述第一数据长度和时，根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值。

8.一种列表查询方法，包括：

根据终端的数据查询请求，查询符合所述数据查询条件的全量列表条目；所述数据查询请求携带了所述终端本地所缓存的全量列表条目的第一哈希值；

获取与查询到的全量列表条目所对应的第二哈希值；

当所述第二哈希值与所述第一哈希值不一致时，对查询到的全量列表条目及所述第二哈希值打包压缩，得到压缩包；

将所述压缩包返回至所述终端，使所述终端根据所述压缩包记录的更新的全量列表条目和所述第二哈希值对本地所缓存的全量列表条目及所述第一哈希值更新，并分页显示更新的全量列表条目。

9.根据权利要求8所述的方法，其特征在于，所述获取与查询到的全量列表条目所对应的第二哈希值包括：

计算查询到的全量列表条目中每个列表条目对应的哈希值；

按照所述全量列表条目间的排列顺序将多个所述哈希值记录至中间文件；

将所述中间文件对应的哈希值确定为所述全量列表条目的第二哈希值。

10.根据权利要求8所述的方法，其特征在于，所述对查询到的全量列表条目及所述第二哈希值打包压缩，得到压缩包包括：

对查询到的全量列表条目进行压缩；

计算所述第二哈希值和压缩后全量列表条目的数据长度和；

将所述数据长度和、第二哈希值及压缩后全量列表条目打包，得到压缩包。

11.根据权利要求8所述的方法，其特征在于，所述数据查询请求还携带了所述终端在每个分页需要显示的列表条目的数量；所述对查询到的全量列表条目及所述第二哈希值打包压缩，得到压缩包包括：

根据所述数量及查询到的全量列表条目中单个列表条目的数据量，确定对所述全量列表条目进行分页传输的第一数据量；

根据查询到的全量列表条目对应的数据量及预设压缩方式的压缩比例，确定对所述全量列表条目进行全量传输的第二数据量；

当所述第二数据量超过所述第一数据量时，根据所述第一数据量将查询到的全量列表条目划分为多组列表条目；

按照所述预设压缩方式对每组列表条目进行打包压缩，得到多个压缩包；

所述将压缩包返回至所述终端包括：将多个压缩包并行传输至所述终端。

12.一种列表显示装置，其特征在于，所述装置包括：

数据更新确认模块，用于当触发列表查询时，获取本地所缓存的全量列表条目对应的第一哈希值；当所述第一哈希值与服务器上的全量列表条目对应的第二哈希值不一致时，获取来自所述服务器的压缩包；

全量数据获取模块，用于对所述压缩包解压缩，获得更新的全量列表条目和所述第二哈希值；根据解压缩得到的全量列表条目和所述第二哈希值，更新本地所缓存的全量列表条目及对应的所述第一哈希值；

数据分页显示模块，用于将更新的全量列表条目进行分页显示。

13.一种列表查询装置，其特征在于，所述装置包括：

数据标识比对模块，用于根据终端的数据查询请求，查询符合所述数据查询条件的全量列表条目；所述数据查询请求携带了所述终端本地所缓存的全量列表条目的第一哈希值；获取与查询到的全量列表条目所对应的第二哈希值；

全量数据压缩模块，用于当所述第二哈希值与所述第一哈希值不一致时，对查询到的全量列表条目及所述第二哈希值打包压缩，得到压缩包；

全量数据发送模块，用于将所述压缩包返回至所述终端，使所述终端根据所述压缩包记录的更新的全量列表条目和所述第二哈希值对本地所缓存的全量列表条目及所述第一哈希值更新，并分页显示更新的全量列表条目。

14.一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行如权利要求1至11中任一项所述方法的步骤。

15.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行如权利要求1至11中任一项所述方法的步骤。

Images