CN111611115B

CN111611115B - Method and device for detecting frame rate

Info

Publication number: CN111611115B
Application number: CN202010397532.9A
Authority: CN
Inventors: 於林涛
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2020-05-12
Filing date: 2020-05-12
Publication date: 2023-10-13
Anticipated expiration: 2040-05-12
Also published as: CN111611115A

Abstract

The present disclosure relates to a frame rate detection method, apparatus, electronic device, and storage medium. The method comprises the following steps: binding a frame rate FPS detection trigger timer to a thread of an application program; starting an FPS detection trigger timer, so that the FPS detection trigger timer calls a designated interface according to a set timing period to acquire the identifications of all frames refreshed and displayed in the timing period; the designated interface includes: an identification acquisition interface of a screen refreshing frame provided by an operating system; and determining the FPS according to the number of the identifiers of all frames of the refreshing display acquired in the unit time length. The method can solve the problem of inaccurate detection results in the FPS detection in the prior art.

Description

Method and device for detecting frame rate

Technical Field

The disclosure relates to the technical field of terminals, and in particular, to a method and device for detecting a frame rate, an electronic device and a storage medium.

Background

In the Application performance management (Application Performance Management, APM) requirements of the mobile terminal, some metrics are generally required to measure the smoothness of the interface during the operation of the Application (Application) by the user.

Currently, the accepted index is compared to the frame rate of the application interface (herein, the number of frames per second, frames Per Second, FPS) and the interface smoothness is measured by detecting the FPS. It will be appreciated that the more frames per second are displayed, the smoother the interface, and conversely, the interface may become stuck.

In the prior art, taking an iOS mobile terminal (i.e. an installed operating system includes a mobile terminal of the iOS) as an example, detecting the FPS mainly by the following two ways:

mode one: and fitting the FPS by calculating the calling frequency of the CADisplayLink bound on the main thread. CADisplayLink is a timer object that allows an application to display an application's interface on a screen at the same frequency as the screen refresh frequency.

Mode two: the FPS is approximately obtained by detecting the polling frequency of the RunLoop of the main thread. RunLoop is a loop that keeps a program running continuously, and mainly plays roles in iOS include: keep the application running continuously and process various events in the application (e.g., touch events, timer events, UI refresh events, etc.) in each cycle. in the iOS system, screen refreshing depends on CoreAnimation, and the framework submits contents (such as memory objects or bitmaps to be drawn) to an operating system by scheduling Runloop of a main thread, and the operating system converts the submitted contents into textures and then realizes refreshing of the screen contents by hardware. By adding monitoring to the RunLoop of the main thread, the polling frequency of the RunLoop can be monitored, and then the polling frequency is used as the calculated FPS.

The two modes are respectively calculating the calling frequency of CADisplayLink bound on the main thread or the polling frequency of RunLoop of the main thread as the FPS, wherein the calculation result is not exactly equal to the actual FPS, but only approximately equal to the FPS. Especially in some scenarios, the FPS obtained in the two ways described above is much different from the actual FPS. Wherein the actual FPS should be equal to the FPS of the application interface that the user really sees.

For example, for the first mode, the call frequency of the CADisplayLink bound on the main thread is greatly affected by the loads of the central processing unit (Central Processing Unit, CPU) and the image processor (Graphics Processing Unit, GPU), and in a scenario where the load of the CPU or GPU is too high, the actual FPS will be reduced, so that the call frequency of the CADisplayLink on the main thread will be far higher than the actual FPS, and thus, taking the call frequency of the CADisplayLink as the FPS will result in inaccuracy of the detected FPS.

For the second mode, the RunLoop polling frequency of the main thread only depends on the scheduling condition of the CPU on the RunLoop of the main thread, and is irrelevant to the GPU. In fact, the actual FPS size is affected by the GPU load. Thus, when the load of the GPU is too high, the RunLoop polling frequency is directly used as an actual FPS, and the influence of the load of the GPU on the FPS is ignored, so that the detected FPS is inaccurate.

Disclosure of Invention

The disclosure provides a method, a device, electronic equipment and a storage medium for detecting FPS, which at least solve the problem of inaccurate detection result in FPS detection by adopting the prior art. The technical scheme of the present disclosure is as follows:

according to a first aspect of an embodiment of the present disclosure, there is provided a method for detecting a frame rate, including:

binding a frame rate FPS detection trigger timer to a thread of an application program;

starting the FPS detection trigger timer, so that the FPS detection trigger timer triggers the thread to call a designated interface to acquire the identifications of all frames which are refreshed and displayed in a set timing period; the specified interface includes: an identification acquisition interface of a screen refreshing frame provided by an operating system;

and determining the FPS according to the number of the identifiers of all frames of the refreshing display acquired in the unit time length.

In an alternative embodiment, the FPS detection trigger timer is started, so that the FPS detection trigger timer triggers the thread to call a designated interface to acquire the identification of all frames that are refreshed and displayed in a set timing period, and the method includes:

According to the regular refreshing period of the screen, periodically modifying the attribute value of the appointed display attribute of at least one pixel point arranged in the interface displayed on the screen; wherein the specified display attribute comprises an attribute related to a display mode of the pixel point in an interface;

starting the FPS detection trigger timer to enable the FPS detection trigger timer to trigger the thread to call a designated interface to acquire according to the timing period: and triggering the refreshing of the identification of all the frames displayed in the timing period by periodically modifying the attribute value of the appointed display attribute of at least one pixel point arranged in the interface of the screen display.

In an alternative embodiment, the method further comprises: and setting the at least one pixel point with the specified display attribute in the screen display interface.

In an alternative embodiment, the specified display attribute of the pixel point includes: at least one of transparency and color value.

In an alternative embodiment, the thread includes: asynchronous threads.

In an alternative embodiment, after determining the FPS according to the number of identifiers of all frames of the refresh display acquired in a unit time length, the method further includes:

Storing each FPS determined in a preset time length;

and determining the interface display fluency of the application program based on the determined FPSs.

In an alternative embodiment, determining the smoothness of the interface display of the application program based on the determined FPSs includes:

and reporting the stored FPSs determined in the preset time length to a server, so that the server determines the interface fluency of the application program based on the FPSs determined in the preset time length.

In an alternative embodiment, the operating system includes iOS.

According to a second aspect of embodiments of the present disclosure, there is provided a frame rate detection apparatus including:

a binding module configured to perform binding of the frame rate FPS detection trigger timer on the threads of the application;

the acquisition module is configured to start the FPS detection trigger timer, so that the FPS detection trigger timer triggers the thread to call a designated interface to acquire the identification of all frames which are refreshed and displayed in a set timing period; the specified interface includes: an identification acquisition interface of a screen refreshing frame provided by an operating system;

And a determining module configured to perform a determination of the FPS according to the number of identifications of all frames of the refresh display acquired within a unit time length.

In an alternative embodiment, the acquiring module includes:

a modifying unit configured to perform periodic modification of an attribute value of a specified display attribute of at least one pixel point set in an interface of screen display in accordance with the screen regular refresh period; wherein the specified display attribute comprises an attribute related to a display mode of the pixel point in an interface;

an acquisition unit configured to perform starting the FPS detection trigger timer, so that the FPS detection trigger timer triggers the thread to call a specified interface to acquire according to the timing period: and triggering the refreshing of the identification of all the frames displayed in the timing period by periodically modifying the attribute value of the appointed display attribute of at least one pixel point arranged in the interface of the screen display.

In an alternative embodiment, the apparatus further comprises:

and a setting module configured to set the at least one pixel point having the specified display attribute in an interface of the screen display.

In an alternative embodiment, the thread includes: asynchronous threads.

In an alternative embodiment, the apparatus further comprises:

a storage module configured to perform storing of the FPSs determined within a preset time period;

and the determining module is configured to determine the interface display fluency of the application program based on the determined FPSs.

In an alternative embodiment, the determining module is configured to specifically perform: and reporting the stored FPSs determined in the preset time length to a server, so that the server determines the interface fluency of the application program based on the FPSs determined in the preset time length.

In one embodiment, the operating system includes iOS.

According to a third aspect of embodiments of the present disclosure, there is provided an electronic device, comprising:

a processor; a memory for storing the processor-executable instructions;

wherein the processor is configured to perform the method steps of detecting a frame rate of any of the above first aspects.

According to a fourth aspect of embodiments of the present disclosure, there is provided a storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform the method of detecting a frame rate of any one of the above-described first aspects.

According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product that, when run on an electronic device, causes the detection electronic device of a frame rate to perform: the method steps of the method for detecting a frame rate according to any one of the first aspect.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:

in the embodiment of the disclosure, the FPS detection trigger timer is used for triggering and calling the designated interface at fixed time to acquire the identifiers of all frames refreshed and displayed in the fixed time period according to the set fixed time period, so that the identifiers of the frames actually refreshed and displayed are directly acquired to determine the FPS.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.

Fig. 1 is a flowchart illustrating a method of detecting a frame rate according to an exemplary embodiment.

Fig. 2 is a block diagram illustrating a frame rate detection apparatus according to an exemplary embodiment.

FIG. 3 is a block diagram of a frame rate detection system, according to an exemplary embodiment.

Fig. 4 is a block diagram of an electronic device, according to an example embodiment.

Detailed Description

In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the foregoing figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

In the prior art, the calling frequency of CADisplayLink bound on a main thread or the polling frequency of RunLoop of the main thread is calculated to serve as the FPS, and the calculation result is not exactly equal to the actual FPS, but only approximately equal to the FPS. In practical applications, it is also inaccurate to measure the smoothness of the application interface of the user during operation according to the detected inaccurate FPS.

