Log processing method and apparatus, and electronic device

Abstract

This application provides a log processing method, apparatus, and electronic device. The method includes responding to a focus window switching event during application startup, acquiring target information for log capture, and performing log capture when the target information meets preset conditions. The preset conditions include at least one of the following: the duration of the focusless state during focus window switching exceeds a first preset duration threshold; the user's gesture information during focus window switching conforms to a first preset gesture; and the frequency of gesture information conforming to a second preset gesture exceeds a preset frequency threshold. By real-time monitoring of window focus switching events and target information, the timing of application startup anomalies can be accurately captured, ensuring the capture of critical logs and improving defect location and repair efficiency.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to a log processing method, apparatus, and electronic device. Background Technology

[0002] In the field of application development and testing, black screen or freezing issues caused by application startup anomalies mainly rely on testers to manually identify them during the debugging process. Once a problem is found, testers need to manually export the logs for development engineers to analyze.

[0003] However, this manual intervention model has significant limitations: successfully capturing valid logs requires the timing of the operation to be highly consistent with the abnormal situation. Because the triggering of black screen or freeze issues is sudden, accidental, and transient, testers find it difficult to accurately perceive the anomaly and complete the log capture operation in the first instance, easily missing the opportunity to capture critical logs, which in turn affects subsequent defect localization and repair. Summary of the Invention

[0004] This application provides a log processing method, apparatus, and electronic device to solve the technical problem that the time difference between manual identification and data capture can easily cause applications to miss critical log capture opportunities when they start up abnormally.

[0005] This application provides a log processing method, the method comprising: in response to a focus window switching event during application startup, acquiring target information for log capture; performing log capture if the target information meets preset conditions; wherein, the target information meeting the preset conditions includes at least one of the following: the duration of the non-focus state during focus window switching is greater than a first preset duration threshold, the user's gesture information during focus window switching conforms to a first preset gesture, the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold; and reporting the captured log information.

[0006] In one embodiment of this application, when the target information includes the duration, the method includes: comparing the duration with a first preset duration threshold; and determining that the application is in an unresponsive state when the duration exceeds the first preset duration threshold, and capturing logs. By monitoring the duration of the unfocused state during the focus window switching process and using the first preset duration threshold as the determination criterion, the application's unresponsiveness can be captured in a timely manner, and logs can be quickly captured so that development engineers can quickly locate the cause of the unresponsiveness based on the logs.

[0007] In one embodiment of this application, when the duration exceeds the first preset duration threshold, the method further includes: comparing the duration with a second preset duration threshold, wherein the second preset duration threshold is greater than the first preset duration threshold; generating operation prompt information when the duration exceeds the second preset duration threshold; obtaining operation instructions based on the operation prompt information; capturing logs according to the operation instructions and executing corresponding application handling strategies; wherein the application handling strategies include one of the following: keeping the application running, restarting the application, or terminating the application. By setting a longer second preset duration threshold and introducing a user confirmation mechanism, bidirectional front-end and back-end processing of application startup anomalies is achieved: automatically capturing logs for back-end analysis, while giving users the option to continue running, restart, or terminate, which can reduce the impact of forced restarts due to occasional lag on user experience, and execute handling strategies according to needs after user confirmation of the anomaly, balancing problem collection and user-friendliness.

[0008] In one embodiment of this application, where the target information includes the gesture information, the method includes: calculating the similarity between the gesture information and a first preset gesture to obtain a first similarity between the gesture information and the first preset gesture; and, if the gesture information conforms to the first preset gesture based on the first similarity, determining that the application has an anomaly and performing log capture. By introducing a gesture triggering mechanism, user-initiated intervention is achieved, allowing users to proactively trigger log capture and flexibly manage application operation when they perceive lag, thus detecting other anomalies caused by prolonged non-focusless states.

[0009] In one embodiment of this application, where the target information includes the gesture information, the method includes: calculating the similarity between the gesture information and a second preset gesture to obtain a second similarity between the gesture information and the second preset gesture; determining that the gesture information conforms to the second preset gesture based on the second similarity, and counting the frequency of the gesture information conforming to the second preset gesture within a preset period; determining that the user exhibits panic behavior and performing log capture when the frequency exceeds a preset frequency threshold. By statistically analyzing the frequency of specific gesture triggers, abnormal user operations are perceived, thereby timely and accurately identifying the user's panic behavior.

[0010] In one embodiment of this application, after determining that the user is exhibiting panic behavior, the method further includes: comparing the duration with a first preset duration threshold, provided that the target information includes the duration; switching the application to run in the background if the duration is less than or equal to the first preset duration threshold; and switching the application to the background and terminating the process if the duration is greater than the first preset duration threshold. When a user exhibits panic behavior, by implementing tiered control over the application based on the duration of the unfocused state, the application is switched to run in the background only for short periods of unfocused state, reducing false positives; and the process is forcibly terminated upon timeout confirmation of anomalies, releasing resources in a timely manner. This ensures user safety while improving system stability and resource utilization efficiency.

