A data processing method and device, electronic equipment and storage medium

Abstract

The application provides a data processing method and device, electronic equipment and storage medium. A time when a freezing phenomenon is expected to occur in the running process of an application is acquired. The time is predicted according to historical running data of the application. Whether the application is in the time when the freezing phenomenon is expected to occur is determined. In the case that the application is in the time when the freezing phenomenon is expected to occur, whether the freezing phenomenon occurs in the application is monitored. In the case that the freezing phenomenon occurs in the application, the call stack of the main thread allocated by the terminal for the application is acquired multiple times in succession in an intermittent manner. The call stack at least includes the function name of the function in the application being called by the main thread. The function causing the freezing phenomenon is determined according to the function name in the call stack acquired multiple times in a time sequence. Invalid detection can be avoided, excessive system resources can be saved, and the accuracy of determining the function causing the freezing phenomenon can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and in particular, to a data processing method and device, electronic equipment and storage medium. BACKGROUND

[0002] With the rapid development of technology, application programs are gradually indispensable in people's life and work. The stability of the application program has a very important influence on user experience, user growth and user retention.

[0003] Among them, in the case that the user needs to use the application program on the terminal, the terminal will allocate a main thread for the application program, and the main thread can run the application program, so that the user can use the application program.

[0004] The inventor found through statistical analysis of the current situation that during the process of running the application program by the main thread, sometimes it will be stuck, which will cause the user to be unable to normally use the application program, will bring very poor user experience to the user, will reduce the user retention rate of the application program, and will cause loss to the manufacturer of the application program.

[0005] In view of this, the demand of improving the user experience, improving the user retention rate of the application program, and avoiding loss to the manufacturer of the application program is put forward.

[0006] In order to achieve the purpose of "improving the user experience, improving the user retention rate of the application program, and avoiding loss to the manufacturer of the application program", in one way, after the application program is started, the application program can be continuously monitored in real time whether the application program has a stuck phenomenon, if the application program has a stuck phenomenon, the reason for the stuck phenomenon of the application program is analyzed, so that the developer can optimize the application program according to the reason, so as to avoid the application program of the subsequent version from being stuck due to this reason as much as possible, so as to improve the user experience in the process of using the application program of the subsequent version, improve the user retention rate of the application program of the subsequent version, and avoid loss to the manufacturer of the application program.

[0007] However, the inventor found that in the above-mentioned way, the process of continuously monitoring the application program in real time after the application program is started whether the application program has a stuck phenomenon will consume more system resources. SUMMARY

[0008] The present application shows a kind of data processing method, device, electronic equipment and storage medium.

[0009] In a first aspect, the present application shows a kind of data processing method, applied to terminal, and the terminal runs application program, and the method comprises:

[0010] acquire a time when the application is expected to have a frame freezing phenomenon; the time when the application is expected to have the frame freezing phenomenon is predicted according to historical running data of the application;

[0011] determine whether the application is at the time when the frame freezing phenomenon is expected to occur;

[0012] monitor whether the application has the frame freezing phenomenon in a case where the application is at the time when the frame freezing phenomenon is expected to occur;

[0013] in a case where the application has the frame freezing phenomenon, acquire a call stack of a main thread allocated by the terminal for the application intermittently and successively for multiple times, the call stack including a function name of a function in the application being called by the main thread;

[0014] determine the function causing the frame freezing phenomenon according to at least the function names in the call stacks acquired successively for the multiple times.

[0015] In an optional implementation, the determining the function causing the frame freezing phenomenon according to at least the function names in the call stacks acquired successively for the multiple times includes:

[0016] acquire the function name at the top of each call stack acquired for the multiple times;

[0017] determine the function causing the frame freezing phenomenon according to at least the function names at the top of each call stack acquired for the multiple times.

[0018] In an optional implementation, the determining the function causing the frame freezing phenomenon according to at least the function names at the top of each call stack acquired for the multiple times includes:

[0019] count a continuous calling duration of the function corresponding to the function name at the top of each call stack acquired for the multiple times being called by the main thread;

[0020] determine the function causing the frame freezing phenomenon according to the continuous calling duration of the function corresponding to the function name at the top of each call stack acquired for the multiple times being called by the main thread.

[0021] In an optional implementation, the counting the continuous calling duration of the function corresponding to the function name at the top of each call stack acquired for the multiple times being called by the main thread includes:

[0022] The call stacks with the sequential order acquired multiple times are divided into at least one call stack group according to the sequential order; the function names at the top of each call stack in the same call stack group are the same, and the function names at the top of the call stacks in different call stack groups are different;

[0023] For any one of the at least one call stack group, the duration of the function corresponding to the function name at the top of the call stack in the call stack group being called by the main thread is acquired according to the time interval between the acquisition time when the call stack with the last sequential order in the call stack group is acquired and the acquisition time when the call stack with the first sequential order in the call stack group is acquired.

[0024] Or,

[0025] For any one of the at least one call stack group, the duration of the function corresponding to the function name at the top of the call stack in the call stack group being called by the main thread is acquired according to the time interval between the acquisition time when the call stack with the first sequential order in the call stack group adjacent to the call stack group is acquired and the acquisition time when the call stack with the first sequential order in the call stack group is acquired.

[0026] In an optional implementation, the function causing the freezing phenomenon is determined according to the duration of the function corresponding to the function name at the top of each call stack acquired multiple times being called by the main thread, comprising:

[0027] Among the functions corresponding to the function names at the top of each call stack acquired multiple times, the function with a duration of being called by the main thread greater than a preset duration is selected;

[0028] The function causing the freezing phenomenon is determined according to the selected function.

[0029] In an optional implementation, the historical running data of the application program comprises: the number of times of the freezing phenomenon occurring when the application program displays each of the at least one page in a historical time period is greater than a preset number of times;

[0030] The determination of whether the application program is at the time when the freezing phenomenon is expected to occur comprises:

[0031] When the application program displays one of the at least one page, it is determined that the application program is at the time when the freezing phenomenon is expected to occur.

[0032] In an optional implementation, the historical running data of the application program comprises: at least one specific time length, the number of times of occurrence of the lag phenomenon of the application program after the application program is started at each of the at least one specific time length in a historical time period is greater than a preset number of times;

[0033] The determining whether the application program is in the time when the lag phenomenon is expected to occur comprises:

[0034] In a case where a current time of the application program reaches one of the at least one specific time length from a start time when the application program is started on the terminal, it is determined that the application program is in the time when the lag phenomenon is expected to occur.

[0035] In an optional implementation, the historical running data of the application program comprises: at least one specific operation, the number of times of occurrence of the lag phenomenon of the application program in a case where each of the at least one specific operation is received in a running process of the application program in a historical time period is greater than a preset number of times.

[0036] The determining whether the application program is in the time when the lag phenomenon is expected to occur comprises:

[0037] In a case where one of the at least one specific operation is received by the application program, it is determined that the application program is in the time when the lag phenomenon is expected to occur.

[0038] In a second aspect, a data processing apparatus is shown, which is applied to a terminal, and an application program is run on the terminal. The apparatus comprises:

[0039] A first obtaining module is configured to obtain a time when a lag phenomenon is expected to occur in a running process of the application program, and the time when the lag phenomenon is expected to occur is predicted according to historical running data of the application program.

[0040] A first determining module is configured to determine whether the application program is in the time when the lag phenomenon is expected to occur.

