CN117692998A

CN117692998A - Data acquisition method under abnormal dormancy condition and electronic equipment

Info

Publication number: CN117692998A
Application number: CN202310934649.XA
Authority: CN
Inventors: 谢瑜
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-07-27
Filing date: 2023-07-27
Publication date: 2024-03-12

Abstract

The application provides a data acquisition method under a sleep abnormality condition and electronic equipment. The electronic equipment such as the mobile phone and the like provided with the DSP can detect whether the DSP has abnormal situations of no dormancy or not. When detecting that the DSP is not dormant, the electronic equipment can acquire information such as algorithm related information, DSP field information, DSP logs and the like when the DSP is not dormant and send the information to a server for analysis and use by a developer, so that the developer is helped to quickly determine the reason causing the non-dormancy of the DSP, and further a solution is determined as soon as possible. Wherein the electronic device can determine whether the DSP is dormant by timing a dormancy timer of the DSP. At the same time, the problem of whether the DSP should sleep without sleep (i.e., not sleep) is determined in conjunction with the target application being inactive.

Description

Data acquisition method under abnormal dormancy condition and electronic equipment

Technical Field

The present disclosure relates to the field of terminals, and in particular, to a method for acquiring data under a sleep abnormality condition and an electronic device.

Background

Digital signal processors (digital signal processor, DSP) are used to handle computationally intensive tasks such as model reasoning, image enhancement, video stream processing, and the like. After one computing task of the DSP is finished and when no other computing task is available, the DSP performs a sleep state according to a sleep policy. However, as more and more algorithms are run on the DSP, the DSP has a gradually complex working scenario, and the DSP is often not dormant when the DSP should be dormant, i.e. a problem of non-dormancy occurs, which results in increased power consumption of the device and affects the cruising ability of the device.

Disclosure of Invention

The application provides a data acquisition method under a sleep abnormality condition and electronic equipment.

The electronic equipment such as the mobile phone and the like provided with the DSP can detect whether the DSP has abnormal situations of no dormancy or not. When detecting that the DSP is not dormant, the electronic equipment can acquire information such as algorithm related information, DSP field information, DSP logs and the like when the DSP is not dormant and send the information to a server for analysis and use by a developer, so that the developer is helped to quickly determine the reason causing the non-dormancy of the DSP, and further a solution is determined as soon as possible.

In a first aspect, the present application provides a data acquisition method. The method is applicable to an electronic device comprising a DSP. The method comprises the following steps: running a first number of algorithms on the DSP; when any algorithm starts to run, recording related information of the algorithm, wherein the related information at least comprises an algorithm name of the algorithm; stopping running the second number of algorithms; deleting the related information of a second number of algorithms, wherein the second number is smaller than or equal to the first number; detecting that the DSP is not dormant, and sending related information of a third number of algorithms remained currently to a server; non-sleep of a DSP means that the DSP should sleep without being dormant; wherein, when the target application corresponding to the first number of algorithms is not active, the DSP should sleep; the target application being inactive includes that the target application is running without any algorithms being executed by the DSP.

By implementing the method provided in the first aspect, the electronic device may, when each algorithm is running on the DSP, based on the related information of the algorithm, and delete the related information of the algorithm after stopping running. Meanwhile, the electronic device can determine whether the target application is active or not by identifying that the target application is not required to run by executing any algorithm by the DSP, and further determine whether the DSP is not dormant when the DSP should be dormant, i.e. the DSP is not dormant. After detecting that the DSP is not dormant, the electronic device may trigger a sleep exception report, and send relevant information of the currently-retained algorithm to the server.

When the target application is not active, the registered algorithms should be logged out successively, and accordingly, the related information of the algorithms should be deleted. Therefore, the research and development personnel can conveniently and efficiently determine the possible algorithm causing the non-dormancy of the DSP according to the related information of the retained algorithm when the DSP is not dormant.

In combination with the method provided in the first aspect, in some embodiments, the related information further includes one or more of: calculating the power level, voting frequency points and registration time.

The information such as the calculation power level, the voting frequency point, the registration time and the like are important parameters for running various algorithms by the DSP. Based on the above information, the developer more accurately and efficiently determines the reason for the non-dormancy of the DSP from the level of the running algorithm.

In combination with the method provided in the first aspect, in some embodiments, after detecting that the DSP is not dormant, the method further comprises: the field information of the current DSP is sent to the server and/or the log of the current DSP is sent to the server.

The on-site information of the DSP and the log of the DSP can further reflect the working state of the DSP when the DSP is not dormant, thereby further helping research personnel determine the reason for causing the DSP not to be dormant.

In some embodiments, in combination with the method provided in the first aspect, after detecting that the DSP is not dormant, before sending the relevant information of the currently remaining third number of algorithms to the server, the method further includes: and confirming that the duration of the non-dormancy of the DSP reaches a preset value.

By implementing the method provided by the embodiment, before the duration of the non-sleep time of the DSP reaches the preset duration, the electronic device may not trigger the sleep exception report. And after the duration of the non-dormancy of the DSP is longer than the preset duration, the electronic equipment triggers the dormancy exception report. Therefore, the method can shield the relatively unimportant short-time non-dormancy problem, help research personnel focus on the long-time non-dormancy of the DSP, and preferentially determine the reason of the long-time non-dormancy problem of the DSP, thereby preferentially solving the long-time non-dormancy problem of the DSP.

In combination with the method provided in the first aspect, in some embodiments, detecting that the DSP is not dormant specifically includes: detecting that the target application is not active and the timing of the sleep timer of the DSP acquired twice before and after is the same; the dormancy timer starts timing after the DSP enters dormancy, and stops timing after the dormancy is finished.

