Network detection method and related device, electronic device and storage medium

Abstract

The present application discloses a network detection method and related devices, electronic devices and storage media, wherein the network detection method includes: selecting an application that currently triggers a network service request as a target application; predicting the current network status based on the historical network information determined after the target application and the applications in the trusted application set each recently triggered a network service request; wherein the historical network information includes the historical network status and the historical moment when the historical network status was determined; based on the current network status, determining the timeout request duration of the target application; wherein the timeout request duration is positively correlated with the network quality represented by the current network status; and determining whether it is prompted that the network service request of the target application cannot be responded to based on whether the request feedback result of the target application is obtained within the timeout request duration. The above scheme can improve the judgment accuracy of the network status and the feedback speed of the application.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a network detection method and related devices, electronic equipment, and storage media. Background Art

[0002] With the rapid popularization of the internet, electronic devices such as smartphones and tablets are widely used in daily life, work, and professional engineering. When connected to the internet, the various applications within their systems can provide users with a wide range of information, satisfying their diverse needs.

[0003] Currently, applications generally rely on internal detection within the application system to determine network status. However, this approach often has significant limitations in specific environments, such as tunnels and elevators. In particular, in weak network environments, long progress bars are often required to load and refresh, resulting in slow application response and increased user wait time. Furthermore, untimely refreshes can lead to incorrect network status determinations. Therefore, improving the accuracy of network status determination and the speed of application response has become an urgent issue. Summary of the Invention

[0004] The main technical problem solved by this application is to provide a network detection method and related devices, electronic equipment and storage media, which can improve the judgment accuracy of network status and the feedback speed of application programs.

[0005] In order to solve the above-mentioned technical problems, the first aspect of the present application provides a network detection method, including: selecting an application that currently triggers a network service request as a target application; predicting the current network status based on the historical network information determined after the target application and the application in the trusted application set each recently triggered a network service request; wherein the historical network information includes the historical network status and the historical moment when the historical network status was determined; based on the current network status, determining the timeout request duration of the target application; wherein the timeout request duration is positively correlated with the network quality represented by the current network status; based on whether the request feedback result of the target application is obtained within the timeout request duration, determining whether it is prompted that the network service request of the target application cannot be responded to at present.

[0006] In order to solve the above technical problems, the second aspect of the present application provides a network detection device, including: a selection module, a pre-judgment module, a determination module and a prompt module, the selection module is used to select the application that currently triggers the network service request as the target application; the pre-judgment module is used to pre-judgment the current network status based on the historical network information determined after the target application and the application in the trusted application set each recently triggered the network service request; wherein the historical network information includes the historical network status and the historical moment when the historical network status was determined; the determination module is used to determine the timeout request duration of the target application based on the current network status; wherein the timeout request duration is positively correlated with the network quality represented by the current network status; the prompt module is used to determine whether to prompt that the network service request of the target application cannot be responded to at present based on whether the request feedback result of the target application is obtained within the timeout request duration.

[0007] In order to solve the above technical problems, the third aspect of the present application provides an electronic device, which includes at least a memory and a processor coupled to each other, wherein the memory stores at least program instructions, and the processor is used to execute the program instructions to implement the network detection method in the above first aspect.

[0008] In order to solve the above technical problems, the fourth aspect of the present application provides a computer-readable storage medium storing program instructions that can be executed by a processor, and the program instructions are used to implement the network detection method of the first aspect.

[0009] The above scheme selects the application that currently triggers the network service request as the target application, and then predicts the current network status based on the historical network information determined by the target application and the application in the trusted application set after each of them recently triggered the network service request, and the historical network information includes the historical network status and the historical time when the historical network status was determined, so as to determine the timeout request duration of the target application based on the current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, and then, based on whether the request feedback result of the target application is obtained within the timeout request duration, it is determined whether it is prompted that the network service request of the target application cannot be responded to at present. Therefore, on the one hand, since the current network status is determined by the target application itself and the application in the trusted application set after each of them recently triggered the network service request The determined historical network information is predicted without relying on the internal detection of the application system. This can avoid network status judgment errors caused by untimely refresh as much as possible, which helps to improve the accuracy of network status judgment. On the other hand, since the timeout request duration is adaptively determined based on the predicted current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, that is, the higher the network quality represented by the current network status, the longer the timeout request duration. In a high-quality network, it is possible to wait for a longer time to successfully obtain the feedback result of the network service request. Conversely, the lower the network quality represented by the current network status, the shorter the timeout request duration. In a low-quality network, it is possible to wait for a shorter time to shorten the waiting time as much as possible in a weak network environment, which helps to improve the feedback speed of the application. Therefore, it is possible to improve the accuracy of network status judgment and the feedback speed of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 This is a flow chart of an embodiment of the network detection method of the present application;

[0011] Figure 2 This is a schematic diagram of the framework of an embodiment of the network detection device of the present application;

[0012] Figure 3 This is a schematic diagram of the framework of an embodiment of the electronic device of the present application;

[0013] Figure 4 It is a schematic diagram of a framework of an embodiment of a computer-readable storage medium of the present application. DETAILED DESCRIPTION

[0014] The following describes the embodiments of the present application in detail with reference to the accompanying drawings.

[0015] In the following description, for the purpose of explanation rather than limitation, specific details such as specific system structures, interfaces, and technologies are provided to facilitate a thorough understanding of the present application.

[0016] The terms "system" and "network" are often used interchangeably in this document. The term "and / or" is simply a description of an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the fragment " / " generally indicates that the related objects are in an "or" relationship. Furthermore, "multiple" in this document refers to two or more than two.

[0017] See also Figure 1 , Figure 1 It is a flowchart of an embodiment of the network detection method of the present application.

[0018] Specifically, the following steps may be included:

[0019] Step S11: Select the application that currently triggers the network service request as the target application.

