CN109697113B

CN109697113B - Method, device and equipment for requesting retry and readable storage medium

Info

Publication number: CN109697113B
Application number: CN201811640170.0A
Authority: CN
Inventors: 杨子国; 周健兴
Original assignee: Guangzhou Cubesili Information Technology Co Ltd
Current assignee: Guangzhou Cubesili Information Technology Co Ltd
Priority date: 2018-12-29
Filing date: 2018-12-29
Publication date: 2021-06-01
Anticipated expiration: 2038-12-29
Also published as: CN109697113A

Abstract

The application discloses a method, a device, equipment and a readable storage medium for requesting retry, and belongs to the field of application development. The method comprises the following steps: sending a cross-process request; if the response corresponding to the request is not received, acquiring the time offset of the current request retry; performing request retry according to the time offset of the current request retry; the time offset of the current request retry is the time interval of two requests, and the time interval is dynamically determined according to the service scene. After the cross-process request is sent, if the response corresponding to the request is not received, the time offset of the current request retry is obtained, the request retry is carried out, and the time offset is dynamically determined according to the service scene, so that the request retry in batch in fixed time is avoided, and the flexibility and the success rate of the request retry are improved; and avoids the load increase of the called end caused by service failure.

Description

Method, device and equipment for requesting retry and readable storage medium

Technical Field

The present application relates to the field of application development, and in particular, to a method, an apparatus, a device, and a readable storage medium for requesting retry.

Background

In the distributed service development process, when a first service a of a client calls a second service B across processes, a request failure occurs, so how to design a request retry method becomes a very concerned problem in the application development field.

In the related technology, when a first service a of a client invokes a second service B across processes, the client carries a unique sequence number when sending a request, and retries the request at the same time interval and fixed retry times within a fixed time according to the unique sequence number when retriing the request after the request fails until the first service a of the client successfully receives a response or reaches the upper limit of the retry times.

The related art has at least the following problems:

the method for retrying the request retries the request at the same time interval and the fixed retry times within the fixed time, has poor flexibility of retrying the request, has low success rate, and may cause the load of the called end to be increased, thereby causing the vicious circle of the service quality.

Content of application

Embodiments of the present application provide a method, an apparatus, a device, and a readable storage medium for request retry, so as to solve the problems of poor flexibility, low success rate, and possibly increased load on a called end in related art. The technical scheme is as follows:

in one aspect, a method of requesting retry is provided, the method comprising:

sending a cross-process request;

if the response corresponding to the request is not received, acquiring the time offset of the current request retry;

performing request retry according to the time offset of the current request retry;

the time offset of the current request retry is the time interval of two requests, and the time interval is dynamically determined according to a service scene.

Optionally, after performing a request retry according to the time offset of the current request retry, the method further includes:

and if a response corresponding to the request retry is received, ending the request retry.

Optionally, after the retry of the end request, the method further includes:

and storing the response of the request retry, wherein the stored response of the request retry is used as the response of the subsequent same request.

Optionally, the method further comprises: obtaining a threshold value of retry times;

and if the retry number reaches the retry number threshold, ending the request retry.

Optionally, the method further comprises: and dynamically adjusting the threshold value of the retry times according to the service scene.

Optionally, after the sending the cross-process request, the method further includes:

receiving a response corresponding to the cross-process request;

and storing the response corresponding to the cross-process request, wherein the stored response of the request retry is used as the response of the subsequent same request.

In one aspect, an apparatus for requesting retry is provided, the apparatus comprising:

a sending module, configured to send a cross-process request;

a first obtaining module, configured to obtain a time offset of retry of a current request if a response corresponding to the request is not received;

a retry module, configured to retry the request according to the time offset of the current request retry;

Optionally, the retry module is further configured to finish the request retry if a response corresponding to the request retry is received.

Optionally, the apparatus further comprises:

and the first storage module is used for storing the response of the request retry, and the stored response of the request retry is used as the response of the subsequent same request.

