Thread wake-up monitoring methods, devices, electronic equipment and storage media

Abstract

This disclosure relates to a thread wake-up monitoring method, apparatus, electronic device, and storage medium. The thread wake-up monitoring method includes: acquiring thread wake-up data of an application during its current execution within a predetermined duration; saving the acquired thread wake-up data and its corresponding index identifier to a thread file; and after the application exits its current execution, upon the next startup of the application, if the exit of the current execution is detected as an abnormal exit, sending the thread file to a server to determine the cause of the abnormal exit. The thread wake-up monitoring method, apparatus, electronic device, and storage medium of this disclosure solve the problem of not being able to obtain thread wake-up data during application execution after application exit. By saving the thread wake-up data in a thread file, persistent storage of the thread wake-up data is possible, providing a reference for optimizing thread wake-up.

Description

Technical Field

[0001] This disclosure relates to the fields of computer technology and data processing technology, and in particular to a thread wake-up monitoring method, apparatus, electronic device and storage medium. Background Technology

[0002] Thread wakeup refers to switching to a new thread to update data while the application is running in the foreground or background. Thread wakeup consumes resources on the electronic device that is running the application and increases battery consumption. Therefore, thread wakeup needs to be monitored while the application is running or sleeping to prevent it from impacting the device's performance. For example, if the number of thread wakeups exceeds a threshold, the application can be forcibly terminated.

[0003] In the existing thread wake-up monitoring process, only thread wake-up data is acquired in real time, and thread wake-up monitoring is implemented based on the acquired thread wake-up data. In this method, after the application is exited normally or abnormally, it is impossible to obtain the thread wake-up data during the application's operation. In particular, in the case of abnormal application exit, it is impossible to know whether the abnormal exit was caused by thread wake-up, and it cannot provide guidance for optimizing the application. Summary of the Invention

[0004] This disclosure provides a thread wake-up monitoring method, apparatus, electronic device, and storage medium to at least solve the problem in related technologies where thread wake-up data during application runtime cannot be obtained after application exit. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a thread wake-up monitoring method is provided, the thread wake-up monitoring method comprising: acquiring thread wake-up data of an application during a predetermined duration of current operation; saving the acquired thread wake-up data and an index identifier corresponding to the thread wake-up data to a thread file; and after the application exits during the current operation, when the application is started again, if it is detected that the exit of the current operation of the application was an abnormal exit, sending the thread file to a server to determine the reason for the abnormal exit of the application.

[0006] Optionally, the thread wake-up monitoring method further includes: searching for the thread file; if the thread file is not found, creating the thread file and mapping the file address of the created thread file to the process virtual address space of the application.

[0007] Optionally, the step of mapping the file address of the created thread file to the process virtual address space of the application includes: mapping the file address of the created thread file to the process virtual address space of the application based on the mmap function.

[0008] Optionally, the step of saving the acquired thread wake-up data and the corresponding index identifier to the thread file includes: saving the acquired thread wake-up data and the corresponding index identifier to the thread file, and incrementing the number of data saved in the thread file by 1, wherein when the number of data saved in the thread file exceeds the saving threshold, the earliest saved thread wake-up data indicated by the index identifier in the thread file is deleted.

[0009] Optionally, the thread wake-up data includes the number of threads woken up. The step of obtaining the thread wake-up data of the application within a predetermined duration includes: using the predetermined duration as a time interval, obtaining the total number of threads woken up in the current lifecycle of the application at the current time; and taking the difference between the total number of threads woken up at the current time and the total number of threads woken up at the previous time as the number of threads woken up within the predetermined duration.

[0010] Optionally, the thread wake-up monitoring method further includes: determining the sum of the number of thread wake-ups in all thread wake-up data stored in the thread file; and stopping the application from running when the sum is equal to or greater than the wake-up number threshold.

[0011] Optionally, the save threshold and the predetermined duration are determined by a time threshold, wherein the application stops running when the total number of threads woken up in the current lifecycle of the application is equal to or greater than the wake-up number threshold and the running time of the application in the current lifecycle is less than the time threshold.

[0012] Optionally, the thread wake-up monitoring method further includes: when the application is launched again, if it is detected that the exit of the current run of the application is a normal exit, deleting the thread wake-up data stored in the thread file.

[0013] Optionally, the thread file has a circular queue data structure.

[0014] According to a second aspect of the present disclosure, a method for determining the cause of abnormal exit is provided. The method includes: receiving abnormal exit information and a thread file from an application, wherein the thread file contains the start time and / or end time of the application and thread wake-up data during the application's operation; and determining the cause of the abnormal exit of the application based on the thread file.