In order to solve the problem of inaccurate detection results in the FPS detection in the prior art, one or more embodiments of the present disclosure acquire, through a designated interface provided by an operating system, an identifier of a frame refreshed on a screen (i.e., an identifier of a frame actually refreshed is acquired), and determine an FPS based on the number of acquired identifiers, so as to improve the accuracy of the detected FPS.

Fig. 1 is a flowchart illustrating a method of detecting a frame rate according to an exemplary embodiment, by which the problem of inaccurate detection results existing in the FPS detection using the related art can be solved.

The execution subject of the method includes, but is not limited to, a server, a personal computer, a notebook computer, a tablet computer, a smart phone, etc. and can execute a predetermined processing procedure such as numerical calculation and/or logic calculation by running a predetermined program or instruction. Wherein the server may be a single web server or a server group composed of a plurality of web servers or a Cloud based on Cloud Computing (Cloud Computing) composed of a large number of computers or web servers.

In the embodiment of the present disclosure, the execution subject is described as an example of a terminal device, and in particular, the iOS-based terminal device is described as an example. It is to be appreciated that while the embodiments of the present disclosure are presented with respect to solutions to iOS-based FPS detection problems, the concepts disclosed in the embodiments of the present disclosure may also be applied to android systems. If the inventive concept disclosed by the embodiment of the present disclosure is applied to the android system to implement FPS detection based on the android system, the method also belongs to the scope of the protection scope of the present disclosure. Specifically, the method for detecting a frame rate provided by the embodiment of the disclosure may include the following steps:

in step 11, the frame rate FPS detection trigger timer is bound to the thread of the application.

The frame rate FPS detection trigger timer here may be a timer for timing trigger detection of the FPS.

In practical applications, the timing period of the frame rate FPS detection trigger timer may be set according to practical requirements. For example, the actual requirements described herein may include, but are not limited to: the problems of excessively high power consumption, high performance load and the like caused by excessively frequent FPS detection are avoided.

In one or more embodiments of the present disclosure, for a terminal device whose operating system is iOS, the FPS detection trigger timer may use the CADisplayLink as the FPS detection trigger timer, so that the cost for developing the FPS detection trigger timer may be saved by using the existing FPS detection trigger timer provided by iOS. Wherein CADisplayLink is a timer object that allows an application to display an interface of the application on a screen at the same frequency as the screen refresh frequency.

Of course, the developer can also develop the FPS detection trigger timer according to different operating systems and actual requirements, so as to realize the FPS detection trigger timer function. The present disclosure is not limited with respect to the implementation of the FPS detection trigger timer.

In practical application, when an application on a terminal device is started, a process, a thread and the like are generated to realize the running of the application, and in the embodiment of the present disclosure, considering that the determined FPS may be used to determine the interface display smoothness of the application, the FPS detection trigger timer may be bound to the thread of the application whose interface display smoothness is to be determined, so that the FPS detection trigger timer is started when the application is started.

Of course, if it is not necessary to detect the smoothness of the application program, but only to detect the FPS, the FPS detection trigger timer may be bound to the thread of the application program to which the current display interface belongs.

As described above, when an application is started, a process is created by the operating system. At the same time, a Thread also runs immediately, which is often called the Main Thread (Main Thread) of the application, and if a Thread needs to be recreated, the created Thread is a child of this Main Thread. Each process has at least one main thread.

In practical application, if the FPS detection trigger timer is bound to the main thread of the application program, the main thread works in a "synchronous" manner, and the task for periodically calling the designated interface needs to wait for the completion of the work of the other threads of the application program and then execute, so that the phenomenon of "main thread Cheng Kadu" is easily caused by the influence of the task completion condition of the other threads, and the FPS detection trigger timer cannot trigger the main thread to periodically call the designated interface. Thus, in one or more embodiments of the present disclosure, binding the FPS detection trigger timer to the threads of the application may specifically include: the FPS detection trigger timer is bound to an asynchronous thread of the application. Wherein, the asynchronous thread of the application program refers to a plurality of threads of the application program for realizing asynchronization. The plurality of threads may be a plurality of sub-threads of a main thread of the application created by the operating system.

Because the asynchronous threads have the characteristic of being independent of each other and continuously doing own in the process of waiting for an event, and do not need to wait for the event to finish and then work, the FPS detection triggering timer is bound to the asynchronous threads, so that the problem of blocking the detection of the FPS caused by the blocking of the main thread can be avoided.

In addition, in the embodiment of the present disclosure, the CADisplayLink is used as an FPS detection trigger timer to be bound to an asynchronous thread, so that the characteristic of the CADisplayLink as a timer can be used to drive the normal running of the logic of the method provided in the present disclosure, and the interface drawing of the application program executed by the main thread is hardly affected.

In step 12, the FPS detection trigger timer is started, so that the FPS detection trigger timer calls the designated interface to acquire the identifications of all frames that are refreshed and displayed in the timing period according to the set timing period.