Optionally, the apparatus further comprises:

a second obtaining module, configured to obtain a threshold of retry times;

the retry module is further configured to end the request retry if the retry number reaches the retry number threshold.

Optionally, the apparatus further comprises:

and the adjusting module is used for dynamically adjusting the threshold value of the retry times according to the service scene.

Optionally, the apparatus further comprises:

the second storage module is used for receiving a response corresponding to the cross-process request; and storing the response corresponding to the cross-process request, wherein the stored response of the request retry is used as the response of the subsequent same request.

In one aspect, a device for requesting retry is provided, the device comprising a processor and a memory, the memory having stored therein at least one instruction, the instruction being displayed and executed by the processor to implement the method for requesting retry as described above.

In one aspect, a computer-readable storage medium having stored therein at least one instruction for display by a processor and execution to implement a method for request retry as described above is provided.

The beneficial effect that technical scheme that this application provided brought includes at least:

after the cross-process request is sent, if a response corresponding to the request is not received, the request retry is carried out by acquiring the time offset of the current request retry, and the time offset is dynamically determined according to a service scene, so that the request is prevented from being retried in batch within fixed time, and the flexibility and the success rate of the request retry are improved; and avoids the load increase of the called end caused by service failure.

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 description of the embodiments are briefly introduced 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 creative efforts.

FIG. 1 is a schematic diagram of an implementation environment provided by an embodiment of the present application;

FIG. 2 is a flow chart of a method for requesting retry provided by an embodiment of the present application;

FIG. 3 is a flow chart of a method for requesting retry provided by an embodiment of the present application;

FIG. 4 is a schematic view of a game display interface provided by an embodiment of the present application;

FIG. 5 is a block diagram of an apparatus for requesting retry according to an embodiment of the present disclosure;

fig. 6 is a schematic structural diagram of an apparatus for requesting retry according to an embodiment of the present application;

FIG. 7 is a block diagram of an apparatus for requesting retry according to an embodiment of the present disclosure;

FIG. 8 is a block diagram of an apparatus for requesting retry according to an embodiment of the present disclosure;

fig. 9 is a schematic structural diagram of an apparatus for requesting retry according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a terminal according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The embodiment of the application provides a method for requesting retry, which can be applied to the implementation environment shown in fig. 1. In fig. 1, at least one terminal 11 and a server 12 are included, and the terminal 11 can be communicatively connected to the server 12 to obtain a time offset for a request retry from the server 12.

The terminal 11 may be any electronic product that can perform human-Computer interaction with a user through one or more modes such as a keyboard, a touch pad, a touch screen, a remote controller, voice interaction, or handwriting equipment, for example, a PC (Personal Computer), a mobile phone, a smart phone, a PDA (Personal Digital Assistant), a wearable device, a pocket PC (pocket PC), a tablet Computer, a smart car, a smart television, a smart sound box, and the like.

The server 12 may be a server, a server cluster composed of a plurality of servers, or a cloud computing service center.

It should be understood by those skilled in the art that the above-mentioned terminal 11 and server 12 are only examples, and other existing or future terminals or servers may be suitable for the present application and are included within the scope of the present application and are herein incorporated by reference.

Based on the implementation environment shown in fig. 1, referring to fig. 2, an embodiment of the present application provides a method for requesting retry, which can be applied to the terminal shown in fig. 1. As shown in fig. 2, the method includes:

step 201, a cross-process request is sent.

In distributed service development, after a client receives a request, the request can be sent across processes, and a response corresponding to the request is waited. Wherein, the cross-process is used for data exchange between different application programs.

Taking the example of sending a request from a first service to a second service cross-process in the same client as an example, when the first service sends the request to the second service cross-process, that is, the first service cross-process calls the second service, if the call is non-idempotent, that is, the influence of repeated operation and one operation is different, it is necessary to ensure that the called services are consistent.

