Client-run method, computing device, computer-readable storage medium, and computer program product

Abstract

Embodiments of the present application provide a client running method, a computing device, a computer readable storage medium and a computer program product. The client running method comprises: receiving stutter information sent by a first client, the stutter information being generated in the case that the first client detects a stutter event; the stutter information comprising function information of a target function corresponding to the stutter event; analyzing the stutter information to obtain the function information of the target function; generating stutter prompt information based on the function information; and sending the stutter prompt information to a target client in a silent push manner, so that the target client adjusts an execution operation of the target function based on the stutter prompt information, wherein the target client comprises the first client and / or a second client. The technical solution provided by the embodiments of the present application improves the stutter optimization efficiency of the client.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a client running method, computing device, computer-readable storage medium, and computer program product. Background Technology

[0002] During client-side operation, stuttering typically refers to phenomena such as delayed application interface response, stagnant operation feedback, or dropped animation frames. Essentially, it is because the application's main thread fails to process user input or complete rendering tasks in a timely manner, resulting in a decrease in the perceived smoothness of interaction for the user.

[0003] In the process of realizing the concept of this application, the inventors discovered that in related technologies, when optimizing lag, it is usually necessary to release the client version to the user's terminal device through iteration. That is, after completing the code modification and testing, the new version is pushed to the user in the form of an installation package. Only after the user updates the application can they enjoy the lag optimization effect.

[0004] However, this method of optimizing performance by relying on version iterations has a long fix cycle, resulting in a poor user experience. Summary of the Invention

[0005] This application provides a client running method, a computing device, a computer-readable storage medium, and a computer program product.

[0006] In a first aspect, this application provides a client-side operation method applied to a server, the method comprising:

[0007] The system receives lag information sent by a first client, which is generated when the first client detects a lag event. The lag information includes function information of the target function corresponding to the lag event, and the target function includes the function currently being executed by the first client when the lag event occurs.

[0008] The lag information is analyzed to obtain the function information of the objective function;

[0009] Based on the function information, a stuttering warning message is generated;

[0010] The lag notification information is sent to the target client in a silent push manner, so that the target client can adjust the execution operation of the target function based on the lag notification information. The target client includes the first client and / or the second client, and the second client is a second client that matches the first client.

[0011] Secondly, this application provides a client running method, applied to a first client, the method comprising:

[0012] When a lag event is detected, lag information is collected.

[0013] The lag information is sent to the server so that the server can parse the lag information, obtain the function information of the target function, and generate lag prompt information based on the function information. The target function is the function currently being executed by the first client when the lag event occurs.

[0014] Receive the lag notification information sent by the server in a silent push manner;

[0015] Based on the lag warning information, adjust the execution operation of the objective function.

[0016] Thirdly, this application provides a client running method, applied to a second client, the method comprising:

[0017] The system receives a lag notification from the server. The lag notification is generated based on the function information contained in the lag information. The lag information is generated when the first client detects a lag event. The function information is the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs. The lag notification is used to prompt adjustments to the execution of the target function.

[0018] Based on the lag warning information, adjust the execution operation of the objective function.

[0019] Fourthly, this application provides a client-side operating device applied to a server, the device comprising:

[0020] The first receiving module is used to receive lag information sent by the first client. The lag information is generated when the first client detects a lag event. The lag information includes function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs.

[0021] The parsing module is used to parse the stuttering information and obtain the function information of the target function;

[0022] The information generation module is used to generate lag prompt information based on the function information;

[0023] The push module is used to send the lag notification information to the target client in a silent push manner, so that the target client can adjust the execution operation of the target function based on the lag notification information. The target client includes the first client and / or the second client, and the second client is a second client matched with the first client.

[0024] Fifthly, this application provides a client running method, applied to a first client, the method comprising:

[0025] The information acquisition module is used to collect lag information when a lag event is detected.

[0026] The information sending module is used to send the lag information to the server so that the server can parse the lag information, obtain the function information of the target function, and generate lag prompt information based on the function information. The target function is the function currently being executed by the first client when the lag event occurs.

[0027] The second receiving module is used to receive the lag notification information sent by the server in a silent push manner;

[0028] The first operation adjustment module is used to adjust the execution operation of the target function based on the lag prompt information.

[0029] Sixthly, this application provides a client running method applied to a second client, the method comprising:

[0030] The third receiving module is used to receive lag prompt information sent by the server. The lag prompt information is generated based on the function information contained in the lag information. The lag information is generated when the first client detects a lag event. The function information is the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs. The lag prompt information is used to prompt adjustment of the execution operation of the target function.

[0031] The second operation adjustment module is used to adjust the execution operation of the target function based on the lag prompt information.

[0032] In a seventh aspect, embodiments of this application provide a computing device, including a processing component and a storage component;

[0033] The storage component stores a computer program; the computer program is invoked and executed by the processing component to implement the client running method provided in this application embodiment.

[0034] Eighthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processing component, implements the client running method provided in this application.

[0035] Ninthly, this application provides a computer program product, including a computer program or instructions, which, when executed by a processing component, implement the client running method provided in this application.

[0036] In the embodiments of this application, when the first client detects a lag event, it obtains the function information of the target function currently being executed at the time of the lag event and sends the lag information containing the function information to the server. This enables the server to generate lag prompts for adjusting the operation of the target function and sends these prompts to the target client via silent push. The target client can then adjust the execution of the target function based on the lag prompts during runtime, achieving lag optimization. Through this technical solution, on the one hand, after the target client detects a lag event and reports lag information during runtime, the server can directly generate targeted lag prompts based on the function information and deliver them to the target client instantly via silent push. The target client does not need to wait for application version iterations or go through the lengthy process of code recompilation and release; it can directly adjust the execution of the target function. This end-to-end process from lag occurrence to optimization execution eliminates the testing, review, and user download stages in version updates, significantly shortening the optimization cycle and significantly improving the overall efficiency of lag optimization. On the other hand, by combining silent push notifications with dynamic adjustments to execution operations, the target client can adjust the execution operations of the target function based on the lag warning information without restarting the application or terminal device. The entire process is completed in the background without interrupting the main thread, ensuring uninterrupted user experience. This allows lag optimization to take effect in real time without the user noticing, achieving seamless, real-time optimization. Furthermore, the lag information includes the function information of the target function that was executing at the time of the lag event. The lag warning information generated by the server is also targeted at this target function. The target client then performs corresponding adjustments to the target function, avoiding the generalized adjustments at the client-wide or system-level level found in traditional lag optimization. This precise intervention targeting the target function directly addresses the root cause of lag, achieving function-level lag optimization and improving the targeting and effectiveness of lag optimization.

