CN116456021A - 页面数据请求方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请提供了一种页面数据请求方法、装置、电子设备及可读存储介质。该方法包括：获取当前页面通过数据总线发送的当前网络请求；在预置的数据总线的接口数据池中查找是否存在当前网络请求的对应的服务器接口数据，得到第一查找结果；响应于第一查找结果表征接口数据池中存在对应的服务器接口数据，在预置的数据总线的请求内容数据池中根据服务器接口数据查找当前网络请求对应的网络请求数据，得到第二查找结果；响应于第二查找结果表征请求内容数据池中存在对应的网络请求数据，向当前页面通过数据总线返回对应的网络请求数据。本申请的技术方案可以节约应用程序的资源，提高数据类型的匹配度。

Description

页面数据请求方法、装置、电子设备及可读存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种页面数据请求方法、装置、电子设备及可读存储介质。

背景技术

在移动端的APP(Application，应用程序)中，每个页面有其单独需要显示的数据。在页面加载之初或者页面存活时任一需要更新数据的时刻，APP客户端会向服务器发送接口请求，并在得到响应数据后进行处理和展示。在该过程中，每个页面单独维护自己的接口请求和数据，数据可能在页面之间传递，但是一般不会跨页面保存。

每个页面单独维护自己的接口请求和数据考虑了操作简易性和数据实时正确性的要求，但会造成程序性能和用户带宽的浪费，并且由于不同页面间的数据类型不一致，页面之间传递的数据需要重新组合构造，增加了后期对代码维护的难度。

发明内容

有鉴于此，本申请实施例提供了一种页面数据请求方法、装置、电子设备及计算机可读存储介质，以解决应用程序的每个页面单独维护自己的接口请求和数据导致的资源浪费和数据类型不匹配的问题。

本申请实施例的第一方面，提供了一种页面数据请求方法，该方法包括：获取当前页面通过数据总线发送的当前网络请求；在预置的数据总线的接口数据池中查找是否存在当前网络请求的对应的服务器接口数据，得到第一查找结果，其中，接口数据池中保存有网络请求的服务器接口数据，服务器接口数据包括网络请求的参数、第一标识符和关联请求；响应于第一查找结果表征接口数据池中存在对应的服务器接口数据，在预置的数据总线的请求内容数据池中根据服务器接口数据查找当前网络请求对应的网络请求数据，得到第二查找结果，其中，请求内容数据池中保存有网络请求的网络请求数据，网络请求数据包括网络请求结果、第二标识符和页面处理展示数据；响应于第二查找结果表征请求内容数据池中存在对应的网络请求数据，向当前页面通过数据总线返回对应的网络请求数据。

本申请实施例的第二方面，提供了一种页面数据请求装置，该装置包括：获取模块，用于获取当前页面通过数据总线发送的当前网络请求；第一查找模块，用于在预置的数据总线的接口数据池中查找是否存在当前网络请求的对应的服务器接口数据，得到第一查找结果，其中，接口数据池中保存有网络请求的服务器接口数据，服务器接口数据包括网络请求的参数、第一标识符和关联请求；第二查找模块，用于响应于第一查找结果表征接口数据池中存在对应的服务器接口数据，在预置的数据总线的请求内容数据池中根据服务器接口数据查找当前网络请求对应的网络请求数据，得到第二查找结果，其中，请求内容数据池中保存有网络请求的网络请求数据，网络请求数据包括网络请求结果、第二标识符和页面处理展示数据；响应模块，用于响应于第二查找结果表征请求内容数据池中存在对应的网络请求数据，向当前页面通过数据总线返回对应的网络请求数据。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器以及存储在存储器中并且可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例与现有技术相比存在的有益效果至少包括：本申请实施例通过使用数据总线的接口数据池和请求内容数据池对不同页面的服务器接口数据和网络请求数据进行存储，并在产生新的网络请求时在接口数据池和请求内容数据池中匹配对应数据，实现了在不同页面间的服务器接口数据和网络请求数据的共享，节约了应用程序的用户带宽，提高了应用程序的程序性能以及不同页面间的数据类型的匹配度。

附图说明

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

图1是相关技术中的页面数据请求过程的示意图；

图2是相关技术中的数据类型重构过程的示意图；

图3是本申请实施例提供的一种页面数据请求方法的流程示意图；

图4是本申请实施例提供的数据存储过程的示意图；

图5是本申请实施例提供的调用API过程的示意图；

图6是本申请实施例提供的存储请求内容数据的流程示意图；

图7是本申请实施例提供的处理页面通用刷新逻辑过程的示意图；

图8是本申请实施例提供的一种页面数据请求装置的结构示意图；

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

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

相关技术中，移动端APP的每个页面单独维护自己的接口请求和数据，这些数据一般不会跨页面保存，其中，跨页面保存指的是将数据存在一个公共的地方，并被多个页面共享，从而使得数据不需要在页面之间传递。

每个页面单独维护自己的接口请求和数据会造成程序性能和用户带宽的浪费，并且由于不同页面间的数据类型不一致，页面之间传递的数据需要重新组合构造，增加了后期对代码维护的难度。

具体地，针对每个页面单独维护自己的接口请求和数据造成程序性能和用户带宽的浪费的问题，举例如图1所示：

