Android system dynamic frame rate control method and related equipment

Abstract

The invention discloses an Android system dynamic frame rate control method and related equipment, and relates to the technical field of terminal display control, and the method comprises the steps: obtaining a target frame rate parameter set by a user; determining a preset frame rate safety range based on the extended identification data analysis result of the target display hardware; when the target frame rate parameter is within a preset frame rate safety range, generating a dynamic display time sequence configuration parameter according to the target frame rate parameter; a default display strategy is bypassed through a system service layer injection mechanism, and dynamic display time sequence configuration parameters are written into a display controller drive; and monitoring a frame rate deviation value between the actual rendering frame rate of the target display hardware and the target frame rate parameter in real time, and when the frame rate deviation value exceeds a preset deviation value, performing rendering control through a multi-stage compensation mechanism. Through custom frame rate setting, safety range determination based on hardware characteristics, precise time sequence control and a multi-stage compensation optimization mechanism, the safety, real-time performance and energy efficiency performance of Android system frame rate regulation and control can be improved.

Description

Technical Field

[0001] This application relates to the technical field of mobile terminal display control. More specifically, this application relates to an Android system dynamic frame rate control method and related devices. Background Art

[0002] With the continuous improvement of the hardware performance of mobile terminals, users have put forward higher requirements for the smoothness and response speed of the screen display effect. Especially in scenarios such as game entertainment, virtual reality (VR / AR), and high frame rate video playback, the demand for dynamic frame rate control technology is increasing day by day. The traditional Android system usually relies on preset fixed modes (such as 60Hz, 90Hz, or 120Hz) in frame rate control, and the system default display strategy limits the dynamic adjustment ability of the frame rate. This fixed and conservative frame rate control mechanism is difficult to optimize flexibly according to different application loads, user requirements, or hardware characteristics, easily leading to waste of system resources, increased energy consumption, and even rendering delays or stuttering phenomena in high-performance demand scenarios.

[0003] In related technologies, the research on Android system frame rate control mostly focuses on basic frame rate switching or simple adjustments within the system-set range, lacking the ability to analyze the target display hardware characteristics (such as EDID data) to dynamically determine the safe frame rate range; at the same time, at the system architecture level, existing methods are often limited by the display strategy of the system service layer and cannot inject custom timing parameters in real time for underlying driver control; in addition, there is also a lack of an effective multi-level compensation mechanism for the deviation response between the actual rendering frame rate and the target frame rate, resulting in insufficient accuracy, real-time performance, and energy efficiency optimization ability of frame rate control. That is, there are technical problems in the prior art that cannot achieve dynamic safe regulation and fine-grained rendering compensation based on target frame rate parameters. Summary of the Invention

[0004] A series of simplified concepts are introduced in the Summary of the Invention section of this application, which will be further detailed in the Detailed Description section. The Summary of the Invention section of this application does not mean to attempt to define the key features and essential technical features of the claimed technical solution, nor does it mean to attempt to determine the protection scope of the claimed technical solution.

[0005] The Android system dynamic frame rate control method and related devices provided by this application can improve the personalization, security, real-time performance, and energy efficiency performance of Android system frame rate regulation through user-defined frame rate settings, determination of safe ranges based on hardware characteristics, precise timing control implemented by injecting into the system service layer, and multi-level compensation optimization mechanism.

[0006] In a first aspect, the present application provides an Android system dynamic frame rate control method, including: obtaining a target frame rate parameter set by a user; determining a preset frame rate safety range based on the parsing result of the extended identification data of the target display hardware; when the target frame rate parameter is within the preset frame rate safety range, generating dynamic display timing configuration parameters according to the target frame rate parameter; bypassing the default display policy through the system service layer injection mechanism, and writing the dynamic display timing configuration parameters into the display controller driver; and real-time monitoring the frame rate deviation value between the actual rendering frame rate of the target display hardware and the target frame rate parameter, and when the frame rate deviation value exceeds a preset deviation value, performing rendering control through a multi-level compensation mechanism.

[0007] In some embodiments, the determining a preset frame rate safety range based on the parsing result of the extended identification data of the target display hardware includes: parsing the extended display identification data of the target display hardware to obtain the physical range of the vertical synchronization frequency and the physical range of the horizontal synchronization frequency; performing a compression calculation process on the physical range of the vertical synchronization frequency based on a first preset safety margin coefficient to obtain a dynamic vertical frequency allowable interval; performing a compression calculation process on the physical range of the horizontal synchronization frequency based on a second preset safety margin coefficient to obtain a dynamic horizontal frequency allowable interval; and generating the preset frame rate safety range according to the intersection of the dynamic vertical frequency allowable interval and the dynamic horizontal frequency allowable interval, where the upper limit value of the preset frame rate safety range is the maximum value of the intersection, and the lower limit value of the preset frame rate safety range is the minimum value of the intersection.

[0008] In some embodiments, the performing rendering control through a multi-level compensation mechanism includes: when the frame rate deviation value is within a first amplitude interval, increasing the scheduling priority of the rendering thread; when the frame rate deviation value is within a second amplitude interval, switching the rendering buffer queue to a triple buffer mode and dynamically adjusting the GPU clock frequency; when the frame rate deviation value is within a third amplitude interval, reverting to the system default vertical synchronization policy and generating a hardware alarm signal, where the first amplitude interval, the second amplitude interval, and the third amplitude interval are all dynamically divided based on the target frame rate parameter and the response delay characteristics of the target display hardware, and the first amplitude interval, the second amplitude interval, and the third amplitude interval are arranged in ascending order of the deviation amplitude value and have no overlap.

[0009] In some embodiments, the dynamically adjusting the GPU clock frequency includes: generating a GPU clock frequency adjustment instruction through a proportional-integral-derivative control algorithm based on the real-time change rate of the frame rate deviation value to adjust the GPU clock frequency, where the proportional coefficient of the proportional-integral-derivative control algorithm is positively correlated with the absolute value of the frame rate deviation value.

[0010] In some embodiments, bypassing the default display policy through the system service layer injection mechanism and writing the dynamic display timing configuration parameters to the display controller driver includes: intercepting the generation instruction of the default display timing parameters by hooking the display mode callback function of the system display composition service; replacing the default display timing parameters with the dynamic display timing configuration parameters to generate a display mode override instruction, where the display mode override instruction includes a set of dynamic association parameters of the horizontal blanking period, vertical blanking period, and pixel clock division factor corresponding to the target frame rate parameter; sending the display mode override instruction to the kernel layer through the cross-process communication interface to trigger the register writing operation of the display controller driver; and when detecting a write failure event for a continuous preset number of times, canceling the display mode override instruction and restoring the system default vertical synchronization policy.

[0011] In some embodiments, the Android system dynamic frame rate control method further includes: generating a gyroscope angular velocity change rate according to the inertial measurement unit data in the VR / AR scenario; when the gyroscope angular velocity change rate exceeds a preset change rate, increasing the target frame rate parameter to the physical limit frame rate of the target display hardware and locking the rendering buffer queue to the triple buffer mode; and when detecting that the rendering load of continuous N frames is lower than a preset load threshold, decreasing the target frame rate parameter, where the value of N has a negative correlation with the physical limit frame rate.

[0012] In some embodiments, the Android system dynamic frame rate control method further includes: detecting the frame rate request information in the multi-application scenario, where the frame rate request information includes the first frame rate request of the foreground application and the second frame rate request of the background application; when detecting a conflict event between the first frame rate request and the second frame rate request, switching the current display mode of the target display hardware to the target display mode matching the first frame rate request based on the application type priority policy; gradually reducing the rendering frame rate of the background application to a preset energy-saving threshold through the frame rate smoothing attenuation mechanism in the rendering pipeline of the background application; and when detecting that the foreground application exits or switches to the background, restoring the original frame rate request of the background application and recalculating the global display timing parameters to update the system resource allocation policy.