[0037] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0038] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0039] Figure 1 A system architecture diagram illustrating a technical solution of an embodiment of this application that can be applied thereto is shown;

[0040] Figure 2 A flowchart of an embodiment of a client operation method provided in this application;

[0041] Figure 3 A flowchart illustrating a client operation method provided in another embodiment of this application;

[0042] Figure 4 A flowchart illustrating a client operation method provided in another embodiment of this application;

[0043] Figure 5 A block diagram of a client running device provided in one embodiment of this application;

[0044] Figure 6 A block diagram of a client running device provided in one embodiment of this application;

[0045] Figure 7 A block diagram of a client running device provided in one embodiment of this application;

[0046] Figure 8 This is a block diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0049] During client-side operation, stuttering typically refers to phenomena such as delayed application interface response, stagnant operation feedback, or dropped animation frames. Essentially, it's because the application's main thread fails to process user input or complete rendering tasks in a timely manner, resulting in a decrease in the perceived smoothness of interaction for the user. This phenomenon is often related to function execution logic. When an application calls functions with excessively long execution times (such as complex calculations, large amounts of data parsing, or unoptimized UI rendering functions) on the main thread, it consumes main thread resources, blocks the execution of subsequent tasks, and thus causes stuttering.

[0050] In the process of realizing the concept of this application, the inventors discovered that in related technologies, after locating the function causing the lag through online monitoring tools or offline debugging tools, the developers optimize the function and release it to the user's device through application version iteration. That is, after completing the code modification and testing, it is pushed to the user in the form of a new version installation package. The user can only enjoy the optimization effect after updating the application.

[0051] However, this optimization method, which relies on version iterations, has a long fix cycle, resulting in a poor user experience.

[0052] To address the technical problem of long repair cycles leading to poor user experience, this application provides a solution. The basic idea is as follows: The server receives lag information from a first client, generated when the first client detects a lag event. This lag information includes function information of the target function corresponding to the lag event. The server parses the lag information to obtain the function information of the target function. Based on the function information, a lag warning message is generated. This message is then silently pushed to a target client, allowing the target client to adjust the execution of the target function based on the warning message. The target client includes the first client and / or a second client. Therefore, when the first client detects a lag event and sends lag information containing target function information, the server can quickly parse the information and generate targeted lag warning messages, then silently push these messages to the target client. This process eliminates the need for lengthy version iteration processes such as code modification, testing, version packaging, and user updates, thus quickly optimizing client-side lag performance.

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] Figure 1A system architecture diagram is shown that can be applied to a technical solution of an embodiment of this application. The system architecture may include a client 101 and a server 102.

[0055] In this system, client 101 and server 102 can establish a connection via a network. The network provides a communication link between client 101 and server 102. The network can include various connection types, such as wired, wireless, or fiber optic cable. Client 101 can interact with server 102 via the network to receive or send messages, etc.

[0056] The client 101 can be a browser, an app (application), a web application such as an H5 (HyperText Markup Language 5) application, a lightweight application (also known as a mini-program), or a cloud application. The client 101 can be deployed on a terminal device and depends on the device or certain apps on the device to run. The terminal device can have a display screen and support information browsing, such as a personal mobile terminal like a mobile phone, tablet, personal computer, desktop computer, smart speaker, smartwatch, etc. For ease of understanding, Figure 1 The client is primarily represented by the image of a device. Various other types of applications can typically be configured on the terminal device, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc. A terminal device can refer to a device used by a user that has the computing, internet access, and communication functions required by the user, such as a mobile phone, tablet computer, personal computer, wearable device, etc. A terminal device typically includes at least one processing component and at least one storage component. A terminal device may also include basic configurations such as a network interface card (NIC) chip, I / O (input / output) bus, and audio / video components; this application does not limit its scope. Optionally, depending on the implementation of the terminal device, it may also include some peripheral devices, such as a keyboard, mouse, input pen, printer, etc.; this application does not limit its scope either.

[0057] Server 102 may include servers that provide various services, such as a server for background training that supports the model used on client 101, or a server that processes interactive information sent by the client.

[0058] It should be noted that server 102 can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. The server can also be a server in a distributed system, or a server integrated with blockchain. The server can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0059] It should be noted that the client-side running method provided in this application embodiment is generally executed by the server 102, and the corresponding client-side running device is generally located in the server 102. However, in other embodiments of this application, the client 101 may also have similar functions to the server 102, thereby executing the client-side running method provided in this application embodiment. In other embodiments, the client-side running method provided in this application embodiment may also be jointly executed by the client 101 and the server 102.

[0060] It should be understood that Figure 1 The number of clients and servers shown is merely illustrative. Depending on implementation needs, there can be any number of clients and servers.

[0061] The implementation details of the technical solutions in the embodiments of this application are described in detail below.

[0062] Figure 2 This is a flowchart of an embodiment of a client running method provided in this application, which can be applied to a server.

[0063] Figure 2 The client execution method shown may include the following steps:

[0064] 201: Receive lag information sent by the first client. The lag information is generated when the first client detects a lag event. The lag information includes the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs.

[0065] In the embodiments of this application, the first client can use a performance monitoring tool to monitor its own operating status in real time. The performance monitoring tool can be used to capture the occurrence of lag events and record lag information related to lag. Here, a lag event can refer to a situation such as interface stagnation or response delay that occurs when the first client performs an operation. For example, when a user uses the first client to perform page navigation, data loading, or interactive operations, the first client fails to complete the corresponding processing within the expected time, resulting in no feedback or slow feedback for the user's operation.

[0066] The lag information may include, for example, the function information of the target function that caused the lag. This function information may include, for example, the function's name, unique identifier, or other characteristic information that accurately points to the function. The target function can be the function that is executing when the lag occurs and may directly or indirectly cause the lag. For example, in an e-commerce application, the function responsible for loading images on a product details page may block the main thread due to processing a large amount of data, thus causing a lag. In this case, this function would be considered the target function.

[0067] 202: Analyze the stuttering information to obtain the function information of the objective function.

[0068] 203: Generate stuttering warning messages based on function information.

[0069] After receiving the lag information sent by the first client, the server can parse the lag information to extract the function information of the target function that caused the lag in the first client.

[0070] After extracting the function information of the target function, the server can generate stuttering prompts based on this information. These stuttering prompts can be instructive messages designed to guide the client in adjusting the execution logic of the target function, including instructions on how to adjust its execution to ensure the client can accurately perform the necessary adjustments.