页面A，页面B，页面C都有用户信息的展示。页面A是订单列表页，当点击列表中的某一个订单，跳转至订单详情页的页面B，在页面B上，用户可以点击用户信息区域，进入页面C，页面C上展示着用户信息的具体项目，如名称、地址以及电话等。用户可以对其中的一项或某几项进行修改操作。

当用户修改了页面C上的用户信息后，点击提交按钮，页面C调用服务器接口，更新用户信息，此时订单列表页的页面A和订单详情页的页面B上的用户数据都要进行相应的更新。这时，可以在页面C调用服务器接口成功后立刻发送通知，让页面A和页面B去重新请求服务器接口并刷新界面，也可以在页面A和页面B重新进入页面时，调用模板方法去重新请求服务器接口并刷新界面。

上述做法虽然能确保数据实时性，却造成了程序性能和用户带宽的浪费。因为页面C调用了服务器接口，页面A和页面B也需要调用对应的服务器接口。如果这3个页面使用的获取用户信息的服务器接口是同一个接口，就相当于同一个服务器接口在很短的时间内被调用了3次，会增加对服务器的压力，浪费用户带宽。对客户端来说，客户端为了让这三个调用之间互不干扰，需要开启三个线程逐一进行处理，会造成数据处理的压力。

针对每个页面单独维护自己的接口请求和数据造成数据类型不一致，页面之间传递的数据需要重新组合构造的问题，举例如图2所示：

页面A，页面B都要展示一部分同样的数据，但是这些数据的来源并不相同。页面A是通过服务器接口得到这些数据的，所以页面A维护自己的数据实体类ClassA，页面B通过其它页面传递这些数据到自身从而展示，也可能是通过其它服务器接口得到这些数据，所以它定义自己的数据实体类ClassB，两个页面的这部分同样的数据，分别在ClassA和ClassB的部分成员属性中存储，但是属性名和属性的类型都不一致。

当页面A需要跳转到页面B时，它需要把ClassA中对应的成员属性值读出来，进行类型和值上的转换，组合成ClassB需要的方式并赋值给ClassB的成员属性，页面B才能使用它。这种情况在实际开发中十分常见，甚至出现了专门的适配者设计模式来处理这个问题。为了避免数据实体类类型和值转换的麻烦，页面A和页面B都可以选择单独请求同样的服务器接口来获取这部分数据，这将同样造成程序性能的降低和带宽的浪费。

为解决以上问题，本申请实施例提供一种页面数据请求方案，将不同页面的多个网络请求优化为一次网络请求，并在优化的同时保持数据的实时性、协调页面之间的共享数据以及对网络数据进行统一化处理，提升程序性能、减少服务器压力、节省用户带宽。

下面将结合附图详细说明根据本申请实施例的页面数据请求方法和装置。

图3是本申请实施例提供的一种页面数据请求方法的流程示意图。本申请实施例提供的方法可以由任意具备计算机处理能力的电子设备执行，例如终端或服务器。如图3所示，该页面数据请求方法包括：

步骤S301，获取当前页面通过数据总线发送的当前网络请求。

步骤S302，在预置的数据总线的接口数据池中查找是否存在当前网络请求的对应的服务器接口数据，得到第一查找结果，其中，接口数据池中保存有网络请求的服务器接口数据，服务器接口数据包括网络请求的参数、第一标识符和关联请求。

步骤S303，响应于第一查找结果表征接口数据池中存在对应的服务器接口数据，在预置的数据总线的请求内容数据池中根据服务器接口数据查找当前网络请求对应的网络请求数据，得到第二查找结果，其中，请求内容数据池中保存有网络请求的网络请求数据，网络请求数据包括网络请求结果、第二标识符和页面处理展示数据。

步骤S304，响应于第二查找结果表征请求内容数据池中存在对应的网络请求数据，向当前页面通过数据总线返回对应的网络请求数据。

本申请实施例提出一种基于客户端的HTTP(Hyper Text Transfer Protocol，超文本传输协议)网络请求的数据总线方案。该数据总线方案采用两种数据总线的数据池，即接口数据池(InterfacePool)和请求内容数据池(DataPool)。接口数据池为对服务器接口的网络请求进行保存的数据池，请求内容数据池为对所有网络请求回来的数据进行保存的数据池。

数据总线应该维护一个属性来描述自己的当前状态，这些状态可能为网络请求数据预处理、网络请求开始、网络请求中网络请求完成、网络数据处理中以及网络数据处理完成等状态。这个状态除用于记录外，还可被外部使用iOS移动操作系统的KVO(Key-Value-Observing，键值监听)技术进行键值对观察，以便进行下一步操作。其中，在键值监听技术中，其它类可以对某个类的属性进行观察，在其发生变化时得到通知并进行自己的逻辑。

在步骤S301中，可以通过数据总线管理类获取当前页面通过数据总线发送的当前网络请求，其中，当前页面通过在本地通知中心进行注册或者进行键值监听监控的方式与数据总线管理类产生联系。

接口数据池对App中用到的所有网络请求的相关数据进行存储。每个数据的内容分为三大类。其中，第一大类为一个HTTP网络请求所需的所有常规参数，第二大类为标识一个网络请求的唯一标识符，即第一标识符，第三大类一个网络请求的关联网络请求及其执行顺序。

