Vehicle display screen frame rate adjusting method and device and vehicle

Abstract

The invention discloses a vehicle display screen frame rate adjusting method and device and a vehicle, and is applied to the technical field of vehicle screen display control. According to the vehicle display screen frame rate adjusting method, in combination with system load data, a vehicle running state and an application priority, a falling vehicle state interval can be judged, the vehicle state interval is a predefined state interval, each vehicle state interval can correspond to a target rendering frame rate, and after the vehicle state interval is determined, the target rendering frame rate is obtained. And the target rendering frame rate of the vehicle display screen can be determined. Through the division of the vehicle state interval, the dynamic adjustment of the rendering frame rate can be realized, and the display fluency is maximized on the premise of ensuring the system stability, so that the fluency experience and the intelligent balance of the system load are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle screen display control, in particular to a vehicle display screen frame rate adjustment method and device and a vehicle. BACKGROUND

[0002] With the rapid development of intelligent networked automobile technology, the digitalization and intelligence level of vehicle cabin have been significantly improved. The current mainstream intelligent automobile cabin generally adopts a multi-screen interaction architecture. As a key driving assistance tool, the vehicle navigation map needs to render real-time dynamic road conditions, lane-level guidance and surrounding environment information to provide precise spatial decision support for the driver. However, the existing rendering strategy has significant technical contradictions. In order to balance system stability and power consumption control, the industry generally adopts a fixed low frame rate. This strategy effectively reduces the computing load and heat dissipation of the cabin domain controller by limiting the rendering frequency of the graphics processing unit, thereby prolonging the service life of the hardware. However, the fixed low frame rate mode exposes serious defects in complex driving scenarios. Although low frame rate rendering can meet the basic display requirements, it will cause obvious lag and ghosting in the application display when the scene changes. If the rendering level is maintained at a high level, it will cause unnecessary power consumption burden and affect the system energy efficiency and hardware life. Therefore, how to improve the display effect of the vehicle display screen application during driving has become a technical problem to be solved in the current vehicle screen display control technical field. SUMMARY

[0003] In order to solve the above technical problems, the present application is proposed. The embodiments of the present application provide a vehicle display screen frame rate adjustment method, device and vehicle, which can refer to vehicle system load data, vehicle running state and application priority to dynamically adjust the rendering frame rate of the display screen, thereby improving the display effect of the application.

[0004] According to a first aspect of the present application, a vehicle display screen frame rate adjustment method is provided, comprising: obtaining system load data, vehicle running state and application priority of a vehicle; determining a vehicle state interval according to the system load data, the application priority and the vehicle running state; determining a target rendering frame rate of a vehicle display screen according to the vehicle state interval.

[0005] As a possible implementation manner, the vehicle display screen includes a center control screen, an instrument screen and a head-up display. After determining the target rendering frame rate of the vehicle display screen according to the vehicle state interval, the vehicle display screen frame rate adjustment method further comprises: adjusting the rendering frame rates of the center control screen, the instrument screen and the head-up display at the same time point based on the target rendering frame rate, so that the differences between the rendering frame rates of the center control screen, the instrument screen and the head-up display and the target rendering frame rate are all less than a first preset difference.

[0006] By simultaneously adjusting the rendering frame rates of the central control screen, instrument panel screen, and head-up display to achieve the target rendering frame rate, consistency and synchronization among these screens during frame rate adjustment can be ensured, avoiding the inconsistency issues that occur with traditional solutions. When multiple screens run at the same frame rate, the transitions and animations between them will be smoother and more consistent. A unified frame rate helps reduce screen tearing and stuttering, providing a smoother and more coherent visual experience.

[0007] As one possible implementation, the vehicle display screen frame rate adjustment method further includes: determining the application priority based on the application's historical usage frequency, application status, and preset weight; wherein the historical usage frequency is positively correlated with the application priority, the application status includes foreground and background, and the preset weight is positively correlated with the application priority.

[0008] When system load is high, multiple processes fiercely compete for CPU time. Without priority adjustment, foreground user-interactive applications may become extremely sluggish as background tasks consume significant resources. Therefore, dynamically allocating resources based on application priority can significantly improve system performance, stability, and resource utilization. By adjusting priorities, computing, memory, and network resources are tilted towards high-priority applications, preventing localized overload that could lead to system crashes. Simultaneously, the availability of high-priority applications is maintained, ensuring core business operations remain responsive under high load and preventing delays or failures due to resource shortages. Dynamically limiting the resource usage of low-priority applications prevents system crashes due to resource exhaustion. More efficient resource utilization delays or reduces server expansion needs, lowering hardware costs.

[0009] As one possible implementation, determining the vehicle state interval based on the system load data, the application priority, and the vehicle operating status includes: when the system load data is greater than a first preset load threshold, determining the vehicle state interval as a first state interval; when the system load data is not greater than the first preset load threshold, determining the vehicle state interval as a second state interval or a third state interval based on the application priority and the vehicle operating status; wherein the target rendering frame rate corresponding to the second state interval is greater than the target rendering frame rate corresponding to the first state interval, and the target rendering frame rate corresponding to the third state interval is greater than the target rendering frame rate corresponding to the second state interval.

[0010] When the system load data exceeds the first preset load threshold, it indicates that the system load is too high. In this case, excluding the influence of vehicle operating status and application priority, the vehicle status interval is directly determined as the first status interval. The first status interval corresponds to the interval with the lowest rendering frame rate. Prioritizing ensuring the system load does not exceed the threshold allows for a reduction in the rendering frame rate, thereby reducing system performance consumption. When the system load data is not greater than the first preset load threshold, it can be determined that the system load is not too high. Therefore, the target rendering frame rate can be adjusted by referring to application priority and vehicle operating status. The target rendering frame rate for the second or third status interval should be higher than the target rendering frame rate corresponding to the first status interval, thereby improving the application's display effect.

[0011] As one possible implementation, the vehicle operating state includes vehicle speed and steering angle; the step of determining the vehicle state interval as a second state interval or a third state interval based on the application priority and the vehicle operating state when the system load data is not greater than the first preset load threshold includes: determining the vehicle state interval as a second state interval when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, and the application priority is low priority; determining the vehicle state interval as a third state interval when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, the application priority is high priority, and the vehicle speed is greater than a first vehicle speed threshold or the steering angle is greater than a first steering angle; and determining the vehicle state interval as a second state interval when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, the application priority is high priority, and the vehicle speed is not greater than the first vehicle speed threshold and the steering angle is not greater than the first steering angle.