[0015] According to a third aspect of the present disclosure, a thread wake-up monitoring device is provided, the thread wake-up monitoring device comprising: an acquisition unit configured to acquire thread wake-up data of an application within a predetermined time period; a storage unit configured to store the acquired thread wake-up data and an index identifier corresponding to the thread wake-up data in a thread file; and a sending unit configured to, after the application exits in this run, when the application is started again in the next run, if it is detected that the exit of the application in this run was an abnormal exit, send the thread file to a server to determine the reason for the abnormal exit of the application.

[0016] Optionally, the thread wake-up monitoring device further includes a creation unit, which is configured to: locate the thread file; if the thread file is not found, create the thread file and map the file address of the created thread file to the process virtual address space of the application.

[0017] Optionally, the creation unit is further configured to: map the file address of the created thread file to the process virtual address space of the application based on the mmap function.

[0018] Optionally, the storage unit is further configured to: save the acquired thread wake-up data and the corresponding index identifier to the thread file, and increment the number of data saved in the thread file by 1, wherein when the number of data saved in the thread file exceeds the storage threshold, the earliest saved thread wake-up data indicated by the index identifier in the thread file is deleted.

[0019] Optionally, the thread wake-up data includes the number of threads woken up, wherein the acquisition unit is further configured to: acquire the total number of threads woken up in the current lifecycle of the application at the current time, with the predetermined duration as the time interval; and take the difference between the total number of threads woken up at the current time and the total number of threads woken up at the previous time as the number of threads woken up within the predetermined duration.

[0020] Optionally, the thread wake-up monitoring device further includes a control unit, which is configured to: determine the sum of the number of thread wake-ups in all thread wake-up data stored in the thread file; and stop the application from running when the sum is equal to or greater than a wake-up number threshold.

[0021] Optionally, the save threshold and the predetermined duration are determined by a time threshold, wherein the application stops running when the total number of threads woken up in the current lifecycle of the application is equal to or greater than the wake-up number threshold and the running time of the application in the current lifecycle is less than the time threshold.

[0022] Optionally, the thread wake-up monitoring device further includes a deletion unit, which is configured to delete the thread wake-up data stored in the thread file when the application is launched again and the exit of the current run of the application is detected to be a normal exit.

[0023] Optionally, the thread file has a circular queue data structure.

[0024] According to a third aspect of the present disclosure, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing processor-executable instructions, wherein, when executed by the processor, the processor-executable instructions cause the processor to execute a thread wake-up monitoring method according to an exemplary embodiment of the present disclosure or a method for determining abnormal exit reasons according to an exemplary embodiment of the present disclosure.

[0025] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform a thread wake-up monitoring method according to an exemplary embodiment of the present disclosure or a method for determining an abnormal exit reason according to an exemplary embodiment of the present disclosure.

[0026] According to a fifth aspect of the present disclosure, a computer program product is provided, the computer program product including computer instructions, which, when executed by a processor, implement the thread wake-up monitoring method or the abnormal exit reason determination method according to the exemplary embodiments of the present disclosure.

[0027] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects:

[0028] Thread wake-up data can be stored in a thread file, which allows for accurate monitoring and recording of application thread wake-up data, and persistent storage of thread wake-up data. This provides data support for distinguishing application crashes caused by thread wake-ups and provides reference indicators for optimizing thread wake-ups.

[0029] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0030] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0031] Figure 1 This is a flowchart illustrating a thread wake-up monitoring method according to an exemplary embodiment.

[0032] Figure 2 This is a flowchart illustrating the steps of obtaining the number of threads woken up in a thread wake-up monitoring method according to an exemplary embodiment.

[0033] Figure 3 This is a flowchart illustrating an example of a thread wake-up monitoring method according to an exemplary embodiment.

[0034] Figure 4 This is a block diagram illustrating a thread wake-up monitoring device according to an exemplary embodiment.