具体地，常规参数包括：网络请求的url(uniform resource locator，统一资源定位器)、方法、请求的参数、请求头以及参数格式等，这一类参数是HTTP请求的常见的参数，一个HTTP网络请求所需的所有常规参数如果有所不同，则应该视为不同的网络请求，需要用不同的唯一标识符。例如，网络请求M和N的url和方法等都是一样的，但是M的请求体参数中需求x和y两个参数，N的请求体参数中需求x一个参数，则M和N要用不同的唯一标识符区分，而不能写成一个。

唯一标识符在实际的程序实现上，可以是任意类型，如：字符串，数字，枚举及其组合等等。每个标识符对应一个后台数据接口。例如，如获取用户信息接口，它的唯一标识符可能是："getUserInfo"，如获取订单信息接口，它的唯一标识符可能是："getOrderInfo"。在本申请实施例中，第一标识符可以称为network identifier(网络标识符)。

某个网络请求如果一旦执行，则接下来需要顺序或同时执行的其它网络请求，关联网络请求可能有多个，所以它是一个集合。因为是集合，所以在指定关联网络请求的同时，同时也要指定集合执行的顺序是并行还是串行的，如果是串行的，其先后顺序是什么。

在本申请实施例中，需要对接口数据池中的数据进行合理的组织。例如，可以创建一个类或者结构体，通过成员属性来组织具体的组成关系。具体地，可以创建一个接口数据池类，即InterfacePool，其实例是一个单例，生命周期和App生命周期相同。如图4所示，InterfacePool有一个集合类型的成员变量，可以称为interfaceSet，它存放了所有App中用到的所有网络请求。

InterfaceSet的每个元素可以是一个字典。字典的键是网络请求的唯一标识符，字典的值对应着一个类，可以称其为接口(Interface)。这个类有很多成员变量。这些成员变量存储着一个网络请求所需的所有常规参数、其它关联网络请求的执行顺序以及其它关联网络请求，还存储着第一标识符。其中，InterfaceSet的每个元素可以是一个类而不是字典，与上述类结构相同。

DataPool中对App中用到的所有网络请求到的接口数据进行存储。它不仅仅存储原始流数据，也存储对原始数据进行一定加工处理后的数据，具体可以根据业务需求选择都存储或只存储一种。

具体地，DataPool中的数据主要为以下四类：

第一类数据为服务器接口获取到的二进制流的接口数据。

第二类数据为调用系统提供的API(Application Programming Interface，应用程序接口)将二进制流转换为程序中使用的数据结构。例如，数字、字典以及字符串等基本数据类型。

第三类数据为根据业务需求，将二进制流或者程序中使用的数据结构进一步转换成特定的类型：通用自定义数据模型。

第四类数据为根据业务需求，对通用自定义数据模型进行特殊的处理得到的数据。

具体地，第四类数据为进一步生成的特定数据模型，特定数据模型和页面的数据展示有密切关系，是页面数据展示时直接访问的对象。特定数据模型可以选择继承于通用自定义数据模型，也可以直接使用通用自定义数据模型。特定数据模型具有更多的成员属性，这些成员属性包括成员变量和成员方法。其中，特殊的处理可以为：丢弃掉某些字段、将某些字段翻译为其它类型的字段以及将某几个字段拼接后，赋值给另一个字段。例如，将某些字段翻译为其它类型的字段时，若服务器给的某个字段是int，值是1，我们将其转换为String，值为“订单已支付”。

在向请求内容数据池中存储接口数据时，根据业务需求，既可以选择对原始二进制流进行直接存储，也可以选择第二类数据至第四类数据中的任一数据结构进行存储。

请求内容数据池的第二标识符应是唯一的，用来标识某个数据。在本申请实施例中，第一标识符和第二标识符相同或者存在映射关系。具体地，第二标识符可以和第一标识符重合，也可以根据业务需求自定义。在本申请实施例中，第二标识符可以称为dataidentifier(数据标识符)。

如果第一标识符和第二标识符没有完全重合，则程序中需要存储一份关系映射表。在该关系映射表中，某个第一标识符对应着一个或多个请求内容数据池的第二标识符。这个关系映射表也支持增加、删除、修改以及查找等操作，由总线管理类Manager统一管理。

在本申请实施例中，需要对请求内容数据池中的数据进行合理的组织。例如，可以创建一个类或者结构体，通过成员属性来组织具体的组成关系。具体地，可以创建一个请求内容数据池类，即DataPool，其实例是一个单例，生命周期和App生命周期相同。如图4所示，DataPool有一个集合类型的成员变量，可以称为dataSet，它存放了所有App中用到的所有网络数据。集合中的每个元素的结构为通用自定义数据模型。其由通用的数据和具体的数据两部分组成。

通用的数据一般放在最外层和最前面，可以称为容器，包括：接口是否请求成功、接口的错误码以及接口的错误信息。具体的数据一般放在内层，用于给客户端页面展示和逻辑处理。具体的数据由数组、字典、基本数据类型构成，它是容器包裹的实际的数据。

通常情况下，页面一般用外层的通用的数据来判断接口请求是否成功，用内层的具体的数据进行逻辑处理和页面展示。外层通用的数据持有具体的数据的集合。

