CN104216695A - 提供页面待展现信息及展现页面信息的方法及系统 - Google Patents

Abstract

本申请公开了提供页面待展现信息及展现页面信息的方法及系统，其中，所述展现页面信息的方法可以包括：预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；根据本地加载的数据以及从服务器端加载的数据进行页面展现。通过本申请，能够减少在收到用户浏览请求之后与服务器端进行的数据交互量，进而可以加快页面的加载速度，并且避免产生过大的流量。

Description

提供页面待展现信息及展现页面信息的方法及系统

技术领域

本申请涉及移动互联网技术领域，特别是涉及提供页面待展现信息及展现页面信息的方法及系统。

背景技术

在移动互联网时代，手机等移动终端已经开始超过桌面电脑(台式机、笔记本等)成为人们最常用的上网设备。通过移动终端，人们可以使用即时通信软件来“聊天”，可以使用微博等社交网站进行“互动”，还可以听音乐看电影等等。而随着电子商务交易平台的移动终端版客户端的出现，人们还可以通过移动终端浏览交易平台中提供的商品信息，还可以购买感兴趣的商品，等等。

然而，与桌面电脑不同，移动终端需要通过无线网络来接入互联网。在有Wi-Fi热点信号的情况下，移动终端可以通过Wi-Fi热点来接入互联网。这种方式相当于是将移动终端连接到一条ADSL(Asymmetric Digital SubscriberLine，非对称数字用户环路)或者别的上网线路上，可以与该上网线路上连接的其他终端(包括桌面电脑以及其他移动终端)共享网络带宽，产生的流量也是按照该上网线路对应的计费标准进行计费。在采用了“包月”、“包年”等缴费方式的情况下，移动终端产生的流量不会带来额外的费用，并且这种上网线路的带宽一般都比较大，联网的速度会比较快。

但是，Wi-Fi热点一般需要借助与无线路由器等设备才能实现，只有在无线路由器的电波覆盖的有效范围内，才可以采用Wi-Fi连接方式进行联网。因此，在很多情况下是无法通过Wi-Fi热点接入互联网的，此时，只能通过2G(第二代移动通信技术)、3G等方式来接入。然而，由于技术、成本以及运营等多方面的原因，导致通过2G或者3G网络接入网络时，速度一般会比较慢，并且是按照流量来计费的，收费标准也相对较高。因此，对于对流量消耗较大的手机应用而言，在没有Wi-Fi热点的情况下，一般无法得到较好的利用。例如，对于某移动终端版的电子商务交易平台而言，由于一般需要通过包含有大量图片的网页来展示各个商品的信息，而图片这种资源一般需要很大的数据量，因此，在通过2G或3G网络上网时，图片加载的速度会比较慢，在浏览的过程中带来的网络流量也会非常大，从而限制了在移动终端中的使用率，并且增加了访问成本。

发明内容

本申请提供了提供页面待展现信息展现页面信息的方法及系统，能够减少在收到用户浏览请求之后与服务器端进行的数据交互量，进而可以加快页面的加载速度，并且避免产生过大的流量。

本申请提供了如下方案：

一种提供页面待展现信息的方法，包括：

按照预置的数据结构，将页面的待展现数据中数据更新周期及数据量符合预置条件的部分数据生成数据包；

接收到下载数据包的请求时，将所述数据包发送到客户端，以便客户端在本地保存所述数据包，并在接收到用户访问网页的请求时，从本地加载所述数据包中的数据；

接收到加载页面的请求时，根据页面的待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据，并返回给客户端。

一种展现页面信息的方法，包括：

预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；

接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；

向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；

根据本地加载的数据以及从服务器端加载的数据进行页面展现。

一种提供页面待展现信息的服务器，包括：

数据包生成单元，用于按照预置的数据结构，将页面的待展现数据中数据更新周期及数据量符合预置条件的部分数据生成数据包；

数据包发送单元，用于接收到下载数据包的请求时，将所述数据包发送到客户端，以便客户端在本地保存所述数据包，并在接收到用户访问网页的请求时，从本地加载所述数据包中的数据；

待展现数据返回单元，用于接收到加载页面的请求时，根据页面的待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据，并返回给客户端。

一种展现页面信息的客户端，包括：

下载单元，用于预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；

本地加载单元，用于接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；

服务器加载单元，用于向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；

展现单元，用于根据本地加载的数据以及从服务器端加载的数据进行页面展现。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，对于包含有数据量较大但更新周期相对较长的数据的页面而言，可以由服务器端预先按照一定的数据结构生成数据包，并由客户端预先将数据包下载到终端设备本地；这样，后续在接收到用户的访问请求时，可以直接从本地保存的数据包进行加载并进行页面的展现，而不用再与服务器端实时交互这些数据。可见，由于数据包已经预先下载到本地，因此，相当于可以实现一种离线的页面加载，这减少了在收到用户浏览请求之后与服务器端进行的数据交互量，进而可以加快页面的加载速度，并且避免产生过大的流量，有利于提高电子商务交易平台等应用或服务在移动终端中的使用率。