[0071] 204: Send a stuttering notification to the target client in a silent push manner so that the target client can adjust the execution of the target function based on the stuttering notification. The target client includes a first client and / or a second client, and the second client is a second client that matches the first client.

[0072] After generating a lag warning message, the server can send the message to the target client using a silent push method. Silent push means sending the message to the client in the background without disturbing the user. The client receives the message but does not display any notification pop-ups or prompts; instead, it processes the message directly in the background.

[0073] The target client may include a first client that sends lag information and / or a second client that matches the first client. Matching the first client means that the second client may have the same lag risk as the first client. By sending lag information to the target client, the target client can make corresponding adjustments to the execution of the target function based on the lag information, thereby avoiding or mitigating the occurrence of lag and improving the client's running performance and user experience.

[0074] In realizing the concept of this application, the inventors also conceived of using a hot update method, generating a configuration file based on the update code and distributing it to the client. For example, lag optimization for clients experiencing stuttering could be achieved through RUS (ROM update system). This involves generating the update code, converting it into a configuration file conforming to the ROM update specification, and then pushing the configuration file to the client. When the configuration file is pushed to the client, the client will prompt the user to update when the device is in a specific state such as charging or idle; in some scenarios, manual confirmation from the user is even required. During the update process, the device will reboot into Recovery mode. After the reboot is complete, the stuttering warning information contained in the configuration file will officially take effect—at this point, when the client runs, the execution logic of the original stuttering function has been updated, thereby alleviating the stuttering problem. However, stuttering optimization implemented using RUS not only interrupts the user's use of the client, but the stuttering optimization strategy also cannot take effect within a short period after the stuttering occurs, causing the optimization response to lag behind the stuttering event.

[0075] In the embodiments of this application, when the first client detects a lag event, it obtains the function information of the target function currently being executed at the time of the lag event, and sends the lag information containing the function information to the server. This enables the server to generate lag prompts that adjust the operation of the target function, and sends the lag prompts to the target client via silent push. The target client can then adjust the execution of the target function based on the lag prompts during operation, achieving lag optimization. Through this technical solution, on the one hand, there is no need to convert the lag prompts into a configuration file conforming to ROM specifications, nor is it necessary to wait for the device to be charging or idle, nor is it necessary for the user to manually confirm the update—through silent push, the lag prompts are delivered to the target client immediately after being generated by the server. The entire process is completed in the background, without interrupting the user's ongoing operations, and without requiring the device to restart into Recovery mode. Upon receiving the information, the target client can dynamically adjust the execution of the target function during runtime. From the occurrence of a stuttering event to the activation of the optimization strategy, there is no need for lengthy processes such as vendor review and scheduling, or users waiting for updates. This allows stuttering optimization to take effect in real time, ensuring user continuity and improving the timeliness and efficiency of optimization. Furthermore, by combining silent push notifications with dynamic adjustments, the target client adjusts the execution of the target function based on stuttering alerts without restarting the application or terminal device. The entire process is completed in the background without interrupting the main thread, ensuring uninterrupted user experience. This allows stuttering optimization to take effect in real time without the user's awareness, achieving seamless, real-time optimization. Moreover, the stuttering information includes the function information of the target function being executed at the time of the stuttering event. The stuttering alerts generated by the server are also specific to this target function. The target client then performs corresponding adjustments to the target function, avoiding the generalized adjustments at the client-wide or system-level in traditional stuttering optimization. Precise intervention at the target function directly addresses the root cause of stuttering, achieving function-level stuttering optimization and improving its targeting and effectiveness.

[0076] Compared to hot updates, which often require pushing a full update package containing a large amount of code or resources, resulting in a large update package size, this approach addresses the issue of resource consumption. This not only consumes more network bandwidth and prolongs transmission time but can also negatively impact user experience due to prolonged download times, potentially leading to update failures and the need for re-downloading. Furthermore, processing a full update package consumes more hardware resources on the client side. In this solution, when the first client experiences a stutter and reports the target function information, the server generates a targeted stuttering alert only for that target function and sends it to the target client via silent push. The stuttering alert only contains instructions related to adjusting the target function's execution, is smaller than the full update package, and can be quickly transmitted over the network and received by the client. Simultaneously, the client does not need to process redundant update content; it only needs to precisely adjust the execution of the target function based on the alert. This process avoids the resource consumption and transmission delays associated with full updates while achieving precise function-level control, making stuttering optimization more efficient and targeted. In some embodiments, the stuttering information also includes the target description information of the first client. The method may also include:

[0077] Parse the lag information to obtain target description information; the target description information includes at least one of device description information and the version number of the first client, and the device description information is the description information of the terminal device on which the first client is installed;

[0078] Based on the target description information, a second client that matches the first client is identified.

[0079] In the embodiments of this application, the lag information may include not only the function information of the objective function, but also the objective description information of the first client. The server can identify the characteristics of the first client based on the objective description information, thereby accurately locating the second client with potential lag risks. Specifically, the objective description information may include the device description information of the terminal device on which the first client is installed, and the version number of the first client itself. The device description information is used to reflect the hardware and system characteristics of the terminal device in detail, such as the specific model of the terminal device, the name and version of the operating system, the processor model, and the size of the running memory. This information together constitutes a unique identifier for the terminal device, making it easy for the server to distinguish different types of terminal devices. The version number of the first client is used to identify the iterative version of the client application, for example, it may be presented in the form of "V2.5.1" or "3.0.0 beta". Different versions of the client may have differences in functional implementation and code logic. Accurately obtaining the version number helps the server determine whether the lag problem is related to a specific version.

[0080] Therefore, a second client that matches the first client can be determined based on the target description information.

[0081] This matching mechanism based on target description information allows the push notification of lag alerts to extend beyond the first client that has already experienced lag to all second clients that may be affected by the same issue. As a result, before lag actually occurs on the second client, the objective function can be adjusted based on the lag alerts, shifting from passively resolving existing lag to proactively preventing potential lag, thus expanding the scope of optimization and allowing more users to avoid encountering the same experience problems.

[0082] In one implementation of this application, the stuttering notification message can be implemented as follows:

[0083] {

[0084] "aps": {

[0085] "data": {

[0086] "os": "X",

[0087] "model": "Y",

[0088] "stack": "-[CoreFrameworkConfig showMainPage]",

[0089] "isAsyn": true,

[0090] "isStop": false

[0091] },

[0092] "content-available": 1

[0093] }

[0094] }