[0020] In an implementation scenario, an application system may include multiple applications, and the application may trigger a network service request in response to user operations, or the application layer may automatically trigger a network service request. For example, taking an application for listening to music as an example, when a user opens the application and clicks on a song to play, a network service request may be triggered, such as requesting song audio, cover, lyrics, and other information; or, taking an application for watching the stock market as an example, the application may automatically trigger a network service request at intervals of a preset duration (e.g., 0.5 seconds, 1 second, etc.), such as requesting the current stock price, trading volume, and other information. Of course, the above examples are only a few possible examples of how an application may trigger a network service request in actual application, and do not limit the specific method of triggering a network service request.

[0021] In one implementation scenario, as described above, the application program may be included in an application system. The application system may specifically include, but is not limited to, a Windows operating system, a mobile terminal system such as Android, or an embedded system such as Ubuntu. The specific type of application system is not limited herein.

[0022] In one implementation scenario, when it is detected that a certain application is currently triggering a network service request, the application can be used as the target application. For example, the application system may include N applications, some of which may be in a silent state (i.e., not pulled up by the user, and not automatically triggering a network service request), such as alarm clocks, notes, calculators and other applications, and some applications may be in a state of automatically triggering a network service request, such as an online music player application in a playing state, a stock application in the foreground, etc. There are also applications that may be used to trigger a network service request, such as chat applications. Among the above N applications, if it is currently detected that a user enters and sends text in a chat application, a network service request is triggered. Of course, other applications can be deduced by analogy, and no one is given as an example here.

[0023] Step S12: Predicting the current network status based on historical network information determined after the target application and the application programs in the trusted application set have recently triggered network service requests.

[0024] In the disclosed embodiments, historical network information includes historical network status and the historical time when the historical network status was determined. For example, the historical network information for a particular application may include, but is not limited to, "XX day XX hour XX minute 01 second - Network available," "XX day XX hour XX minute 10 seconds - Network available," and "XX day XX hour XX minute 50 seconds - No network available." Of course, the above example is merely one possible example of historical network information in actual applications, and the specific content of the historical network information is not limited here. Furthermore, historical network status can not only roughly indicate whether a network is available or not, but also more finely indicate the strength of the network when a network is available. Still using the aforementioned historical network information as an example, it may specifically include, but is not limited to, "XX day XX hour XX minute 01 second - Network available and strong," "XX day XX hour XX minute 10 seconds - Network available and weak," and "XX day XX hour XX minute 50 seconds - No network available." Of course, in addition to using the text "strong network" or "weak network" as in the above example, specific network strength values ​​such as RSSI can also be used to indicate network strength, which is not limited here.

[0025] In one implementation scenario, the trusted application set may be composed of applications whose historical network status is trusted. As a possible example, the trusted application set may be initialized first. Specifically, the attribute information of each application in the application system may be obtained, and the attribute information may include: the frequency of use of the application, whether the application is at least one of the programs that come with the application system. On this basis, it may be determined whether to select the application to the trusted application set based on the attribute information of the application. The above method, which determines whether to select the application to the trusted application set based on the attribute information of the application, can improve the initialization quality of the trusted application set as much as possible, and help improve the credibility of historical network information.

[0026] In a specific implementation scenario, when the attribute information includes application usage frequency, the higher the application usage frequency, the higher the likelihood of selecting the application into the trusted application set. For example, the applications in the application system can be sorted according to their usage frequency, and then applications ranked before a preset ranking (e.g., the top five, top eight, top ten, etc.) are selected and added to the trusted application set.

[0027] In a specific implementation scenario, when the attribute information includes whether the application program is a built-in program of the application system, the built-in program of the application system can be selected into the trusted application set.

[0028] In one implementation scenario, the most recently triggered network service request may be the most recently triggered network service request, or may be the most recently triggered network service request several times (e.g., the most recently triggered network service request, the most recently triggered network service request, etc.). As a possible example, taking the most recently triggered network service request as the most recently triggered network service request, the historical network information determined after the target application itself last triggered the network service request can be obtained, such as "XX day XX hour XX minute 20 seconds - there is a network status and a strong network status", and the historical network information determined when the application in the trusted application set last triggered the network service request can be obtained, such as "XX day XX hour XX minute 30 seconds - there is a network status and a strong network status". Of course, the above examples are only possible examples of the historical network information determined after the target application and the application in the trusted application set each last triggered the network service request, and the specific content of the historical network information corresponding to the target application and the application in the trusted application set is not limited here.

[0029] In one implementation scenario, after obtaining the historical network information determined after the target application and the application in the trusted application set each recently triggered a network service request, the historical network state can be selected as the first network state and the historical moment can be selected as the first historical moment in the historical network information corresponding to the target application, and the historical network state can be selected as the second network state and the historical moment can be selected as the second historical moment in the historical network information corresponding to the application in the trusted application set. On this basis, the first network state or the second network state can be selected as the current network state based on the first historical moment and the second historical moment. The above method, based on the historical moment of the historical network state obtained after the target application and the application in the trusted application set each recently triggered a network service request, selects one of the two historical network states as the current network state, which helps to improve the accuracy and efficiency of predicting the current network state.

[0030] In a specific implementation scenario, as a possible example, still taking the example of obtaining historical network information determined after the most recent network service request was triggered, as described above, the historical network information corresponding to the target application may include, but is not limited to, "XX day XX hour XX minute 20 seconds - network available and strong network status." In this case, the first network status may be "network available and strong network status," and the first historical moment may be "XX day XX hour XX minute 20 seconds." The historical network information corresponding to an application within the trusted application set may include, but is not limited to, "XX day XX hour XX minute 30 seconds - network available and strong network status." In this case, the second network status may be "network available and strong network status," and the second historical moment may be "XX day XX hour XX minute 30 seconds." Of course, the above example is merely one possible example of the first network status, second network status, first historical moment, and second historical moment in actual application, and does not limit the specific content of the first network status, second network status, first historical moment, and second historical moment.