Optionally, after the cross-process request is sent, if a response corresponding to the cross-process request is received, the response corresponding to the cross-process request is stored, and the stored response corresponding to the cross-process request is used as a response of a subsequent same request.

That is to say, after the client sends the cross-process request, when the client receives a response corresponding to the cross-process request, the request task is ended, and the response corresponding to the cross-process request is stored in the memory of the client. When the client receives the same request subsequently, the response in the memory of the client is directly used as the corresponding response for feedback.

In consideration of the limited storage space of the memory, the method provided by the embodiment of the application can sequence the responses stored in the memory according to the storage time or the use frequency of the responses, and delete the responses of the reference number after the sequencing at regular intervals to release the storage space of the memory. The period of the deletion response may be set according to experience or according to a service scenario, which is not limited in the embodiment of the present application. After the period of the deletion response is set, the method provided by the embodiment of the application also supports adjustment of the deletion period. Once adjusted, the responses stored in the memory are subsequently periodically deleted according to the adjusted period.

For example, 3 responses, namely a response a, a response B, and a response C, are stored in the memory, the storage time of the response a is 20 hours, the storage time of the response B is 12 hours, the storage time of the response C is 1 hour, and taking the period for deleting the responses as 24 hours as an example, one response in the next rank is deleted every 24 hours, and since the storage time of the response a is longest and the rank is in the next rank, the response a is deleted after the period is reached.

In addition, optionally, after the period of deleting the response is reached, the response with the storage time reaching a certain length or the use frequency being less than the use frequency threshold value in the memory can be deleted.

Still taking the example that 3 responses, namely response a, response B and response C are stored in the memory, and the period for deleting the response is 24 hours, if the frequency of use of response a is 20 times, the frequency of use of response B is 2 times, the frequency of use of response C is 0 times, and the frequency of use threshold is 2, the response C is deleted because the frequency of use of response C does not reach the frequency of use threshold after the period for deleting the response of 24 hours is reached.

Step 202, if no response corresponding to the request is received, obtaining a time offset of retry of the current request.

And when the client does not receive the response corresponding to the request, acquiring the time offset of the current request retry from the memory of the client. The time offset of the current request retry is the time interval of two requests, and the time interval is dynamically determined according to the service scene.

It should be noted that, when the client does not receive a response corresponding to the request, it is indicated that the invoking of the service fails. The call failure has the following three conditions:

situation one

When the first service calls the second service, the request is not sent to the second service due to network reasons, and the request fails, namely the call fails.

Situation two

When the first service calls the second service, the request is sent to the second service, but the second service generates an in-process exception during service processing, so that the request is failed, namely the calling is failed.

Situation three

When the first service calls the second service, the request is sent to the second service, the service processing in the second service process is normal, and the response is successfully sent, so that the response is not sent to the first service due to network problems; or the first service is disconnected due to the timeout of the waiting response, and no response is received; resulting in a call failure.

No matter which of the above situations the call failure belongs to, when the client does not receive the response corresponding to the request, the time offset of the current request retry is obtained from the memory of the client. The time offset of the current request retry is the time interval between two requests, that is, the time interval from the last request transmission, and the last request transmission may be the first request transmission or the last request retry transmission. For example, if the current request retry is a first request retry, the time interval is a time interval from the first request retry, and if the current request retry is a second request retry, the time interval is a time interval from the first request retry.

For example, the time offset for obtaining the current request retry from the memory of the client is 5s, and if the time for sending the request last time is 10:10:08, the time for the current request retry is 10:10: 13.

Further, according to the service scenario, the time offset of the next request retry may also be dynamically adjusted to 10s, or according to the current service scenario, the time offset of the next request retry may also be dynamically adjusted to 20 s. It should be noted that the dynamic adjustment of the next request retry may be adjusted according to a service scenario or an empirical value, which is not limited in the embodiment of the present application.

