Method, device, storage medium and electronic device for starting application

Abstract

The application discloses a kind of application starting method, storage medium and electronic device, the application starting method includes: in the case where application starts, determine whether the application is first started;In the case where it is determined that the application is not first started, read the access token used by user login in the process of last time starting the application in the local cache of the application;In the case where the access token is still within the validity period and the remaining time of the validity period is less than or equal to time threshold, skip the login page of the application to display the home page of the application, and verify the access token in the background.The quick identification for non-first start avoids repeated login verification, directly enters the home page of the application, improves the starting speed and user experience.Even if the login page is skipped, the asynchronous verification process in the background can still ensure the validity and security of the access token, and maintain the overall stability of the system.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method, apparatus, storage medium, and electronic device for launching an application. Background Technology

[0002] In today's mobile internet era, mobile applications (Apps) have become an indispensable part of people's daily lives. People's demands for the user experience of Apps are also increasing, and a key factor affecting the user experience is the App's launch speed.

[0003] However, apps using this technology experience significant startup delays and consume a lot of network resources. Summary of the Invention

[0004] This invention provides a method and apparatus for application startup, a storage medium, and an electronic device to at least solve the problems of large application startup delays and high resource consumption in related technologies.

[0005] According to one embodiment of the present invention, a method for launching an application is provided, comprising: determining whether the application is being launched for the first time when the application is launched; if the application is not being launched for the first time, reading the access token used by the user to log in during the previous launch of the application from the local cache of the application; if the access token is still valid and the remaining time of the validity period is less than or equal to a time threshold, skipping the login page of the application to display the homepage of the application, and verifying the access token in the background.

[0006] In one exemplary embodiment, verifying the access token includes: sending the access token to a server, wherein the server verifies the validity of the access token after receiving it; receiving a verification result from the server, wherein the verification result indicates whether the access token has passed verification; and refreshing the validity period of the access token if it is determined that the access token has passed verification.

[0007] In one exemplary embodiment, the method further includes: if no verification result indicating that the access token verification has passed is received, determining the operation behavior triggered by the target object in the application; if the operation behavior is determined to be a preset non-sensitive operation behavior, performing a corresponding action in response to the operation behavior of the target object; if the operation behavior is determined to be a preset sensitive operation behavior, issuing a prompt message to the target object to wait for verification and providing the target object with a manual verification page; and if the access token verification passes or the target object's manual verification passes, performing a corresponding action in response to the sensitive operation behavior of the target object.

[0008] In one exemplary embodiment, the method further includes: if the expiration time of the access token is obtained, calculating the time difference between the current time and the expiration time to determine the remaining time of the validity period; if the remaining time is greater than the time threshold, skipping the login page of the application and displaying the homepage of the application; if the remaining time is less than or equal to zero, determining whether a secondary access token exists in the local cache of the application, wherein the validity period of the secondary access token is greater than the validity period of the access token; if it is determined that the secondary access token exists in the local cache of the application and the secondary access token has not expired, skipping the login page of the application and displaying the homepage of the application, and verifying the access token in the background; if it is determined that the secondary access token does not exist in the local cache of the application, or that the secondary access token exists and the secondary access token has expired, displaying the login page of the application.

[0009] In one exemplary embodiment, the method further includes: generating a refresh request for the access token if the access token verification passes; detecting whether the application has an ongoing refresh task; if it is determined that the application has an ongoing refresh task, placing the refresh request for the access token into a waiting queue to suspend initiating the refresh request for the access token to the server; if the application obtains the refresh result of the access token, sharing the refresh result with the refresh requests in the waiting queue; if it is determined that the application does not have an ongoing refresh task, initiating a refresh request for the access token to the server.

[0010] In one exemplary embodiment, the method further includes: determining the network connection status of the application; if the network connection status of the application is offline, and the access token is still valid, then skipping the login page of the application and displaying the offline cache page; if it is determined that the operation triggered by the target object requires obtaining real-time data, reminding the target object to wait for the network to recover and then retry.

[0011] In one exemplary embodiment, the method further includes: collecting historical startup information of the application and monitoring network quality data of the application; predicting the timing of access token usage based on the historical startup information; predicting the network state at the time of access token usage based on the timing of access token usage and the network quality data; determining whether there is a blocking risk when the access token is used based on the remaining validity period of the access token, the timing of access token usage, and the predicted network state at the time of access token usage, wherein the blocking risk includes access token expiration and / or abnormal network state; and adjusting the time threshold according to the blocking risk to adjust the refresh timing of the access token if it is determined that there is a blocking risk when the access token is used.

[0012] According to another embodiment of the present invention, an application launching device is also provided, comprising: The startup determination module is used to determine whether the application is being launched for the first time when the application is launched. The token reading module is used to read the access token used by the user to log in during the previous launch of the application from the local cache of the application if it is determined that the application is not being launched for the first time. The execution module is started to skip the application's login page and display the application's homepage when the access token is still valid and the remaining time of the validity period is less than or equal to a time threshold, and to verify the access token in the background.