[0031] In a specific implementation scenario, in response to the elapsed time from at least the first historical moment to the current moment being no greater than the first time threshold, the first network state may be selected as the current network state. That is, when the elapsed time from the first historical moment to the current moment is no greater than the first time threshold, or when the elapsed time from the first historical moment and the second historical moment to the current moment are both no greater than the first time threshold, the first network state may be selected as the current network state. It should be noted that the first time threshold may be set according to actual application conditions. For example, when the prediction accuracy of the network state is relatively high, the first time threshold may be set to be appropriately smaller, or when the prediction accuracy of the network state is relatively loose, the first time threshold may be set to be appropriately larger. The specific value of the first time threshold is not limited here. Taking the aforementioned historical network information as an example, if the current time is "XX day XX hour XX minute 40 seconds" and the first duration threshold is set to 30 seconds, since the elapsed time from the first historical moment to the current moment (20 seconds) is not greater than the first duration threshold of 30 seconds, and the elapsed time from the second historical moment to the current moment (10 seconds) is not greater than the first duration threshold of 30 seconds, then the first historical state "network available and strong" can be selected as the current network state. Of course, the above example is only one possible example in actual application, and other possible situations will not be given examples here. The above approach selects the first network state as the current network state in response to the elapsed time from at least the first historical moment to the current moment being not greater than the first duration threshold. This allows the target application's own first network state to be preferentially selected as the current network state when the elapsed time from at least the first historical moment to the current moment is not greater than the first duration threshold, i.e., when at least the first historical moment of the first network state is within the time limit defined by the first duration threshold, thereby helping to improve the accuracy of network status prediction.

[0032] In one specific implementation scenario, in response to only the elapsed time from the second historical moment to the current moment being less than the first duration threshold, the second network state is selected as the current network state. That is, when the elapsed time from the first historical moment to the current moment is greater than the first duration threshold, while the elapsed time from the second historical moment to the current moment is less than the first duration threshold, the second network state may be selected as the current network state. It should be noted that the specific setting of the first duration threshold can be found in the aforementioned related description and will not be repeated here. Still using the aforementioned historical network information as an example, if the current moment is "XX day XX hour XX minute 40 seconds" and the first duration threshold is set to 15 seconds, since the elapsed time from the first historical moment to the current moment, 20 seconds, is greater than the first duration threshold of 15 seconds, and the elapsed time from the second historical moment to the current moment, 10 seconds, is less than the first duration threshold of 15 seconds, the second historical state, "network available and strong network state," may be selected as the current network state. Of course, the above example is only one possible example in actual application, and other possible scenarios will not be given one by one here. The above method selects the second network state as the current network state in response to the fact that only the elapsed time from the second historical moment to the current moment is not greater than the first time threshold. When only the elapsed time from the second historical moment to the current moment is not greater than the first time threshold, that is, only the second historical moment of the second network state is within the time limit defined by the first time threshold, the second network state can be selected as the current network state, which helps to improve the prediction accuracy of the network state.

[0033] In a specific implementation scenario, different from the above two situations, in response to the fact that the elapsed time from the first historical moment and the second historical moment to the current moment is greater than the first time threshold, that is, the first network state and the second network state are not within the time limit defined by the first time threshold, then the one with the shorter elapsed time corresponding to the first network state and the second network state can be selected as the current network state.

[0034] Step S13: Based on the current network status, determine the timeout request duration of the target application.

[0035] In the disclosed embodiments, the timeout request duration is positively correlated with the network quality represented by the current network status. That is, the higher the network quality represented by the current network status, the longer the timeout request duration. Conversely, the lower the network quality represented by the current network status, the shorter the timeout request duration. For example, if the current network status is "roughly" represented by "network status" or "no network status," the network quality represented by "network status" is higher than the network quality represented by "no network status." Alternatively, if the current network status is "detailedly" represented by expressions such as "network status and strong network status," "network status and weak network status," or "no network status," the network quality represented by "network status and strong network status" is higher than the network quality represented by "network status and weak network status," and the network quality represented by "network status and weak network status" is higher than the network quality represented by "no network status." Other situations can be deduced from this analogy and are not further exemplified here.

[0036] In one implementation scenario, as a possible example, several timeout request durations can be pre-set, such as 5 seconds, 10 seconds, 15 seconds, etc. Then, after obtaining the current network status, one of the several timeout request durations can be selected as the timeout request duration of the target application based on the network quality represented by the current network status. For example, taking the current network status as "detailedly" represented by "network status and strong network status", "network status and weak network status", and "no network status" as an example, when the current network status is "network status and strong network status", based on the principle that the timeout request duration is positively correlated with the network quality represented by the current network status, the largest one of several timeout request durations, such as 15 seconds, can be selected as the timeout request duration of the target application. Alternatively, when the current network status is "network status and weak network status", based on the principle that the timeout request duration is positively correlated with the network quality represented by the current network status, a moderate one of several timeout request durations, such as 10 seconds, can be selected as the timeout request duration of the target application. Alternatively, when the current network status is "no network status", based on the principle that the timeout request duration is positively correlated with the network quality represented by the current network status, the smallest one of several timeout request durations, such as 5 seconds, can be selected as the timeout request duration of the target application. Of course, the above example is only a possible example in actual application. When the preset timeout request durations are other values ​​or when the current network status is expressed in other ways, the timeout request durations of the target application can be deduced accordingly, and no further examples are given here.

[0037] In another implementation scenario, as another possible example, a mapping relationship can be pre-set to show a positive correlation between network quality and request timeout duration. Based on this, after pre-determining the current network quality, the network quality represented by the current network quality can be mapped based on the mapping relationship to obtain the request timeout duration of the target application. Exemplarily, the aforementioned mapping relationship can be a linear mapping relationship or a nonlinear mapping relationship, which is not limited here.

