Page data request method, device, electronic device and readable storage medium

Abstract

The present application provides a page data request method, device, electronic device and readable storage medium. The method includes: obtaining the current network request sent by the current page, the current network request includes first evaluation reference data and server interface data; obtaining second evaluation reference data from the data bus according to a preset evaluation strategy; evaluating whether the current network request needs to make a server data request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtaining an evaluation result; when the evaluation result indicates that the current network request does not need to make a server data request, obtaining the network request data corresponding to the server interface data from the request content data pool of the data bus and sending it to the current page. The technical solution of the present application can reduce unnecessary network requests and improve the client page jump and response speed.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a page data request method, device, electronic device and readable storage medium. Background Art

[0002] In the mobile APP (Application), each page has its own data to be displayed. At the beginning of page loading or at any time when the page needs to update data, the APP client will send an interface request to the server, and process and display the response data after receiving it. In this process, each page maintains its own interface request and data separately. Data may be transferred between pages, but it is generally not saved across pages.

[0003] Each page maintains its own interface requests and data separately, which takes into account the requirements of ease of operation and real-time data correctness, but it will cause a waste of program performance and user bandwidth. Frequent server data requests put pressure on bandwidth, power and server resources, thereby affecting client performance and page jump response speed. Summary of the invention

[0004] In view of this, embodiments of the present application provide a page data request method, device, electronic device, and computer-readable storage medium to solve the problem of a page frequently requesting data from a server.

[0005] In a first aspect of an embodiment of the present application, a page data request method is provided, the method comprising: obtaining a current network request sent by a current page, the current network request comprising first evaluation reference data and server interface data; obtaining second evaluation reference data from a data bus according to a preset evaluation strategy; evaluating whether a server data request is required for the current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtaining an evaluation result; when the evaluation result indicates that the current network request does not require a server data request, obtaining network request data corresponding to the server interface data from a request content data pool of the data bus and sending it to the current page.

[0006] According to a second aspect of an embodiment of the present application, a page data request device is provided, which includes: a first acquisition module, used to acquire a current network request sent by a current page, the current network request including first evaluation reference data and server interface data; a second acquisition module, used to acquire second evaluation reference data from a data bus according to a preset evaluation strategy; an evaluation module, used to evaluate whether a server data request is required for the current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtain an evaluation result; and a response module, used to acquire network request data corresponding to the server interface data from a request content data pool of the data bus and send it to the current page when the evaluation result indicates that the current network request does not need a server data request.

[0007] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0008] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0009] Compared with the prior art, the embodiments of the present application have at least the following beneficial effects: the embodiments of the present application reduce the number of server requests by the page by evaluating whether a server data request is required for the current network request, and obtaining the network request data from the request content data pool of the data bus when the evaluation result is that a server data request is not required, thereby reducing bandwidth, power, and server pressure, and improving client performance as well as client page jump and response speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0011] Figure 1 is a schematic diagram of a page data request process in the related art;

[0012] Figure 2 is a schematic diagram of a data type reconstruction process in the related art;

[0013] Figure 3 It is a flowchart of a page data request method provided in an embodiment of the present application;

[0014] Figure 4 This is a data interaction diagram of a page data request method provided by an embodiment of the present application;

[0015] Figure 5 It is a schematic diagram of a process of requesting page data according to an evaluation rule provided in an embodiment of the present application;

[0016] Figure 6 is a flow chart of requesting page data according to another evaluation rule provided in an embodiment of the present application;

[0017] Figure 7 is a schematic diagram of a data storage process provided by an embodiment of the present application;

[0018] Figure 8 It is a schematic diagram of the API calling process provided by the embodiment of the present application;

[0019] Fig. 9 It is a schematic diagram of the process of storing request content data provided by an embodiment of the present application;

[0020] Fig.10 It is a schematic diagram of a general refresh logic process for processing pages provided in an embodiment of the present application;

[0021] Fig.11 It is a structural diagram of a page data request device provided in an embodiment of the present application;

[0022] Fig.12 It is a structural schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0024] In the related art, each page of the mobile APP maintains its own interface requests and data separately, and these data are generally not saved across pages. Among them, saving across pages means storing the data in a common place and being shared by multiple pages, so that the data does not need to be transferred between pages.

[0025] If each page maintains its own interface requests and data, it will cause a waste of program performance and user bandwidth. In addition, due to the inconsistency of data types between different pages, the data transferred between pages needs to be reassembled and constructed, which increases the difficulty of later code maintenance.

[0026] Specifically, each page maintains its own interface requests and data, which causes a waste of program performance and user bandwidth. For example, Figure 1 As shown:

[0027] Page A, Page B, and Page C all display user information. Page A is the order list page. When you click on an order in the list, you will be redirected to Page B, the order details page. On Page B, the user can click on the user information area to enter Page C, which displays specific items of user information, such as name, address, and phone number. The user can modify one or several of these items.

[0028] When the user modifies the user information on page C and clicks the Submit button, page C calls the server interface to update the user information. At this time, the user data on page A of the order list page and page B of the order details page must be updated accordingly. At this time, a notification can be sent immediately after page C successfully calls the server interface, so that pages A and B can re-request the server interface and refresh the interface. You can also call the template method to re-request the server interface and refresh the interface when pages A and B re-enter the page.

[0029] Although the above approach can ensure the real-time nature of data, it wastes program performance and user bandwidth. Because page C calls the server interface, page A and page B also need to call the corresponding server interface. If the server interface used by these three pages to obtain user information is the same interface, it is equivalent to the same server interface being called three times in a very short period of time, which will increase the pressure on the server and waste user bandwidth. For the client, in order to prevent the three calls from interfering with each other, the client needs to open three threads to process them one by one, which will cause pressure on data processing.

[0030] Maintaining its own interface requests and data for each page causes inconsistent data types, and the data transferred between pages needs to be recombined and restructured. For example, Figure 2 As shown:

[0031] Page A and Page B both display some of the same data, but the data comes from different sources. Page A obtains the data through the server interface, so Page A maintains its own data entity class ClassA. Page B displays the data by passing it to itself through other pages, or it may obtain the data through other server interfaces, so it defines its own data entity class ClassB. The same data on the two pages is stored in some member attributes of ClassA and ClassB, but the attribute names and attribute types are inconsistent.

[0032] When page A needs to jump to page B, it needs to read the corresponding member attribute value in ClassA, convert the type and value, combine it into the method required by ClassB, and assign it to the member attribute of ClassB before page B can use it. This situation is very common in actual development, and there is even a special adapter design pattern to deal with this problem. In order to avoid the trouble of data entity class type and value conversion, page A and page B can choose to request the same server interface separately to obtain this part of data. Frequent server data requests put pressure on bandwidth, power and server resources, thereby affecting client performance and page jump response speed.

[0033] To solve the above problems, an embodiment of the present application provides a page data request solution to reduce the number of server data requests, improve program performance, reduce server pressure, and save user bandwidth.

[0034] The page data request method and device according to the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0035] Figure 3 1 is a flow chart of a page data request method provided in an embodiment of the present application. The method provided in an embodiment of the present application can be executed by any electronic device with computer processing capabilities, such as a terminal or a server. Figure 3 As shown, the page data request method includes:

[0036] Step S301, obtaining a current network request sent by a current page, where the current network request includes first evaluation reference data and server interface data.

[0037] Step S302 : acquiring second evaluation reference data from the data bus according to a preset evaluation strategy.

[0038] Step S303: evaluating whether a server data request is required for the current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtaining an evaluation result.

[0039] Step S304, when the evaluation result indicates that the current network request does not need to make a server data request, the network request data corresponding to the server interface data is obtained from the request content data pool of the data bus and sent to the current page.

[0040] The technical solution in the embodiment of the present application relates to a data bus solution based on HTTP (Hyper Text Transfer Protocol) network requests from a client. The data bus solution uses two data bus data pools, namely, an interface data pool (InterfacePool) and a request content data pool (DataPool). The interface data pool is a data pool for storing network requests of a server interface, and the request content data pool is a data pool for storing data returned from all network requests.

[0041] Furthermore, in the embodiment of the present application, the page may not be directly connected to the data bus, but by constructing a Figure 4 The middle layer shown in the figure communicates with the page of the external caller, and the middle layer communicates with the data bus as needed.

[0042] In the embodiment of the present application, the middle layer can pre-formulate a set of evaluation schemes for network requests according to business needs. Specifically, when an external network request is sent to the middle layer, the middle layer evaluates the request according to the pre-evaluation scheme and makes a strategy, namely: whether to actually contact the data bus to make an actual network request? If no network request is made, the latest data can be directly obtained from the request content data pool of the data bus.

[0043] In step S303, whether the current network request needs to make a server data request can be evaluated based on two or any one of the following two evaluation rules: evaluation is performed based on the relationship between the current time of the current network request and the time interval between the timestamp and the set time interval threshold, wherein the timestamp is the time data of the server interface data corresponding to the current network request in the interface data pool of the data bus, the current time is the first evaluation reference data, and the timestamp and the time interval threshold are the second evaluation reference data; evaluation is performed based on the current version number of the request content data of the current network request and the historical version number of the request content data corresponding to the current network request in the request content data pool of the data bus, wherein the current version number is the first evaluation reference data, and the historical version number is the second evaluation reference data.

[0044] Specifically, the evaluation schemes corresponding to the above two evaluation rules are used to further control the frequency of network requests and evaluate the newness of data bus data. When implementing the evaluation strategy, you can choose any one evaluation rule to implement the evaluation, or you can use a combination of two evaluation rules to implement the evaluation.

[0045] After step S303, when the evaluation result indicates that the current network request needs to make a server data request, a server data request corresponding to the current network request is sent to the network server via the data bus, and the network request data corresponding to the current network request returned by the network server is sent to the current page.

[0046] In step S304, if the time interval is greater than or equal to the time interval threshold, the server data request corresponding to the current network request is sent to the network server through the data bus, and the network request data corresponding to the current network request returned by the network server is saved in the request content data pool and sent to the current page; if the time interval is less than the time interval threshold, the network request data corresponding to the current network request is obtained from the request content data pool and sent to the current page.

[0047] In step S304, if the current version number is greater than or equal to the historical version number, the server data request corresponding to the current network request is sent to the network server through the data bus, and the network request data corresponding to the current network request returned by the network server is saved in the request content data pool and sent to the current page; if the current version number is less than the historical version number, the network request data corresponding to the current network request is obtained from the request content data pool and sent to the current page.

[0048] In an embodiment of the present application, after the network request data corresponding to the current network request returned by the network server is saved in the request content data pool, the current version number corresponding to the newly saved network request data can also be processed according to the set version sorting rules to obtain a new version number and save the new version number synchronously with the newly saved network request data.

[0049] In an embodiment of the present application, an evaluation can be performed based on the relationship between the current request count of the current network request and a set count threshold, wherein the current request count is the first evaluation reference data and the count threshold is the second evaluation reference data.

[0050] like Figure 5 As shown, when evaluating the relationship between the time interval between the current time of the current network request and the timestamp and the set time interval threshold, the evaluation is based on the time interval between two identical network requests. Specifically, the evaluation process includes the following steps:

[0051] The middle layer pre-plans a set of network request intervals based on business needs. This set of plans can be pre-stored in the App installation package in the form of a file, or written on the server for easy update at any time.

[0052] When the App starts, the middle layer accesses the Manager's InterfacePool, retrieves the data of each network request, and assigns it an attribute: the predetermined interval allowed by business needs. Different network requests can have different allowed request intervals.

[0053] For example: The real-time requirements for order interface data are very high, so the interval time must be very short, so it can be set to 0.1 seconds. The real-time requirements for user address information are not high, so the interval time can be set to 4 hours. Or it can be used to determine whether it has been requested x times during the life cycle of this App. The data of the user agreement interface hardly changes, and the business believes that it only needs to be requested once during the entire life cycle of the App, or once every few days. Therefore, the interval time can be set to 7 days, or it can be used to determine whether it has been requested once during the life cycle of this App.