By implementing the method provided by the embodiment, the electronic device can determine whether the sleep timer is running or not through the timing of the sleep timer of the DSP, so as to determine whether the DSP is dormant or not. At the same time, the problem of whether the DSP should sleep without sleep (i.e., not sleep) is determined in conjunction with the target application being inactive.

In combination with the method provided in the first aspect, in some embodiments, the confirming that the duration of the DSP not being dormant reaches a preset value specifically includes: continuing to acquire the timing of the dormancy timer for N times; n is more than or equal to 1; when any one of the acquired N timings is the same as the timing of the sleep timer of the DSP acquired twice before and after, determining that the duration of the non-sleep time of the DSP reaches a preset value. N=m-1. Where M is the count threshold of the non-sleep counter.

With the method provided in connection with the first aspect, in some embodiments, the first number of algorithms includes an image processing algorithm; the target application is run without using the DSP to perform any algorithm including the target application turning off the camera.

In one embodiment, the DSP is required to run multiple image processing algorithms when the target application invokes the camera. The DSP is now occupied. When the target application turns off the camera, the target application no longer needs to perform the various image processing algorithms described above using the DSP. At this point, the DSP should go to sleep.

In some embodiments, the target application includes one or more of a camera application, an instant messaging application, a motion sensing game application, and a method provided in connection with the first aspect.

The target application may also be a video editing application. When the target application performs the video editing task, the DSP is required to run a variety of image processing algorithms. The DSP is now occupied. When the target should stop the video editing task, the target application no longer needs to perform the various image processing algorithms described above using the DSP. At this point, the DSP should go to sleep. Thus, in another embodiment, the target application is run without performing any algorithms with the DSP and includes the target application not performing video editing tasks.

In some embodiments, the electronic device includes a hardware abstraction layer, HAL, comprising a detection thread and a reporting module; detecting that the DSP is not dormant, and sending relevant information of the rest third number of algorithms to a server, wherein the relevant information specifically comprises the following steps: the detection thread detects that the DSP is not dormant; the reporting module sends information about the remaining third number of algorithms to the server.

By implementing the method provided by the embodiment, the detection thread can independently detect whether the DSP has a non-dormancy problem in real time.

In combination with the method provided in the first aspect, in some embodiments, the HAL further includes a status registration module, recording information about the algorithm, including: the state registration module creates a state registry; the state registration module records the related information of the algorithm in a state registration table; deleting the related information of the second number of algorithms, specifically including: the state registration module deletes the related information of the second number of algorithms from the state registration table, and the related information of the third number of algorithms remains.

In a second aspect, the present application provides an electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories being for storing a computer program which, when executed by the one or more processors, causes the electronic device to perform the method as described in the first aspect and any possible implementation of the first aspect.

In a third aspect, embodiments of the present application provide a chip system for application to an electronic device, the chip system comprising one or more processors for invoking a computer program to cause the electronic device to perform a method as described in the first aspect and any one of the possible implementations of the first aspect.

In a fourth aspect, the present application provides a computer readable storage medium comprising a computer program which, when run on an electronic device, causes the electronic device to perform a method as described in the first aspect and any one of the possible implementations of the first aspect.

In a fifth aspect, the present application provides a computer program product comprising instructions which, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect and any possible implementation of the first aspect.

It will be appreciated that the electronic device provided in the second aspect, the chip system provided in the third aspect, the computer storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect are all configured to perform the method provided in the present application. Therefore, the advantages achieved by the method can be referred to as the advantages of the corresponding method, and will not be described herein.

Drawings

Fig. 1 is a system architecture diagram of an Android-based electronic device 100 provided in an embodiment of the present application;

FIG. 2 is a flowchart of a method for detecting whether a DSP has a non-sleep problem by a detection thread according to an embodiment of the present application;

FIG. 3 is a schematic diagram of detecting threads in a DSP normal sleep scenario according to an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of detecting threads in a non-sleep scenario of a DSP according to an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of detecting threads in a non-sleep scenario of another DSP according to an embodiment of the present application;

fig. 6 shows a schematic structural diagram of the electronic device 100.

Detailed Description

The terminology used in the following embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

After one computing task of the DSP is finished and when no other computing task is available, the DSP sleeps according to a sleep policy. However, as the number of algorithms running on the DSP increases, the working scenario of the DSP becomes more and more complex, and the DSP often does not sleep when it should sleep, i.e. a problem of not sleeping occurs, which results in an increase in power consumption of the device and affects the cruising ability of the device.

Before solving the problem of DSP non-dormancy, first, the developer needs to determine the reason for inducing DSP non-dormancy in a complex DSP working scenario. However, the problem of non-dormancy is often characterized by low probability, difficulty in reproduction, and significant hysteresis. Therefore, the subsequent analysis method based on the complete storage mechanism (full dump) has the problems of great difficulty and high cost.

In view of this, the embodiment of the present application provides a data acquisition method for acquiring relevant data when a non-sleep problem occurs, so as to help a developer to quickly determine a reason for non-sleep of a DSP.

In implementing the above method, the electronic device 100 configured with the DSP, such as a mobile phone, a tablet computer, etc., may create a state registry. The electronic device 100 may register the related information of each algorithm in the above state registry before the algorithm is run on the DSP, and delete the related information of the algorithm after stopping the operation of the algorithm. The related information includes, but is not limited to, algorithm name, calculation power level, voting frequency point, registration time. The information about any algorithm registered in the state registry is also referred to as registration information for that algorithm. In addition, the electronic device 100 may create a detection thread for detecting whether the DSP is experiencing a non-sleep problem. When the problem of non-dormancy occurs, the electronic device 100 may save the state registry, the on-site data of the DSP, and the DSP log, and upload the saved data to the cloud for the developer to analyze and use, thereby helping the developer to quickly determine the reason of non-dormancy of the DSP and determine the solution of the problem of non-dormancy of the DSP.