[0041] A monitoring module is configured to monitor whether the application program occurs the lag phenomenon in a case where the application program is in the time when the lag phenomenon is expected to occur.

[0042] A second obtaining module is configured to intermittently obtain a call stack of a main thread of the application program allocated by the terminal for the application program for multiple times in a case where the application program occurs the lag phenomenon, and the call stack comprises a function name of a function in the application program being called by the main thread.

[0043] The second determining module is configured to determine the function causing the freezing phenomenon according to at least the function names in the call stacks acquired multiple times in the order.

[0044] In an optional implementation, the second determining module includes:

[0045] The acquisition unit is configured to acquire the function name at the top of each call stack acquired multiple times;

[0046] The first determining unit is configured to determine the function causing the freezing phenomenon according to at least the function name at the top of each call stack acquired multiple times.

[0047] In an optional implementation, the first determining unit includes:

[0048] The statistical subunit is configured to statistically determine the continuous calling duration of the function corresponding to the function name at the top of each call stack acquired multiple times, which is called by the main thread.

[0049] The determining subunit is configured to determine the function causing the freezing phenomenon according to the continuous calling duration of the function corresponding to the function name at the top of each call stack acquired multiple times, which is called by the main thread.

[0050] In an optional implementation, the statistical subunit is specifically configured to:

[0051] The call stacks acquired multiple times in the order are divided into at least one call stack group in the order; the function names at the top of the call stacks in the same call stack group are the same, and the function names at the top of the call stacks in different call stack groups are different;

[0052] For any one of the at least one call stack group, the continuous calling duration of the function corresponding to the function name at the top of the call stack in the call stack group is acquired according to the time interval between the acquisition time when the call stack at the last position in the order in the call stack group is acquired and the acquisition time when the call stack at the first position in the order in the call stack group is acquired.

[0053] Or,

[0054] For any one of the at least one call stack group, the continuous calling duration of the function corresponding to the function name at the top of the call stack in the call stack group is acquired according to the time interval between the acquisition time when the call stack at the first position in the order in the call stack group adjacent to the call stack group is acquired and the acquisition time when the call stack at the first position in the order in the call stack group is acquired.

[0055] In an optional implementation, the determining subunit is specifically configured to:

[0056] In the function corresponding to the function name at the top of the stack in each of the plurality of acquired call stacks, a function called by the main thread and having a call duration greater than a preset duration is selected.

[0057] According to the selected function, a function causing the freezing phenomenon is determined.

[0058] In an optional implementation, the historical running data of the application program includes: at least one page in the application program, a number of times that the application program has occurred the freezing phenomenon when respectively displaying each of the at least one page in a historical time period is greater than a preset number of times.

[0059] The first determining module includes:

[0060] The second determining unit is configured to determine that the application program is in the time when the freezing phenomenon is expected to occur when the application program displays one of the at least one page.

[0061] In an optional implementation, the historical running data of the application program includes: at least one specific duration, a number of times that the application program has occurred the freezing phenomenon when respectively starting after an interval of each of the at least one specific duration in a historical time period is greater than a preset number of times.

[0062] The first determining module includes:

[0063] The third determining unit is configured to determine that the application program is in the time when the freezing phenomenon is expected to occur when a current time of the application program reaches one of the at least one specific duration from a start time when the application program is started on the terminal.

[0064] In an optional implementation, the historical running data of the application program includes: at least one specific operation, a number of times that the application program has occurred the freezing phenomenon when respectively receiving each of the at least one specific operation in a historical time period is greater than a preset number of times.

[0065] The first determining module includes:

[0066] The fourth determining unit is configured to determine that the application program is in the time when the freezing phenomenon is expected to occur when the application program receives one of the at least one specific operation.

[0067] In a third aspect, the present application shows an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the data processing method of any one of the above aspects.

[0068] In a fourth aspect, the present application shows a non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, the electronic device can execute the data processing method of any one of the above aspects.

[0069] In a fifth aspect, the present application shows a computer program product, when the instructions in the computer program product are executed by a processor of an electronic device, the electronic device can execute the data processing method of any one of the above aspects.

[0070] The technical solutions provided by the present application can include the following beneficial effects:

[0071] In the present application, the time when the application program is expected to have a freezing phenomenon is obtained. The time when the freezing phenomenon is expected to occur is predicted according to the historical running data of the application program. It is determined whether the application program is in the time when the freezing phenomenon is expected to occur. In the case that the application program is in the time when the freezing phenomenon is expected to occur, it is monitored whether the application program has a freezing phenomenon. In the case that the application program has a freezing phenomenon, the call stack of the main thread allocated by the terminal for the application program is intermittently obtained for multiple times in sequence, and the call stack at least includes the function name of the function in the application program being called by the main thread. At least according to the function name in the call stack obtained for multiple times in sequence, the function causing the freezing phenomenon is determined.

[0072] On the one hand, it is found through statistics that in the case that the application program is in the time when the freezing phenomenon is expected to occur, the application program is likely to have a freezing phenomenon, and in the case that the application program is not in the time when the freezing phenomenon is expected to occur, the application program is not likely to have a freezing phenomenon.

[0073] In this way, in the case that the application program is not in the time when the freezing phenomenon is expected to occur, the effectiveness of monitoring whether the application program has a freezing phenomenon is low or meaningless, that is, it is unnecessary to monitor whether the application program has a freezing phenomenon in the state that the application program is not likely to have a freezing phenomenon, and it can be seen that monitoring whether the application program has a freezing phenomenon in the state that the application program is not likely to have a freezing phenomenon is often invalid monitoring, and system resources are often wasted.

[0074] The application predicts the time when the application program is expected to have the lag phenomenon by using the historical running data of the application program, and monitors whether the application program has the lag phenomenon when the application program is at the time when the lag phenomenon is expected to occur. When the application program is not at the time when the lag phenomenon is expected to occur, the application program can not be monitored whether the application program has the lag phenomenon.

[0075] When the application program is at the time when the lag phenomenon is expected to occur, the effectiveness and significance of monitoring whether the application program has the lag phenomenon are high, that is, it is necessary to monitor whether the application program has the lag phenomenon when the application program is likely to have the lag phenomenon. It can be seen that monitoring whether the application program has the lag phenomenon when the application program is likely to have the lag phenomenon is often effective detection.

[0076] In this way, compared with the way of continuously monitoring whether the application program has the lag phenomenon during the running of the application program, the application monitors whether the application program has the lag phenomenon when necessary and can not monitor whether the application program has the lag phenomenon when unnecessary, thereby avoiding ineffective detection, avoiding wasting too many system resources, and saving system resources.

[0077] On the other hand, when the application program has the lag phenomenon, the calling stack of the main thread allocated by the terminal for the application program is intermittently acquired for multiple times in succession. The function name at the top of each calling stack corresponds to the function that is being called by the main thread of the application program at the time when the calling stack is acquired. In this way, the function that is being called by the main thread of the application program at the time when the calling stack is acquired can be obtained according to the function name at the top of the calling stack, and the acquisition time when each calling stack is acquired is different. In this way, the function that causes the lag phenomenon can be accurately determined according to the time interval between the acquisition times when the calling stacks are acquired and the function that is being called by the main thread of the application program at the time when the calling stack is acquired. For example, the duration of the continuous calling of at least part of the functions in the acquired multiple calling stacks by the main thread can be accurately determined, so that the function that causes the lag phenomenon can be accurately determined according to the duration of the continuous calling. In this way, the application can improve the accuracy of determining the function that causes the lag phenomenon. BRIEF DESCRIPTION OF DRAWINGS