其中，如果页面中的待展现信息包括多个类目，则可以分别针对各个类目生成数据包，然后在客户端的用户界面上为用户提供订阅指定类目的选择入口，这样，可以仅将用户选择订阅的数据包下载到用户终端设备本地，而其他类目的数据包则不再下载，后续进行页面展现时，也仅向用户展现关于其订阅类目的信息即可。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的展现页面信息的方法的流程图；

图2是本申请实施例提供的提供页面待展现信息的方法的流程图；

图3是本申请实施例提供的展现页面信息的客户端的示意图；

图4是本申请实施例提供的提供页面待展现信息的服务器的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

对于电子商务交易平台等应用或者服务而言，之所以在浏览其网页的过程中会产生很大的流量，是因为，当一个终端用户通过交易平台的客户端发起浏览请求之后，客户端需要向服务器端请求数据，服务器端向客户端传输具体的页面数据时，由于大量的图片等大数据量资源的存在，会产生很大的流量，同时也会使得页面加载速度很慢。在本申请实施例中，考虑到一些页面中的数据的更新速度并不是很快，例如，可能每天或者每两天甚至更长的时间才会更新一次，如果页面中的数据还没有更新，则用户在t1时刻访问网页时以及在t2时刻访问网页时，看到的网页上的信息是相同的。因此，对于这种信息而言，可以不必在用户需要浏览时即时地向服务器端请求下载，而是可以预先从服务器端下载到本地进行保存，这样，当用户需要浏览时，直接从本地进行加载即可，而不用重新向服务器端请求下载相关的数据，显然，这样就可以大大降低在浏览这种网页时产生的流量。例如，在实际应用中，可以在移动终端通过Wi-Fi热点连接到网络的情况下，将数据包下载到本地，这样，如果后续移动终端已经不在某Wi-Fi热点的信号覆盖范围内，需要通过2G或3G技术接入网络，则可以采用离线加载的方式来响应用户访问网页的请求。当然，在具体实现时，将会涉及到更多具体的技术细节，下面进行详细地介绍。

实施例一

参见图1，本申请实施例提供了一种展现页面信息的方法，该方法可以包括以下步骤：

S101：预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；

首先，为了实现离线加载，需要在服务器端生成数据包，然后客户端从服务器端进行下载，保存到客户端所在的终端设备本地。具体实现时，服务器端可以根据页面中待展现信息的更新周期及其数据量来选择性地加入到数据包中。也就是说，如果一些数据更新速度很快，或者对实时性的要求很高，则一般不适于进行离线加载；另外，如果一些数据占用的数据量很小，实时与服务器交互的情况下也不会产生很大的流量，则没有必要进行离线加载。对于一个页面而言，其中可能包括多种数据，可能其中一部分是适合于进行离线加载的，另一部分则不适合或者没有必要。因此，服务器端在生成数据包时，可以对页面中的待展现信息进行分析，仅将其中适合于并且有必要(也即在更新周期以及数据量两方面进行衡量)进行离线加载的部分数据生成数据包，以供客户端进行下载，而其他的不适合于或者不必要进行离线加载的数据，则可以通过客户端与服务器端的实时交互进行加载及展现。

例如，对于团购网站的商品列表信息页面，其中可能需要展现很多个商品的链接，商品链接中一般包含一些图片以及文字摘要信息，另外还可能会包括商品价格信息。团购网站的商品列表一般是每天才会更新一次，或者时间可能更长，但是同一件商品的成交数量、价格可能会受到具体交易的影响，更新的更频繁一些；因此，对于这种页面而言，商品的名称、商品链接中的图片及文字摘要信息属于适合于进行离线加载的信息，而价格、成交数量等则不适合于离线加载，这样，可以仅将商品的名称、ID、需要在链接中显示的图片以及文字描述信息，按照一定的数据结构生成数据包。客户端可以预先将这种数据包下载到本地。其中，由于这种用于展现商品列表的页面中一般包含有多个商品的链接，因此，在生成数据包时，可以按照条目保存各个商品对应的信息，每条信息可以包括对应商品的ID、名称、在商品列表页面中显示商品链接时的链接图片以及链接文本信息，等等。其中，如果一个商品ID对应多个图片，则图片之间可以以分号(也可以约定其他的分隔符)进行分隔。例如，每条数据可以分为以下字段：

商品ID：商品1；

图片：{图片1；图片2；图片3；...}；

文字详情信息。

