A client application reliable awakening and adaptive degradation method and system in a small program embedded web page environment

Abstract

A kind of applet in embedded web environment under the reliable arousal and adaptive degradation method of client application, system, the method includes: in response to arousal trigger instruction, record trigger time;Listen to event set and page visibility change event;Set first preset time window and second preset time window;If in first preset time window, page is switched to invisible state or receives first type event and is monitored, then determine arousal success;If in the second preset time window, page remains visible state and does not receive the first type event or receives second type event, then determine arousal failure.The application also realizes full-link closed loop by non-blocking reporting, platform adaptive degradation, general link secondary bottom page configuration and state reset after page recovery.The application solves the problems of inaccurate judgment of client application arousal result, difficult cross-platform adaptation, white screen when application is not installed and secondary arousal after page return under applet embedded web environment.

Description

Technical Field

[0001] This invention relates to the fields of mobile Internet, embedded web pages in mini-programs, deep linking of client applications, application distribution and cross-platform redirection, and specifically to a reliable launch and adaptive degradation method and system for client applications in a mini-program embedded web page environment. Background Technology

[0002] In mobile internet services, users often complete preliminary operations such as browsing, claiming, placing orders, watching live streams, or checking benefits within mini-programs, and then need to be redirected to the native client application to complete a more complete business process. Common implementation methods include embedding web pages within mini-programs, using the WeChat open tag wx-open-launch-app, URL Scheme, UniversalLink, app store links, and links from Tencent App Store or other app distribution platforms.

[0003] However, in practical implementation, existing solutions still have significant shortcomings. First, embedded webpages within mini-programs operate within a restricted WebView environment; ordinary `window.location.href`, URL Schemes, Universal Links, or third-party application distribution pages may not function correctly on all platforms. Second, iOS and Android system policies, WeChat embedded webpage policies, and browser policies differ significantly. The same redirect code might work on iOS with an installed application but fail on Android. Third, the launch and error events provided by open tags cannot fully cover the actual launch state. For example, when a confirmation pop-up appears but the page hasn't switched to the background, neither launch nor error is triggered, making the launch result undetermined. Fourth, when the client application is not installed, Universal Links might directly access paths under their bound domain. If this path is configured as object storage or a static resource directory, errors such as a blank screen, NoSuchKey, or inability to open the page may occur. Fifth, in some implementations, interface reporting, initial authentication, and failure fallback are coupled in the same process; any interface exception could block subsequent launches. Sixth, after the user returns to the embedded webpage in the mini-program from the client application, the page's state machine remains in the "awakened" state, making it impossible to re-initiate the awakening action when the button is clicked again.

[0004] Therefore, there is an urgent need for a reliable launch and adaptive degradation solution for client applications embedded in mini-program web environments. This solution should be able to accurately handle complex scenarios such as applications not installed, launch failures, uncertain launch results, and relaunches after the system returns to the previous page, without compromising the normal launch capability of already installed client applications. Summary of the Invention

[0005] This invention aims to solve the problems of cross-platform adaptation difficulties and inaccurate judgment of launch results in the process of launching client applications by embedding web pages within mini programs. This invention provides a reliable launch and adaptive degradation method and system for client applications in a mini program embedded web page environment.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] A method for determining the launch result of a client application in a webpage embedded in a mini-program includes:

[0008] In response to a wake-up command, the trigger time of the wake-up command is recorded;

[0009] Listen to a preset set of events and page visibility change events, wherein the set of events includes at least a client callback event used to indicate the result of the invocation operation;

[0010] Set a first preset time window and a second preset time window, wherein the duration of the first preset time window is shorter than the duration of the second preset time window;

[0011] If the page visibility change event is detected within the first preset time window, indicating that the current page has switched to an invisible state, or if the first type of event in the event set is detected, then the client application is determined to have been successfully launched.

[0012] If the page remains visible within the second preset time window and no first type of event is detected, or a second type of event in the event set is detected, then the client application is determined to have failed to launch.

[0013] In some embodiments, the wake-up trigger instruction includes a click instruction triggered by the user clicking the wake-up control, or an automatic wake-up instruction that is executed automatically after the page is loaded.

[0014] In some embodiments, the duration of the first preset time window and / or the second preset time window is dynamically adjusted according to the performance level of the terminal device or the current network latency;

[0015] And / or, the method further includes: when the page is switched to an invisible state, starting a timer; if the page becomes visible again within the first preset time window and no first type of event is detected, then canceling the successful wake-up determination result and marking the state as unknown or failed.

[0016] In some embodiments, it also includes:

[0017] A state machine is constructed based on the wake-up trigger instruction, and the state machine includes at least an initial state, a ready state, a wake-up state, an open state, and a failed state.

[0018] When the wake-up trigger command is received, the state machine switches from the ready state to the wake-up state;

[0019] When it is determined that the client application has been successfully invoked, the state machine switches from the invoked state to the in-open state;

[0020] When it is determined that the client application has failed to be woken up, the state machine switches from the wake-up state to the failure state.

[0021] In some embodiments, it also includes:

[0022] Before the trigger command is executed, the jump information storage interface is called to report the business source information and application link information of this jump;

[0023] The call result of the jump information storage interface is decoupled from the subsequent wake-up process. That is, regardless of whether the jump information storage interface returns success, failure or timeout, the client application wake-up action corresponding to the wake-up trigger instruction will continue to be executed.

[0024] In some embodiments, it also includes:

[0025] When it is determined that the client application fails to be invoked or no definite result is obtained, the operating system type of the current terminal device is identified;

[0026] If the operating system type is a first type system, then the first downgrade boot strategy is executed;

[0027] If the operating system type is a second type of system, then a second downgrade boot strategy, different from the first downgrade boot strategy, is executed.

[0028] In some embodiments, the first downgrade boot strategy includes:

[0029] A copy link control is displayed, and the link address corresponding to the copy link control points to a preset application distribution guide page, which is used to guide users to jump to the official application store.

[0030] The address of the preset application distribution guide page is configured as the binding path of a universal link. When the client application is not installed, the binding path pointed to by the universal link is opened by the system to display the application distribution guide page.

[0031] In some embodiments, the second downgrade boot strategy includes:

[0032] Display a copy link control, the link address of which points to a preset intermediate guide page, and prompt the user to open the intermediate guide page in the system browser;

[0033] The intermediate redirection page is used to relaunch the client application in the system browser environment, or to redirect to a third-party application distribution platform.

[0034] This embodiment also provides a reliable launch and adaptive degradation method for client applications in a webpage environment embedded in a mini-program, including:

[0035] The client application wake-up result is determined by the method described in any one of claims 1 to 4;

[0036] Non-blocking jump information reporting is performed using the method described in claim 5;

[0037] When the wake-up failure or unknown is determined, the platform adaptive degradation boot is performed using the method described in any one of claims 6 to 8;