[0054] The data bus manager adds an API to add, delete, modify, and query the timestamp of each network request data in its InterfacePool. During the life cycle of the App, every time there is a network request, the external layer first accesses the middle layer, and the middle layer first accesses the InterfacePool of the data bus manager, retrieves the data of the network request, checks its request timestamp, and calculates the time interval from the last request: current time - timestamp.

[0055] If this value is greater than or equal to the preset interval, the middle layer accesses the API of the data bus Manager to make an actual network request and updates the request timestamp of the network request in the InterfacePool. The obtained interface data is returned to the outside from the Manager API. If this value is less than the preset interval, the middle layer accesses the API of the data bus Manager to obtain the latest cached interface data and returns it to the outside.

[0056] The timestamp algorithm can also be simplified to the number of times judgment: when making a request, record that the request has been executed x times, and then compare this number to derive the strategy for each time: whether it is necessary to actually send the request. According to business needs, the middle layer can adjust the timestamp in the Manager's data pool at any time to achieve specific purposes.

[0057] like Figure 6As shown, when evaluating the current version number of the request content data of the current network request and the historical version number of the request content data corresponding to the current network request in the request content data pool of the data bus, the evaluation is based on the newness as the core. Specifically, the evaluation process includes the following steps: the data bus Manager adds an API for adding, deleting, modifying and checking the version number of each network request data in its DataPool. At the beginning of the App startup, the data bus Manager sets the version number of each data, if any, to an initial value, for example, the initial value can be set to 0. If there is no data for the time being, the version number is assigned to the initial value when the data is generated for the first time. During the life cycle of the App, each time there is a network request, the external first accesses the middle layer, with the version number of the data obtained from the outside, and the middle layer first accesses the DataPool of the data bus Manager, takes out the data, and checks its version number. Compare the external data version number with the version number of the DataPool data to obtain the maximum version number for backup.

[0058] If the external data version number is greater than or equal to the version number of the DataPool data, it means that the external data is newer. Then the middle layer accesses the API of the data bus Manager to make an actual network request. After obtaining the interface data, the Manager updates the version number of this data: the maximum version number + 1. And returns it to the outside. If the external data version number is less than the version number of the DataPool data, it means that the data in the data pool DataPool is newer. Then the middle layer accesses the API of the data bus Manager to obtain the network data and returns it to the outside. According to business needs, the middle layer can adjust the version number of external data or the data in the Manager's data pool at any time to achieve specific purposes.

[0059] When the Manager of the data bus directly obtains the page webpage request data without using the middle layer, the current network request sent by the current page can be obtained, and the corresponding server interface data of the current network request can be searched in the preset interface data pool to obtain a first search result, wherein the interface data pool stores the server interface data of the network request, and the server interface data includes the parameters of the network request, the first identifier, and the associated request. Afterwards, in response to the first search result indicating that the corresponding server interface data exists in the interface data pool, the network request data corresponding to the current network request is searched in the preset request content data pool according to the server interface data, and a second search result is obtained, wherein the network request data of the network request is stored in the request content data pool, and the network request data includes the network request result, the second identifier, and the page processing display data. Afterwards, in response to the second search result indicating that the corresponding network request data exists in the request content data pool, the corresponding network request data is returned to the current page.

[0060] The embodiment of the present application proposes a data bus solution based on HTTP (Hyper Text Transfer Protocol) network requests from a client. The data bus solution uses two data bus data pools, namely an interface data pool (InterfacePool) and a request content data pool (DataPool). The interface data pool is a data pool that stores network requests of a server interface, and the request content data pool is a data pool that stores data returned from all network requests.

[0061] The data bus should maintain an attribute to describe its current state, which may be network request data preprocessing, network request start, network request in progress, network data processing, and network data processing completed. In addition to being used for recording, this state can also be used externally to observe key-value pairs using the iOS mobile operating system's KVO (Key-Value-Observing) technology for the next step. Among them, in the key-value monitoring technology, other classes can observe the attributes of a class, get notified when it changes, and perform their own logic.

[0062] In an embodiment of the present application, the current network request sent by the current page can be obtained through the data bus management class, wherein the current page is connected to the data bus management class by registering in the local notification center or performing key-value listening monitoring.

[0063] The interface data pool stores the data related to all network requests used in the App. The content of each data is divided into three categories. Among them, the first category is all the general parameters required for an HTTP network request, the second category is the unique identifier that identifies a network request, that is, the first identifier, and the third category is the associated network requests of a network request and their execution order.

[0064] Specifically, the general parameters include: the URL (uniform resource locator) of the network request, the method, the request parameters, the request header, and the parameter format, etc. This type of parameters is common parameters of HTTP requests. If all the general parameters required by an HTTP network request are different, they should be regarded as different network requests and need to use different unique identifiers. For example, the URL and method of network requests M and N are the same, but the request body parameters of M require two parameters x and y, and the request body parameters of N require one parameter x. Then M and N should be distinguished by different unique identifiers, and cannot be written as one.

[0065] In actual program implementation, the unique identifier can be of any type, such as: string, number, enumeration and their combination, etc. Each identifier corresponds to a background data interface. For example, if the user information interface is obtained, its unique identifier may be: "getUserInfo", and if the order information interface is obtained, its unique identifier may be: "getOrderInfo". In the embodiment of the present application, the first identifier can be called a network identifier.

[0066] Once a network request is executed, other network requests need to be executed sequentially or simultaneously. There may be multiple associated network requests, so it is a set. Because it is a set, when specifying the associated network requests, you also need to specify whether the order of the collection execution is parallel or serial. If it is serial, what is the order of execution.

[0067] In the embodiment of the present application, the data in the interface data pool needs to be organized reasonably. For example, a class or structure can be created to organize specific composition relationships through member attributes. Specifically, an interface data pool class, namely InterfacePool, can be created, whose instance is a singleton and has the same life cycle as the App life cycle. Figure 7 As shown, InterfacePool has a member variable of collection type, which can be called interfaceSet, which stores all network requests used in all apps.