The detection thread can periodically acquire the working state of the target application. When the target application is in an inactive state without occupying the DSP, the detection thread can acquire the timing of the sleep timer of the DSP, and determine whether the DSP is in sleep or not according to whether the acquired timing is consistent or not, so as to determine whether the DSP is not in sleep or not. When the target application is in an inactive state and the timings of the sleep timers acquired before and after are consistent, the detection thread can determine that the DSP has a problem of non-sleep.

In one embodiment, upon detection of a non-sleep problem, the electronic device 100 may immediately save and upload the state registry, the DSP's field data, and DSP logs.

In another embodiment, the electronic device may further set a non-sleep counter for recording a duration for which the non-sleep problem persists. When the time that the DSP is in the non-sleep state exceeds the preset value, the electronic device 100 may save and upload the state registry, the field data of the DSP, and the DSP log. Therefore, the research and development personnel can focus on the scene that the DSP does not sleep for a long time, and help the research and development personnel to determine the reason that the DSP does not sleep more quickly.

Not limited to cell phones, tablet computers, electronic device 100 may also be desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPC), netbooks, as well as cellular telephones, personal digital assistants (personal digital assistant, PDA), augmented reality (augmented reality, AR) devices, virtual Reality (VR) devices, artificial intelligence (artificial intelligence, AI) devices, wearable devices, vehicle devices, smart home devices, and/or smart city devices configured with a DSP, the specific types of electronic device 100 are not limited by the embodiments of the present application.

Fig. 1 is a system architecture diagram of an Android-based electronic device 100 according to an embodiment of the present application.

The android architecture is a hierarchical architecture. The layered architecture divides the system into several layers. The layers communicate via interfaces. The layered architecture of android may include five layers, from top to bottom, an application layer, a framework layer, a hardware abstraction layer, a driver layer, and a hardware layer, respectively. Fig. 1 only shows an application layer, a hardware abstraction layer and a hardware layer, and does not embody a framework layer and a driving layer.

The application layer may comprise a series of applications. In the embodiment of the application, the application layer at least comprises a camera application.

The camera application may include a number of algorithms that need to run on the DSP, such as algorithm 01, algorithm 02, algorithm 03, etc. By way of example, the above-described algorithms are typically computationally intensive algorithms for processing images, such as white balance algorithms, color correction algorithms, defocus blur algorithms, background blurring algorithms, portrait beauty algorithms, and various filter algorithms, among others.

The application layer includes other application programs that need to occupy the DSP during the running process, especially application programs that need to call the camera to provide shooting services for the user, such as WeChat, tremble, etc. These applications also include a number of algorithms that need to run on the DSP. Applications that need to occupy a DSP at runtime may be referred to as target applications, and algorithms in the target applications that need to run on the DSP may be referred to as DSP algorithms.

The hardware abstraction layer provides a virtual hardware platform for the operating system. In the embodiment of the application, the hardware abstraction layer at least comprises a state registration module, a dimension measurement system, a report module and a DSP system.

The DSP system is a virtual hardware platform of a hardware layer DSP chip. The DSP system runs each DSP algorithm through the support provided by the DSP chip.

The status registration module includes a status registry. After the target application is started, the state registration module may create a state registry. When the DSP starts to run any one DSP algorithm, the state registration module may record relevant information of the algorithm in the state registry, such as an algorithm name, a calculation power level (indicating algorithm complexity, which may be represented by algorithm time consumption), a voting frequency point (indicating a frequency at which the DSP runs the algorithm, e.g., 1/30 of the voting frequency point of the algorithm if executed per frame in a video stream of 30 FPS), a registration time (time when the DSP starts to run the algorithm), and the like. The information about any algorithm registered in the state registry is also referred to as registration information for that algorithm. After stopping the algorithm, the state registration module may delete registration information for the algorithm from the state registry. The above-mentioned stopping means that the algorithm is run out and the algorithm is not needed for a certain period of time later. For example, after exiting portrait mode, the background blurring algorithm may be stopped.

The dimension measurement system includes a detection thread. After the target application is started, the metering system may create and initialize a detection thread. The dimension test system can then detect whether the DSP is experiencing a non-sleep problem by detecting threads. The non-sleep state of the DSP is a sleep exception state of the DSP, specifically, it means that the DSP should sleep without sleep when there is no computational task. The following embodiments will specifically describe a method for detecting whether a thread detects that a DSP has a problem of not being dormant, and will not be developed here.

After detecting that the DSP has the problem of non-dormancy, the dimension measurement system can send dormancy abnormality indication to the DSP system to trigger the DSP system to perform local transfer storage (also called miniump), and transfer the effective information such as the current memory information, register information and the like of the DSP into a file to be stored, namely, the on-site information of the DSP is stored.

Meanwhile, the maintenance system can send a sleep abnormality indication to the reporting module to indicate that the DSP has a non-sleep problem, and trigger the reporting module to report the sleep abnormality to the cloud. Wherein, in response to the sleep anomaly indication, the reporting module may obtain DSP field information and DSP logs from the DSP system, while the reporting module may also obtain a status registry from the status registration module. And then, reporting the dormancy abnormality to the cloud by the reporting module, and sending the DSP field information, the DSP log and the state registry to the cloud for storage so as to enable the research and development personnel to analyze and find the reason for causing the DSP not to dormancy later.

Taking a camera application as an example, the camera application comprises a DSP algorithm such as algorithm 01, algorithm 02, algorithm 03 and the like. After the camera application is started, the algorithm 01, the algorithm 02 and the algorithm 03 can be loaded on the DSP and run on the DSP successively. At this time, the state registry in the state registration module may be as shown in table 1:

TABLE 1