[0038] In scenarios where a universal link is used for invocation, the binding path of the universal link is configured to point to the access address of a real fallback onboarding page; when the terminal system responds to the open request of the universal link and the client application is not installed, the terminal system loads and displays the fallback onboarding page; the fallback onboarding page contains application identification information, guidance text, and a link to the app store;

[0039] After the wake-up process ends and the page becomes visible again, the pre-built wake-up state machine is reset to the ready state; after the reset, in response to the wake-up operation command triggered by the user again, the client application wake-up process is re-executed.

[0040] In some embodiments, configuring the binding path of the universal link to an access address pointing to a real fallback onboarding page specifically includes:

[0041] The server hosting the fallback guide page is pre-configured with path rewriting rules. These rules are used to identify general link access requests from mobile terminal browsers and return the HTML content of the fallback guide page, while ensuring that the configuration file used by the terminal system for application wake-up is not overwritten or corrupted.

[0042] In some embodiments, resetting the pre-built wake-up state machine to a ready state specifically includes:

[0043] Listen for page visibility change events or page display events. When the page display event is detected to be triggered, or the page visibility change event is detected to indicate that the current page has switched from an invisible state to a visible state, the reset operation is performed.

[0044] This embodiment also provides a reliable wake-up and adaptive degradation system for client applications in a webpage environment embedded in a mini-program, including:

[0045] The parameter generation module is used to generate jump parameters on the mini-program side. The jump parameters include at least the source identifier, business type, and invocation protocol link.

[0046] The reporting module is used to call the jump information storage interface before the actual jump to report the jump parameters in a non-blocking manner. The execution result of the reporting module is decoupled from the subsequent wake-up action.

[0047] An embedded webpage initialization module is used to load the embedded webpage and read the redirection parameters, as well as initialize the software development kit configuration on the webpage side; and

[0048] Also includes:

[0049] A state machine detection module is used to execute the method as described in any one of claims 1 to 4 to determine the client application wake-up result;

[0050] The platform identification module is used to identify the operating system type of the current terminal device;

[0051] The downgrade guidance module is used to perform differentiated downgrade guidance according to the determination result of the state machine detection module and the identification result of the platform identification module, as described in any one of claims 6 to 8.

[0052] The fallback page processing module is used to configure and return the fallback guide page to handle access requests in scenarios where the general link is not installed;

[0053] The state reset module is used to reset the state machine to the ready state after the page is restored.

[0054] In some embodiments, it also includes:

[0055] The threshold dynamic adjustment module is used to obtain the hardware performance parameters and network status parameters of the current terminal device, and dynamically adjust the specific duration values ​​of the first preset time window and the second preset time window in the state machine detection module according to the preset mapping relationship.

[0056] Compared with the prior art, the present invention has the following significant advantages / technical benefits:

[0057] First, the wake-up determination is more accurate. This application combines page visibility change events with client-side callback events for determination, and sets two sequentially related time windows as the determination boundary, no longer relying solely on the launch or error callback of the open tag. In scenarios where neither launch nor error is triggered, such as when the system pops up a confirmation popup, the wake-up result can be accurately determined by the physical change in page visibility state, filling the judgment blind spot of existing technologies. At the same time, through the anti-false alarm cancellation mechanism, it effectively distinguishes between two different scenarios: "truly switching to the background" and "returning after a brief popup," avoiding false alarms.

[0058] Second, it offers stronger cross-platform compatibility. This application identifies and differentiates between operating system types, designing different downgrade boot strategies for iOS and Android platforms. Instead of attempting to adapt the same code to all platforms, it adopts the optimal solution based on the characteristics of each platform, ensuring the best wake-up experience for both devices.

[0059] Third, the experience of already installed applications remains unaffected. Upon successful activation, this application immediately switches the state machine to the "on" state without performing any degradation actions, ensuring that the normal activation process of already installed applications is not interfered with.

[0060] Fourth, the blank screen is no longer displayed when the application is not installed. This application completely solves the blank screen and NoSuchKey error in the scenario where Universal Link is not installed by configuring the Universal Link binding path to a real fallback onboarding page and ensuring that the same path returns readable HTML onboarding content when the application is not installed through server-side path rewriting rules.

[0061] Fifth, interface exceptions do not disrupt the process. This application adopts a non-blocking reporting strategy, completely decoupling the call result of the jump information storage interface from the subsequent wake-up action. Even if the reporting interface times out or is abnormal, the user's wake-up operation can still be executed normally, improving the robustness of the system.

[0062] Sixth, users can reopen the application after returning. This application listens for page display events and page visibility change events, and automatically resets the state machine to a ready state when the page becomes visible again, allowing users to reopen the application by clicking the button after returning from the client application or an external browser without manually refreshing the page.

[0063] Seventh, the business redirection link is traceable. This application, through a non-blocking reporting mechanism, completed the reporting of redirection source, business type, and application link without affecting user experience, providing a reliable data foundation for subsequent business attribution and data analysis. Attached Figure Description

[0064] Figure 1This is a schematic diagram of the overall system architecture of the present invention.

[0065] Figure 2 This is a schematic diagram of the client application wake-up state machine of the present invention.

[0066] Figure 3 This is a flowchart illustrating the process of launching an installed client application on iOS according to the present invention.

[0067] Figure 4 This is a flowchart illustrating the iOS application downgrade process for applications not installed in this invention.

[0068] Figure 5 This is a flowchart illustrating the Android external browser boot process of this invention.

[0069] Figure 6 This is a flowchart of the secondary wake-up and status abnormal reset process after page restoration according to the present invention.

[0070] Figure 7 This is a flowchart of the non-blocking reporting mechanism of the present invention.

[0071] Figure 8 This is a flowchart of the method for determining the activation result of the present invention. Detailed Implementation

[0072] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0073] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, an indirect connection through an intermediate medium, or the internal communication between two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0074] See Figures 1-8 This invention provides a complete set of reliable client application wake-up and adaptive degradation technology solutions, as detailed below:

[0075] To address the inaccurate judgment of wake-up results caused by relying solely on open tag callback events in existing technologies, particularly the blind spot in judgment when the page neither switches to the background nor triggers an error event when the system pops up a confirmation pop-up, this application provides a method for determining the wake-up result of a client application in a mini-program embedded webpage environment:

[0076] Specifically, this method responds to a wake-up command and records the trigger time of the command as the starting zero point for time calculation. Simultaneously, it listens for a preset set of events and page visibility change events. The event set includes at least client-side callback events indicating the result of the wake-up operation, such as the launch and error events of the WeChat open tag. Based on this, a first preset time window and a second preset time window are set, with the first preset time window having a shorter duration than the second preset time window. The first preset time window is used to determine whether the wake-up was successful, and the second preset time window is used to determine whether the wake-up failed. If a page visibility change event indicating that the current page has switched to an invisible state is detected within the first preset time window, it means that the client application has been successfully woken up and switched to the foreground, and the current webpage has been pushed to the background. Alternatively, if the first type of event in the event set, i.e., a success callback event, is detected, then the client application is considered successfully woken up. Conversely, if the page remains visible within the second preset time window and no first type of event is detected, it means that the client application has not been woken up, and the page remains in the foreground. Alternatively, if the second type of event in the event set, i.e., a failure callback event, is detected, then the client application is considered to have failed to wake up.

[0077] Through the above technical means, this application no longer relies solely on the single callback of the open tag, but uses changes in page visibility as physical evidence of successful invocation. At the same time, it clearly distinguishes between the two states of "already in the background" and "always in the foreground" through two time windows set sequentially, which greatly improves the accuracy of the invocation result judgment and fills the gap in the existing technology for judging failure in system pop-up scenarios.

[0078] To address the issues of adaptability of wake-up trigger commands in different business scenarios and misjudgment caused by fixed time window thresholds on different performance devices, this application further specifies the triggering method and the dynamic adjustment mechanism of the threshold.

[0079] Specifically, the wake-up trigger commands include click commands triggered by the user clicking the wake-up control, or automatic wake-up commands executed automatically after the page loads. Both triggering methods are subject to the above-described judgment logic, ensuring the versatility of the solution.

[0080] Furthermore, the duration of the first preset time window and / or the second preset time window is dynamically adjusted based on the device performance level of the terminal device or the current network latency. For example, high-performance devices use a shorter time window to improve response speed, while low-performance devices or high-latency network environments use a longer time window to avoid misjudgment. In addition, to prevent the page from being mistakenly judged as successfully launched due to system pop-ups or the user briefly switching out and then returning, this application also sets up a misjudgment cancellation mechanism: a timer is started when the page switches to an invisible state. If the page becomes visible again within the first preset time window and no first type of event is detected, the judgment result of successful launch is cancelled, and the status is marked as unknown or failed, and monitoring continues in the subsequent second preset time window.

[0081] In order to implement the above-mentioned decision-making logic in a controllable and reproducible state management manner, and to solve the technical problems of scattered states and untraceable processes, this application introduces a state machine mechanism.

[0082] Specifically, a state machine is constructed based on the wake-up trigger command. This state machine includes at least an initial state, a ready state, a wake-up in progress state, an opened state, and a failed state. It may also include an unknown state to handle abnormal situations such as conflicting signals from page visibility change events and client callback events, or uncertain wake-up results. When responding to the wake-up trigger command, the state machine switches from the ready state to the wake-up in progress state, indicating that the wake-up process is in progress. When the client application is successfully woken up based on the above determination method, the state machine switches from the wake-up in progress state to the opened state, indicating that the client application has been successfully opened. When the client application is determined to have failed to wake up based on the above determination method, the state machine switches from the wake-up in progress state to the failed state, indicating that the wake-up failed and subsequent degradation processes can be triggered. By introducing the state machine, each stage of the wake-up process has a clear state identifier, facilitating precise control and exception handling in subsequent processes.

[0083] To address the technical problem in existing technologies where the call result of the jump information storage interface blocks the subsequent wake-up process, i.e., when the reporting interface is unresponsive for a long time due to network timeout or server abnormality, resulting in a poor user experience of no feedback after clicking the button for an extended period, this application provides a non-blocking reporting method that completely decouples the reporting action from the wake-up action.

[0084] Specifically, before the trigger command is executed—that is, before the user clicks the trigger button or the page triggers automatic activation—the jump information storage interface is called to report the business source information, business type, and application link information of this jump, so that the server can record the jump source and business attribution. The result of this jump information storage interface call is decoupled from the subsequent activation process. That is, regardless of whether the jump information storage interface returns success, failure, or timeout, the client application activation action corresponding to the trigger command continues to be executed, without blocking or interrupting the user flow due to interface abnormalities.

[0085] Through the above technical means, even in the case of unstable network or abnormal server interface, the user's wake-up operation can still be executed normally, avoiding the problem of core functions being unavailable due to auxiliary function failure, and significantly improving the smoothness of user experience and the robustness of the system.

[0086] To address the technical issues in existing technologies, such as the significant differences in system strategies between iOS and Android, the inability of the same jump code to function correctly on both platforms, and the inability of users to receive effective guidance when no application is installed, this application provides a differentiated downgrade boot method based on operating system type.

[0087] Specifically, when the client application fails to launch or no definite result is obtained based on the above determination method, the operating system type of the current terminal device is first identified. If the operating system type is a first-type system, the first downgrade boot strategy is executed; if the operating system type is a second-type system, the second downgrade boot strategy, which is different from the first downgrade boot strategy, is executed. By identifying and routing based on the operating system type, different platforms can execute their most suitable downgrade scheme, avoiding cross-platform compatibility issues.

[0088] Furthermore, the first downgrade guidance strategy specifically includes: displaying a copy link control, the link address of which points to a preset app distribution guidance page. This app distribution guidance page is used to redirect users to the official app store. After clicking the copy link control, the user can copy the guidance page link to the clipboard and then open the link in the system's built-in browser, where the guidance page will complete the redirection to the App Store. The address of this preset app distribution guidance page is configured as the binding path of a universal link. When the client app is not installed, the binding path pointed to by the universal link is opened by the system to display the app distribution guidance page, thereby avoiding the white screen or NoSuchKey error caused by directly accessing the static resource directory.

[0089] Furthermore, the second downgrade guidance strategy specifically includes: displaying a copy link control, the link address of which points to a preset intermediate guidance page, and prompting the user to open the intermediate guidance page in the system browser. This intermediate guidance page is used to re-attempt to launch the client application in the system browser environment, or to redirect to a third-party application distribution platform. Since the success rate of directly launching the client application from a webpage embedded in a mini-program on Android is low, guiding the user to switch to the system browser environment and utilizing the browser's URL Scheme processing capabilities to launch the client application significantly improves the launch success rate. When the client application is not installed, the system browser will redirect the user to Tencent App Store or other application distribution platforms for download and installation.

[0090] Through the aforementioned technical means, iOS and Android platforms each obtain their optimal downgrade paths, ensuring the normal launch of installed applications while providing clear download guidance for users who have not installed applications, effectively solving the problem of cross-platform adaptation difficulties.

[0091] In order to integrate the above-mentioned judgment method, reporting method, degradation guidance method, fallback page configuration and status reset into a complete, feasible solution covering the entire process, this application also provides a complete closed-loop method that executes the above steps in series.