In practical application, as described above, the FPS detection trigger timer may be bound to a thread of an application program, and in order to timely detect the FPS of a user in the process of operating the application program, when the application program is started, the FPS detection trigger timer may be started.

After the FPS detection trigger timer is started, the specified interface may be invoked by the timing trigger thread according to a set timing period, so as to obtain the identifiers of all frames that are refreshed and displayed in the timing period. In practical applications, the thread may be the thread that binds the FPS detection trigger timer described above.

In practical applications, the timing period of the FPS detection trigger timer may be set smaller than the regular refresh period of the screen, but it is considered that if the timing period of the FPS detection trigger timer is too small, the identifier of the current frame acquired in the regular refresh period of the single screen may be unchanged, which may result in resource waste. For example, if the conventional refresh period of the screen of the terminal device a is Tms, it may be understood that the terminal device a completes the screen refresh every Tms under normal conditions, if the timing period of the FPS detection trigger timer is set to (T/4) ms, at a certain time point, the screen starts to refresh, the frame identifier of the time point acquired by the FPS detection trigger timer start trigger may be "frame id=0", and after (T/4) ms, since the interface of the terminal device is not refreshed according to the conventional refresh period of the screen at this time Tms, the frame identifier acquired by the FPS detection trigger timer is still "frame id=0". It can be seen that such frequent triggering of thread calls to acquire the number of screens can be superfluous and waste power, possibly even resulting in a significant amount of power loss, affecting the user experience.

Based on the existence of the above-described problems, in one or more embodiments disclosed, the timing period of the FPS detection trigger timer may be set to be not less than the screen regular refresh period. In practical applications, the screen regular refresh period may be different for different terminal devices, and for a terminal device with an os as the operating system, the screen regular refresh period is about 16.67ms, and then the timing period may be set to a value not less than 16.67 ms. The specific value of the timing period can be set according to the actual requirement, and the application is not limited.

In practical applications, the designating interface in step 12 may include: the identification of the screen refresh frame provided by the operating system obtains the interface.

Taking iOS as an example, the specified interface may include, but is not limited to, the calendeservergetframe counter function provided by iOS. The CARenderServerGetFrameCounter function obtains the identifiers of all frames that can be actually refreshed and displayed on the screen of the device on which the operating system is installed, and since the identifiers of the frames are generally numbered continuously, it can be understood that the obtained frames are the actual number of frames that are refreshed and displayed on the screen. The working principle of the CARenderServerGetFramecounter function can include: the number of frames acquired by the CARenderServerGetFrameCounter function is increased once every screen refresh, that is, every time a screen is refreshed, the acquired refresh indicates that the identifiers of all frames are increased by a corresponding amount corresponding to the number of screen refreshes, so the CARenderServerGetFrameCounter function can acquire what is actually the number of screen refreshes.

For ease of understanding, the frame identification is denoted as "frame ID" by way of example, and for iOS, as described above, for a terminal device whose operating system is iOS, the screen normal refresh period is about 16.67ms, and if it is assumed that the ID of the first frame refreshed after the application is started is 1, and at some point after the application is started, the frame id=20 acquired by the calendeservergetframe counter function, it can be understood that the number of frames for screen refresh is 20 from the start of the application to that point.

For the iOS, the number of frames of the real screen refresh display can be detected through the specified interface provided by the iOS, namely the caprendeservergetframe counter function, and compared with the prior art, the accuracy of detecting the FPS can be greatly improved. And an API interface which is not used by other people in the field, namely a CARenderServerGetFrameCounter function, is creatively found in the APM field, so that the FPS is detected. Because the CARenderServerGetFramecounter function can detect the number of frames of real screen refreshing display, the influence of GPU load on FPS is not ignored, and when the GPU load is too high, the clamping caused by the too high GPU load can be detected, so that the detected FPS is more accurate.

In step 13, the FPS is determined based on the number of identifications of all frames of the refresh display acquired in a unit time length.

The identification of all frames of the refresh display here may be obtained by step 12.

In practical use, as described above, the FPS may be the number of frames displayed per second, i.e., the number of frames displayed with screen refresh per unit length of time. In the disclosed embodiment, the FPS may be determined based on the number of identifications of all frames acquired per unit length of time to refresh the display.

In the embodiment of the present disclosure, in determining the FPS according to the number of the identifications of all frames of the refresh display acquired in a unit time length, various calculation manners may be adopted. Embodiments of the present disclosure provide the following several calculation modes, which may include:

the first calculation mode is as follows: the FPS may be calculated from a variation difference in the number of identifications of frames per unit time length, for example, frame id=20 acquired at time point m, and the identifications of frames acquired within 1 second from the time point m may include "frame id=21, frame id=22, frame id=23, … … frame id=80", wherein the frame id=80 acquired at time point m+1s is 60 (frames/sec) by calculating a difference between frame id=20 and frame id=80, that is, 80-20=60, and the obtained identifications of frames vary 60 times.

