CN111479334A

CN111479334A - Network request retry method, device and terminal equipment

Info

Publication number: CN111479334A
Application number: CN202010199740.8A
Authority: CN
Inventors: 许蛟
Original assignee: Ping An International Smart City Technology Co Ltd
Current assignee: Shenzhen Saiante Technology Service Co Ltd
Priority date: 2020-03-20
Filing date: 2020-03-20
Publication date: 2020-07-31
Anticipated expiration: 2040-03-20
Also published as: CN111479334B

Abstract

The application provides a network request retry method, a network request retry device and terminal equipment, which are applicable to the technical field of data processing, and the method comprises the following steps: detecting a response state of a network request initiated by an application program; if the response fails, acquiring the field parameters corresponding to the network request with the failed response, and adding the network request with the failed response and the corresponding field parameters to a retry request queue; if the request response is successful, the network requests in the retry request queue are subjected to priority sequencing; taking out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter; and if the network request with the highest priority succeeds in response, returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameters from the retry request queue until the retry request queue is emptied. The method and the device for network retry can greatly improve the probability of network retry success.

Description

Network request retry method, device and terminal equipment

Technical Field

The application belongs to the technical field of data interaction, and particularly relates to a network request retry method and terminal equipment.

Background

The network request is a common front-end and back-end interaction mode of an application program, and when the network is abnormal, the network request often fails to respond. In order to improve the probability of network request success when the network is abnormal, a network retry mechanism needs to be established in advance, that is, a scheme for performing network request retry after network request response fails.

The current network request mechanism directly retries to initiate the network request when the network request response fails, and does not stop retrying until the network request response succeeds or the number of retries reaches a certain threshold, but statistics show that the success rate of the network request retrying is extremely low, and the normal use of the application program by the user is seriously influenced.

Disclosure of Invention

In view of this, embodiments of the present application provide a network request retry method and a terminal device, which can solve the problem of low network request retry success rate.

A first aspect of an embodiment of the present application provides a network request retry method, including:

detecting a response state of a network request initiated by an application program;

if the network request response failure is detected, acquiring a field parameter corresponding to the network request with the response failure, and adding the network request with the response failure and the corresponding field parameter to a retry request queue, wherein the field parameter comprises a request mode, a request address and a request parameter of the network request;

if the network request response is detected to be successful, performing priority ordering on the network requests in the retry request queue, wherein the retry request queue is a queue formed by network requests with failed response;

taking out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiating the network request with the highest priority based on the extracted field parameter;

and if the response of the network request with the highest priority is successful, returning to execute the operation of taking out the network request with the highest priority and the corresponding field parameters from the retry request queue until the retry request queue is emptied.

In a first possible implementation manner of the first aspect, the first aspect further includes:

and if the response of the network request with the highest priority fails, adding the network request with the highest priority and the corresponding field parameters to the retry request queue, and returning to execute the operation of detecting the response state of the network request in the application program.

In a second possible implementation manner of the first aspect, the first aspect further includes:

if an interface switching instruction or an interface quitting instruction of the current display interface of the application program is detected, searching all application program functions contained in the current display interface;

and screening all network requests corresponding to the application program function from the retry request queue based on the function identification, and removing the screened network requests from the retry request queue.

On the basis of the first possible implementation manner and the second possible implementation manner, in a third possible implementation manner of the first aspect, the prioritizing the network requests in the retry request queue includes:

acquiring first historical request data of the application program and field parameters of network requests which are successfully responded historically in the first historical request data, wherein the first historical request data comprises the network requests which are initiated historically by the application program and the initiation times of each network request;

based on the initiation times of the network requests in the first historical request data, performing priority sequencing on the network requests in the retry request queue to obtain a first priority sequence corresponding to the network requests in the retry request queue;

based on the field parameters of the network requests successfully responded by the history, the network requests in the retry request queue are subjected to priority sequencing to obtain a second priority sequence corresponding to the network requests in the retry request queue;

and fusing the priorities in the first priority sequence and the second priority sequence to obtain the priority of each network request in the retry request queue.

On the basis of the third possible implementation manner, in a fourth possible implementation manner of the first aspect, the obtaining, by the first historical request data, a second historical request data of the application program after the application program is started again, and a third historical request data of the application program before the application program is started again, and the prioritizing, based on the number of times of network request initiation in the first historical request data, the network requests in the retry request queue to obtain a first priority sequence includes:

screening out first initiation times of each network request in the retry request queue from the second historical request data, and screening out second initiation times of each network request in the retry request queue from the third historical request data;

performing weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain a weight score corresponding to each network request in the retry request queue, wherein a weight coefficient corresponding to the first initiation times is greater than a weight coefficient corresponding to the second initiation times;

and according to the sequence of the weight scores from high to low, carrying out priority sequencing on each network request in the retry request queue to obtain a first priority sequence.

On the basis of the third possible implementation manner, in a fifth possible implementation manner of the first aspect, the prioritizing the network requests in the retry request queue based on the field parameters of the network requests successfully responded by the history to obtain a second priority sequence includes:

performing field parameter matching on the network requests in the retry request queue and the network requests successfully responded in the history, screening out the network requests successfully responded in the history, wherein the network requests have the highest matching degree with the field parameters of each network request in the retry request queue, and taking the screened network requests as target requests;

and screening the response success times and the third initiation times of each target request from the first historical request data, and performing priority sequencing on each network request in the retry request queue according to the sequence that the proportion of the response success times to the third initiation times is from high to low to obtain a second priority sequence.

A second aspect of an embodiment of the present application provides a network request retry apparatus, including:

the response detection module is used for detecting the response state of the network request initiated by the application program;

the request caching module is used for acquiring field parameters corresponding to the network request with failed response if the network request response failure is detected, and adding the network request with failed response and the corresponding field parameters to a retry request queue, wherein the field parameters comprise a request mode, a request address and request parameters of the network request;

the request ordering module is used for carrying out priority ordering on the network requests in the retry request queue if the network request response is detected to be successful, wherein the retry request queue is a queue formed by network requests with failed response;

a request retrying module, configured to take out the network request with the highest priority and the corresponding field parameter from the retrying request queue, and initiate the network request with the highest priority based on the extracted field parameter;

and the return execution module is used for returning and executing the operation of taking out the network request with the highest priority and the corresponding field parameters from the retry request queue until the retry request queue is emptied if the network request with the highest priority is successfully responded.

A third aspect of the embodiments of the present application provides a terminal device, where the terminal device includes a memory and a processor, where the memory stores a computer program that is executable on the processor, and the processor implements the steps of the network request retry method according to any one of the first aspect when executing the computer program.

A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, including: there is stored a computer program, characterized in that the computer program, when being executed by a processor, carries out the steps of the network request retry method according to any of the above-mentioned first aspects.

A fifth aspect of embodiments of the present application provides a computer program product, which, when run on a terminal device, causes the terminal device to execute the network request retry method according to any one of the first aspect.

Compared with the prior art, the embodiment of the application has the advantages that: when the network request response failure is detected, the network request response failure is not directly retried, but the network request with the response failure is buffered to a retry request queue, and the network requests with the response failure in the retry request queue are sorted and retried only when the network request response is successful, since a successful response means that the current network is available, retrying at this point can greatly increase the chance of successful retrying, meanwhile, the network requests are subjected to priority sorting retry, the probability of successful retry of each time can be improved as much as possible, and finally, the retry request queue is continuously processed only when the extracted network request with the highest real-time priority response is successful, therefore, the embodiment of the application can continuously retry the network request aiming at the normal condition of the network, avoid invalid repeated attempts and ensure the success rate of each retry.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

Fig. 1 is a schematic flow chart illustrating an implementation of a network request retry method according to an embodiment of the present application;

fig. 2 is a schematic flow chart illustrating an implementation of a network request retry method according to a second embodiment of the present application;

fig. 3 is a schematic flow chart illustrating an implementation of a network request retry method according to a third embodiment of the present application;

fig. 4 is a schematic flow chart illustrating an implementation of a network request retry method according to a fourth embodiment of the present application;

fig. 5 is a schematic flow chart illustrating an implementation of a network request retry method according to a fifth embodiment of the present application;

fig. 6 is a schematic structural diagram of a network request retry apparatus according to a sixth embodiment of the present application;

fig. 7 is a schematic diagram of a terminal device provided in the seventh embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

In order to explain the technical solution described in the present application, the following description will be given by way of specific examples.

In order to facilitate understanding of the present application, a brief description of the embodiments of the present application will be provided herein. Because the network connection is usually abnormal when the network request fails, if the retry success rate is very low when the network request fails to be directly reinitiated, and meanwhile, because the network abnormal request is not managed and controlled, the retry is only a single retry, precious network resources are wasted, and the purpose to be achieved by real network request retry is not obtained.