[0013] According to another aspect of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, wherein the computer program is configured to execute the above-described application startup method at runtime.

[0014] According to another aspect of the present invention, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the application startup method described above through the computer program.

[0015] The aforementioned application launch method, by quickly identifying non-first-time launches, avoids repeated login verifications and directly leads to the application's homepage, improving launch speed and user experience. Based on time threshold judgments, it reduces useless requests to the server within the validity period, effectively controlling network traffic and server resource consumption. Furthermore, even if the login page is skipped, the asynchronous verification process in the background still ensures the validity and security of the access token, maintaining overall system stability. In summary, by intelligently identifying the launch type at application startup, prioritizing the reading of access tokens stored in the local cache, and implementing asynchronous background verification within the token's validity range, the method effectively reduces launch latency and resource consumption. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the hardware environment for an application startup method according to an embodiment of this application; Figure 2 This is a flowchart of an application startup method according to an embodiment of the present invention; Figure 3 This is a second flowchart of an application startup method according to an embodiment of the present invention; Figure 4 This is the third flowchart of the application startup method according to an embodiment of the present invention; Figure 5 This is the fourth flowchart of the application startup method according to an embodiment of the present invention; Figure 6 This is the fifth flowchart of the application startup method according to an embodiment of the present invention; Figure 7 This is a flowchart of the application startup method according to an embodiment of the present invention; Figure 8 This is the seventh flowchart of the application startup method according to an embodiment of the present invention; Figure 9 This is a structural block diagram of an application launch device according to an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] According to one aspect of the embodiments of this application, a method for launching an application is provided. This application launching method is widely applicable to whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned interaction method for smart home devices can be applied to, for example... Figure 1 The hardware environment shown consists of terminal device 102 and server 104. For example... Figure 1 As shown, server 104 is connected to terminal device 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0022] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0023] As described in the background section, apps in related technologies often experience significant startup delays and high network resource consumption. This is because the startup process of these apps is often overly cumbersome, especially on subsequent startups. Even though users may possess valid login credentials, such as access tokens, many applications still adhere to a conservative security strategy: immediately sending a login status verification or token refresh request to the server each time the application starts. In poor network conditions or with slow server response, waiting for the interface to return a result leads to significant startup delays, directly impacting user experience. Performing a complete token verification or refresh on every startup incurs additional network traffic consumption and server-side computational burden. Furthermore, this strict synchronization mechanism creates a rigid dependency between the client and server; the client must wait for a server response before continuing the subsequent initialization process, limiting the potential for improving startup efficiency. This, in turn, affects user experience; startup delays may cause users to question the application's performance and reliability, impacting user retention. Even small delays can accumulate into a significant negative experience, especially given the high expectations modern users have for instant responsiveness. In conclusion, significant startup delays and high resource consumption have become major factors restricting the performance, efficiency, and user experience of mobile applications. The above issues need to be addressed in the design of mobile applications that strive for a seamless experience and high performance.

[0024] This embodiment provides a method for launching an application, applied to the aforementioned terminal device. Figure 2 This is a flowchart of an application startup method according to an embodiment of the present invention, the process including the following steps S200-S220: Step S200: If the application is launched, determine whether it is the first time it is launched.

[0025] Specifically, in the initial stage of application startup, the system needs to determine whether the current startup process is the first launch. The processing logic for first launches and non-first launches differs significantly. First launches may require performing more initialization tasks, while non-first launches can utilize previously saved login state and data to launch the application more efficiently. By identifying first and non-first launches, the system can optimize the startup process accordingly, reducing the consumption of network and server resources. In the case of non-first launches, the system can directly utilize the saved state to quickly enter the application, improving the user experience.

[0026] For example, upon startup, an application can determine whether it's its first launch by checking if a record related to the login state exists in local storage. For instance: Reading local flags: Look for a flag indicating the launch state, such as `isFirstLaunch`, in the application's local storage (e.g., SharedPreferences on Android, UserDefaults on iOS). Determining the flag's state: If the `isFirstLaunch` flag exists and its value is true, it indicates a first launch; otherwise, if the flag does not exist or its value is false, it's considered a non-first launch. After the first launch, the value of `isFirstLaunch` is updated to false to ensure that subsequent launches can recognize it as a non-first launch.

[0027] Step S210: If it is determined that the application is not being launched for the first time, read the access token used by the user to log in during the application's last launch from the application's local cache.

[0028] Specifically, when it is confirmed that the application is not being launched for the first time, the system should immediately read the access token saved after the user's last successful login from the local cache. This aims to quickly access the application using existing credentials and avoid unnecessary network requests. By directly reading the locally saved access token, the system can avoid unnecessary synchronous login verification at application startup, significantly reducing startup latency and resource consumption.