[0011] In one embodiment of this application, log capture includes: obtaining the state of a log switch, wherein the state of the log switch includes an on state or a off state; when the log switch is in the on state, capturing log information of different log types and writing it to the corresponding path; when the log switch is in the off state, determining the target log type according to the current lifecycle stage of the application's corresponding interface, capturing log information that matches the target log type, and writing it to the corresponding path. By dynamically controlling the log capture logic through a log switch, different types of logs are efficiently captured when the log switch is on, and the target log type is determined according to the lifecycle when the log switch is off, reducing invalid log collection and thus improving the flexibility and accuracy of log capture while reducing waste of system resources.

[0012] In one embodiment of this application, determining the target log type based on the current lifecycle stage of the application's corresponding interface includes: determining the target log type as application-related when the current lifecycle stage is in the startup stage; and determining the target log type as system-related when the current lifecycle stage is after the startup stage. By initially determining the source of startup anomalies based on the application's lifecycle, problems with the application itself or the system can be investigated. This allows for targeted collection of critical logs, reduces interference from irrelevant logs, and improves troubleshooting efficiency.

[0013] This application also provides a log processing device, the device comprising: a monitoring module, configured to, in response to a focus window switching event during application startup, acquire target information for log capture, and generate a log capture instruction if the target information meets preset conditions; wherein, the target information meeting the preset conditions includes at least one of the following: the duration of the focusless state during focus window switching is greater than a first preset duration threshold, the user's gesture information during focus window switching conforms to a first preset gesture, and the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold; a log capture module, configured to, in response to the log capture instruction, perform log capture; and a log reporting module, configured to, report the captured log information.

[0014] This application also provides an electronic device, the electronic device comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the log processing method described above.

[0015] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer's processor, causes the computer to perform the log processing method described above.

[0016] This application offers at least the following benefits: It replaces manual intervention with an automated monitoring mechanism, enabling automatic identification of application startup anomalies and automatic log capture. By real-time monitoring of window focus switching events and target information, it accurately captures the timing of application startup anomalies, ensuring the capture of critical logs. By setting preset conditions as judgment criteria, it transforms vague anomaly perception into quantifiable judgment standards, reducing false triggers caused by normal focus window switching and quickly capturing logs when target information meets preset conditions, thus improving the accuracy and real-time performance of log capture. The entire process, from monitoring and condition judgment to log capture and reporting, is fully automated, eliminating the need for real-time monitoring and manual operation by testers. This reduces labor costs and ensures that every anomaly is fully recorded, providing development engineers with complete on-site data and improving defect location and repair efficiency. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0018] In the attached diagram:

[0019] Figure 1 A schematic diagram illustrating the implementation environment of a log processing method provided in an embodiment of this application; Figure 2 A schematic flowchart illustrating a log processing method provided in an embodiment of this application; Figure 3 A schematic diagram of the lifecycle switching process provided for an exemplary embodiment of this application; Figure 4 A schematic diagram illustrating the focus window switching process provided for an exemplary embodiment of this application; Figure 5 A schematic diagram of the application startup exception log capture process provided as an exemplary embodiment of this application; Figure 6 A block diagram of a log processing apparatus provided in one embodiment of this application; Figure 7 This is a schematic diagram of the structure of a computer system for an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0021] The illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0023] The embodiments of this application respectively propose a log processing method, a log processing device, and an electronic device, which will be described in detail below.

[0024] Please see Figure 1 , Figure 1This is a schematic diagram illustrating the implementation environment of a log processing method according to an embodiment of this application, as shown below. Figure 1 As shown, the implementation environment can include application client 110 and server client 120. Application client 110 can be an electronic device with display capabilities, such as a mobile phone, tablet, in-vehicle screen, laptop, desktop computer, smart TV, or smart wearable device. Server client 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or 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, and big data and artificial intelligence platforms. There are no restrictions here. Application client 110 can be used to capture logs and report the captured log information to server client 120.

[0025] Schematic, in response to the focus window switching event during application startup, application terminal 110 obtains target information for log capture; if the target information meets preset conditions, log capture is performed; wherein, the target information meeting the preset conditions includes at least one of the following: the duration of the non-focus state during focus window switching exceeds a first preset duration threshold, the user's gesture information during focus window switching conforms to a first preset gesture, and the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold; the captured log information is reported to server terminal 120. It can be seen that the technical solution of this application embodiment replaces manual intervention with an automated monitoring mechanism, realizing automatic identification of application startup anomalies and automatic log capture. By real-time listening to window focus switching events and monitoring target information, the timing of application startup anomalies can be accurately captured, ensuring the capture of critical logs; by setting preset conditions as the judgment basis, the fuzzy anomaly perception is transformed into a quantifiable judgment standard, which can reduce false triggers caused by normal focus window switching and quickly capture logs when the target information meets the preset conditions, improving the accuracy and real-time performance of log capture. The entire process, from monitoring and condition determination to log capture and reporting, is fully automated, eliminating the need for real-time monitoring and manual operation by testers. This reduces labor costs and ensures that every anomaly is fully recorded, providing development engineers with complete on-site data and improving defect location and repair efficiency.