[0012] Taking navigation maps as an example, within the range where the system load data is no greater than the first preset load threshold and no less than the second preset load threshold, if the application priority is low, then regardless of the vehicle speed and steering angle, it is determined to be in the second state range. At this time, the system load is generally low, but the application's frame rate requirement is not high, so the frame rate is adjusted to a moderate range. If the application priority is high, and one of the vehicle speed or steering angle values ​​is relatively large, it indicates that the frame rate refresh requirement for the navigation map is high, and the driver needs smooth visual feedback to ensure driving safety. In this case, it is determined to be in the third state range, and the range with the highest frame rate adjustment is selected to improve the visual experience. If both the vehicle speed and steering angle values ​​are relatively small, it indicates that the vehicle is running smoothly, possibly in low-speed straight-line travel. At this time, the frame rate refresh requirement for map navigation is low, and the frame rate can be appropriately reduced to ensure stability.

[0013] As one possible implementation, determining the vehicle state interval as a second or third state interval based on the application priority and the vehicle operating state when the system load data is not greater than the first preset load threshold includes: determining the vehicle state interval as the second state interval when the system load data is not greater than the second preset load threshold and the application priority is low priority; determining the vehicle state interval as the third state interval when the system load data is not greater than the second preset load threshold, the application priority is high priority and the vehicle speed is greater than the first vehicle speed threshold; and determining the vehicle state interval as the second state interval when the system load data is not greater than the second preset load threshold, the application priority is high priority and the vehicle speed is not greater than the first vehicle speed threshold.

[0014] When the system load data is no greater than the second preset load threshold, it can be understood that the system load is relaxed, and there are sufficient resources available for applications. Under this condition, if the application priority is low, the frame rate requirement is low. Taking music playback as an example, vehicle speed and steering angle can be disregarded, and the application can be allocated to the second state interval to save resources, balancing visual experience and resource utilization. If the application priority is high and the vehicle speed is relatively fast, taking map navigation as an example, the application should provide the driver with the best smooth experience and should be allocated to the third state interval to ensure driving safety. If the application priority is high but the vehicle speed is low, taking map navigation as an example, the frame rate requirement for the navigation map is lower than at high speeds. Therefore, the frame rate can be appropriately reduced to save resources, and the application should be allocated to the second state interval. During high-speed driving, vehicles may need to make emergency route adjustments due to obstacles ahead or changes in traffic conditions. High frame rate navigation can render new routes faster, for example, completing the switching display from the original route to the alternative route within 1 second, while a low frame rate may take 2-3 seconds, which may cause the driver to miss the best lane change opportunity. Increasing the frame rate further at particularly high speeds allows for more accurate matching of vehicle dynamics, avoiding the risk of misjudgments caused by route deviations or stuttering, and providing more reliable visual guidance and operational response for high-speed driving. Dynamically adjusting the frame rate at different speeds ensures safety in high-speed scenarios while also meeting the battery life requirements of daily use.

[0015] As one possible implementation, the system load data includes CPU utilization, GPU utilization, and memory utilization, and the application includes navigation maps.

[0016] Navigation maps need to provide drivers with real-time information during driving to ensure driving safety and the accuracy of driving routes. Therefore, dynamic frame rate adjustment of navigation maps can provide drivers with clearer and more accurate environmental information in complex environments, and balance resource allocation and display smoothness under different driving conditions to optimize the driver's driving experience.

[0017] According to a second aspect of this application, a vehicle display screen frame rate adjustment device is provided, comprising: a status detection module for acquiring vehicle system load data, vehicle operating status, and application priority; a performance decision module for determining a vehicle status interval based on the system load data, the application priority, and the vehicle operating status; and a frame rate control module for determining a target rendering frame rate for the vehicle display screen based on the vehicle status interval.

[0018] As one possible implementation, the vehicle display screen includes a central control screen, an instrument panel screen, and a head-up display; the vehicle display screen frame rate adjustment device further includes a multi-screen collaboration module, used to adjust the rendering frame rates of the central control screen, the instrument panel screen, and the head-up display at the same time point based on the target rendering frame rate, so that the difference between the rendering frame rates of the central control screen, the instrument panel screen, and the head-up display and the target rendering frame rate is less than a first preset difference.

[0019] According to a third aspect of this application, a vehicle is provided, comprising: a vehicle display screen; and a vehicle display screen frame rate adjustment device as described in the second aspect or any implementation thereof, wherein the vehicle display screen frame rate adjustment device is communicatively connected to the vehicle display screen.

[0020] According to a fourth aspect of this application, a computer device is provided, the computer device comprising: one or more processors; a memory; and one or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the processor to implement the method as described in the first aspect or any implementation thereof.

[0021] According to a fifth aspect of this application, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the method as described in the first aspect or any implementation thereof.

[0022] According to a sixth aspect of this application, an electronic device is provided, including a module for performing the method as described in the first aspect or any implementation thereof.

[0023] According to a seventh aspect of this application, a computer program product is provided, comprising program code for performing the method as described in the first aspect or any implementation thereof.

[0024] The vehicle display screen frame rate adjustment method, device, and vehicle provided in this application utilize vehicle system load data, which reflects the resource consumption of the intelligent cockpit and autonomous driving main control chip. The level of system load data directly determines the performance, smoothness, and stability of applications, while the vehicle's operating status determines the application's frame rate requirements. Application priority reflects the priority of resource allocation for applications during use. Therefore, by combining system load data, vehicle operating status, and application priority, the vehicle state interval can be determined. This vehicle state interval is a predefined interval, and each interval corresponds to a target rendering frame rate. Once the vehicle state interval is determined, the target rendering frame rate for the vehicle display screen can be determined. Through the division of vehicle state intervals, dynamic adjustment of the rendering frame rate can be achieved, maximizing display smoothness while ensuring system stability, thereby achieving an intelligent balance between smooth experience and system load. Attached Figure Description

[0025] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0026] Figure 1 This is a flowchart illustrating a vehicle display screen frame rate adjustment method provided in an exemplary embodiment of this application.

[0027] Figure 2 This is a schematic diagram of the structure of a vehicle display screen frame rate adjustment device provided in an exemplary embodiment of this application.

[0028] Figure 3 This is a schematic diagram of the structure of a vehicle display screen frame rate adjustment device provided in another exemplary embodiment of this application.