具体地，容器的类可以称为DataResult，其为通用自定义数据模型之一。其可以定义以下成员属性：接口是否请求成功、接口的错误码、接口的错误信息、接口的原始数据、本次请求的唯一标识。该唯一标识分为业务上的唯一标识和数据上的唯一标识。业务上的唯一标识如data identifier，数据上的唯一标识强调唯一性，可能是一串长而无意义的字符串。

具体的数据可以称为DataItem集合，因为DataResult和DataItem之间的关系是容器和内层数据的关系，所以DataResult要持有一个或多个DataItem对象集合。在本申请实施例中，可以从当前对象序列化到二进制流中，也可以从二进制流中反序列化出一个DataItem对象。其定义成员时，可以向当前容器的后端追加列表容器所有的数据。当服务器的数据是分页的列表时，请求完第一页数据后，用户下滑界面时，请求第二页数据，把第二页的数据剔除容器，把具体的数据追加到第一页具体的数据上。

具体地，存放具体的数据的类可以称为DataItem，其为通用自定义数据模型之一。整个App理论上就使用这个类及其子类作为业务数据的承载工具。其可以定义以下成员属性：内部字典。这个属性应该是私有的，对外不可见的。DataItem的成员方法基本是对它的增加、删除、修改以及查找操作。其定义以下成员方法：

通过一个键获取值，值的类型为基本数据类型或任何类，键的类型推荐为字符串常量或字符串类型的枚举。

增加一组键值对，值的类型为基本数据类型。例如，iOS中有7大基本数据类型：字符串，二进制流NSData，时间NSDate，数字NSNumber，列表NSArray，字典NSDictionary；

增加一组键值对，值的类型为任何自定义类。值的类型包括并不限于基本数据类型，可以是常用的类，如颜色NSColor，形状NSRect，也可以是自定义的数据实体类。

此外，定义的DataItem成员方法还包括：是否存在键值对、获取所有键值对、清除所有键值对、从字典转成自身、从当前对象序列化到二进制流中以及从二进制流中反序列化出一个DataItem对象。

在本申请实施例中，需要保存接口数据池和请求内容数据池承载的数据。其中，保存数据的地点包括并不限于以下任一位置：应用程序本地沙盒、内存的类或结构体和服务器端。保存的方式包括并不限于以下任一种形式：二进制流、文件以及本地数据库的表。其中，沙盒是手机中专门为每个应用程序开辟的一个供其专用的本地存储空间，其它应用程序或者用户访问这块内存需权限。

接口数据池和请求内容数据池具有永久存储性，它们的具有设定的更新机制和时机。

具体地，在App开发阶段，可以将所有服务器接口数据和网络请求数据整理，全部写入一个文件中。文件放在App的安装包里，同时在服务器中保存一份。

在App第一次启动时或App更新启动时，将App安装包里的文件内容读入内存，并拷贝到沙盒地址下，如果用到了手机端数据库，也可以拷贝到数据库中。在实际应用中，App会更新升级，打包时应将最新文件置于App的包中，当用户安装时，检测到本地手机中的App的版本号有变化，就可以进行文件的更新覆盖工作。

在请求服务器接口，得到服务器端最新的文件后，可以对App的安装包、本地内存、沙盒和数据库的文件内容进行更新。由于服务器端的文件可以随时被更新，所以应看作是最新版，优先级高于客户端的文件，当得到服务器的文件后，要对客户端的文件进行及时覆盖。

在更新数据池的API被调用时，需要及时更新内存中的相关字段，并同步更新到安装包、沙盒和数据库。

以iOS的实现为例，对接口数据池和请求内容数据池进行更新的机制和时机如下：

将App安装包里的文件内容读入内存：访问类安装包的main属性，再访问main的path(forResource：，ofType：)方法，对方法的参数传入文件在包中的名称，得到其在App安装包里的全路径；再调用类Data的初始化方法Data(contentsOf：)，对方法的参数传入全路径，得到文件的二进制流；再调用JSONSerialization的jsonObject(with：)方法，将文件的二进制流转换成程序可以识别的基本数据格式的组合；再将这个组合转换成interface实例集合，存入接口池InterfacePool的属性interfaceSet中，完成读入内存操作。

将内存中的接口集合数据拷贝进沙盒：先通过NSKeyedUnarchiver类和NSKeyedArchiver类的相关数据方法，将接口数据池的数据转换二进制流NSData的实例，再根据NSData的writeToFile或writeToURL等方法，写入沙盒对应的路径。

将内存中的接口集合数据拷贝到数据库：引入sqlite3数据库的库文件，调用C语言函数sqlite3_open(，)创建数据库链接，并把本地数据库格式文件的路径传入函数，把内存中的数据结构拼接位数据库需要的SQL(Structured Query Language，结构化查询语言)语句并通过sqlite3_prepare_v2()，sqlite3_finalize()等方法进行写入数据库操作。

将App安装包的文件拷贝进沙盒：利用类FileManager的copyItem(atPath：toPath：)方法将文件拷贝进沙盒，沙盒的路径可以由NSSearchPathForDirectoriesInDomains(_：，_：，_：)获取，也可以由URL的url(for：in：appropriateFor：create：)方法获取。

将App安装包的文件拷贝进数据库：依据上面的描述，先读出文件内容，转换成内存中的接口集合，再把数据组装成SQL语句写入数据库。