另外，对于上述用于展现商品列表的页面而言，其中展现的一般都是一些商品的链接，而当用户点击其中某条链接之后，就可以进入到展现对应商品的详情的页面。在商品详情页面中，一般需要展现出关于该商品的大量图片，另外还可能包括一些文字描述信息，以及用户对该商品的评价信息等等。而在这种用于展现商品详情的页面中，显然其中的图片、文字等描述信息的更新周期一般会比较长，只有成交数量、价格以及用户评价信息等可能会更新地比较频繁。因此，这种页面中包括的图片、文字等描述信息也都适合于进行离线加载，即，可以由服务器端按照一定的数据结构生成数据包，而价格以及用户评价信息则可以在用户需要浏览时实时向服务器端请求。

具体实现时，对于上述用于展现多个商品的列表的页面以及用于展现某个特定商品的详情的页面而言，前者相当于是一个目录，后者相当于是进入到某个具体的条目。因此，在生成数据包时，可以针对这两种页面生成同一个数据包，用商品ID将两者联系起来，也就是说，可以在数据包中按条目保存各个商品分别在商品列表页面以及商品详情页面中展现时的商品信息，每条商品信息包括商品ID、图片信息以及详情描述信息。换言之，数据包中的某条数据可以包含以下信息：某商品的ID、该商品在商品列表页面中显示时需显示的图片以及文字描述信息、以及该商品在商品详情列表中显示时需显示的图片及文字描述信息。这样，无论是请求访问商品列表页面还是商品详情页面，就都可以加载同一个数据包来完成页面的展现。

需要说明的是，关于服务器端生成数据包时所采用的数据结构，可以是与客户端协商好的，这样，客户端才能够正常的解析并加载预先从服务器端获取到的数据包。例如，在一种实现方式下，这种数据结构可以是JSON(JavaScriptObject Notation，javascript中的对象和数组)，当然也可以是其他的数据结构，这里不做限定。当然，无论采用何种具体的数据结构，为了后续数据的定位和加载方便，均可以按照基础数据(例如，某团购网站某一天的团购商品信息，等等)的生成页序列表进行存储。

另外需要说明的是，关于数据包中保存的信息，如果其中存在图片等信息，则可以分为图片的描述信息以及具体的图片数据两部分内容，在下载数据包的同时，可将图片的描述信息以及图片数据全部下载到本地。其中，前文所述的按条目保存的数据中保存的就是图片的描述信息，主要是指图片的保存路径。也就是说，对于某个商品对象而言，在数据包中保存其数据时，可以生成一条数据，其中，这条数据中保存有商品ID、对应的各个图片的路径、商品的文字描述信息这样几个字段；关于具体的图片数据，则可以在数据包中的另一个文件夹中来保存，图片的路径也就是对应该文件夹中各个图片的相对路径。所谓的相对路径是指相对于数据包所在的位置的路径。例如，客户端下载了某数据包之后，将其保存在C盘某名称为A的目录下，则该数据包所在的位置为C：\A\aa，其中，“aa”为数据包名称。假设用于保存具体图片数据的文件夹是aa下某个名称为bb的文件夹，则根据数据包的存放位置可以得到图片所在文件夹的路径为C：\A\aa\bb，再结合具体的图片名称即可组成一个图片的完整路径，进而定位到具体的图片。

另外，对于一个页面中包含多个商品对象信息的情况，具体在生成数据包时，服务器端可以直接将页面中各个商品对象中适合于进行离线加载的数据都加入到数据包中；或者，在商品对象数量非常多的情况下，考虑到一般并不是所有的商品对象的信息都是用户需要的，因此，也可以从中截取一定数目的商品对象(例如前20个等等)，并将其中适于进行离线加载的数据加入到数据包中。

此外，在实际应用中，还可以允许用户订阅其中的部分商品对象的信息。例如，一般情况下，一个页面中展现出的商品对象可能存在多个类目，例如，服装类、休闲娱乐类、生活用品类等等，因此，可以针对各个类目分别生成对应的数据包；并在客户端为用户提供可订阅的类目入口，如果用户选择订阅某个或者某些类目，则可以仅将这个或者这些类目对应的数据包从服务器端下载到本地；最终在向用户展现页面信息时，也可以仅将这个或者这些类目对应的信息展现在页面中。

当然，对于已经下载到用户终端本地的数据包，虽然其中的数据的更新周期相对较长，但是一般也是会更新的，因此，在实际应用中，也需要对本地的数据包进行更新。具体实现时，当对应的数据发生更新后，服务器端可以直接向用户终端推送用于更新的数据，客户端可以对数据包进行更新。由于加入到数据包中的数据的更新周期一般不会太短，因此，更新数据包的操作也不会太频繁。例如，同样以团购网站为例，如果网站中的商品信息每天更新一次，则数据包也可以相应的每天更新一次。或者，为了避免自动的更新过程给用户带来干扰或者更新时恰好是移动终端处于无Wi-Fi热点覆盖的情况，也可以在客户端为用户提供用于手动发起更新操作的操作入口，这样，用户可以自行选择更新数据包的时机，相应的，客户端可向服务器端请求获取用于更新的数据，在服务器端返回之后，在本地对数据包进行更新即可。