[0038] Step S14: Based on whether the request feedback result of the target application is obtained within the timeout request duration, it is determined whether it is prompted that the network service request of the target application cannot be responded to at present.

[0039] It should be noted that the request feedback result of the target application specifically represents the request feedback result of the network service request triggered by the target application this time. For example, taking the target application as an "online music player" as an example, the network service request of the target application this time is triggered by the user clicking on any song. If the target application obtains the audio, lyrics, cover and other information of the song, it can be determined that the request feedback result is obtained; or, taking the target application as a "chat software" as an example, the network service request of the target application this time is triggered by the user sending a message. If the target application obtains the relevant instructions indicating that the message has been successfully sent, it can be determined that the request feedback result is obtained. Other situations can be deduced by analogy, and no examples are given here one by one.

[0040] In one implementation scenario, in response to obtaining a request feedback result within the timeout request duration, a prompt indicating that the target application's network service request is currently unable to be responded to may not be prompted. Taking the current network status as "network status and strong network status" as an example, as described above, the target application's timeout request duration can be set to 15 seconds. If a request feedback result is obtained within 15 seconds after the target application triggers the network service request, a prompt indicating that the target application's network service request is currently unable to be responded to may not be prompted; or, taking the current network status as "network status and weak network status" as an example, as described above, the target application's timeout request duration can be set to 10 seconds. If a request feedback result is obtained within 10 seconds after the target application triggers the network service request, a prompt indicating that the target application's network service request is currently unable to be responded to may not be prompted; or, taking the current network status as "no network status" as an example, as described above, the target application's timeout request duration can be set to 5 seconds. If a request feedback result is obtained within 5 seconds after the target application triggers the network service request, a prompt indicating that the target application's network service request is currently unable to be responded to may not be prompted. In other words, the worse the network quality represented by the current network status, the shorter the corresponding request timeout period. Generally speaking, the lower the likelihood of obtaining a request feedback result, the shorter the user's wait time. In other words, the worse the network quality represented by the current network status, the shorter the user's wait time, minimizing the wait time when the likelihood of successfully obtaining a request feedback result is low.

[0041] In one implementation scenario, in response to not obtaining a request feedback result within a timeout request duration, a prompt may be given that the network service request of the target application cannot be currently responded to. Taking the current network status as "network status and strong network status" as an example, as described above, the timeout request duration of the target application can be set to 15 seconds. If the request feedback result is not obtained within 15 seconds after the target application triggers the network service request, a prompt may be given that the network service request of the target application cannot be currently responded to; or, taking the current network status as "network status and weak network status" as an example, as described above, the timeout request duration of the target application can be set to 10 seconds. If the request feedback result is not obtained within 10 seconds after the target application triggers the network service request, a prompt may be given that the network service request of the target application cannot be currently responded to; or, taking the current network status as "no network status" as an example, as described above, the timeout request duration of the target application can be set to 5 seconds. If the request feedback result is not obtained within 5 seconds after the target application triggers the network service request, a prompt may be given that the network service request of the target application cannot be currently responded to. In other words, the worse the network quality represented by the current network status, the shorter the corresponding request timeout period. Generally speaking, the lower the likelihood of obtaining a request feedback result, the shorter the user's wait time. In other words, the worse the network quality represented by the current network status, the shorter the user's wait time, minimizing the wait time when the likelihood of successfully obtaining a request feedback result is low.

[0042] In one implementation scenario, any application that triggers a network service request can determine the historical network status at the time the request was triggered based on whether it receives a response within a specified timeout. This historical network status, along with the time at which the historical network status was determined, can then be broadcast to the application system for all applications within the system to learn about.

[0043] In one implementation scenario, for the target application, after determining the timeout request duration of the target application based on the current network status, the historical network information determined after the target application triggers the network service request this time can be obtained based on whether the request feedback result of the target application is obtained within the timeout request duration. Then, in the application system, the historical network information determined after the target application triggers the network service request this time is broadcast so that it can be known by each application in the application system, thereby being able to update the historical network information in time for use when any application in the application system triggers a network service request subsequently.

[0044] In a specific implementation scenario, in response to obtaining a request feedback result within the timeout request duration, it can be determined that the historical network status of the target application triggering the network service request this time at least includes that the network is available and the historical moment is the moment when the request feedback result is obtained. Specifically, the historical network status can be set according to whether the "granularity requirement" of its expression is "coarsely" or "finely". For example, when "coarsely" expressed is required, if the request feedback result is obtained within the timeout request duration, it can be determined that the historical network status of the target application triggering the network service request this time can be expressed as "network status available". Alternatively, when a "detailed" representation is required, if the request feedback result is obtained within the timeout request duration and the difference between the time the request feedback result is obtained and the time the network service request is triggered is less than a set threshold (e.g., 4 seconds, 5 seconds, etc.), it can be determined that the historical network status of the target application triggering the network service request can be expressed as "network available and strong network status." Alternatively, if the request feedback result is obtained within the timeout request duration and the difference between the time the request feedback result is obtained and the time the network service request is triggered is greater than a set threshold (e.g., 4 seconds, 5 seconds, etc.), it can be determined that the historical network status of the target application triggering the network service request can be expressed as "network available and weak network status." In the above method, in response to obtaining the request feedback result within the timeout request duration, it is determined that the historical network status of the target application triggering the network service request at least includes the time when the network is available and the historical time is the time when the request feedback result is obtained. If the request feedback result is obtained within the timeout request duration, the time when the request feedback result is obtained is used as the historical time to maximize the accuracy of the historical time.