在步骤S302之后，可以响应于第一查找结果表征接口数据池中不存在对应的服务器接口数据，将对应的服务器接口数据保存到接口数据池中。

在步骤S303之后，可以响应于第二查找结果表征请求内容数据池中不存在对应的网络请求数据，向当前网络请求对应的服务器接口发送当前网络请求，并将对应的服务器接口返回的对应网络请求数据保存到请求内容数据池。

其中，在将对应的服务器接口返回的对应网络请求数据保存到请求内容数据池时，可以将对应网络请求数据进行数据处理后保存到请求内容数据池，数据处理包括以下至少一种操作：将对应网络请求数据的数据类型由二进制流转换为通用自定义数据模型、将对应网络请求数据的数据类型由二进制流转换为应用程序接口适配的数据类型以及字段选择处理。

在本申请实施例中，可以针对数据总线定义一个功能类，可以称其为总线管理类Manager，其为数据总线的数据的管理类。它的实例是一个单例，单例的生命周期和App相同。

Manager负责管理整个移动端的所有网络请求，将获取到的网络数据的二进制流转换为通用自定义数据模型，并负责进行数据缓存等其它工作。

Manager持有接口数据池和请求内容数据池的单例，即InterfacePool和DataPool，并可对它们进行增加、删除、修改以及查找等操作。为了使得外部不擅改数据池数据，InterfacePool和DataPool对外不可见，只被Manager持有和修改。

如图5所示的是四个API在一次网络请求中会被Manager调用的实施例。

在本申请实施例中，针对Manager可以定义一个接受网络请求的API，该API可以理解为一个函数。其接受外部传入的网络请求，存储它们并发起网络请求。它接受的参数有四大类，包括：一个HTTP网络请求所需的所有常规参数、标识这个网络请求的唯一标识符(network identifier)、这个网络请求的关联网络请求及其执行顺序、回调函数。其中，回调函数是非必须的，外部可用通知或者KVO形式得到网络请求完成的消息。

该函数接受到上述四类参数后，Manager可以根据network identifier在InterfacePool中进行更新存储，查询数据池InterfacePool中是否已存在该网络请求，如不存在就要加入，如已存在，但参数不一致需进行更新参数。最后，Manager开启一个线程，对该网络请求执行实际的请求服务器接口的动作。完成数据处理操作后，Manager发送通知，设置自己当前的状态为网络数据处理完成，并调用第四个参数传入的回调函数。

在本申请实施例中，针对Manager可以定义若干处理网络请求数据池的API。接口数据池InterfacePool作为缓存数据，必然存在对其增加、删除、修改以及查找的操作，因此需要定义的API包括：更新单个、更新全部、删除单个、删除全部、查询单个以及查询全部。

在本申请实施例中，针对Manager可以定义一个接受网络请求回来的数据池的API，当一个网络请求得到服务器响应并接受到对应数据后，Manager根据数据标识符dataidentifier在DataPool中进行更新存储。

具体地，可以查询数据池DataPool中是否已存在该数据，如不存在就要加入，如存在但值不一致需进行更新。同时如有的话，也要更新关联数据。最后，Manager发送通知，通知中应携带data identifier和数据的引用等相关重要信息。Manager设置描述自己当前状态属性为：数据处理完成。与该data identifier有关的页面在接受到通知后，自行刷新页面。

Manager存储网络数据的具体步骤如图6所示。

具体地，接口数据刚从接口获取到时，都是二进制流。Manager可以调用系统提供的API，将其转换为程序中使用的基本数据结构。Manager还可以根据业务需求，进一步转换成特定的类型即通用自定义数据模型。

在进行类型转换时，可以初始化一个DataResult对象，将通用的数据即上述基本数据结构填入对应的字段。

如果具体的数据是非集合的字典或者数组等基础类型，就初始化一个DataItem对象，将具体的数据根据类型的不同，调用API，填入DataItem对象对应的字段。例如，若具体的订单数据为：一个字符串(“order”：“1231”)，一个数值(“price”：333)，则可以初始化一个DataItem对象，并调用“增加一组键值对，值的类型为基本数据类型”的API，填入DataItem对象对应的字段。

若在任何情况下遇到字典，则可以调用“从字典转成自身”的API，生成一个DataItem的实例，并调用其“增加一组键值对，值的类型为任何自定义类”的API。

在本申请实施例中，可以将DataItem对象赋值到DataResult对象的“具体数据DataItem集合”属性。

此外，根据业务需求，还可以对通用自定义数据模型进行一些特殊的处理。具体地，可以访问DataResult下的DataItem集合，集合中可能有一个或多个DataItem。遍历DataItem集合，取出每一个DataItem数据，根据业务需求对取出每一个DataItem数据进行处理得到特定数据模型集合。其中，特定数据模型可以选择继承于通用自定义数据模型，也可以直接使用通用自定义数据模型。特定数据模型具有更多的成员属性。该成员属性包括成员变量和成员方法。例如，若帖子数据需要展示组合数据：由“发帖人名字+发帖内容+第一条评价”三个字段组成一个预览内容置于列表位置。上述三个字段来自于DataItem的不同字段，所以可以对DataItem实例调用：“增加一组键值对，值的类型为基本数据类型”API，键为一个新值，例如“Preview content”，值为组合数据。