需要说明的是，在以往的网页缓存技术中，一般是在用户第一次访问一个网页时，服务器将页面数据发送到客户端，然后客户端可以在本地缓存网页数据，这样下次用户再访问相同的网页时，使用缓存的数据对页面进行加载及展现。而在本申请实施例中，服务器在向客户端发送或者更新数据包时，并不以用户访问网页的请求为触发条件，也就是说，并不是在接收到用户访问某网页的请求时将数据包发送给用户，在用户本地缓存，而是在接收到专用于下载数据包的请求后，将数据包发送给用户，之后可以定期或者不定期地向用户的客户端发送更新数据。

S102：接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；

由于预先已经将数据包下载并保存在了本地，因此，当用户需要浏览该页面时，就可以直接从本地对数据包进行加载，而不需要再与服务器端交互这部分数据。例如，如果用户请求浏览的是前述商品列表页面，则可以直接从本地加载数据包，获取到各个商品对象的名称、链接图片及文字等数据。

S103：向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；

由于之前下载到本地的数据包中仅包含了待展现页面数据中的一部分，因此，还可以向服务器请求获取各个商品对象对应的价格等信息未包含在本地数据包中的页面数据，以便最终再将本地加载的信息以及从服务器端加载的信息一起展现在页面中即可。在此过程中，虽然价格等信息是重新与服务器端进行交互之后才获取到的信息，但是，由于成交数量、价格等信息一般都是一些文字信息，占用的数据量非常小，因此，服务器端回传的数据量已经大大减小，产生的流量也大大降低。

如果用户点击了商品列表页面中的某个商品的链接，则同样可以在本地加载对应的数据包，并根据被点击的链接对应的商品ID，获取到数据包中该I D对应的需要在详情页面中展现的图片、文字等信息，然后在新的页面展现这些信息即可。当然，如果商品详情信息中还包括有成交数量、价格、用户评论等未包含在本地数据包中的页面数据，则还可以通过与服务器端的实时交互获取到，并连同本地加载的信息一起展现在页面中。

其中，如果用户订阅了某个类别的数据包，则在向服务器端请求数据时，也仅需要请求该类别中未包含在数据包中的数据即可。为此，可以在每次向服务器端发送页面加载请求时，在页面加载请求中携带上当前用户订阅的类目信息，这样，服务器端就可以返回该类目下未包含在该类目数据包中的待展现的页面数据。或者，在另一种实现方式下，也可以在服务器端保存用户标识信息与其订阅的类目信息之间的对应关系，这样，在向服务器端发送页面加载请求时，就可以直接在页面加载请求中携带上用户的标识信息即可，而不用携带该用户订阅的类目信息，服务器端根据页面加载请求中携带的用户标识信息，以及之前记录的用户标识与订阅的类目之间的对应关系，就可以获知该用户订阅的类目，并返回该类目下未包含在该类目数据包中的待展现的页面数据。

在实际应用中，客户端在接收到一个页面浏览请求之后，还可以首先确定是否需要采用离线加载模式进行加载，如果需要，再从本地进行加载，否则，就可以采用传统的方式向服务器端获取实时的页面数据。其中，具体在确定是否需要采用离线加载模式进行加载时，一种实现方式可以是：在用户界面上为用户提供选择离线模式进行加载的操作入口，如果通过该入口接收到用户的指令，则确定需要采用离线加载模式进行加载，进而从本地加载对应的数据包即可。或者，也可以采用自动判断的方式来进行确定，例如，在接收到用户浏览某网页的请求之后，可以首先通过系统接口等判断当前移动终端的联网方式，如果是采用Wi-Fi等方式联网，则不需要采用离线加载模式，而如果是采用的2G或者3G方式联网，则需要采用离线加载模式，进而从本地预先获取到的数据包进行加载即可。当然，在实际应用中，还可以向用户提供切换到传统加载模式的操作入口，或者也可以在监控发现当前终端已经采用Wi-Fi等联网方式之后，自动切换为传统加载模式进行页面的加载。

S104：根据本地加载的数据以及从服务器端加载的数据进行页面展现。

在完成本地数据包及服务端的加载之后，或者在加载的同时，就可以对页面进行渲染，以便将加载结果展现在页面中，这样用户就可以在页面中浏览到商品列表或者商品的详情等等，并且在以较快的速度浏览到页面内容的同时，还不会产生大的流量。