[0013] In a second aspect, the present application further provides an Android system dynamic frame rate control device, including: a parameter acquisition unit configured to acquire a target frame rate parameter set by a user; a safety range determination unit configured to determine a preset frame rate safety range based on a parsing result of extended identification data of a target display hardware; a configuration parameter generation unit configured to generate a dynamic display timing configuration parameter according to the target frame rate parameter when the target frame rate parameter is within the preset frame rate safety range; a driver writing unit configured to bypass a default display policy through a system service layer injection mechanism and write the dynamic display timing configuration parameter into a display controller driver; a rendering control unit configured to monitor in real time a frame rate deviation value between an actual rendering frame rate of the target display hardware and the target frame rate parameter, and perform rendering control through a multi-level compensation mechanism when the frame rate deviation value exceeds a preset deviation value.

[0014] In a third aspect, the present application further provides an electronic device, including: a memory and a processor, where the processor is configured to implement the steps of the Android system dynamic frame rate control method described in the first aspect when executing a computer program stored in the memory.

[0015] In a fourth aspect, the present application further provides a computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the steps of the Android system dynamic frame rate control method described in the first aspect.

[0016] In a fifth aspect, the present application further provides a computer program product, including a computer program or computer executable instructions, where the computer program or computer executable instructions, when executed by a processor, implement the Android system dynamic frame rate control method provided in the embodiments of the present application.

[0017] In summary, by obtaining the target frame rate parameter set by the user, this application allows for flexible customization of the display frame rate according to specific application scenarios (such as games, video playback, reading, etc.), breaking the limitation of the traditional Android system that only fixedly supports limited frame rate modes (such as 60Hz, 90Hz, 120Hz), and enhancing the personalized experience of frame rate control; based on the parsing result of the extended identification data (such as EDID) of the target display hardware, dynamically determine the safe operating range of the frame rate, effectively avoiding hardware abnormalities, screen flashing or damage caused by setting abnormal frame rates, and ensuring that the frame rate adjustment operates safely within the physical support range of the display or panel; through the system service layer injection mechanism, it is possible to bypass the relatively conservative display strategies in the native system (such as SurfaceFlinger or HWC module limitations), directly write the dynamically generated display timing parameters into the display controller driver layer, improving the real-time performance and accuracy of frame rate regulation, reducing system layer interference, and increasing the configuration response speed; by real-time monitoring the deviation between the actual rendering frame rate and the target frame rate parameter, timely respond to changes in system load; and adopt a multi-level compensation mechanism (such as increased scheduling priority, triple buffering enabled, GPU frequency adjustment, forced fallback, etc.) according to the deviation amplitude, which can effectively optimize the rendering performance, alleviate frame dropping and stuttering, and while ensuring a smooth experience, also take into account energy consumption control and extend the device battery life. In summary, the Android system dynamic frame rate control method provided by this application, through user-defined frame rate settings, security range determination based on hardware characteristics, precise timing control achieved through system service layer injection, and multi-level compensation optimization mechanism, improves the personalization, security, real-time performance, and energy efficiency performance of Android system frame rate regulation. Description of the Drawings

[0018] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of this specification. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0019] Figure 1 It is a schematic flowchart of a method for dynamically controlling the frame rate of an Android system provided by an embodiment of this application;

[0020] Figure 2 It is a schematic diagram of the composition structure of a device for dynamically controlling the frame rate of an Android system provided by an embodiment of this application;

[0021] Figure 3 It is a schematic diagram of the composition structure of an electronic device provided by an embodiment of this application. Detailed Embodiments

[0022] The terms in the description, claims and drawings of this application, such as "first", "second", "third", "fourth", etc. (if any), are used to distinguish similar objects, rather than to describe a specific order or sequence. Therefore, it is understood that under appropriate circumstances, these terms can be used interchangeably, so that the described embodiments can be in a different order, unless there are special requirements in the drawings or description. In addition, the terms "is" and "has" in this application and any of their variants are intended to non-exclusively cover all possible constituent elements. For example, a process, method, system, product or device that includes several steps or units does not have to be limited to the steps or units that are clearly listed, but may also include other steps or units that are not clearly listed, or steps or units that are inherent to the process, method, product or device.

[0023] In this application, a "module" or "unit" refers to a computer program or a part of a computer program with a specific function, and works in cooperation with other relevant parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (such as a processing circuit or a memory), or a combination of both. One or more processors or memories can implement one or more modules or units. At the same time, each module or unit can also be a part of a larger module or unit.

[0024] The technical solutions in this application will be described in detail below with reference to the drawings in the embodiments. It should be noted that the described embodiments are only a part of this application, rather than all embodiments. In the following description, the "some embodiments" mentioned are only subsets of all possible embodiments, which can be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0025] Figure 1 is a schematic flowchart of a method for dynamically controlling the frame rate of an Android system provided by an embodiment of this application. Exemplarily, see Figure 1 The method for dynamically controlling the frame rate of the Android system provided by the embodiment of this application may include the following S110 to S150:

[0026] S110, obtain the target frame rate parameter set by the user;

[0027] In some examples, the target frame rate parameter is the frame rate value (unit: Hz) that the user or application program sets for the display hardware to run; the target frame rate parameter is used to indicate that the system adjusts the screen refresh frequency to a specified value to match different application requirements (such as high-frame games, reading for energy saving, etc.); for example, the user sets the target frame rate to 90 Hz in the game mode and 48 Hz in the e-book reading mode.

[0028] Exemplarily, in the system settings interface, the user can operate through a dedicated frame rate setting entry. This entry provides an EditTextPreference component for entering the target frame rate value, and is accompanied by a SwitchPreference switch control to turn the frame rate setting on or off. When the user turns on the switch and enters the desired frame rate value in the input box, such as entering "90" when playing a high-frame-rate game, and clicks the confirmation button, the system then obtains this target frame rate parameter. At this time, the system calls the applyForceRefreshRate() method, passing the "90Hz" entered by the user as a parameter, and then initiates the subsequent frame rate adjustment process.

[0029] Through the implementation of S110, it is allowed to flexibly customize the display frame rate according to different application scenarios (such as games, videos, reading, etc.), breaking the limitations of the fixed frame rate mode of traditional Android systems, which can enhance the flexibility of frame rate control and the personalized experience, and improve user satisfaction.

[0030] S120, based on the parsing result of the extended identification data of the target display hardware, determines the preset frame rate safety range;

[0031] In some examples, the target display hardware refers to the specific display device currently connected for image output, such as a mobile phone screen, an external monitor, a VR headset, etc.; the target display hardware is the object of the frame rate adjustment operation, and its hardware characteristics (such as the highest supported refresh rate, synchronization signal range) directly affect the feasible frame rate setting; for example, the target display hardware can be an OLED screen supporting a refresh rate change range of 60Hz - 144Hz. The parsing result of the extended identification data is a set of parameters obtained by parsing the extended display identification data (such as EDID, Extended Display Identification Data) provided by the display device, which can be used to obtain information such as the synchronization frequency range, resolution ability, and maximum and minimum refresh rates supported by the display device, providing a basis for subsequent frame rate safety range judgment; for example, by parsing the EDID data, it is obtained that the vertical synchronization frequency supported by the target screen is 48Hz - 144Hz, and the horizontal synchronization frequency is 30kHz - 160kHz. The preset frame rate safety range is the allowable frame rate interval determined based on the parsing result of the extended identification data and adjusted by the safety margin; it is used to prevent the target frame rate from exceeding the hardware safe operating range and protect the stable operation of the display; for example, after parsing, it is determined that the screen safety frame rate interval is 50Hz - 140Hz, and setting below 50Hz or above 140Hz will trigger the protection mechanism.

[0032] Exemplarily, by parsing the EDID data of the display, the vertical synchronization frequency range is obtained as 48Hz - 144Hz, and the horizontal synchronization frequency range is 30kHz - 160kHz. Combining with the preset safety threshold (such as ±5%), the preset frame rate safety range is calculated. Taking the vertical synchronization frequency as an example, the lower limit is 48Hz * (1 - 5%) = 45.6Hz, rounded up to 50Hz; the upper limit is 144Hz * (1 + 5%) = 151.2Hz, rounded down to 140Hz. So the finally determined preset frame rate safety range is 50Hz - 140Hz. If the target frame rate set by the user is 150Hz, which exceeds this safety range, the system will automatically pop up a prompt box to inform the user that the currently set frame rate exceeds the safety range and recommend the closest optional value of 140Hz.