[0026] The log processing method provided in this application embodiment can be specifically executed by the application terminal 110, and correspondingly, the log processing device can be set in the application terminal 110.

[0027] Please see Figure 2 , Figure 2 This is a flowchart illustrating a log processing method according to an embodiment of this application. This log processing method can be applied to... Figure 1The implementation environment shown is specifically executed by application terminal 110 within that implementation environment. This log processing method can also be applied to other exemplary implementation environments and executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which this log processing method is applicable. Figure 2 As shown, in an exemplary embodiment, the log processing method includes at least steps S210 to S230, which are described in detail below: Step S210: In response to the focus window switching event of the application startup, obtain the target information for log capture.

[0028] Step S220: If the target information meets the preset conditions, log capture is performed.

[0029] Step S230: Report the captured log information.

[0030] In step S210, the application startup can be a cold start or a warm start. The focus window switching event refers to the process of focus shifting from currentFocus (the current focus window) to newFocus (the new focus window or target focus window). The current focus window is the window that currently has focus, and the target focus window is the window that is about to gain focus. The current focus window and the target focus window can belong to the same application or different applications. During the focus window switching process, the system causes the current focus window to lose focus and then assigns focus to the target focus window. Between these two phases, there is a brief state of no focus. Therefore, the focus window switching of the application interface actually involves switching between three states: currentFocus, null (empty, i.e., no focus state), and then newFocus.

[0031] The target information includes at least one of the following: a focusless state during a focus window switching process and user gesture information. Gesture information refers to interactive signals generated by the user through hand or finger movements, postures, and motion trajectories that can be recognized and analyzed by the device. This information can be collected through devices such as touchscreens, cameras, or electromagnetic sensors. For example, gesture information includes the position, trajectory, speed, and duration of the gesture. Acquiring target information can be continuous (monitoring target information) or periodic (acquiring target information at regular intervals).

[0032] In some embodiments, the duration of the focusless state during the focus window switching process can be continuously acquired, that is, the duration of the focusless state can be monitored and used as target information. For example, when the current focus window switches to the focusless state, a timer can be started and stopped until the focusless state switches to the target focus window, thereby realizing the monitoring of the duration of the focusless state.

[0033] In some embodiments, user gesture information can be continuously acquired during the switching of the focus window, that is, the gesture information is monitored and the monitored gesture information is used as target information.

[0034] In some embodiments, the duration of the non-focus state and the user's gesture information can be continuously acquired during the focus window switching process. That is, the duration of the non-focus state and the user's gesture information during the focus window switching process are monitored simultaneously, and the monitored duration of the non-focus state and the user's gesture information are used as target information.

[0035] In step S220, the target information satisfying preset conditions includes at least one of the following: the duration of the non-focus state during the focus window switching process exceeds a first preset duration threshold; the user's gesture information during the focus window switching process conforms to a first preset gesture; and the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold. Here, the first preset gesture and the second preset gesture are different; the first preset gesture represents a log capture gesture, and the second preset gesture represents a gesture to exit the application. Different types of logs can be captured through log capture services such as native services. Native services refer to code modules developed using the native language in the Android system, responsible for writing logs to disk. The log type can be preset according to user needs or determined based on the current lifecycle stage of the corresponding interface of the application.

[0036] In some embodiments, the native service is configured in the init.rc file. When the application is determined to be unresponsive, the native service can be started by setting a system property value. The init.rc file is an initialization configuration file or system startup configuration file, a script file read by the initialization process when the Android system starts. The property value is a system attribute value. The initialization process monitors changes to this system attribute value in real time. When the initialization process detects that the system attribute value has been modified to a predetermined string such as 1, it will start the corresponding native service to perform log capture according to the configuration in the init.rc file.

[0037] In some embodiments, a duration can be preset as a first preset duration threshold. When the focus window switching event occurs during application startup, the focusless state is monitored and the duration of the focusless state is recorded in real time. When the duration exceeds the first preset duration threshold, the native service is automatically started to capture logs. In some embodiments, a special gesture can be preset as the first preset gesture, such as three-finger swipe down or five-finger pinch. When the focus window switching event occurs during application startup, the user's gesture information is listened to and it is determined whether a gesture that conforms to the first preset gesture is triggered. When the triggering of the first preset gesture is detected, the native service is automatically started to capture logs.

[0038] In some embodiments, gestures such as swiping back, returning to the desktop, or exiting an application can be preset as a second preset gesture. When an application launch focus window switching event occurs, the user's gesture information is monitored, and it is determined whether a gesture matching the second preset gesture is triggered. The frequency of the gesture triggering is recorded. When the frequency exceeds a preset frequency threshold, the native service is automatically started to capture logs.