[0095] Here, "os" can represent the system version of the terminal device, "model" can represent the model of the terminal device, "stack" can represent the function information of the target function, "isAsyn" and "isStop" can respectively represent a function execution adjustment operation. For example, "isAsyn" can indicate whether to execute the target function asynchronously, and "isStop" can indicate whether to block the execution of the target function. In the example above, "isAsyn" is true, which means that the target function can be executed asynchronously. "content-available": 1 can indicate that the lag prompt message is a silent push message.

[0096] The above-mentioned lag message indicates that the target function [CoreFrameworkConfig showMainPage] has been adjusted to be executed asynchronously on the terminal device of model Y on system version X.

[0097] After receiving the lag notification, the target client can verify the lag notification using the "os" and "model" in the notification. If the "os" and "model" match the device information of the terminal device currently deployed on the client, the client can perform the corresponding adjustment operation, thereby avoiding erroneous execution.

[0098] In some embodiments, determining the second client that matches the first client based on the target description information can be specifically implemented as follows:

[0099] Select a second client from the client cluster that matches both the version number and the device description information; or...

[0100] Filter the client cluster to find a second client that matches the version number or the device description information.

[0101] In the embodiments of this application, when the server filters the second client, it first retrieves a preset client cluster database. This database stores detailed information about all registered clients that communicate with the server, including device description information (such as model, system version, hardware configuration, etc.) and the client's own version number. This information is updated periodically to ensure data timeliness. For example, when a client completes a version upgrade or device system update, it will actively synchronize the latest information with the server. The server then updates the database after confirming the accuracy of the information through a data verification mechanism.

[0102] In one possible implementation of this application, the server can filter out second clients from the client cluster that match the version number and device description information of the first client. Version number matching can mean that the application version number of the second client is the same as the version number of the first client; while device description information matching can mean that the device characteristics of the second client are consistent with those of the first client, such as the same device model or system version. The server can use a database query statement to use the version number and device description information as joint query conditions to extract a list of second clients that meet the conditions from the query results.

[0103] In another possible implementation of this application, the server can filter out a second client from the client cluster that matches the version number or device description information of the first client.

[0104] In practical applications, the server can select appropriate filtering logic based on the specific characteristics of the lag event. For example, if the lag event of the first client is initially analyzed to be highly likely to be a compatibility issue of a specific version on a specific device, an "AND" logic is used for precise filtering; if the lag event may be related to version iteration or device hardware characteristics, but the evidence is insufficient, an "OR" logic is used to broaden the filtering scope. After filtering, the server can perform a secondary verification on the selected second client to check whether its communication status with the server is normal, ensuring that the lag notification information can be successfully pushed. The final determined second client will, together with the first client, constitute the target client to receive the lag notification information sent by the server.

[0105] It should be noted that this application embodiment is not a repetition of single technologies such as silent push or function execution operation adjustment, but rather breaks the original application boundaries of these technologies, organically integrating technologies from different fields to form a completely new solution. Traditionally, silent push technology is mostly used in message notification scenarios, such as pushing news reminders or application update prompts to users in the background, the core of which is to complete the one-way transmission of information; while function execution operation adjustment technology is mainly used for performance tuning within a single client, avoiding lag on a single device by separating time-consuming operations from the main thread, but its scope is limited to the current device and cannot extend to other terminals. This application embodiment combines silent push technology and performance optimization technology to build a cross-device real-time response closed loop: when the first client lags, the server can quickly collect lag information and locate the key target function. After generating lag prompt information based on this information, the server uses silent push technology to accurately send the lag prompt information to a second client with the same device characteristics (such as model and system version), and then uses function asynchronous execution operation intervention strategies to allow the first client and / or the second client to complete the function execution operation adjustment in the background.

[0106] This cross-domain technology combination leverages the efficiency of silent push in background information transmission, utilizes the practicality of asynchronous functions in performance optimization, and achieves precise positioning of target clients through a device tagging system. The synergistic effect of these three technologies upgrades lag optimization from "post-event remediation for a single device" to "real-time prevention across multiple devices," solving the core problem of existing technologies' inability to optimize lag across devices in real time, and achieving a breakthrough from fragmented technology applications to a systemic solution.

[0107] In some embodiments, when determining a second client that matches the first client based on target description information, in addition to version number and device description information, device performance information can be further combined for filtering, making the matching results more closely related to the actual scenarios of lag risk. Device performance information can include the hardware configuration parameters of the terminal device where the client is installed (such as CPU model, number of cores, clock speed, memory capacity and type, GPU model, and read / write speed of storage media) and real-time performance status (such as current CPU load, memory usage, number of background processes, battery level, and power consumption mode). In one implementation, a second client matching the first client in terms of device performance information can be selected from the client cluster: for example, if the device performance information of the first client shows that it has a certain type of processor, 12GB of LPDDR5 memory, and a current CPU load of approximately 70%, then clients with the same CPU model, memory capacity difference of no more than 4GB, and real-time CPU load in the 60%-80% range can be prioritized for matching. These clients, due to their similar hardware and real-time load status, are more likely to face similar resource bottlenecks when executing the same functions, thus having the same lag risk.

[0108] In some embodiments, generating stuttering warning information based on function information can be specifically implemented as follows:

[0109] Obtain the pre-configured strategy library, which records the execution operation intervention strategies corresponding to multiple functions;

[0110] Based on function information, the target execution operation intervention strategy corresponding to the target function is searched from the pre-configured strategy library;

[0111] Based on the target execution operation intervention strategy, a lag prompt message is generated.

[0112] In the embodiments of this application, the server can pre-build and maintain a pre-configured strategy library. This library can be established based on a large amount of historical lag data, function execution characteristic analysis, and summaries of manual optimization experience. The pre-configured strategy library can record multiple function-specific intervention strategies. Each record contains a unique identifier for the function (such as function name, feature code, etc.) and the corresponding intervention strategy content. The function identifier can maintain a format consistent with the function information that the client may send. The pre-configured strategy library can use a matching string as the identifier, while the intervention strategy content specifies the concrete adjustments to be made when the function experiences lag, ensuring the executability of the strategy.

[0113] After parsing the stuttering information on the server side to obtain the function information of the target function, the matching process with the pre-configured strategy library can be initiated. To ensure the accuracy of the matching, the server can first standardize the function information of the target function, such as removing potentially redundant characters in the function name and unifying the capitalization (if the function name sent by the client has a different format), so that the identifier of the function to be matched is consistent with the record format in the strategy library. Subsequently, the server can search the strategy library using a preset matching algorithm to obtain the search results.