For example, at some point, the camera application may turn off the camera, switch to background run (standby) or shut down (shutdown). At this time, since the camera is turned off, the camera application no longer needs to process the image reported by the camera, and therefore, the camera application does not need to run various DSP algorithms. Thus, the camera application may stop each DSP algorithm running on the DSP. After a successful stop, the DSP algorithm will de-register at the state registration module, i.e. the registration information for the algorithm in the state registry will be deleted.

However, for various reasons, the camera application may fail to stop one or more DSP algorithms. At this time, the registration information of the unsuccessfully stopped algorithm is retained in the state registry. Illustratively, the camera application may successfully stop the DSP algorithm, e.g., algorithm 01, but fail to stop algorithm 02, algorithm 03. Thus, referring to table 2, the state registry will hold the registration information of algorithm 02, algorithm 03:

TABLE 2

At this point, the detection thread may confirm that the DSP is detected not to sleep based on the camera application running in the background or shutting down while the DSP is not sleeping (e.g., still running one or more DSP algorithms that were not successfully stopped as described above, or other computing work). Thus, the reporting module may report the DSP sleep anomaly to the cloud and send the state registry shown in table 2, the current DSP field information, and the DSP log to the cloud. The developer can then analyze and determine the reason for the DSP not to sleep based on the information.

Algorithm 01 has been successfully stopped when the camera application is running in the background or is turned off. This indicates that the DSP is not dormant, at least not caused by algorithm 01. Correspondingly, as shown in table 2, at this time, the registration information of algorithm 01 that has been successfully stopped is not included in the state registry. This also avoids the developer from further analyzing whether algorithm 01 induces DSP to go non-dormant, which is beneficial to help the developer to quickly determine the reason for DSP non-dormancy and determine the solution of DSP non-dormancy problem.

In the implementation scenarios shown in tables 1 and 2: the camera application may be referred to as a target application; when the camera application stops calling the camera to switch to background operation or closing, the camera application is not active; the algorithms shown in table 1 as algorithm 01, algorithm 02, algorithm 03, etc. may be referred to as a first number of algorithms, the DSP algorithm of algorithm 01, etc. stopped may be referred to as a second number of algorithms, and the remaining algorithms 02, 03 may be referred to as a third number of algorithms.

Fig. 2 is a flowchart of a method for detecting whether a DSP has a non-sleep problem by a detection thread according to an embodiment of the present application.

S101, initializing a detection thread.

The DSP system includes a sleep timer (SlpTimer). After the DSP enters a dormant state, the SlpTimer is started and begins to time; after the DSP wakes up, the SlpTimer stops timing. In the process of starting and timing the SlpTimer, the timing of the SlpTimer corresponds to the current system time of the electronic device 100 at any time; after the SlpTimer stops counting, the counting of the SlpTimer, that is, the time at which the SlpTimer stops counting, is at any time.

Illustratively, the SlpTimer is turned on and begins to count at 00:00 and stops counting at 00:25. The timing of any time of the SlpTimer corresponds to the system time of the electronic device 100 at that time in the time range of 00:00 to 00:25. For example, the SlpTimer has a timing of 00:09, at which time the system time of the electronic device 100 is 00:09. After 00:25, the timing of the SlpTimer may be kept at 00:25 before the SlpTimer is turned on again. During this period, the time of the SlpTimer, i.e., the stop time of the SlpTimer, is 00:25. Illustratively, the SlpTimer may be turned on again at system time 01:00. At this time, the timer of the SlpTimer is updated from 00:25 to 01:00, and the time is updated in real time along with the system time until the SlpTimer is turned off again and the timer is stopped.

After the instrumentation system creates the instrumentation thread, the instrumentation thread may be initialized. The detection thread includes the last sleep time parameter, denoted LastSlpTime. LastSlpTime is used to record the timing of the SlpTimer last acquired by the detection thread. Upon initialization, the detection thread may set the value of LastSlpTime to 0, i.e., lastslptime=0.

The detection thread is also provided with a non-sleep counter (non-slpcounter) for recording the duration of the DSP non-sleep persistence. The value of the NonSlpCounter count is incremented by 1 after each detection that the DSP is not dormant. Upon initialization, the detection thread may also set the value of noslpcount to 0, i.e., noslpcount=0.

S102, acquiring a system state, and determining whether the target application is active.

The system state may be used to indicate the operational state of the electronic device 100: work/sleep. In a scenario in which the electronic device 100 is operating, the system status may further indicate the operating status of each application on the electronic device 100: active/inactive. The detection thread may then determine whether the target application is active through the system state described above. Wherein, in the embodiment of the present application, the working state of the target application running DSP algorithm (i.e. occupying DSP) may be referred to as active state; the operating state in which the target application is not running DSP algorithms (i.e., not occupying the DSP) may be referred to as an inactive state.

When the camera is turned on, a DSP algorithm (e.g., white balance algorithm, color correction algorithm, etc.) for image preprocessing necessarily occupies DSP operation. Thus, in one implementation, the operational status (active/inactive) of the target application may be determined based on whether the target application turns on the camera.

Taking the camera application as an example, the camera is turned on when the camera application is running in the foreground. At this point, the camera application is in an active state. When the camera application is switched to background operation, the camera is closed. At this time, the camera application is in an inactive state or a dormant state. Taking instant messaging applications such as WeChat to support video call as an example, when video call is started, the camera is started. At this time, instant messaging applications such as WeChat are in an active state. After the video call is ended, the camera is closed. At this time, instant messaging applications such as WeChat are in an inactive state. Furthermore, when the instant messaging applications such as WeChat are operated in the background, the instant messaging applications such as WeChat are also in an inactive state.