[0039] In some embodiments, when an application launch focus window switching event occurs, the duration of the focusless state and the user's gesture information can be monitored, and the native service can be automatically started to capture logs when any of the following conditions are met: The duration of the unfocused state exceeds a first preset duration threshold; The gesture information matches the first preset gesture; The frequency of gesture information matching the second preset gesture exceeds the preset frequency threshold.

[0040] In step S230, the captured log information is uploaded to the server so that development engineers can locate and fix defects.

[0041] In some embodiments, log information can be reported in real time after it is captured.

[0042] In some embodiments, a reporting period can be preset, such as one hour or one day, and all log information captured within the reporting period can be periodically packaged and uploaded.

[0043] In one embodiment of this application, where the target information includes a duration, the method includes: comparing the duration with a first preset duration threshold; determining that the application is in an unresponsive state if the duration is greater than the first preset duration threshold, and capturing logs; and re-acquiring the duration and comparing it with the first preset duration threshold if the duration is less than or equal to the duration, until the focus window switching is complete. By monitoring the duration of the unfocused state during focus window switching and using the first preset duration threshold as the determination criterion, the application's unresponsiveness can be captured promptly, and logs can be quickly captured, allowing development engineers to quickly locate the cause of the unresponsiveness based on the logs.

[0044] In this embodiment, the switching process of the focus window can be monitored. When the current focus window is detected to switch to a non-focus state, the timer can be controlled to start counting until the non-focus state switches to a new focus window, and the timer is controlled to stop counting. The duration of the non-focus state can be monitored through the timer. Once the timer count exceeds a first preset duration threshold, it is determined that the application is unresponsive and log capture is triggered.

[0045] In one embodiment of this application, when the duration exceeds a first preset duration threshold, the method further includes: comparing the duration with a second preset duration threshold, wherein the second preset duration threshold is greater than the first preset duration threshold; generating operation prompt information when the duration exceeds the second preset duration threshold; obtaining operation instructions based on the operation prompt information; capturing logs according to the operation instructions and executing corresponding application handling strategies; wherein the application handling strategies include one of the following: keeping the application running, restarting the application, or terminating the application. By setting a longer second preset duration threshold and introducing a user confirmation mechanism, bidirectional front-end and back-end processing of application startup anomalies is achieved: automatically capturing logs for back-end analysis, while giving users the option to continue running, restart, or terminate, which can reduce the impact of forced restarts due to occasional lag on user experience, and execute handling strategies according to needs after user confirmation of the anomaly, balancing problem collection and user-friendliness.

[0046] In this embodiment, the operation prompts include an application unresponsiveness warning and prompts for operation options such as continue waiting, kill to restart the application, or terminate the application. These prompts can be delivered via voice or pop-ups. The "kill" option indicates that the application process is forcibly terminated before restarting. Operation commands refer to system-recognizable instructions generated based on the user's response to the operation prompts. These instructions represent the user's next intention to determine the corresponding application handling strategy. After receiving the operation prompts, the user performs a gesture (such as clicking, swiping, or long-pressing) on ​​the corresponding interface button (e.g., terminate the application or continue waiting) as a response to the operation prompts. The system captures this gesture and generates command information, i.e., the operation command based on the operation prompts.

[0047] For example, the second preset duration threshold can be n times the first preset duration threshold, where n is greater than 1, and there is no restriction here.

[0048] In some embodiments, if the duration exceeds a second preset duration threshold, it can be further determined whether the application is running in the foreground. If the application is running in the foreground, an operation prompt message is generated; if the application is running in the background, no action is taken, which can reduce user panic.

[0049] In one embodiment of this application, where the target information includes gesture information, the method includes: calculating the similarity between the gesture information and a first preset gesture to obtain a first similarity between the gesture information and the first preset gesture; and determining that the gesture information conforms to the first preset gesture based on the first similarity, determining that the application has an anomaly, and performing log capture. By introducing a gesture triggering mechanism, user intervention is achieved, allowing users to actively trigger log capture and flexibly manage application operation when they perceive lag, thus detecting other anomalies caused by prolonged non-focusless states. Furthermore, for development versions of applications, capturing different logs often requires executing cumbersome instructions and takes a long time, resulting in missing key moments and failing to capture effective logs. The gesture triggering mechanism enables users to capture logs with a single click, allowing users to quickly save critical instantaneous logs to disk with a gesture when they notice an anomaly, improving the efficiency of capturing effective logs.

[0050] In this embodiment, feature samples of a first preset gesture can be pre-configured, including motion trajectory samples, speed samples, position samples, and gesture duration samples, etc.; feature extraction is performed on the acquired gesture information, including motion trajectory, speed, position, and gesture duration, etc.; the Euclidean distance or cosine similarity between the extracted features and the feature samples is calculated as the first similarity; when the first similarity reaches the similarity threshold, the gesture information is determined to conform to the first preset gesture, otherwise, the gesture information is determined to not conform to the first preset gesture.

[0051] In some embodiments, after determining that the application has an anomaly, the method further includes: generating a second operation prompt message; and executing a corresponding application handling strategy in response to a second operation instruction corresponding to the second operation prompt message; wherein the application handling strategy includes one of the following: keeping the application running, restarting the application, or terminating the application.