[0035] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0036] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0037] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0038] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. As another example, "performing at least one of step one and step two" indicates the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0039] As mentioned earlier, thread wake-up consumes device resources (e.g., the device's CPU) and increases the device's power consumption. To prevent thread wake-up from affecting device performance, thread wake-up can be monitored.

[0040] Taking iOS as an example, the system monitors various resources used by applications, such as memory, CPU, and disk. Thread wake-up is one of the system monitoring metrics. Specifically, the system can set thresholds for thread wake-up, such as a threshold for the number of times a thread is woken up. When an application wakes up too many threads per second, exceeding the system-set threshold, it may cause the application to terminate abnormally. For example, if an application's average number of thread wake-ups per second exceeds 150 times within 300 seconds, the system can forcibly terminate the application.

[0041] In existing thread wake-up monitoring, the system's built-in interface is typically used to obtain the number of threads woken up by the application. However, in such monitoring, the thread wake-up count is usually only available during the current lifecycle of the application, and the obtained thread wake-up count cannot be persistently stored. After the application exits, it is impossible to obtain the changes in thread wake-up during the last startup, making it impossible to effectively utilize thread wake-up monitoring data, resulting in significant limitations in data usage.

[0042] Furthermore, such monitoring makes it impossible to correlate the acquired thread wake-up count with the reasons for the application's abnormal exit, thus failing to provide effective reference information for attributing abnormal application exits. For example, when an application experiences an Out of Memory (OOM) problem, the user only perceives a momentary app crash, indistinguishable from an app crash caused by other reasons. Therefore, even if the crash is due to thread wake-ups, the cause remains unknown. Here, OOM refers to an application being forcibly terminated by the operating system due to excessive memory usage on the device.

[0043] Therefore, accurate monitoring of thread wake-up data for targeted improvements is crucial for enhancing application stability and user experience.

[0044] It should be noted that although the application scenario of the iOS system is used as an example here, it should be understood that the application scenarios of the thread wake-up monitoring method, device, electronic device and storage medium disclosed herein are not limited to this, and can also be applied to any operating system involving thread wake-up.

[0045] In view of the above problems, the following describes a thread wake-up monitoring method, a thread wake-up monitoring device, an electronic device, a computer-readable storage medium, and a computer program product according to exemplary embodiments of the present disclosure, with reference to the accompanying drawings.

[0046] According to a first aspect of an exemplary embodiment of this disclosure, a thread wake-up monitoring method is provided, which can be applied to an application terminal. Here, the application terminal can be a concept corresponding to a server terminal, which can provide local services to users. The application terminal can be, for example, a terminal device, specifically including physical devices such as smartphones, tablets, laptops, digital assistants, wearable devices, and in-vehicle terminals, or software running on the physical device such as web browsers, virtual machines, and application clients, which provides services to users by receiving corresponding service information from the server terminal. A specific communication connection can be established between the server terminal and the application terminal to ensure normal data communication. The communication connection can be established in any manner, and this disclosure does not impose any particular limitation on it.

[0047] like Figure 1 As shown, a thread wake-up monitoring method according to an exemplary embodiment includes the following steps:

[0048] In step S10, thread wake-up data of the application during the current run within a predetermined duration can be obtained.

[0049] In this step, an application can refer to a computer program that performs a specific function and can be loaded onto an electronic device. The operation of an application can include foreground and background operation. When running in the foreground, the application may have a visual user interface, allowing interaction with the user; when running in the background, the application may be in a dormant state or perform functions without displaying a user interface. During application operation, data from one or more threads can be updated by waking them up, such as periodically sending or receiving data.

[0050] Thread wake-up data can refer to data generated during the thread wake-up process. For example, thread wake-up data may include the number of threads woken up, but the exemplary embodiments of this disclosure are not limited to this. Thread wake-up data may also include the task executed by each woken-up thread, resource information occupied by the woken-up thread, etc. Here, the number of thread wake-ups can refer to the count of thread wake-ups performed by the application, which includes multiple wake-ups of a single thread and wake-ups of multiple threads. By monitoring the number of thread wake-ups, it is possible to determine whether the abnormal exit of the application is caused by frequent thread wake-ups, providing data support for optimizing the application and thread wake-ups.

[0051] In this step, the predetermined duration can be arbitrarily set according to actual needs; that is, thread wake-up data can be obtained within a certain period of time. Here, starting from the application startup time, thread wake-up data within the predetermined duration can be obtained periodically.

[0052] For example, the predetermined duration can be one second, and correspondingly, the obtained thread wake-up data will be the thread wake-up data per second.

[0053] If the obtained thread wake-up data is the number of threads woken up, the number of threads woken up within a predetermined time period can be obtained in the following way:

[0054] In step S11, the total number of threads woken up in the current lifecycle of the application at the current time can be obtained at a predetermined time interval.

[0055] Here, lifecycle refers to the usage time of an application from startup to shutdown. Shutdown can be a normal shutdown based on user interaction or an abnormal shutdown due to any reason. The total number of thread wake-ups in the current lifecycle can be calculated from the startup time of the current lifecycle. The current time can refer to the time when the fetch operation was performed. Therefore, the total number of thread wake-ups in the current lifecycle of the application at the current time can refer to the number of thread wake-ups from the startup time of the current lifecycle to the current time.

[0056] In this step, during application runtime, the total number of threads woken up can be periodically retrieved at predetermined intervals, as mentioned above. As an example, in an iOS application scenario, this can be achieved using the system's GCD timer. For instance, the predetermined interval could be one second, and the GCD timer could be set to retrieve the total number of threads woken up once per second.

[0057] In step S12, the difference between the total number of thread wake-ups obtained at the current time and the total number of thread wake-ups obtained at the previous time can be used as the number of thread wake-ups within the predetermined time period.

[0058] During application runtime, the difference between two consecutive total thread wake-up counts can be used as the thread wake-up count within a single predetermined duration. Here, when the current time is the time when the total thread wake-up count is first obtained, the thread wake-up count can be disregarded.

[0059] In step S20, the obtained thread wake-up data and the index identifier corresponding to the thread wake-up data are saved to the thread file.

[0060] In this step, the index identifier can be an indicator that indicates the saving order of thread wake-up data. For example, it can be the number of thread wake-up data. As described in the steps above, starting from the application startup time, thread wake-up data within a predetermined time interval can be obtained periodically. The thread wake-up data obtained each time can be saved to the thread file. The order of multiple thread wake-up data obtained can be determined by the index identifier.

[0061] Here, given the predetermined duration, the time to retrieve the thread wake-up data can be calculated based on the thread wake-up data number. For example, the time to retrieve the thread wake-up data can be equal to the application startup time plus the product of the number and the predetermined duration.

[0062] However, the exemplary embodiments of this disclosure are not limited thereto. The index identifier can be in any form, as long as the storage order of the corresponding thread wake-up data can be determined according to the index identifier. For example, it can also be the storage time of the thread wake-up data.

[0063] A thread file can be a file used to store thread wake-up data, which can be stored, for example, in the persistent storage of an electronic device. Each time thread wake-up data is obtained, along with its corresponding index, can be saved to the thread file. This way, even after the application exits, the thread file can be consulted to obtain the thread wake-up data incurred during the application's runtime.

[0064] As an example, each thread file can store thread wake-up data for a single lifecycle of the application. For instance, a thread file can be created when thread wake-up data is first obtained within each lifecycle of the application. The thread file may include the application's start time and may also include the application's exit time.

[0065] The thread wake-up monitoring method according to an exemplary embodiment of this disclosure may specifically include: searching for a thread file; and creating a thread file if no thread file is found.

[0066] Specifically, after obtaining the thread wake-up data, the system can check if a thread file already exists on the device. If not, it can create one. Once created, the thread file will be permanently stored on the device, and its data can be updated each time the application runs. A corresponding thread file can be created for each application on the device.

[0067] In one example, the file address of the created thread file can be mapped to the application's process virtual address space.

[0068] For example, the mmap function can be used to map the file address of a thread file to the application's process virtual address space. Here, the mmap mechanism is a memory-mapped file method that can map a file to the process's virtual address space, establishing a one-to-one correspondence between the file's disk address and a segment of virtual memory address in the process's virtual address space.

[0069] After mapping the file address of the thread file to the application's process virtual address space, the process can operate on the thread file by reading and writing memory. The system automatically updates the operation content in memory to the thread file stored on disk at regular intervals. In this way, the frequent reading and writing of the thread file stored on disk can be avoided, which would affect the operation efficiency. Furthermore, after the application exits, the system's automatic timed update function can ensure that the thread wake-up data can be automatically written to the thread file, avoiding data loss.

[0070] If the thread file is found, the obtained thread wake-up data and the corresponding index identifier can be saved to the thread file.

[0071] As an example, a thread file can save a predetermined number of thread wake-up data or a predetermined time period of thread wake-up data. When more than the predetermined number of thread wake-up data or more than the predetermined time period of thread wake-up data is obtained, the earliest saved thread wake-up data in the thread file can be deleted.

[0072] Specifically, step S20 may include: saving the acquired thread wake-up data to a thread file, and incrementing the count of data saved in the thread file by 1. Here, when creating the thread file, the count of data saved can be 0, and the count of data saved can be incremented by 1 each time the thread wake-up data saving operation is performed.

[0073] When the number of data entries saved in the thread file exceeds the saving threshold, the earliest saved thread wake-up data, indicated by the index in the thread file, is deleted. For example, the saving threshold can be 300 entries, and the index can be the number of the thread wake-up data saved to the thread file. When thread wake-up data with the index 301 is saved to the thread file, thread wake-up data with the index 1 (i.e., the earliest saved thread wake-up data in the thread file) can be deleted. In this way, the number of thread wake-up data entries saved in the thread file is fixed and will not exceed the saving threshold, thus saving the resource space occupied by the thread file.

[0074] As an example, a thread file can have a circular queue data structure, which refers to a first-in, first-out (FIFO) data structure where the head and tail are connected. For example, it can use the linear space of an array to store data. Based on the circular queue data structure, it is possible to quickly know whether the queue is full and improve the speed of data access.

[0075] The above reference Figure 1 Exemplary steps for acquiring and saving thread wake-up data are described. The thread wake-up monitoring method according to an exemplary embodiment of this disclosure may further include the step of stopping application execution based on the acquired thread wake-up data.

[0076] Specifically, in one example, if the acquired thread wake-up data includes the number of threads woken up, the thread wake-up monitoring method may further include: determining the sum of the number of threads woken up in all the thread wake-up data stored in the thread file; and stopping the application from running when the sum is equal to or greater than the wake-up number threshold.

[0077] In this example, the sum of the number of thread wake-ups in the thread file can be calculated. When this sum equals or exceeds a preset wake-up threshold, thread wake-ups are considered too frequent, and the application can be stopped. The wake-up threshold can be set arbitrarily according to actual needs. For example, the thread file's save threshold could be 300, and the preset duration could be 1 second. Therefore, the wake-up threshold could be set to 45,000. This means that if the number of thread wake-ups exceeds 45,000 within 300 seconds, the application can be forcibly stopped. Thus, compared to existing methods that rely on real-time acquisition of total thread wake-up data to control application operation, controlling application operation by querying the thread file allows for more flexible application control.

[0078] Alternatively, or in addition to the examples above, in another example where the acquired thread wake-up data includes the number of threads woken up, the thread wake-up monitoring method may further include: stopping the application when the total number of threads woken up in the current lifecycle of the application is equal to or greater than a wake-up number threshold and the application's runtime in the current lifecycle is less than a time threshold.

[0079] Furthermore, the thread file saving threshold and the predetermined duration for acquiring thread wake-up data mentioned above can be determined using the time threshold mentioned here. When the total number of thread wake-ups is equal to or greater than the preset wake-up number threshold, it can be determined whether the application's runtime in the current lifecycle is less than the preset time threshold. If it is less than the time threshold, it can be considered that thread wake-ups are too frequent, and the application can be stopped. For example, the time threshold can be 300 seconds, and the wake-up number threshold can be 45,000. When the number of thread wake-ups is greater than or equal to 45,000 and the application's runtime is less than 300 seconds, the application can be forcibly stopped.

[0080] Based on the two examples above, the application can be stopped either by obtaining the total number of threads woken up in real time, or by querying the thread file, which provides more options for application monitoring.

[0081] As an example, the time threshold can be equal to the product of the thread file's storage threshold and the predetermined duration for retrieving thread wake-up data. For instance, as described above, the time threshold could be 300 seconds, the storage threshold could be 300, and the predetermined duration could be 1 second. In other words, the thread file's storage threshold and the predetermined duration for retrieving thread wake-up data can be adjusted based on the time threshold for determining whether the application needs to be stopped, so that the thread wake-up data stored in the thread file just meets the time threshold for determining whether the application needs to be stopped.

[0082] The thread wake-up monitoring method according to the exemplary embodiments of this disclosure can record thread wake-up data by saving the thread wake-up data to a thread file, and the thread file will be persistently stored on the device. Even if the application exits (normally or abnormally), the thread wake-up data of the application before exiting can be retained in the thread file, so as to know the thread wake-up status of the application during the running period by querying the thread file as needed.

[0083] In step S30, after the application exits this run, when the application starts again, if it is detected that the exit of the current run was abnormal, the thread file can be sent to the server to determine the reason for the abnormal exit of the application.

[0084] Specifically, each time the application starts, it checks whether the application's previous exit was an abnormal exit, and processes the thread files based on the check results.

[0085] Specifically, when an application exits abnormally, the thread file can be sent to the server, and the thread wake-up data stored in the thread file can be deleted after sending. Here, since the thread file can include the application's start time and / or exit time, when an abnormal exit is detected, the thread file, including thread wake-up data during application runtime as well as the application's start time and / or exit time, can be sent to the server. The server can then determine whether the abnormal application exit is related to thread wake-ups based on the thread wake-up data. After sending the thread file to the server, the thread wake-up data stored in the thread file can be deleted, while the thread wake-up data for the current application runtime can continue to be stored.

[0086] When the application is launched again, if the exit of the current run is detected as a normal exit, the thread wake-up data stored in the thread file is deleted.

[0087] In this way, regardless of whether the application exits abnormally or normally during this run, the thread wake-up data saved during this run will be deleted when the application starts again. In other words, the thread file only needs to store the thread wake-up data for a single run. This helps save the resource space occupied by the thread file and allows for timely reporting of thread wake-up data.

[0088] As described above, the thread wake-up monitoring method according to the exemplary embodiments of this disclosure can save thread wake-up data in a thread file, thereby allowing accurate monitoring and recording of application thread wake-up data, and persistently saving the thread wake-up data, providing data support for distinguishing application crashes caused by thread wake-up, and providing reference indicators for optimizing thread wake-up.

[0089] The following will refer to Figure 3 Using the iOS system as an example, an example of a thread wake-up monitoring method according to an exemplary embodiment of this disclosure is described.

[0090] like Figure 3 As shown, in step S1, a timer that executes once per second can be started using the GCD function of the iOS system.

[0091] In step S2, a timer can be used to determine if a 1-second interval has been reached. If the interval is less than 1 second, step S2 can be repeated. When the interval reaches 1 second, in step S3, thread wake-up data can be obtained. This data can include the number of threads woken up. Specifically, the total number of threads woken up in the application can be obtained using the built-in function of the iOS system. The increment of the thread wake-up count can be calculated by subtracting the total number of threads woken up in the previous second from the total number of threads woken up in this second.

[0092] In step S4, it can be determined whether a thread file exists. If the thread file does not exist, in step S5, it can be created. Then, in step S6, the created thread file is mapped into memory using the mmap mechanism, and the data structure of the thread file is set to a circular queue data structure. Then, step S7 is executed. If it is determined in step S4 that a thread file exists, step S7 can be executed directly.

[0093] In step S7, the thread wake-up data obtained in step S3 can be saved to a thread file. Specifically, it can be saved to a circular queue in the thread file.

[0094] In step S8, it can be determined whether the queue size in the thread file exceeds the storage threshold (e.g., 300), that is, whether the number of data items stored in the thread file exceeds the storage threshold. When the storage threshold is exceeded, the earliest stored thread wake-up data in the circular queue of the thread file can be deleted; that is, the earliest stored thread wake-up data in the thread file is overwritten with the thread wake-up data obtained in step S3. When the storage threshold is not exceeded, the thread wake-up data obtained in step S3 can be directly stored in the thread file, keeping the data stored in the thread file unchanged.

[0095] According to a second aspect of an exemplary embodiment of this disclosure, a method for determining the cause of abnormal exit is provided. This method can be applied to a server, where the server can refer to any execution entity capable of executing the thread wake-up monitoring method described below, such as a server. The server may include a standalone server, a distributed server, or a server cluster consisting of multiple servers.

[0096] Methods for determining the cause of abnormal exit may include: receiving abnormal exit information and a thread file from the application, wherein the thread file contains the application's start time and / or end time, as well as thread wake-up data during application execution; and determining the cause of the application's abnormal exit based on the thread file.

[0097] The thread file and thread wake-up data here can be obtained using the methods described above, which will not be repeated here. By analyzing the thread wake-up data recorded in the thread file, it can be determined whether the abnormal exit of the application is related to thread wake-up, thereby guiding application optimization and improving the stability of application operation.

[0098] Figure 4 This is a block diagram illustrating a thread wake-up monitoring device according to an exemplary embodiment. Figure 4 As shown, the thread wake-up monitoring device includes an acquisition unit 100, a storage unit 200, and a sending unit 300.

[0099] The acquisition unit 100 can be configured to acquire thread wake-up data of the application during a predetermined duration during the current run.

[0100] The storage unit 200 can be configured to save the acquired thread wake-up data and the index identifier corresponding to the thread wake-up data to the thread file.

[0101] The sending unit 300 can be configured to send a thread file to the server when the application is started again after the current run has ended, if the exit of the current run is detected as an abnormal exit, in order to determine the reason for the abnormal exit of the application.

[0102] As an example, the thread wake-up monitoring device 10 may also include a creation unit 400, which can be configured to: search for a thread file; if the thread file is not found, create a thread file and map the file address of the created thread file to the application's process virtual address space.

[0103] As an example, creation unit 400 can also be configured to map the file address of the created thread file to the application's process virtual address space based on the mmap function.

[0104] As an example, the storage unit 200 can also be configured to: save the acquired thread wake-up data and the corresponding index identifier to the thread file, and increment the number of data saved in the thread file by 1. When the number of data saved in the thread file exceeds the storage threshold, the index identifier in the thread file indicates that the earliest saved thread wake-up data will be deleted.

[0105] As an example, the thread wake-up data includes the number of threads woken up. The acquisition unit 100 can also be configured to: acquire the total number of threads woken up in the current lifecycle of the application at the current time with a predetermined time interval; and use the difference between the total number of threads woken up at the current time and the total number of threads woken up at the previous time as the number of threads woken up within the predetermined time interval.

[0106] As an example, the thread wake-up monitoring device 10 may also include a control unit 500, which may be configured to: determine the sum of the number of thread wake-ups in all thread wake-up data stored in the thread file; and stop the application from running when the sum is equal to or greater than the wake-up number threshold.

[0107] As an example, the save threshold and the predetermined duration can be determined by a time threshold, wherein the application stops running when the total number of threads woken up in the current lifecycle of the application is equal to or greater than the wake-up number threshold and the running time of the application in the current lifecycle is less than the time threshold.

[0108] As an example, the thread wake-up monitoring device 10 may also include a deletion unit 600, which may be configured to delete the thread wake-up data stored in the thread file when the application is launched again and the exit of the current run of the application is detected to be a normal exit.

[0109] As an example, the thread file has a circular queue data structure.

[0110] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0111] Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Figure 5 As shown, the electronic device 1000 may include a processor 1001 and a memory 1002 for storing processor-executable instructions. Here, when the processor-executable instructions are executed by the processor 1001, they cause the processor 1001 to execute the thread wake-up monitoring method as described in the exemplary embodiment above.