[0114] After determining the target function and the corresponding intervention strategy, the server can generate a stuttering message based on this strategy. The stuttering message can contain two core parts: first, it clearly points to the target function that needs adjustment, ensuring the client can accurately identify the corresponding function; second, it describes the specific content of the intervention strategy, such as the required adjustment method for the target function and the triggering conditions (e.g., execution in a specific scenario), enabling the client to directly perform the corresponding operation according to the message after receiving it.

[0115] In another embodiment of this application, when generating stuttering prompts based on function information, in addition to relying on the characteristics of the function itself, the search logic can be further refined by combining device description information and version number, making the matching of the target execution operation intervention strategy more closely match the actual operating environment of the client. The pre-configured strategy library can not only record the basic execution operation intervention strategies corresponding to multiple functions, but also set multiple sets of differentiated strategies for the same function based on different device description information and client version number. For example, for a data loading function, when the device description information is "Type 1" and the client version number is "4.2.0", the corresponding strategy is "asynchronous function execution"; when the device description information is "Type 2" and the client version number is "4.1.0", the corresponding strategy is "block execution".

[0116] When a lag warning message needs to be generated, the server can first locate the policy set of the function in the policy library based on the function information. Then, combined with the device description information and client version number of the first client, it can filter out the target operation intervention policy adapted to the current device and version from the set, and finally generate the lag warning message based on the policy. This search method that combines multi-dimensional information makes the target operation intervention policy more accurately adapted to the actual situation of the client, thereby improving the targeting and effectiveness of lag optimization.

[0117] In the embodiments of this application, stuttering prompts are generated based on function information of the objective function, thereby achieving precise optimization of the stuttering problem of the first client.

[0118] In some embodiments, the stuttering information includes the function call stack of the first client.

[0119] In some embodiments, parsing the stuttering information to obtain the function information of the target function can be specifically implemented as follows:

[0120] Determine the top function from the function call stack;

[0121] Use the function at the top of the stack as the target function;

[0122] Use the name of the objective function as the function information.

[0123] When the first client detects a lag event, it can capture the function call stack at the time of the lag, write this function call stack into the lag information, and send it to the server. The function call stack, as a stack data structure recording the hierarchical relationship of function calls, is generated by the client's built-in performance monitoring module. When a lag event is triggered (such as a main thread timeout), the performance monitoring module obtains the call sequence of all currently active functions through the system interface and stores them as stack frames in the order of their calls. The last function called is located at the top of the stack, i.e., the top function, which is often most directly related to the lag event. For example, if a lag occurs after a user clicks the "Submit Order" button in the first client, the function call stack might contain functions such as "[OrderService checkStock]", "[OrderViewModel submitOrder]", and "[OrderViewController onClick]", with the last executed function, "[OrderService checkStock]", being recorded as the top function in the call stack.

[0124] After obtaining the function call stack, the server can determine the target function. Because the function call stack follows the "last-in, first-out" stack structure, the function at the top of the stack is the function being executed when the stutter occurs, and it is also the most directly related function causing the stutter. Therefore, the server can determine the function at the top of the function call stack as the target function.

[0125] In traditional stuttering information transmission, transmitting the complete function call stack often requires multiple levels of function names, parameter information, and call relationships, resulting in a large data volume. This not only consumes more network bandwidth but can also cause server-side reception delays due to excessive data transmission time, and may even lead to transmission failures in unstable network scenarios. Retransmission further slows down the entire optimization process. In contrast, the top function of the stack, as the function executing when the stutter occurs, is the core function most directly associated with the stuttering event. Its function information (such as the function name) is sufficient for the server to locate the problem and generate optimization strategies, without relying on other levels of information in the complete call stack. Transmitting only the function information of the top function significantly reduces the data volume, which may be just a short string (such as "[CoreFrameworkConfigshowMainPage]"). This lightweight data can quickly pass through the network link during transmission, reducing transmission time and lowering the probability of push failures due to excessive data size, allowing the server to receive critical information and start the processing flow more quickly.

[0126] In this embodiment, based on the stuttering prompt information, only the function information of the top stack function is transmitted, which reduces the information volume from the source of data transmission and thus improves the efficiency of performance optimization.

[0127] The inventors further discovered that, according to the operation intervention strategy determined in the manner described in the above embodiments, for some clients, the execution of the operation intervention strategy may affect the device performance due to device load limitations. Therefore, in order to take into account device performance, in some embodiments, the lag information also includes device performance information, which is used to describe the performance load of the terminal device on which the first client is installed.

[0128] In some embodiments, generating stuttering warning information based on function information can be specifically implemented as follows:

[0129] Analyze the stuttering information to obtain device performance information;

[0130] From a variety of pre-configured execution operation intervention strategies, determine the target execution operation intervention strategy that matches the equipment performance information;

[0131] Based on the target execution operation intervention strategy, a lag prompt message is generated.

[0132] When the first client detects a lag event, in addition to collecting function information of the target function, it can also collect device performance information of the terminal device where the client is located, and write the device performance information into the lag information and send it to the server. Device performance information can be key data reflecting the terminal's operating status when the lag occurs, specifically including but not limited to CPU utilization, memory usage, thread utilization, disk I / O read / write speed, etc.

[0133] In the embodiments of this application, the server can maintain policy matching rules corresponding to different device performance information. The policy matching rules can be formulated based on a large amount of performance test data. For example, when the CPU utilization exceeds 80%, the "asynchronous execution" strategy is preferred to reduce main thread blocking; when the memory utilization is higher than 90%, the "delayed execution" strategy is preferred to avoid memory overflow; when the main thread is blocked for more than 1.5 seconds and the CPU utilization is lower than 50%, the "blocking execution" strategy may be adopted to quickly release resources.

[0134] After parsing the device performance information, the server can match the device performance information with the rules in the pre-configured policy library to determine the target to execute the operation intervention policy.

[0135] Then, the server can silently push a lag warning message containing the intervention strategy for the target execution operation to the target client. After receiving the message, the target client can adjust the execution operation of the target function according to the strategy in the warning message.

[0136] In the embodiments of this application, since the device performance information can reflect the performance parameters of the terminal device such as CPU load, memory usage, and network status, the server can determine the hardware environment of the terminal device when lag occurs. The pre-configured multiple execution operation intervention strategies cover the optimization needs under different performance scenarios and provide adaptation solutions for diverse performance states. As a result, the lag optimization process can be dynamically adjusted according to the changes in the real-time performance parameters of the terminal device, thereby improving the pertinence and effectiveness of lag optimization.