[0029] For example, access token information is read from the application's local secure storage (such as Android's Keystore system or iOS's Keychain service). The read token string is parsed into a TokenRecord structure, containing key fields such as accessToken, refreshToken, and exp.

[0030] An access token is a short-term, valid form of identification used to prove to the API server that the client has legitimate access rights. The local cache is a temporary data area in the application's local storage for fast access. A TokenRecord is a data structure containing the access token and related state information, such as expiration time and refresh token.

[0031] In step S220, if the access token is still valid and the remaining validity period is less than or equal to the time threshold, skip the application's login page to display the application's homepage and verify the access token in the background.

[0032] Specifically, if the locally read access token has not expired and its remaining validity period is less than or equal to a preset time threshold, the system will skip the login page, display the application's homepage, and asynchronously verify the access token's validity in the background. By performing asynchronous verification in the background, the system ensures that applications not launched for the first time can quickly display the homepage, while maintaining login security and credential validity without blocking user operations. This mechanism significantly shortens startup time, reduces network resource consumption, and improves user experience.

[0033] For example, validity determination: The remaining validity period (TTL) of the access token is calculated by subtracting the current time from the token's expiration time (exp), thus determining whether the token is valid. Skip login page: If TTL > Δ (where Δ is a time threshold), the homepage rendering process is initiated directly, without the user seeing the login interface. Background verification: While the homepage is loading, an asynchronous token verification request is initiated to ensure the token's legality and validity. If verification fails, it is processed in the background or the user is prompted to log in again.

[0034] In this embodiment, rapid identification upon non-first-time launches avoids repeated login verifications, allowing direct access to the application's homepage and improving startup speed and user experience. Time-threshold-based judgment reduces unnecessary requests to the server within the validity period, effectively controlling network traffic and server resource consumption. Even if the login page is skipped, the background asynchronous verification process still ensures the validity and security of the access token, maintaining overall system stability. By intelligently identifying the startup type upon application startup, prioritizing the reading of access tokens stored in the local cache, and implementing background asynchronous verification within the token's validity range, the effects of reducing startup latency and resource consumption are achieved.

[0035] In one embodiment, such as Figure 3 As shown, step S220 verifies the access token. This includes steps S300-S330, wherein: Step S300: Send an access token to the server.

[0036] The server verifies the validity of the access token upon receiving it.

[0037] Specifically, when a mobile application client launches the app for the first time and the access token is deemed valid but nearing expiration, it sends the locally stored access token to the server for verification. Upon receiving the access token, the server checks its validity, signature, and any signs of tampering to ensure the client's credentials are legitimate and valid. Through server-side verification of the access token, the mobile application can confirm the user's continued login status, thus providing a seamless user experience while ensuring application security.

[0038] Step S310: Receive the verification result from the server.

[0039] The verification result indicates whether the access token has passed verification.

[0040] Specifically, after sending the access token, the client waits for a response from the server, receives and parses the verification result in the response to determine whether the token has passed the server's security verification. This step is crucial in determining the client's subsequent actions, such as whether to refresh the token or prompt the user to log in again. The validity of the access token is determined based on the response status code. For example, 200 OK indicates the token is valid and can be used; 401 Unauthorized indicates the token is invalid or expired, and further action may be required.

[0041] Step S320: If the access token verification is successful, refresh the validity period of the access token.

[0042] Specifically, if the server confirms that the access token is valid but nearing expiration, the client will immediately execute a token refresh process to extend its validity. This operation is performed asynchronously in the background and does not affect the application interface being used by the user. By refreshing the access token's validity in the background, the client can ensure that the user always has the latest and valid credentials to access server resources while seamlessly using the application. This method avoids frequent interruptions to the user during application use, improving the experience, and enhances application security by reducing the use of invalid credentials.

[0043] In this embodiment, server-side verification ensures the validity of the access token, while background refresh on the client side avoids interference with the user flow, improving application efficiency and experience. Users can continue using the application without having to log in again, and even if the access token is about to expire, it can be automatically refreshed in the background to maintain session continuity. The background refresh mechanism reduces unnecessary network requests and server computing resource consumption, especially when the access token is within its validity period but close to expiration, enabling more intelligent resource management.

[0044] In one embodiment, such as Figure 4 As shown, the method further includes steps S400-S430, wherein: Step S400: If no verification result indicating that the access token verification has passed is received, determine the operation behavior triggered by the target object in the application.