In order to improve the success rate of network request retry, when a network request response failure is detected, the network request with the response failure is not directly retried, but the network request with the response failure is cached in a retry request queue, and each network request with the response failure in the retry request queue is sequenced and retried only when the network request response success, because the response success means that the current network is available, the retry success rate can be greatly improved by retrying at the moment, meanwhile, the priority sequencing retry is carried out on the network requests, the probability of each retry success can be improved as much as possible, and finally, the retry request queue is continuously processed only when the extracted network request with the highest real-time priority response succeeds, thereby ensuring that the network request retry is continuously carried out under the normal condition of the network, invalid repeated attempts are avoided, and the success rate of each retry is guaranteed.

Meanwhile, in the embodiment of the present application, the main body for executing the network request retry may be any terminal device that can run an application program and send the network request, where a specific device type is not limited herein, and may be selected or set by a technician according to a requirement of an actual scene, including but not limited to, for example, a mobile terminal, a computer, a server, and the like.

The detailed description of the embodiments of the present application is as follows:

fig. 1 shows a flowchart of an implementation of a network request retry method according to an embodiment of the present application, which is detailed as follows:

s101, detecting the response state of the network request initiated by the application program.

In the embodiment of the application, the response state of each network request initiated by the application program is monitored in real time, that is, each network request is successfully or unsuccessfully responded, and the subsequent processing policy is selected according to different response states.

S102, if the network request response failure is detected, acquiring the field parameters corresponding to the network request with the response failure, and adding the network request with the response failure and the corresponding field parameters to a retry request queue, wherein the field parameters comprise a request mode, a request address and request parameters of the network request.

In this embodiment, a retry request queue is preset for buffering network requests that have failed to respond to by an application. Therefore, when the network request fails to respond, the embodiment of the application does not retry directly, but adds the network request which fails to respond and the corresponding field parameters into a retry request queue for subsequent retry calling. The field parameters are mainly used for really restoring the network request when the network request retries.

S103, if the network request response is detected to be successful, the network requests in the retry request queue are subjected to priority sequencing, wherein the retry request queue is a queue formed by network requests with failed response.

When a network request response success is detected, it indicates that the network connection is normal at this time, that is, the success rate of network request retry at this time is very high, so in the embodiment of the present application, when a network request response success is detected, a retry mechanism for a network request with a response failure is triggered. Meanwhile, because the importance degrees of different network requests to users are not necessarily the same, and because the differences of request objects, request contents and the like of the network requests also cause the success rates of the network requests to have some differences, in order to meet the actual conditions of different network requests and the requirements of actual users as much as possible, the embodiment of the application also sequences the network requests in the retry request queue first and then performs subsequent retry operations. The retry request queues in S102 and S103 are the same queue, and a sorting method of the network requests in the queues is not limited herein, and may be set by a technician according to actual requirements, including but not limited to, for example, simply sorting according to the adding time, or sorting according to the importance degree of the application program function corresponding to the network request, and refer to embodiments three to five of the present application.

S104, the network request with the highest priority and the corresponding field parameters are taken out from the retry request queue, and the network request with the highest priority is initiated based on the extracted field parameters.

After S103 finishes sequencing the network requests, in the embodiment of the present application, the network request with the highest priority and the field parameter corresponding to the network request are removed from the network request, a specific request address, a request mode, and the like are determined based on the field parameter, and the network request with the highest priority is re-issued, so that retry of the network request with the highest priority is realized.

And S105, if the response of the network request with the highest priority is successful, returning to execute the operation of taking the network request with the highest priority and the corresponding field parameters out of the retry request queue until the retry request queue is emptied.

After retrying the network request with the highest priority, the embodiment of the application also detects whether the retrying is successful or not.

When the response of the network request with the highest priority is successful, it indicates that the network connection is still normal at this time, that is, the success rate of retrying the network request again is still high, so the embodiment of the present application returns to the operation of step S104, continues to fetch the network request with the highest priority from the remaining network requests in the retrying request queue, and continues to perform retrying operation on the fetched network request. If the network request can be successfully retried each time, the network requests in the retry request queue can be retried one by circularly taking out the real-time network request with the highest priority and carrying out retry, all the network requests which fail to respond can be effectively retried, and meanwhile, the next network request is taken out when the taken-out network request is successfully responded, so that the network environment of network request retry each time is normal, and the success rate of retry each time is large.