在本申请实施例中，针对Manager可以定义若干处理网络请求回来的数据池的API。请求内容数据池DataPool作为缓存数据，必然存在对其增加、删除、修改以及查找的操作，因此需要定义的API包括：更新单个、更新全部、删除单个、删除全部、查询单个以及查询全部。

因为数据总线统一管理了网络请求和网络数据，所以也可以开发与数据总线架构紧耦合即和数据中心紧耦合的工具和页面。这类工具和页面的特点是：在App中反复出现，所以可以提取出通用代码，避免重复代码。外部在使用时，只需提供具体业务逻辑需求的不同点，即可快速构造出页面或效果。

以iOS开发为例，App中的列表页面会展示列表页，它页面的顶部有下拉刷新控件，底部有上滑刷新控件。其数据刷新机制为：刚进入页面时+下拉刷新+上滑刷新，这种列表页面在App中十分常见。不同点只在于具体数据构造和界面元素的不同。

在本申请实施例中，开发和数据总线紧耦合的通用列表页面的实现步骤包括：先创建一个列表展示页面，可以称其类名为ivyTableview，再构建常规的页面元素，在ivyTableview内部添加表视图UITableView实例控件、下拉刷新控件和上滑刷新控件，并实现了UITableView的两个常用代理UITableViewDelegate和UITableViewDataSource及其方法。在构建常规的页面元素后，可以构建网络请求逻辑、处理页面通用刷新逻辑以及处理处理页面不同的刷新逻辑。

具体地，在构建网络请求逻辑时，如图7所示，在数据刷新机制：在满足刚进入页面或者下拉刷新或者上滑刷新这三个时机中的一个时，执行请求网络数据的操作。具体地，数据刷新机制中的三个时机为：页面刚进入时，即iOS系统函数viewDidLoad或者viewWillAppear中，下拉刷新控件的回调函数中，上滑刷新控件的回调函数中。执行请求网络数据具体的操作中，在请求参数设置时，如果满足刚进入页面时或者下拉刷新控件这两时机中的一个时，则应设置请求的数据的开始页的索引为0。如果是上滑刷新控件，则应设置开始页的索引为上一次的索引值+1。求调用的总线API可传入回调函数，供数据到达后被调用。其中，接受到接口数据的方式为下列任选一个：接受总线发送的数据到达通知、KVO总线的状态属性以及传入的回调函数。

在处理页面通用刷新逻辑时，每得到一组网络数据，将DataResult设置为UITableView实例的一节(section)对应的数据，DataResult中的多个DataItem对应着每个表格(cell)。把一节添加到表视图的末尾，并调用表视图的系统函数reloadData()刷新页面。

如图7中，一节对应多个表格(cell)，本申请实施例中的的DataResult和DataItem也是一对多的关系。

在处理处理页面不同的刷新逻辑时，将页面可能的不同点制作成模版方法或属性，提供给外部可见。外部可以继承ivyTableview类，实现这些方法或属性，达到定制化自己页面的效果。外部可以直接使用ivyTableview类，设置这些方法或属性，达到定制化自己页面的效果。

常见的需外部设置的方法或属性包括：对表视图的拖动方法、对表视图节(section)的增加、删除、修改以及查找方法、对表视图节的个数指定方法、对表格(cell)的增加、删除、修改以及查找方法、对表格的样式定制方法、对表格的数据填充方法、对表格的用户交互响应方法以及发起请求前/后回调方法。

当用户对表视图进行拖动时，ivyTableview调用对表视图的拖动方法。当表格初始化时，ivyTableview调用对表视图节的增加、删除、修改以及查找方法。当表格初始化时，ivyTableview调用对表视图节的个数指定方法。当表格需要增加、删除、修改以及查找时，ivyTableview调用对表格的增加、删除、修改以及查找方法。当表格初始化时，ivyTableview调用对表格的样式定制方法。当接受到网络请求的数据后，ivyTableview调用对表格的数据填充方法。当用户对表视图进行点击/长按等交互时，ivyTableview调用对表格的用户交互响应方法。当发起请求前/后，ivyTableview调用发起请求前/后回调的方法，让外部可以做一些自定义操作。常见的对外部可见，只能调用的方法包括发送网络请求和接受到网络请求。

在进行列表展示页面的外部使用时，如果一个外部业务逻辑要求的列表展示页面，其布局是自定义的，数据也是自定义的，例如每个数据项由订单号，订单价格，客户名称，客户地址组成。

在本申请一种实施例中，可以在外部直接使用ivyTableview类，生成一个实例，并设置对表格的样式定制方法。初始化订单号、订单价格、客户名称以及客户地址四个控件，并按照业务需求的布局设置好位置。进一步地，再设置表格的高度方法以及设置对表格的数据填充方法。这个时候已经拿到数据DataResult和DataItem。根据索引参数，得到DataResult中对应的那项DataItem，将订单号、订单价格、客户名称以及客户地址数据设置到控件上。根据业务需求，还可以设置对表格的用户交互响应方法或其它方法。在进入页面时/用户下拉刷新时/用户上滑刷新时，对定制好的ivyTableview实例调用发送网络请求，即可。

在本申请实施例中，可以按照列表展示页面的类似实现过程实现宫格展示页面。

在应用数据总线时，以iOS在实现层面上为例，阐述页面和Manager交互，包括发送网络请求，接受接口数据以及刷新页面的全过程。