[0078] Figure 1 is a step flow chart of a data processing method of the application.

[0079] Figure 2 is a step flow chart of a data processing method of the application.

[0080] Figure 3 is a structural block diagram of a data processing device of the application.

[0081] Figure 4 is a block diagram of an electronic device of the present application.

[0082] Figure 5 is a block diagram of an electronic device of the present application. DETAILED DESCRIPTION

[0083] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0084] Referring to Figure 1 , a step flowchart of a data processing method of the present application is shown, which is applied to a terminal, the terminal including a mobile phone or a tablet computer used by a large number of users, and the terminal running an application program, the terminal allocating a main thread for the application program, for example, the operating system of the terminal allocating a main thread for the application program. The method can specifically include the following steps:

[0085] In step S101, a time when a freezing phenomenon is predicted to occur in the process of running the application program is acquired. The time when the freezing phenomenon is predicted to occur is predicted according to historical running data of the application program.

[0086] In the present application, for the application program, the time when the freezing phenomenon occurs can include a plurality of, for example, can include that the application program displays a specific page, the application program receives a specific operation or is located after the start time when the application program is started, and the distance from the start time when the application program is started reaches a specific time length.

[0087] In step S102, it is determined whether the application program is at the time when the freezing phenomenon is predicted to occur.

[0088] In an embodiment, the historical running data of the application program includes that the application program has occurred a freezing phenomenon more than a preset number of times in a case that the application program respectively displays each of at least one page in a historical time period.

[0089] For example, in the process of running in the historical time period, the application program will display various pages, however, in the process of displaying some pages, the application program will not occur a freezing phenomenon, and in the process of displaying other pages, the application program will often occur a freezing phenomenon.

[0090] In this way, the number of times of occurrence of the freezing phenomenon in the process of displaying each page by the application program in the historical time period can be counted, and then the pages with the number of times of occurrence of the freezing phenomenon greater than the preset number of times are combined to form the historical running data of the application program.

[0091] The number of times of occurrence of the freezing phenomenon in the process of displaying each page by the application program in the historical time period can be counted by the server for the running data of the application program (the same application program) in a large number of terminals, or counted by the terminal for the running data of the application program in the terminal itself, etc.

[0092] The preset number of times can include 10, 20, or 30, etc., and can be determined according to actual conditions, which is not limited in the present application.

[0093] In this way, when determining whether the application program is in the time when the freezing phenomenon is expected to occur, it can be determined whether the application program displays one of the at least one page.

[0094] In the case where the application program displays one of the at least one page, it is determined that the application program is in the time when the freezing phenomenon is expected to occur.

[0095] Alternatively, in the case where the application program does not display one of the at least one page, it is determined that the application program is not in the time when the freezing phenomenon is expected to occur.

[0096] Then, the number of times of occurrence of the freezing phenomenon in the process of displaying each page by the application program in the historical time period can be updated according to the actual situation whether the freezing phenomenon occurs after the page is displayed, and the historical running data of the application program is updated to improve the accuracy of the time when the freezing phenomenon is expected to occur in the process of running the application program (more in line with the actual situation).

[0097] In another embodiment, the historical running data of the application program includes: at least one specific time length, the number of times of occurrence of the freezing phenomenon when the application program is started after the historical time period and each of the at least one specific time length is greater than the preset number of times.

[0098] For example, in the historical time period, after starting the application program, no freezing phenomenon occurs after a certain specific time length from the start of the application program, and freezing phenomenon occurs after another specific time length from the start of the application program.

[0099] Thus, after starting the application program and running the application program in the historical time period, the time length between the start time when the application program is started and the lag time when the lag phenomenon occurs each time can be counted each time the lag phenomenon occurs, and finally a large number of time lengths are obtained, some of which are the same, so the number of times of the same time length can be counted. Then the time length corresponding to the number of times greater than the preset number of times is used to form the historical running data of the application program, etc.

[0100] The time length between the start time when the application program is started and the lag time when the lag phenomenon occurs each time can be counted by the server for the running data of the application program (the same application program) in a large number of terminals, or can be counted by the terminal for the running data of the application program in the terminal itself, etc.

[0101] The preset number of times can include 10, 20, or 30, etc., which can be determined according to actual conditions, and the present application does not limit it.

[0102] Thus, when determining whether the application program is at the time when the lag phenomenon is expected to occur, it can be determined whether the current time of the application program reaches one of the at least one specific time length from the start time when the application program is started on the terminal.

[0103] In the case where the current time of the application program reaches one of the at least one specific time length from the start time when the application program is started on the terminal, it is determined that the application program is at the time when the lag phenomenon is expected to occur.

[0104] Alternatively, in the case where the current time of the application program does not reach one of the at least one specific time length from the start time when the application program is started on the terminal, it is determined that the application program is not at the time when the lag phenomenon is expected to occur.

[0105] After that, the number of times of the lag phenomenon occurring after the current time of the application program reaches one of the specific time lengths from the start time when the application program is started on the terminal can also be updated according to the actual situation whether the lag phenomenon occurs, and the historical running data of the application program is updated, so as to improve the accuracy of the time when the lag phenomenon is expected to occur in the process of running the application program (more in line with the actual situation).

[0106] In yet another embodiment, the historical running data of the application program includes: a number of times of the lag phenomenon occurring when the application program receives each of the at least one specific operation in the process of running in the historical time period is greater than a preset number of times.

[0107] For example, the application program receives various operations, such as a sliding operation, a clicking operation, a double-clicking operation, a long-pressing operation, and an operation on different buttons, during the process of running in the historical time period. The application program performs corresponding actions according to the received operations. After performing corresponding actions according to some operations, the application program does not have a freezing phenomenon. After performing corresponding actions according to other operations, the application program often has a freezing phenomenon.

[0108] In this way, the number of times of the freezing phenomenon after the application program receives each operation in the historical time period can be counted, and operations with a number of times of the freezing phenomenon greater than a preset number are included in the historical running data of the application program.

[0109] The number of times of the freezing phenomenon after the application program receives each operation in the historical time period can be counted by the server for the running data of the application program (the same application program) in a large number of terminals or by the terminal for the running data of the application program in the terminal itself.

[0110] The preset number can include 10, 20, or 30, and can be determined according to actual conditions. The application does not limit this.

[0111] In this way, when it is determined whether the application program is in the time when the freezing phenomenon is expected to occur, it can be determined whether the application program receives one of the at least one specific operation.

[0112] In the case where the application program receives one of the at least one specific operation, it is determined that the application program is in the time when the freezing phenomenon is expected to occur.

[0113] Alternatively, in the case where the application program does not receive one of the at least one specific operation, it is determined that the application program is not in the time when the freezing phenomenon is expected to occur.

[0114] Then, the number of times of the freezing phenomenon after the application program receives each specific operation in the process of running in the historical time period can be updated according to the actual situation of whether the freezing phenomenon occurs after the application program receives the operation, and the historical running data of the application program is updated to improve the accuracy (more consistent with the actual situation) of the time when the freezing phenomenon is expected to occur in the process of running of the application program.