The service scenario includes, but is not limited to, the current running smoothness of the client or the network state where the client is located, for example, when the client does not receive a response corresponding to the request and obtains the time offset for the current request retry from the memory, the size of the time offset is dynamically adjusted according to the current running smoothness of the client, that is, the size of the load, the running state of the current client is not smooth, and the current time offset can be dynamically adjusted to be large; the running state of the current client is smooth, and the current time offset can be dynamically adjusted to be small. Wherein. The judgment of the fluency of the current operating state of the client may be performed according to the response time of the request sending or receiving the response, or according to an empirical value, which is not limited in the embodiment of the present application.

In addition, the time offset can be dynamically adjusted according to the current network state, for example, the network state is sequentially divided into five levels from good to bad, namely, a first level, a second level, a third level, a fourth level and a fifth level; when the current network state is the second-level, the current time offset can be dynamically adjusted to 10 s; when the current network state is four levels, the current time offset can be dynamically adjusted to 20 s. The determination method of the network state is not limited in the embodiments of the present application, and for example, the determination method may be determined according to the strength of the network signal. In addition, the corresponding relationship between the network status and the current time offset may also be set according to an empirical value, which is not limited in the embodiment of the present application.

Step 203, retry request is performed according to the time offset of current retry request.

And when the client acquires the time offset of the current request retry from the memory, carrying out the request retry according to the time offset of the request retry. For example, the time offset of the current request retry is acquired from the memory of the client for 5s, and if the time of the last request sending is 10:10:08, the time of the current request retry is determined to be 10:10: 13. When the time reaches 10:10:13, the request is resent.

Optionally, when a request retry is performed, the time offset of multiple request retries may be sequentially obtained according to a service scenario, the time of the current request retry is subsequently determined according to the time offset of each request retry, and the request is retransmitted after the time of the current request retry is reached. And if a response corresponding to the request retry is received in the request retry process, ending the request retry. For example, after the time offset of multiple request retries is obtained, and a request retries is performed according to the time offset of the current request retries, when the client receives a response corresponding to the request retries, the subsequent request retries are ended.

Optionally, after receiving a response corresponding to the request retry, the method provided by the embodiment of the present application supports storing the response of the request retry, and the stored response of the request retry serves as a response of a subsequent same request.

For example, after the client performs request retry, if the client receives a response corresponding to the request retry, the request retry task is ended, and the response corresponding to the request retry is stored in the memory of the client, and when the client subsequently receives the same request, the response in the memory of the client is directly used as the corresponding response for feedback.

Since the memory space is limited, even if the response is obtained by retrying the request, the response can be periodically deleted as the response stored in the memory, and the deleting manner can refer to the related content of step 201, which is not described herein any more.

In an alternative implementation manner, based on the same concept, referring to fig. 3, in the method provided in the embodiment of the present application, when the client performs a request retry, the method further includes the following steps:

step 204, obtaining a threshold value of retry times; and if the retry number reaches the retry number threshold, ending the request retry.

When the client acquires the time offset of the current request retry from the memory, the client also acquires the retry time threshold from the memory, and when the retry time reaches the retry time threshold during the request retry, the client ends the request retry task no matter whether the client receives a response corresponding to the request retry or not.

The threshold value of the number of retries may be 6 or 10, or may be set according to actual conditions or empirical values, which is not limited in the embodiments of the present application.

Optionally, the threshold of the retry number is dynamically adjusted according to the service scenario.

The manner of dynamically adjusting the retry time threshold according to the service scenario is the same as the manner of dynamically adjusting the time offset according to the service scenario in step 202, and is not described herein again.

In an alternative embodiment, see FIG. 4, an in-game prize award is illustrated. When a user shares a game every day, the user can obtain a game ticket, a cross-process request needs to be sent when the user clicks to receive the game ticket, and when the client does not receive a response corresponding to the cross-process request, the client obtains a time offset of request retry after the cross-process request fails to be sent in order to ensure that the game ticket is normally issued to an account of the user.