[0029] Figure 4 This is a structural diagram of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0030] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0031] With the rapid development of intelligent connected vehicle technology, the digitalization and intelligence of vehicle cockpits have significantly improved. Currently, mainstream intelligent vehicle cockpits generally adopt a multi-screen interactive architecture, including a central console display (CCD), an instrument cluster display (ICD), and a head-up display (HUD), forming a multi-dimensional information presentation system covering core driving information, entertainment control, and augmented reality projection. The central console screen is the in-vehicle infotainment and control hub, with core functions including navigation, multimedia playback (music / video), vehicle settings (air conditioning / seat adjustment), telephone communication, and reversing camera. The central console screen has evolved from traditional physical buttons to a large touchscreen, and some models support voice interaction and gesture control, allowing users to operate it while parked or driving at low speeds, such as setting navigation destinations, changing music, and adjusting the in-vehicle environment. The instrument cluster screen is the core display of vehicle status and driving information, with core functions including real-time display of key driving data such as vehicle speed, engine speed, fuel / battery level, coolant temperature, and fault warnings. It allows for quick access to vehicle status during driving, assisting in safe driving. The head-up display (HUD) is used for seamless projection of key information. Its core function is to project information such as vehicle speed, navigation guidance, lane departure warning, and collision alerts onto the windshield, reducing the need for eye shift. This allows users to keep their eyes forward while driving at high speeds, improving safety. The in-vehicle navigation map, as a crucial driving assistance tool, can be displayed simultaneously on the central control screen, instrument panel, and HUD. By rendering dynamic road conditions, lane-level guidance, and surrounding environmental information in real time, it provides drivers with precise spatial decision support. The central control screen, instrument panel, and HUD respectively fulfill the roles of interactive control, status monitoring, and safety assistance; all three are indispensable. In the future, with technological integration and cost optimization, they will jointly build a more intelligent and safer in-vehicle interaction system, making driving both convenient and technologically advanced.

[0032] However, existing rendering strategies for in-vehicle map applications suffer from significant technical contradictions. To balance system stability and power consumption control, the industry generally employs a fixed low frame rate rendering scheme for each screen, typically set to 10 frames per second (fps). This strategy effectively reduces the computational load and thermal power consumption of the cockpit domain controller by limiting the rendering frequency of the graphics processing unit (GPU), thus extending the hardware lifespan. However, the fixed low frame rate mode exposes serious flaws in complex driving scenarios: when the vehicle is in dynamic conditions such as low-speed crawling (e.g., in congested urban areas), sharp turns, or U-turns, the continuity of map element displacement is disrupted, resulting in stepped jumps and motion blur in the rendering of critical information such as road signs and turn arrows. This visual distortion not only reduces the readability of map information but may also cause drivers to misjudge spatial distances, creating safety hazards. Furthermore, the fixed frame rate strategy lacks dynamic adaptability to actual driving scenarios. When road conditions are simple, vehicles are traveling straight, or cruise at high speeds, low frame rate rendering can meet basic display requirements, but it cannot actively increase the frame rate to ensure display accuracy under complex conditions. Conversely, maintaining a high rendering level continuously outside of high frame rate demand scenarios will cause unnecessary power consumption burden, affecting system energy efficiency and hardware lifespan.

[0033] To address the aforementioned problems, this application proposes a vehicle display screen frame rate adjustment method. This method combines multi-dimensional vehicle data and maps it to predefined vehicle state intervals. The output rendering frame rate is determined through these vehicle state intervals, thereby dynamically adjusting the display frame rate of the vehicle display screen under different conditions. This balances system power consumption and display smoothness, adapts to diverse driving scenario requirements, and ultimately improves user experience and enhances driving safety. Figure 1 This is a flowchart illustrating a vehicle display screen frame rate adjustment method provided in an exemplary embodiment of this application. Figure 1 For example, first, obtain the vehicle's system load data, vehicle operating status, and application priority (see...). Figure 1 (S110). Vehicle system load refers to the degree to which various hardware resources in the vehicle's electronic system are occupied during operation, reflecting the current workload and resource utilization efficiency of the system. Vehicle operating status refers to data such as vehicle speed and steering angle obtained through the CAN bus, reflecting various operational data of the vehicle's actual operation. Application priority refers to the importance labels assigned by the system to different tasks or processes; tasks with higher priority are more likely to be executed first during resource contention. Essentially, it is a resource allocation decision rule used to resolve resource conflicts in a multi-tasking environment. Secondly, based on system load data, application priority, and vehicle operating status, the vehicle state interval is determined (see...). Figure 1(S120). Combining system load data, application priority, and vehicle operating status—multi-dimensional parameters—the vehicle state interval is determined. This interval is predefined, and a corresponding rendering frame rate can be set for each interval. Finally, based on the vehicle state interval, the target rendering frame rate for the vehicle display screen is determined (see [reference]). Figure 1 (S130). Once the vehicle state range is determined by combining multi-dimensional data, the target rendering frame rate can be determined, thereby dynamically adjusting the rendering frame rate of the vehicle display screen. When high frame rate is required, the rendering frame rate of the vehicle display screen is increased to improve the smoothness of the display, reduce screen tearing and ghosting, and bring a better display and interactive experience. When there is no high frame rate requirement, the rendering frame rate of the vehicle display screen is reduced, which greatly reduces the power consumption of the screen while ensuring smooth playback. It can also adapt to different frame rate requirements to suit driving scenarios and display needs.

[0034] The following text combines Figure 1 The following is a more detailed description of the vehicle display screen frame rate adjustment method provided in the embodiments of this application.

[0035] See Figure 1 In S110, the system load data, vehicle operating status, and application priority of the vehicle are obtained.