[0068] Each element of InterfaceSet can be a dictionary. The key of the dictionary is the unique identifier of the network request, and the value of the dictionary corresponds to a class, which can be called an interface. This class has many member variables. These member variables store all the regular parameters required for a network request, the execution order of other related network requests, and other related network requests, and also store the first identifier. Among them, each element of InterfaceSet can be a class instead of a dictionary, which is the same as the above class structure.

[0069] DataPool stores all the interface data requested by the network used in the App. It not only stores the original stream data, but also stores the data after processing the original data. You can choose to store all or only one type according to business needs.

[0070] Specifically, the data in DataPool mainly falls into the following four categories:

[0071] The first type of data is the interface data of the binary stream obtained by the server interface.

[0072] The second type of data is the data structure used in the program by converting the binary stream into the data structure used in the program by calling the API (Application Programming Interface) provided by the system, such as basic data types such as numbers, dictionaries, and strings.

[0073] The third type of data is to further convert binary streams or data structures used in programs into specific types based on business needs: general custom data models.

[0074] The fourth type of data is the data obtained by performing special processing on the general custom data model according to business needs.

[0075] Specifically, the fourth type of data is a further generated specific data model. The specific data model is closely related to the data display of the page and is the object directly accessed when the page data is displayed. The specific data model can choose to inherit from the general custom data model, or directly use the general custom data model. The specific data model has more member attributes, which include member variables and member methods. Among them, special processing can be: discarding certain fields, translating certain fields into other types of fields, and concatenating several fields and assigning them to another field. For example, when translating certain fields into other types of fields, if a field given by the server is int and the value is 1, we convert it to String with a value of "Order Paid".

[0076] When storing the interface data in the request content data pool, according to business requirements, you can choose to directly store the original binary stream, or you can choose to store any data structure from the second to fourth types of data.

[0077] The second identifier of the request content data pool should be unique and used to identify a certain data. In an embodiment of the present application, the first identifier and the second identifier are the same or have a mapping relationship. Specifically, the second identifier can overlap with the first identifier, or can be customized according to business needs. In an embodiment of the present application, the second identifier can be called a dataidentifier.

[0078] If the first identifier and the second identifier do not completely overlap, a relationship mapping table needs to be stored in the program. In the relationship mapping table, a first identifier corresponds to one or more second identifiers of the request content data pool. This relationship mapping table also supports operations such as adding, deleting, modifying, and searching, and is uniformly managed by the bus management class Manager.

[0079] In the embodiment of the present application, it is necessary to organize the data in the request content data pool reasonably. For example, a class or structure can be created to organize the specific composition relationship through member attributes. Specifically, a request content data pool class, namely DataPool, can be created, whose instance is a singleton and has the same life cycle as the App life cycle. Figure 7 As shown, DataPool has a member variable of collection type, which can be called dataSet, which stores all network data used in all apps. The structure of each element in the collection is a general custom data model. It consists of two parts: general data and specific data.

[0080] Common data is usually placed in the outermost layer and the front, which can be called a container, including: whether the interface request is successful, the interface error code, and the interface error message. Specific data is usually placed in the inner layer, which is used for client page display and logic processing. Specific data consists of arrays, dictionaries, and basic data types, which are the actual data wrapped in the container.

[0081] Usually, the page generally uses the outer layer's general data to determine whether the interface request is successful, and uses the inner layer's specific data for logical processing and page display. The outer layer's general data holds a collection of specific data.

[0082] Specifically, the class of the container can be called DataResult, which is one of the general custom data models. It can define the following member attributes: whether the interface request is successful, the error code of the interface, the error message of the interface, the original data of the interface, and the unique identifier of this request. The unique identifier is divided into a business unique identifier and a data unique identifier. The business unique identifier is like a data identifier, and the data unique identifier emphasizes uniqueness and may be a long and meaningless string.

[0083] The specific data can be called a DataItem collection, because the relationship between DataResult and DataItem is the relationship between the container and the inner data, so DataResult must hold one or more DataItem object collections. In an embodiment of the present application, the current object can be serialized into a binary stream, and a DataItem object can be deserialized from the binary stream. When defining its members, all the data of the list container can be appended to the back end of the current container. When the server data is a paginated list, after requesting the first page of data, when the user slides down the interface, the second page of data is requested, the data of the second page is removed from the container, and the specific data is appended to the specific data of the first page.

[0084] Specifically, the class that stores specific data can be called DataItem, which is one of the general custom data models. In theory, the entire App uses this class and its subclasses as a carrier for business data. It can define the following member properties: internal dictionary. This property should be private and invisible to the outside world. The member methods of DataItem are basically operations to add, delete, modify, and find it. It defines the following member methods:

[0085] Get a value through a key. The value type is a basic data type or any class. The key type is recommended to be a string constant or an enumeration of string type.

[0086] Add a set of key-value pairs, the value type is a basic data type. For example, there are 7 basic data types in iOS: string, binary stream NSData, time NSDate, number NSNumber, list NSArray, dictionary NSDictionary;

[0087] Add a set of key-value pairs, the value type is any custom class. The value type includes but is not limited to basic data types, which can be commonly used classes such as color NSColor, shape NSRect, or custom data entity classes.

[0088] In addition, the defined DataItem member methods include: whether a key-value pair exists, getting all key-value pairs, clearing all key-value pairs, converting from a dictionary to itself, serializing from the current object to a binary stream, and deserializing a DataItem object from a binary stream.

[0089] In the embodiment of the present application, it is necessary to save the data carried by the interface data pool and the request content data pool. The location where the data is saved includes but is not limited to any of the following locations: the local sandbox of the application, the class or structure of the memory, and the server side. The way of saving includes but is not limited to any of the following forms: binary stream, file, and table of the local database. The sandbox is a local storage space specially opened up for each application in the mobile phone for its exclusive use. Other applications or users need permission to access this memory.