[0112] As an example, electronic device 1000 is not necessarily a single device, but can be a collection of any means or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 1000 can also be part of an integrated control system or system manager, or can be configured to interconnect with a server locally or remotely (e.g., via wireless transmission) through an interface.

[0113] In electronic device 1000, processor 1001 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 1001 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0114] The processor 1001 can execute instructions or code stored in the memory 1002, which can also store data. Instructions and data can also be sent and received over a network via a network interface device, which can employ any known transmission protocol.

[0115] The memory 1002 may be integrated with the processor 1001, for example, by arranging RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 1002 may include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 1002 and the processor 1001 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 1001 to read files stored in the memory 1002.

[0116] In addition, the electronic device 1000 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device 1000 can be connected to each other via a bus and / or network.

[0117] In an exemplary embodiment, a computer-readable storage medium may also be provided, which, when executed by a processor, enables the processor to perform the thread wake-up monitoring method as described in the exemplary embodiment above. The computer-readable storage medium may be, for example, a memory including instructions. Optionally, the computer-readable storage medium may be: a read-only memory (ROM), a random access memory (RAM), a random access programmable read-only memory (PROM), an electrically erasable programmable read-only memory (EEPROM), a dynamic random access memory (DRAM), a static random access memory (SRAM), flash memory, non-volatile memory, a CD-ROM, a CD-R, a CD+R, a CD-RW, a CD+RW, a DVD-ROM, a DVD-R, a DVD+R, a DVD-RW, a DVD+RW, a DVD-RAM, a BD-ROM, a BD-R, or a BD-R... LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0118] In an exemplary embodiment, a computer program product may also be provided, which includes computer instructions that, when executed by a processor, implement the thread wake-up monitoring method as described in the exemplary embodiment above.