[0036] In some embodiments, vehicle system load data includes CPU (Central Processing Unit) utilization, GPU (Graphics Processing Unit) utilization, memory utilization, and temperature. CPU utilization refers to the percentage of tasks processed by the CPU per unit of time, indicating the busyness of the CPU cores performing computational tasks. Low CPU utilization (e.g., less than 30%) indicates that the system's computational tasks are not heavy, while high utilization (e.g., 70%-80%) indicates that the system is handling a large number of computational tasks. If it consistently reaches 100%, it means that the CPU has become a bottleneck, and tasks need to queue up waiting for CPU resources. GPU utilization refers to the load on the GPU when rendering images or processing parallel computing tasks, that is, the busyness of the GPU in handling graphics rendering or general computing tasks. Low GPU utilization may mean normal operation, or it may mean that the CPU is not able to prepare data frames for the GPU to render in time, causing the GPU to wait for task allocation. High GPU utilization indicates that the GPU is working at full capacity, is the main performance bottleneck, and is a normal state for graphics-intensive tasks. Memory usage refers to the amount of system memory (RAM) currently occupied, including running programs and cached data. The operating system uses free memory as a disk cache to speed up the system. This occurs when the system needs data that is not in physical memory and must be read from the hard drive's page file. If this value remains high, it indicates insufficient physical memory, and the system is frequently exchanging data with the hard drive. If the system starts using the swap file and disk activity (from the system monitor) is very high, while system response becomes extremely slow, this is a typical memory bottleneck. System load data can be combined with CPU usage, GPU usage, memory usage, and temperature to jointly assess the total system load value. If the total system load value decreases, it will manifest as a decline in vehicle system performance, resulting in response delays, stuttering, and function interruptions. Therefore, the vehicle's system load data will affect the display quality of the vehicle's display screen.

[0037] In some embodiments, vehicle operating status includes vehicle speed, steering angle, and gear status acquired via the CAN bus. If the application is a navigation map, at higher vehicle speeds, the faster the surrounding environment changes, the higher the refresh requirement for the navigation map. Therefore, to ensure the display effect of the navigation map, the rendering frame rate can be increased to reduce stuttering and ghosting, improving the driver's efficiency and accuracy in reading navigation information. Similarly, at larger steering angles, smooth visual feedback is also required, which can also increase the rendering frame rate of the navigation map. Gear status has similar display requirements as vehicle speed; at higher gears, the refresh requirement for the navigation map increases. Therefore, to ensure the display effect of the navigation map, the rendering frame rate can be increased. When the gear indicates a stationary state, the rendering frame rate can be decreased to avoid excessive resource consumption. It is understandable that determining the target rendering frame rate solely based on the vehicle's operating status, without considering the actual system load, will not actually achieve the target rendering frame rate. Therefore, system load data can be given priority in the judgment process. If the system load data is high, the target rendering frame rate should be reduced directly. If the system load data allows, the target rendering frame rate should be appropriately increased according to the vehicle's condition.

[0038] As one possible implementation, system load data includes CPU utilization, GPU utilization, and memory utilization, with applications including navigation maps. Since navigation maps need to provide drivers with real-time information during driving to ensure driving safety and route accuracy, dynamically adjusting the frame rate of navigation maps can provide drivers with clearer and more accurate environmental information in complex environments, and balance resource allocation and display smoothness under different driving conditions, thus optimizing the driver's experience. Besides functional foreground applications like navigation maps, other entertainment-type foreground applications such as music playback, or applications with complex refresh rate requirements, can also benefit from this adjustment method.

[0039] Using CPU utilization, GPU utilization, and memory utilization together to evaluate system load data can improve the accuracy of system load data. For example, by simultaneously monitoring CPU utilization, GPU utilization, and memory utilization, the interrelationships between them can be analyzed. For instance, is low GPU utilization due to a fully utilized CPU? Is system lag due to memory exhaustion and the use of the swap file? Through correlation analysis, the most critical resource limiting system performance can be identified, thereby determining the appropriate value for system load data. Furthermore, static weighting, dynamic bottleneck identification, and time series analysis can be introduced to comprehensively assess system load.

[0040] Understandably, besides CPU utilization, GPU utilization, and memory utilization affecting system load data, the impact of temperature can also be considered. For example, when the temperature exceeds a set high-temperature value, the system load data value should be increased; when the temperature does not exceed the set high-temperature value, the system load data value should be decreased. The more influencing factors considered when calculating system load data, the more accurate the calculated system load data will be, leading to more accurate adjustments to the rendering frame rate and a greater likelihood of achieving the target rendering frame rate.

[0041] With the rapid development of intelligent vehicle cockpits, multi-screen display systems have become mainstream, typically including a central control screen, instrument panel screen, and head-up display (HUD). These screens often need to display related map content, but traditional systems lack a unified frame rate scheduling strategy, leading to inconsistent display effects across screens (e.g., the HUD remains smooth even when the central control screen stutters), creating a visually disjointed experience. To address this issue, after determining the target rendering frame rate for the vehicle's display screens, the rendering frame rates of the central control screen, instrument panel screen, and HUD can be adjusted simultaneously based on this target frame rate. This ensures that the difference between the rendering frame rate of each screen and the target frame rate is less than a first preset difference. This ensures consistency and synchronization during frame rate adjustment, avoiding the inconsistencies in traditional solutions. When multiple screens operate at the same frame rate, screen transitions and animations become smoother and more consistent. A unified frame rate helps reduce screen tearing and stuttering, providing a smoother and more coherent visual experience.

[0042] See Figure 1 In S120, the vehicle status range is determined based on system load data, application priority, and vehicle operating status.

[0043] In some embodiments, application priority is determined based on the application's historical usage frequency, application status, and preset weight; wherein, historical usage frequency is positively correlated with application priority, application status includes foreground and background, and preset weight is positively correlated with application priority.

[0044] As one possible implementation of application prioritization, application prioritization aims to ensure that high-priority applications receive sufficient GPU and CPU resources to maintain a smooth frame rate and avoid stuttering or frame drops caused by resource contention. For example, when a vehicle is in motion and map navigation is enabled, if the real-time rendering of the in-vehicle navigation system drops due to insufficient resources, it may affect driving safety. Therefore, it should be assigned a high priority to ensure safety. In determining the target rendering frame rate, applications can consider historical usage frequency, application status, and preset weights to determine priority. For example, applications with higher historical usage frequency can have their priority increased to optimize display effects and improve user experience. In application status, foreground applications should have a higher priority than background applications to ensure fast response and smooth operation during interaction. Furthermore, applications that need to provide users with critical information, such as navigation maps, should be given a higher priority, for example, by increasing the preset weight of navigation map applications to ensure timely provision of real-time map information and ensure driving safety. Entertainment applications, such as music players, have lower frame rate requirements and do not require optimization of their display effects. Therefore, they can be set to a lower priority or have their preset weight reduced to balance resource allocation and reduce resource consumption. Understandably, the preset weights of applications can be customized, allocating higher weights to applications with optimized display requirements to ensure a personalized user experience. Preset weights can also provide useful references to users based on big data analysis. For example, if analysis shows that navigation maps have higher frame rate requirements than music playback, allocation suggestions can be provided to users, who can then directly select. Applications with higher preset weights have higher priority and receive more resources.