[0090] The interface data pool and the request content data pool have permanent storage, and they have set update mechanisms and timings.

[0091] Specifically, during the App development phase, all server interface data and network request data can be collated and written into a file. The file is placed in the App installation package, and a copy is saved on the server.

[0092] When the App is started for the first time or when the App is updated, the file contents in the App installation package are read into the memory and copied to the sandbox address. If the mobile phone database is used, it can also be copied to the database. In actual applications, the App will be updated and upgraded. When packaging, the latest file should be placed in the App package. When the user installs it, if the App version number in the local mobile phone is detected to have changed, the file can be updated and overwritten.

[0093] After requesting the server interface and getting the latest file on the server, you can update the file contents of the App installation package, local memory, sandbox, and database. Since the server-side files can be updated at any time, they should be considered the latest version and have a higher priority than the client-side files. When the server files are obtained, the client files should be overwritten in a timely manner.

[0094] When the API for updating the data pool is called, the relevant fields in the memory need to be updated in a timely manner and synchronously updated to the installation package, sandbox, and database.

[0095] Taking iOS implementation as an example, the mechanism and timing for updating the interface data pool and request content data pool are as follows:

[0096] Read the file contents in the App installation package into memory: access the main property of the class installation package, then access the path(forResource:, ofType:) method of main, pass the name of the file in the package as the method parameter, and get its full path in the App installation package; then call the Data(contentsOf:) initialization method of the class Data, pass the full path as the method parameter, and get the binary stream of the file; then call the jsonObject(with:) method of JSONSerialization to convert the binary stream of the file into a combination of basic data formats that the program can recognize; then convert this combination into a set of interface instances, and store it in the interfaceSet property of the interface pool InterfacePool to complete the operation of reading into memory.

[0097] Copy the interface collection data in the memory into the sandbox: first convert the data of the interface data pool into an instance of the binary stream NSData through the relevant data methods of the NSKeyedUnarchiver class and the NSKeyedArchiver class, and then write it to the corresponding path of the sandbox according to the writeToFile or writeToURL methods of NSData.

[0098] Copy the interface collection data in the memory to the database: import the library file of the sqlite3 database, call the C language function sqlite3_open() to create a database link, pass the path of the local database format file to the function, splice the data structure in the memory into the SQL (Structured Query Language) statement required by the database and write it to the database through methods such as sqlite3_prepare_v2() and sqlite3_finalize().

[0099] Copy the files of the App installation package into the sandbox: Use the copyItem(atPath:toPath:) method of the FileManager class to copy the files into the sandbox. The path of the sandbox can be obtained by NSSearchPathForDirectoriesInDomains(_:, _:, _:) or by the url(for:in:appropriateFor:create:) method of the URL.

[0100] Copy the files of the App installation package into the database: According to the above description, first read the file content, convert it into an interface set in the memory, and then assemble the data into SQL statements and write them into the database.

[0101] In an embodiment of the present application, in response to the first search result indicating that the corresponding server interface data does not exist in the interface data pool, the corresponding server interface data may be saved in the interface data pool.

[0102] In an embodiment of the present application, in response to the second search result indicating that there is no corresponding network request data in the request content data pool, the current network request can be sent to the server interface corresponding to the current network request, and the corresponding network request data returned by the corresponding server interface can be saved to the request content data pool.

[0103] Among them, when the corresponding network request data returned by the corresponding server interface is saved in the request content data pool, the corresponding network request data can be processed and then saved in the request content data pool, and the data processing includes at least one of the following operations: converting the data type of the corresponding network request data from a binary stream to a general custom data model, converting the data type of the corresponding network request data from a binary stream to a data type adapted to the application interface, and field selection processing.

[0104] In the embodiment of the present application, a function class can be defined for the data bus, which can be called the bus management class Manager, which is the management class of the data of the data bus. Its instance is a singleton, and the life cycle of the singleton is the same as that of the App.

[0105] The Manager is responsible for managing all network requests on the entire mobile terminal, converting the binary stream of acquired network data into a common custom data model, and performing other tasks such as data caching.

[0106] The Manager holds singletons of the interface data pool and the request content data pool, namely InterfacePool and DataPool, and can add, delete, modify, and search them. In order to prevent external users from modifying the data pool data, InterfacePool and DataPool are not visible to the outside world and are only held and modified by the Manager.

[0107] like Figure 8 Shown is an embodiment in which four APIs are called by the Manager in one network request.

[0108] In an embodiment of the present application, an API for accepting network requests can be defined for the Manager, and the API can be understood as a function. It accepts external incoming network requests, stores them and initiates network requests. It accepts four major types of parameters, including: all regular parameters required for an HTTP network request, a unique identifier (network identifier) ​​that identifies this network request, the associated network requests of this network request and their execution order, and a callback function. Among them, the callback function is not necessary, and the external network request completion message can be obtained in the form of notification or KVO.

[0109] After receiving the above four types of parameters, the Manager can update the storage in InterfacePool according to the network identifier, and query whether the network request already exists in the data pool InterfacePool. If not, it needs to be added. If it already exists, but the parameters are inconsistent, the parameters need to be updated. Finally, the Manager starts a thread to perform the actual request server interface action for the network request. After completing the data processing operation, the Manager sends a notification, sets its current status to network data processing completed, and calls the callback function passed in by the fourth parameter.

[0110] In the embodiment of the present application, several APIs for processing network request data pools can be defined for the Manager. As the interface data pool InterfacePool is cached data, there must be operations to add, delete, modify and search it, so the APIs that need to be defined include: update single, update all, delete single, delete all, query single and query all.

[0111] In an embodiment of the present application, an API for a data pool that receives network requests may be defined for the Manager. When a network request is responded to by the server and the corresponding data is received, the Manager updates and stores the data in the DataPool according to the data identifier dataidentifier.

[0112] Specifically, you can query whether the data already exists in the data pool DataPool. If not, add it. If it exists but the value is inconsistent, update it. At the same time, if it exists, update the associated data. Finally, the Manager sends a notification, which should carry important information such as the data identifier and data reference. The Manager sets the attribute describing its current status as: data processing completed. After receiving the notification, the page related to the data identifier refreshes the page automatically.