In the second calculation method, the number of the frame IDs acquired in 1 second from the point m of time is counted as 60 frame IDs, and the FPS is 60 (frames/second) in accordance with the number of the frame IDs acquired in the unit time length counted as described in the first calculation method.

It should be noted that, the first and second modes are two specific calculation modes provided by the embodiments of the present disclosure, and in practical application, the calculation mode may be determined according to the actual situation, which is not limited to this disclosure.

In one or more embodiments of the present disclosure, to facilitate a developer to determine the FPS according to the detected level of the flow displayed by the interface of the FPS analysis application, after determining the FPS according to the number of the identifiers of all frames of the refresh display acquired in the unit time length, the method may further include:

storing each FPS determined in a preset time length;

The preset time length may be set according to actual requirements, for example, may be 3 minutes.

In practical application, the determined FPSs may be stored in a specified readable and writable local file, so that the stored FPSs determined in a preset time length are reported to the server, so that the server determines the interface display smoothness of the application program based on the FPSs determined in the preset time length.

Or, the terminal device itself may read each FPS determined in the preset time period from the readable and writable local file, and determine the interface display smoothness of the application program based on each FPS. It will be appreciated that the more Frames Per Second (FPS) are displayed, the smoother the interface, whereas the interface may appear to be stuck, for example, assuming that the FPS is considered to be smooth at around 60 (frames/second), when the FPS is detected to be 40 (frames/second), it may be determined that the interface is stuck, i.e., the smoothness is not high.

In practical application, the identifiers of all frames stored and refreshed are reported to the server, and data can be transmitted to the server through a hypertext transfer protocol (HyperText Transfer Protoco, HTTP), and other data transmission modes can be adopted, so that the application is not limited. After the data is transmitted to the server, each data demander can be allowed to acquire the FPS data by means of the registration instance. After each data demander obtains the FPS data, the data may be analyzed according to the respective service requirements, and so on.

For the iOS, if the interface of the application program does not change within a period of time, the iOS will automatically reduce the screen refreshing frequency for power saving, and the lack of change in the interface within a period of time may be due to no operation of the user or a stuck interface, so that the smoothness of the interface of the application program cannot be accurately determined according to the FPS. For example, as described above, if the conventional refresh period of the screen of the iOS device is 16.67ms, the screen is normally refreshed about 60 times within 1 second, that is, 60 (frames/second) FPS are normal, and if the screen refresh frequency is reduced by 40 times within 1 second due to no change in the interface for a period of time caused by no operation by the user, the iOS device detects that 40 (frames/second) FPS are actually normal, although 40 (frames/second) FPS are detected, the interface smoothness may be misjudged because the interface is not jammed.

In one or more embodiments of the present disclosure, in order to solve the problem that the iOS may automatically reduce the conventional refresh frequency of the screen to cause erroneous determination of the smoothness of the interface in order to save power, at least one pixel having a specified display attribute may be set in advance in the interface displayed on the screen, so that the screen is forced to be refreshed by modifying the attribute value of the specified display attribute of the at least one pixel, so that the iOS is forced not to automatically reduce the refresh frequency. It is understood that the screen displayed interface referred to herein may refer to the interface of the application.

In one or more embodiments of the present disclosure, at the start of an application, an attribute value of a specified display attribute of the at least one pixel point set in an interface of a screen display may be periodically modified according to a regular refresh period of the screen. As described above, by periodically modifying the attribute value of the specified display attribute of at least one pixel, it is equivalent to forcing screen refresh, so that iOS can be forced not to decrease the screen refresh frequency.

The specified display attribute here includes an attribute related to a display manner of the pixel point in the interface, and specifically may include at least one of transparency and color value.

In practical application, the attribute value of the designated display attribute of at least one pixel point set in the interface displayed on the screen can be periodically modified according to the regular refresh period of the screen by setting a timer. In one or more embodiments of the present disclosure, in order to save development costs and avoid excessive code amounts, the timer may be the same timer as the above-described FPS detection trigger timer. Of course, different timers may be employed, and the disclosure is not limited in this regard.

In practical application, as described above, by periodically modifying the attribute value of the designated display attribute of at least one pixel point set in the interface of the screen display, the iOS may be forced to perform screen refresh, and it may be understood that, if the screen refresh may change the identifier of the displayed frame, in one or more embodiments of the present disclosure, starting the FPS detection trigger timer, so that the FPS detection trigger timer calls the designated interface to obtain the identifier of all frames that refresh the display in the timing period according to the set timing period, which may include:

according to the regular refreshing period of the screen, periodically modifying the attribute value of the appointed display attribute of at least one pixel point arranged in the interface displayed on the screen;

starting an FPS detection trigger timer, so that the FPS detection trigger timer triggers a thread to call a designated interface to acquire according to a timing period: and triggering and refreshing the identification of all frames displayed in a timing period by periodically modifying the attribute value of the appointed display attribute of at least one pixel point arranged in the interface of the screen display.