[0092] Specifically, the method includes: first, determining the client application's activation result using the aforementioned time window and page visibility-based determination method; simultaneously, reporting jump information using the aforementioned non-blocking jump information reporting method to ensure that the reporting action does not affect the activation process; and when activation is determined to have failed or is unknown, using the aforementioned platform adaptive degradation guidance method for differentiated degradation guidance. Specifically, in scenarios using a universal link for activation, the binding path of the universal link is configured to point to the access address of a real fallback guidance page. When the terminal system responds to the universal link's open request and the client application is not installed, the terminal system loads and displays the fallback guidance page, which includes application identification information, guidance text, and a link to the app store. After the activation process ends and the page becomes visible again, the pre-built activation state machine is reset to a ready state. After the reset, in response to a user's re-triggered activation command, the client application activation process is re-executed.

[0093] Through the above complete closed-loop method, from non-blocking reporting before invocation, accurate judgment during invocation, platform-differentiated degradation after invocation failure, server-side fallback configuration in general link scenarios, to state reset after page return, a reliable invocation guarantee is achieved across the entire link.

[0094] To address the technical issues in existing technologies where Universal Links directly open their bound domain paths when the client application is not installed, and where a blank screen or NoSuchKey error occurs if the path is configured as an object storage or static resource directory, this application further limits the specific configuration method of the fallback page in the general link invocation scenario of the complete closed-loop method.

[0095] Specifically, the universal link's binding path is configured to point to the access address of a real fallback onboarding page. The server-side configuration for this fallback onboarding page is as follows: the server hosting the fallback onboarding page has pre-configured path rewriting rules. These rules are used to identify universal link access requests from mobile browsers and return the HTML content of the fallback onboarding page, while ensuring that the configuration file used by the terminal system for application launch is not overwritten or corrupted. More specifically, the server needs to declare the path bound to the Universal Link as a path that can be processed by the application in the apple-app-site-association file, and configure web server rules under the same path. When the User-Agent is detected as a mobile browser and the client application is not installed, the HTML content of the onboarding page is returned instead of a 404 or NoSuchKey error. Through the above configuration, the same Universal Link address can launch the application when it is installed and display the onboarding page when the application is not installed, achieving graceful degradation.

[0096] The above technical methods completely solve the white screen problem in the case of Universal Link not being installed, so that users can get clear guidance when the application is not installed, instead of facing a meaningless error page.

[0097] To address the technical problem in existing technologies where the page remains in an "activated" state after a user returns from a client application to an embedded webpage within a mini-program, and clicking the button again fails to re-initiate the activation action, this application further defines the specific operation method for state reset in the page recovery scenario of the complete closed-loop method described above.

[0098] Specifically, after the page loading or wake-up process is completed, the system continuously listens for page visibility change events or page display events. When a page display event is detected, or a page visibility change event indicates that the current page has switched from an invisible state to a visible state, it means that the user has returned to the current webpage from the client application or external browser. At this time, the pre-built wake-up state machine is reset to the ready state. After the reset, in response to the user's wake-up operation command, the client application wake-up process is re-executed, including re-executing all the aforementioned steps such as wake-up trigger command recording, event listening, and time window determination.

[0099] Through the above technical means, the button status automatically returns to available after the user returns from the client application, and the application can be restarted by clicking again without manually refreshing the page, which significantly improves the ease of use in multi-tasking scenarios.

[0100] To address the technical challenge of implementing the aforementioned methods in a systematic and modular manner, this application also provides a system corresponding to the methods described above.

[0101] The system includes: a parameter generation module for generating jump parameters on the mini-program side, which includes at least the source identifier, business type, and invocation protocol link; a reporting module for calling the jump information storage interface before the actual jump to report the jump parameters in a non-blocking manner, and the execution result of the reporting module is decoupled from the subsequent invocation action; and an embedded webpage initialization module for loading the embedded webpage and reading the jump parameters, as well as initializing the software development kit configuration on the webpage side.

[0102] The system also includes: a state machine detection module, used to execute the aforementioned client application wake-up result determination method to determine the client application wake-up result; a platform identification module, used to identify the operating system type of the current terminal device; a degradation boot module, used to execute the aforementioned platform adaptive degradation boot method for differentiated degradation boot based on the determination result of the state machine detection module and the identification result of the platform identification module; a fallback page processing module, used to configure and return the aforementioned fallback boot page to handle access requests in scenarios where the general link is not installed; and a state reset module, used to reset the state machine to the ready state after the page is restored.

[0103] Furthermore, the system also includes a threshold dynamic adjustment module, which acquires the hardware performance parameters and network status parameters of the current terminal device, and dynamically adjusts the specific duration values ​​of the first and second preset time windows in the state machine detection module according to a preset mapping relationship. For example, when a flagship model is detected and the network latency is less than 100ms, a shorter time window is used to improve response sensitivity; when a low-end model is detected or the network latency is greater than 300ms, a longer time window is used to avoid misjudgments caused by slow system response or network latency.

[0104] To address the deployment and operation issues of the aforementioned methods on different hardware platforms, this application also provides a computer device and a computer-readable storage medium. The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the methods described in any of the preceding claims. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the methods described in any of the preceding claims.

[0105] The present application will be further described below with reference to several specific embodiments: Embodiment 1

[0106] This embodiment provides a concentrated explanation of the system architecture of the present invention, the connection relationships between its modules, and its working principle. Figure 1 The overall system architecture of the present invention is shown.

[0107] like Figure 1 As shown, the overall system architecture of the present invention includes the following layers from top to bottom from the user end to the server end: mini-program end, embedded web page end, and server end.

[0108] The mini-program includes a parameter generation module and a reporting module. The parameter generation module runs within the mini-program's business page. When a user triggers a redirect entry point, this module generates a `redirect_type` parameter based on the entry point type, a `source_type` parameter based on a fixed configuration, and retrieves the scheme's generic link address and user identifier from the server's pre-configuration. The parameter generation module assembles these parameters into a URL query string format, which is then used as data for subsequent page redirects. The reporting module works in parallel with the parameter generation module. Before the actual redirect, it calls the server's `storeRedirectInfo` interface to report the redirect parameters generated by the parameter generation module. This reporting module uses an asynchronous, non-blocking method to call the interface and sets a timeout timer. Regardless of whether the interface call succeeds, fails, or times out, it immediately triggers a page redirect.

[0109] The embedded web page includes an embedded web page initialization module, a state machine detection module, a platform identification module, a fallback guidance module, a fallback page processing module, and a state reset module. The embedded web page initialization module starts when the mini-program loads bridge.html via the web-view component. It is responsible for reading the parameters from the URL query string and calling the WeChat web JS-SDK's wx.config for initialization configuration. After the wx.ready callback is triggered, this module determines the page rendering strategy based on the platform identification module's results: for iOS, it renders the open tag and the "Open App" button; for Android, it directly renders the copy link guide interface.