[0045] In a specific implementation scenario, in response to not obtaining a request feedback result within a timeout request duration, it is determined that the historical network state of the target application triggering the network service request this time at least includes that the network is unavailable and the historical moment is the arrival time of the timeout request duration. Specifically, as mentioned above, in this case, the historical network state can be expressed as "no network state". In the above method, in response to not obtaining a request feedback result within a timeout request duration, it is determined that the historical network state of the target application triggering the network service request this time at least includes that the network is unavailable and the historical moment is the arrival time of the timeout request duration. When the request feedback result is not obtained within the timeout request duration, the arrival time of the timeout request duration can be used as the historical moment to improve the accuracy of the historical moment as much as possible.

[0046] In one implementation scenario, in order to improve the reference value of the trusted application set, the trusted application set can be regularly inspected. Specifically, for each application in the trusted application set, the network status sequence of the application can be obtained based on the historical network status from the historical moment to the current moment, where the elapsed time is not greater than the second time threshold. On this basis, it can be determined separately based on the network status sequence of each application in the trusted application set whether to transfer the application out of the trusted application set. The above method determines whether to move the application out of the trusted application set based on the network status sequence formed by the historical network status within the failure period defined by the second time threshold. It can discover applications with abnormal network status sequences from the time dimension, which helps to improve the reference value of the trusted application set.

[0047] In a specific implementation scenario, the second duration threshold can be set specifically based on timeliness requirements. For example, when timeliness requirements are relatively high, the second duration threshold can be set appropriately shorter, or when timeliness requirements are relatively low, the second duration threshold can be set appropriately longer. The specific value of the second duration threshold is not limited herein.

[0048] In a specific implementation scenario, for each application in the trusted application set, the historical network information determined after each network service request is triggered can be screened. Specifically, for each historical network information, it can be checked whether the elapsed time from the historical moment to the current moment in the historical network information is not greater than the second time threshold. If so, the historical network information can be selected. Finally, the historical network information obtained can be sorted according to the order of the historical moments in the historical network information to obtain a network state sequence. Exemplarily, the network state sequence can be expressed as {(historical moment 1, historical network state 1), (historical moment 2, historical network state 2), ..., (historical moment t, historical network state t)}. Of course, the above example is only one possible way to represent the network state sequence, and the specific representation of the network state sequence is not limited here.

[0049] In a specific implementation scenario, after obtaining the network status sequence of each application in the trusted application set, each application in the trusted application set can be selected as the current application, and an application other than the current application in the trusted application set can be selected as a reference application. The correlation between the network status sequence of the current application and the network status sequence of the reference application can then be obtained. For example, the network status sequence can be mapped onto a two-dimensional coordinate system with the historical time as the horizontal axis and the historical network status as the vertical axis, so that each application can form a trend curve representing the change of the historical network status with the historical time. The trend curve of the current application can then be correlated with the trend curve of the reference application to obtain the correlation. Of course, the above example is only one possible example of obtaining the correlation and does not limit other methods of obtaining the correlation. On this basis, it can be determined whether to remove the current application from the trusted application set based on the reference application whose correlation with the current application meets the correlation condition. As a possible example, the correlation condition can be set to a correlation greater than a correlation threshold (e.g., 0.8, 0.9, etc.), which is not limited here. Specifically, we can count the total number of reference applications that meet the correlation criteria. If this total number exceeds a threshold, we can conclude that the trend curve of the current application's historical network status is highly correlated with the trend curves of the historical network status of a larger number of reference applications. Therefore, we can consider the current application to be reliable and therefore retain it in the trusted application set. Conversely, we can consider the current application to be unreliable and remove it from the trusted application set. This approach, by measuring whether to remove an application from the trusted application set by obtaining the correlation between the network status sequences of applications, can enhance the reference value of the trusted application set.

[0050] In one implementation scenario, in order to enhance the reference value of the trusted application set, in contrast to the aforementioned periodic verification method, timely and instant verification can also be performed. Specifically, in the case where the target application happens to be an application within the trusted application set, it is also possible to determine whether to perform a test on the target application's network permissions based on the historical network information determined after the target application triggers the network service request this time, and to determine whether to remove the target application from the trusted application set based on the test results of the target application's network permissions. The above method, by determining whether to perform a test on the target application's network permissions based on the historical network information determined after the target application triggers the network service request this time, and determining whether to remove the target application from the trusted application set based on the test results of the network permissions, can timely update the trusted application set during use, which helps to enhance the reference value of the trusted application set.

[0051] In a specific implementation scenario, after obtaining the historical network information determined after the target application triggers the network service request this time, it can be determined that the target application's network permission is detected in response to the historical network status determined after the target application triggers the network service request this time at least including network unavailability (such as the aforementioned "no network status"), and in response to the historical network status determined after the target application triggers the network service request this time at least including network availability (such as the aforementioned "network status", "network status and strong network status", "network status and weak network status", etc.), it is determined not to detect the target application's network permission, and directly not to remove the target application from the trusted application set. The above method, which determines whether to detect or not to detect the target application's network permission through different situations of historical network information, helps to improve the update efficiency of the trusted application set.

[0052] In a specific implementation scenario, after obtaining the target application's detection result on the network permission, it can be determined not to remove the target application from the trusted application set in response to the target application's detection result on the network permission including that the target application has the network permission, and it can be determined to remove the target application from the trusted application set in response to the target application's detection result on the network permission including that the target application does not have the network permission. It should be noted that since the application may change the network permission due to user operation during use (such as from "allow network access" to "do not allow network access", or from "do not allow network access" to "allow network access", etc.), when the target application does not have the network permission, it can be determined that its historical network status is also difficult to have reference value for network detection. Conversely, when the target application has the network permission, it can be determined that its historical network status is of reference value for network detection. The above method determines whether to remove the target application from the trusted application set through the detection result of the network permission, which can maximize the reference value of the trusted application set.