It can be understood that, by periodically modifying the attribute value of the designated display attribute of at least one pixel point set in the interface of the screen display, the identification of the frame of the refresh display can be triggered, and then the FPS detection triggers the timer to trigger the thread to call the designated interface according to the timing period, so that the identification of all frames of the refresh display triggered in the timing period can be obtained.

In the embodiment of the disclosure, the periodic modification of the attribute value of the designated display attribute of at least one pixel point set in the application program interface of the screen display is equivalent to forcing the screen refresh, so that the iOS can be forced not to reduce the screen refresh frequency. In such a case, triggering the thread to call the designated interface by the FPS detection trigger timer at a timing period, and triggering the refreshing of the identification of all frames of the display in such a manner that the attribute value of the designated display attribute of at least one pixel point set in the interface of the screen display is periodically modified in the timing period, so that the detected FPS is not the FPS after the screen refresh frequency is reduced but the FPS at the time of refreshing at the regular refresh period of the screen. The display smoothness of the judging interface based on the FPS is more accurate, and the problem of misjudgment can be avoided.

Fig. 2 is a block diagram illustrating a frame rate detection apparatus according to an exemplary embodiment. Referring to fig. 2, the apparatus includes a binding module 101, an acquisition module 102, and a determination module 103.

The binding module 101 is configured to perform binding of the frame rate FPS detection trigger timer on the thread of the application;

The acquiring module 102 is configured to perform starting the FPS detection trigger timer, so that the FPS detection trigger timer triggers the thread to call a designated interface to acquire the identifications of all frames displayed in a refreshing manner in a set timing period; the specified interface includes: an identification acquisition interface of a screen refreshing frame provided by an operating system;

the determining module 103 is configured to perform a determination of the FPS based on the number of identifications of all frames of the refresh display acquired within a unit time length.

The specific workflow of the above device embodiment is: a binding module 101 that binds the frame rate FPS detection trigger timer to the thread; the acquiring module 102 starts the FPS detection trigger timer, so that the FPS detection trigger timer triggers the thread to call a designated interface to acquire the identifications of all frames which are refreshed and displayed in a set timing period; the determining module 103 determines the FPS according to the number of the identifiers of all the frames of the refresh display acquired in the unit time length. .

In one embodiment, the obtaining module 102 includes:

In one embodiment, the apparatus further comprises:

In one embodiment, the specified display attribute of the pixel includes: at least one of transparency and color value.

In one embodiment, the thread comprises: asynchronous threads.

In one embodiment, the apparatus further comprises:

In one embodiment, the determining module is configured to specifically perform: and reporting the stored FPSs determined in the preset time length to a server, so that the server determines the interface display smoothness of the application program based on the FPSs determined in the preset time length.

In one embodiment, the operating system includes iOS.

In one embodiment, the frame rate FPS detection trigger timer comprises a CADisplayLink.

In one embodiment, the designated interface includes: the CARenderServerGetFramecounter function.

The above is a frame rate detection method and a frame rate detection device disclosed in the embodiments of the present disclosure, and the embodiments of the present disclosure also disclose a frame rate detection system. As shown in fig. 3, there may be a frame rate detection system consisting of: calculator, timmer, manager, forceUpdate, modules, six modules of FPS monitor.

And the Calculator module is used for calling the CARenderServerGetFrameCounter function to acquire the identification of the frames displayed by screen refreshing, calculating the FPS, and storing the identification of all the frames in the appointed time period and the calculated FPS.

And the timer module is used for calling back CADisplayLink once at a frequency of 16.67ms to realize that signals are sent to the Manager at regular time, so that the Manager triggers the Calculator module and the ForceUpdate module at regular time.

And the Manager module is used for transmitting information/instructions between the Manager modules for Calculator, timmer, forceUpdate, modules so as to coordinate the work of each module.

And the ForceUpdate module is used for periodically modifying the attribute value of the appointed display attribute of at least one pixel point arranged in the interface of the screen display so as to forcedly refresh the screen. Details of the foregoing embodiments are described in the foregoing embodiments, and are not repeated here.

The Modules module allows each data demander to inject own instance in a registration mode, so that when the Manager module obtains the frame identification displayed by screen refreshing and the FPS obtained by calculation from the Calculator module, the frame identification and the FPS are counted and aggregated, and then the frame identification and the FPS are distributed to each registered data demander.

And the FPS Monitor module is used for each data demander to Monitor the Modules according to the respective requirements so as to acquire the frame identification and the FPS which are sent by the Modules and matched with the requirements of the data demander.

Wherein the Calculator, timmer, manager, forceUpdate module is bound to the asynchronous thread.

In the embodiment of the disclosure, through the frame rate detection system, the designated interface can be triggered and invoked at fixed time according to the set timing period to acquire the identifiers of all frames refreshed and displayed in the timing period, so that the real FPS is obtained by directly acquiring the identifiers of the frames actually refreshed and displayed to determine the FPS.