[0119] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0120] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A thread wake-up monitoring method, characterized in that, The thread wake-up monitoring method includes: Retrieve thread wake-up data for the application during the predetermined duration of this run; The acquired thread wake-up data and the index identifier corresponding to the thread wake-up data are saved to a thread file. The file address of the thread file is mapped to the process virtual address space of the application based on the mmap function. The thread file stores the thread wake-up data of the application during a single run. After the application exits during its current run, upon the next launch of the application, if the exit is detected as an abnormal exit, the thread file is sent to the server to determine the reason for the abnormal exit. The step of saving the acquired thread wake-up data and the corresponding index identifier to a thread file includes: saving the acquired thread wake-up data and the corresponding index identifier to the thread file, and incrementing the number of data entries saved in the thread file by 1. When the number of data entries saved in the thread file exceeds a saving threshold, the earliest saved thread wake-up data indicated by the index identifier in the thread file is deleted. The saving threshold and the predetermined duration are determined by a time threshold, which is used to determine whether the application needs to be stopped. The thread wake-up data includes the number of threads woken up, and the thread wake-up monitoring method further includes: Determine the sum of the number of threads woken up in all the thread wake-up data stored in the thread file; When the sum is equal to or greater than the wake-up count threshold, the application stops running.

2. The thread wake-up monitoring method according to claim 1, characterized in that, The thread wake-up monitoring method also includes: Locate the thread file; If the thread file is not found, a thread file is created, and the file address of the created thread file is mapped to the process virtual address space of the application.