这里需要说明的是，对于一个页面而言，其中的图片、文字等通常需要按照一定的样式进行展现，例如，包括图片显示的位置、大小，文字的字体、颜色、字号、与图片之间的位置关系等等；在常规的页面展现过程中，不仅需要从服务器端获取具体的图片、文字等数据，还要获取到页面的样式信息，最终客户端需要按照该样式信息来进行具体页面元素的展现。而在本申请实施例中，对于图片、文字等数据，已经预先下载到本地，因此，具体在展现时，关于展现的样式可以是预先默认设置好的，也就是说，客户端可以自定义一种页面样式，直接按照该样式对本地加载的数据进行展现即可。或者，在另一种实现方式下，可以在本地加载具体数据的同时，向服务器端获取页面的样式信息，之后再按照服务器端返回的样式信息，对本地加载的数据进行展现。当然，如果还需要向服务器端获取商品的价格、用户评论信息等数据，也可以连同样式信息一起向服务器发起请求，最终按照服务器端返回的样式信息，对本地加载的数据以及服务器端加载的数据进行展现。这样，可以保证用户最终看到的页面与常规方式下加载时看到的页面是完全相同的。

需要说明的是，关于页面的样式信息，主要以CSS(Cascading Style Sheet，级联样式表)代码等形式存在，所需的数据量很小，因此，实时交互所带来的流量也会比较小。

当然，对于电子商务交易平台而言，在将商品列表或者商品详情等信息展现给用户之后，还应该能够对接下来的购买指定商品等流程进行支持。在本申请实施例中，虽然页面中显示部分数据是从本地加载的，但是，电子商务各个环节的后续流程与常规的方法都是相同的。例如，对于“购买”指定商品的流程，由于数据包中保存有商品ID信息，并且页面中也同样为各个商品提供有“购买”等操作入口，因此，如果用户通过某商品的购买操作入口进入，则客户端可以获取到该商品的ID，并向服务器端发送相关的信息，这种相关信息可以包括“购买”这一事件、对应的商品ID，另外还可能包括用户选择的参数信息，例如颜色、尺寸、件数等等；相应的，服务器端就可以根据收到的相关信息生成订单确认页面，并将相关的数据返回给客户端进行展现。

总之，在本申请实施例中，对于包含有数据量较大但更新周期较长的数据的页面而言，可以由服务器端预先生成数据包，并由客户端预先将数据包下载到终端设备本地；这样，后续在接收到用户的访问请求时，直接从本地保存的数据包进行加载并进行页面的展现即可。可见，由于数据包已经预先下载到本地，因此，相当于可以实现一种离线的页面加载，减少了在收到用户浏览请求之后与服务器端进行的数据交互量，进而可以加快页面的加载速度，并且避免产生过大的流量，有利于提高电子商务交易平台等应用或服务在移动终端中的使用率。

实施例二

以上实施例一从客户端的角度对本申请实施例提供的技术方案进行了详细地介绍，下面从服务器的角度对本申请实施例的技术方案进行介绍。参见图2，从服务器角度，本申请实施例提供了一种提供页面待展现信息的方法，该方法可以包括以下步骤：

S101：按照预置的数据结构，将页面的待展现数据中数据更新周期及数据量符合预置条件的部分数据生成数据包；

S102：接收到下载数据包的请求时，将所述数据包发送到客户端，以便客户端在本地保存所述数据包，并在接收到用户访问网页的请求时，从本地加载所述数据包中的数据；

S103：接收到加载页面的请求时，根据页面的待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据，并返回给客户端。

其中，如果页面中包括至少两个类目的数据，则数据包可以包括分别与各个类目相对应的至少两个数据包，在这种情况下，客户端可以选择下定指定类目对应的数据包，对于服务器端而言，在接收到下载指定类目的数据包的请求时，将该类目的数据包发送到客户端。

服务器端在接收到客户端的加载页面的请求时，如果该请求中携带有当前用户指定的类目信息，则可以根据页面中该类目下的待展现数据以及该类目的数据包中包含的部分数据，确定需要向客户端返回的待展现数据。

或者，服务器端也可以保存用户的标识信息与该用户订阅的类目信息之间的对应关系，在这种情况下，服务器端在接收到下载指定类目的数据包的请求时，根据该请求中携带的用户标识信息，保存用户标识信息与该用户指定的类目信息之间的对应关系；而在接收到客户端的加载页面的请求时，可以根据请求中携带有当前用户的标识信息，查询之前保存的对应关系，确定该用户所需的类目信息；然后，根据页面中该类目下的待展现数据以及该类目的数据包中包含的部分数据，确定需要向客户端返回的待展现数据。

在实际应用中，所述页面包括用于展现商品列表的第一页面或用于展现指定商品详情的第二页面，所述数据包中按条目保存有各个商品分别在所述第一页面及第二页面中展现时的商品信息，每条商品信息包括商品I D、图片信息以及文字描述信息。

为了使得客户端在显示能够保持服务器端定义的页面样式，还可以在接收到加载页面的请求时，向客户端返回页面的样式信息。

需要说明的是，上述实施例二与实施例一相比仅是描述的角度有所不同，因此，实施例二中具体的实现细节可以参见实施例一中的记载，鉴于篇幅限制，这里不再赘述。

与本申请实施例提供的展现页面信息的方法相对应，本申请实施例还提供了一种展现页面信息的客户端，参见图3，该客户端可以包括：