[0052] In this embodiment, the second operation prompt information includes application error messages and operation selection prompts such as continue waiting, terminate and restart the application, or end the application. These prompts can be delivered via voice or pop-up windows. After receiving the second operation prompt information, the user performs a gesture action on the corresponding interface button according to their needs. As a response to the second operation prompt information, the system captures the gesture action and generates corresponding instruction information, i.e., the second operation instruction corresponding to the second operation prompt information.

[0053] In one embodiment of this application, log capture includes: obtaining the state of a log switch, which may be either on or off; when the log switch is on, capturing log information of different log types and writing them to corresponding paths; when the log switch is off, determining the target log type based on the current lifecycle stage of the application's corresponding interface, capturing log information matching the target log type, and writing it to the corresponding path. By dynamically controlling the log capture logic through a log switch, different types of logs are efficiently captured when the log switch is on, and the target log type is determined based on the lifecycle when the log switch is off, reducing invalid log collection and thus improving the flexibility and accuracy of log capture while reducing waste of system resources.

[0054] In this embodiment, log types include application-level, system-level, and kernel-level logs. Log switch on / off information and preset log types can be configured in a specific system partition using XML (Extensible Markup Language). When the application boots up, the XML content is parsed to enable or disable the log switch and configure the preset log types. For example, the log switch on / off information and preset log types can be user-defined. XML can be remotely pushed from the server in the background to allow users to customize the log switch and preset log types. If no user customization is specified, default values ​​can be set for the log switch and preset log types, such as a default log switch being enabled and a default preset log type including all log types.

[0055] After the native service starts, a thread pool manager is created. Threads are created through the thread pool manager, and each thread executes the corresponding log fetching instructions based on the required log type (preset log type or target log type), and writes the fetched log information to the specified path for each log type for final packaging. When there is only one log type to be fetched, a single thread is created through the thread pool manager to fetch the logs; when there are multiple log types to be fetched, multiple threads are created through the thread pool manager to fetch the logs of each type in parallel.

[0056] In one embodiment of this application, the target log type is determined based on the current lifecycle stage of the application's corresponding interface. This includes: determining the target log type as application-related when the current lifecycle stage is the startup stage; and determining the target log type as system-related when the current lifecycle stage is after the startup stage. By initially determining the source of startup exceptions based on the application's lifecycle, problems with the application itself or the system can be investigated. This allows for targeted collection of critical logs, reduces interference from irrelevant logs, and improves the efficiency of problem investigation.

[0057] In this embodiment, the current lifecycle stage refers to the current stage of the application's Activity (visual interactive interface component) lifecycle, or simply the current launch screen lifecycle. Both cold and warm starts of the application involve Activity lifecycle switching, which requires multiple interactions between the system and application sides to complete.

[0058] Please see Figure 3 , Figure 3 A schematic diagram of the lifecycle switching process provided for an exemplary embodiment of this application is shown below. Figure 3As shown, the lifecycle of an Activity includes the startup phase, running phase, paused phase, stopped phase, and destruction phase. Among them, onCreate(), onStart(), and onResume() all belong to the startup phase, representing the three sub-phases of the startup phase respectively. onCreate() represents the creation or initialization phase, onStart() represents the visible but not interactive phase, onResume() represents the visible and interactive phase, onPause() represents the paused phase, onStop() represents the stopped phase, and onDestroy() represents the destruction phase. The Activity lifecycle transition process is as follows: When an Activity starts, its lifecycle sequentially enters the startup phase: onCreate() to create the starting point, onStart() to become visible, onResume() to become interactive with the user, and then enters the running phase, where the Activity runs in the foreground and is interactive with the user. When other Activities move to the foreground, this Activity will be placed in the background, first entering onPause(), during which the Activity is partially visible, then entering onStop(), during which the Activity is completely invisible. The Activity can be restored to visibility from onPause() and onStop(). When the process ends, the Activity enters onDestroy().

[0059] As we can see, `onResume()` is involved in every window switch. During this stage, the application calls `addView()` to add a window, which allows drawing and frame data submission to be triggered through the `ViewRootImpl` object. `addView()` is the view addition method, used in Android to dynamically add child views to a view container. The `ViewRootImpl` object is the root implementation object of the view and is the core hub connecting the application layer view and the underlying rendering system in Android; each application window corresponds to one `ViewRootImpl` object. Therefore, the focus window switch can only proceed after the `onResume()` method of the Activity lifecycle has completed execution.