[0045] Specifically, when the application starts and attempts to asynchronously verify the locally stored access token, if no response confirming the token's validity is received from the server within a short period, the system needs to detect and categorize the target user's (target object's) actions within the application. This step is to determine whether to execute an action immediately or wait for the verification result based on different levels of action. By distinguishing between different types of user actions, the system can continue to support the use of non-sensitive functions for a limited time before receiving a verification success indication, while sensitive functions are temporarily suspended or require waiting for verification to complete, effectively balancing the needs of functionality and security.

[0046] For example, event listening: Implement an event listening mechanism at each interaction layer of the application to capture all user-triggered actions. Action classification: Based on preset criteria, actions are divided into two main categories: non-sensitive and sensitive. For example, browsing product details and reading news are considered non-sensitive actions, while making payments, transferring funds, and modifying account information are considered sensitive actions.

[0047] Non-sensitive operations are those that have minimal impact on a user's account or financial status and can be performed without full identity verification. Sensitive operations are those that may involve high-risk functions such as user privacy leaks or fund security and can only be performed after full identity verification.

[0048] Step S410: If it is determined that the operation behavior belongs to the preset non-sensitive operation behavior, the corresponding action is executed in response to the operation behavior of the target object.

[0049] Specifically, if the detected operation is of a non-sensitive type, the mobile application will immediately respond and execute the corresponding function, such as loading product details or displaying a news list, even before the access token verification result is returned. By responding instantly to non-sensitive operations, the application can provide some functions and services while waiting for access token verification, significantly reducing user waiting time and improving user experience.

[0050] For example, for non-sensitive operations, the system directly responds to user input and triggers the corresponding functional flow without waiting for the access token verification result. To improve response speed, locally cached data can be used to populate the interface, and the latest data can be retrieved and refreshed after successful verification.

[0051] Step S420: If it is determined that the operation behavior belongs to the preset sensitive operation behavior, a prompt message for waiting for verification is sent to the target object, and a manual verification page is provided to the target object.

[0052] Specifically, when the system detects an operation as sensitive, the application will pause its function and send a clear verification prompt to the user, while also displaying a manual verification page where the user can enter their account password or other identity information for verification. By providing clear prompts and manual verification options, the application enhances the user's right to know and sense of control, while ensuring that high-risk operations are not performed before the user's identity is fully verified, thus maintaining the application's security.

[0053] Step S430: If the access token verification is successful or the target object is manually verified, execute the corresponding action in response to the sensitive operation behavior of the target object.

[0054] Specifically, once the access token verification result is returned and confirmed to be valid, or the user verifies their identity through a manual verification process, the system removes the restrictions on sensitive operations, allowing the user to perform high-risk operations, including payments and transfers.

[0055] In this embodiment, during the uncertain period of waiting for the access token verification result, non-sensitive functions with immediate response are provided to ensure that the user experience is not excessively affected, while sensitive operations are handled with care to protect user privacy and financial security. The design of a manual verification option allows users to proactively expedite the verification process for sensitive operations according to their own circumstances, improving the system's operational flexibility and personalized experience. Immediate response to non-sensitive operations reduces unnecessary waiting time, while temporary restrictions on sensitive operations avoid resource waste in unverified states, ensuring the rationality and efficiency of application function execution.

[0056] In one embodiment, such as Figure 5As shown, the method further includes steps S500-S540, wherein: Step S500: If the expiration time of the access token is obtained, calculate the time difference between the current time and the expiration time to determine the remaining validity period.

[0057] Specifically, after the mobile application reads the local access token and parses out the expiration time information it contains, the system performs a time difference calculation to determine how much time the access token is valid for. This step is the foundation of subsequent decision-making processes and will directly affect whether the application can skip the login page and directly display the homepage.

[0058] For example, the `exp` field in the access token is read, which is the expiration timestamp (Unix timestamp format). The current system time is subtracted from the expiration timestamp to obtain the TTL (Time To Live), which is the remaining validity period of the access token. To ensure the accuracy of time calculation, time synchronization may be required between the client and server to correct for clock skew.

[0059] In step S510, if the remaining time is greater than the time threshold, skip the application's login page and display the application's homepage.

[0060] Specifically, if the calculated remaining validity period of the access token is greater than the preset time threshold, the mobile application will consider the access token to be still valid, and can directly skip the login process, display the application's homepage, allow users to start using the application immediately, and the remaining validity period is long, so there is no need to perform asynchronous verification in the background.

[0061] Step S520: If the remaining time is less than or equal to zero, determine whether a second-level access token exists in the application's local cache.

[0062] The validity period of the secondary access token is longer than that of the primary access token.

[0063] Specifically, if the remaining validity period of the access token is less than or equal to zero, it means the access token has expired. In this case, the system needs to further check whether there is a secondary access token with a longer validity period to attempt to quickly restore the user's login status. By checking the secondary access token, the system can quickly attempt to restore the login status after the access token expires, avoiding a complete re-login process and improving the user experience.

[0064] The secondary access token check is a long-term valid credential used to obtain a new access token when the old one expires. The secondary access token can be valid for one month, while the regular access token can be valid for seven days.

[0065] In step S530, if it is determined that a secondary access token exists in the application's local cache and the secondary access token has not expired, the application's login page is skipped to display the application's homepage, and the access token is verified in the background.

[0066] Specifically, if an expired secondary access token is found in the local cache, the system will allow the user to skip the login page and directly access the homepage. At the same time, the system will initiate a verification and refresh process for the access token in the background to ensure the continuity of the user's login status.

[0067] In step S540, if it is determined that there is no second-level access token in the application's local cache, or if there is a second-level access token but it has expired, the application's login page is displayed.

[0068] Specifically, when there is neither a valid access token nor a usable secondary access token in the local cache, the system will require the user to re-authenticate through the login page in order to generate a new access token and a possible secondary access token.

[0069] In this embodiment, by comparing the remaining validity period of the access token with a time threshold, it is possible to quickly determine whether the login process can be skipped and the user can directly enter the application homepage, significantly reducing the user's application launch waiting time. When the access token expires, the system automatically checks the existence and validity of the secondary access token and refreshes the access token in the background using the secondary access token, avoiding unnecessary re-login, providing a seamless user experience, and reducing network resource consumption. Even if the access token expires and the secondary access token is non-existent or expired, the system does not compromise security but requires the user to re-verify their identity through the login page, ensuring the overall security of the system and the protection of the user's personal information.

[0070] In one embodiment, such as Figure 6 As shown, the method further includes steps S600-S640, wherein: Step S600: If the access token verification passes, generate an access token refresh request.

[0071] Specifically, when the client receives a response from the server confirming the validity of the access token, in order to ensure the continued availability of the token, the system needs to automatically generate a new token refresh request to extend the validity period of the access token.

[0072] Step S610: Detect whether the application has a refresh task in progress.

[0073] Specifically, to avoid sending multiple refresh requests simultaneously, which would waste network resources and increase server load, the system needs to detect whether there are currently any ongoing refresh tasks. By detecting the existence of ongoing refresh tasks, the system can avoid multiple concurrent refresh requests, reduce unnecessary network traffic consumption and server-side processing pressure, and optimize resource utilization efficiency.

[0074] Step S620: If it is determined that there is an ongoing refresh task in the application, the refresh request for the access token is placed in the waiting queue to suspend the refresh request for the access token to be sent to the server.

[0075] Specifically, if an existing refresh task is detected, new refresh requests will be temporarily suspended and placed in a waiting queue until the current refresh task is completed, at which point the requests in the queue will be processed sequentially. Managing refresh requests through a waiting queue ensures that the refresh process proceeds in an orderly manner, avoids refresh storms, reduces instantaneous pressure on the server, and guarantees that all refresh requests will eventually be processed.

[0076] For example, design a refresh request queue, adding newly generated refresh requests to the end of the queue. Mark refresh requests in the queue as pending to avoid sending them to the server immediately.

[0077] The waiting queue is a first-in-first-out (FIFO) data structure used to temporarily store refresh requests that are waiting to be executed.

[0078] Step S630: If the application obtains the refresh result of the access token, the refresh result is shared with the refresh requests in the waiting queue.

[0079] Specifically, once a refresh request succeeds and obtains a new access token from the server, the system must share the latest token information with other refresh requests waiting in the queue to avoid repeatedly refreshing the same token. Sharing refresh results prevents refresh requests in the queue from being sent repeatedly, reduces the number of network requests, optimizes the use of server resources, and ensures that all components can use the latest valid access token, thereby improving the overall efficiency and security of the system.

[0080] Step S640: If it is determined that there is no ongoing refresh task in the application, a refresh request for the access token is sent to the server.

[0081] Specifically, if the system detects that no ongoing refresh task is in progress, it can directly send a new access token refresh request to the server to obtain an updated access token. Initiating a refresh directly when there are no concurrent requests allows for a quick response to token expiration, ensuring that users always have the latest access token, thus improving system responsiveness and the smoothness of user operations.

[0082] In this embodiment, by detecting and managing ongoing refresh tasks, redundant network requests and server processing are avoided, reducing resource consumption. This optimization is particularly significant under conditions of concurrent requests and weak network conditions. Automated and background execution of refresh requests ensures the validity of access tokens, avoids interruptions during user operation, and improves the continuity and satisfaction of the user experience. Utilizing a waiting queue and refresh result sharing mechanism ensures the orderly progress of the refresh process, maintaining system responsiveness and stability even in high-concurrency environments.

[0083] In one embodiment, such as Figure 7 As shown, the method further includes steps S700-S720, wherein: Step S700: Determine the network connection status of the application.

[0084] Specifically, when an application starts or a user performs an operation, the system needs to detect the current network connection status to determine whether it is online or offline. This is crucial for deciding on subsequent processing procedures. By detecting the network connection status in real time, the system can make corresponding adjustments when network conditions are poor, such as providing an offline cached page or prompting the user to wait for the network to recover. This avoids invalid operations when the network is inaccessible and improves the user experience under various network conditions.

[0085] In step S710, if the application's network connection status is offline and the access token is still valid, the application's login page is skipped and the offline cache page is displayed.

[0086] Specifically, if the application is detected to be offline, but the locally stored access token is still valid, the system will skip the login process and directly access the offline cache page, allowing users to continue using some functions even without a network connection. By skipping the login page and displaying the offline cache page, users can continue to use some application functions, such as viewing cached news or product information, even when offline. This greatly improves the app's usability and user experience in weak or no network environments.

[0087] Step S720: If it is determined that the operation triggered by the target object requires real-time data, remind the target object to wait for the network to recover and then retry.

[0088] Specifically, if the operation triggered by the target user (such as payment, online shopping, etc.) requires real-time network data and the user is currently offline, the system will prompt the user and suggest waiting for the network to be restored before attempting the operation again.

[0089] For example, all user actions in the application are marked as either real-time or non-real-time actions, with real-time actions requiring network data updates. When a user attempts a real-time action, a dialog box or prompt message appears, informing the user that they are currently offline and unable to obtain real-time data, suggesting they retry when a network connection is available.

[0090] In this embodiment, the system can intelligently determine the current network connection status and respond accordingly, such as displaying an offline cached page or reminding the user of operation restrictions. Within the access token's validity period, even when the network is offline, the user can still access pre-cached content, improving the application's availability in weak or no-network environments and meeting user needs in various scenarios. For operations requiring real-time network data, the system guides the user to perform the operation when a network connection is available through user prompts, avoiding operation failures due to network issues and improving the success rate and user experience.

[0091] In one embodiment, such as Figure 8 As shown, the method further includes steps S800-S840, wherein: Step S800: Collect historical startup data of the application and network quality data of the application.

[0092] Specifically, in order to predict when access tokens will be used and the network conditions at that time, the system needs to collect application startup history data and real-time network quality information, including startup frequency, startup time, network latency, packet loss rate, etc. By collecting startup history and network quality data, the system can build a comprehensive user usage and network environment model, providing a rich data foundation for subsequent predictive analysis and helping to optimize access token usage strategies and network resource management.

[0093] For example, upon application startup, record the startup time, startup environment (such as device model and operating system version), and network quality metrics at startup. Use network quality monitoring tools (such as NetInfo or NetworkQualityEstimator) to continuously capture data such as network latency, packet loss rate, and connection type (WiFi / 4G / 5G). Store the collected information in a local database or log file for subsequent analysis and prediction.

[0094] Step S810: Predict the timing of access token usage based on historical startup data.

[0095] Specifically, by utilizing historical startup data and employing data analysis models, the system can predict when users might need to use access tokens, allowing for advance preparation and optimization of the access token refresh process. Predicting when access tokens will be used helps the system accurately refresh tokens when needed, avoiding unnecessary refresh operations, saving network resources, reducing the risk of congestion due to expired access tokens, and optimizing the user experience.

[0096] For example, time series forecasting algorithms (such as ARIMA and Prophet) can be used to analyze user launch behavior patterns and predict future launch times. A machine learning model based on historical data, such as a random forest or neural network, is constructed. Inputs include features such as launch time, device status, and network environment; the output is the probability or time prediction of when the user launches the application. After analyzing historical data, a set of rules based on time, location, and network status is developed to determine the optimal timing for using access tokens.

[0097] Step S820: Predict the network state when the access token is used based on the timing of access token use and network quality data.

[0098] Specifically, by combining access token usage timing prediction with real-time network quality data, the system can predict the network environment when a user performs a critical operation and determine whether it is suitable to refresh the access token. By predicting the network state when the access token is used, the system can intelligently determine whether to refresh the token in the current network environment, avoiding the risk of blocking and failure caused by refreshing the access token in a weak network environment, and improving the efficiency and success rate of the entire refresh process.

[0099] For example, a predictive model is trained using collected network quality data and user initiation behavior to predict the possible state of the network at a specific point in time. The network quality data is mapped to different network state categories (such as "good", "average", "poor"), and the access token refresh strategy is adjusted based on the classification results.

[0100] Step S830: Based on the remaining validity period of the access token, the timing of the access token's use, and the predicted network status at the time of access token use, determine whether there is a risk of blocking when the access token is used.

[0101] Among the risks of congestion are expired access tokens and / or abnormal network conditions.

[0102] Specifically, by combining the access token's validity period, usage predictions, and predicted network conditions, the system assesses whether users might encounter interruptions due to expired tokens or network anomalies when using access tokens for critical operations. By assessing congestion risks, the system can proactively prevent and reduce interruptions and failures in access token usage, ensuring the validity of access tokens and network availability when users perform critical operations, thereby improving the continuity and satisfaction of the user experience.

[0103] For example, different thresholds can be set based on the risk assessment results. When the risk level exceeds the threshold, preventive measures can be taken, such as refreshing the access token in advance or reminding the user to check the network connection.

[0104] Step S840: If it is determined that there is a risk of blocking when the access token is used, the time threshold is adjusted according to the risk of blocking in order to adjust the refresh timing of the access token.

[0105] Specifically, if a blocking risk is assessed, the system will dynamically adjust the access token refresh time threshold according to the severity of the risk, so as to advance or postpone the refresh operation and reduce the risk.

[0106] For example, the risk assessment algorithm includes a threshold adjustment module that adjusts the refresh trigger time based on network state predictions and the access token's validity period. The adjusted threshold is then applied to the access token refresh policy to ensure that the refresh operation is performed at the most appropriate time.

[0107] In this embodiment, by collecting and analyzing historical startup data and network quality information, the system can predict when to use the access token and the network status at that time, intelligently adjust the refresh strategy, reduce unnecessary refresh operations, and lower network resource consumption. Assessing the blocking risk during access token use and advancing or postponing refresh operations effectively prevents users from encountering access token expiration or network anomalies during critical operations, improving the continuity and satisfaction of the user experience. The intelligent access token refresh strategy and network status prediction ensure the validity of the access token under any network conditions, enhancing the stability and reliability of the system and providing users with a smoother and more secure application environment.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0109] Figure 9 This is a structural block diagram of an application launching device according to an embodiment of the present invention. Figure 9 As shown, it includes: The startup determination module 901 is used to determine whether the application is being launched for the first time when the application is started.