[0033] By implementing S120, the characteristic data of the display hardware is parsed to ensure that the frame rate adjustment operation is always within the hardware safety range, which can effectively prevent problems such as screen flickering, black screen, or hardware damage caused by setting abnormal frame rates, and improve system stability and hardware protection.

[0034] S130, when the target frame rate parameter is within the preset frame rate safety range, generate dynamic display timing configuration parameters according to the target frame rate parameter;

[0035] In some examples, the dynamic display timing configuration parameters are a set of hardware parameter sets related to the display timing dynamically generated according to the target frame rate, usually including horizontal / vertical synchronization duration, blanking period, pixel clock, etc.; the dynamic display timing configuration parameters can be used to drive the display controller to work at the new target frame rate to ensure stable and correct display output; for example, when the target frame rate is 90Hz, the dynamically generated horizontal blanking time is 88 pixel clocks, the vertical blanking time is 4 lines, and the pixel clock division coefficient is a specific value.

[0036] Exemplarily, after determining that the user-set target frame rate of 90Hz is within the preset frame rate safety range, the dynamic display timing configuration parameters are started to be generated. First, a CustomMode object is created, and information such as the target frame rate of 90Hz, the horizontal display parameters (such as the number of pixel clocks corresponding to the horizontal synchronization duration) and vertical display parameters (such as the number of lines corresponding to the vertical synchronization duration) determined according to the hardware characteristics are encapsulated into this object. Then, by hooking the displayModeChanged callback function of the system SurfaceFlinger service, the parameters in the CustomMode object are injected, bypassing the system's default display mode selection strategy, and these parameters are directly written into the display controller driver, such as executing the display_ioctl(SET_DYNAMIC_REFRESH_RATE) command to make the display controller work according to the new timing parameters to achieve a frame rate display of 90Hz.

[0037] Through the implementation of S130, matching display timing parameters are dynamically generated, enabling the frame rate adjustment to be highly adapted to specific hardware characteristics, ensuring the stability of the display timing, and at the same time improving the response speed and accuracy of the system to different target frame rate switches.

[0038] S140 bypasses the default display policy through the system service layer injection mechanism and writes the dynamic display timing configuration parameters into the display controller driver.

[0039] In some examples, the system service layer injection mechanism is a technical means of inserting custom code or Hook callbacks at the system service (such as SurfaceFlinger, DisplayService, etc.) layer; the system service layer injection mechanism allows bypassing the Android default frame rate policy and enforcing custom-generated display parameters, enhancing the flexibility of frame rate adjustment; for example, through the injection mechanism, the 60Hz timing settings originally allocated by the system can be intercepted and replaced with dynamically generated 75Hz timing parameters. The default display policy is the display control policy natively set by the Android system, including limiting the support for fixed refresh rates (such as 60Hz, 90Hz, 120Hz) and automatically switching according to the system state (power saving, load, etc.); the default display policy usually aims to balance compatibility and power consumption, with limited flexibility. The display controller driver is the underlying driver (Kernel Driver layer) that controls the actual output timing signal of the screen and is responsible for writing the set display timing parameters into the registers of the display hardware, directly affecting the refresh behavior of the display; for example, the msm-dsi-display.c file in the kernel state is used to control the screen refresh rate of the Qualcomm platform.

[0040] Exemplarily, the injection operation is performed through the newly added FrameRateController service in the framework layer. This service inherits from IBinder and has the ability to interact with other system services. When it is necessary to bypass the default display policy, the FrameRateController service will perform a key operation of calling the displayModeChanged callback function of the Hook system SurfaceFlinger service. Suppose the current system default policy sets the screen refresh rate to 60Hz, but the target frame rate set by the user is 75Hz, and the corresponding dynamic display timing configuration parameters have been generated. At this time, the FrameRateController service modifies the mActiveMode attribute of SurfaceFlinger through a Binder call and injects the custom 75Hz dynamic display timing configuration parameters into it. Then, the system will execute the display_ioctl(SET_DYNAMIC_REFRESH_RATE) command and directly write these parameters into the display controller driver (such as the driver controlled by the msm-dsi-display.c file corresponding to the Qualcomm platform). After receiving the parameters, the display controller driver will write them into the registers of the display hardware, such as the DISPLAY_TIMING_CTRL register, so that the display refreshes at a frame rate of 75Hz, successfully bypassing the default 60Hz display policy.

[0041] Through the implementation of S140, by bypassing the restrictions of the Android native display layer and directly acting on the display controller driver, it is possible to achieve higher-precision and lower-latency frame rate control, improving the real-time performance of display adjustment and the degree of freedom of system regulation.

[0042] S150, real-time monitor the frame rate deviation value between the actual rendering frame rate of the target display hardware and the target frame rate parameter. When the frame rate deviation value exceeds the preset deviation value, perform rendering control through a multi-level compensation mechanism;

[0043] In some examples, the actual rendering frame rate is the number of frames of images that the system actually renders and submits to the screen at the current time (unit: fps), which can reflect the actual effects such as the current GPU / CPU load, rendering complexity, and system scheduling. For example, in a game scenario, even if the target is set to 90 fps, due to high system load, the actual rendering frame rate may only be 75 fps. The frame rate deviation value is the difference between the target frame rate and the actual rendering frame rate (which can be an absolute value or a relative value), and is used to dynamically evaluate whether the system performance and display effect meet the expectations to trigger compensation adjustment. For example, if the target frame rate is 90 fps and the actual rendering frame rate is 80 fps, the deviation value is 10 fps. The preset deviation value is the tolerance range preset by the system, which is used to judge whether there is an abnormal deviation between the actual rendering frame rate and the target frame rate, and can be used as the judgment threshold for triggering the compensation mechanism to avoid frequent and meaningless adjustments. For example, the system sets the preset deviation value to ±5 fps, and the rendering compensation is only started when it exceeds this range. According to different degrees of frame rate deviation, hierarchical adjustment means are adopted (such as scheduling optimization, cache mechanism adjustment, frequency increase or fallback protection); it can not only optimize slightly in case of mild deviation, but also protect the system stability in time in case of serious abnormality, taking into account both fluency and energy consumption.

[0044] Exemplarily, the actual rendering frame rate is collected in real time through a frame rate monitoring service, which reads the actual frame rate data from / sys / class / display / fps every 100 ms. For example, in a complex 3D game scene where the target frame rate is set to 90 fps, during the game operation, the frame rate monitoring service obtains the actual rendering frame rate at a certain moment as 80 fps, and the calculated frame rate deviation value at this time is 10 fps. Since the system preset deviation value is ±5 fps, 10 fps exceeds the preset range, triggering a multi-level compensation mechanism. First, the process scheduler of the system elevates the priority of the rendering thread through the Linux CFS scheduler. For example, the nice value of the rendering thread is adjusted from 0 to -20, so that the rendering task can obtain system resources preferentially and speed up the rendering speed. At the same time, the GPU frequency controller dynamically adjusts the GPU operating frequency according to the frame rate deviation value, based on the PID control algorithm (the proportional coefficient Kp ranges from 0.8 to 1.2, the integral time Ti is 200 - 300 ms, and the differential time Td is 50 - 100 ms). If the deviation persists and the preset deviation value is exceeded in three consecutive samples, the system will enable the triple buffering mechanism, and the rendering pipeline management module will switch the number of BufferQueue buffers from double buffering to triple buffering to reduce screen tearing and stuttering. If after a series of adjustments, the frame rate deviation still does not return to the preset range and the number of consecutive overlimit times reaches 3 times, the system will perform the operation of the safe frame rate fallback, call setDisplayModeOverride(null), force the system to restore the default VSync policy, avoid system instability caused by abnormal frame rates, and at the same time pop up a window through the user notification module to prompt the user "The frame rate instability has been reverted".