下载单元301，用于预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；

本地加载单元302，用于接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；

服务器加载单元303，用于向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；

展现单元304，用于根据本地加载的数据以及从服务器端加载的数据进行页面展现。

在实际应用中，所述页面包括用于展现商品列表的第一页面或用于展现指定商品详情的第二页面，所述数据包中按条目保存有各个商品分别在所述第一页面及第二页面中展现时的商品信息，每条商品信息包括商品ID、图片信息以及文字描述信息。

相应的，本地加载单元202具体可以包括：

第一加载子单元，用于接收到浏览所述第一页面信息的请求后，加载本地保存的数据包；

所述展现单元203可以包括：

第一展现子单元，用于根据所述数据包中各个条目保存的商品信息，提取各个商品在第一页面中展现时的商品信息，并展现在所述第一页面中。

另外，本地加载单元202具体也可以包括：

第二加载子单元，用于接接收到浏览所述第一页面中的某指定商品对应的第二页面信息的请求后，加载本地保存的数据包；

所述展现单元203具体可以包括：

第二展现子单元，用于根据所述指定商品的ID以及数据包中保存的商品信息，提取该指定商品在第二页面中展现时的商品信息，并展现在所述第二页面中。

在实际应用中，所述第一页面中包括至少两个类目的待展现信息，此时，服务器端可以分别针对各个类目分别生成数据包，也就是说生成的所述数据包可以包括分别与各个类目相对应的至少两个数据包，所述系统还可以包括：

订阅信息展现单元，用于展现可订阅的类目信息以供用户选择；

所述下载单元201具体用于：

预先从服务器端下载用户选择订阅的类目对应的数据包。

在这种情况下，服务器加载单元303具体可以包括：

第一请求子单元，用于向服务器端发送页面加载请求，所述页面加载请求中携带有该用户订阅的类目信息，以便所述服务器端返回该类目下未包含在该类目数据包中的待展现的页面数据。

或者，在另一种实现方式下，可以在服务器端保存有用户标识信息与其订阅的类目信息之间的对应关系，此时，所述服务器加载单元303具体可以包括：

第二请求子单元，用于向服务器端发送页面加载请求，所述页面加载请求中携带有用户的标识信息，以便所述服务器端根据所述页面加载请求中携带的用户标识信息，获知该用户订阅的类目，并返回该类目下未包含在该类目数据包中的待展现的页面数据。

具体在页面中展现从本地加载的信息时，页面的样式信息可以是预先设置好的默认样式，也即展现单元203可以用于：

采用预置的默认页面样式信息，将所述本地加载的数据以及从服务器端加载的数据展现在页面中。

或者，为了与常规加载方式下显示出的页面具有相同的样式，也可以与服务器端实时交互页面的样式信息，此时，展现单元具体可以用于：

向服务器端请求获取页面样式信息；

采用服务器端返回的页面样式信息，将所述本地加载的数据以及从服务器端加载的数据展现在页面中。

另外，在实际应用中，对于一个页面而言，可能仅将其中一部分待展现信息写到数据包中并预先下载到客户端本地，而对于另一部分没有包含在数据包中的待展现信息，则可以通过与服务器端的实时交互进行加载及展现，此时，该系统还可以包括：

请求单元，用于向服务器端请求加载页面中实时更新的待展现信息；

远程加载展现单元，用于将从服务器端加载的待展现信息展现在页面中。

当然，对于本地保存的数据包而言，其中的数据也是会发生更新的，因此，该系统还可以包括：

第一更新单元，用于根据服务器端按照待展现信息的更新周期推送的用于更新数据包的数据，更新所述数据包；

或者，

第二更新单元，用于通过用户操作入口接收到用户的更新数据包请求时，向服务器端请求用于更新数据包的数据，对数据包进行更新。

在具体实现时，本地加载单元具体可以用于：

接收到浏览页面信息的请求后，确定是否采用离线加载模式进行加载，如果是，则加载本地保存的数据包。

其中，可以通过以下方式确定是否采用离线加载模式进行加载：

如果通过用户操作入口接收到用户的离线加载请求，则确定需要采用离线加载模式进行加载；

或者，

根据所在终端设备当前接入网络的方式，确定是否采用离线加载模式进行加载。

当然，在实际应用中，还可以为用户提供切换回常规加载模式的操作入口，或者，也可以对终端设备接入网络的方式进行监控，如果发现终端设备能够通过Wi-Fi热点接入，则可以自动切换回常规加载模式。

另外，与本申请实施例提供的提供页面待展现信息的方法相对应，申请实施例还提供了一种提供页面待展现信息的服务器，参见图4，该服务器可以包括：

数据包生成单元401，用于按照预置的数据结构，将页面的待展现数据中数据更新周期及数据量符合预置条件的部分数据生成数据包；