[0053] The above scheme selects the application that currently triggers the network service request as the target application, and then predicts the current network status based on the historical network information determined by the target application and the application in the trusted application set after each of them recently triggered the network service request, and the historical network information includes the historical network status and the historical time when the historical network status was determined, so as to determine the timeout request duration of the target application based on the current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, and then, based on whether the request feedback result of the target application is obtained within the timeout request duration, it is determined whether it is prompted that the network service request of the target application cannot be responded to at present. Therefore, on the one hand, since the current network status is determined by the target application itself and the application in the trusted application set after each of them recently triggered the network service request The determined historical network information is predicted without relying on the internal detection of the application system. This can avoid network status judgment errors caused by untimely refresh as much as possible, which helps to improve the accuracy of network status judgment. On the other hand, since the timeout request duration is adaptively determined based on the predicted current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, that is, the higher the network quality represented by the current network status, the longer the timeout request duration. In a high-quality network, it is possible to wait for a longer time to successfully obtain the feedback result of the network service request. Conversely, the lower the network quality represented by the current network status, the shorter the timeout request duration. In a low-quality network, it is possible to wait for a shorter time to shorten the waiting time as much as possible in a weak network environment, which helps to improve the feedback speed of the application. Therefore, it is possible to improve the accuracy of network status judgment and the feedback speed of the application.

[0054] See also Figure 2 , Figure 2 The present invention is a schematic diagram of a framework of an embodiment of a network detection device 20. The network detection device 20 includes: a selection module 21, a pre-judgment module 22, a determination module 23, and a prompt module 24. The selection module 21 is used to select the application currently triggering the network service request as the target application; the pre-judgment module 22 is used to pre-judgment the current network status based on the historical network information determined after the target application and the applications in the trusted application set each recently triggered the network service request; wherein the historical network information includes the historical network status and the historical time when the historical network status was determined; the determination module 23 is used to determine the timeout duration of the target application's request based on the current network status; wherein the timeout duration is positively correlated with the network quality represented by the current network status; and the prompt module 24 is used to determine whether to prompt that the network service request of the target application cannot be responded to based on whether the request feedback result of the target application is obtained within the timeout duration.

[0055] In the above scheme, the network detection device 20 selects the application that currently triggers the network service request as the target application, and then predicts the current network status based on the historical network information determined by the target application and the application in the trusted application set after each of them recently triggered the network service request, and the historical network information includes the historical network status and the historical time when the historical network status was determined, thereby determining the timeout request duration of the target application based on the current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, and then determining whether the request feedback result of the target application is obtained within the timeout request duration to prompt that the network service request of the target application cannot be responded to at present. Therefore, on the one hand, since the current network status is determined by the target application itself and the application in the trusted application set recently triggered the network service request Afterwards, the historical network information determined is predicted without relying on the internal detection of the application system. This can avoid network status judgment errors caused by untimely refresh as much as possible, which helps to improve the accuracy of network status judgment. On the other hand, since the timeout request duration is adaptively determined based on the current network status obtained in advance, and the timeout request duration is positively correlated with the network quality represented by the current network status, that is, the higher the network quality represented by the current network status, the longer the timeout request duration. In a high-quality network, it is possible to wait for a longer time to successfully obtain the feedback result of the network service request. Conversely, the lower the network quality represented by the current network status, the shorter the timeout request duration. In a low-quality network, it is possible to wait for a shorter time to shorten the waiting time as much as possible in a weak network environment, which helps to improve the feedback speed of the application. Therefore, it is possible to improve the accuracy of network status judgment and the feedback speed of the application.

[0056] In some disclosed embodiments, the prediction module 22 includes a first selection submodule, which is used to select the historical network state as the first network state and the historical moment as the first historical moment in the historical network information corresponding to the target application, and to select the historical network state as the second network state and the historical moment as the second historical moment in the historical network information corresponding to the application in the trusted application set; the prediction module 22 includes a second selection submodule, which is used to select the first network state or the second network state as the current network state based on the first historical moment and the second historical moment.

[0057] In some disclosed embodiments, the second selection submodule is specifically used to perform at least one of the following: in response to the elapsed time from at least the first historical moment to the current moment being no greater than a first time threshold, selecting the first network state as the current network state; in response to the elapsed time from only the second historical moment to the current moment being no greater than the first time threshold, selecting the second network state as the current network state.

[0058] In some disclosed embodiments, after the historical network state is determined, the historical network state and the historical time when the historical network state is determined are broadcasted to the application system.

[0059] In some disclosed embodiments, the network detection device 20 includes an acquisition module for obtaining historical network information determined after the target application triggers the network service request based on whether the request feedback result of the target application is obtained within the timeout request duration; the network detection device 20 includes a broadcast module for broadcasting the historical network information determined after the target application triggers the network service request in the application system.

[0060] In some disclosed embodiments, the acquisition module includes a first acquisition sub-module for determining, in response to obtaining a request feedback result within a timeout request duration, that the historical network status of the target application triggering the network service request this time at least includes that the network is available and the historical moment is the acquisition moment of the request feedback result; the acquisition module includes a second acquisition sub-module for determining, in response to not obtaining a request feedback result within a timeout request duration, that the historical network status of the target application triggering the network service request this time at least includes that the network is unavailable and the historical moment is the arrival moment of the timeout request duration.

[0061] In some disclosed embodiments, the prompt module 24 is specifically used to perform at least one of the following: in response to obtaining a request feedback result within a timeout request period, not prompting that the network service request of the target application cannot be responded to at present; in response to not obtaining a request feedback result within a timeout request period, prompting that the network service request of the target application cannot be responded to at present.

[0062] In some disclosed embodiments, the network detection device 20 includes an attribute module for obtaining attribute information of each application in the application system; wherein the attribute information includes: the frequency of use of the application, and whether the application is at least one of the built-in programs of the application system; the network detection device 20 includes a collection module for determining whether to select the application into the trusted application set based on the attribute information of the application.