[0045] When system load is high, multiple processes fiercely compete for CPU time. Without priority adjustment, foreground user-interactive applications may become extremely sluggish as background tasks consume significant resources. Therefore, dynamically allocating resources based on application priority can significantly improve system performance, stability, and resource utilization. By adjusting priorities, computing, memory, and network resources are tilted towards high-priority applications, preventing localized overload that could lead to system crashes. Simultaneously, the availability of high-priority applications is maintained, ensuring core business operations remain responsive under high load and preventing delays or failures due to resource shortages. Dynamically limiting the resource usage of low-priority applications prevents system crashes due to resource exhaustion. More efficient resource utilization delays or reduces server expansion needs, lowering hardware costs.

[0046] After determining the application priority, in some embodiments, when the system load data is greater than a first preset load threshold, the vehicle state interval is determined as the first state interval; when the system load data is not greater than the first preset load threshold, the vehicle state interval is determined as the second or third state interval based on the application priority and the vehicle's operating status. The target rendering frame rate corresponding to the second state interval is greater than the target rendering frame rate corresponding to the first state interval, and the target rendering frame rate corresponding to the third state interval is greater than the target rendering frame rate corresponding to the second state interval. When the system load data is greater than the first preset load threshold, it indicates that the system load is too high. In this case, excluding the influence of the vehicle's operating status and application priority, the vehicle state interval is directly determined as the first state interval. The first state interval corresponds to the interval with the lowest rendering frame rate, prioritizing ensuring that the system load is not overloaded, which can reduce the rendering frame rate and thus reduce system performance consumption. When the system load data is not greater than the first preset load threshold, it can be determined that the system load is not too high. Therefore, the target rendering frame rate can be adjusted with reference to the application priority and the vehicle's operating status. The target rendering frame rate of the second or third state interval is higher than the target rendering frame rate corresponding to the first state interval, thereby improving the application's display effect.

[0047] In some embodiments, vehicle operating states include vehicle speed and steering angle. Incorporating vehicle speed and steering angle with system load data further adjusts the rendering frame rate of the display screen. Vehicle speed significantly impacts the required refresh rate of the navigation map. Higher refresh rates are needed at high speeds to ensure positioning accuracy and smooth operation, while lower frame rates are acceptable at low speeds. If the vehicle speed is too high and the navigation map refresh rate is only 1Hz (i.e., updating the position once per second), positioning delays may cause the actual vehicle position to deviate from the map display position by more than several meters, easily leading to misjudgments in complex intersections or highway ramp scenarios. Therefore, a high refresh rate can reduce positioning errors. Steering angle determines whether the vehicle is turning or making a U-turn. In complex driving scenarios such as turning or U-turns, smooth visual feedback is usually required. Therefore, when the steering angle is large, the rendering frame rate can be appropriately increased if the system load data allows. When incorporating vehicle speed and steering angle, system load data should be prioritized. Therefore, only when the system load data is not greater than a first preset load threshold should the vehicle state interval be considered for allocation as a second or third state interval.

[0048] As one possible implementation, when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, and the application priority is low, the vehicle state interval is determined as the second state interval; when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, the application priority is high, and the vehicle speed is greater than the first vehicle speed threshold or the steering angle is greater than the first steering angle, the vehicle state interval is determined as the third state interval; when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, the application priority is high, and the vehicle speed is not greater than the first vehicle speed threshold and the steering angle is not greater than the first steering angle, the vehicle state interval is determined as the second state interval.

[0049] Taking navigation maps as an example, within the range where the system load data is no greater than the first preset load threshold and no less than the second preset load threshold, if the application priority is low, then regardless of vehicle speed and steering angle, it is determined to be in the second state range. At this time, the system load is generally low, but the application's frame rate requirement is not high, so the frame rate is adjusted to a moderate range. If the application priority is high, and one of the vehicle speed or steering angle values ​​is large, it indicates a high demand for navigation map frame rate refresh. The driver needs smooth visual feedback to ensure driving safety, so this is determined to be the third state range, and the range with the highest frame rate adjustment is selected to improve the visual experience. If both vehicle speed and steering angle values ​​are small, it indicates that the vehicle is running smoothly, possibly in low-speed straight-line travel. At this time, the demand for map navigation frame rate refresh is low, and the frame rate can be appropriately reduced to ensure stability. Increasing the navigation rendering frame rate when the vehicle speed is high or the steering angle is large can significantly improve driving safety and navigation accuracy by reducing screen latency, improving the real-time performance of path planning, and enhancing visual smoothness. For example, in rainy or snowy weather or when driving at night, low frame rate navigation may cause drivers to misread routes due to screen stuttering. High frame rate navigation, through smoother dynamic rendering, reduces visual interference. During long-distance high-speed driving, the stuttering and latency of low frame rate navigation may force drivers to frequently concentrate on correcting routes, increasing fatigue. High frame rate navigation, through more stable screen output, reduces the visual burden on the driver.

[0050] As one possible implementation, when the system load data is not greater than the second preset load threshold and the application priority is low, the vehicle state interval is determined as the second state interval; when the system load data is not greater than the second preset load threshold, the application priority is high, and the vehicle speed is greater than the first vehicle speed threshold, the vehicle state interval is determined as the third state interval; when the system load data is not greater than the second preset load threshold, the application priority is high, and the vehicle speed is not greater than the first vehicle speed threshold, the vehicle state interval is determined as the second state interval.