Fig. 4 is a schematic hardware architecture diagram of a mobile terminal implementing various embodiments of the present disclosure, where the mobile terminal 300 includes, but is not limited to: radio frequency unit 401, network module 402, audio output unit 403, input unit 404, sensor 405, display unit 406, user input unit 407, interface unit 408, memory 409, processor 410, and power source 411. Those skilled in the art will appreciate that the mobile terminal structure shown in fig. 4 is not limiting of the mobile terminal and that the mobile terminal may include more or fewer components than shown, or may combine certain components, or a different arrangement of components. In the embodiment of the invention, the mobile terminal comprises, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle-mounted terminal, a wearable device, a pedometer and the like.

Wherein the processor 410 is configured to bind the frame rate FPS detection trigger timer to a thread of the application; starting an FPS detection trigger timer, so that the FPS detection trigger timer calls a designated interface according to a set timing period to acquire the identifications of all frames refreshed and displayed in the timing period; the specified interface includes: an identification acquisition interface of a screen refreshing frame provided by an operating system; and determining the FPS according to the number of the identifiers of all frames of the refreshing display acquired in the unit time length.

Memory 409 for storing a computer program executable on processor 410, which, when executed by processor 410, implements the functions implemented by processor 410 as described above.

It should be understood that, in the embodiment of the present invention, the radio frequency unit 401 may be used for receiving and transmitting signals during the process of receiving and transmitting information or communication, specifically, receiving downlink data from a base station and then processing the received downlink data by the processor 410; and, the uplink data is transmitted to the base station. Typically, the radio frequency unit 401 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier, a duplexer, and the like. In addition, the radio frequency unit 401 may also communicate with networks and other devices through a wireless communication system.

The mobile terminal provides wireless broadband internet access to the user through the network module 402, such as helping the user to send and receive e-mail, browse web pages, access streaming media, etc.

The audio output unit 403 may convert audio data received by the radio frequency unit 401 or the network module 402 or stored in the memory 409 into an audio signal and output as sound. Also, the audio output unit 403 may also provide audio output (e.g., a call signal reception sound, a message reception sound, etc.) related to a specific function performed by the mobile terminal 400. The audio output unit 403 includes a speaker, a buzzer, a receiver, and the like.

The input unit 404 is used to receive an audio or video signal. The input unit 404 may include a graphics processor (Graphics Processing Unit, GPU) 4041 and a microphone 4042, the graphics processor 4041 processing image data of still pictures or video obtained by an image capturing device (e.g., a camera) in a video capturing mode or an image capturing mode. The processed image frames may be displayed on the display unit 406. The image frames processed by the graphics processor 4041 may be stored in memory 409 (or other storage medium) or transmitted via the radio frequency unit 401 or the network module 402. The microphone 4042 may receive sound and may be capable of processing such sound into audio data. The processed audio data may be converted into a format output that can be transmitted to the mobile communication base station via the radio frequency unit 401 in the case of a telephone call mode.

The mobile terminal 400 also includes at least one sensor 405, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 4061 according to the brightness of ambient light, and the proximity sensor can turn off the display panel 4061 and/or the backlight when the mobile terminal 400 moves to the ear. As one of the motion sensors, the accelerometer sensor can detect the acceleration in all directions (generally three axes), and can detect the gravity and direction when stationary, and can be used for recognizing the gesture of the mobile terminal (such as horizontal and vertical screen switching, related games, magnetometer gesture calibration), vibration recognition related functions (such as pedometer and knocking), and the like; the sensor 405 may further include a fingerprint sensor, a pressure sensor, an iris sensor, a molecular sensor, a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, etc., which are not described herein.

The display unit 406 is used to display information input by a user or information provided to the user. The display unit 406 may include a display panel 4061, and the display panel 4061 may be configured in the form of a liquid crystal display (Liquid Crystal Display, LCD), an Organic Light-Emitting Diode (OLED), or the like.

The user input unit 407 may be used to receive input numeric or character information and to generate key signal inputs related to user settings and function control of the mobile terminal. Specifically, the user input unit 407 includes a touch panel 4071 and other input devices 4072. The touch panel 4071, also referred to as a touch screen, may collect touch operations thereon or thereabout by a user (e.g., operations of the user on the touch panel 4071 or thereabout using any suitable object or accessory such as a finger, stylus, etc.). The touch panel 4071 may include two parts, a touch detection device and a touch controller. The touch detection device detects the touch azimuth of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends the touch point coordinates to the processor 410, and receives and executes commands sent from the processor 410. In addition, the touch panel 4071 may be implemented in various types such as resistive, capacitive, infrared, and surface acoustic wave. The user input unit 407 may include other input devices 4072 in addition to the touch panel 4071. In particular, other input devices 4072 may include, but are not limited to, a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which are not described in detail herein.