When the embodiment of the application detects that the network request response fails, the network request which fails to respond is not directly retried, but the network request which fails to respond is cached in a retry request queue, and only when the network request response succeeds, the network requests which fail to respond in the retry request queue are sequenced and retried, because the response success means that the current network is available, the retry is carried out at the moment, so that the retry success probability can be greatly improved, meanwhile, the network request is subjected to priority sequencing retry, the retry success probability of each retry can be improved as much as possible, and finally, the retry request queue is continuously processed only when the extracted network request response with the highest real-time priority succeeds, thereby ensuring that the embodiment of the application continuously retries the network request aiming at the normal condition of the network, and avoiding invalid repeated attempts, the success rate of each retry is guaranteed.

As an embodiment of the present application, in addition to retrying a network request with the highest priority in the embodiment of the present application, in consideration that it is not always possible to succeed every retrying in practical applications, in order to cope with a case where a retry fails, and guarantee a success rate of every retrying, in the embodiment of the present application, after retrying the network request with the highest priority, the method further includes:

and if the response of the network request with the highest priority fails, adding the network request with the highest priority and the corresponding field parameters to a retry request queue, and returning to execute the operation of detecting the response state of the network request in the application program.

In the embodiment of the present application, when the response of the network request with the highest priority fails, it is described that the current network situation is abnormal, and the success rate of network request retry is very low, so that in the embodiment of the present application, retry of the network request in the retry request queue is stopped at this time, so as to avoid excessive useless retry and reduce the success rate of retry, and at the same time, the network request with the highest priority and corresponding field parameters that failed retry are added to the retry request queue again, and the monitoring step of the response state of the application network request is returned S101.

As an optional embodiment of the present application, in consideration of the practical situation, a large functional interface may include many functions, for example, a banking application financial interface may include a plurality of different financial management functional modules, a user may perform operations such as buying and selling a plurality of different financial management products therein, a news interface may include a plurality of different types of news selecting and browsing functions, for example, in a large functional interface, if a network request response triggered by the user fails, a next request may be made again to assist the user in normal operation, but if the user has left a certain functional interface, if an error request of the functional interface is retried, normal use of the user may be affected.

Therefore, in order to ensure that the user normally uses the application program, in an embodiment of the present application, the field parameter further includes a function identifier, where the function identifier is used to identify an application program function corresponding to the network request, and at the same time, the operation condition of the user on the function interface is monitored, and the network request with a failed response is cleared in time, so as to ensure normal use of the user, as shown in fig. 2, in a second embodiment of the present application, while performing operations S101 to S105, the first embodiment of the present application further includes:

s201, if an interface switching instruction or an interface quitting instruction of the current display interface of the application program is detected, all application program functions contained in the current display interface are searched.

The current display interface refers to a functional interface of current browsing operation of a user, a financing interface, a news interface and the like in a bank application program. When the user performs interface switching or quitting operation, it indicates that the user does not need to use the current display interface, and therefore, in the embodiment of the application, all functions contained in the current display interface are found out so as to perform subsequent network request removal.

S202, based on the function identification, all network requests corresponding to the application program function are screened out from the retry request queue, and the screened network requests are removed from the retry request queue.

After obtaining all application program functions contained in the current display interface, the embodiment of the application judges whether the application program function corresponding to the network request belongs to the application program function or not based on the function identifier in each network request field parameter, and if the application program function belongs to the application program function, the application program function is removed from the retry request queue, so that all network requests corresponding to the current display interface in the retry request queue can be cleared in time, and the normal use of the application program by a user is guaranteed.

As a specific implementation manner of ordering network requests in the retry request queue in the first embodiment of the present application, considering that in practical applications, functions corresponding to network requests in the retry request queue are different, the interface conditions corresponding to the request are different, and when the request is retried, if the retry is performed directly according to the added time sequence, the success rate of the retry cannot be maximized (for example, the server interfaces corresponding to different requests are different, and when the request is successful, the success rate of the request of the same or similar interface is undoubtedly greater), and the actual requirement of the user cannot be met (although the user triggers network requests with different functions, the actual requirement degree for each function is different, and it is very likely that some functions are tried randomly after the network is found to be abnormal), so the effectiveness of the retry is extremely low.

In order to improve the success rate and effectiveness of retry, in the embodiments of the present application, network request priority ranking is performed based on two dimensions, that is, the demand of a user for each network request and the success rate of retry of each network request, as shown in fig. 3, based on the above embodiments of the present application, the operation of ranking network requests in the third embodiment of the present application specifically includes:

s301, acquiring first historical request data of the application program and field parameters of network requests which are successfully responded historically in the first historical request data, wherein the first historical request data comprises network requests which are initiated historically by the application program and the initiation times of each network request.

The first historical request data is network requests initiated by the application program history, and the initiation times of each network request, and the first historical request data is response data of historical demands of the user, so that how much the user demands each network request can be reflected to a certain extent by analyzing the first historical request data. It should be noted that, because the user's requirement has a certain real-time property in an actual situation, the reference value of some historical request data with too long time intervals may be relatively low, and therefore, in order to improve the effectiveness of the analysis, in the embodiment of the present application, the sampling time range of the first historical request data is not limited, and may be set by a technician according to the actual requirement, for example, the sampling time range may be all the historical data since the application program is installed, or the historical data within a certain time period, such as the historical request data within the last year.

On one hand, because there may be a certain difference between addresses, modes, etc. of requests corresponding to different network requests, when a certain network request is successfully responded, the probability of successful response is undoubtedly greater than that of a network request with similar field parameters, and on the other hand, because of the difference between objects of network requests, the success rate between network requests itself may also have a certain difference, for example, for some servers with network states congested for a long time, if the objects of application program network requests are these servers, the probability of network request failure caused by identification is greatly increased. Therefore, in the embodiment of the application, all network requests and field parameters which are successfully responded in the first historical request data are obtained for subsequent analysis, wherein the same network request may have a situation that multiple historical responses are successfully responded, so that in order to avoid interference caused by multiple analyses, the field parameters of one time are only reserved, and as an optional implementation mode, only sequential field parameters which are closest to the current time can be reserved.

S302, based on the number of times of initiating the network requests in the first historical request data, the network requests in the retry request queue are subjected to priority sequencing to obtain a first priority sequence corresponding to the network requests in the retry request queue.

On the basis of acquiring the first historical request data, the network requests in the retry request queue are subjected to priority ranking based on the initiation times of the network requests, and the priorities of the network requests in the retry request queue are obtained, so that the requirement degree of the network requests of the user is effectively analyzed, wherein a specifically used ranking method is not limited in the embodiment of the application, and technical personnel can select or relate to the ranking according to actual requirements, including but not limited to directly ranking according to the sequence of the initiation times of the network requests in the first historical request data from high to low, or referring to the fourth embodiment of the application.

And S303, based on the field parameters of the network requests successfully responded by the history, carrying out priority sequencing on the network requests in the retry request queue to obtain a second priority sequence corresponding to the network requests in the retry request queue.

After obtaining the field parameters of the network requests with successful historical responses, the embodiment of the present application may rank the network requests in the retry request queue according to the actual response conditions of the network requests with successful historical responses and the similarity conditions between the retry request queue and the network requests with successful historical responses, to obtain the corresponding second priority sequence, where the specific ranking method is not limited here, and includes, but is not limited to, first ranking according to the response success times corresponding to the network requests with successful historical responses, then matching the network requests with successful historical responses corresponding to the network requests in the retry request queue through the field parameters, and performing priority ranking according to the response success times corresponding to the network requests in the retry request queue, or may refer to the fifth embodiment of the present application.

S304, the priorities in the first priority sequence and the second priority sequence are fused to obtain the priority of each network request in the retry request queue.

After the two priority sequences are obtained, the embodiment of the application also fuses the specific priorities of the network requests in the two priority sequences, so as to obtain the final priority condition. The specific fusion method is not limited herein, and may be set by a technician, for example, the method may be direct averaging and sorting, for example, if it is assumed that for the network request a, the priorities in the first priority sequence and the second priority sequence are 1 and 5, respectively, at this time, the averaging is 3, and then sorting is performed again according to the average of all the network requests.

As an optional embodiment of the present application, in consideration of the fact that there may be a certain difference between demands for a user and a response success rate under different scene demands, for example, in some possible scenes, the demands for the user need to be guaranteed preferentially, and in other possible scenes, the response success rate needs to be guaranteed preferentially, so that when fusing two priority sequences, a weight coefficient may be set for each sequence, and weight calculation is performed on the priority based on the weight coefficient, where a value of a specific weight coefficient may be set by a technician according to the actual scene demands, thereby achieving effective response to different scene demands, and achieving different side weight considerations on the demands for the user or the response success rate.