[0063] In some disclosed embodiments, the network detection device 20 includes a screening module for obtaining, for each application in the trusted application set, a network status sequence of the application based on a historical network status where the time elapsed from a historical moment to a current moment is not greater than a second time threshold; the network detection device 20 includes a first update module for determining whether to remove the application from the trusted application set based on the network status sequence of each application.

[0064] In some disclosed embodiments, the first update module includes a third selection submodule for selecting each application in the trusted application set as the current application, and selecting an application other than the current application in the trusted application set as a reference application; the first update module includes a correlation measurement submodule for obtaining the correlation between the network status sequence of the current application and the network status sequence of the reference application; the first update module includes a removal determination submodule for determining whether to remove the current application from the trusted application set based on a reference application whose correlation with the current application satisfies a correlation condition.

[0065] In some disclosed embodiments, the network detection device 20 includes a detection module for determining, in response to the target application being an application in the trusted application set, whether to detect the network permissions of the target application based on historical network information determined after the target application triggers the network service request this time; the network detection device 20 includes a second update module for determining whether to remove the target application from the trusted application set based on the detection result of the target application regarding the network permissions.

[0066] In some disclosed embodiments, the detection module is specifically used to perform at least one of the following: in response to the historical network status determined after the target application triggers the network service request this time, at least the network is unavailable, determining to detect the network permission of the target application; in response to the historical network status determined after the target application triggers the network service request this time, at least the network is available, determining not to detect the network permission of the target application, and directly not removing the target application from the trusted application set.

[0067] In some disclosed embodiments, the second update module is specifically used to perform at least one of the following: in response to the detection result of the target application regarding networking permissions including that the target application has networking permissions, determining not to remove the target application from the trusted application set; in response to the detection result of the target application regarding networking permissions including that the target application does not have networking permissions, determining to remove the target application from the trusted application set.

[0068] See also Figure 3 , Figure 3 This is a schematic diagram of an embodiment of an electronic device 30 of the present application. The electronic device 30 includes a memory 31 and a processor 32 coupled to each other. The memory 31 stores at least program instructions, and the processor 32 is configured to execute the program instructions to implement the steps of any of the aforementioned network detection method embodiments. For details, please refer to the previously disclosed embodiments and will not be repeated here. The electronic device 30 may include, but is not limited to, a smartphone, a tablet computer, etc., and the specific type of the electronic device 30 is not limited here.

[0069] Specifically, the processor 32 is used to control itself and the memory 31 to implement the steps in any of the above-mentioned network detection method embodiments. The processor 32 can also be called a CPU (Central Processing Unit). The processor 32 may be an integrated circuit chip with signal processing capabilities. The processor 32 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. In addition, the processor 32 can be implemented by an integrated circuit chip.

[0070] In the above scheme, the electronic device 30 implements the steps of any of the above network detection method embodiments. Therefore, on the one hand, because the current network status is predicted based on historical network information determined by the target application itself and the applications within the trusted application set after the most recent network service request was triggered, without relying on the application system's internal detection, network status errors caused by untimely refreshes can be avoided as much as possible, helping to improve the accuracy of network status judgment. On the other hand, because the timeout request duration is adaptively determined based on the predicted current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, that is, the higher the network quality represented by the current network status, the longer the timeout request duration. This allows for a longer wait time to successfully obtain feedback results for the network service request on a high-quality network. Conversely, the lower the network quality represented by the current network status, the shorter the timeout request duration. This allows for a shorter wait time on a low-quality network, minimizing wait times in weak network environments, helping to improve application feedback speed. Therefore, the accuracy of network status judgment and the speed of application feedback can be improved.

[0071] See also Figure 4 , Figure 4 1 is a schematic diagram of a framework of an embodiment of a computer-readable storage medium 40 of the present application. The computer-readable storage medium 40 stores program instructions 41 that can be executed by a processor, and the program instructions 41 are used to implement the steps of any of the above network detection method embodiments.

[0072] In the above scheme, the computer-readable storage medium 40 implements the steps of any of the above network detection method embodiments. Therefore, on the one hand, because the current network status is predicted based on historical network information determined by the target application itself and the applications within the trusted application set after the most recent network service request was triggered, without relying on the application system's internal detection, network status errors caused by untimely refreshes can be avoided as much as possible, helping to improve the accuracy of network status judgment. On the other hand, because the timeout request duration is adaptively determined based on the predicted current network status, and the timeout request duration is positively correlated with the network quality represented by the current network status, that is, the higher the network quality represented by the current network status, the longer the timeout request duration. This allows for a longer wait time to successfully obtain feedback results for the network service request on a high-quality network. Conversely, the lower the network quality represented by the current network status, the shorter the timeout request duration. This allows for a shorter wait time on a low-quality network, minimizing wait times in weak network environments, helping to improve application feedback speed. Therefore, the accuracy of network status judgment and the speed of application feedback can be improved.

[0073] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments. For the sake of brevity, it will not be repeated here.

[0074] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced with each other and will not be repeated herein for the sake of brevity.

[0075] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation methods described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0076] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0077] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0078] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0079] If the technical solution of this application involves personal information, the product that applies the technical solution of this application has clearly informed the personal information processing rules and obtained the individual's voluntary consent before processing personal information. If the technical solution of this application involves sensitive personal information, the product that applies the technical solution of this application has obtained the individual's separate consent before processing sensitive personal information, and at the same time meets the "explicit consent" requirement. For example, on personal information collection devices such as cameras, a clear and prominent sign is set to inform that the personal information collection scope has been entered and personal information will be collected. If the individual voluntarily enters the collection scope, it is deemed that they agree to the collection of their personal information; or on the personal information processing device, when the personal information processing rules are notified by obvious signs / information, the individual's authorization is obtained through pop-up information or by asking the individual to upload their personal information; among which, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the type of personal information processed.

Claims