3. The thread wake-up monitoring method according to claim 2, characterized in that, The steps of mapping the file address of the created thread file to the process virtual address space of the application include: Based on the mmap function, the file address of the created thread file is mapped to the process virtual address space of the application.

4. The thread wake-up monitoring method according to claim 1, characterized in that, The steps to obtain thread wake-up data for the application during the current run within a predetermined duration include: Using the predetermined duration as the time interval, obtain the total number of threads woken up in the current lifecycle of the application at the current time; The difference between the total number of threads woken up at the current time and the total number of threads woken up at the previous time is taken as the number of threads woken up within the predetermined time period.

5. The thread wake-up monitoring method according to claim 1, characterized in that, The thread wake-up monitoring method further includes: stopping the application when the total number of thread wake-ups in the current lifecycle of the application is equal to or greater than the wake-up number threshold and the running time of the application in the current lifecycle is less than the time threshold.

6. The thread wake-up monitoring method according to claim 1, characterized in that, The thread wake-up monitoring method also includes: When the application is launched again, if it is detected that the application exited normally this time, the thread wake-up data stored in the thread file is deleted.

7. The thread wake-up monitoring method according to claim 1, characterized in that, The thread file has a circular queue data structure.

8. A method for determining the cause of abnormal exit, characterized in that, The determination method includes: Receive abnormal exit information and thread file from the application, wherein the thread file contains the start time and / or end time of the application and thread wake-up data during the operation of the application, and the thread file is obtained by executing the thread wake-up monitoring method according to any one of claims 1 to 7 on the application. Based on the thread file, the reason for the abnormal termination of the application is determined.