[0110] The state machine detection module is one of the core modules of this invention. Internally, it maintains a state machine instance, which includes at least the initial state INIT, the ready state READY, the launching state LAUNCHING, the opened state OPENED, the failed state FAILED, the unknown state UNKNOWN, and the reset state RESET. The state machine detection module listens for click events from user interactions, client callback events from the WeChat JS-SDK (in this embodiment, the client callback events include a first type of event launch indicating successful launch and a second type of event error indicating failed launch), visibilitychange and pageshow events from the page document, and timeout events from internal timers. Based on the event type and the current state, the state machine detection module performs state switching according to preset state transition rules and outputs the determination result to the degradation guidance module.

[0111] The platform identification module executes once when the page loads. It determines the current operating system type by parsing the navigator.userAgent string, identifying it as iOS, Android, or other. This identification result is cached and used by the fallback bootstrapping module and page rendering control logic.

[0112] The degradation guidance module receives the judgment result from the state machine detection module and the identification result from the platform identification module. When the judgment result is a failure state (FAILED) or an unknown state (UNKNOWN), the degradation guidance module selects different degradation strategies based on the platform identification result. For the iOS platform, the degradation guidance module instructs the page rendering engine to switch to the UI state of copying the App Store onboarding page link; for the Android platform, the degradation guidance module instructs the page rendering engine to switch to the UI state of copying the intermediate onboarding page link.

[0113] The fallback page processing module is deployed on the server side, corresponding to the bound path of the Universal Link. This module includes path rewriting rule configuration and onboarding page HTML content. When the terminal system accesses the bound path through the Universal Link and the client application is not installed, this module receives the HTTP request from the mobile browser, checks the User-Agent in the request header, and returns the onboarding page HTML content. When the client application is installed, this module does not interfere with the system's processing of the Universal Link; the system forwards the request to the client application. Through this configuration, differentiated responses are achieved for the same path in different scenarios.

[0114] The state reset module listens for the page show event and the page visibility change event. When it detects that the page has switched from invisible to visible or the page show event is triggered, the state reset module reads the current state from the state machine detection module. If the current state is OPENED (open) or FAILED (failed), it performs a reset operation to restore the state machine to the READY (ready) state.

[0115] The server also includes a redirect information storage interface, storeRedirectInfo. This interface receives redirect parameters from the reporting module on the mini-program side and stores the parameters in a database or log system for subsequent business attribution and data analysis.

[0116] Through the coordinated work of the above modules, the system of the present invention realizes a complete closed loop from jump triggering, wake-up determination, failure degradation to state recovery.

[0117] Example 2

[0118] This embodiment provides a detailed description of the state definition and state transition rules of the state machine of the present invention. Figure 2 A schematic diagram of the client application wake-up state machine of the present invention is shown.

[0119] like Figure 2 As shown, the state machine of the present invention includes the following states:

[0120] The initial state INIT indicates that the state machine has just been created and has not yet completed its initialization configuration. The state machine is in this state when the embedded webpage has finished loading and the wx.ready callback has not yet been triggered.

[0121] The READY state indicates that the state machine has completed its initial configuration and is ready to accept user-triggered commands. When the wx.ready callback is triggered, the state machine transitions from the initial INIT state to the READY state. Furthermore, when the page resumes from the background and the state reset module performs a reset operation, the state machine transitions from the OPENED state or the FAILED state to the READY state.

[0122] The LAUNCHING state indicates that the wake-up action has been triggered, and the state machine is monitoring the event to determine the result. When the user clicks the "Open App" button or an automatic wake-up action is triggered, the state machine switches from the READY state to the LAUNCHING state.

[0123] The OPENED state indicates that the client application has been successfully launched. When the state machine is in the LAUNCHING state and detects a page visibility change event indicating that the page has switched to the background, and this event occurs within the first preset time window, or when a launch event is detected, the state machine switches from the LAUNCHING state to the OPENED state.

[0124] The FAILED state indicates that the client application failed to launch. When the state machine is in the LAUNCHING state, and the page remains visible without receiving a launch event or detecting an error event by the end of the second preset time window, the state machine switches from the LAUNCHING state to the FAILED state.

[0125] The Unknown state (UNKNOWN) indicates that the outcome of the launch is uncertain. When the state machine is in the LAUNCHING state, if the signals given by the page visibility change event and the client callback event contradict each other (e.g., the page briefly switches to the background but immediately resumes, and no launch event is received), or other unclassifiable abnormal situations occur, the state machine switches from the LAUNCHING state to the Unknown state (UNKNOWN).

[0126] The state transition rules of the state machine are shown in the table below. In this embodiment, the "first type of event" is the launch event of the WeChat Open tag, and the "second type of event" is the error event of the WeChat Open tag.

[0127]

[0128] Through the aforementioned state machine and its transition rules, the wake-up process of this invention possesses deterministic state management capabilities. The state at each moment is clear and predictable, providing a reliable foundation for subsequent degradation guidance and state reset.

[0129] Example 3

[0130] This embodiment uses a scenario where the client application is already installed on the iOS platform as an example to explain the complete workflow of the present invention in detail. Figure 3 The complete process of this embodiment is shown.

[0131] like Figure 3As shown, when a user triggers a redirect entry on a mini-program business page, the mini-program first generates a `redirect_type` parameter based on the type of entry clicked by the user. This parameter identifies the business type of the redirect source, such as live streaming, products, orders, activities, memberships, or benefits. Simultaneously, a `source_type` parameter is generated, which consistently identifies the source as the mini-program environment. The mini-program also obtains a pre-agreed scheme universal link address and the current user's identifier. This user identifier is used by the server to record the redirect source and business attribution. These parameters are generated by the parameter generation module on the mini-program side.

[0132] After generating the redirect parameters, the mini-program calls the redirect information storage interface `storeRedirectInfo` to report parameters such as the source identifier `source_type`, business type `redirect_type`, and application link scheme. This reporting process employs a non-blocking design, meaning a short reporting timeout is set, such as 800 milliseconds. Regardless of whether the interface returns success, failure, or no response within the timeout period, subsequent page redirection actions immediately continue, without blocking the user flow due to the status of the reporting interface. Through this design, even if the server-side reporting interface experiences network fluctuations or temporary failures, the user's invocation operation will not be affected.

[0133] Subsequently, the mini-program redirects to the embedded webpage `bridge.html` via the web-view component, passing the aforementioned parameters to the embedded webpage through a URL query string. Once the embedded webpage loads, it reads the parameters from the URL and calls the `wx.config` method of the WeChat Web JS-SDK for initialization configuration. The configuration includes authentication information such as `appId`, `timestamp`, `nonceStr`, and `signature`. After the `wx.ready` callback is triggered, indicating that the WeChat JS-SDK is ready, the embedded webpage renders the client application's icon, name, and "Open App" button. Simultaneously, it creates a `wx-open-launch-app` tag and mounts it to the page. The `extinfo` attribute of this tag carries the Universal Link address used to launch the client application.