[0115] In the case where the application program is in the time when the freezing phenomenon is expected to occur, in step S103, it is monitored whether the application program has a freezing phenomenon.

[0116] In another embodiment, in a case where the application is not in the timing in which the freezing phenomenon is expected to occur, the application can not be monitored for the freezing phenomenon.

[0117] Alternatively, in another embodiment, in a case where the application is not in the timing in which the freezing phenomenon is expected to occur, the step S102 can be returned to be executed.

[0118] Alternatively, in another embodiment, in a case where the application is in the timing in which the freezing phenomenon is expected to occur, after the application is monitored for the freezing phenomenon, the application can no longer be in the timing in which the freezing phenomenon is expected to occur during the running process. In a case where the application is no longer in the timing in which the freezing phenomenon is expected to occur, the application can no longer be monitored for the freezing phenomenon, etc.

[0119] In this step, the sub-thread can be created, and then the message loop state data of the main thread recorded in the message loop function of the main thread can be acquired based on the sub-thread, and then the continuous execution duration of the binary file of the function executed by the main thread can be acquired according to the message loop state data.

[0120] The operating system of the terminal can allocate the message loop function to the main thread, and the message loop function can include a Runloop function or a Looper function, etc.

[0121] The message loop function is used to process various events (such as touch events, UI refresh events, or timer events, etc.) occurring in the running process of the executable file of the application.

[0122] The operating system of the terminal provides an API (Application Programming Interface) externally to monitor the message loop function, so that the message loop state data of the main thread recorded in the message loop function of the main thread can be monitored through the API,

[0123] The continuous duration of the Timer event, the Source event, and the wake-up event of the one function in the message loop state data can be acquired, and the longest continuous duration is taken as the continuous execution duration of the process of the binary file of the one function executed by the main thread.

[0124] In a case where the continuous execution duration is greater than or equal to a duration, the freezing phenomenon of the application occurs. The duration can be set in advance according to actual conditions, for example, 3 seconds, 4 seconds, or 5 seconds, etc., which is not limited in the present application.

[0125] In one embodiment, an observer of CFRunLoopObserverContext can be created to receive various callback events of a Runloop provided by an operating system of the terminal, and the observer is added to the common mode of the Runloop in the main thread; then a sub-thread is created to continuously listen to the callback events of the Runloop of the main thread, and a timeout duration corresponding to the freezing phenomenon can be set in the sub-thread in advance by using the signal mechanism; after the signal timeout signal is triggered, the current monitored Runloop state of the main thread is detected.

[0126] The callback events supported by the Runloop include RunloopEntry, RunloopBeforeTimers, RunloopBeforeSources, RunloopBeforeWaiting, RunloopAfterWaiting, and RunloopExit, etc. The processing of the user interaction event UIEvent is located between the RunloopBeforeSources and RunloopBeforeWaiting event callbacks, so that if the Runloop state of the main thread continuously remains kCFRunLoopBeforeSources or kCFRunLoopAfterWaiting for a duration without any change (for example, no new callback event is received), it can be determined that the freezing phenomenon occurs in the application.

[0127] In the case where the freezing phenomenon occurs in the application, in step S104, the call stack of the main thread allocated by the terminal for the application is intermittently acquired for multiple times, and the call stack at least includes the function name of the function in the application being called by the main thread.

[0128] In another embodiment of the present application, in the case where the freezing phenomenon does not occur in the application, the step S103 can be returned to execute.

[0129] In the process of running the application, the main thread allocated by the terminal for the application calls the functions of the application to implement certain functions of the application through the functions.

[0130] In one case, the main thread often continuously or nestedly calls multiple functions of the application in sequence.

[0131] For example, suppose the main thread needs to call a function in an application to achieve a certain goal. This function contains another function nested within it. Therefore, during the main thread's call to this function, it needs to call another function within the application. Furthermore, this other function contains another function nested within it. Therefore, during the main thread's call to this function, it needs to call yet another function within the application.

[0132] In this way, assuming that the application freezes in the process of calling functions in sequence to achieve this goal, it is necessary to determine which functions caused the freeze, that is, it is necessary to determine which functions among this function, another function, and another function caused the freeze.

[0133] Among them, the function name of the function called by the main thread of the application is stored in the call stack.

[0134] For example, when the main thread needs to call a function, it stores the function name in the call stack. After the function is called, it is deleted from the call stack. The principle of the call stack is first-in, last-out. Function names that enter the call stack earlier are closer to the bottom of the stack, and function names that enter the call stack later are closer to the top of the stack.

[0135] Thus, in the above example, when the main thread needs to call this function of the application, the function name of this function can be stored in the call stack. At this time, the function name of this function is at the top of the call stack.

[0136] This function is nested within another function. Therefore, when the main thread calls this function, it needs to call another function. When the main thread needs to call another function, it can store the name of the other function on the call stack. This function's name is located closer to the bottom of the call stack than the other function's name.

[0137] Another function is nested within another function. Thus, when the main thread calls another function in the application, it needs to call yet another function in the application. When the main thread needs to call yet another function in the application, it can store the name of the yet another function in the call stack. At this point, the name of the yet another function is at the top of the call stack. The name of the yet another function is closer to the bottom of the call stack than the name of the yet another function.

[0138] After the main thread calls the other function, the function name of the other function can be deleted from the call stack, and then the function name of the other function is located at the top of the call stack, and the function name of the one function is closer to the bottom of the call stack than the function name of the other function in the call stack.

[0139] Then the main thread returns to call the other function, and after the main thread calls the other function, the function name of the other function can be deleted from the call stack, and then the function name of the one function is located at the top of the call stack.

[0140] Then the main thread returns to call the one function, and after the main thread calls the one function, the function name of the one function can be deleted from the call stack, and then the function name of the one function does not exist in the call stack.

[0141] In the case where it is necessary to determine which functions cause the frame freezing phenomenon, the call stack of the main thread allocated by the terminal for the application program can be obtained intermittently and multiple times in succession. The multiple call stacks obtained have a chronological order. The call stack obtained earlier has a more advanced chronological order, and the call stack obtained later has a more backward chronological order.

[0142] “Intermittently” can include waiting regularly, for example, obtaining the call stack of the main thread allocated by the terminal for the application program every 10 ms, 20 ms, 50 ms or 100 ms.

[0143] For any call stack obtained, the function name located at the top of the call stack corresponds to a function that is being called by the main thread at the time when the call stack is obtained. The function name not located at the top of the call stack corresponds to a function that is not being called by the main thread at the time when the call stack is obtained. The function not being called can also be a function not called.

[0144] Since the function name located at the top of the call stack of the main thread obtained multiple times is not the same. And the time interval between the time when the call stack of the main thread is obtained adjacent to each other has a specific interval, so that the function causing the frame freezing phenomenon can be determined according to the function name located at the top of the call stack of the main thread obtained multiple times. For details, see the embodiments below, which are not described here.

[0145] In step S105, the function causing the frame freezing phenomenon is determined according to at least the function names in the call stacks obtained multiple times and having a chronological order.

[0146] In another embodiment of the present application, referring to Figure 2 , step S105 can be implemented by the following flow, comprising:

[0147] In step S201, the function name at the top of each call stack acquired multiple times is acquired.

[0148] Among them, for any call stack, the main thread is calling the function name at the top of the call stack when the call stack is acquired. The same is true for every other call stack.