9. A thread wake-up monitoring device, characterized in that, The thread wake-up monitoring device includes: The acquisition unit is configured to acquire thread wake-up data of the application within a predetermined time period; The storage unit is configured to save the acquired thread wake-up data and the index identifier corresponding to the thread wake-up data to a thread file, wherein the file address of the thread file is mapped to the process virtual address space of the application based on the mmap function, and the thread file stores the thread wake-up data of the application during a single run. The sending unit is configured to, after the application exits in its current run, upon the next startup of the application, send the thread file to the server if it detects that the application's current exit was an abnormal exit, in order to determine the reason for the abnormal exit of the application. The storage unit is further configured to: save the acquired thread wake-up data and corresponding index identifiers to the thread file, and increment the number of data items saved in the thread file by 1. When the number of data items saved in the thread file exceeds a storage threshold, the earliest saved thread wake-up data, indicated by the index identifier in the thread file, is deleted. The storage threshold and the predetermined duration are determined by a time threshold, which is used to determine whether the application needs to be stopped. The thread wake-up data includes the number of threads woken up, and the thread wake-up monitoring device further includes a control unit. The control unit is configured to: determine the sum of the number of threads woken up in all the thread wake-up data stored in the thread file; and stop the application from running when the sum is equal to or greater than the wake-up number threshold.