The target application also includes motion type application based on motion sense recognition, game type application, and the like, not limited to camera application, weChat, and the like. The embodiments of the present application are not limited in this regard.

The target application may also be a video editing application. After the video editing application is started and enters any video editing task, the video editing application needs to execute various image processing algorithms by using the DSP. At this time, the video editing application needs to occupy the DSP, and the video editing application is active; otherwise, after all video editing tasks are exited, the video editing application does not need to occupy the DSP, and the video editing application is not active. Thus, in other implementations, whether the target application is active may also be determined based on whether the target application performs the video editing task.

The detection thread may periodically acquire the system state, thereby periodically detecting whether the target application is active.

S103, when the target application is not active, acquiring the timing of the SlpTimer, and determining whether the timing TS1 of the currently acquired SlpTimer is consistent with the timing TS0 of the SlpTimer acquired last time.

When the number of target applications is 1, the one target application inactivity equals the target application inactivity. When the target application includes a plurality of target applications, all of the target applications are inactive equal to the target application being inactive.

At the beginning of a period, the detection thread may determine that the target application is not active based on the acquired system state, S102. At this time, the detection thread may acquire the timing of the SlpTimer from the DSP system, denoted as Ts1.

LastSlpTime is used to record the timing of the SlpTimer last acquired by the detection thread. After the obtained timing Ts1 of the SlpTimer, the detection thread can obtain the timing Ts0 of the last SlpTimer by reading LastSlpTime. Wherein, when the detection thread is first executed after creating the detection thread S102, the last time the detection thread obtains by reading LastSlpTime is clocked with an initial value of LastSlpTime, for example 0.

The timing (Ts 1, ts 0) of the SlpTimer obtained twice successively is consistent, meaning that the SlpTimer is not started, i.e. the DSP is not dormant; otherwise, the inconsistency means that the SlpTimer is turned on and the DSP has entered a sleep state. In a scenario where the target application is inactive, the DSP is not dormant, meaning that the DSP has a sleep anomaly problem, i.e., a non-sleep problem, that should sleep without being dormant.

Thus, after acquisition of Ts1, ts0, the detection thread may compare whether these Ts1, ts0 are consistent, thereby determining whether the DSP is experiencing a non-sleep problem.

S104, when the Ts1 and the Ts0 are consistent, the count of a non-dormancy counter (NonSlpCounter) is increased, and whether the count value of the NonSlpCounter is larger than or equal to a threshold value is determined.

The timing Ts1 and TS0 of the SlpTimer obtained twice successively are consistent, which means that the SlpTimer is not started, i.e. the DSP is not dormant. At this point, the detection thread may acknowledge detection that the DSP is not dormant.

Considering that some DSP processing is delayed, when the target application just exits the active state, the DSP may be in a state where there is still data to process, and will not enter the sleep state. In view of this, the detection thread may set a NonSlpCounter and set a count threshold for the NonSlpCounter to detect whether the DSP has not entered the sleep state after a period of time for which the target application exits the active state, i.e., has not entered the sleep state for a long period of time.

Thus, after detecting that the DSP is not dormant, the detection thread may first increment the NonSlpCounter count, indicating that the DSP is detected not dormant once. After incrementing the NonSlpCounter count, the detection thread may compare the NonSlpCounter count value to a threshold value to determine whether the current NonSlpCounter count value is greater than or equal to the threshold value, i.e., to determine whether the DSP is not dormant for a long period of time.

The above threshold may be set empirically. In particular, the above threshold value should be set in consideration of the influence of the period in which the detecting thread acquires the system state on the time range indicated by the non slpcounter count, and also in consideration of the period in which the detecting thread acquires the system state. For example, when the period in which the detecting thread acquires the system state is long, the count threshold of the noslpcount may be set smaller. When the period in which the detection thread acquires the system state is short, the count threshold of the non slpcounter may be set larger.

S105, triggering sleep exception reporting when the count value of the NonSlpCounter is larger than or equal to a threshold value.

A value of the non slpcounter count equal to or greater than the threshold value means that the DSP has not entered sleep state for a long time. At this point, the detection thread may trigger a sleep exception report.

With reference to fig. 1, the dimension measurement system may send a sleep exception indication to the DSP system, trigger the DSP system to perform miniump, and save field information, to obtain DSP field information. At the same time, the dimension measurement system may send a sleep anomaly indication to the reporting module. In response to the sleep abnormality indication, the reporting module may acquire DSP field information, a DSP log, and a status registry, and then the reporting module may report the sleep abnormality to the cloud, and send the DSP field information, the DSP log, and the status registry to the cloud together for storage.

And S106, continuing to detect when the count value of the NonSlpCounter is less than the threshold value.

A value of the non slpcounter count less than the threshold value means that the DSP is not in a non-sleep state for a long period of time. At this time, the detection thread may continue to detect until the count value of the NonSlpCounter is less than or equal to the threshold value, triggering the sleep exception report. Specifically, when the next cycle arrives, the detection thread may again acquire the system state to determine whether the target application is active, again acquire the timing of the SlpTimer, again determine whether the timings of the two slptimers are identical, and so on.

S107, when the TS1 is inconsistent with the TS0, the count value of the NonSlpCounter is cleared, the timing TS1 of the currently acquired SlpTimer is assigned to LastSlpTime, the LastSlpTime is updated, and then detection is continued.

The inconsistency of Ts1 and Ts2 means that the SlpTimer is turned on, i.e. the DSP has entered a sleep state. This indicates that no non-sleep problem has occurred for the DSP.

At this time, the detection thread may assign a timing Ts1 of the latest acquired SlpTimer to LastSlpTime for updating LastSlpTime. Thus, when the next execution of S103 is performed, the detection thread may acquire the timing Ts1 of the last SlpTimer through LastSlpTime, and further compare the timing Ts2 of the last SlpTimer acquired with the timing Ts1 of the last SlpTimer to determine whether the SlpTimer is on and whether the DSP is dormant.