[0137] In some embodiments, when generating stuttering prompts based on function information, device performance information, device description information, and version number can be combined to accurately locate the target execution intervention strategy, making the generated stuttering prompts more consistent with the actual operating scenario of the client. In one implementation, the pre-configured strategy library can not only record the basic execution intervention strategies corresponding to multiple functions, but also include multiple sets of differentiated strategies for the same function based on different device description information, client version number, and device performance information. For example, for a certain image rendering function, the strategy library may store multiple sets of strategies: when the device description information is "low-end model + Android 12", the version number is "3.0.0", and the device performance information shows "CPU load > 80%", the corresponding strategy is "asynchronous execution"; when the device description information is "high-end model + iOS 16", the version number is "3.2.0", and the device performance information shows "memory usage < 50%", the corresponding strategy is "block execution". When it is necessary to generate a stuttering prompt message, the server can first locate the set of strategies for the image rendering function in the strategy library based on the function information, and then combine the device description information, version number and device performance information of the first client to select the most suitable target execution intervention strategy from the set, and finally generate the stuttering prompt message based on the strategy.

[0138] In this embodiment, when the first client detects a lag event, it captures lag information at the time of the event, including the terminal device's device description information, the client version number, and the objective function causing the lag. This lag information is then sent to the server. Upon receiving the information, the server parses and processes it to determine the target client requiring lag optimization and generates a lag warning message. By performing correlation analysis on the key dimensions of the lag problem—terminal device, client version, and objective function—a multi-dimensional data model is constructed. This helps the server accurately locate the lag problem scenario and generate targeted optimization strategies. The core of this modeling method lies in combining device characteristics with software behavior to form a high-precision lag feature profile, achieving the technical effect of single-device lag information collection and cross-device lag optimization. Furthermore, since low-end models typically have limited hardware configurations, such as weak CPU processing power, small memory capacity, or insufficient graphics processing performance, pushing high-load strategies originally designed for high-end models to them may exacerbate lag or even cause applications to become unresponsive because the terminal devices cannot handle the additional load. Therefore, by matching the corresponding execution operation intervention strategy based on device performance information, it is ensured that the operation intervention strategy executed by each terminal device is adapted to its hardware capabilities, thereby improving the effectiveness of lag optimization.

[0139] To avoid invalid push notifications caused by occasional lag events, and thus optimize server resource allocation and client processing efficiency, in some embodiments, the method may further include:

[0140] Determine the cumulative number of stuttering events received for the target function;

[0141] Based on the cumulative quantity, determine whether the objective function meets the execution adjustment conditions;

[0142] If the target function satisfies the execution adjustment, execute the step of sending the lag notification information to the target client in a silent push manner;

[0143] Otherwise, return to the step of checking whether the objective function meets the optimization conditions and continue execution.

[0144] When the server receives a lag message from the first client and parses the function information of the target function, it may not immediately generate and push a lag notification. Instead, it first initiates a mechanism to count the cumulative number of lag events associated with that target function. The server can pre-build a lag event statistics database with a dedicated statistics table. The table fields include the unique identifier of the target function (such as the function name), the corresponding set of client device identifiers, the timestamp of the lag event, and the cumulative number of times. Whenever the server receives a lag message containing a specific target function, it immediately queries and updates the statistics table: first, it checks if a corresponding record exists in the table using the unique identifier of the target function. If it exists, it increments the cumulative number field of that record by 1 and updates the timestamp of the latest lag event; if it does not exist, it creates a new record, initializes the cumulative number to 1, and records the timestamp of the first lag event.

[0145] After updating the cumulative number of stuttering events, the server can use this cumulative number to check whether the target function meets the execution adjustment conditions. The execution adjustment conditions need to be determined comprehensively based on the characteristics of the target function, historical stuttering data, and the actual application scenario. The core is to use threshold judgments to filter out stuttering events that are widespread or severe, rather than responding to occasional, isolated stutters. Specifically, the execution adjustment conditions may include a combination of a cumulative count threshold and a time window. For example, "the cumulative number of stuttering events for the same target function reaches 5 within 24 hours" can be set as the execution adjustment condition, where "24 hours" is the time window and "5 times" is the count threshold. This condition is based on the analysis of historical data: if a function frequently causes stuttering in a short period, it indicates a relatively stable performance defect, rather than temporary fluctuations caused by accidental factors, making intervention and adjustment more necessary.

[0146] When the detection results show that the target function meets the execution adjustment conditions, the server can generate a stuttering prompt based on the function information of the target function and send it to the target client via silent push, allowing the target client to adjust the execution operation of the target function. If the detection results show that the execution adjustment conditions are not met, the server will terminate the current push preparation process and return to the stuttering event accumulation detection stage, continuing to listen for and count stuttering events for the target function—that is, whenever stuttering information containing the target function is received again, the accumulation count update and condition detection steps are repeated until the accumulated number reaches a set threshold, satisfying the execution adjustment conditions.

[0147] Therefore, the server can effectively filter out interference from occasional lag, ensuring that each push points to the function that truly needs optimization. This not only improves the targeted nature of client-side lag resolution but also reduces the resource consumption on the server caused by frequent pushes.

[0148] In some embodiments, the execution of the operational intervention strategy can be specifically implemented as follows:

[0149] Execute the target function asynchronously; or,

[0150] Delay the execution of the objective function; or,

[0151] Block the execution of the target function.

[0152] Figure 3 The flowchart illustrates a client operation method provided in another embodiment of this application, which can be applied to a first client.

[0153] like Figure 3 As shown, the method may include the following steps:

[0154] 301: When a lag event is detected, lag information is collected;

[0155] 302: Send the lag information to the server so that the server can parse the lag information, obtain the function information of the target function and the base function information, and generate lag prompt information. The target function is the function currently being executed by the first client when the lag event occurs.

[0156] 303: Receives a lag notification message sent by the server via silent push notification;

[0157] 304: Based on the stuttering warning message, adjust the execution operation of the target function.

[0158] In some embodiments, adjusting the execution of the objective function based on the stuttering warning information can be specifically implemented as follows:

[0159] Execute the target function asynchronously; or,

[0160] Delay the execution of the objective function; or,

[0161] Block the execution of the target function.

[0162] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0163] Figure 4 The flowchart illustrates a client operation method provided in another embodiment of this application, which can be applied to a second client.

[0164] like Figure 4 As shown, the method may include the following steps:

[0165] 401: Receive a lag notification message sent by the server. The lag notification message is generated based on the function information contained in the lag information. The lag information is generated when the first client detects a lag event. The function information is the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs. The lag notification message is used to prompt adjustments to the execution of the target function.