As a specific implementation manner of calculating the first priority sequence in the third embodiment of the present application, considering that the user's requirement has extremely strong real-time performance in an actual situation, and it cannot be predicted whether the time interval of each use of the application program by the user is too long, that is, it cannot be predicted whether the time interval of the last use of the application program is too long, and for the history request data with too long time interval, the reference value for the analysis of the user requirement is relatively low, so in order to improve the accuracy of the analysis of the user requirement degree as much as possible, in the third embodiment of the present application, the first history request data is further disassembled, and is divided into the second history request data of the application program after the application program is started, and the third history request data of the application program before the application program is started, and the second history request data and the third history request data are distinguished and analyzed, as shown in fig. 4, a fourth process for calculating a first priority sequence in the embodiment of the present application specifically includes:

s401, screening out the first initiation times of each network request in the retry request queue from the second historical request data, and screening out the second initiation times of each network request in the retry request queue from the third historical request data.

According to the embodiment of the application, firstly, the network requests in the retry request queue are respectively counted according to the second history request data and the third history request data, so that the corresponding first initiation times and second initiation times are obtained.

S402, carrying out weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain the weight score corresponding to each network request in the retry request queue, wherein the weight coefficient corresponding to the first initiation times is greater than the weight coefficient corresponding to the second initiation times.

Considering that the interval duration of the last application program usage cannot be predicted, but the second historical request data generated by the application program usage at this time is definitely the latest data and can represent the requirement condition of the current user most, in the embodiment of the present application, the weight calculation is performed on the first initiation times and the second initiation times, and the weight coefficient corresponding to the first initiation times is set to be greater than the weight coefficient corresponding to the second initiation times, so that the influence degree of the latest data on the user requirement calculation is increased. The specific values of the weighting coefficients corresponding to the first initiation times and the second initiation times are not limited herein, and can be set by a technician according to the needs.

And S403, performing priority ordering on each network request in the retry request queue according to the sequence of the weight scores from high to low to obtain a first priority sequence.

After the weight score of each network request is obtained, the network requests are prioritized from high to low from the weight score, so that the network requests can be prioritized based on the user demand degree, and a required first priority sequence is obtained.

As a specific implementation manner of calculating the second priority sequence in the third embodiment of the present application, in consideration of the practical situation, the network requests in the retry request queue do not always respond successfully once, that is, the network requests that have successfully responded historically do not always have the network requests in the retry request queue, so that if the network request matching search is directly performed, the search effect may be very poor, and further, the effectiveness of the sorting may be reduced.

In order to ensure the validity of the ranking result and ensure the accuracy and reliability of the retry success rate analysis, as shown in fig. 5, in the fifth embodiment of the present application, the network request is not directly searched, but similar requests are matched, and the network request that is successfully responded based on the most similar history is analyzed and ranked, the step of calculating the second priority sequence in the fifth embodiment of the present application includes:

s501, performing field parameter matching on the network requests in the retry request queue and the network requests successfully responded in the history, screening out the network requests which are successfully responded in the history and have the highest matching degree with the field parameters of each network request in the retry request queue, and taking the screened network requests as target requests.

Specifically, the network requests in the retry request queue are matched with the field parameters of the network requests successfully responded by each history, and the network request successfully responded by the history with the highest similarity is found out, so that the target requests corresponding to the network requests in the retry request queue one by one are obtained. Wherein, for a single network request in the retry request queue, if it once responded successfully, the lookup process is itself. The embodiment of the application does not limit the specific matching method, and technicians can select or set the method according to actual requirements, for example, the method can be set to match each data in field parameters one by one, so as to ensure the matching reliability.

As an optional embodiment of the present application, in order to improve the reliability of matching, in the embodiment of the present application, the field parameter further includes a function identifier, where the function identifier is used to identify an application function corresponding to the network request, so that when matching the field parameter, the function corresponding to the network request is further matched, so that a matching result is more accurate and reliable.

As an optional embodiment of the present application, when matching the field parameters, different matching rules may be set for each item of data in the field parameters, to meet the requirements of different data characteristics and to improve the reliability of data matching, for example for the request mode, the request modes can be combined pairwise in advance, and corresponding similarity is set according to the similar conditions of the request modes in each pair of combinations, for example, the similarity of the same request modes is the maximum value and is reduced in sequence, for the request address, the server type or the company to which the server belongs corresponding to the address can be used, the similarity of the same server is set to be the highest, the similarity of the servers of the same type or the same company is set to be the lowest, after similarity calculation is carried out on each data, weight summation is carried out, and corresponding matching degree can be obtained.