After the user shares the game, due to the sharing operation of the user, when the first service sends a request to the second service across processes, the second service receives the request and responds to the request, the response is fed back to the first service, and the user receives the competition ticket according to the feedback of the first service. However, when the user does not receive any feedback at the time of picking up the ticket after sharing the game, the request retry strategy is initiated.

For example, when the user fails to receive the ticket at 00:00, the client will sequentially obtain the time offset 5, 10, 30, 60, 120, 240, 300, 600, 1200, 3600, 7200 of the request retry; the request retries may be performed sequentially at 00:00:05, 00:00:15, 00:00:45, 00:01:45, 00:03:45, 00:07:45, 00:12:45, 00:22:45, 00:42:45, 01:42:45, 03:42: 45. When the user successfully takes the ticket, the user stops retrying the request; or stop the request retry task when the number of request retries reaches the retry number threshold, i.e., after the last retry time 03:42: 45.

The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:

The response corresponding to the cross-process request and the response corresponding to the request retry are stored, so that the stored responses are used as the responses of the same subsequent requests, and the response speed can be further improved.

By obtaining the threshold value of the retry times, the request retry task is ended after the retry times reach the threshold value of the retry times, and by dynamically adjusting the threshold value of the retry times, the request retry is ended in time, so that the client is prevented from carrying out useless request retry.

An embodiment of the present application provides an apparatus for requesting retry, and referring to fig. 5, the apparatus includes:

a sending module 501, configured to send a cross-process request;

a first obtaining module 502, configured to obtain a time offset of retry of a current request if a response corresponding to the request is not received;

a retry module 503, configured to retry the request according to a time offset of the current request retry;

the cross-process is used for data exchange among different application programs; the time offset of the current request retry is the time interval of two requests, and the time interval is dynamically determined according to the service scene.

In an alternative embodiment, the retry module 503 is configured to end the request retry if a response corresponding to the request retry is received.

In an alternative embodiment, referring to fig. 6, the apparatus further comprises:

the first storage module 504 is configured to store a response requesting a retry, where the stored response requesting the retry is used as a response of a subsequent same request.

In an alternative embodiment, referring to fig. 7, the apparatus further comprises:

a second obtaining module 505, configured to obtain a retry number threshold;

the retry module 503 is further configured to end the request retry if the retry number reaches the retry number threshold.

In an alternative embodiment, referring to fig. 8, the apparatus further comprises:

and an adjusting module 506, configured to dynamically adjust the threshold of the retry number according to the service scenario.

In an alternative embodiment, referring to fig. 9, the apparatus further comprises:

a second storage module 507, configured to receive a response corresponding to the cross-process request; and storing the response corresponding to the cross-process request, wherein the stored response of the request retry is used as the response of the subsequent same request.

It should be noted that, when the apparatus provided in the foregoing embodiment implements the functions thereof, only the division of the functional modules is illustrated, and in practical applications, the functions may be distributed by different functional modules according to needs, that is, the internal structure of the apparatus may be divided into different functional modules to implement all or part of the functions described above. In addition, the apparatus and method embodiments provided by the above embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments for details, which are not described herein again.

Referring to fig. 10, a schematic structural diagram of a terminal 1000 for requesting retry according to an embodiment of the present application is shown. The terminal 1000 can be a portable mobile terminal such as: a smart phone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III, motion video Experts compression standard Audio Layer 3), an MP4 player (Moving Picture Experts Group Audio Layer IV, motion video Experts compression standard Audio Layer 4), a notebook computer, or a desktop computer. Terminal 1000 can also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or the like by other names.

In general, terminal 1000 can include: a processor 1001 and a memory 1002.

Processor 1001 may include one or more processing cores, such as 4 core processors, 5 core processors, and so forth. The processor 1001 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 1001 may also include a main processor and a coprocessor, where the main processor is a processor for Processing data in an awake state, and is also referred to as a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 1001 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the display screen. In some embodiments, the processor 1001 may further include an AI (Artificial Intelligence) processor for processing a computing operation related to machine learning.