[0113] The specific steps for Manager to store network data are as follows Fig. 9 shown.

[0114] Specifically, when the interface data is first obtained from the interface, it is a binary stream. The Manager can call the API provided by the system to convert it into the basic data structure used in the program. The Manager can also further convert it into a specific type, that is, a general custom data model, according to business needs.

[0115] When performing type conversion, a DataResult object can be initialized and the common data, that is, the above basic data structure, can be filled into the corresponding fields.

[0116] If the specific data is a non-collection dictionary or array or other basic type, initialize a DataItem object, call the API according to the specific data type, and fill in the corresponding fields of the DataItem object. For example, if the specific order data is: a string ("order": "1231"), a value "price": 333), you can initialize a DataItem object, call the "add a set of key-value pairs, the value type is the basic data type" API, and fill in the corresponding fields of the DataItem object.

[0117] If you encounter a dictionary in any case, you can call the "convert from dictionary to itself" API, generate an instance of DataItem, and call its "add a set of key-value pairs, the value type is any custom class" API.

[0118] In the embodiment of the present application, the DataItem object can be assigned to the "specific data DataItem collection" property of the DataResult object.

[0119] In addition, according to business needs, some special processing can be performed on the general custom data model. Specifically, you can access the DataItem collection under DataResult, which may contain one or more DataItems. Traverse the DataItem collection, take out each DataItem data, and process each DataItem data according to business needs to obtain a specific data model collection. Among them, the specific data model can choose to inherit from the general custom data model, or directly use the general custom data model. The specific data model has more member attributes. The member attributes include member variables and member methods. For example, if the post data needs to display combined data: a preview content composed of three fields "poster name + post content + first comment" is placed in the list position. The above three fields come from different fields of DataItem, so you can call the "Add a set of key-value pairs, the value type is the basic data type" API on the DataItem instance, the key is a new value, such as "Preview content", and the value is the combined data.

[0120] In the embodiment of the present application, several APIs for processing the data pool returned by network requests can be defined for the Manager. The request content data pool DataPool is used as cache data, and there must be operations to add, delete, modify and search it, so the APIs that need to be defined include: update single, update all, delete single, delete all, query single and query all.

[0121] Because the data bus manages network requests and network data in a unified manner, it is also possible to develop tools and pages that are tightly coupled with the data bus architecture, that is, tightly coupled with the data center. The characteristics of such tools and pages are: they appear repeatedly in the App, so common code can be extracted to avoid duplication of code. When used externally, only the differences in specific business logic requirements need to be provided to quickly construct a page or effect.

[0122] Taking iOS development as an example, the list page in the App will display a list page with a pull-down refresh control at the top of the page and a swipe-up refresh control at the bottom. Its data refresh mechanism is: when entering the page + pull-down refresh + swipe-up refresh. This kind of list page is very common in Apps. The only difference is the specific data structure and interface elements.

[0123] In the embodiment of the present application, the implementation steps of developing a general list page tightly coupled with a data bus include: first creating a list display page, which can be called ivyTableview, then building regular page elements, adding a table view UITableView instance control, a pull-down refresh control, and a slide-up refresh control inside ivyTableview, and implementing two common agents of UITableView, UITableViewDelegate and UITableViewDataSource, and their methods. After building regular page elements, you can build network request logic, process page general refresh logic, and process different refresh logics for processing pages.

[0124] Specifically, when building network request logic, such as Fig.10 As shown, in the data refresh mechanism: just entering the page + pull-down refresh + swipe up refresh, the operation of requesting network data is performed at these three times. Specifically, the three times in the data refresh mechanism are: when the page is just entered, that is, in the iOS system function viewDidLoad or viewWillAppear, in the callback function of the pull-down refresh control, and in the callback function of the swipe up refresh control. In the specific operation of requesting network data, when setting the request parameters, if it is just entering the page + pull-down refresh control, the index of the start page of the requested data should be set to 0. If it is a swipe up refresh control, the index of the start page should be set to the previous index value + 1. The bus API requested to be called can pass in a callback function for being called after the data arrives. Among them, the way to receive the interface data is to select one of the following: accept the data arrival notification sent by the bus, the state attribute of the KVO bus, and the passed callback function.

[0125] When processing the general refresh logic of the page, each time a set of network data is obtained, the DataResult is set to the data corresponding to a section of the UITableView instance. The multiple DataItems in the DataResult correspond to each table (cell). A section is added to the end of the table view, and the system function reloadData() of the table view is called to refresh the page.

[0126] like Fig.10 In the example, one section corresponds to multiple tables (cells), and the DataResult and DataItem in the embodiment of the present application are also a one-to-many relationship.

[0127] When processing different refresh logics of the page, the possible differences of the page are made into template methods or properties and provided to the outside world. The outside world can inherit the ivyTableview class, implement these methods or properties, and achieve the effect of customizing its own page. The outside world can directly use the ivyTableview class, set these methods or properties, and achieve the effect of customizing its own page.

[0128] Common methods or properties that require external settings include: dragging methods for table views, adding, deleting, modifying, and searching for table view sections, specifying the number of table view sections, adding, deleting, modifying, and searching for tables, customizing table styles, filling table data, responding to user interactions with tables, and callback methods before and after initiating requests.

[0129] When the user drags the table view, ivyTableview calls the drag method of the table view. When the table is initialized, ivyTableview calls the methods for adding, deleting, modifying, and finding table view sections. When the table is initialized, ivyTableview calls the method for specifying the number of table view sections. When the table needs to be added, deleted, modified, and found, ivyTableview calls the methods for adding, deleting, modifying, and finding the table. When the table is initialized, ivyTableview calls the method for customizing the style of the table. After receiving the data requested from the network, ivyTableview calls the method for filling the data in the table. When the user interacts with the table view by clicking / long pressing, ivyTableview calls the user interaction response method of the table. Before / after initiating a request, ivyTableview calls the callback method before / after initiating the request, so that the outside can do some custom operations. Common methods that are visible to the outside and can only be called include sending network requests and receiving network requests.