[0060] Please see Figure 4 , Figure 4 A schematic diagram of the focus window switching process provided in an exemplary embodiment of this application is shown below. Figure 4 As shown, after the onResume() method of the Activity lifecycle is executed, the process of switching the focus window is as follows: S1. Switching interfaces and relaying windows is achieved through WindowManagerService.relayoutWindow(), where WindowManagerService is the window management service and relayoutWindow() represents the method for relaying windows; S2. The window management service updates the focus window through DisplayContent.updateFocusedWindowLocked(). DisplayContent is a class in the window management service used to manage the window state and layout of a single logical display screen, and updateFocusedWindowLocked() is the method for updating the focus window. S3. Pass the new focus window to InputMonitor, which is achieved through InputMonitor.setInputFocusLw(), where InputMonitor is the input monitor on the window management service side, and setInputFocusLw() is the input focus setting method; S4. Set the focus window on the input event service side using InputDispatcher.setFocusedWindow(), where InputDispatcher is the input dispatcher on the input event service side, and setFocusedWindow() is the method for setting the focus window.

[0061] Therefore, if the Activity lifecycle occurs before or during the `onResume()` method (i.e., during the startup phase), the possibility of application timeout should be considered, primarily by capturing application logs such as stack traces and Perfetto data. Perfetto data refers to performance tracing data collected using the Perfetto tool, an Android system performance analysis and tracing tool. If the Activity lifecycle occurs after `onResume()` (i.e., after the startup phase), the possibility of window state anomalies should be considered, primarily by capturing system logs such as `dumpsys` system information. `dumpsys` is a command-line tool provided by Android used to query the real-time status of various system services.

[0062] In another embodiment of this application, where the target information includes gesture information, the method includes: calculating the similarity between the gesture information and a second preset gesture to obtain a second similarity between the gesture information and the second preset gesture; determining that the gesture information conforms to the second preset gesture based on the second similarity, and counting the frequency of the gesture information conforming to the second preset gesture within a preset period; determining that the user is exhibiting panic behavior when the frequency exceeds a preset frequency threshold, and performing log capture, and switching the application to run in the background or terminating the process in the background; and keeping the application running in the foreground when the frequency is less than or equal to the preset frequency threshold. By counting the frequency of specific gesture triggers to detect abnormal user operations, the method can identify panic behavior of users in a timely and accurate manner, automatically execute background control after detecting abnormal operations based on frequency, intervene in abnormalities in advance, and improve the user experience.

[0063] In this embodiment, feature samples of a second preset gesture can be pre-configured, including motion trajectory samples, speed samples, position samples, and gesture duration samples. Feature extraction is performed on the acquired gesture information, including motion trajectory, speed, position, and gesture duration. The Euclidean distance or cosine similarity between the extracted features and the feature samples is calculated as a second similarity. When the second similarity reaches a similarity threshold, the gesture information is determined to conform to the second preset gesture; otherwise, it is determined not to conform to the second preset gesture. A counter is used to count the trigger frequency of gesture information conforming to the second preset gesture within a preset period. For example, the preset period can be 1 second or 2 seconds; no limitation is imposed here.

[0064] In one embodiment of this application, after determining that a user is exhibiting panic behavior, the method further includes: using the collected gesture information and corresponding time as user gesture data; classifying and identifying the user's behavior based on the user gesture data using a preset model to obtain the user's behavior category, which includes normal or panic; verifying the determination result of the user exhibiting panic behavior based on the behavior category; under the condition that the behavior category is panic, determining that the determination result of the user exhibiting panic behavior is true, and performing log capture, as well as switching the application to run in the background or switching to the background to terminate the process; under the condition that the behavior category is normal, determining that the determination result of the user exhibiting panic behavior is false, and keeping the application running in the foreground. Based on the initial identification of panic behavior through frequency statistics, the behavior classification and identification using a model achieves a secondary verification of the initial identification result. The combination of initial screening of gesture frequency and secondary verification by the model enables accurate perception of abnormal user operations, reducing false positives or false negatives.

[0065] In this embodiment, the user gesture data includes all gesture information collected within the current preset period and the corresponding time, or gesture information that conforms to the second preset gesture collected within the current preset period and the corresponding time. The current preset period is the preset period when the frequency exceeds the preset frequency threshold.

[0066] In some embodiments, a preset model can be used to calculate the total number of times all gestures are triggered within the current preset period, the number of times the same gesture is triggered consecutively, and the number of times the gesture trigger interval is less than a preset duration threshold, based on gesture information and the corresponding time. This comprehensive determination of the user's behavior category is then made. The gesture trigger interval refers to the duration between two adjacent gesture triggers.

[0067] In some embodiments, the preset model may be a pre-configured, trained classification model on the application. This pre-configured classification model can be obtained by training the initial classification model with gesture data samples labeled as panic behavior and gesture data samples labeled as normal behavior.

[0068] In some embodiments, the preset model may also be an AI dialogue assistant application, which, through a pre-configured interface, calls the AI ​​dialogue assistant application to classify and identify user behavior based on user gesture data.

[0069] In another embodiment of this application, after determining that a user is exhibiting panic behavior, the method further includes: comparing the duration with a first preset duration threshold, provided that the target information includes the duration; switching the application to run in the background if the duration is less than or equal to the first preset duration threshold; and switching the application to the background and terminating the process if the duration exceeds the first preset duration threshold. When a user exhibits panic behavior, by implementing tiered control over the application based on the duration of the unfocused state, switching the application to run in the background only for short periods of unfocused state reduces false positives and negative impacts; and forcibly terminating the process upon confirmation of an anomaly after a timeout releases resources in a timely manner, this approach ensures user safety while improving system stability and resource utilization efficiency.