10. The thread wake-up monitoring device according to claim 9, characterized in that, The thread wake-up monitoring device further includes a creation unit, which is configured to: search for the thread file; if the thread file is not found, create the thread file and map the file address of the created thread file to the process virtual address space of the application.

11. The thread wake-up monitoring device according to claim 10, characterized in that, The creation unit is also configured to: map the file address of the created thread file to the process virtual address space of the application based on the mmap function.

12. The thread wake-up monitoring device according to claim 9, characterized in that, The acquisition unit is further configured to: Using the predetermined duration as the time interval, obtain the total number of threads woken up in the current lifecycle of the application at the current time; The difference between the total number of threads woken up at the current time and the total number of threads woken up at the previous time is taken as the number of threads woken up within the predetermined time period.

13. The thread wake-up monitoring device according to claim 9, characterized in that, When the total number of threads woken up in the current lifecycle of the application is equal to or greater than the wake-up number threshold and the running time of the application in the current lifecycle is less than the time threshold, the application shall be stopped.

14. The thread wake-up monitoring device according to claim 9, characterized in that, The thread wake-up monitoring device further includes a deletion unit, which is configured to delete the thread wake-up data stored in the thread file when the application is launched again and the exit of the current run of the application is detected to be a normal exit.

15. The thread wake-up monitoring device according to claim 9, characterized in that, The thread file has a circular queue data structure.

16. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store the processor's executable instructions. Wherein, when the processor-executable instructions are executed by the processor, they cause the processor to execute the thread wake-up monitoring method according to any one of claims 1 to 7 or the method for determining the cause of abnormal exit according to claim 8.

17. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the thread wake-up monitoring method according to any one of claims 1 to 7 or the method for determining the cause of abnormal exit according to claim 8.

18. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the thread wake-up monitoring method according to any one of claims 1 to 7 or the method for determining the cause of abnormal exit according to claim 8.

Images