[0110] The token reading module 902 is used to read the access token used by the user during the previous startup of the application from the application's local cache if it is determined that the application is not being launched for the first time.

[0111] The execution module 903 is started to skip the application's login page and display the application's homepage, and to verify the access token in the background, provided that the access token is still valid and the remaining validity period is less than or equal to the time threshold.

[0112] In one exemplary embodiment, the apparatus is further configured to: send an access token to a server, wherein the server verifies the validity of the access token upon receiving it; receive a verification result from the server, wherein the verification result indicates whether the access token has passed verification; and, if the access token has passed verification, refresh the validity period of the access token.

[0113] In one exemplary embodiment, the apparatus is further configured to: determine the operation behavior triggered by the target object in the application if no verification result indicating that the access token verification has passed is received; if the operation behavior is determined to be a preset non-sensitive operation behavior, execute a corresponding action in response to the target object's operation behavior; if the operation behavior is determined to be a preset sensitive operation behavior, issue a prompt message to the target object indicating that verification is pending and provide the target object with a manual verification page; and if the access token verification is successful or the target object's manual verification is successful, execute a corresponding action in response to the target object's sensitive operation behavior.

[0114] In one exemplary embodiment, the apparatus is further configured to: upon obtaining the expiration time of an access token, calculate the time difference between the current time and the expiration time to determine the remaining validity period. If the remaining time is greater than a time threshold, skip the application's login page and display the application's homepage. If the remaining time is less than or equal to zero, determine whether a secondary access token exists in the application's local cache, wherein the validity period of the secondary access token is greater than the validity period of the access token. If it is determined that a secondary access token exists in the application's local cache and the secondary access token has not expired, skip the application's login page and display the application's homepage, and verify the access token in the background. If it is determined that no secondary access token exists in the application's local cache, or that a secondary access token exists but has expired, display the application's login page.