[0070] The solution of this application will now be described in detail with reference to an exemplary embodiment.

[0071] A predefined focus window detector class is defined, whose main functions are focus window switching timeout detection and critical log capture. A singleton object is created in SystemServer (the system service process responsible for starting and managing all system services). Its detection mechanism runs in SystemServer's bgHandler (a background thread or background message handler), driven by a defined focus window detection timeout message. The execution of this message indicates the start of the detection timeout.

[0072] like Figure 5 As shown, the log capture process for application startup exceptions is as follows: S1. In the updateFocusedWindowLocked() method of the focus window, check whether the current focus state is null. If the current focus state is null, send a focus window detection timeout message to bgHandler to start the detection timer. When the current focus window successfully switches to a new non-null window, cancel the timer.

[0073] S2. If the user exhibits panic behavior before the timer exceeds 1 times the threshold (first preset duration threshold), the current application will be hidden in the background; if the user exhibits panic behavior after the timer exceeds 1 times the threshold, the current application will be hidden in the background and the process will be terminated. The panic behavior can be determined by statistically analyzing the frequency of the user's second preset gesture within a preset period using system tracking. For example, if the user attempts to swipe back more than twice within 1 second, it is determined that the user is exhibiting panic behavior. Alternatively, user behavior can be analyzed using interfaces provided by artificial intelligence tools to determine if the user is repeatedly trying to restore the interface. A combination of these two methods can also be used to determine if the user is exhibiting panic behavior.

[0074] S3. If the timer exceeds 1x the threshold and the message initiating the detection timer is not removed, critical log capture is triggered. It checks if a full log switch is configured, i.e., whether the full log switch is enabled. The full log switch is the switch configured for all log types. If enabled, all logs matching the configured log types (preset log types) are captured. If not enabled, logs are captured on demand based on the interface state. Specifically, it determines the current startup interface lifecycle. If it's on or before `onResume()`, the possibility of application timeout is considered, primarily capturing stack trace information and Perfetto data. If it's after `onResume()`, abnormal window state is considered, primarily capturing dumpsys system information.

[0075] S4. If the application is in the foreground and the timeout exceeds twice the threshold (second preset duration threshold), and the message initiating the detection timeout is still not removed, a pop-up window will prompt the user that the current application startup is abnormal. The user can choose to continue waiting or terminate and restart the application, and then capture the logs again.

[0076] In addition, a one-click capture function can be added for testing scenarios. When users notice an anomaly, they can quickly save the configured key instant logs to disk with a single click using the first preset gesture.

[0077] For details regarding the log capture process for application startup anomalies, please refer to the descriptions in the aforementioned embodiments; they will not be repeated here. By implementing embedded monitoring of high-frequency anomalies such as black screens or freezes caused by application startup anomalies, the necessary key logs can be automatically and quickly written to disk when such problems occur, increasing the probability of capturing effective logs, saving manpower reproduction costs, and shortening the problem localization cycle. During log capture, a preliminary judgment is made based on the anomaly type, and logs are captured as needed according to the log on / off status, making reasonable use of system resources. This solution runs in the background thread and native service of the systemServer process, without affecting the operation of the foreground application, and the log writing function is unaffected by upper-layer anomalies, exhibiting high stability. Key logs written to disk can be exported at any time or packaged and exported along with the final logs, without affecting the continuity of testing. By adding a one-click gesture capture function, the necessary key logs can be quickly written to disk with a single click when a user discovers an anomaly, increasing the flexibility of detection and improving the probability of effective log capture for similar anomalies caused by other reasons. By identifying user panic behavior and applying different processing procedures based on the duration of the unfocused state, the system can capture key log information and perform anomaly recovery, thereby improving the user experience.

[0078] Please see Figure 6 , Figure 6 This is a block diagram of a log processing apparatus according to an embodiment of this application. The apparatus can be applied to… Figure 1 The implementation environment shown is specifically configured in application terminal 110. This device can also be applied to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment to which the device is applicable.

[0079] like Figure 6 As shown, the exemplary log processing device includes: a monitoring module 610, configured to, in response to a focus window switching event during application startup, acquire target information for log capture, and generate a log capture instruction if the target information meets preset conditions; wherein, the target information meeting the preset conditions includes at least one of the following: the duration of the focusless state during focus window switching is greater than a first preset duration threshold, the user's gesture information during focus window switching conforms to a first preset gesture, and the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold; a log capture module 620, configured to, in response to the log capture instruction, perform log capture; and a log reporting module 630, configured to, report the captured log information.

[0080] In some embodiments, the monitoring module 610 and the log reporting module 630 may be background threads of the systemServer process.

[0081] In some embodiments, the log capture module 620 may be a native service.