[0149] In step S202, the function that causes the stall phenomenon is determined according to at least the function name at the top of each call stack acquired multiple times.

[0150] Among them, this step can be implemented by the following process, including:

[0151] 2021, the duration of the function corresponding to the function name at the top of each call stack acquired multiple times being called by the main thread is counted.

[0152] In this application, the call stacks acquired multiple times with a chronological order can be divided into at least one call stack group according to the chronological order. The function names at the top of the call stacks in the same call stack group are the same (one call stack group may have one call stack, or more than two call stacks, etc.), and the function names at the top of the call stacks in different call stack groups are different.

[0153] Among them, in the case of more than two call stack groups, the more than two call stack groups have a chronological order, which can be determined according to the chronological order of the call stacks included in each call stack group (such as the chronological order of the acquisition time when the call stack is acquired, etc.). For example, the earlier the chronological order of the included call stacks, the earlier the chronological order of the call stack group, and the later the chronological order of the included call stacks, the later the chronological order of the call stack group.

[0154] In an embodiment of the present application, for any call stack group in at least one call stack group, the duration of the function corresponding to the function name at the top of the call stack in the call stack group is acquired according to the time interval between the acquisition time when the call stack group adjacent to the call stack group is acquired. The call stack with the first chronological order in the call stack group, and the acquisition time when the call stack with the first chronological order in the call stack group is acquired.

[0155] For example, the time interval is taken as the duration of the function corresponding to the function name at the top of the call stack in the call stack group being called by the main thread.

[0156] In the present application, the acquisition time when each call stack is acquired is the time when the call stack can be acquired in real time when the call stack is acquired.

[0157] The same is true for each of the other call stack groups in the at least one call stack group.

[0158] For example, in the above example of "this function", "another function", and "yet another function", assuming that yet another function triggers the lag phenomenon, in the process of acquiring the call stack multiple times at intervals, at least two identical call stacks are often continuously acquired, in which the top of the stack is the function name of yet another function, the bottom of the stack is the function name of this function, and the function name of another function is located between the function name of yet another function and the function name of yet another function.

[0159] The function name of yet another function no longer exists in the call stack acquired after the main thread calls the function of yet another function for a long time.

[0160] In one possible case, at least one call stack acquired after the main thread calls the function of yet another function for a long time includes the function name of another function and the function name of this function (the function name of another function is at the top of the stack).

[0161] Alternatively, in another possible case, at least one call stack acquired after the main thread calls the function of yet another function for a long time includes the function name of this function (the function name of this function is at the top of the stack).

[0162] Alternatively, in yet another possible case, at least one call stack acquired after the main thread calls the function of yet another function for a long time does not include the function name of another function and the function name of this function.

[0163] In this way, the duration of the continuous call of yet another function by the main thread can be acquired through the relevant data of at least two identical call stacks in which the top of the stack is the function name of yet another function.

[0164] The duration of the continuous call of another function by the main thread can be acquired through the relevant data of at least one call stack in which the top of the stack is the function name of another function.

[0165] The duration of the continuous call of this function by the main thread can be acquired through the relevant data of at least one call stack in which the top of the stack is the function name of this function.

[0166] In the above example, three call stack groups can be obtained, the call stack group at the top of which is the function name of the further function, the call stack group at the top of which is the function name of the other function, and the call stack group at the top of which is the function name of the one function.

[0167] The order of the further call stack group is earlier than the order of the other call stack group, and the order of the other call stack group is earlier than the order of the one call stack group.

[0168] The duration of the function corresponding to the function name at the top of the call stack in the further call stack group is obtained according to a time interval between a time when the call stack in the other call stack group adjacent to the further call stack group and later in the order is obtained and a time when the call stack in the further call stack group and earlier in the order is obtained. For example, the time interval is taken as the duration of the function corresponding to the function name at the top of the call stack in the further call stack group.

[0169] The duration of the function corresponding to the function name at the top of the call stack in the other call stack group is obtained according to a time interval between a time when the call stack in the one call stack group adjacent to the other call stack group and later in the order is obtained and a time when the call stack in the other call stack group and earlier in the order is obtained. For example, the time interval is taken as the duration of the function corresponding to the function name at the top of the call stack in the other call stack group.

[0170] The duration of the function corresponding to the function name at the top of the call stack in the one call stack group is obtained according to a time interval between a time when the call stack adjacent to the one call stack group is obtained and a time when the call stack in the one call stack group and earlier in the order is obtained. For example, the time interval is taken as the duration of the function corresponding to the function name at the top of the call stack in the one call stack group.

[0171] Alternatively, in another embodiment, for any one of the at least one call stack group, according to a time interval between a time when the call stack with the last order in the call stack group is acquired and a time when the call stack with the first order in the call stack group is acquired, a duration of a function corresponding to a function name at the top of the call stack in the call stack group is acquired.

[0172] For example, the time interval is taken as the duration of the function corresponding to the function name at the top of the call stack in the call stack group.

[0173] In the present application, the time when each call stack is acquired is the time when the call stack is acquired in real time.

[0174] The same is true for each of the at least one call stack group.

[0175] 2022, according to the duration of the function corresponding to the function name at the top of each call stack acquired multiple times, determine the function that causes the freezing phenomenon.

[0176] In this step, among the functions corresponding to the function names at the top of each call stack acquired multiple times, the function with a duration of being called by the main thread greater than a preset duration can be selected. According to the selected function, the function that causes the freezing phenomenon is determined, for example, the selected function can be determined as the function that causes the freezing phenomenon, etc.

[0177] The preset duration can be determined according to the actual situation, for example, including 150ms, 170ms or 200ms, etc., which is not limited in the present application.

[0178] Further, the function name of the function that causes the freezing phenomenon can also be uploaded to the server, so that the developer of the application can optimize the function corresponding to the function name in the application.

[0179] Further, the acquired call stack can also be sent to the server for recording, etc.

[0180] In the present application, the time when the application program is expected to have a lag phenomenon is obtained. The time when the lag phenomenon is expected to occur is predicted according to historical running data of the application program. It is determined whether the application program is in the time when the lag phenomenon is expected to occur. In the case where the application program is in the time when the lag phenomenon is expected to occur, it is monitored whether the application program has a lag phenomenon. In the case where the application program has a lag phenomenon, the call stack of the main thread allocated by the terminal for the application program is intermittently obtained for multiple times in sequence, and the call stack at least includes the function name of the function in the application program being called by the main thread. The function causing the lag phenomenon is determined according to the function name in the call stack obtained for multiple times in sequence.

[0181] In one aspect, it is found through statistics that in the case where the application program is in the time when the lag phenomenon is expected to occur, the application program is likely to have a lag phenomenon, and in the case where the application program is not in the time when the lag phenomenon is expected to occur, the application program is not likely to have a lag phenomenon.

[0182] Therefore, in the case where the application program is not in the time when the lag phenomenon is expected to occur, the effectiveness of monitoring whether the application program has a lag phenomenon is low or the significance is low, that is, it is unnecessary to monitor whether the application program has a lag phenomenon in the state where the application program is not likely to have a lag phenomenon, and it can be seen that monitoring whether the application program has a lag phenomenon in the state where the application program is not likely to have a lag phenomenon is often invalid monitoring and often wastes system resources.