[0166] 402: Adjust the execution of the target function based on the stuttering warning information.

[0167] The detailed implementation methods and beneficial effects of each step in this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0168] It should be noted that the technical solutions in this application are applicable to virtual network environments, and the users described generally refer to "virtual users." Real users can register user accounts on the server through registration to obtain user identities in the network environment. The same user account can log in to the server through different types of client terminals, enabling the server to identify the same user.

[0169] Interactions between the server and the user can be based on user accounts. The data received or sent by the server to the user is also based on the user account; in reality, the user's client, corresponding to the user account, receives or sends data to the server. Furthermore, users can also communicate with each other through their user accounts. Here, "user" can refer to an individual or an organization, such as a company; this application does not impose specific restrictions.

[0170] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear in this document, or they may be executed in parallel. The operation numbers, such as 201, 202, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should also be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0171] In this embodiment, on the one hand, silent push notifications are combined with function-level operation adjustments. Silent push notifications leverage their advantages of being "unobtrusive" and "background delivery" to accurately deliver instructions for adjusting the execution logic of the target function to the client. Meanwhile, function-level operation adjustments allow the client to dynamically update the function's execution logic without interrupting its operation. The synergy of these two approaches transforms stuttering optimization from "users waiting for version updates" to "real-time background logic replacement," a process that is completely unnoticed by the user, achieving truly seamless and real-time stuttering optimization. On the other hand, by comprehensively considering terminal devices, version numbers, and device performance information, operation adjustment strategies for the target function are generated. Based on the hardware characteristics, versions, and real-time performance status of different terminal devices, differentiated strategies are dynamically matched to the target function, enabling precise stuttering optimization for different clients.

[0172] Therefore, the embodiments of this application overcome the limitations of the prior art through technical collaboration, and achieve seamless, real-time, and precise lag optimization.

[0173] Figure 5 This is a block diagram of a client-side operating device provided in one embodiment of this application. This device can be applied to a server, such as... Figure 5 As shown, the device may include:

[0174] The first receiving module 501 is used to receive lag information sent by the first client. The lag information is generated when the first client detects a lag event. The lag information includes the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs.

[0175] The parsing module 502 is used to parse the stuttering information and obtain the function information of the target function;

[0176] The information generation module 503 is used to generate stuttering prompt information based on function information;

[0177] The push module 504 is used to send lag prompt information to the target client in a silent push mode, so that the target client can adjust the execution operation of the target function based on the lag prompt information. The target client includes a first client and / or a second client, wherein the second client is a second client matched with the first client.

[0178] In some embodiments, the stuttering information also includes target description information of the first client, and the device may further include:

[0179] The lag information parsing module is used to parse lag information and obtain target description information. The target description information includes at least one of device description information and the version number of the first client. The device description information is the description information of the terminal device on which the first client is installed.

[0180] The second client determination module is used to determine a second client that matches the first client based on the target description information.

[0181] In some embodiments, the second client determination module is specifically used for:

[0182] Select a second client from the client cluster that matches both the version number and the device description information; or...

[0183] Filter the client cluster to find a second client that matches the version number or the device description information.

[0184] In some embodiments, the parsing module 502 is specifically used for:

[0185] Obtain the pre-configured strategy library, which records the execution operation intervention strategies corresponding to multiple functions;

[0186] Based on function information, the target execution operation intervention strategy corresponding to the target function is searched from the pre-configured strategy library;

[0187] Based on the target execution operation intervention strategy, a lag prompt message is generated.

[0188] In some embodiments, the stuttering information includes the function call stack of the first client.

[0189] In some embodiments, the parsing module 502 is specifically used for:

[0190] Determine the top function from the function call stack;

[0191] Use the function at the top of the stack as the target function;

[0192] Use the name of the objective function as the function information.

[0193] In some embodiments, the stuttering information also includes device performance information, which describes the performance load of the terminal device on which the first client is installed.

[0194] In some embodiments, the parsing module 502 is specifically used for:

[0195] Analyze the stuttering information to obtain device performance information;

[0196] From a variety of pre-configured execution operation intervention strategies, determine the target execution operation intervention strategy that matches the equipment performance information;

[0197] Based on the target execution operation intervention strategy, a lag prompt message is generated.

[0198] In some embodiments, the device may further include:

[0199] The determination module is used to determine the cumulative number of stuttering events received for the target function;

[0200] The judgment module is used to detect whether the objective function meets the execution adjustment conditions based on the cumulative quantity;

[0201] The push execution module is used to silently push out the lag warning information to the target client when the target function meets the execution adjustment requirements.

[0202] Return to the execution module; otherwise, return to the step of checking whether the objective function meets the optimization conditions and continue execution.

[0203] In some embodiments, the implementation of operational intervention strategies includes:

[0204] Execute the target function asynchronously; or,

[0205] Delay the execution of the objective function; or,

[0206] Block the execution of the target function.

[0207] Figure 5 The client-side runtime device can execute Figure 2 The implementation principle and technical effects of the client running method in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit of the client running device in the above embodiments performs operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0208] Figure 6 This is a block diagram of a client operating device provided in one embodiment of the present application. This device can be applied to a first client, such as... Figure 6 As shown, the device may include:

[0209] The information acquisition module 601 is used to acquire lag information when a lag event is detected.

[0210] The information sending module 602 is used to send the lag information to the server so that the server can parse the lag information, obtain the function information of the target function, and generate lag prompt information based on the function information. The target function is the function currently being executed by the first client when the lag event occurs.

[0211] The second receiving module 603 is used to receive the lag notification information sent by the server in a silent push manner;

[0212] The first operation adjustment module 604 is used to adjust the execution operation of the target function based on the lag prompt information.

[0213] In some embodiments, the first operation adjustment module 604 is specifically used for:

[0214] Execute the target function asynchronously; or,

[0215] Delay the execution of the objective function; or,

[0216] Block the execution of the target function.

[0217] Figure 6 The aforementioned client running device can execute Figure 3 The implementation principle and technical effects of the client running method described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit of the client running device in the above embodiments performs operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0218] Figure 7 This is a block diagram of a client operating device provided in one embodiment of the present application. This device can be applied to a second client, such as... Figure 7 As shown, the device may include:

[0219] The third receiving module 701 is used to receive lag prompt information sent by the server. The lag prompt information is generated based on the function information contained in the lag information. The lag information is generated when the first client detects a lag event. The function information is the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs. The lag prompt information is used to prompt adjustment of the execution operation of the target function.

[0220] The second operation adjustment module 702 is used to adjust the execution operation of the target function based on the lag prompt information.