数据包发送单元402，用于接收到下载数据包的请求时，将所述数据包发送到客户端，以便客户端在本地保存所述数据包，并在接收到用户访问网页的请求时，从本地加载所述数据包中的数据；

待展现数据返回单元403，用于接收到加载页面的请求时，根据页面的待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据，并返回给客户端。

其中，如果页面中包括至少两个类目的数据，则数据包可以包括分别与各个类目相对应的至少两个数据包，在这种情况下，客户端可以选择下定指定类目对应的数据包，对于服务器端数据包发送单元402来说，具体可以用于：在接收到下载指定类目的数据包的请求时，将该类目的数据包发送到客户端。

服务器端在接收到客户端的加载页面的请求时，如果该请求中携带有当前用户指定的类目信息，则待展现数据返回单元403可以根据页面中该类目下的待展现数据以及该类目的数据包中包含的部分数据，确定需要向客户端返回的待展现数据。

或者，服务器端也可以保存用户的标识信息与该用户订阅的类目信息之间的对应关系，在这种情况下，服务器端在接收到下载指定类目的数据包的请求时，待展现数据返回单元403可以根据该请求中携带的用户标识信息，保存用户标识信息与该用户指定的类目信息之间的对应关系；而在接收到客户端的加载页面的请求时，可以根据请求中携带有当前用户的标识信息，查询之前保存的对应关系，确定该用户所需的类目信息；然后，根据页面中该类目下的待展现数据以及该类目的数据包中包含的部分数据，确定需要向客户端返回的待展现数据。

在实际应用中，所述页面包括用于展现商品列表的第一页面或用于展现指定商品详情的第二页面，所述数据包中按条目保存有各个商品分别在所述第一页面及第二页面中展现时的商品信息，每条商品信息包括商品ID、图片信息以及文字描述信息。

为了使得客户端在显示能够保持服务器端定义的页面样式，服务器端还可以包括：

样式信息返回单元，用于在接收到加载页面的请求时，向客户端返回页面的样式信息。

总之，在本申请实施例提供的上述系统中，对于包含有数据量较大但更新周期较长的数据的页面而言，可以由服务器端预先生成数据包，并由客户端预先将数据包下载到终端设备本地；这样，后续在接收到用户的访问请求时，直接从本地保存的数据包进行加载并进行页面的展现即可。可见，由于数据包已经预先下载到本地，因此，相当于可以实现一种离线的页面加载，减少了在收到用户浏览请求之后与服务器端进行的数据交互量，进而可以加快页面的加载速度，并且避免产生过大的流量，有利于提高电子商务交易平台等应用或服务在移动终端中的使用率。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的提供页面待展现信息及展现页面信息的方法及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (20)

1.一种提供页面待展现信息的方法，其特征在于，包括：

按照预置的数据结构，将页面的待展现数据中数据更新周期及数据量符合预置条件的部分数据生成数据包；

接收到下载数据包的请求时，将所述数据包发送到客户端，以便客户端在本地保存所述数据包，并在接收到用户访问网页的请求时，从本地加载所述数据包中的数据；

接收到加载页面的请求时，根据页面的待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据，并返回给客户端。

2.根据权利要求1所述的方法，其特征在于，所述页面中包括至少两个类目的数据；所述数据包包括分别与各个类目相对应的至少两个数据包；

所述接收到下载数据包的请求时，将所述数据包发送到客户端包括：

接收到下载指定类目的数据包的请求时，将该类目的数据包发送到客户端。

3.根据权利要求2所述的方法，其特征在于，所述接收到加载页面的请求时，根据页面的全部待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据包括：

接收加载页面的请求，所述请求中携带有当前用户指定的类目信息；

根据页面中该类目下的待展现数据以及该类目的数据包中包含的部分数据，确定需要向客户端返回的待展现数据。

4.根据权利要求2所述的方法，其特征在于，还包括：

接收到下载指定类目的数据包的请求时，根据该请求中携带的用户标识信息，保存用户标识信息与该用户指定的类目信息之间的对应关系；

所述接收到加载页面的请求时，根据页面的全部待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据包括：

接收加载页面的请求，所述请求中携带有当前用户的标识信息；

根据该用户的标识信息查询所述对应关系，确定该用户所需的类目信息；

根据页面中该类目下的待展现数据以及该类目的数据包中包含的部分数据，确定需要向客户端返回的待展现数据。

5.根据权利要求1所述的方法，其特征在于，所述页面包括用于展现商品列表的第一页面或用于展现指定商品详情的第二页面，所述数据包中按条目保存有各个商品分别在所述第一页面及第二页面中展现时的商品信息，每条商品信息包括商品ID、图片信息以及文字描述信息。

6.根据权利要求1所述的方法，其特征在于，还包括：

接收到加载页面的请求时，向客户端返回页面的样式信息。

7.一种展现页面信息的方法，其特征在于，包括：

预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；

接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；

向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；

根据本地加载的数据以及从服务器端加载的数据进行页面展现。