[0183] The present application predicts the time when the application program is expected to have a lag phenomenon through historical running data of the application program, and monitors whether the application program has a lag phenomenon in the case where the application program is in the time when the lag phenomenon is expected to occur, and does not monitor whether the application program has a lag phenomenon in the case where the application program is not in the time when the lag phenomenon is expected to occur.

[0184] In the case where the application program is in the time when the lag phenomenon is expected to occur, the effectiveness of monitoring whether the application program has a lag phenomenon is high and the significance is high, that is, it is necessary to monitor whether the application program has a lag phenomenon in the state where the application program is likely to have a lag phenomenon, and it can be seen that monitoring whether the application program has a lag phenomenon in the state where the application program is likely to have a lag phenomenon is often effective detection.

[0185] Therefore, compared with the mode of continuously monitoring whether the application program has a lag phenomenon in the process of running the application program, the present application monitors whether the application program has a lag phenomenon in the case where it is necessary and does not monitor whether the application program has a lag phenomenon in the case where it is unnecessary, so as to avoid invalid detection, avoid wasting too much system resources, and save system resources.

[0186] In another aspect, in the case that the application program has a lag phenomenon, the call stack of the main thread allocated by the terminal for the application program is intermittently acquired multiple times in succession, and the function name at the top of each call stack corresponds to a function being called by the main thread of the application program at the time of acquiring the call stack. Thus, the function being called by the main thread of the application program at the time of acquiring the call stack can be obtained according to the function name at the top of the call stack, and the time interval between the acquisition times of each call stack is different. Thus, the function causing the lag phenomenon can be accurately determined according to the function being called by the main thread of the application program at the time of acquiring the call stack and the time interval between the acquisition times of each call stack. For example, the duration of the continuous calling of at least some of the functions in the acquired multiple call stacks by the main thread can be accurately determined, so that the function causing the lag phenomenon can be accurately determined according to the duration of the continuous calling. Thus, the accuracy of determining the function causing the lag phenomenon can be improved.

[0187] It should be noted that, for the method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited by the action order described, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all optional embodiments, and the actions involved are not necessarily required by the present application.

[0188] Reference Figure 3 , a structural block diagram of a data processing apparatus of the present application is shown, which is applied to a terminal, an application program is running on the terminal, and the apparatus comprises:

[0189] The first acquisition module 11 is configured to acquire a time when the application program is expected to have a lag phenomenon during running, and the time when the lag phenomenon is expected to occur is predicted according to historical running data of the application program;

[0190] The first determination module 12 is configured to determine whether the application program is at the time when the lag phenomenon is expected to occur;

[0191] The monitoring module 13 is configured to monitor whether the application program has a lag phenomenon in the case that the application program is at the time when the lag phenomenon is expected to occur;

[0192] The second acquisition module 14 is configured to intermittently acquire the call stack of the main thread allocated by the terminal for the application program multiple times in succession in the case that the application program has a lag phenomenon, and the call stack comprises the function name of the function in the application program being called by the main thread;

[0193] The second determining module 15 is configured to determine the function causing the freezing phenomenon according to at least the function names in the call stacks acquired at different times.

[0194] In an optional implementation, the second determining module includes:

[0195] The acquisition unit is configured to acquire the function name at the top of each call stack acquired at different times.

[0196] The first determining unit is configured to determine the function causing the freezing phenomenon according to at least the function name at the top of each call stack acquired at different times.

[0197] In an optional implementation, the first determining unit includes:

[0198] The statistical subunit is configured to statistically determine the continuous calling duration of the function corresponding to the function name at the top of each call stack acquired at different times.

[0199] The determining subunit is configured to determine the function causing the freezing phenomenon according to the continuous calling duration of the function corresponding to the function name at the top of each call stack acquired at different times.

[0200] In an optional implementation, the statistical subunit is specifically configured to:

[0201] The call stacks acquired at different times are divided into at least one call stack group according to the order of the call stacks; the function names at the top of the call stacks in the same call stack group are the same, and the function names at the top of the call stacks in different call stack groups are different.

[0202] For any one of the at least one call stack group, the continuous calling duration of the function corresponding to the function name at the top of the call stack in the call stack group is acquired according to the time interval between the acquisition time when the call stack at the last position in the call stack group is acquired and the acquisition time when the call stack at the first position in the call stack group is acquired.

[0203] Or,

[0204] For any one of the at least one call stack group, the continuous calling duration of the function corresponding to the function name at the top of the call stack in the call stack group is acquired according to the time interval between the acquisition time when the call stack at the first position in the call stack group adjacent to the call stack group is acquired and the acquisition time when the call stack at the first position in the call stack group is acquired.

[0205] In an optional implementation, the determining subunit is specifically configured to:

[0206] In the function corresponding to the function name at the top of the stack in each of the plurality of acquired call stacks, a function called by the main thread and having a call duration greater than a preset duration is selected.

[0207] According to the selected function, a function causing the freezing phenomenon is determined.

[0208] In an optional implementation, the historical running data of the application program includes: at least one page in the application program, a number of times that the application program has occurred the freezing phenomenon when displaying each of the at least one page in a historical time period is greater than a preset number of times.

[0209] The first determining module includes:

[0210] The second determining unit is configured to determine that the application program is at the time when the freezing phenomenon is expected to occur when the application program displays one of the at least one page.

[0211] In an optional implementation, the historical running data of the application program includes: at least one specific duration, a number of times that the application program has occurred the freezing phenomenon when starting and then being separated by each of the at least one specific duration in a historical time period is greater than a preset number of times.

[0212] The first determining module includes:

[0213] The third determining unit is configured to determine that the application program is at the time when the freezing phenomenon is expected to occur when a current time of the application program reaches one of the at least one specific duration from a start time when the application program is started on the terminal.

[0214] In an optional implementation, the historical running data of the application program includes: at least one specific operation, a number of times that the application program has occurred the freezing phenomenon when receiving each of the at least one specific operation in a historical time period is greater than a preset number of times.

[0215] The first determining module includes:

[0216] The fourth determining unit is configured to determine that the application program is at the time when the freezing phenomenon is expected to occur when the application program receives one of the at least one specific operation.

[0217] In the present application, the time when the application program is expected to have a lag phenomenon is obtained. The time when the lag phenomenon is expected to occur is predicted according to historical running data of the application program. It is determined whether the application program is in the time when the lag phenomenon is expected to occur. In the case where the application program is in the time when the lag phenomenon is expected to occur, it is monitored whether the application program has a lag phenomenon. In the case where the application program has a lag phenomenon, the call stack of the main thread allocated by the terminal for the application program is intermittently obtained for multiple times in sequence, and the call stack at least includes the function name of the function in the application program being called by the main thread. The function causing the lag phenomenon is determined according to the function name in the call stack obtained for multiple times in sequence.

[0218] In one aspect, it is found through statistics that in the case where the application program is in the time when the lag phenomenon is expected to occur, the application program is likely to have a lag phenomenon, and in the case where the application program is not in the time when the lag phenomenon is expected to occur, the application program is not likely to have a lag phenomenon.

[0219] Therefore, in the case where the application program is not in the time when the lag phenomenon is expected to occur, the effectiveness of monitoring whether the application program has a lag phenomenon is low or the significance is low, that is, it is unnecessary to monitor whether the application program has a lag phenomenon in the state where the application program is not likely to have a lag phenomenon, and it can be seen that monitoring whether the application program has a lag phenomenon in the state where the application program is not likely to have a lag phenomenon is often invalid monitoring and often wastes system resources.