[0045] Through the implementation of S150, by using real-time monitoring and multi-level compensation (such as elevation of scheduling priority, enabling triple buffering, GPU frequency adjustment, reverting to the default policy, etc.), it is possible to effectively alleviate the stuttering and frame dropping phenomena caused by load fluctuations, balance performance smoothness and energy consumption control, and further improve system stability and user experience.

[0046] In summary, in the embodiments of the present application, by obtaining the target frame rate parameter set by the user, it is allowed to flexibly customize the display frame rate according to specific application scenarios (such as games, video playback, reading, etc.), breaking the limitation of the traditional Android system that only fixedly supports a limited frame rate mode (such as 60Hz, 90Hz, 120Hz), and enhancing the personalized experience of frame rate control; based on the parsing result of the extended identification data (such as EDID) of the target display hardware, the safe operating range of the frame rate is dynamically determined, effectively avoiding hardware anomalies, screen flickering or damage caused by setting abnormal frame rates, and ensuring that the frame rate adjustment operates safely within the physical support range of the display or panel; through the system service layer injection mechanism, it is possible to bypass the relatively conservative display strategies in the native system (such as SurfaceFlinger or HWC module limitations), directly write the dynamically generated display timing parameters into the display controller driver layer, improving the real-time performance and accuracy of frame rate regulation, reducing system layer interference, and improving the configuration response speed; by real-time monitoring the deviation between the actual rendering frame rate and the target frame rate parameter, timely responding to changes in system load; and adopting a multi-level compensation mechanism (such as scheduling priority improvement, triple buffering enabling, GPU frequency adjustment, forced fallback, etc.) according to the deviation amplitude, it is possible to effectively optimize the rendering performance, alleviate frame drop and stuttering, and while ensuring a smooth experience, also take into account power consumption control and extend the device battery life. In summary, the Android system dynamic frame rate control method provided by the embodiments of the present application improves the personalization, security, real-time performance and energy efficiency performance of Android system frame rate regulation through user-defined frame rate settings, safe range determination based on hardware characteristics, precise timing control implemented by system service layer injection, and multi-level compensation optimization mechanism.

[0047] In some embodiments, the foregoing S120 may include: parsing the extended display identification data of the target display hardware to obtain the physical range of the vertical synchronization frequency and the physical range of the horizontal synchronization frequency; performing compression calculation processing on the physical range of the vertical synchronization frequency based on a first preset safety margin coefficient to obtain a dynamic vertical frequency allowable interval; performing compression calculation processing on the physical range of the horizontal synchronization frequency based on a second preset safety margin coefficient to obtain a dynamic horizontal frequency allowable interval; generating a preset frame rate safety range according to the intersection of the dynamic vertical frequency allowable interval and the dynamic horizontal frequency allowable interval, wherein the upper limit value of the preset frame rate safety range is the maximum value of the intersection, and the lower limit value of the preset frame rate safety range is the minimum value of the intersection.

[0048] Specifically, parsing the Extended Display Identification Data (EDID) of the target display hardware is a key step in obtaining the basic information of the display hardware. Through a specific parsing algorithm, the physical range of the vertical synchronization frequency and the physical range of the horizontal synchronization frequency are extracted from the EDID data structure. These two ranges define the synchronization frequency boundaries supported by the display hardware under ideal conditions. When performing compression calculation processing on the physical range of the vertical synchronization frequency based on the first preset safety margin coefficient, usually the upper and lower limits of the physical range of the vertical synchronization frequency are respectively operated with the first preset safety margin coefficient. For example, if the physical range of the vertical synchronization frequency is [Vmin, Vmax] and the first preset safety margin coefficient is α, then the lower limit of the allowable interval of the dynamic vertical frequency is Vmin * (1 + β) (β is the coefficient considering the lower limit compression, related to α and the value is ensured to be within the safe range), and the upper limit is Vmax * (1 - α), which can provide a safe frequency interval for frame rate setting in the vertical direction. Similarly, based on the second preset safety margin coefficient, a similar process is performed on the physical range of the horizontal synchronization frequency to obtain the allowable interval of the dynamic horizontal frequency. After obtaining the allowable interval of the dynamic vertical frequency and the allowable interval of the dynamic horizontal frequency, the intersection of the two is taken to generate the preset frame rate safety range. This is because only the frame rate that meets the frequency requirements in both the vertical and horizontal directions can be stably supported by the hardware. The maximum value of the intersection is used as the upper limit value of the preset frame rate safety range, and the minimum value is used as the lower limit value, thus accurately defining the safe frame rate range.

[0049] Exemplarily, assume that after parsing the EDID data of a certain OLED screen, the physical range of the vertical synchronization frequency is obtained as 48 Hz - 144 Hz, and the physical range of the horizontal synchronization frequency is 30 kHz - 160 kHz. Set the first preset safety margin coefficient to 5%, and the second preset safety margin coefficient is also 5%. Perform compression calculation on the physical range of the vertical synchronization frequency. The lower limit is 48 Hz * (1 + 0.02) = 48.96 Hz, rounded up to 49 Hz (here 0.02 is the adjustment coefficient calculated based on the 5% safety margin coefficient for the lower limit to ensure that the lower limit is within the safe range). The upper limit is 144 Hz * (1 - 0.05) = 136.8 Hz, rounded down to 136 Hz. So the allowable range of the dynamic vertical frequency is 49 Hz - 136 Hz. Process the physical range of the horizontal synchronization frequency. Since its unit is kHz, first convert it to Hz for calculation. 30 kHz is 30000 Hz, and 160 kHz is 160000 Hz. The lower limit is 30000 Hz * (1 + 0.02) = 30600 Hz, rounded up to 30600 Hz. The upper limit is 160000 Hz * (1 - 0.05) = 152000 Hz, rounded down to 152000 Hz. The allowable range of the dynamic horizontal frequency is approximately 30.6 kHz - 152 kHz after converting back to kHz. The minimum value of the intersection of the two (corresponding to the lower limit of the frame rate) is determined jointly by the vertical frequency range and the horizontal frequency range (in actual hardware, there is an association relationship between frequencies, and the minimum frame rate value of the intersection is determined according to the corresponding relationship. Assume it is 50 Hz here). The maximum value of the intersection (corresponding to the upper limit of the frame rate) is assumed to be 130 Hz. Then the finally generated preset frame rate safety range is 50 Hz - 130 Hz. If the target frame rate set by the user is within this range, the system will allow the setting and perform subsequent processing; if it exceeds this range, the system will prompt the user to reset an appropriate frame rate.

[0050] Through the implementation of the above embodiments, deeply analyze the display hardware extension identification data, and introduce the safety margin compression calculation method to dynamically generate the effective working range of the frame rate, which can accurately avoid problems such as screen flashing, display failure, or hardware damage caused by setting the frame rate exceeding the hardware limit, thereby enhancing the applicability, safety, and stability of the frame rate control scheme.

[0051] In some embodiments, the foregoing rendering control through the multi-level compensation mechanism may include: when the frame rate deviation value is within the first amplitude range, increasing the scheduling priority of the rendering thread; when the frame rate deviation value is within the second amplitude range, switching the rendering buffer queue to the triple buffer mode and dynamically adjusting the GPU clock frequency; when the frame rate deviation value is within the third amplitude range, reverting to the system default vertical synchronization policy and generating a hardware warning signal, where the first amplitude range, the second amplitude range, and the third amplitude range are all dynamically divided based on the target frame rate parameter and the response latency characteristics of the target display hardware, and the first amplitude range, the second amplitude range, and the third amplitude range are arranged in ascending order of the deviation amplitude value and have no overlap.