8.根据权利要求7所述的方法，其特征在于，所述页面包括用于展现商品列表的第一页面或用于展现指定商品详情的第二页面，所述数据包中按条目保存有各个商品分别在所述第一页面及第二页面中展现时的商品信息，每条商品信息包括商品ID、图片信息以及文字描述信息。

9.根据权利要求8所述的方法，其特征在于，所述接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载包括：

接收到浏览所述第一页面信息的请求后，加载本地保存的数据包；

所述根据本地加载的数据以及从服务器端加载的数据进行页面展现包括：

根据所述数据包中各个条目保存的商品信息，提取各个商品在第一页面中展现时的商品信息，并展现在所述第一页面中。

10.根据权利要求8所述的方法，其特征在于，所述接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载包括：

接收到浏览所述第一页面中的某指定商品对应的第二页面信息的请求后，加载本地保存的数据包；

所述根据本地加载的数据以及从服务器端加载的数据进行页面展现包括：

根据所述指定商品的ID以及数据包中保存的商品信息，提取该指定商品在第二页面中展现时的商品信息，并展现在所述第二页面中。

11.根据权利要求1所述的方法，其特征在于，所述页面中包括至少两个类目的待展现信息，所述数据包包括分别与各个类目相对应的至少两个数据包，所述方法还包括：

展现可订阅的类目信息以供用户选择；

所述预先从服务器端下载数据包包括：

预先从服务器端下载用户选择订阅的类目对应的数据包。

12.根据权利要求11所述的方法，其特征在于，所述向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据，包括：

向服务器端发送页面加载请求，所述页面加载请求中携带有该用户订阅的类目信息，以便所述服务器端返回该类目下未包含在该类目数据包中的待展现的页面数据。

13.根据权利要求11所述的方法，其特征在于，所述服务器端保存有用户标识信息与其订阅的类目信息之间的对应关系，所述向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据，包括：

向服务器端发送页面加载请求，所述页面加载请求中携带有用户的标识信息，以便所述服务器端根据所述页面加载请求中携带的用户标识信息，获知该用户订阅的类目，并返回该类目下未包含在该类目数据包中的待展现的页面数据。

14.根据权利要求7至13任一项所述的方法，其特征在于，所述根据本地加载的数据以及从服务器端加载的数据进行页面展现包括：

采用预置的默认页面样式信息，将所述本地加载的数据以及从服务器端加载的数据展现在页面中。

15.根据权利要求7至13任一项所述的方法，其特征在于，所述根据本地加载的数据以及从服务器端加载的数据进行页面展现包括：

向服务器端请求获取页面样式信息；

采用服务器端返回的页面样式信息，将本地加载的数据以及从服务器端加载的数据展现在页面中。

16.根据权利要求7至13任一项所述的方法，其特征在于，还包括：

根据服务器端按照待展现信息的更新周期推送的用于更新数据包的数据，更新所述数据包；

或者，

通过用户操作入口接收到用户的更新数据包请求时，向服务器端请求用于更新数据包的数据，对数据包进行更新。

17.根据权利要求7至13任一项所述的方法，其特征在于，所述接收到浏览页面信息的请求后，加载本地保存的数据包包括：

接收到浏览页面信息的请求后，确定是否采用离线加载模式进行加载，如果是，则加载本地保存的数据包。

18.根据权利要求17所述的方法，其特征在于，所述确定是否采用离线加载模式进行加载包括：

如果通过用户操作入口接收到用户的离线加载请求，则确定需要采用离线加载模式进行加载；

或者，

根据所在终端设备当前接入网络的方式，确定是否采用离线加载模式进行加载。

19.一种提供页面待展现信息的服务器，其特征在于，包括：

数据包生成单元，用于按照预置的数据结构，将页面的待展现数据中数据更新周期及数据量符合预置条件的部分数据生成数据包；

数据包发送单元，用于接收到下载数据包的请求时，将所述数据包发送到客户端，以便客户端在本地保存所述数据包，并在接收到用户访问网页的请求时，从本地加载所述数据包中的数据；

待展现数据返回单元，用于接收到加载页面的请求时，根据页面的待展现数据以及所述数据包中包含的部分数据，确定需要向客户端返回的待展现数据，并返回给客户端。

20.一种展现页面信息的客户端，其特征在于，包括：

下载单元，用于预先从服务器端下载数据包，并在本地进行保存；其中，所述数据包为服务器端根据页面中的待展现信息按照预置的数据结构生成的，所述数据包中保存有待展现的页面数据中更新周期及数据量符合预置条件的部分数据；

本地加载单元，用于接收到浏览页面信息的请求后，根据本地保存的数据包进行本地加载；

服务器加载单元，用于向所述服务器端请求加载未包含在所述数据包中的待展现的页面数据；

展现单元，用于根据本地加载的数据以及从服务器端加载的数据进行页面展现。