[0220] The present application predicts the time when the application program is expected to have a lag phenomenon through historical running data of the application program, and monitors whether the application program has a lag phenomenon in the case where the application program is in the time when the lag phenomenon is expected to occur, and does not monitor whether the application program has a lag phenomenon in the case where the application program is not in the time when the lag phenomenon is expected to occur.

[0221] In the case where the application program is in the time when the lag phenomenon is expected to occur, the effectiveness of monitoring whether the application program has a lag phenomenon is high and the significance is high, that is, it is necessary to monitor whether the application program has a lag phenomenon in the state where the application program is likely to have a lag phenomenon, and it can be seen that monitoring whether the application program has a lag phenomenon in the state where the application program is likely to have a lag phenomenon is often effective detection.

[0222] Therefore, compared with the mode of continuously monitoring whether the application program has a lag phenomenon in the process of running the application program, the present application monitors whether the application program has a lag phenomenon in the case where it is necessary and does not monitor whether the application program has a lag phenomenon in the case where it is unnecessary, so as to avoid invalid detection, avoid wasting too much system resources, and save system resources.

[0223] In another aspect, in the case that the application program has a lag phenomenon, the call stack of the main thread allocated by the terminal for the application program is intermittently acquired for multiple times in succession, the function name at the top of the stack in each call stack corresponds to a function that is being called by the main thread of the application program at the time of acquiring the call stack. Thus, the function being called by the main thread of the application program at the time of acquiring the call stack can be obtained according to the function name at the top of the stack in the call stack, and the acquisition time points at the time of acquiring each call stack are different. Thus, the function causing the lag phenomenon can be accurately determined according to the time interval between the acquisition time points at the time of acquiring the call stack and the function being called by the main thread of the application program at the time of acquiring the call stack, for example, the duration of the continuous calling of at least part of the functions in the acquired multiple call stacks by the main thread can be accurately determined, so that the function causing the lag phenomenon can be accurately determined according to the duration of the continuous calling. Thus, the application can improve the accuracy of determining the function causing the lag phenomenon.

[0224] For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant part can be referred to the part of the method embodiment.

[0225] Optionally, the embodiment of the application further provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program is executed by the processor to realize the processes of the above-mentioned data processing method embodiment, and the same technical effects can be achieved. To avoid repetition, details are not described here.

[0226] The embodiment of the application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, wherein the computer program is executed by the processor to realize the processes of the above-mentioned data processing method embodiment, and the same technical effects can be achieved. To avoid repetition, details are not described here. The computer readable storage medium includes a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0227] Figure 4 is a block diagram of an electronic device 800 shown in the application. For example, the electronic device 800 can be a mobile phone, a computer, a digital broadcast terminal, a message transmission device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0228] Reference Figure 4The electronic device 800 can include one or more of the following components: a processing component 802, a memory 804, a power component 806, a multimedia component 808, an audio component 810, an input / output (I / O) interface 812, a sensor component 814, and a communication component 816.

[0229] The processing component 802 usually controls overall operations of the electronic device 800, such as operations associated with displaying, making phone calls, data communications, camera operations and recording operations. The processing component 802 can include one or more processors 820 to execute instructions to complete all or part of steps of the above methods. In addition, the processing component 802 can include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 can include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0230] The memory 804 is configured to store various types of data to support operations of the electronic device 800. Examples of these data include instructions for any application or method operating on the electronic device 800, contact data, phonebook data, messages, images, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage devices or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0231] The power component 806 provides power to various components of the electronic device 800. The power component 806 can include a power management system, one or more power sources, and other components associated with generating, managing and distributing power for the electronic device 800.

[0232] The multimedia component 808 includes a screen to provide an output interface between the electronic device 800 and a user. In some embodiments, the screen can include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense a touch, a slide, and a gesture on the touch panel. The touch sensor can not only sense a boundary of a touching or a sliding action, but also detect duration and pressure related to the touching or sliding action. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. The front camera and / or the rear camera can receive external multimedia data when the electronic device 800 is in an operation mode, such as a photographing mode or a video mode. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zooming capability.

[0233] The audio component 810 is configured to output and / or input an audio signal. For example, the audio component 810 includes a microphone (MIC) to receive an external audio signal when the electronic device 800 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, the audio component 810 further includes a speaker to output an audio signal.

[0234] The I / O interface 812 provides an interface for the processing component 802 and peripheral interface modules, such as a keypad, a click wheel, buttons, and the like. The buttons can include, but are not limited to, a home button, a volume button, a start button, and a lock button.

[0235] The sensor component 814 includes one or more sensors to provide various state assessments for the electronic device 800. For example, the sensor component 814 can detect an open / closed position of the device 800, relative positioning of components, such as a display and a keypad of the electronic device 800, a change in position of the electronic device 800 or a component of the electronic device 800, the presence or absence of user contact with the electronic device 800, the orientation or acceleration / deceleration of the electronic device 800, and a temperature change of the electronic device 800. The sensor component 814 can include a proximity sensor configured to detect the presence of a nearby object without any physical touch. The sensor component 814 can further include a light sensor such as a CMOS or CCD image sensor for use in an imaging application. In some embodiments, the sensor component 814 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0236] The communication component 816 is configured to facilitate wired or wireless communication between the electronic device 800 and other devices. The electronic device 800 can access a wireless network based on a communication standard, such as WiFi, a cellular network standard (such as 2G, 3G, 4G, or 5G), or a combination thereof. In an example embodiment, the communication component 816 receives broadcast signals or broadcast operation information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component 816 can further include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) techniques, infrared data association (IrDA) techniques, ultra-wideband (UWB) techniques, Bluetooth (BT) techniques, and other techniques.

[0237] In an example embodiment, the electronic device 800 can be implemented using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic elements, for performing the above-described methods.

[0238] In an example embodiment, a non-transitory computer-readable storage medium including instructions, such as the memory 804 including instructions, is also provided, which can be executed by the processor 820 of the electronic device 800 to complete the above-described methods. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disc, and an optical data storage device, etc.

[0239] Figure 5 is a block diagram of an electronic device 1900 shown in the present application. For example, the electronic device 1900 can be provided as a server.

[0240] Referring to Figure 5 The electronic device 1900 includes a processing component 1922, which further includes one or more processors, and memory resources represented by a memory 1932, for storing instructions executable by the processing component 1922, such as an application program. The application program stored in the memory 1932 can include one or more modules each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the above-described methods.

[0241] The electronic device 1900 can further include a power supply component 1926 configured to perform power management of the electronic device 1900, a wired or wireless network interface 1950 configured to connect the electronic device 1900 to a network, and an input / output (I / O) interface 1958. The electronic device 1900 can operate based on an operating system stored in the memory 1932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or the like.

[0242] It should be noted that the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0243] Those skilled in the art can clearly understand the above-mentioned embodiment method can be realized by means of software and necessary general hardware platform, of course, can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes a plurality of instructions for causing a terminal (which can be a mobile phone, computer, server, air conditioner, or network device) to execute the method described in each embodiment of the present application.

[0244] The embodiments of the present application are described above with reference to the accompanying drawings, but the present application is not limited to the specific embodiments described above, which are merely illustrative rather than restrictive, and a person of ordinary skill in the art can make many forms without departing from the purpose of the present application and the scope protected by the claims.