[0134] When the user clicks the "Open App" button, a wake-up action is triggered, and the state machine detection module of this invention begins to work. Specifically, in response to the click instruction, the state machine switches from the READY state to the LAUNCHING state, and simultaneously records the click time t0 as the starting zero point for time calculation. The state machine detection module then starts two timers: a first preset time window Topen, which is preferably set to 2500 milliseconds in this embodiment; and a second preset time window Tfail, which is preferably set to 5000 milliseconds in this embodiment.

[0135] During the time interval from t0 to t0+Topen, the state machine detection module continuously listens for two types of signals: one is the first type of event (in this embodiment, the launch event of the WeChat open tag), and the other is the page visibility change event `visibilitychange`. Since the client application is already installed in this embodiment, when the user clicks the button, the iOS system successfully launches the client application through the Universal Link mechanism, and the currently embedded webpage is switched to the background. At this time, the page visibility change event is triggered, and its `visibilityState` property changes from `visible` to `hidden`. The state machine detection module captures this visibility change event at t0+800 milliseconds. Because this time is within the first preset time window of 2500 milliseconds, the state machine detection module determines that the client application has been successfully launched and switches the state machine from the launching state `LAUNCHING` to the open state `OPENED`. Simultaneously, the first type of event (in this embodiment, the launch event of the WeChat open tag) is also triggered, further confirming the successful launch. After the determination is completed, the state machine no longer performs any degradation actions, and the launch process ends normally.

[0136] It should be noted that although the launch event is also triggered simultaneously in this embodiment, the core judgment logic of this invention does not rely solely on the launch event. In actual operation, even if the launch event fails to trigger or is delayed for various reasons, as long as the page visibility change event indicates that the page has switched to the background within the first preset time window, the state machine detection module can still independently determine that the launch was successful. This dual confirmation mechanism greatly improves the reliability of the launch result judgment.

[0137] When a user returns from the client application to the embedded webpage within the mini-program, the pageshow event is triggered. The state reset module captures this event, detects that the current state machine is in the OPENED state, and then performs a reset operation, restoring the state machine from the OPENED state to the READY state. After the reset is complete, the "Open App" button on the page becomes clickable again. If the user clicks this button again, the state machine will re-execute the entire wake-up process described above, thus achieving a secondary wake-up.

[0138] Example 4

[0139] This embodiment uses the scenario where the client application is not installed on the iOS platform as an example to explain in detail the downgrade boot process and the secondary fallback page mechanism of the present invention. Figure 4 The complete process of this embodiment is shown.

[0140] like Figure 4 As shown, after completing the preliminary operations in the mini program, the user enters the embedded webpage bridge.html. Its preliminary process is the same as that in Example 3, including parameter generation, non-blocking reporting, embedded webpage loading and WeChat JS-SDK initialization, etc., which will not be described in detail here.

[0141] After the user clicks the "Open App" button, the state machine switches from the READY state to the LAUNCHING state and records the click time t0. Since the client application is not installed in this embodiment, when the iOS system attempts to launch the client application via the Universal Link, the system detects that no installed application can handle the link, therefore the current webpage is not switched to the background, and the embedded webpage remains visible in the foreground. Simultaneously, the second type of event (in this embodiment, the error event of the WeChat open tag) is triggered, indicating that the launch has failed.

[0142] The state machine detection module did not detect any page visibility change events indicating the page had switched to the background within the first preset time window Topen (2500 milliseconds), nor did it detect any launch events, therefore it did not make a success determination. At t0+2500 milliseconds, the first preset time window expired, and the state machine detection module continued monitoring, entering the monitoring phase of the second preset time window Tfail (5000 milliseconds). From t0+2500 milliseconds to t0+5000 milliseconds, the page remained visible and no launch events were received. At t0+5000 milliseconds, the second preset time window expired, and the state machine detection module, based on the judgment rule of "the page remained visible within the second preset time window and no first type of event was detected," determined that the client application launch had failed and switched the state machine from the launching state LAUNCHING to the failed state FAILED.

[0143] After the state machine enters the FAILED state, the platform identification module begins to work, identifying the operating system type of the current terminal device. In this embodiment, the platform identification module identifies the current system as iOS, i.e., the first type of system, by parsing keywords in the navigator.userAgent string. The platform identification module then passes the identification result to the downgrade bootstrapping module.

[0144] After receiving a platform identification result indicating iOS and a FAILED status, the downgrade guidance module executes the first downgrade guidance strategy. Specifically, the page UI switches, hiding the "Open App" button and the wx-open-launch-app open label, and instead displaying a copy link control. The link corresponding to this copy link control points to a preset application distribution guidance page, whose address is https: / / example.com / app / app-store-guide.html. This address is also configured as the binding path for the Universal Link. The page also displays the guidance text "The application is not installed. Please copy the link and open it in Safari to view the download instructions."

[0145] After the user clicks the copy link control, the page copies the aforementioned onboarding page address to the system clipboard using the `document.execCommand('copy')` method and displays a success message. The user then opens the link in the Safari browser. Because this link is also the bound path of a Universal Link, and the client application is not installed, the iOS system cannot forward the request to the client application for processing. Therefore, the Safari browser directly loads the page corresponding to that address.

[0146] It is important to explain the server-side configuration mechanism of the second-level fallback page in this invention. In existing technologies, the binding path of a Universal Link typically points to an object storage address or a static resource directory. When the client application is not installed, the system directly accesses this path. If no actual HTML file exists under this path, a NoSuchKey error is returned or a blank screen is displayed. In this invention, however, this path is configured as a real fallback guide page. Specifically, the server pre-configures path rewriting rules. For requests pointing to the path / app / app-store-guide.html, the server checks the User-Agent field in the request header. If the User-Agent indicates that the request comes from a mobile browser and is an iOS system, the server returns the pre-written guide page HTML content. This guide page displays the application icon, application name, the guide text "Welcome to use this application, please click the button below to download and install," and a "Go to App Store to download" button. After the user clicks this button, the page redirects to the itms-apps: / / protocol link via window.location.href, directly opening the application's download page in the App Store. Meanwhile, this path is declared in the apple-app-site-association file as an associated path that the application can handle, ensuring that the Universal Link can launch the application normally when the application is installed. With this configuration, the same Universal Link address launches the application when it is installed and displays a onboarding screen when the application is not installed, achieving graceful degradation and completely solving the white screen problem.

[0147] Example 5

[0148] This embodiment uses the Android platform as an example to explain in detail the Android-side differentiation processing flow of the present invention. Figure 5 The complete process of this embodiment is shown.