Meanwhile, the detection thread may clear the count value of the NonSlpCounter. In the case that the count value of the non-slpcounter is not 0 and is smaller than the threshold value, the zero clearing of the count value of the non-slpcounter can be used for subsequent calculation of the duration of continuous non-sleep of the DSP, that is, restarting to detect whether the DSP is in the non-sleep state for a long time.

S108, when the target application is active, clearing the count of the NonSlpCounter, and then continuing to detect.

The target application being active means that the DSP is occupied. Accordingly, the DSP does not go to sleep, and thus, a sleep abnormality problem that should sleep without sleep does not occur. At this time, the detecting thread only needs to zero the count value of the nonSlpCounter for the subsequent recalculation of the duration of continuous non-dormancy of the DSP after the non-dormancy is detected.

Fig. 3 is a schematic diagram illustrating the operation of a detection thread in a DSP normal sleep scenario according to an embodiment of the present application.

As shown in fig. 3, the coordinate axis T represents time, i.e., a time axis. The time axes have the same intervals of time T1, T2, T3, … …, tn-1 and Tn. The interval between any two adjacent moments may represent a preset detection period of the detection thread, i.e. a period in which the detection thread executes S102 to acquire the system state.

Illustratively, the metering system may create and initialize a detection thread at time T1. After initialization, lastslptime=0 and nonslpcounter=0. Subsequently, running S102, the detection thread may confirm that the current target application is active, whereupon the detection thread may zero out the nonSlpCounter count and then continue detection. At this time, after the 1 st detection, lastslptime=0 and nonslpcounter=0.

The target application may exit the active state and go inactive until the next period (time T2) arrives, e.g., TX time. For example, the camera application may exit the active state when the camera application transitions to background operation at TX time; when the instant messaging application such as the WeChat ends the video call service at the TX moment, the instant messaging application such as the WeChat can exit the active state. At this time, the DSP stops running each DSP algorithm and enters a sleep state. Meanwhile, the state registration module cancels the registration information of each DSP algorithm in the state registration table. Wherein, after the DSP enters the sleep state, the SlpTimer is turned on and begins to time. The timing of the SlpTimer varies with system time.

Then, when the next cycle (time T2) arrives, the detection thread executes S102 again. At this point, the detection thread may confirm that the current target application is not active. Thus, the detection thread can acquire the timing of the SlpTimer, denoted as X1. Comparing X1 with LastSlpTime (where lastslptime=0), the detection thread may determine that the timing of the slptime is inconsistent two times before and after, and then the detection thread may zero the NonSlpCounter count value and assign the currently acquired timing X1 of the slptime to LastSlpTime. At this time, after the 2 nd detection, lastslptime=x1, nonslpcounter=0.

Continuing, upon the arrival of the next cycle (time T3), the detection thread executes again S102. At this point, the detection thread continues to confirm that the current target application is not active. Then, the timing when the detection thread acquires SlpTimer again is denoted as X2, x2+.x1. Comparing X2 with LastSlpTime (where lastslptime=x1), the detection thread can determine that the timing of the slptime is inconsistent two times before and after, and then the detection thread continues to zero the NonSlpCounter count value, assigning the currently acquired timing X2 of the slptime to LastSlpTime. At this time, after the 3 rd detection, lastslptime=x2, nonslpcounter=0.

And so on, when the time Tn-2 arrives, the detection thread again executes S102. The detection thread continues to confirm that the current target application is not active and then again obtains the timer Xn-3 for SlpTimer. At this time, lastSlpTime=Xn-3 and NonSlpCounter=0 after the n-2 nd detection.

For example, the DSP may end sleep at time TY. TY is between Tn-2 and Tn-1. The timing of the SlpTimer after the end of dormancy is no longer changed.

At this time, when the time Tn-1 arrives, the detection thread executes S102 again. The detection thread may confirm that the current target application is active, and then the detection thread may directly zero out the NonSlpCounter count and then continue detection. At this time, lastSlpTime=Xn-3 and NonSlpCounter=0 after the n-1 st detection.

As shown in fig. 3, in the scenario where the DSP is normally dormant, the detection thread does not trigger a sleep exception report. Meanwhile, the detection thread can update LastSlpTime in real time so as to keep the LastSlpTime consistent with the SlpTimer of the DSP system.

Fig. 4 is a schematic diagram of detecting threads in a DSP non-sleep scenario according to an embodiment of the present application.

As shown in fig. 4, at the TX time, the target application exits the active state and goes inactive, but the DSP does not enter the sleep state, i.e., the DSP does not sleep. Since the DSP does not enter the sleep state, accordingly, the SlpTimer is not turned on. The timer for SlpTimer is still the last time sleep was ended, e.g. X0.

At this time, when the time T2 arrives, the detection thread executes S102 again. At this point, the detection thread may confirm that the current target application is not active. Thus, the detection thread may acquire the timing X0 of the SlpTimer. Comparing X0 with LastSlpTime (where lastslptime=0), the detection thread may determine that the timing of the slptime is inconsistent two times before and after, and then the detection thread may zero the NonSlpCounter count value and assign the currently acquired timing X0 of the slptime to LastSlpTime. At this time, after the 2 nd detection, lastslptime=x0, nonslpcounter=0.

When the time T3 arrives, the detection thread executes S102 again. At this point, the detection thread continues to confirm that the current target application is not active. The detection thread may then acquire the timing of the SlpTimer. Since the SlpTimer is not on, the timing of the SlpTimer acquired by the detection thread is still X0. Comparing X0 with LastSlpTime (where lastslptime=x0), the detection thread can determine that the timing of the two slptimers is consistent. At this point, the detection thread may determine that the DSP is experiencing a non-sleep problem. Thereupon, the detection thread may increment the nonSlpCounter count value. At this time, after the 3 rd detection, lastslptime=x0, nonslpcounter=1.