S502, screening out the response success times and the third initiation times of each target request from the first historical request data, and carrying out priority sequencing on each network request in the retry request queue according to the sequence that the proportion of the response success times to the third initiation times is from high to low to obtain a second priority sequence.

After the target requests corresponding to the network requests in the retry request queue are matched, the embodiment of the application searches corresponding response success times and third sending times from the first historical request data, calculates the proportion of the response success times to the third sending times so as to obtain corresponding response success rates, and finally sorts the network requests in the retry request queue according to the sequence from high to low of the response success rates so as to obtain an accurate and reliable second priority sequence.

Fig. 6 shows a block diagram of a network request retry apparatus provided in an embodiment of the present application, which corresponds to the method in the foregoing embodiment, and only shows a part related to the embodiment of the present application for convenience of description. The network request retry apparatus illustrated in fig. 6 may be an execution subject of the network request retry method provided in the first embodiment.

Referring to fig. 6, the network request retry apparatus includes:

and the response detection module 61 is used for detecting the response state of the network request initiated by the application program.

The request caching module 62 is configured to, if it is detected that a network request response fails, obtain a field parameter corresponding to the network request that fails to respond, and add the network request that fails to respond and the corresponding field parameter to a retry request queue, where the field parameter includes a request mode, a request address, and a request parameter of the network request.

And a request sorting module 63, configured to, if it is detected that the network request response is successful, perform priority sorting on the network requests in the retry request queue, where the retry request queue is a queue formed by network requests that fail to respond.

A request retry module 64, configured to take out the network request with the highest priority and the corresponding field parameter from the retry request queue, and initiate the network request with the highest priority based on the extracted field parameter.

A return execution module 65, configured to, if the response of the network request with the highest priority is successful, return to execute the operation of taking out the network request with the highest priority and the corresponding field parameter from the retry request queue until the retry request queue is emptied.

Further, the network request retry apparatus further includes:

and the cache adding module is used for adding the network request with the highest priority and the corresponding field parameters to the retry request queue if the response of the network request with the highest priority fails, and returning and executing the operation of detecting the response state of the network request in the application program.

Further, the network request retry apparatus further includes:

and the instruction detection module is used for searching all application program functions contained in the current display interface if an interface switching instruction or an interface exit instruction of the current display interface of the application program is detected.

And the request removing module is used for screening all network requests corresponding to the application program functions from the retry request queue based on the function identification, and removing the screened network requests from the retry request queue.

Further, the request ordering module 63 includes:

the data acquisition module is used for acquiring first historical request data of the application program and field parameters of network requests which are successfully responded historically in the first historical request data, wherein the first historical request data comprises the network requests which are initiated historically by the application program and the initiation times of each network request.

And the first sequencing module is used for carrying out priority sequencing on the network requests in the retry request queue based on the initiation times of the network requests in the first historical request data to obtain a first priority sequence corresponding to the network requests in the retry request queue.

And the second sequencing module is used for carrying out priority sequencing on the network requests in the retry request queue based on the field parameters of the network requests successfully responded by the history to obtain a second priority sequence corresponding to the network requests in the retry request queue.

And the sequencing fusion module is used for fusing the priorities in the first priority sequence and the second priority sequence to obtain the priority of each network request in the retry request queue.

Further, the first historical request data includes a second historical request data of the application program after the application program is started again and a third historical request data of the application program before the application program is started again, and the first sequencing module includes:

and screening out the first initiation times of each network request in the retry request queue from the second historical request data, and screening out the second initiation times of each network request in the retry request queue from the third historical request data.

And performing weight calculation on the first initiation times and the second initiation times of each network request in the retry request queue to obtain a weight score corresponding to each network request in the retry request queue, wherein a weight coefficient corresponding to the first initiation times is greater than a weight coefficient corresponding to the second initiation times.

Further, the second sorting module includes:

and performing field parameter matching on the network requests in the retry request queue and the network requests successfully responded in the history, screening the network requests successfully responded in the history, and taking the screened network requests as target requests, wherein the network requests have the highest field parameter matching degree with the network requests in the retry request queue.

The process of implementing each function by each module in the network request retry apparatus provided in this embodiment may specifically refer to the description of the first embodiment shown in fig. 1, and is not described herein again.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance. It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements in some embodiments of the application, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first table may be named a second table, and similarly, a second table may be named a first table, without departing from the scope of various described embodiments. The first table and the second table are both tables, but they are not the same table.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