[0052] Specifically, the frame rate deviation value between the actual rendering frame rate and the target frame rate parameter can be calculated in real time. When the frame rate deviation value is within the first amplitude range, in order to improve the rendering efficiency, the system's process scheduler will intervene. The process scheduler adjusts the scheduling priority of the rendering thread through the Linux CFS scheduler. For example, the nice value of the rendering thread is adjusted from the default 0 to -20, so that the rendering thread can obtain a higher priority in the system resource allocation, and preferentially obtain system resources such as the CPU, thereby accelerating the rendering speed and making the actual rendering frame rate as close as possible to the target frame rate.

[0053] When the frame rate deviation value is within the second amplitude range, it means that the frame rate deviation is relatively large, and only increasing the thread priority may not meet the requirements. At this time, the system will take two measures simultaneously: on the one hand, the rendering pipeline management module will switch the rendering buffer queue from the current mode to the triple buffer mode. The triple buffer mode increases the number of buffers, which can effectively reduce screen tearing and stuttering phenomena and improve the smoothness of the display; on the other hand, the GPU frequency controller will dynamically adjust the GPU clock frequency based on the frame rate deviation value through the PID control algorithm. For example, when the deviation value is large, the GPU clock frequency is appropriately increased to enhance the rendering ability of the GPU to increase the actual rendering frame rate.

[0054] When the frame rate deviation value is within the third amplitude range, it indicates that the frame rate deviation is already very serious, which may affect the system stability and user experience. At this time, the system will perform the operation of reverting to the system default vertical synchronization policy, call the setDisplayModeOverride(null) function to restore to the system default vertical synchronization setting, and ensure the basic stability of the display. At the same time, the system will generate a hardware warning signal and inform the user in the form of a pop-up window through the user notification module, such as displaying "The frame rate instability has been restored to the default mode", so that the user can know the current system status.

[0055] The division of the first amplitude range, the second amplitude range, and the third amplitude range here is not fixed, but is dynamically determined based on the target frame rate parameter and the response delay characteristics of the target display hardware. When the target frame rate is relatively high, the tolerance for frame rate deviation is relatively low, and the ranges of each amplitude range will be adjusted accordingly; different display hardware with different response delay characteristics will also affect the division of the amplitude range to ensure that the compensation mechanism can more accurately adapt to different hardware and frame rate settings.

[0056] Exemplarily, assume that the target frame rate parameter is 90Hz. In a certain game scenario, the system monitors in real time that the actual rendering frame rate is 85Hz, and calculates that the frame rate deviation value is 5Hz. After judgment, 5Hz is within the first amplitude range (for example, the first amplitude range is set to a deviation value between ±3Hz and ±5Hz), and the process scheduler of the system immediately adjusts the nice value of the rendering thread from 0 to -20. After adjusting the priority, the rendering thread obtains more system resources, and the actual rendering frame rate gradually increases.

[0057] As the complexity of the game scenario increases, the actual rendering frame rate drops to 75Hz. At this time, the frame rate deviation value is 15Hz, which is within the second amplitude range (assuming the second amplitude range is set to a deviation value between ±5Hz and ±15Hz). The rendering pipeline management module of the system switches the rendering buffer queue from the double-buffer mode to the triple-buffer mode. At the same time, the GPU frequency controller starts the PID control algorithm, calculates the adjustment amount according to the deviation value of 15Hz. Assume that the GPU clock frequency is increased by a certain value (such as 50MHz calculated according to the PID algorithm), so that the GPU rendering ability is enhanced, and the actual rendering frame rate begins to rise.

[0058] If the game scenario further becomes extremely complex, the actual rendering frame rate drops suddenly to 60Hz, and the frame rate deviation value reaches 30Hz, which is within the third amplitude range (assuming the third amplitude range is set to a deviation value greater than ±15Hz). The system quickly performs a rollback operation, calls setDisplayModeOverride(null), and restores to the system default vertical synchronization policy, such as restoring the screen refresh rate to 60Hz. At the same time, the system pops up a window to prompt the user "The frame rate instability has been restored to the default mode", informing the user of the current system status, avoiding system crashes or serious display problems caused by abnormal frame rates, and ensuring the stability of the system.

[0059] Through the implementation of the above embodiments, a multi-level compensation strategy based on the deviation amplitude is constructed, which can adopt hierarchical response means for different degrees of frame rate deviation situations, such as thread scheduling optimization, buffer mechanism switching, and rollback protection mechanism, etc., effectively taking into account system performance, energy consumption, and stability, and improving the robustness and adaptability of the frame rate control algorithm in dynamic operation scenarios.

[0060] In some embodiments, the aforementioned dynamic adjustment of the GPU clock frequency may include: generating a GPU clock frequency adjustment instruction through a proportional-integral-derivative control algorithm based on the real-time change rate of the frame rate deviation value to adjust the GPU clock frequency, wherein the proportional coefficient of the proportional-integral-derivative control algorithm is positively correlated with the absolute value of the frame rate deviation value.

[0061] Specifically, when the proportional-integral-derivative (PID) control algorithm adjusts the GPU clock frequency, it will obtain the real-time change rate of the frame rate deviation value in real time. The proportional link will multiply the corresponding proportional coefficient according to the magnitude of the frame rate deviation value to make a preliminary adjustment quickly. Since the proportional coefficient is positively correlated with the absolute value of the frame rate deviation value, when the deviation value is large, the proportional coefficient will also increase, enabling the GPU clock frequency to be adjusted rapidly in the direction that is conducive to reducing the deviation. For example, if the current frame rate deviation value is large, the proportional coefficient will become larger accordingly, causing a large increase in the GPU clock frequency and quickly improving the rendering ability of the GPU.

[0062] The integral link will calculate the integral of the frame rate deviation value over a period of time to eliminate the steady-state error of the system. By continuously accumulating the deviation, the integral link can continuously adjust the GPU clock frequency in the case of a long-term existing deviation, gradually making the actual frame rate approach the target frame rate. Even if the proportional link has made a large adjustment, but if there is still a certain steady-state deviation, the integral link will play a role and continuously correct this deviation.

[0063] The derivative link predicts the change trend of the deviation based on the real-time change rate of the frame rate deviation value. If the deviation value changes rapidly, the derivative link will output a large adjustment amount to adjust the GPU clock frequency in advance to prevent the deviation from further expanding. For example, when it is found that the frame rate deviation value is increasing rapidly, the derivative link will quickly increase the GPU clock frequency to cope with the upcoming larger deviation. By integrating the functions of these three links, a GPU clock frequency adjustment instruction is generated, thereby accurately adjusting the GPU clock frequency and reasonably controlling the power consumption of the GPU while ensuring the rendering performance.

[0064] Exemplarily, assume that in a scenario of running a high-quality 3D game, the target frame rate is set to 120 Hz. At the beginning of the game, the scene is relatively simple, and the actual frame rate is stable at 115 Hz. At this time, the frame rate deviation value is 5 Hz, and the real-time change rate of the deviation value is small. Since the proportional coefficient is positively correlated with the absolute value of the frame rate deviation value, according to the preset relationship between the proportional coefficient and the deviation value, the proportional coefficient takes a small value at this time, such as 0.8. The adjustment amount calculated by the proportional link is small, resulting in a relatively small increase in the GPU clock frequency.

[0065] As the game progresses to complex scenes, monsters and special effects increase, the actual frame rate drops rapidly to 100Hz, the frame rate deviation value becomes 20Hz, and the real-time change rate of the deviation value increases negatively (that is, the actual frame rate drops faster). At this time, the proportional coefficient increases as the absolute value of the deviation value increases, assuming it becomes 1.0. Based on this larger proportional coefficient and deviation value, the proportional link outputs a larger adjustment amount to quickly increase the GPU clock frequency. At the same time, the integral link begins to accumulate previous deviations, gradually increasing the adjustment amount, and further increasing the GPU clock frequency. Based on the rapid change of the deviation value, the differential link predicts that the deviation will continue to increase, and also outputs a larger adjustment amount, which greatly increases the GPU clock frequency, thereby rapidly improving the GPU's rendering capabilities and allowing the actual frame rate to approach the target frame rate of 120Hz as soon as possible.