Memory 1002 may include one or more computer-readable storage media, which may be non-transitory. The memory 1002 may also include high-speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in memory 1002 is used to store at least one instruction for execution by processor 1001 to implement a method of request retry as provided by method embodiments herein.

In some embodiments, terminal 1000 can also optionally include: a peripheral interface 1003 and at least one peripheral. The processor 1001, memory 1002 and peripheral interface 1003 may be connected by a bus or signal line. Various peripheral devices may be connected to peripheral interface 1003 via a bus, signal line, or circuit board. Specifically, the peripheral device includes: at least one of radio frequency circuitry 1004, touch screen display 1005, camera 1006, audio circuitry 1007, positioning components 1008, and power supply 1009.

The peripheral interface 1003 may be used to connect at least one peripheral related to I/O (Input/Output) to the processor 1001 and the memory 1002. In some embodiments, processor 1001, memory 1002, and peripheral interface 1003 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1001, the memory 1002, and the peripheral interface 1003 may be implemented on separate chips or circuit boards, which are not limited by this embodiment.

The Radio Frequency circuit 1004 is used for receiving and transmitting RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuitry 1004 communicates with communication networks and other communication devices via electromagnetic signals. The radio frequency circuit 1004 converts an electrical signal into an electromagnetic signal to transmit, or converts a received electromagnetic signal into an electrical signal. Optionally, the radio frequency circuit 1004 comprises: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and so forth. The radio frequency circuit 1004 may communicate with other terminals via at least one wireless communication protocol. The wireless communication protocols include, but are not limited to: metropolitan area networks, various generation mobile communication networks (2G, 3G, 4G, and 5G), Wireless local area networks, and/or WiFi (Wireless Fidelity) networks. In some embodiments, the rf circuit 1004 may further include NFC (Near Field Communication) related circuits, which are not limited in this application.

The display screen 1005 is used to display a UI (User Interface). The UI may include graphics, text, icons, video, and any combination thereof. When the display screen 1005 is a touch display screen, the display screen 1005 also has the ability to capture touch signals on or over the surface of the display screen 1005. The touch signal may be input to the processor 1001 as a control signal for processing. At this point, the display screen 1005 may also be used to provide virtual buttons and/or a virtual keyboard, also referred to as soft buttons and/or a soft keyboard. In some embodiments, display screen 1005 can be one, providing a front panel of terminal 1000; in other embodiments, display 1005 can be at least two, respectively disposed on different surfaces of terminal 1000 or in a folded design; in still other embodiments, display 1005 can be a flexible display disposed on a curved surface or on a folded surface of terminal 1000. Even more, the display screen 1005 may be arranged in a non-rectangular irregular figure, i.e., a shaped screen. The Display screen 1005 may be made of LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), and the like.

The camera assembly 1006 is used to capture images or video. Optionally, the camera assembly 1006 includes a front camera and a rear camera. Generally, a front camera is disposed at a front panel of the terminal, and a rear camera is disposed at a rear surface of the terminal. In some embodiments, the number of the rear cameras is at least two, and each rear camera is any one of a main camera, a depth-of-field camera, a wide-angle camera and a telephoto camera, so that the main camera and the depth-of-field camera are fused to realize a background blurring function, and the main camera and the wide-angle camera are fused to realize panoramic shooting and VR (Virtual Reality) shooting functions or other fusion shooting functions. In some embodiments, camera assembly 1006 may also include a flash. The flash lamp can be a monochrome temperature flash lamp or a bicolor temperature flash lamp. The double-color-temperature flash lamp is a combination of a warm-light flash lamp and a cold-light flash lamp, and can be used for light compensation at different color temperatures.