[0115] In one exemplary embodiment, the apparatus is further configured to: generate an access token refresh request if the access token verification passes; detect whether the application has an ongoing refresh task; if it is determined that the application has an ongoing refresh task, place the access token refresh request in a waiting queue to suspend sending the access token refresh request to the server; if the application obtains the refresh result of the access token, share the refresh result with the refresh requests in the waiting queue; if it is determined that the application does not have an ongoing refresh task, send an access token refresh request to the server.

[0116] In one exemplary embodiment, the apparatus is further configured to: determine the network connection status of the application. If the application's network connection status is offline, and the access token is still valid, the application's login page is skipped and an offline cached page is displayed. If it is determined that an operation triggered by a target object requires real-time data, the target object is prompted to wait for the network to recover and then retry.

[0117] In one exemplary embodiment, the apparatus is further configured to: collect historical launch information of the application and monitor network quality data of the application; predict the timing of access token usage based on historical launch information; predict the network state at the time of access token usage based on the timing of access token usage and network quality data; determine whether there is a risk of congestion at the time of access token usage based on the remaining validity period of the access token, the timing of access token usage, and the predicted network state at the time of access token usage, wherein the risk of congestion includes access token expiration and / or abnormal network state; if it is determined that there is a risk of congestion at the time of access token usage, adjust a time threshold according to the risk of congestion to adjust the refresh timing of the access token.