[0149] like Figure 5 As shown, when a user triggers a redirect entry on the mini-program's business page, the mini-program performs parameter generation and non-blocking reporting. The specific implementation method is the same as in Example 3, and will not be repeated here. Subsequently, the mini-program redirects to the embedded webpage bridge.html.

[0150] After the embedded webpage loads, it reads the URL parameters and executes wx.config initialization. Unlike the iOS platform, in this embodiment, after the embedded webpage completes the WeChat JS-SDK initialization, the platform identification module first identifies the operating system type of the current terminal device. The platform identification module identifies the current system as Android, i.e., the second type of system, by parsing the navigator.userAgent string. The platform identification module then passes the identification result to the page rendering control logic.

[0151] Based on the platform identification result of Android, the page rendering control logic decides not to attempt to directly launch the client application via URL Scheme or WeChat open tags within the embedded webpage of the mini-program. This is because, after extensive testing, it has been verified that the success rate of directly launching the client application via URL Scheme in an embedded WebView environment on the Android platform is low. Furthermore, different Android manufacturers have significantly different restrictions on scheme redirects initiated from WebView, with some systems even directly blocking such redirects. Therefore, in this embodiment, the embedded webpage directly displays a guide interface, which includes the client application's icon and name, the guiding text "Please copy the link and open it in your system browser to use the full functionality," and a copy link control. The link address corresponding to this copy link control points to a preset intermediate guide page, android-redirect.html.

[0152] After the user clicks the copy link control, the page creates a hidden input element and copies the intermediate landing page address to the system clipboard using a compatible method of selecting and executing execCommand('copy'). This copying method is only an example; in other implementations, the copy interface provided by the Clipboard API or WeChat JS-SDK can also be used. A Toast notification indicating successful copying is displayed. The user then pastes and opens the link in the system's built-in browser (such as Chrome or the browser provided by each vendor).

[0153] In the system browser environment, after the android-redirect.html page loads, it executes the following logic: First, it attempts to directly launch the client application via an intent protocol link. The intent link format is intent: / / path#Intent;scheme=example;package=com.example.app;end. If the client application is already installed, the system will display an application selection dialog box or directly launch the client application, allowing the user to continue subsequent business processes within the client application. If the client application is not installed, the system browser cannot process the intent request. The page will capture this failure event and automatically redirect to the download page of Tencent App Store or other application distribution platforms, guiding the user to download and install the client application.

[0154] By employing the aforementioned differentiated processing on the Android platform, the low launch success rate issue inherent in embedded web pages within mini-programs is avoided. The launch action is redirected to the system browser environment, significantly improving the launch success rate on the Android platform. Simultaneously, for users who haven't installed the application, clear download guidance is provided through distribution platforms such as App Store, ensuring a complete user experience.

[0155] Example 6

[0156] See Figure 6 This embodiment uses a scenario of a second page refresh after page restoration as an example to explain in detail the state reset mechanism of the present invention. This mechanism is involved in all the foregoing embodiments, and this embodiment focuses on explaining its working principle.

[0157] When a user completes a launch action and returns to the page, if the page state is not reset, the launch button on the page will remain unavailable or unresponsive after being clicked. This is because the state machine remains in the OPENED or FAILED state and will not respond to new click commands.

[0158] To address this issue, this application continuously listens for the pageshow event after the page has finished loading. The pageshow event is triggered when the page is first loaded and also when the page is restored from the browser's round-trip cache. When the user switches back to the browser from the client application or returns to the embedded webpage from an external browser, the pageshow event is triggered, and its persisted property indicates whether the page has been restored from the cache.

[0159] In this embodiment, when the state reset module captures the pageshow event, it first reads the current state value of the state machine. If the current state is OPENED (open) or FAILED (failed), the state reset module forcibly resets the state machine to READY. After the reset is complete, the wake-up button on the page changes from grayed-out to highlighted and displays the text "Open App". When the user clicks the button again, the state machine changes from READY to LAUNCHING, and the complete wake-up process is re-executed, including recording the trigger time, listening for changes in page visibility and client callback events, and starting the first and second preset time windows for judgment.

[0160] It's important to note that if the page is reclaimed by the system while the user is away from it, the state machine will be reinitialized to the initial INIT state upon page reload and automatically switch to the READY state after page loading is complete. Therefore, whether the page is reloaded after being reclaimed or restored from the cache, the state reset module ensures the availability of buttons after page restoration, achieving true support for secondary page refreshes.

[0161] Furthermore, this embodiment also includes a state exception reset mechanism. If the state machine remains in the LAUNCHING state for more than the second preset time window Tfail due to unknown reasons (such as abnormal page script execution, system interruption, etc.) without transitioning to the OPENED or FAILED state, the state machine will automatically force a switch to the FAILED state, subsequently triggering a degradation boot process. This mechanism avoids the problem of the state machine permanently getting stuck in the LAUNCHING state and the user interface becoming unresponsive for extended periods due to abnormal situations, further improving the system's robustness.

[0162] Example 7

[0163] This embodiment provides a detailed description of the non-blocking reporting mechanism of the present invention.

[0164] See Figure 7 In this invention, the redirection information storage interface `storeRedirectInfo` is designed to operate in non-blocking mode. Specifically, on the mini-program side, when the reporting module calls this interface, it uses an asynchronous request method, that is, it initiates a network request using an XMLHttpRequest object or the asynchronous mode of the fetch API, and sets a timeout timer for this request, preferably 800 milliseconds.

[0165] The reporting module's calling logic is as follows: First, a reporting request object is created, the request method is set to POST, the Content-Type in the request header is set to application / json, and the request body contains the following fields: sourceType (source type, fixed as the mini-program identifier), redirectType (business type, such as live streaming, product, order, etc.), scheme (application general link), userId (user identifier), and timestamp (current timestamp). Then, an asynchronous request is initiated, and an 800-millisecond timeout timer is started.

[0166] Within 800 milliseconds, if the request returns a success status code, the reporting module records a success log but does not perform any subsequent actions; if the request returns a failure status code, the reporting module records a failure log, also without performing any subsequent actions; if the request still has not returned when the 800-millisecond timeout timer is triggered, the reporting module actively terminates the request, records a timeout log, and immediately executes the subsequent process. The reporting module also has an exception handling mechanism. When a network exception occurs during the request process (such as network disconnection, DNS resolution failure, etc.), the exception handling mechanism captures the exception and records it in the log, but does not throw the exception to the upper-level caller.

[0167] Regardless of which of the three scenarios occurs, the reporting module immediately calls the page redirection function after completing log recording, redirecting the mini-program to the embedded webpage. Because the reporting process and the redirection process are completely decoupled at the code level, the execution result of the reporting process will not affect the startup timing or execution status of the redirection process in any way.