The audio circuit 1007 may include a microphone and a speaker. The microphone is used for collecting sound waves of a user and the environment, converting the sound waves into electric signals, and inputting the electric signals to the processor 1001 for processing or inputting the electric signals to the radio frequency circuit 1004 for realizing voice communication. For stereo sound collection or noise reduction purposes, multiple microphones can be provided, each at a different location of terminal 1000. The microphone may also be an array microphone or an omni-directional pick-up microphone. The speaker is used to convert electrical signals from the processor 1001 or the radio frequency circuit 1004 into sound waves. The loudspeaker can be a traditional film loudspeaker or a piezoelectric ceramic loudspeaker. When the speaker is a piezoelectric ceramic speaker, the speaker can be used for purposes such as converting an electric signal into a sound wave audible to a human being, or converting an electric signal into a sound wave inaudible to a human being to measure a distance. In some embodiments, the audio circuit 1007 may also include a headphone jack.

A Location component 1008 is employed to locate a current geographic Location of terminal 1000 for purposes of navigation or LBS (Location Based Service). The Positioning component 1008 may be a Positioning component based on the Global Positioning System (GPS) in the united states, the beidou System in china, the graves System in russia, or the galileo System in the european union.

Power supply 1009 is used to supply power to various components in terminal 1000. The power source 1009 may be alternating current, direct current, disposable batteries, or rechargeable batteries. When the power source 1009 includes a rechargeable battery, the rechargeable battery may support wired charging or wireless charging. The rechargeable battery may also be used to support fast charge technology.

In some embodiments, terminal 1000 can also include one or more sensors 1010. The one or more sensors 1010 include, but are not limited to: acceleration sensor 1011, gyro sensor 1012, pressure sensor 1013, fingerprint sensor 1014, optical sensor 1015, and proximity sensor 1016.

Acceleration sensor 1010 can detect acceleration in three coordinate axes of a coordinate system established with terminal 1000. For example, the acceleration sensor 1011 may be used to detect components of the gravitational acceleration in three coordinate axes. The processor 1001 may control the touch display screen 1005 to display a user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 1011. The acceleration sensor 1011 may also be used for acquisition of motion data of a game or a user.