[0118] Embodiments of the present invention also provide a storage medium comprising a stored program, wherein the program, when executed, performs any of the methods described above.

[0119] Optionally, in this embodiment, the storage medium may be configured to store program code for performing the following steps: S1 determines whether the application is being launched for the first time when the application is started.

[0120] S2, if it is determined that the application is not being launched for the first time, reads the access token used by the user to log in during the application's last launch from the application's local cache.

[0121] S3, if the access token is still valid and the remaining validity period is less than or equal to the time threshold, skip the application's login page to display the application's homepage and verify the access token in the background.

[0122] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0123] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0124] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program: S1 determines whether the application is being launched for the first time when the application is started.

[0125] S2, if it is determined that the application is not being launched for the first time, reads the access token used by the user to log in during the application's last launch from the application's local cache.

[0126] S3, if the access token is still valid and the remaining validity period is less than or equal to the time threshold, skip the application's login page to display the application's homepage and verify the access token in the background.

[0127] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0128] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0129] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0130] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for launching an application, characterized in that, include: Determine whether the application is being launched for the first time when the application is started; If it is determined that the application is not being launched for the first time, the access token used by the user to log in during the previous launch of the application is read from the local cache of the application. If the access token is still valid and the remaining time of the validity period is less than or equal to the time threshold, skip the application's login page to display the application's homepage and verify the access token in the background; Collect historical launch data of the application and monitor network quality data of the application; Predict the timing of the access token's use based on the historical startup data; Predict the network state when the access token is used based on the timing of its use and the network quality data. Based on the remaining validity period of the access token, the timing of the access token's use, and the predicted network status at the time of the access token's use, determine whether there is a blocking risk when the access token is used, wherein the blocking risk includes the access token expiring and / or abnormal network status; If it is determined that there is a risk of blocking when the access token is used, the time threshold is adjusted according to the risk of blocking to adjust the refresh timing of the access token.