在App启动之初，初始化总线处理类Manager，初始化其2个数据池InterfacePool和DataPool，将两个数据池的配置文件读入数据池。在页面A和页面B都要展示订单列表信息时，可以任选下面一种方法和总线产生联系。

第一种方法是对iOS提供的本地通知中心NotificationCenter.default进行注册，调用NotificationCenter.default的addObserver(_：，selector：，name：，object：)方法，告诉系统需要得到名为“通知x”的通知，根据业务需求，页面A和B可以注册共同的通知，可以有各自不同的通知。

第二种方法是页面A和页面B都对总线处理类Manager的状态字段进行KVO监控。具体为：通过方法[addObserver：forKeyPath：options：context：]方法注册KVO，通过方法[observeValueForKeyPath：ofObject：change：context：]实现KVO的监听。

在本申请实施例中，在页面真正调用数据池中的数据时，传入参数为回调函数。

在页面A需要刷新时，页面A对数据总线管理类Manager请求订单列表的服务器接口。在服务器数据返回后，Manager调用API将数据存入数据池，并发送本地通知“通知x”，设置网络请求状态，调用回调函数。

页面A和页面B虽然都要展示订单列表信息，但是页面A和页面B要求的字段不一样，展示逻辑也不一样，例如：页面A需要的订单单项的订单状态只需要数字，但是页面B需要字符串展示，如以“已支付”。页面A需要展示订单的地址，页面B不需要展示订单的地址但需要展示订单的金额。总结一下，页面A和页面B需要不同的数据实体。所以利用具体的数据的定义，在这一步对原始数据实体DataItem进行处理，加入页面A和页面B各自需要的字段，生成2个新的实例。或者生成DataItem的子类，加入页面A和页面B各自需要的字段，生成2个新的实例。页面A和B得到“通知x”通知或KVO通知，得到各自需要的数据实体DataItem，刷新各自的界面。

具体地，如果是“通知x”通知，页面A和页面B可以从通知所带的userinfo属性中得到对应数据；也可以收到通知后，通过单例Manager获得数据池的对应数据，然后刷新页面。如果是KVO通知，页面A和页面B检测Manager的状态字段的具体值，当其为网络数据处理完成时，通过单例Manager获得数据池的对应数据，然后刷新页面。

采用本申请实施例的技术方案，可以减少非必要的网络请求，节省用户手机耗电量和流量，可以对App用到的数据和网络请求进行统一管理，提升程序效率，还可以统一数据格式，减少代码开发量和难度。

根据本申请实施例的页面数据请求方法，通过使用数据总线的接口数据池和请求内容数据池对不同页面的服务器接口数据和网络请求数据进行存储，并在产生新的网络请求时在接口数据池和请求内容数据池中匹配对应数据，实现了在不同页面间的服务器接口数据和网络请求数据的共享，节约了应用程序的用户带宽，提高了应用程序的程序性能以及不同页面间的数据类型的匹配度。

下述为本申请装置实施例，可以用于执行本申请方法实施例。下文描述的页面数据请求装置与上文描述的页面数据请求方法可相互对应参照。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图8是本申请实施例提供的一种页面数据请求装置的示意图。如图8所示，本申请实施例中的页面数据请求装置包括：

获取模块801，用于获取当前页面通过数据总线发送的当前网络请求。

第一查找模块802，用于在预置的数据总线的接口数据池中查找是否存在当前网络请求的对应的服务器接口数据，得到第一查找结果，其中，接口数据池中保存有网络请求的服务器接口数据，服务器接口数据包括网络请求的参数、第一标识符和关联请求。

第二查找模块803，用于响应于第一查找结果表征接口数据池中存在对应的服务器接口数据，在预置的数据总线的请求内容数据池中根据服务器接口数据查找当前网络请求对应的网络请求数据，得到第二查找结果，其中，请求内容数据池中保存有网络请求的网络请求数据，网络请求数据包括网络请求结果、第二标识符和页面处理展示数据。

响应模块804，用于响应于第二查找结果表征请求内容数据池中存在对应的网络请求数据，向当前页面通过数据总线返回对应的网络请求数据。

在本申请实施例中，页面数据请求装置还可以包括保存模块，用于响应于第一查找结果表征接口数据池中不存在对应的服务器接口数据，将对应的服务器接口数据保存到接口数据池中，以及响应于第二查找结果表征请求内容数据池中不存在对应的网络请求数据，向当前网络请求对应的服务器接口发送当前网络请求，并将对应的服务器接口返回的对应网络请求数据保存到请求内容数据池。

上述保存模块还用于将对应网络请求数据进行数据处理后保存到请求内容数据池，数据处理包括以下至少一种操作：将对应网络请求数据的数据类型由二进制流转换为通用自定义数据模型、将对应网络请求数据的数据类型由二进制流转换为应用程序接口适配的数据类型以及字段选择处理。

在本申请实施例中，获取模块还用于通过数据总线管理类获取当前页面通过数据总线发送的当前网络请求，其中，当前页面通过在本地通知中心进行注册或者进行键值监听监控的方式与数据总线管理类产生联系。

由于本申请的示例实施例的页面数据请求装置的各个功能模块与上述页面数据请求方法的示例实施例的步骤对应，因此对于本申请装置实施例中未披露的细节，请参照本申请上述的页面数据请求方法的实施例。