[0051] When the system load data is no greater than the second preset load threshold, it can be understood that the system load is relaxed, and there are sufficient resources available for applications. Under this condition, if the application priority is low, the frame rate requirement is low. Taking music playback as an example, vehicle speed and steering angle can be disregarded, and the application can be allocated to the second state interval to save resources, balancing visual experience and resource utilization. If the application priority is high and the vehicle speed is relatively fast, taking map navigation as an example, the application should provide the driver with the best smooth experience and should be allocated to the third state interval to ensure driving safety. If the application priority is high but the vehicle speed is low, taking map navigation as an example, the frame rate requirement for the navigation map is lower than at high speeds. Therefore, the frame rate can be appropriately reduced to save resources, and the application should be allocated to the second state interval. During high-speed driving, vehicles may need to make emergency route adjustments due to obstacles ahead or changes in traffic conditions. High frame rate navigation can render new routes faster, for example, completing the switching display from the original route to the alternative route within 1 second, while a low frame rate may take 2-3 seconds, which may cause the driver to miss the best lane change opportunity. Increasing the frame rate further at particularly high speeds allows for more accurate matching of vehicle dynamics, avoiding the risk of misjudgments caused by route deviations or stuttering, and providing more reliable visual guidance and operational response for high-speed driving. Dynamically adjusting the frame rate at different speeds ensures safety in high-speed scenarios while also meeting the battery life requirements of daily use.

[0052] As one possible implementation, the target rendering frame rate for the first state interval can be set to 10fps, which is the fixed low frame rate rendering parameter commonly used in traditional solutions. This reduces system performance consumption while providing a minimum frame rate guarantee for application priority. The second state interval can be set to 20fps, and the third state interval can be set to 30fps.

[0053] Understandably, in addition to setting the first, second, and third state intervals, it is possible to divide the screen into more or fewer state intervals to accommodate the different needs of the vehicle's display screen. Besides setting 10fps for the first state interval, 20fps for the second state interval, and 30fps for the third state interval, the frame rate can also be adjusted according to the actual needs of the application and the requirements of the vehicle's display screen.

[0054] Understandably, in addition to determining the vehicle status range based on the system load data, application priority, and vehicle operating status in the above examples, other parameters such as temperature and gear status can be added to further improve the accuracy of determining the vehicle status range, thereby achieving finer control of frame rate adjustment.

[0055] See Figure 1 In S130, the target rendering frame rate of the vehicle display screen is determined based on the vehicle status interval.

[0056] In some embodiments, the first state interval can be set as the red light interval, the second state interval as the yellow light interval, and the third state interval as the green light interval. When the system load data is greater than 85%, the application is of arbitrary priority, and the vehicle speed and steering angle are of arbitrary values, it is classified as the red light interval. At this time, the load is too high, and the frame rate is uniformly reduced to ensure stability. When the corresponding system load data is between 40% and 85%, the application is of low priority, and the vehicle speed and steering angle are of arbitrary values, it is classified as the yellow light interval. The system load is moderate, the application is not important, and the frame rate is moderate. When the corresponding system load data is between 40% and 85%, the application is of high priority, and the vehicle speed is greater than 30 km / h or the steering angle is greater than 30°, it is classified as the green light interval. At this time, the application is critical and requires a high frame rate, so the highest frame rate is allocated to improve performance. When the corresponding system load data is between 40% and 85%, the application is of high priority, the vehicle speed is not greater than 30 km / h, and the steering angle is not greater than 30°, it is classified as the yellow light interval, and the frame rate is appropriately reduced to ensure stability. When system load data is less than 40%, the application is of arbitrary priority, and vehicle speed and steering angle are arbitrary values, the system is classified as a yellow light zone. System resources are sufficient, but the application is not critical, and the frame rate is moderate. When system load data is less than 40%, the application is of high priority, and the vehicle speed is greater than 30 km / h, the system is classified as a green light zone, providing the best smooth experience. When system load data is less than 40%, the application is of high priority, and the vehicle speed is no greater than 30 km / h, the system is classified as a yellow light zone. Although it is a high-priority application, the vehicle speed is low, so the frame rate can be appropriately reduced to save resources. Inputting system load data, vehicle operating status, and application priority can be mapped to three predefined state zones (red light zone, yellow light zone, and green light zone), thereby determining the corresponding target rendering frame rate. This achieves fine-grained control of frame rate adjustment, maximizing display smoothness while ensuring system stability.

[0057] Understandably, the parameters corresponding to the vehicle state interval can be dynamically adjusted, and the target rendering frame rate corresponding to the vehicle state interval can also be dynamically adjusted. Therefore, the screen's rendering frame rate can be adjusted according to the vehicle state and real-time requirements to achieve precise control, while also optimizing the display to improve the smoothness of the vehicle display screen and adapt to the needs of different vehicles and different screens.

[0058] In some embodiments, the system state can be evaluated at a fixed frequency, for example, once every 100 milliseconds. That is, the system load data, vehicle operating status and application priority of the vehicle are obtained once every 100 milliseconds, the vehicle state interval is determined, and the corresponding frame rate control command is output. This ensures real-time response and avoids the system overhead caused by too frequent decision-making.

[0059] Figure 2 This is a schematic diagram of the structure of a vehicle display screen frame rate adjustment device provided in an exemplary embodiment of this application, as shown below. Figure 2As shown, the vehicle display screen frame rate adjustment device 2 includes: a status detection module 21, used to acquire the vehicle's system load data, vehicle operating status, and application priority; a performance decision module 22, used to determine the vehicle status range based on the system load data, application priority, and vehicle operating status; and a frame rate control module 23, used to determine the target rendering frame rate of the vehicle display screen based on the vehicle status range.

[0060] As one possible implementation method, Figure 3 This is a schematic diagram of the structure of a vehicle display screen frame rate adjustment device provided in another exemplary embodiment of this application, as shown below. Figure 3 As shown, the vehicle display screen includes a central control screen, an instrument panel screen, and a head-up display; the vehicle display screen frame rate adjustment device 2 may further include: a multi-screen collaboration module 24, used to adjust the rendering frame rate of the central control screen, the instrument panel screen, and the head-up display at the same time point based on the target rendering frame rate, so that the difference between the rendering frame rate of the central control screen, the instrument panel screen, and the head-up display and the target rendering frame rate is less than a first preset difference.

[0061] In some embodiments, a vehicle display screen frame rate adjustment system can be constructed, which includes a status monitoring module, a performance decision module, a frame rate control module, and a multi-screen collaboration module. It monitors multi-dimensional parameters such as system load, application priority, vehicle speed, and steering angle in real time, divides the system status into three intervals: red light, yellow light, and green light, and dynamically adjusts the frame rate of the map display (10fps / 20fps / 30fps) accordingly, thereby achieving an intelligent balance between smooth user experience and system load.