By analogy, when the time T8 arrives, the detection thread executes S102 again. The detection thread continues to confirm that the current target application is not active, again taking the timing of the SlpTimer, which is still X0. Thus, the count value of the NonSlpCounter continues to increase. After the 8 th test, lastslptime=x0, noslpcount=6.

For example, the threshold for NonSlpCounter may be set to 10. The TY moment of the target application in the recovery active state is between the T8 and the T9 moment.

At this time, when the time T9 arrives, the detection thread executes S102 again. At this time, the detection thread may confirm that the current target application is active, and then the detection thread may directly clear the NonSlpCounter count and then continue detection. At this time, after the 9 th detection, lastslptime=x0, nonslpcounter=0.

Fig. 5 is a schematic diagram of detecting threads in another non-sleep scenario of a DSP according to an embodiment of the present disclosure.

Likewise, at TX time, the target application exits the active state, transitions to the inactive or dormant state, but the DSP does not enter the dormant state. Accordingly, slpTimer is not turned on. The timer of SlpTimer is still the last time sleep was ended X0. The threshold for the nonSlpCounter is 10. The TY time when the target application is in the inactive state may be after time T12, e.g. between time T12 and time T13.

As shown in fig. 5, when the time T12 arrives, the detection thread executes S102 again. The detection thread continues to confirm that the current target application is not active and the timing of the re-acquired SlpTimer is still X0. Thus, the count value of the NonSlpCounter continues to increase. After the 12 th test, lastslptime=x0, noslpcount=10. At this point, noslpcount=10 reaches a preset threshold, and the detection thread may trigger a sleep exception report.

Referring to fig. 4 and 5, after the DSP experiences a non-sleep problem, the detection thread may detect that the DSP is not sleeping. The monitoring thread may not trigger a sleep exception report until the duration of non-sleep of the DSP reaches a preset duration indicated by the non-slpcounter threshold. After the duration of the non-dormancy of the DSP reaches the preset duration indicated by the NonSlpCounter threshold, the monitoring thread can trigger a dormancy abnormality report and send the DSP field information, the DSP log and the data of the state registry when the DSP is not dormant to the cloud.

Setting the NonSlpCounter threshold can shield the relatively unimportant short-time non-dormancy problem, help the research personnel focus on the long-time non-dormancy of the DSP, and preferentially determine the reason of the long-time non-dormancy problem of the DSP, thereby preferentially solving the long-time non-dormancy problem of the DSP.

In some embodiments, the detection thread may not set the non slpcounter threshold. At this time, the detection thread may trigger sleep exception reporting immediately after detecting that the DSP is not dormant.

Fig. 6 shows a schematic structural diagram of the electronic device 100.

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It should be understood that the illustrated structure of the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a DSP, a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

A memory may also be provided in the processor 110 for storing instructions and data.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present invention is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also use different interfacing manners, or a combination of multiple interfacing manners in the foregoing embodiments.

The charge management module 140 is configured to receive a charge input from a charger. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 to power the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low frequency baseband signal to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques. The wireless communication techniques may include the Global System for Mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).

In this embodiment of the present application, after triggering the sleep exception report, the reporting module may send information such as DSP field information, a state registry, and DSP log during sleep exception to the cloud through a wireless communication method such as 2G/3G/4G/5G provided by the mobile communication module 150 or a wireless communication method such as Wi-Fi/bluetooth/GNSS/FM/NFC/IR provided by the wireless communication module 160.

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information. The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD). The display panel may also be manufactured using organic light-emitting diode (OLED), active-matrix organic light-emitting diode (AMOLED) or active-matrix organic light-emitting diode (active-matrix organic light emitting diode), flexible light-emitting diode (FLED), mini, micro-OLED, quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like.

In the embodiment of the present application, the electronic device 100 may display a User Interface (UI) through a GPU, a display screen 194, and a display function provided by an application processor, for example, a shooting interface of a camera application, an interactive interface of an instant messaging application such as a WeChat, a video call interface, and the like.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and is converted into an image visible to naked eyes. ISP can also perform algorithm optimization on noise and brightness of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

In the embodiment of the present application, based on the shooting functions provided by the ISP, the camera 193, the video codec, the GPU, the display screen 194, the application processor, and the like, the target applications such as the camera and the WeChat can call the camera to realize the shooting or video call functions.

The DSP is used to process digital signals, and may process other digital signals in addition to the digital image signals described above. For example, when the electronic device 100 selects a frequency bin, the DSP is used to fourier transform the frequency bin energy, or the like. Therefore, in the embodiment of the application, the DSP algorithm further includes a frequency point selection algorithm, and the target application further includes an application for implementing an access network function based on the frequency point selection algorithm.

The internal memory 121 may include one or more random access memories (random access memory, RAM) and one or more non-volatile memories (NVM).

The random access memory may be read directly from and written to by the processor 110, may be used to store executable programs (e.g., machine instructions) for an operating system or other on-the-fly programs, may also be used to store data for users and applications, and the like. The nonvolatile memory may store executable programs, store data of users and application programs, and the like. The executable programs and the data of the user and application programs stored in the nonvolatile memory can be loaded into the random access memory in advance for the processor 110 to directly read and write.

In the embodiment of the present application, the executable program code of the data acquisition method, the DSP non-sleep detection method, and the user data described in the embodiment of the present application may be stored in a nonvolatile memory. When implementing the data acquisition method and the DSP non-sleep detection method, the electronic device 100 may load and execute the executable program code of the nonvolatile memory and the user data into the random access memory, thereby implementing real-time detection of whether the DSP is not in sleep, and implementing saving and reporting of relevant data when the DSP is not in sleep.