[0066] When the scene complexity decreases, the actual frame rate returns to 118Hz, the deviation value becomes 2Hz, and the real-time change rate of the deviation value decreases in a positive direction (that is, the actual frame rate rises gradually slows down). The proportional coefficient decreases accordingly, for example, it becomes 0.6, the adjustment amount output by the proportional link becomes smaller, and the increase in the GPU clock frequency decreases. The integral link continues to fine-tune according to the accumulated deviation, and the differential link outputs a smaller adjustment amount according to the smaller rate of change of the deviation value, avoiding excessive increase in the GPU clock frequency, achieving a balance between GPU power consumption and performance, ensuring the smoothness of the game screen, and also controlling the GPU power consumption.

[0067] Through the implementation of the above embodiments, a proportional-integral-derivative control algorithm is introduced to dynamically adjust the GPU frequency, which not only achieves an intelligent balance between GPU power consumption and performance, but also improves the response efficiency and adjustment accuracy of the frame rate control system to sudden deviations, thereby further optimizing the energy efficiency and real-time performance of the overall rendering system.

[0068] In some embodiments, the aforementioned S140 may include: intercepting the generation instruction of the default display timing parameters by hooking the display mode callback function of the system display synthesis service; replacing the aforementioned default display timing parameters with dynamic display timing configuration parameters to generate a display mode override instruction, wherein the display mode override instruction may include a dynamically associated parameter set of the horizontal blanking period, vertical blanking period and pixel clock division coefficient corresponding to the target frame rate parameters; sending the display mode override instruction to the kernel layer through the cross-process communication interface to trigger the register write operation driven by the display controller; when a preset number of consecutive write failure events are detected, releasing the display mode override instruction and restoring the system default vertical synchronization policy.

[0069] Specifically, when executing step S140, the Hook technology is first used to intervene in the display mode callback function of the system display synthesis service (such as the SurfaceFlinger service). The Hook technology is like inserting a custom code into the normal operation process of the system, so that when the system executes the display mode callback function, it will first execute our custom code logic. Through this custom code, the generation instruction of the default display timing parameters can be intercepted, and the default display timing parameter information that the system originally wanted to generate can be obtained.

[0070] Next, replace these default display timing parameters with the dynamic display timing configuration parameters generated previously based on the target frame rate parameters. During the replacement process, the display mode override instructions containing dynamically associated parameter sets such as horizontal blanking period, vertical blanking period, and pixel clock division factor are regenerated based on the hardware characteristics corresponding to the target frame rate parameters. These parameters are key settings to ensure that the display can display stably at the target frame rate.

[0071] After the display mode override instruction is generated, the instruction is sent to the kernel layer with the help of the cross-process communication interface (such as the Binder mechanism). After receiving the instruction, the kernel layer triggers the display controller driver to perform a register write operation and writes the new display timing parameters into the register of the display controller, such as the DISPLAY_TIMING_CTRL register, thereby changing the refresh frequency and timing of the display to achieve the target frame rate display.

[0072] During this process, the system will monitor the register write operation results driven by the display controller in real time. If a preset number of consecutive write failure events (for example, 3 times) are detected, it means that there may be hardware compatibility issues or other abnormal conditions. At this time, the system will automatically release the previously set display mode override command and restore the system default vertical synchronization policy to ensure the normal operation of the system's basic display functions and avoid abnormal settings that cause the display to malfunction or other failures.

[0073] For example, the onDisplayModeChanged callback function pointer of the SurfaceFlinger service can be modified by dynamically loading the Hook library to intercept the system's default display mode generation process. When the system attempts to generate the default display timing parameters (such as VBlank=1600 lines and HTotal=2200 lines corresponding to 60Hz), the Hook module calls the FrameRateController.getCustomTiming() method to replace the dynamically generated timing parameters (such as VBlank=1200 lines and HTotal=1800 lines corresponding to the target 90Hz) with the DisplayMode object to generate a display mode override instruction. The instruction is sent to the kernel layer through the Binder cross-process communication interface, triggering the ioctl system call driven by the DisplayDriver, executing the SET_DYNAMIC_REFRESH_RATE command, and writing the timing parameters to the DISPLAY_TIMING_CTRL register group of the display controller. During the driver writing process, the system detects the register status by polling the / sys / class / display / status node. If the STATUS_WRITE_FAIL flag is detected three times in a row, the DisplayManager.fallbackToDefault() method is called to release the custom mode and restore the default vertical synchronization policy of SurfaceFlinger. At the same time, the error code ERR_DRV_WRITE_RETRY is recorded through EventLog.

[0074] Through the implementation of the above embodiment, the injection mechanism of the system service layer is used to bypass the default display policy, and the dynamic configuration is accurately written into the driver register through Hook callback, parameter replacement and cross-process communication technology, thereby realizing the complete link of frame rate control from the user layer to the kernel layer, significantly improving the effectiveness speed and execution success rate of control instructions; at the same time, it has fault detection and automatic rollback capabilities, enhancing system stability and fault tolerance.

[0075] In some embodiments, the aforementioned Android system dynamic frame rate control method may further include: generating a gyroscope angular velocity change rate based on the inertial measurement unit data in the VR / AR scenario; when the gyroscope angular velocity change rate exceeds a preset change rate, increasing the target frame rate parameter to the physical limit frame rate of the target display hardware, and locking the rendering buffer queue to triple buffering mode; when it is detected that the rendering load of N consecutive frames is lower than a preset load threshold, lowering the target frame rate parameter, wherein the value of N is negatively correlated with the physical limit frame rate.

[0076] Specifically, during the operation of VR / AR scenes, the data of the inertial measurement unit (IMU) can be continuously obtained, which includes the raw data of the gyroscope. By analyzing and calculating the data collected by the gyroscope at different time points, the gyroscope angular velocity change rate is obtained. This change rate reflects the speed of the user's head rotation.

[0077] When the gyroscope angular velocity change rate exceeds the preset change rate, a series of actions will be taken to provide users with a smoother and more immersive experience. First, the target frame rate parameter will be increased to the physical limit frame rate of the target display hardware. This means that the screen refresh rate will be increased as much as possible, so that the picture can be updated more quickly and reduce the visual delay caused by rapid head rotation. At the same time, the system will lock the rendering buffer queue to triple buffering mode. Triple buffering mode can effectively reduce screen tearing and stuttering, and ensure stable image output at high frame rates.

[0078] During the rendering process, the rendering load is also monitored in real time. When it is detected that the rendering load of N consecutive frames is lower than the preset load threshold, it indicates that the current system resources are somewhat idle, and the target frame rate parameters will be lowered at this time. The value of N here is negatively correlated with the physical limit frame rate, because when the physical limit frame rate is higher, it is more sensitive to frame rate changes and consumes more resources. Therefore, when a lower rendering load is detected, the frame rate needs to be reduced faster to save energy. At this time, the value of N will be relatively small; conversely, when the physical limit frame rate is lower, the value of N will be relatively large.

[0079] For example, when the angular velocity change rate exceeds a preset threshold (such as 150° / s 2 ), trigger the high-speed mode switching process:

[0080] Frame rate improvement: Call DisplayManager.setMaxPhysicalRate() to increase the target frame rate parameter to the physical limit of the display hardware (such as 144Hz), and regenerate matching timing parameters through TimingGenerator (such as shortening the vertical blanking period to 800 lines);

[0081] Buffer optimization: Force the render buffer queue to be locked in triple buffering mode, dynamically allocate the third buffer via BufferQueue.setMaxDequeuedBuffers(3), and set the async flag to achieve non-blocking rendering submission;

[0082] Load Detection: Monitor the rendering load of consecutive N frames (such as shader execution time, vertex processing volume) through GPUProfiler. If the load of consecutive N frames is detected to be lower than the preset threshold (such as GPU utilization < 20%), then dynamically adjust the value of N according to the formula N = max(3, 10 - (physical_max_fps / 30)) (such as N = 5 frames at 144Hz), and then gradually reduce the target frame rate to the reference value (such as 90Hz). This mechanism achieves a balance between high responsiveness and low power consumption through the dynamic matching of hardware performance and scene requirements.