[0062] The status monitoring module is responsible for collecting multi-dimensional input data in real time. This data includes: 1. System load data: This includes CPU utilization, GPU utilization, memory utilization, and temperature. The system load is primarily calculated based on CPU, GPU, and memory utilization. Temperature can be used as supplementary data; for example, if the temperature is too high, the rendering frame rate needs to be reduced to mitigate risk. 2. Vehicle operating status: This is obtained via the CAN bus, including vehicle speed, steering angle, and gear position. When system load data allows, the target rendering frame rate can be further refined using vehicle speed, steering angle, and gear position. For example, higher speeds and higher gears require a higher target rendering frame rate to reduce driving hazards. 3. Application status information: This includes application type and priority. Application priority can be determined based on historical usage frequency, application status, and preset weights. For example, applications like navigation, which significantly impact driving, can be given high priority, while music playback can be given low priority.

[0063] The performance decision module is the core module of the system. It maps input parameters to three predefined state intervals. For example, when the system load is greater than 85%, the application has arbitrary priority, and the vehicle speed and steering angle are arbitrary values, it is classified as a red light interval. At this time, the load is too high, and the frame rate is uniformly reduced to ensure stability. When the corresponding system load is between 40% and 85%, the application has low priority, and the vehicle speed and steering angle are arbitrary values, it is classified as a yellow light interval. The system load is moderate, the application is not important, and the frame rate is moderate. When the corresponding system load is between 40% and 85%, the application has high priority, and the vehicle speed is greater than 30 km / h or the steering angle is greater than 30°, it is classified as a green light interval. At this time, the application is critical and requires a high frame rate, so the highest frame rate is allocated to improve performance. When the corresponding system load is between 40% and 85%, the application has high priority, the vehicle speed is not greater than 30 km / h, and the steering angle is not greater than 30°, it is classified as a yellow light interval, and the frame rate is appropriately reduced to ensure stability. When system load is less than 40%, the application is of arbitrary priority, and vehicle speed and steering angle are arbitrary values, it falls under the yellow light zone. System resources are sufficient, but the application is not critical, and the frame rate is moderate. When system load is less than 40%, the application is of high priority, and vehicle speed is greater than 30 km / h, it falls under the green light zone, providing the best smooth experience. When system load is less than 40%, the application is of high priority, and vehicle speed is no greater than 30 km / h, it falls under the yellow light zone. Although it is a high-priority application, the vehicle speed is low, so the frame rate can be appropriately reduced to save resources.

[0064] The values ​​in system load data, vehicle operating status, and application priority can all be adjusted according to actual needs. The red light interval, yellow light interval, and green light interval can be used as prompt signals. Once the signals of the red light interval, yellow light interval, and green light interval are received, the corresponding rendering frame rate can be output.

[0065] The performance decision module can be set to evaluate the system status every 100 milliseconds and output corresponding frame rate control instructions based on the rule base, which ensures real-time response while avoiding the system overhead caused by overly frequent decisions.

[0066] The frame rate control module receives instructions from the performance decision module and dynamically adjusts the rendering frame rate of each screen by calling the map setting frame rate interface.

[0067] The multi-screen collaboration module coordinates the frame rate strategies of the central control screen, instrument panel, and head-up display, ensuring consistency and synchronization across all screens. For example, when the vehicle enters a turning phase, the module simultaneously adjusts the frame rate of all screens to avoid visual discontinuity. Essentially, the frame rate control module already adjusts the rendering frame rate of each screen to the target frame rate; the multi-screen collaboration module coordinates the adjustment time of multiple screens, ensuring they all begin adjusting at the same time to achieve synchronization.

[0068] As one possible implementation, the vehicle display screen frame rate adjustment device 2 may further include: determining the application priority based on the application's historical usage frequency, application status, and preset weight; wherein, the historical usage frequency is positively correlated with the application priority, the application status includes foreground and background, and the preset weight is positively correlated with the application priority.

[0069] As one possible implementation, the performance decision module 22 can also be configured to: when the system load data is greater than the first preset load threshold, determine the vehicle state interval as the first state interval; when the system load data is not greater than the first preset load threshold, determine the vehicle state interval as the second state interval or the third state interval according to the application priority and the vehicle operating status; wherein, the target rendering frame rate corresponding to the second state interval is greater than the target rendering frame rate corresponding to the first state interval, and the target rendering frame rate corresponding to the third state interval is greater than the target rendering frame rate corresponding to the second state interval.

[0070] As one possible implementation, the vehicle operating state includes vehicle speed and steering angle. The performance decision module 22 can also be configured to: determine the vehicle state interval as the second state interval when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, and the application priority is low priority; determine the vehicle state interval as the third state interval when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, the application priority is high priority, and the vehicle speed is greater than the first vehicle speed threshold or the steering angle is greater than the first steering angle; determine the vehicle state interval as the second state interval when the system load data is not greater than the first preset load threshold, not less than the second preset load threshold, the application priority is high priority, and the vehicle speed is not greater than the first vehicle speed threshold and the steering angle is not greater than the first steering angle.

[0071] As one possible implementation, the performance decision module 22 can also be configured to: determine the vehicle state interval as the second state interval when the system load data is not greater than the second preset load threshold and the application priority is low priority; determine the vehicle state interval as the third state interval when the system load data is not greater than the second preset load threshold, the application priority is high priority and the vehicle speed is greater than the first vehicle speed threshold; and determine the vehicle state interval as the second state interval when the system load data is not greater than the second preset load threshold, the application priority is high priority and the vehicle speed is not greater than the first vehicle speed threshold.

[0072] As one possible implementation, system load data includes CPU utilization, GPU utilization, and memory utilization, with applications including navigation maps.

[0073] Current smart car cockpits typically feature multiple vehicle display screens, including a central control screen, instrument panel screen, and head-up display, used to present navigation maps, vehicle information, and entertainment content. To ensure system stability and improve display quality, vehicles can employ the aforementioned vehicle display screen frame rate adjustment device. This device communicates with the vehicle display screens and, by combining system load data, vehicle operating status, and application priorities, determines the vehicle state interval. These predefined intervals correspond to a target rendering frame rate. Once the vehicle state interval is determined, the target rendering frame rate for the vehicle display screen can be set. By dividing the vehicle state intervals, dynamic adjustment of the rendering frame rate can be achieved, maximizing display smoothness while ensuring system stability, thus achieving an intelligent balance between a smooth user experience and system load.

[0074] An electronic device includes: a processor; a memory for storing processor-executable instructions; and a processor for executing a page layout method as described in the embodiments provided in this application.