The network request retry method provided in the embodiment of the present application may be applied to a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an Augmented Reality (AR)/Virtual Reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a Personal Digital Assistant (PDA), and other terminal devices, and the embodiment of the present application does not set any limit to a specific type of the terminal device.

By way of example and not limitation, when the terminal device is a wearable device, the wearable device may also be a generic term for intelligently designing daily wearing by applying wearable technology, developing wearable devices, such as glasses, gloves, watches, clothing, shoes, and the like. A wearable device is a portable device that is worn directly on the body or integrated into the clothing or accessories of the user. The wearable device is not only a hardware device, but also realizes powerful functions through software support, data interaction and cloud interaction. The generalized wearable intelligent device has the advantages that the generalized wearable intelligent device is complete in function and large in size, can realize complete or partial functions without depending on a smart phone, such as a smart watch or smart glasses, and only is concentrated on a certain application function, and needs to be matched with other devices such as the smart phone for use, such as various smart bracelets for monitoring physical signs, smart jewelry and the like.

Fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 7, the terminal device 7 of this embodiment includes: at least one processor 70 (only one shown in fig. 7), a memory 71, said memory 71 having stored therein a computer program 72 executable on said processor 70. The processor 70, when executing the computer program 72, implements the steps in the various network request retry method embodiments described above, such as the steps 101-105 shown in fig. 1. Alternatively, the processor 70, when executing the computer program 72, implements the functions of the modules/units in the above-mentioned device embodiments, such as the functions of the modules 61 to 65 shown in fig. 6.

The terminal device 7 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The terminal device may include, but is not limited to, a processor 70, a memory 71. It will be appreciated by those skilled in the art that fig. 7 is merely an example of a terminal device 7 and does not constitute a limitation of the terminal device 7 and may comprise more or less components than shown, or some components may be combined, or different components, e.g. the terminal device may further comprise an input transmitting device, a network access device, a bus, etc.

The Processor 70 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 71 may in some embodiments be an internal storage unit of the terminal device 7, such as a hard disk or a memory of the terminal device 7, the memory 71 may also be an external storage device of the terminal device 7, such as a plug-in hard disk provided on the terminal device 7, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), etc. further, the memory 71 may also include both an internal storage unit and an external storage device of the terminal device 7, the memory 71 is used for storing an operating system, applications, a Boot loader (Boot L loader), data and other programs, such as program code of the computer program, etc. the memory 71 may also be used for temporarily storing data that has been sent or is to be sent.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the computer program implements the steps in the above-mentioned method embodiments.

The embodiments of the present application provide a computer program product, which when running on a mobile terminal, enables the mobile terminal to implement the steps in the above method embodiments when executed.

The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application, and are intended to be included within the scope of the present application.

Claims

1. A network request retry method, comprising:

2. The network request retry method of claim 1, further comprising:

3. The network request retry method as claimed in claim 1, wherein the field parameters further include a function identifier, the function identifier is used to identify an application function corresponding to the network request, and the network request retry method further includes:

4. The network request retry method of any of claims 1 to 3, wherein the prioritizing the network requests in the retry request queue comprises:

5. The method as claimed in claim 4, wherein the first historical request data includes a second historical request data of the application program after the application program is started and a third historical request data of the application program before the application program is started, and the network requests in the retry request queue are prioritized based on the number of network request initiations in the first historical request data to obtain a first priority sequence, including:

6. The method of claim 4, wherein prioritizing the network requests in the retry request queue based on the context parameters of the network requests for which the historical responses were successful to obtain a second priority sequence comprises:

7. A network request retry apparatus, comprising:

8. The network request retry apparatus of claim 7, wherein the request ordering module comprises:

the data acquisition module is used for acquiring first historical request data of the application program and field parameters of network requests which are successfully responded historically in the first historical request data, wherein the first historical request data comprises the network requests which are initiated historically by the application program and the initiation times of each network request;

the first sequencing module is used for carrying out priority sequencing on the network requests in the retry request queue based on the initiation times of the network requests in the first historical request data to obtain a first priority sequence corresponding to the network requests in the retry request queue;

the second sequencing module is used for carrying out priority sequencing on the network requests in the retry request queue based on the field parameters of the network requests successfully responded by the history to obtain a second priority sequence corresponding to the network requests in the retry request queue;

9. A terminal device, characterized in that the terminal device comprises a memory, a processor, a computer program being stored on the memory and being executable on the processor, the processor implementing the steps of the method according to any of claims 1 to 6 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 6.