[0083] Through the implementation of the above embodiments, combined with the dynamic characteristics of VR / AR scenarios, introducing the gyroscope angular velocity change rate as the frame rate adjustment trigger factor can actively increase the frame rate when the user makes rapid head movements or interactive operations, enhancing the immersive display experience; and combined with the rendering load adaptive mechanism, intelligently reduce the frame rate when resources are idle to save energy consumption, achieving a dynamic balance between performance and battery life.

[0084] In some embodiments, the foregoing Android system dynamic frame rate control method may further include: detecting frame rate request information in a multi-application scenario, where the foregoing frame rate request information may include a first frame rate request of the foreground application and a second frame rate request of the background application; when a conflict event between the first frame rate request and the second frame rate request is detected, based on the application type priority policy, switch the current display mode of the target display hardware to the target display mode matching the first frame rate request; in the rendering pipeline of the background application, gradually reduce the rendering frame rate of the background application to the preset energy-saving threshold through the frame rate smoothing attenuation mechanism; when it is detected that the foreground application exits or switches to the background, restore the original frame rate request of the background application and recalculate the global display timing parameters to update the system resource allocation policy.

[0085] Specifically, in the Android system environment with multiple applications running, the system will monitor the frame rate request information of each application in real time. The system obtains relevant information of the foreground application and the background application through methods such as ActivityManager.getRunningTasks() and extracts their respective frame rate requests from it, that is, the first frame rate request of the foreground application and the second frame rate request of the background application.

[0086] When the system detects a conflict event between the first frame rate request and the second frame rate request, it will activate the application type priority policy. The system will determine the application type according to the attributes of the application (such as tags like android:category.GAME) and then determine the priority of the application. For example, game applications usually have higher requirements for frame rate, and their priority will be higher than that of video playback applications. Based on this policy, the system will switch the current display mode of the target display hardware to the target display mode matching the first frame rate request to ensure the smooth operation of the foreground application and a good user experience.

[0087] While switching the display mode of the foreground application, in order to prevent background applications from over-consuming system resources, a frame rate smoothing attenuation mechanism is enabled in the rendering pipeline of background applications. The system gradually reduces the rendering frame rate of background applications until a preset energy-saving threshold is reached. This process is not completed instantaneously but is carried out in a smooth manner to avoid sudden impacts on background applications. For example, algorithms such as linear attenuation or exponential attenuation are used to gradually reduce the frame rate at certain time intervals.

[0088] When the system detects that the foreground application exits or switches to the background, a series of recovery and adjustment operations are performed. First, the original frame rate requests of background applications are restored, allowing background applications to return to their original operating states. Then, the global display timing parameters are recalculated, and based on the current states and requirements of each application, system resources are reallocated, and the system resource allocation policy is updated to ensure that the system can operate efficiently and stably in the new application scenario.

[0089] Exemplarily, the ActivityManager is used to monitor the top state of the application stack in real time, and the first frame rate request is obtained by parsing the DisplayFeature metadata of the foreground application (such as a game application declaring android.hardware.display.REQUEST_FRAME_RATE = 90Hz). At the same time, the WindowManager is used to listen to the Surface properties of the background application to obtain the second frame rate request (such as a video player setting Surface.setFrameRate(60Hz)). When a frame rate request conflict is detected, the following priority decision process is executed:

[0090] Application type classification: A priority weight matrix is constructed, and applications are classified into types such as games (weight 0.9), videos (0.7), and tool classes (0.5). The weight of the foreground application is multiplied by the foreground coefficient (1.5) to form the final priority score.

[0091] Dynamic mode switching: The DisplayPolicyResolver module is called to compare the priority scores. If the score of the foreground application is higher than the threshold (such as ≥1.2), the display mode is forcibly switched to its requested frame rate (such as 90Hz), and the VSync signal generation logic of the background application is overridden through SurfaceFlinger.setFrameRateOverride().

[0092] Background frame rate decay: Inject the FrameRateDecayer component into the rendering pipeline of background applications, gradually reduce their actual frame rate to the preset energy-saving threshold (such as 30Hz) according to the exponential decay curve (formula: f(t) = f0 × e^(-λt), λ = 0.1 / ms), and at the same time recycle the released GPU resources (such as texture memory, shader cores) and allocate them to foreground applications;

[0093] State restoration mechanism: When the onActivityPaused() event is detected, immediately call FrameRateRestorer.reset() to restore the original frame rate request of the background application, and recalculate the timing parameters through ResourceAllocator based on the current global load (CPU / GPU utilization, temperature sensor data), and dynamically adjust the resource quotas of each application (such as reducing the GPU time slice of the game application from 70% to 50%, and increasing the video application to 40%).

[0094] Through the implementation of the above embodiments, for the multi-task concurrent application scenario, by detecting the frame rate requests of different applications and coordinating conflicts based on the priority strategy, the display performance of the foreground core application can be guaranteed; at the same time, the frame rate smoothing decay and dynamic resource recycling mechanism for background applications can effectively avoid system resource contention and excessive power consumption, and improve the overall resource scheduling efficiency and usage experience of the system.

[0095] Furthermore, as an implementation of the foregoing method embodiments, the present application also provides an Android system dynamic frame rate control device for implementing the foregoing method embodiments. The device embodiments correspond to the foregoing method embodiments. For the convenience of reading, the details of the foregoing method embodiments will not be described one by one in the Android system dynamic frame rate control device embodiments, but it should be clear that the devices in the embodiments of the present application can correspondingly implement all the contents of the foregoing method embodiments. Such as Figure 2As shown in the figure, the Android system dynamic frame rate control device includes: a parameter acquisition unit 21, a safety range determination unit 22, a configuration parameter generation unit 23, a driver writing unit 24, and a rendering control unit 25. Among them, the parameter acquisition unit 21 is used to acquire the target frame rate parameter set by the user; the safety range determination unit 22 is used to determine the preset frame rate safety range based on the parsing result of the extended identification data of the target display hardware; the configuration parameter generation unit 23 is used to generate dynamic display timing configuration parameters according to the target frame rate parameter when the target frame rate parameter is within the preset frame rate safety range; the driver writing unit 24 is used to bypass the default display policy through the system service layer injection mechanism and write the dynamic display timing configuration parameters into the display controller driver; the rendering control unit 25 is used to monitor the frame rate deviation value between the actual rendering frame rate of the target display hardware and the target frame rate parameter in real time, and when the frame rate deviation value exceeds the preset deviation value, perform rendering control through a multi-level compensation mechanism.

[0096] The present application also provides a computer-readable storage medium, which stores computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will be caused to execute any step of the Android system dynamic frame rate control method provided by the present application.

[0097] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; it may also be various devices including one or any combination of the above memories.

[0098] In some embodiments, the computer-executable instructions may be in the form of a program, software, software module, script, or code, and may be written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0099] In some embodiments, the computer-executable instructions may or may not correspond to files in the file system, and may be stored as part of a file that stores other programs or data. For example, they may be stored in one or more scripts in a hypertext markup language (HTML) document, stored in a single file dedicated to the program being discussed, or stored in multiple cooperating files (such as files that store one or more modules, subroutines, or code portions).

[0100] In some embodiments, the computer-executable instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed at multiple locations and interconnected by a communication network.

[0101] Please refer to Figure 3 , an embodiment of the present application further provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, the steps of any method for multi-language matching of a cloud phone are implemented.

[0102] Since the electronic device introduced in this embodiment is the device adopted by a multi-language matching device of a cloud phone in the embodiments of the present application, based on the method introduced in the embodiments of the present application, those skilled in the art can understand the specific implementation manners and various variations of the electronic device in this embodiment. Therefore, the specific implementation of how this electronic device implements the method in the embodiments of the present application will not be described in detail here. As long as the device adopted by those skilled in the art to implement the method in the embodiments of the present application belongs to the scope protected by the present application.