[0130] When the list display page is used externally, if an external business logic requires a list display page, its layout is customized and the data is also customized. For example, each data item consists of order number, order price, customer name, and customer address.

[0131] In one embodiment of the present application, the ivyTableview class can be used directly externally to generate an instance and set a style customization method for the table. Initialize the four controls of order number, order price, customer name and customer address, and set the positions according to the layout of business requirements. Further, set the height method of the table and set the data filling method for the table. At this time, the data DataResult and DataItem have been obtained. According to the index parameter, get the corresponding DataItem in the DataResult, and set the order number, order price, customer name and customer address data to the control. According to business needs, you can also set the user interaction response method or other methods for the table. When entering the page / when the user pulls down to refresh / when the user swipes up to refresh, call the customized ivyTableview instance to send a network request.

[0132] In an embodiment of the present application, the grid display page can be implemented according to a similar implementation process of the list display page.

[0133] When applying the data bus, take iOS as an example at the implementation level to explain the interaction between the page and the Manager, including the entire process of sending network requests, receiving interface data, and refreshing the page.

[0134] At the beginning of App startup, initialize the bus processing class Manager, initialize its two data pools InterfacePool and DataPool, and read the configuration files of the two data pools into the data pools. When both Page A and Page B need to display the order list information, you can choose any of the following methods to connect with the bus.

[0135] The first method is to register with the local notification center NotificationCenter.default provided by iOS, and call the addObserver(_:, selector:, name:, object:) method of NotificationCenter.default to tell the system that you need to get a notification named "notification x". Depending on business needs, pages A and B can register for common notifications or have different notifications.

[0136] The second method is that both page A and page B perform KVO monitoring on the status field of the bus processing class Manager. Specifically, register KVO through the method [addObserver:forKeyPath:options:context:] and implement KVO monitoring through the method [observeValueForKeyPath:ofObject:change:context:].

[0137] In the embodiment of the present application, when the page actually calls the data in the data pool, the input parameter is the callback function.

[0138] When page A needs to be refreshed, page A requests the server interface of the order list from the data bus management class Manager. After the server data is returned, the Manager calls the API to store the data in the data pool, sends a local notification "notification x", sets the network request status, and calls the callback function.

[0139] Although both page A and page B need to display the order list information, the fields required by page A and page B are different, and the display logic is also different. For example, page A only needs numbers for the order status of the order items, but page B needs to display it as a string, such as "paid". Page A needs to display the address of the order, while page B does not need to display the address of the order but needs to display the amount of the order. In summary, page A and page B require different data entities. Therefore, using the definition of specific data, the original data entity DataItem is processed in this step, and the fields required by page A and page B are added to generate two new instances. Or a subclass of DataItem is generated, and the fields required by page A and page B are added to generate two new instances. Pages A and B receive the "notification x" notification or KVO notification, obtain the data entity DataItem they need, and refresh their respective interfaces.

[0140] Specifically, if it is a "notification x" notification, page A and page B can obtain the corresponding data from the userinfo attribute of the notification; or after receiving the notification, they can obtain the corresponding data from the data pool through the singleton Manager and then refresh the page. If it is a KVO notification, page A and page B detect the specific value of the status field of the Manager. When it is the completion of network data processing, they obtain the corresponding data from the data pool through the singleton Manager and then refresh the page.

[0141] By adopting the technical solution of the embodiment of the present application, unnecessary network requests can be reduced, the power consumption and traffic of the user's mobile phone can be saved, the data and network requests used by the App can be uniformly managed to improve program efficiency, and the data format can be unified to reduce the amount and difficulty of code development.

[0142] According to the page data request method of the embodiment of the present application, the server interface data and network request data of different pages are stored by using an interface data pool and a request content data pool, and the corresponding data is matched in the interface data pool and the request content data pool when a new network request is generated, thereby realizing the sharing of server interface data and network request data between different pages, saving the user bandwidth of the application, improving the program performance of the application and the matching degree of data types between different pages.

[0143] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. The page data request device described below and the page data request method described above can be referred to each other. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0144] Fig.11 Schematic diagram of a page data request device provided in an embodiment of the present application. Fig.11 As shown, the page data requesting device in the embodiment of the present application includes:

[0145] A first acquisition module 1101 is used to acquire a current network request sent by a current page, where the current network request includes first evaluation reference data and server interface data;

[0146] A second acquisition module 1102, configured to acquire second evaluation reference data from a data bus according to a preset evaluation strategy;

[0147] An evaluation module 1103 is used to evaluate whether a server data request is required for a current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtain an evaluation result;

[0148] The response module 1104 is used to obtain the network request data corresponding to the server interface data from the request content data pool of the data bus and send it to the current page when the evaluation result indicates that the current network request does not need to make a server data request.

[0149] In an embodiment of the present application, the page data request device may also include a saving module for saving the corresponding server interface data into the interface data pool in response to the first search result indicating that the corresponding server interface data does not exist in the interface data pool, and for sending the current network request to the server interface corresponding to the current network request in response to the second search result indicating that the corresponding network request data does not exist in the request content data pool, and saving the corresponding network request data returned by the corresponding server interface into the request content data pool.

[0150] The above-mentioned saving module is also used to save the corresponding network request data to the request content data pool after data processing. The data processing includes at least one of the following operations: converting the data type of the corresponding network request data from a binary stream to a general custom data model, converting the data type of the corresponding network request data from a binary stream to a data type adapted to the application program interface, and field selection processing.

[0151] In an embodiment of the present application, the acquisition module is also used to obtain the current network request sent by the current page through the data bus management class, wherein the current page is connected to the data bus management class by registering in the local notification center or performing key-value listening monitoring.

[0152] Since the various functional modules of the page data request device of the example embodiment of the present application correspond to the steps of the example embodiment of the page data request method described above, for details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the page data request method described above in the present application.