1. A network detection method, characterized in that: include: Select the application that currently triggers the network service request as the target application; Predicting a current network state based on historical network information determined after the target application and the application program in the trusted application set each recently triggered the network service request; wherein the historical network information includes a historical network state and a historical moment when the historical network state was determined; Determining a timeout request duration of the target application based on the current network state; wherein the timeout request duration is positively correlated with a network quality represented by the current network state; Based on whether the request feedback result of the target application is obtained within the timeout request duration, it is determined whether it is prompted that the network service request of the target application cannot be responded to at present.

2. The method according to claim 1, characterized in that The predicting of the current network status based on historical network information respectively determined after the target application and the application program in the trusted application set recently triggered the network service request includes: In the historical network information corresponding to the target application, the historical network state is selected as the first network state and the historical moment is selected as the first historical moment; and in the historical network information corresponding to the application program in the trusted application set, the historical network state is selected as the second network state and the historical moment is selected as the second historical moment; Based on the first historical moment and the second historical moment, the first network state or the second network state is selected as the current network state.

3. The method according to claim 2, characterized in that The selecting, based on the first historical moment and the second historical moment, the first network state or the second network state as the current network state includes at least one of the following: In response to at least an elapsed time from the first historical moment to the current moment being no greater than a first time threshold, selecting the first network state as the current network state; In response to the fact that only the elapsed time from the second historical moment to the current moment is not greater than the first time threshold, the second network state is selected as the current network state.

4. The method according to claim 1, wherein After the historical network state is determined, the historical network state and the historical moment when the historical network state is determined are broadcasted in the application system.

5. The method according to claim 1, wherein The method further comprises: Based on whether a request feedback result of the target application is obtained within the timeout request duration, obtaining historical network information determined after the target application triggers the network service request this time; In the application system, the historical network information determined after the target application triggers the network service request this time is broadcasted.

6. The method according to claim 5, characterized in that The obtaining of historical network information determined after the target application triggers the network service request based on whether the request feedback result of the target application is obtained within the timeout request duration includes at least one of the following: In response to obtaining the request feedback result within the timeout request duration, determining that a historical network state of the target application triggering the network service request at least includes that the network is available and the historical moment is the moment of obtaining the request feedback result; In response to not obtaining the request feedback result within the timeout request duration, determining that the historical network status of the target application triggering the network service request this time at least includes that the network is unavailable and the historical moment is the time when the timeout request duration expires.

7. The method according to claim 1, characterized in that The determining whether to prompt that the network service request of the target application cannot be responded to based on whether the request feedback result of the target application is obtained within the timeout request duration includes at least one of the following: In response to obtaining the request feedback result within the timeout request duration, no prompt is given that the network service request of the target application cannot be responded to at present; In response to not obtaining the request feedback result within the timeout request duration, it is prompted that the network service request of the target application cannot be responded to at present.

8. The method according to claim 1, characterized in that The trusted application set initialization step includes: Acquire attribute information of each application in the application system; wherein the attribute information includes: at least one of the frequency of use of the application and whether the application is a built-in program of the application system; Based on the attribute information of the application, it is determined whether to select the application into the trusted application set.

9. The method according to claim 1, characterized in that The method further comprises: For each of the applications in the trusted application set, obtaining a network state sequence of the application based on a historical network state where the elapsed time from the historical moment to the current moment is not greater than a second time threshold; Based on the network status sequence of each of the application programs, it is determined whether to remove the application program from the trusted application set.

10. The method according to claim 9, characterized in that The determining whether to remove the application from the trusted application set based on the network status sequence of each application includes: Selecting each of the applications in the trusted application set as a current application, and selecting applications other than the current application in the trusted application set as reference applications; Obtaining a correlation between the network state sequence of the current application and the network state sequence of the reference application; Based on a reference application whose correlation with the current application satisfies a correlation condition, it is determined whether to remove the current application from the trusted application set.

11. The method according to claim 1, wherein The method further comprises: In response to the target application being the application program in the trusted application set, determining whether to detect the network permission of the target application based on historical network information determined after the target application triggers the network service request this time; Based on a detection result of the target application regarding the networking permission, it is determined whether to remove the target application from the trusted application set.

12. The method according to claim 11, characterized in that The determining whether to detect the network permission of the target application based on the historical network information determined after the target application triggers the network service request this time includes at least one of the following: In response to the historical network status determined after the target application triggers the network service request this time including at least network unavailable, determining to detect the network permission of the target application; In response to the historical network status determined after the target application triggers the network service request this time at least including that the network is available, it is determined not to detect the network permission of the target application, and the target application is not directly removed from the trusted application set.

13. The method according to claim 11, characterized in that The determining whether to remove the target application from the trusted application set based on the detection result of the target application regarding the networking permission includes at least one of the following: In response to the detection result of the target application regarding the networking permission including that the target application has the networking permission, determining not to remove the target application from the trusted application set; In response to the detection result of the target application regarding the networking permission including that the target application does not have the networking permission, determining to remove the target application from the trusted application set.

14. A network detection device, characterized in that: include: A selection module is used to select the application that currently triggers the network service request as the target application; a prediction module, configured to predict a current network state based on historical network information determined after the target application and the application program in the trusted application set each recently triggered the network service request; wherein the historical network information includes a historical network state and a historical moment when the historical network state was determined; A determination module, configured to determine a timeout request duration of the target application based on the current network state; wherein the timeout request duration is positively correlated with a network quality represented by the current network state; The prompt module is used to determine whether to prompt that the network service request of the target application cannot be responded to at present based on whether the request feedback result of the target application is obtained within the timeout request duration.

15. An electronic device, characterized in that: The method comprises at least a memory and a processor coupled to each other, wherein the memory stores at least program instructions, and the processor is used to execute the program instructions to implement the network detection method according to any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that Program instructions that can be executed by a processor are stored, and the program instructions are used to implement the network detection method according to any one of claims 1 to 13.

Images