2. The application launch method according to claim 1, characterized in that, The verification of the access token includes: Send an access token to the server, wherein the server verifies the validity of the access token upon receiving it; Receive the verification result fed back by the server, wherein the verification result is used to indicate whether the access token has passed verification; If the access token verification is successful, refresh the validity period of the access token.

3. The application launch method according to claim 2, characterized in that, The method further includes: If no verification result indicating that the access token verification has passed is received, determine the operation behavior triggered by the target object in the application; If it is determined that the operation behavior belongs to a preset non-sensitive operation behavior, the corresponding action is executed in response to the operation behavior of the target object; If it is determined that the operation is a preset sensitive operation, a prompt message for waiting for verification is sent to the target object, and a manual verification page is provided to the target object; If the access token verification is successful or the target object is manually verified, the corresponding action is executed in response to the sensitive operation behavior of the target object.

4. The application launch method according to any one of claims 1-3, characterized in that, The method further includes: If the expiration time of the access token is obtained, the time difference between the current time and the expiration time is calculated to determine the remaining time of the validity period; If the remaining time is greater than the time threshold, skip the application's login page and display the application's homepage; If the remaining time is less than or equal to zero, determine whether a secondary access token exists in the application's local cache, wherein the validity period of the secondary access token is greater than the validity period of the access token; If it is determined that the secondary access token exists in the application's local cache and the secondary access token has not expired, the application's login page is skipped to display the application's homepage, and the access token is verified in the background. If it is determined that the secondary access token does not exist in the application's local cache, or if the secondary access token exists but has expired, the application's login page is displayed.

5. The application launch method according to any one of claims 1-3, characterized in that, The method further includes: If the access token verification passes, a refresh request for the access token is generated; Check if the application has a currently executing refresh task; If it is determined that the application has an ongoing refresh task, the refresh request for the access token is placed in a waiting queue to suspend sending the refresh request for the access token to the server. If the application obtains the refresh result of the access token, it shares the refresh result with the refresh requests in the waiting queue; If it is determined that there is no ongoing refresh task in the application, a refresh request for the access token is sent to the server.

6. The application launch method according to any one of claims 1-3, characterized in that, The method further includes: Determine the network connection status of the application; If the network connection status of the application is offline, and the access token is still valid, then the login page of the application will be skipped and the offline cached page will be displayed. If it is determined that the operation triggered by the target object requires real-time data, the target object is reminded to wait for the network to recover and then retry.

7. An application launcher, characterized in that, include: The startup determination module is used to determine whether the application is being launched for the first time when the application is launched. The token reading module is used to read the access token used by the user to log in during the previous launch of the application from the local cache of the application if it is determined that the application is not being launched for the first time. The execution module is started to skip the application's login page and display the application's homepage when the access token is still valid and the remaining time of the validity period is less than or equal to a time threshold, and to verify the access token in the background. The device is also used to collect historical startup information of the application and monitor network quality data of the application; predict the timing of access token usage based on the historical startup information; predict the network status when the access token is used based on the timing of access token usage and the network quality data; determine whether there is a blocking risk when the access token is used based on the remaining validity period of the access token, the timing of access token usage, and the predicted network status when the access token is used, wherein the blocking risk includes access token expiration and / or abnormal network status; if it is determined that there is a blocking risk when the access token is used, adjust the time threshold according to the blocking risk to adjust the refresh timing of the access token.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 6.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method of any one of claims 1 to 6 through the computer program.

Images