[0153] According to the page data request device of the embodiment of the present application, the server interface data and network request data of different pages are stored by using the interface data pool and the request content data pool, and the corresponding data is matched in the interface data pool and the request content data pool when a new network request is generated, thereby realizing the sharing of server interface data and network request data between different pages, saving the user bandwidth of the application, improving the program performance of the application and the matching degree of data types between different pages.

[0154] Fig.12 Schematic diagram of an electronic device 12 provided in an embodiment of the present application. Fig.12 As shown, the electronic device 12 of this embodiment includes: a processor 1201, a memory 1202, and a computer program 1203 stored in the memory 1202 and executable on the processor 1201. When the processor 1201 executes the computer program 1203, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 1201 executes the computer program 1203, the functions of the modules in the above-mentioned device embodiments are implemented.

[0155] The electronic device 12 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 12 may include, but is not limited to, a processor 1201 and a memory 1202. Those skilled in the art will appreciate that Fig.12 The electronic device 12 is merely an example and does not limit the electronic device 12 , and may include more or fewer components than those shown in the figure, or different components.

[0156] Processor 1201 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0157] The memory 1202 may be an internal storage unit of the electronic device 12, for example, a hard disk or memory of the electronic device 12. The memory 1202 may also be an external storage device of the electronic device 12, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card (FlashCard), etc. equipped on the electronic device 12. The memory 1202 may also include both an internal storage unit of the electronic device 12 and an external storage device. The memory 1202 is used to store computer programs and other programs and data required by the electronic device.

[0158] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0159] If the integrated module is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, and the computer program code may be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electric carrier signals and telecommunication signals.

[0160] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A page data request method, characterized in that: The method comprises: Acquire a current network request sent by the current page, wherein the current network request includes first evaluation reference data and server interface data; Obtain second evaluation reference data from a data bus according to a preset evaluation strategy; the data bus includes an interface data pool and a request content data pool, the interface data pool is a data pool for storing network requests of a server interface, and the request content data pool is a data pool for storing network request data returned by all network requests, wherein the server interface data includes network request parameters, a first identifier, and an associated request, and the network request data includes a network request result, a second identifier, and page processing display data, and the first identifier and the second identifier are the same or have a mapping relationship; the interface data pool and the request content data pool have a set update mechanism and timing; Evaluate whether the current network request needs to make a server data request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtain an evaluation result; When the evaluation result indicates that the current network request does not need to make a server data request, the network request data corresponding to the server interface data is obtained from the request content data pool of the data bus and sent to the current page.

2. The method according to claim 1, characterized in that When the evaluation result indicates that the current network request needs to make a server data request, the server data request corresponding to the current network request is sent to the network server via the data bus, and the network request data corresponding to the current network request returned by the network server is sent to the current page.

3. The method according to claim 1, characterized in that Evaluating whether a server data request is required for the current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy includes: The current network request is evaluated for whether a server data request is required according to two or any one of the following two evaluation rules: The evaluation is performed according to a size relationship between a time interval between a current time of the current network request and a timestamp and a set time interval threshold, wherein the timestamp is time data of server interface data corresponding to the current network request in an interface data pool of the data bus, the current time is the first evaluation reference data, and the timestamp and the time interval threshold are the second evaluation reference data; The evaluation is performed based on the current version number of the request content data of the current network request and the historical version number of the request content data corresponding to the current network request in the request content data pool of the data bus, wherein the current version number is the first evaluation reference data and the historical version number is the second evaluation reference data.

4. The method according to claim 3, characterized in that After performing the evaluation according to the relationship between the time interval between the current time of the current network request and the timestamp and the set time interval threshold, the method further includes: If the time interval is greater than or equal to the time interval threshold, sending a server data request corresponding to the current network request to the network server through the data bus, and saving the network request data corresponding to the current network request returned by the network server to the request content data pool and sending it to the current page; If the time interval is less than the time interval threshold, the network request data corresponding to the current network request is obtained from the request content data pool and sent to the current page.

5. The method according to claim 3, characterized in that: After performing the evaluation based on the current version number of the request content data of the current network request and the historical version number of the request content data corresponding to the current network request in the request content data pool of the data bus, the method further includes: If the current version number is greater than or equal to the historical version number, sending a server data request corresponding to the current network request to the network server through the data bus, and saving the network request data corresponding to the current network request returned by the network server to the request content data pool and sending it to the current page; If the current version number is smaller than the historical version number, the network request data corresponding to the current network request is obtained from the request content data pool and sent to the current page.

6. The method according to claim 5, characterized in that After the network request data corresponding to the current network request returned by the network server is saved in the request content data pool, the method further includes: The current version number corresponding to the newly saved network request data is processed according to the set version sorting rule to obtain a new version number, and the new version number is synchronously saved with the newly saved network request data.

7. The method according to claim 1, characterized in that Evaluating whether a server data request is required for the current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy includes: The evaluation is performed based on the relationship between the current request count of the current network request and a set count threshold, wherein the current request count is the first evaluation reference data, and the count threshold is the second evaluation reference data.

8. A page data request device, characterized in that: The device comprises: A first acquisition module, used to acquire a current network request sent by a current page, wherein the current network request includes first evaluation reference data and server interface data; The second acquisition module is used to obtain the second evaluation reference data from the data bus according to a preset evaluation strategy; the data bus includes an interface data pool and a request content data pool, the interface data pool is a data pool for storing network requests of the server interface, and the request content data pool is a data pool for storing network request data returned by all network requests, wherein the server interface data includes network request parameters, a first identifier and an associated request, and the network request data includes a network request result, a second identifier and page processing display data, and the first identifier and the second identifier are the same or have a mapping relationship; the interface data pool and the request content data pool have a set update mechanism and timing; An evaluation module, configured to evaluate whether a server data request is required for the current network request according to the first evaluation reference data, the second evaluation reference data and the evaluation strategy, and obtain an evaluation result; The response module is used to obtain the network request data corresponding to the server interface data from the request content data pool of the data bus and send it to the current page when the evaluation result indicates that the current network request does not need to make a server data request.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images