[0221] Figure 7 The aforementioned client running device can executeFigure 4 The implementation principle and technical effects of the client running method described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit of the client running device in the above embodiments performs operations have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0222] Figure 8 This is a schematic diagram of the structure of one embodiment of a computing device provided in this application. Figure 8 As shown, in practice, the computing device may include a storage component 801 and a processing component 802.

[0223] Storage component 801 is used to store computer programs and can be configured to store various other data to support operation on a computing device. Examples of this data include instructions for any application or method used to operate on the computing device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0224] The processing component 802, coupled to the storage component 801, is used to execute the computer program in the storage component 801 to implement the client running method provided in the embodiments of this application.

[0225] The processing component described above includes one or more processors to execute computer instructions to complete all or part of the steps in the method described above. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the method described above.

[0226] The aforementioned storage components can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0227] The aforementioned communication component is configured to facilitate wired or wireless communication between the device housing the communication component and other devices. The device housing the communication component can access wireless networks based on communication standards, such as mobile communication networks, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0228] The aforementioned display components may include a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0229] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0230] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0231] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0232] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0233] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0234] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0235] Finally, it should be noted that the above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A client-side operation method, characterized in that, Applied to the server side, the method includes: The system receives lag information sent by a first client, which is generated when the first client detects a lag event. The lag information includes the function call stack of the first client; the function call stack includes function information of the target function corresponding to the lag event, and the target function includes the function currently being executed by the first client when the lag event occurs; the target function is the top function in the function call stack; the lag information also includes target description information and device performance information of the first client; the target description information includes at least one of device description information and the version number of the first client, and the device description information is the description information of the terminal device on which the first client is installed. The lag information is analyzed to obtain the function information of the objective function, the objective description information, and the device performance information; Based on the target description information, a second client matching the first client is determined; the determination of the second client matching the first client based on the target description information further includes: determining the second client matching the first client based on the device performance information; Based on the function information, a stuttering warning message is generated; The lag notification information is sent to the target client in a silent push manner, so that the target client can adjust the execution operation of the target function based on the target execution operation intervention strategy in the lag notification information during operation. The target client includes the first client and / or the second client. The generation of stuttering prompt information based on the function information includes: Obtain the pre-configured policy library; Based on the function information, the target execution operation intervention strategy corresponding to the target function, the device performance information, the version number, and the device description information is searched from the pre-configured strategy library; The lag warning message is generated based on the target and the operational intervention strategy.

2. The method according to claim 1, characterized in that, The step of determining the second client that matches the first client based on the target description information includes: Select a second client from the client cluster that matches both the version number and the device description information; or... Select a second client from the client cluster that matches the version number or the device description information.

3. The method according to claim 1, characterized in that, The process of parsing the stuttering information to obtain the function information of the objective function includes: Determine the top function from the function call stack; Use the function at the top of the stack as the target function; The function name of the objective function is used as the function information.

4. The method according to claim 1, characterized in that, The method further includes: Determine the cumulative number of stuttering events received for the target function; Based on the cumulative quantity, determine whether the objective function meets the execution adjustment conditions; If the target function meets the execution adjustment conditions, the step of sending the lag prompt information to the target client in a silent push manner is executed; Otherwise, return to the step of checking whether the objective function meets the adjustment conditions and continue execution.

5. The method according to claim 1, characterized in that, The target execution intervention strategy includes: Execute the target function asynchronously; or, Delay the execution of the objective function; or, Block the execution of the target function.

6. A client-side operation method, characterized in that, Applied to a first client, the method includes: Upon detecting a lag event, lag information is collected; the lag information includes the function call stack of the first client; the function call stack includes function information of the target function corresponding to the lag event, the target function includes the function currently being executed by the first client when the lag event occurs; the target function is the top function in the function call stack; the lag information also includes target description information and device performance information of the first client; the target description information includes at least one of device description information and the version number of the first client, the device description information is the description information of the terminal device on which the first client is installed; The lag information is sent to the server so that the server can parse the lag information to obtain the function information of the target function, the target description information and the device performance information. Based on the function information, the server searches the pre-configured policy library for the target execution operation intervention policy corresponding to the target function, the device performance information, the version number and the device description information. Based on the target execution operation intervention policy, the server generates lag prompt information. The server receives the lag notification information sent by the server in a silent push manner; the server is also used to determine a second client that matches the first client based on the target description information and the device performance information, and send the lag notification information to the second client in a silent push manner. Based on the target execution operation intervention strategy in the lag prompt information, adjust the execution operation of the target function.

7. The method according to claim 6, characterized in that, The intervention strategy based on the target execution operation in the lag prompt information, which adjusts the execution operation of the target function, includes: Execute the target function asynchronously; or, Delay the execution of the objective function; or, Block the execution of the target function.

8. A client-side operation method, characterized in that, Applied to a second client, the method includes: The system receives a lag alert message sent silently by the server. This lag alert message is generated based on function information contained within lag information. The lag information is generated when the first client detects a lag event. The function information is the function information of the target function corresponding to the lag event. The target function includes the function currently being executed by the first client when the lag event occurs. The lag alert message is used to prompt adjustments to the execution of the target function. Specifically, the lag information includes the function call stack of the first client, which includes the function information of the target function corresponding to the lag event. The target function is the top function in the function call stack. The lag information also includes the target description information of the first client and device characteristics. The target description information includes at least one of device description information and the version number of the first client, wherein the device description information is the description information of the terminal device on which the first client is installed; the lag prompt information is specifically generated by the server parsing the lag information to obtain the function information of the target function, the target description information, and the device performance information, and based on the function information, searching for the target execution operation intervention policy corresponding to the target function, the device performance information, the version number, and the device description information from the pre-configured policy library, and generating the intervention policy based on the target execution operation intervention policy; the second client is the client that the server determines to match the first client based on the target description information and the device performance information; Based on the target execution operation intervention strategy in the lag prompt information, adjust the execution operation of the target function.

9. A computing device, characterized in that, This includes processing components and storage components; The storage component stores a computer program; the computer program is invoked and executed by the processing component to implement the client running method as described in any one of claims 1 to 5, or to implement the client running method as described in any one of claims 6 to 7, or to implement the client running method as described in claim 8.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processing component, implements the client running method as described in any one of claims 1 to 5, or implements the client running method as described in any one of claims 6 to 7, or implements the client running method as described in claim 8.

11. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processing component, implement the client running method as described in any one of claims 1 to 5, or implement the client running method as described in any one of claims 6 to 7, or implement the client running method as described in claim 8.

Images