[0075] Below, for reference Figure 4 This application describes an electronic device according to embodiments thereof. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0076] Figure 4 A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0077] like Figure 4 As shown, the electronic device 40 includes one or more processors 41 and a memory 42.

[0078] The processor 41 may be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and may control other components in the electronic device 40 to perform desired functions.

[0079] The memory 42 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 41 may execute the program instructions to implement the page layout methods of the various embodiments of this application described above and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0080] In one example, the electronic device 40 may also include an input device 43 and an output device 44, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0081] When the electronic device is a standalone device, the input device 43 can be a communication network connector for receiving the collected input signals from the first device and the second device.

[0082] In addition, the input device 43 may also include, for example, a keyboard, a mouse, etc.

[0083] The output device 44 can output various information to the outside, including determined distance information, direction information, etc. The output device 44 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0084] Of course, for the sake of simplicity, Figure 4 Only some of the components of the electronic device 40 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 40 may include any other suitable components depending on the specific application.

[0085] The methods in this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer programs or instructions that, when loaded and executed on a computer, perform, in whole or in part, the processes or functions described in this application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, core network equipment, OAM (Operational Information Management), or other programmable devices.

[0086] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0087] The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; or an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0088] Furthermore, embodiments of this application may also be storage media storing a computer program, which is executed by a processor through steps of a page layout method described in any of the above embodiments of this specification: For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0089] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0090] The steps in the methods of the various embodiments of this application can be adjusted, combined, or deleted according to actual needs, and the technical features described in each embodiment can be replaced or combined. The apparatuses in the various embodiments of this application can be combined, divided, or deleted according to actual needs.

[0091] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0092] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0093] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0094] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for adjusting the frame rate of a vehicle display screen, characterized in that, include: Acquire vehicle system load data, vehicle operating status, and application priorities; The vehicle status range is determined based on the system load data, the application priority, and the vehicle operating status. The target rendering frame rate of the vehicle display screen is determined based on the vehicle status range.

2. The vehicle display screen frame rate adjustment method according to claim 1, characterized in that, The vehicle display screen includes a central control screen, an instrument panel screen, and a head-up display; After determining the target rendering frame rate of the vehicle display screen based on the vehicle state range, the vehicle display screen frame rate adjustment method further includes: Based on the target rendering frame rate, the rendering frame rates of the central control screen, the instrument panel screen, and the head-up display are adjusted at the same time point so that the difference between the rendering frame rate of the central control screen, the instrument panel screen, and the head-up display and the target rendering frame rate is less than a first preset difference.

3. The vehicle display screen frame rate adjustment method according to claim 1, characterized in that, The methods for adjusting the frame rate of vehicle display screens also include: The application priority is determined based on the application's historical usage frequency, application status, and preset weight; wherein, the historical usage frequency is positively correlated with the application priority, the application status includes foreground and background, and the preset weight is positively correlated with the application priority.

4. The vehicle display screen frame rate adjustment method according to claim 1, characterized in that, The step of determining the vehicle status range based on the system load data, the application priority, and the vehicle operating status includes: When the system load data is greater than the first preset load threshold, the vehicle state interval is determined to be the first state interval; When the system load data is not greater than the first preset load threshold, the vehicle state interval is determined as the second state interval or the third state interval according to the application priority and the vehicle operating status; wherein, the target rendering frame rate corresponding to the second state interval is greater than the target rendering frame rate corresponding to the first state interval, and the target rendering frame rate corresponding to the third state interval is greater than the target rendering frame rate corresponding to the second state interval.

5. The vehicle display screen frame rate adjustment method according to claim 4, characterized in that, The vehicle's operating status includes vehicle speed and steering angle; When the system load data is not greater than the first preset load threshold, determining the vehicle state interval as the second state interval or the third state interval based on the application priority and the vehicle operating status includes: When the system load data is not greater than the first preset load threshold and not less than the second preset load threshold, and the application priority is low priority, the vehicle state interval is determined to be the second state interval. When the system load data is not greater than the first preset load threshold and not less than the second preset load threshold, the application priority is high priority, and the vehicle speed is greater than the first vehicle speed threshold or the steering angle is greater than the first steering angle, the vehicle state interval is determined to be the third state interval. When the system load data is not greater than the first preset load threshold and not less than the second preset load threshold, the application priority is high priority, and the vehicle speed is not greater than the first vehicle speed threshold and the steering angle is not greater than the first steering angle, the vehicle state interval is determined to be the second state interval.

6. The vehicle display screen frame rate adjustment method according to claim 5, characterized in that, When the system load data is not greater than the first preset load threshold, determining the vehicle state interval as the second state interval or the third state interval based on the application priority and the vehicle operating status includes: When the system load data is not greater than the second preset load threshold and the application priority is low priority, the vehicle state interval is determined to be the second state interval; When the system load data is not greater than the second preset load threshold, the application priority is high priority, and the vehicle speed is greater than the first vehicle speed threshold, the vehicle state interval is determined to be the third state interval. When the system load data is not greater than the second preset load threshold, the application priority is high priority, and the vehicle speed is not greater than the first vehicle speed threshold, the vehicle state interval is determined to be the second state interval.

7. The vehicle display screen frame rate adjustment method according to claim 1, characterized in that, The system load data includes CPU utilization, GPU utilization, and memory utilization, and the applications include navigation maps.

8. A vehicle display screen frame rate adjustment device, characterized in that, include: The status detection module is used to acquire vehicle system load data, vehicle operating status, and application priority; The performance decision module is used to determine the vehicle state range based on the system load data, the application priority, and the vehicle operating status. The frame rate control module is used to determine the target rendering frame rate of the vehicle display screen based on the vehicle status interval.

9. The vehicle display screen frame rate adjustment device according to claim 8, characterized in that, The vehicle display screen includes a central control screen, an instrument panel screen, and a head-up display; The vehicle display screen frame rate adjustment device also includes: The multi-screen collaboration module is used to adjust the rendering frame rates of the central control screen, the instrument panel screen, and the head-up display at the same time point based on the target rendering frame rate, so that the difference between the rendering frame rate of the central control screen, the instrument panel screen, and the head-up display and the target rendering frame rate is less than a first preset difference.

10. A vehicle, characterized in that, include: Vehicle display screen; The vehicle display screen frame rate adjustment device as described in any one of claims 8-9, wherein the vehicle display screen frame rate adjustment device is communicatively connected to the vehicle display screen.

Images