The gyro sensor 1012 may detect a body direction and a rotation angle of the terminal 1000, and the gyro sensor 1012 and the acceleration sensor 1011 may cooperate to acquire a 3D motion of the user on the terminal 1000. From the data collected by the gyro sensor 1012, the processor 1001 may implement the following functions: motion sensing (such as changing the UI according to a user's tilting operation), image stabilization at the time of photographing, game control, and inertial navigation.

Pressure sensor 1013 may be disposed on a side frame of terminal 1000 and/or on a lower layer of touch display 1005. When pressure sensor 1013 is disposed on a side frame of terminal 1000, a user's grip signal on terminal 1000 can be detected, and processor 1001 performs left-right hand recognition or shortcut operation according to the grip signal collected by pressure sensor 1013. When the pressure sensor 1013 is disposed at a lower layer of the touch display screen 1005, the processor 1001 controls the operability control on the UI interface according to the pressure operation of the user on the touch display screen 1005. The operability control comprises at least one of a button control, a scroll bar control, an icon control and a menu control.

The fingerprint sensor 1014 is used to collect a fingerprint of the user, and the processor 1001 identifies the user according to the fingerprint collected by the fingerprint sensor 1014, or the fingerprint sensor 1014 identifies the user according to the collected fingerprint. Upon identifying that the user's identity is a trusted identity, the processor 1001 authorizes the user to perform relevant sensitive operations including unlocking a screen, viewing encrypted information, downloading software, paying, and changing settings, etc. Fingerprint sensor 1014 can be disposed on the front, back, or side of terminal 1000. When a physical key or vendor Logo is provided on terminal 1000, fingerprint sensor 1014 can be integrated with the physical key or vendor Logo.

The optical sensor 1015 is used to collect the ambient light intensity. In one embodiment, the processor 1001 may control the display brightness of the touch display screen 1005 according to the intensity of the ambient light collected by the optical sensor 1015. Specifically, when the ambient light intensity is high, the display brightness of the touch display screen 1005 is increased; when the ambient light intensity is low, the display brightness of the touch display screen 1005 is turned down. In another embodiment, the processor 1001 may also dynamically adjust the shooting parameters of the camera assembly 1006 according to the intensity of the ambient light collected by the optical sensor 1015.

Proximity sensor 1016, also known as a distance sensor, is typically disposed on a front panel of terminal 1000. Proximity sensor 1016 is used to gather the distance between the user and the front face of terminal 1000. In one embodiment, when proximity sensor 1016 detects that the distance between the user and the front surface of terminal 1000 gradually decreases, processor 1001 controls touch display 1005 to switch from a bright screen state to a dark screen state; when proximity sensor 1016 detects that the distance between the user and the front of terminal 1000 is gradually increased, touch display screen 1005 is controlled by processor 1001 to switch from a breath-screen state to a bright-screen state.

Those skilled in the art will appreciate that the configuration shown in FIG. 10 is not intended to be limiting and that terminal 1000 can include more or fewer components than shown, or some components can be combined, or a different arrangement of components can be employed.

In an exemplary embodiment, a computer device is also provided, the computer device comprising a processor and a memory, the memory having at least one instruction stored therein. At least one instruction is configured to be executed by one or more processors to implement the method of request retry described above.

In an exemplary embodiment, a computer-readable storage medium is also provided, having stored therein at least one instruction, which when executed by a processor of a computer device, implements the above-described method of request retry.

All the above optional technical solutions may be combined arbitrarily to form the optional embodiments of the present disclosure, and are not described herein again.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for requesting retries, the method comprising:

sending a cross-process request, wherein the cross-process is used for data exchange among different application programs;

if a response corresponding to the cross-process request is received, storing the response corresponding to the cross-process request, wherein the stored response corresponding to the cross-process request is used as a response of a subsequent same request;

obtaining a threshold value of retry times;

if the retry times do not reach the retry time threshold, carrying out request retry according to the time offset of the current request retry;

if the retry times reach the threshold value of the retry times, finishing the retry of the request;

the time offset of the current request retry is a time interval of two requests, the time interval and the retry number threshold are dynamically determined according to a service scenario, and the service scenario includes a running fluency or a network state where the current request retry is located.

2. The method of claim 1, wherein after performing a request retry based on the time offset of the current request retry, further comprising:

3. The method of claim 2, wherein after the end request retry, further comprising:

4. An apparatus for requesting retries, the apparatus comprising:

the system comprises a sending module, a receiving module and a sending module, wherein the sending module is used for sending a cross-process request, and the cross-process is used for carrying out data exchange among different application programs;

the second storage module is used for receiving a response corresponding to the cross-process request; storing a response corresponding to the cross-process request, wherein the stored response of the request retry is used as the response of the subsequent same request;

a second obtaining module, configured to obtain a threshold of retry times;

a retry module, configured to retry the request according to the time offset of the current request retry if the retry number does not reach the retry number threshold; the retry module is also used for finishing the request retry if the retry times reach the retry times threshold value;

the time offset of the current request retry is a time interval of two requests, the time interval and the retry time threshold are dynamically determined according to a service scene, and the service scene comprises operation fluency or a network state;

5. The apparatus of claim 4, wherein the retry module is further configured to end the request retry if a response corresponding to the request retry is received.

6. The apparatus of claim 5, further comprising:

7. A device for requesting retries, the device comprising a processor and a memory, the memory having stored therein at least one instruction, the instruction being displayed and executed by the processor to implement the method for requesting retries as claimed in any one of claims 1-3.

8. A computer-readable storage medium having stored therein at least one instruction for display by a processor and execution to perform a method of request retry according to any of claims 1-3.