[0168] Through the above non-blocking reporting mechanism, even in extreme situations such as weak network environment, high server load or interface failure, the user's wake-up operation will not be affected by the delay or failure of the reporting interface, thus ensuring the availability of the core wake-up function.

[0169] Example 8

[0170] This embodiment describes an implementation of the present invention applicable to computer devices and storage media.

[0171] The method provided by this invention can be deployed as a computer program on various computing devices. These computer devices include, but are not limited to, smartphones, tablets, laptops, desktop computers, and servers. Each computer device includes at least a processor and a memory, wherein the memory stores computer programs and related data, and the processor executes the computer programs stored in the memory to implement the methods described in the embodiments of this invention.

[0172] The storage medium can be any medium capable of storing a computer program, including but not limited to read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical disk storage media, flash memory storage devices, etc. When the computer program stored on the storage medium is executed by a processor, it implements all or part of the steps of the methods described in the various embodiments of the present invention.

[0173] In practical deployment, the solution of this invention can adopt a client-server architecture. The logic of the mini-program and embedded webpage is deployed as JavaScript code on the user's terminal device. When the user accesses the mini-program or embedded webpage, it is dynamically loaded and executed by the terminal device's browser engine or WebView component. The server-side fallback page processing module and redirection information storage interface are implemented in backend languages ​​such as Java, Python, and Node.js, deployed in a cloud server or data center, and communicate with the client via HTTP / HTTPS protocols.

[0174] It should be understood that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0175] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for determining the wake-up result of a client application in a webpage environment embedded in a mini-program, characterized in that, include: In response to a wake-up command, the trigger time of the wake-up command is recorded; Listen to a preset set of events and page visibility change events, wherein the set of events includes at least a client callback event used to indicate the result of the invocation operation; Set a first preset time window and a second preset time window, wherein the duration of the first preset time window is shorter than the duration of the second preset time window; If the page visibility change event is detected within the first preset time window, indicating that the current page has switched to an invisible state, or if the first type of event in the event set is detected, then the client application is determined to have been successfully launched. If the page remains visible within the second preset time window and no first type of event is detected, or a second type of event in the event set is detected, then the client application is determined to have failed to launch.

2. The method according to claim 1, characterized in that, The wake-up triggering instruction includes a click instruction triggered by the user clicking the wake-up control, or an automatic wake-up instruction that is automatically executed after the page is loaded; The duration of the first preset time window and / or the second preset time window is dynamically adjusted according to the performance level of the terminal device or the current network latency; And / or, the method further includes: when the page is switched to an invisible state, starting a timer; if the page becomes visible again within the first preset time window and no first type of event is detected, then canceling the successful wake-up determination result and marking the state as unknown or failed.

3. The method according to claim 1, characterized in that, Also includes: A state machine is constructed based on the wake-up trigger instruction, and the state machine includes at least an initial state, a ready state, a wake-up state, an open state, and a failed state. When the wake-up trigger command is received, the state machine switches from the ready state to the wake-up state; When it is determined that the client application has been successfully invoked, the state machine switches from the invoked state to the in-open state; When it is determined that the client application has failed to be woken up, the state machine switches from the wake-up state to the failure state.

4. The method according to claim 1, characterized in that, Also includes: Before the trigger command is executed, the jump information storage interface is called to report the business source information and application link information of this jump; The call result of the jump information storage interface is decoupled from the subsequent wake-up process. That is, regardless of whether the jump information storage interface returns success, failure or timeout, the client application wake-up action corresponding to the wake-up trigger instruction will continue to be executed.

5. The method according to claim 1, characterized in that, Also includes: When it is determined that the client application fails to be invoked or no definite result is obtained, the operating system type of the current terminal device is identified; If the operating system type is a first type system, then the first downgrade boot strategy is executed; If the operating system type is a second type of system, then a second downgrade boot strategy, different from the first downgrade boot strategy, is executed.

6. The method according to claim 5, characterized in that, The first downgrade boot strategy includes: A copy link control is displayed, and the link address corresponding to the copy link control points to a preset application distribution guide page, which is used to guide users to jump to the official application store. The address of the preset application distribution guide page is configured as the binding path of a universal link. When the client application is not installed, the binding path pointed to by the universal link is opened by the system to display the application distribution guide page.

7. The method according to claim 5, characterized in that, The second downgrade guidance strategy includes: Display a copy link control, the link address of which points to a preset intermediate guide page, and prompt the user to open the intermediate guide page in the system browser; The intermediate redirection page is used to relaunch the client application in the system browser environment, or to redirect to a third-party application distribution platform.

8. A method for reliable launch and adaptive degradation of client applications in a webpage environment embedded in a mini-program, characterized in that, include: The client application wake-up result is determined by the method described in any one of claims 1 to 4; Non-blocking jump information reporting is performed using the method described in claim 5; When the wake-up failure or unknown is determined, the platform adaptive degradation boot is performed using the method described in any one of claims 6 to 7. In scenarios where a universal link is used for invocation, the binding path of the universal link is configured to point to the access address of a real fallback onboarding page; when the terminal system responds to the open request of the universal link and the client application is not installed, the terminal system loads and displays the fallback onboarding page; the fallback onboarding page contains application identification information, guidance text, and a link to the app store; After the wake-up process ends and the page becomes visible again, the pre-built wake-up state machine is reset to the ready state; after the reset, in response to the wake-up operation command triggered by the user again, the client application wake-up process is re-executed.

9. The method according to claim 8, characterized in that, The configuration of the binding path of the universal link to point to the access address of a real fallback page specifically includes: The server hosting the fallback guide page is pre-configured with path rewriting rules. These rules are used to identify general link access requests from mobile terminal browsers and return the HTML content of the fallback guide page, while ensuring that the configuration file used by the terminal system for application wake-up is not overwritten or corrupted.

10. A reliable wake-up and adaptive degradation system for client applications embedded in a webpage environment within a mini-program, characterized in that, include: The parameter generation module is used to generate jump parameters on the mini-program side. The jump parameters include at least the source identifier, business type, and invocation protocol link. The reporting module is used to call the jump information storage interface before the actual jump to report the jump parameters in a non-blocking manner. The execution result of the reporting module is decoupled from the subsequent wake-up action. An embedded webpage initialization module is used to load the embedded webpage and read the jump parameters, as well as initialize the software development kit configuration on the webpage side; Also includes: A state machine detection module is used to execute the method as described in any one of claims 1 to 4 to determine the client application wake-up result; The platform identification module is used to identify the operating system type of the current terminal device; The downgrade guidance module is used to perform differentiated downgrade guidance according to the determination result of the state machine detection module and the identification result of the platform identification module, as described in any one of claims 6 to 8. The fallback page processing module is used to configure and return the fallback guide page to handle access requests in scenarios where the general link is not installed; The state reset module is used to reset the state machine to the ready state after the page is restored.

Images