[0103] In the specific implementation process, when the computer program 311 is executed by the processor, any implementation manner in the corresponding embodiment of the first aspect can be implemented.

[0104] It should be noted that in the above embodiments, the descriptions of each embodiment have their own focuses. For the parts not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0105] Those skilled in the art should understand that the embodiments of the present application may provide a method, a system, or a computer program product. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application may take the form of a computer program product implemented on one or more computer-readable storage media containing computer-readable program code.

[0106] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate for implementing in the process Figure 1one process or multiple processes and / or blocks Figure 1 a device for the functions specified in one block or multiple blocks.

[0107] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufactured article including an instruction device that implements the functions in the process Figure 1 one process or multiple processes and / or blocks Figure 1 specified in one block or multiple blocks.

[0108] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 specified in one block or multiple blocks.

[0109] The embodiments of the present application also provide a computer program product, which includes computer software instructions. When the computer software instructions run on a processing device, the processing device is caused to execute Figure 1 the process of a multi-language matching method for a cloud phone in the corresponding embodiment.

[0110] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are fully or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can 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 can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wired or wireless manner.

[0111] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0112] In several embodiments provided by this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical, or other forms.

[0113] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0114] In addition, in each embodiment of this application, the functional units can be integrated in one processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware and / or software functional units.

[0115] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device to execute all or part of the steps of the methods in each embodiment of this application.

[0116] The above embodiments are only used to illustrate the technical solutions of this application, rather than to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of each embodiment of this application.

[0117] Although the preferred embodiments of this specification have been described, those skilled in the art can make additional changes and modifications once they know the basic creative concepts. Therefore, the appended claims are intended to be construed as including the preferred embodiments and all changes and modifications falling within the scope of this specification.

[0118] Obviously, those skilled in the art can make various modifications and variations to this specification without departing from the spirit and scope of this specification. Thus, if these modifications and variations of this specification fall within the scope of the claims of this specification and their equivalent technologies, then this specification is also intended to include these modifications and variations.

Claims

1. A method for dynamic frame rate control in the Android system, characterized in that, Including: Obtain the target frame rate parameter set by the user; Determine the preset frame rate safety range based on the parsing result of the extended identification data of the target display hardware; When the target frame rate parameter is within the preset frame rate safety range, generate dynamic display timing configuration parameters according to the target frame rate parameter; Bypass the default display policy through the system service layer injection mechanism and write the dynamic display timing configuration parameters into the display controller driver; Real-time monitor the frame rate deviation value between the actual rendering frame rate of the target display hardware and the frame rate of the target frame rate parameter. When the frame rate deviation value exceeds the preset deviation value, perform rendering control through a multi-level compensation mechanism.

2. The Android system dynamic frame rate control method according to claim 1, characterized in that, The determining the preset frame rate safety range based on the parsing result of the extended identification data of the target display hardware includes: Parse the extended display identification data of the target display hardware to obtain the physical range of the vertical synchronization frequency and the physical range of the horizontal synchronization frequency; Perform compression calculation processing on the physical range of the vertical synchronization frequency based on the first preset safety margin coefficient to obtain the dynamic vertical frequency allowable interval; Perform compression calculation processing on the physical range of the horizontal synchronization frequency based on the second preset safety margin coefficient to obtain the dynamic horizontal frequency allowable interval; Generate the preset frame rate safety range according to the intersection of the dynamic vertical frequency allowable interval and the dynamic horizontal frequency allowable interval, where the upper limit value of the preset frame rate safety range is the maximum value of the intersection, and the lower limit value of the preset frame rate safety range is the minimum value of the intersection.

3. The Android system dynamic frame rate control method according to claim 1, wherein The performing rendering control through a multi-level compensation mechanism includes: When the frame rate deviation value is within the first amplitude interval, increase the scheduling priority of the rendering thread; When the frame rate deviation value is within the second amplitude interval, switch the rendering buffer queue to the triple buffer mode and dynamically adjust the GPU clock frequency; When the frame rate deviation value is within the third amplitude interval, fallback to the system default vertical synchronization policy and generate a hardware alarm signal, where the first amplitude interval, the second amplitude interval, and the third amplitude interval are all dynamically divided based on the target frame rate parameter and the response delay characteristics of the target display hardware, and the first amplitude interval, the second amplitude interval, and the third amplitude interval are arranged in ascending order of the deviation amplitude value and have no overlap.

4. The Android system dynamic frame rate control method according to claim 3, wherein The dynamically adjusting the GPU clock frequency includes: Based on the real-time change rate of the frame rate deviation value, generate a GPU clock frequency adjustment instruction through a proportional-integral-derivative control algorithm to adjust the GPU clock frequency, where the proportional coefficient of the proportional-integral-derivative control algorithm is positively correlated with the absolute value of the frame rate deviation value.

5. The Android system dynamic frame rate control method according to claim 1, characterized in that The bypassing the default display policy through the system service layer injection mechanism and writing the dynamic display timing configuration parameters into the display controller driver includes: Intercept the generation instruction of the default display timing parameters by hooking the display mode callback function of the system display composition service; Replacing the default display timing parameters with the dynamic display timing configuration parameters to generate a display mode override instruction, wherein the display mode override instruction includes a dynamically associated parameter set of a horizontal blanking period, a vertical blanking period, and a pixel clock division coefficient corresponding to the target frame rate parameter; Sending the display mode overlay instruction to the kernel layer through the cross-process communication interface to trigger a register write operation driven by the display controller; When a preset number of consecutive write failure events are detected, the display mode overwrite instruction is released and the system default vertical synchronization strategy is restored.

6. The Android system dynamic frame rate control method according to claim 1, wherein The Android system dynamic frame rate control method also includes: Generate the gyroscope angular velocity change rate based on the inertial measurement unit data in the VR / AR scene; When the gyroscope angular velocity change rate exceeds a preset change rate, the target frame rate parameter is increased to the physical limit frame rate of the target display hardware, and the rendering buffer queue is locked to a triple buffer mode; When it is detected that the rendering load of N consecutive frames is lower than a preset load threshold, the target frame rate parameter is reduced, wherein the value of N is negatively correlated with the physical limit frame rate.

7. The Android system dynamic frame rate control method according to claim 1, characterized in that, The Android system dynamic frame rate control method also includes: Detecting frame rate request information in a multi-application scenario, wherein the frame rate request information includes a first frame rate request of a foreground application and a second frame rate request of a background application; When a conflict event is detected between the first frame rate request and the second frame rate request, switching the current display mode of the target display hardware to a target display mode matching the first frame rate request based on an application type priority policy; In the rendering pipeline of the background application, a frame rate smoothing attenuation mechanism is used to gradually reduce the rendering frame rate of the background application to a preset energy-saving threshold; When it is detected that the foreground application exits or switches to the background, the original frame rate request of the background application is restored and the global display timing parameters are recalculated to update the system resource allocation strategy.

8. An Android system dynamic frame rate control device, characterized in that, include: A parameter acquisition unit, used to acquire a target frame rate parameter set by a user; A safety range determination unit, configured to determine a preset frame rate safety range based on a result of parsing the extended identification data of the target display hardware; a configuration parameter generating unit, configured to generate a dynamic display timing configuration parameter according to the target frame rate parameter when the target frame rate parameter is within the preset frame rate safety range; A driver writing unit, used to bypass the default display policy through a system service layer injection mechanism and write the dynamic display timing configuration parameters into a display controller driver; The rendering control unit is used to monitor in real time the frame rate deviation value between the actual rendering frame rate of the target display hardware and the target frame rate parameter, and when the frame rate deviation value exceeds a preset deviation value, rendering control is performed through a multi-level compensation mechanism.

9. An electronic device, comprising: A memory and a processor, wherein the processor is used to implement the steps of the Android system dynamic frame rate control method as described in any one of claims 1-7 when executing the computer program stored in the memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the Android system dynamic frame rate control method as described in any one of claims 1-7 are implemented.

Images