Further, the touch panel 4071 may be overlaid on the display panel 4061, and when the touch panel 4071 detects a touch operation thereon or thereabout, the touch operation is transferred to the processor 410 to determine the type of touch event, and then the processor 410 provides a corresponding visual output on the display panel 4061 according to the type of touch event. Although in fig. 4, the touch panel 4071 and the display panel 4061 are two independent components to implement the input and output functions of the mobile terminal, in some embodiments, the touch panel 4071 may be integrated with the display panel 4061 to implement the input and output functions of the mobile terminal, which is not limited herein.

The interface unit 408 is an interface through which an external device is connected to the mobile terminal 400. For example, the external devices may include a wired or wireless headset port, an external power (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device having an identification module, an audio input/output (I/O) port, a video I/O port, an earphone port, and the like. The interface unit 408 may be used to receive input (e.g., data information, power, etc.) from an external device and transmit the received input to one or more elements within the mobile terminal 400 or may be used to transmit data between the mobile terminal 400 and an external device.

Memory 409 may be used to store software programs as well as various data. The memory 409 may mainly include a storage program area that may store an operating system, application programs required for at least one function (such as a sound playing function, an image playing function, etc.), and a storage data area; the storage data area may store data (such as audio data, phonebook, etc.) created according to the use of the handset, etc. In addition, memory 409 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device.

The processor 410 is a control center of the mobile terminal, connects various parts of the entire mobile terminal using various interfaces and lines, and performs various functions of the mobile terminal and processes data by running or executing software programs and/or modules stored in the memory 409 and calling data stored in the memory 409, thereby performing overall monitoring of the mobile terminal. Processor 410 may include one or more processing units; preferably, the processor 410 may integrate an application processor that primarily handles operating systems, user interfaces, applications, etc., with a modem processor that primarily handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 410.

The mobile terminal 400 may further include a power source 411 (e.g., a battery) for supplying power to the various components, and preferably, the power source 411 may be logically connected to the processor 410 through a power management system, so as to perform functions of managing charging, discharging, and power consumption management through the power management system.

In addition, the mobile terminal 400 includes some functional modules, which are not shown, and will not be described herein.

Preferably, the embodiment of the present invention further provides a mobile terminal, which includes a processor 410, a memory 409, and a computer program stored in the memory 409 and capable of running on the processor 410, where the computer program when executed by the processor 410 implements each process of the above embodiment of the method for detecting a frame rate, and the same technical effects can be achieved, and for avoiding repetition, a detailed description is omitted herein.

The embodiment of the invention also provides a computer readable storage medium, and a computer program is stored on the computer readable storage medium, and the computer program is executed by a processor to realize the method for detecting the frame rate.

The processes of the embodiments can achieve the same technical effects, and in order to avoid repetition, the description is omitted here. Wherein the computer readable storage medium is selected from Read-Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic disk or optical disk.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for detecting a frame rate, comprising:

2. The method of claim 1, wherein starting the FPS detection trigger timer such that the FPS detection trigger timer triggers the thread to invoke a designated interface to obtain an identification of all frames that are refreshed for display within a set timing period, comprising:

3. The method according to claim 2, wherein the method further comprises:

And setting the at least one pixel point with the specified display attribute in the screen display interface.

4. The method of claim 2, wherein the specified display attribute of the pixel comprises: at least one of transparency and color value.

5. The method of claim 1, wherein the thread comprises: asynchronous threads.

6. The method of claim 1, wherein after determining the FPS based on the number of identifications of all frames of the refreshed display acquired per unit length of time, the method further comprises:

storing each FPS determined in a preset time length;

7. The method of claim 6, wherein determining interface display fluency of the application based on the determined FPSs comprises:

and reporting the stored FPSs determined in the preset time length to a server, so that the server determines the interface display smoothness of the application program based on the FPSs determined in the preset time length.

8. The method of any one of claims 1-7, wherein the operating system comprises iOS.

9. A frame rate detection apparatus, comprising:

10. The apparatus of claim 9, wherein the acquisition module comprises:

a modifying unit configured to perform periodic modification of an attribute value of a specified display attribute of at least one pixel point set in an interface of screen display in accordance with a screen regular refresh period; wherein the specified display attribute comprises an attribute related to a display mode of the pixel point in an interface;

11. The apparatus of claim 10, wherein the apparatus further comprises:

12. The apparatus of claim 10, wherein the specified display attribute of the pixel comprises: at least one of transparency and color value.

13. The apparatus of claim 9, wherein the thread comprises: asynchronous threads.

14. The apparatus of claim 9, wherein the apparatus further comprises:

15. The apparatus of claim 14, wherein the determining module is configured to specifically perform: and reporting the stored FPSs determined in the preset time length to a server, so that the server determines the interface fluency of the application program based on the FPSs determined in the preset time length.

16. The apparatus of any one of claims 9 to 15, wherein the operating system comprises iOS.

17. An electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the method of detecting a frame rate as claimed in any one of claims 1 to 8.

18. A storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform the method of detecting a frame rate according to any one of claims 1 to 8.