[0245] Those skilled in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in the embodiments of the present application can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solutions. A person skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0246] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0247] In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented by other manners. For example, the apparatus embodiments described above are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0248] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0249] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0250] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the part of the present application that essentially contributes to the prior art or the part of the technical solutions can be embodied in the form of software products. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk and various program code storage media.

[0251] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A data processing method, characterized in that: Applied to a terminal, where an application is running, the method includes: Obtaining a time when the application is expected to experience a jamming phenomenon during operation; the expected time when the jamming phenomenon is expected to occur is predicted based on historical operation data of the application; the historical operation data of the application includes: at least one page in the application, and the number of times the application has experienced a jamming phenomenon when displaying each of the at least one page in a historical time period is greater than a preset number; or, at least one specific time length, and the number of times the application has experienced a jamming phenomenon at intervals of at least one specific time length after being started in the historical time period is greater than a preset number; or, at least one specific operation, and the number of times the application has experienced a jamming phenomenon when receiving each of the at least one specific operation during operation of the application in the historical time period is greater than a preset number; Determining whether the application is at a time when a freeze phenomenon is expected to occur, comprising: when the application displays one of the at least one page, when the application receives one of the at least one specific operation, or when the application receives one of the at least one specific operation, determining that the application is at a time when a freeze phenomenon is expected to occur; When the application is at a time when a freeze is expected to occur, monitoring whether the application has experienced a freeze; When the application freezes, intermittently and repeatedly obtains a call stack of a main thread allocated by the terminal to the application, the call stack including function names of functions in the application being called by the main thread; The function causing the jamming phenomenon is determined at least according to the function names in the call stacks obtained multiple times in a sequential order.

2. The method according to claim 1, characterized in that The determining of the function causing the jamming phenomenon based on at least the function names in the call stacks obtained multiple times in a sequential order includes: Get the function name at the top of each call stack obtained multiple times; The function causing the jamming phenomenon is determined at least according to the function name at the top of each call stack obtained multiple times.

3. The method according to claim 2, characterized in that The determining of the function causing the jamming phenomenon based on at least the function name at the top of each call stack obtained multiple times includes: Count the duration of each function called by the main thread, corresponding to the function name at the top of each call stack obtained multiple times; The function causing the jamming phenomenon is determined according to the continuous calling time of the function corresponding to the function name at the top of each call stack obtained multiple times being called by the main thread.

4. The method according to claim 3, characterized in that The statistics of the duration of continuous calling of the function corresponding to the function name at the top of each call stack obtained multiple times by the main thread include: Dividing the call stacks obtained multiple times in a sequential order into at least one call stack group according to the sequential order; the function names at the top of the stacks in the call stacks in the same call stack group are the same, and the function names at the top of the stacks in the call stacks in different call stack groups are different; For any one call stack group in at least one call stack group, obtaining, based on a time interval between a time instant when a call stack that is last in the call stack group is obtained and a time instant when a call stack that is first in the call stack group is obtained, a continuous call duration of a function corresponding to a function name at the top of a call stack in the call stack group being called by the main thread; or, For any one call stack group in at least one call stack group, based on the time interval between the time instant when the first call stack in the subsequent call stack group adjacent to the call stack group is acquired and the time instant when the first call stack in the call stack group is acquired, Obtain the duration of a continuous call of a function corresponding to a function name at the top of a call stack in the call stack group by a main thread.

5. The method according to claim 3, characterized in that The determining of the function causing the jamming phenomenon according to the duration of continuous calling of the function corresponding to the function name at the top of each call stack obtained multiple times by the main thread includes: Select, from among the functions corresponding to the function names at the top of each call stack obtained multiple times, a function called by the main thread whose continuous calling time is greater than a preset time; According to the selected function, the function causing the jamming phenomenon is determined.

6. A data processing device, characterized in that: Applied to a terminal, where an application is running, the device comprises: The first acquisition module is used to obtain the time when the application is expected to experience a jamming phenomenon during operation; the expected time when the jamming phenomenon occurs is predicted based on the historical operation data of the application; the historical operation data of the application includes: at least one page in the application, the number of times the application has experienced a jamming phenomenon when displaying each of the at least one page in a historical time period is greater than a preset number; or, at least one specific time length, the number of times the application has experienced a jamming phenomenon at intervals of at least one specific time length after being started in the historical time period is greater than a preset number; or, at least one specific operation, the number of times the application has experienced a jamming phenomenon when receiving each of the at least one specific operation during operation in the historical time period is greater than a preset number; a first determining module for determining whether the application is at a time when a jamming phenomenon is expected to occur; the first determining module includes: a second determining unit for determining, when the application displays one of the at least one page, that the application is at a time when a jamming phenomenon is expected to occur; a third determining unit for determining, when the current time of the application is one of the at least one specific time periods from the start time of the application on the terminal; and a fourth determining unit for determining, when the application receives one of the at least one specific operation, that the application is at a time when a jamming phenomenon is expected to occur; A monitoring module, configured to monitor whether a freeze occurs in the application program when the application program is at a time when a freeze is expected to occur; a second acquisition module, configured to intermittently and repeatedly acquire a call stack of a main thread allocated by the terminal to the application when a freeze occurs in the application, the call stack including function names of functions in the application being called by the main thread; The second determining module is used to determine the function that causes the jamming phenomenon based on at least the function names in the call stacks with a chronological order obtained multiple times.

7. The device according to claim 6, characterized in that The second determining module includes: An acquisition unit, used to acquire the function name at the top of each call stack acquired multiple times; The first determining unit is configured to determine the function causing the jamming phenomenon based on at least the function name at the top of each call stack obtained multiple times.

8. The device according to claim 7, characterized in that The first determining unit includes: The statistics sub-unit is used to count the duration of the function corresponding to the function name at the top of each call stack obtained multiple times being called by the main thread; The determination subunit is used to determine the function that causes the jamming phenomenon based on the continuous call duration of the function corresponding to the function name at the top of each call stack obtained multiple times being called by the main thread.

9. The device according to claim 8, characterized in that The statistics subunit is specifically used for: Dividing the call stacks obtained multiple times in a sequential order into at least one call stack group according to the sequential order; the function names at the top of the stacks in the call stacks in the same call stack group are the same, and the function names at the top of the stacks in the call stacks in different call stack groups are different; For any one call stack group in at least one call stack group, obtaining, based on a time interval between a time instant when a call stack that is last in the call stack group is obtained and a time instant when a call stack that is first in the call stack group is obtained, a continuous call duration of a function corresponding to a function name at the top of a call stack in the call stack group being called by the main thread; or, For any one call stack group in at least one call stack group, based on the time interval between the acquisition time of the call stack that is first in the sequence of priority in the later call stack group adjacent to the call stack group and the acquisition time of the call stack that is first in the sequence of priority in the call stack group, obtain the continuous call duration of the function corresponding to the function name at the top of the call stack in the call stack group being called by the main thread.

10. The device according to claim 8, characterized in that The determining subunit is specifically configured to: Select, from among the functions corresponding to the function names at the top of each call stack obtained multiple times, a function called by the main thread whose continuous calling time is greater than a preset time; According to the selected function, the function causing the jamming phenomenon is determined.

11. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the data processing method according to any one of claims 1 to 5.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the data processing method according to any one of claims 1 to 5.

Images