根据本申请实施例的页面数据请求装置，通过使用数据总线的接口数据池和请求内容数据池对不同页面的服务器接口数据和网络请求数据进行存储，并在产生新的网络请求时在接口数据池和请求内容数据池中匹配对应数据，实现了在不同页面间的服务器接口数据和网络请求数据的共享，节约了应用程序的用户带宽，提高了应用程序的程序性能以及不同页面间的数据类型的匹配度。

图9是本申请实施例提供的电子设备9的示意图。如图9所示，该实施例的电子设备9包括：处理器901、存储器902以及存储在该存储器902中并且可在处理器901上运行的计算机程序903。处理器901执行计算机程序903时实现上述各个方法实施例中的步骤。或者，处理器901执行计算机程序903时实现上述各装置实施例中各模块的功能。

电子设备9可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备9可以包括但不仅限于处理器901和存储器902。本领域技术人员可以理解，图9仅仅是电子设备9的示例，并不构成对电子设备9的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器901可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器902可以是电子设备9的内部存储单元，例如，电子设备9的硬盘或内存。存储器902也可以是电子设备9的外部存储设备，例如，电子设备9上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器902还可以既包括电子设备9的内部存储单元也包括外部存储设备。存储器902用于存储计算机程序以及电子设备所需的其它程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种页面数据请求方法，其特征在于，所述方法包括：

获取当前页面通过数据总线发送的当前网络请求；

在预置的所述数据总线的接口数据池中查找是否存在所述当前网络请求的对应的服务器接口数据，得到第一查找结果，其中，所述接口数据池中保存有网络请求的服务器接口数据，所述服务器接口数据包括网络请求的参数、第一标识符和关联请求；

响应于所述第一查找结果表征所述接口数据池中存在所述对应的服务器接口数据，在预置的所述数据总线的请求内容数据池中根据所述服务器接口数据查找所述当前网络请求对应的网络请求数据，得到第二查找结果，其中，所述请求内容数据池中保存有网络请求的网络请求数据，所述网络请求数据包括网络请求结果、第二标识符和页面处理展示数据；

响应于所述第二查找结果表征所述请求内容数据池中存在所述对应的网络请求数据，向所述当前页面通过所述数据总线返回所述对应的网络请求数据。

2.根据权利要求1所述的方法，其特征在于，得到第一查找结果之后，所述方法还包括：

响应于所述第一查找结果表征所述接口数据池中不存在所述对应的服务器接口数据，将所述对应的服务器接口数据保存到所述接口数据池中。

3.根据权利要求1所述的方法，其特征在于，得到第二查找结果之后，所述方法还包括：

响应于所述第二查找结果表征所述请求内容数据池中不存在所述对应的网络请求数据，向所述当前网络请求对应的服务器接口发送所述当前网络请求，并将所述对应的服务器接口返回的对应网络请求数据保存到所述请求内容数据池。

4.根据权利要求1所述的方法，其特征在于，将所述对应的服务器接口返回的对应网络请求数据保存到所述请求内容数据池，包括：

将所述对应网络请求数据进行数据处理后保存到所述请求内容数据池，所述数据处理包括以下至少一种操作：将所述对应网络请求数据的数据类型由二进制流转换为通用自定义数据模型、将所述对应网络请求数据的数据类型由二进制流转换为应用程序接口适配的数据类型以及字段选择处理。

5.根据权利要求1所述的方法，其特征在于，所述接口数据池的数据保存在以下任一位置：应用程序本地沙盒、内存的类或结构体和服务器端；和/或，所述请求内容数据池的数据保存在以下任一位置：应用程序本地沙盒、内存的类或结构体和服务器端。

6.根据权利要求1所述的方法，其特征在于，所述第一标识符和所述第二标识符相同或者存在映射关系。

7.根据权利要求1所述的方法，其特征在于，获取当前页面通过数据总线发送的当前网络请求，包括：通过数据总线管理类获取所述当前页面发送的所述当前网络请求，其中，所述当前页面通过在本地通知中心进行注册或者进行键值监听监控的方式与所述数据总线管理类产生联系。

8.一种页面数据请求装置，其特征在于，所述装置包括：

获取模块，用于获取当前页面通过数据总线发送的当前网络请求；

第一查找模块，用于在预置的所述数据总线的接口数据池中查找是否存在所述当前网络请求的对应的服务器接口数据，得到第一查找结果，其中，所述接口数据池中保存有网络请求的服务器接口数据，所述服务器接口数据包括网络请求的参数、第一标识符和关联请求；

第二查找模块，用于响应于所述第一查找结果表征所述接口数据池中存在所述对应的服务器接口数据，在预置的所述数据总线的请求内容数据池中根据所述服务器接口数据查找所述当前网络请求对应的网络请求数据，得到第二查找结果，其中，所述请求内容数据池中保存有网络请求的网络请求数据，所述网络请求数据包括网络请求结果、第二标识符和页面处理展示数据；

响应模块，用于响应于所述第二查找结果表征所述请求内容数据池中存在所述对应的网络请求数据，向所述当前页面通过所述数据总线返回所述对应的网络请求数据。

9.一种电子设备，包括存储器、处理器以及存储在所述存储器中并且可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述方法的步骤。