The external memory interface 120 may be used to connect external non-volatile memory to enable expansion of the memory capabilities of the electronic device 100. The external nonvolatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like.

The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. The electronic device 100 may calculate the location, intensity of the touch from the detection signal of the pressure sensor 180A. The gyro sensor 180B may be used to determine a motion gesture of the electronic device 100. The air pressure sensor 180C is used to measure air pressure. The magnetic sensor 180D includes a hall sensor. The electronic device 100 may detect the opening and closing of the flip cover using the magnetic sensor 180D. In some embodiments, when the electronic device 100 is a flip machine, the electronic device 100 may detect the opening and closing of the flip according to the magnetic sensor 180D. And then according to the detected opening and closing state of the leather sheath or the opening and closing state of the flip, the characteristics of automatic unlocking of the flip and the like are set. The acceleration sensor 180E may detect the magnitude of acceleration of the electronic device 100 in various directions (typically three axes). A distance sensor 180F for measuring a distance. The proximity light sensor 180G may include, for example, a Light Emitting Diode (LED) and a light detector, such as a photodiode. The power generation sub-device 100 detects infrared reflected light from nearby objects using a photodiode. When sufficient reflected light is detected, it may be determined that there is an object in the vicinity of the electronic device 100. When insufficient reflected light is detected, the electronic device 100 may determine that there is no object in the vicinity of the electronic device 100. The ambient light sensor 180L is used to sense ambient light level. The fingerprint sensor 180H is used to collect a fingerprint. The temperature sensor 180J is for detecting temperature. The touch sensor 180K, also referred to as a "touch device". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 100 at a different location than the display 194. The bone conduction sensor 180M may acquire a vibration signal. The keys 190 include a power-on key, a volume key, etc. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100. The motor 191 may generate a vibration cue. The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc. The SIM card interface 195 is used to connect a SIM card.

As used in the specification and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates to the contrary. It should also be understood that the term "and/or" as used in this application refers to and encompasses any or all possible combinations of one or more of the listed items. As used in the above embodiments, the term "when …" may be interpreted to mean "if …" or "after …" or "in response to determination …" or "in response to detection …" depending on the context. Similarly, the phrase "at the time of determination …" or "if detected (a stated condition or event)" may be interpreted to mean "if determined …" or "in response to determination …" or "at the time of detection (a stated condition or event)" or "in response to detection (a stated condition or event)" depending on the context.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

Claims

1. A data acquisition method, characterized by being applied to an electronic device, the electronic device comprising a digital signal processor DSP, the method comprising:

running a first number of algorithms on the DSP;

when any algorithm starts to run, recording related information of the algorithm, wherein the related information at least comprises an algorithm name of the algorithm;

stopping running the second number of algorithms;

deleting the related information of the second number of algorithms, wherein the second number is smaller than or equal to the first number;

detecting that the DSP is not dormant, and sending related information of a third number of algorithms which are remained currently to a server;

the DSP not being dormant means that the DSP should be dormant but not dormant; wherein, when the target application corresponding to the first number of algorithms is not active, the DSP should sleep; the target application being inactive includes that the target application is not running without executing any algorithms with the DSP.

2. The method of claim 1, wherein the related information further comprises one or more of: calculating the power level, voting frequency points and registration time.

3. The method of claim 1, wherein after the detecting that the DSP is not dormant, the method further comprises:

the present DSP field information is sent to the server,

and/or sending the current log of the DSP to the server.

4. A method according to any of claims 1-3, wherein after said detecting that the DSP is not dormant, before said sending the relevant information of the currently remaining third number of algorithms to the server, the method further comprises:

and confirming that the duration of the non-dormancy of the DSP reaches a preset value.

5. The method of claim 4, wherein the detecting that the DSP is not dormant comprises:

detecting that the target application is not active and the timing of the sleep timer of the DSP acquired before and after the target application is the same;

and the dormancy timer starts timing after the DSP enters dormancy, and stops timing after the dormancy is finished.

6. The method according to claim 5, wherein said confirming that the duration of the DSP not to sleep reaches a preset value comprises:

Continuing to acquire the timing of the dormancy timer for N times; n is more than or equal to 1;

and when any one of the acquired N timings is the same as the timing of the sleep timer of the DSP acquired in two times, determining that the duration of the non-sleep time of the DSP reaches a preset value.

7. The method of claim 5, wherein the first number of algorithms comprises an image processing algorithm; the running of the target application does not require any algorithm to be performed by the DSP including the target application turning off the camera.

8. The method of claim 7, wherein the target application comprises one or more of a camera application, an instant messaging application, a motion sensing game application.

9. The method of claim 1, wherein the electronic device comprises a hardware abstraction layer HAL, the HAL comprising a detection thread and a reporting module; the detecting that the DSP is not dormant, and sending relevant information of the remaining third number of algorithms to a server, specifically includes:

the detection thread detects that the DSP is not dormant;

the reporting module sends information about the remaining third number of algorithms to the server.

10. The method according to claim 8, wherein the HAL further comprises a status registration module, said recording information about the algorithm, in particular comprising:

the state registration module creates a state registration table;

the state registration module records the related information of the algorithm in the state registration table;

the deleting the related information of the second number of algorithms specifically includes:

the state registration module deletes the related information of the second number of algorithms from the state registration table, and the related information of the third number of algorithms is remained.

11. An electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories being configured to store a computer program that, when executed by the one or more processors, causes the method of any of claims 1-10 to be performed.

12. A computer readable storage medium comprising a computer program, characterized in that the computer program, when run on an electronic device, causes the execution of the method according to any one of claims 1-10.