[0082] The log processing apparatus and log processing method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments and will not be repeated here. In practical applications, the log processing apparatus provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0083] The log processing apparatus and log processing method provided in the above embodiments can be applied not only to the Android system but also to other systems. The application system of the method and apparatus is limited here.

[0084] In one embodiment of this application, an electronic device is also provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the log processing methods provided in the above embodiments.

[0085] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer system for an electronic device provided in an embodiment of this application. Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 7 As shown, the computer system 700 includes a central processing unit 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory 702 or a program loaded from a storage section 708 into a random access memory 703, such as performing the methods described in the above embodiments. The random access memory 703 also stores various programs and data required for system operation. The central processing unit 701, the read-only memory 702, and the random access memory 703 are interconnected via a bus 704. An input / output interface 705 is also connected to the bus 704.

[0087] The following components are connected to the input / output interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including CRT (Cathode Ray Tube), LCD (Liquid Crystal Display), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0088] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs the various functions defined in the apparatus of this application.

[0089] The computer-readable medium shown in the embodiments of this application may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, RAM (Random Access Memory), ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory), flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0090] The flowcharts, block diagrams, and structural diagrams in the accompanying drawings illustrate the architecture, functions, and operations of possible implementations of apparatus, methods, and electronic devices according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0091] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A log processing method, characterized in that, The method includes: In response to the focus window switching event during application startup, obtain the target information for log capture; Log capture is performed when the target information meets preset conditions; wherein, the target information meeting preset conditions includes at least one of the following: the duration of the non-focus state during the focus window switching process is greater than a first preset duration threshold, the user's gesture information during the focus window switching process conforms to a first preset gesture, and the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold. The captured log information will be reported.

2. The log processing method according to claim 1, characterized in that, Given that the target information includes the duration, the method includes: The duration is compared with the first preset duration threshold. If the duration exceeds the first preset duration threshold, the application is determined to be in an unresponsive state, and logs are captured.

3. The log processing method according to claim 2, characterized in that, Under the condition that the duration exceeds the first preset duration threshold, the method further includes: The duration is compared with a second preset duration threshold, wherein the second preset duration threshold is greater than the first preset duration threshold; Under the condition that the duration exceeds the second preset duration threshold, an operation prompt message is generated; Obtain operation instructions based on the operation prompt information; Logs are captured according to the operation instructions, and corresponding application handling strategies are executed; wherein, the application handling strategies include one of the following: keeping the application running, restarting the application, or terminating the application.

4. The log processing method according to claim 1, characterized in that, Given that the target information includes the gesture information, the method includes: The similarity between the gesture information and the first preset gesture is calculated to obtain a first similarity between the gesture information and the first preset gesture. If the gesture information is determined to match the first preset gesture based on the first similarity, the application is deemed to have an anomaly, and logs are captured.

5. The log processing method according to claim 1, characterized in that, Given that the target information includes the gesture information, the method includes: The similarity between the gesture information and the second preset gesture is calculated to obtain a second similarity between the gesture information and the second preset gesture; Under the condition that the gesture information conforms to the second preset gesture based on the second similarity, the frequency of the gesture information conforming to the second preset gesture within a preset period is counted; If the frequency exceeds a preset frequency threshold, it is determined that the user is exhibiting panic behavior, and logs are retrieved.

6. The log processing method according to claim 5, characterized in that, After determining that the user is exhibiting panic behavior, the method further includes: If the target information includes the duration, the duration is compared with the first preset duration threshold. If the duration is less than or equal to the first preset duration threshold, the application will be switched to run in the background. If the duration exceeds the first preset duration threshold, the application is switched to the background and the process is terminated.

7. The log processing method according to any one of claims 1-5, characterized in that, Perform log capture, including: Obtain the status of the log switch, which includes an on or off state. When the log switch is in the "on" state, log information of different log types is captured and written to the corresponding path; When the log switch is in the off state, the target log type is determined according to the current lifecycle stage of the corresponding interface of the application, log information that matches the target log type is captured and written to the corresponding path.

8. The log processing method according to claim 7, characterized in that, The target log type is determined based on the current lifecycle stage of the application's corresponding interface, including: Given that the current lifecycle stage is in the startup phase, the target log type is determined to be an application type; Given that the current lifecycle phase is after the startup phase, the target log type is determined to be a system type.

9. A log processing device, characterized in that, The device includes: The monitoring module is used to respond to the focus window switching event when the application starts, obtain target information for log capture, and generate a log capture instruction when the target information meets preset conditions; wherein, the target information meeting the preset conditions includes at least one of the following: the duration of the non-focus state during the focus window switching process is greater than a first preset duration threshold, the user's gesture information during the focus window switching process conforms to a first preset gesture, and the frequency of the gesture information conforming to a second preset gesture exceeds a preset frequency threshold; The log capture module is used to capture logs in response to the log capture command; The log reporting module is used to report the captured log information.

10. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the log processing method as described in any one of claims 1-8.

Images