Mobile phone energy consumption optimization method

Abstract

The invention discloses a mobile phone energy consumption optimization method, and relates to the technical field of information, and the method comprises the steps: obtaining a current game frame of a mobile phone game application, and extracting a key rendering parameter of the current game frame; according to the current game frame and the historical game frame, calculating a static scene element space consistency score and a dynamic rendering object state change rate; according to the static scene element space consistency score and the dynamic rendering object state change rate, generating a computing resource allocation scheme; according to the computing resource allocation scheme, GPU rendering pipelines and CPU computing resources are configured, corresponding game computing execution paths are selected, and the computing execution paths comprise a complete rendering pipeline path, an incremental rendering path or an inter-frame interpolation path; aiming at high energy consumption of 3D scene rendering in a mobile game, a three-level rendering strategy selection mechanism based on scene change degree and the like are established, and the energy consumption of a mobile phone is reduced while the game quality is kept.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method for optimizing mobile phone power consumption. Background Technology

[0002] With the rapid advancement of mobile device hardware performance, 3D scene rendering technology has become a core pillar of modern mobile games. Currently, the mobile game industry exhibits a clear trend towards 3D development. The GPUs in mainstream smartphones (such as Qualcomm Snapdragon series and Apple A-series chips) are continuously improving in performance, possessing the powerful ability to handle complex 3D scenes. Industry-leading game engines such as Unity and Unreal Engine also provide comprehensive 3D rendering support for mobile platforms, enabling developers to create visually stunning 3D game experiences.

[0003] Market data shows that 3D mobile games have dominated the mobile game market, especially in high-revenue game categories. According to the latest market research, the global mobile game market exceeded $120 billion in 2024, with 3D games accounting for over 60% of the market share. Representative titles such as *Genshin Impact*, *PUBG Mobile*, and *Call of Duty: Mobile* all utilize sophisticated 3D rendering technology, setting industry benchmarks.

[0004] Despite the significant progress 3D games have made on mobile platforms, the "performance-energy consumption gap" is becoming increasingly prominent. Advances in mobile device battery technology are slow, with energy density increasing by only 3%–5% annually, significantly lagging behind the 20%–30% annual growth rate of processing performance. This imbalance leads to severe battery life challenges for modern 3D mobile games. User experience research shows that running 3D games drains a phone's battery 3 to 5 times faster than running regular applications, and a single mainstream 3D game can reduce the battery life of a high-end phone from a full day to just 2–3 hours.

[0005] Traditional mobile 3D rendering pipelines are primarily implemented using graphics APIs such as OpenGL ES, Vulkan, or Metal, employing a classic rendering workflow: geometry processing → rasterization → fragment processing → framebuffer operations. A key characteristic of this rendering architecture is that it performs a complete computation process for every single frame, regardless of the magnitude of scene changes, which presents significant shortcomings in terms of energy consumption control.

[0006] For example, related technology 202411265839.8 discloses a method and system for optimizing mobile game performance, including: determining the game scenario of the mobile game user based on the mobile game user behavior; the mobile game user behavior includes user input and rendering camera movement; determining the game screen requirements based on the game scenario; the game screen requirements include high dynamic range and relatively static screen; and dynamically adjusting the resolution and frame rate of the mobile phone display based on the game screen requirements. However, this solution only optimizes by adjusting the resolution and frame rate, which will significantly affect visual quality or smoothness, and cannot achieve energy consumption optimization while maintaining a high-quality gaming experience. Summary of the Invention

[0007] To address the high energy consumption of 3D scene rendering in mobile games, this application provides a method for optimizing mobile phone energy consumption, which establishes a three-level rendering strategy selection mechanism based on scene variability, thereby reducing mobile phone energy consumption while maintaining game quality.

[0008] This application provides a method for optimizing mobile phone power consumption, comprising: acquiring the current game frame of a mobile game application and extracting key rendering parameters of the current game frame, wherein the key rendering parameters include scene graph structure data, a list of visible objects, camera pose parameters, lighting environment parameters, and rendering command status; calculating the spatial consistency score of static scene elements and the state change rate of dynamic rendering objects based on the current game frame and historical game frames; generating a computing resource allocation scheme based on the spatial consistency score of static scene elements and the state change rate of dynamic rendering objects; wherein the computing resource allocation scheme includes determining reusable visual rendering results; and configuring GPU rendering pipeline and CPU computing resources according to the computing resource allocation scheme, and selecting an appropriate game computing execution path, wherein the computing execution path includes: a full rendering pipeline path, an incremental rendering path, or an inter-frame interpolation path.

[0009] The static scene element spatial consistency score is a quantitative indicator that measures the degree to which static scene elements (objects that do not move or change) remain unchanged between consecutive game frames. A higher score indicates less change in the static scene, making it more suitable to reuse the rendering results of the previous frame, thus saving computational resources. The dynamic rendering object state change rate is an indicator that quantifies the degree of state change of dynamic objects (objects that move or change) between consecutive game frames. A higher change rate indicates more significant changes in dynamic content, requiring a complete re-render; a low change rate allows for optimized rendering paths to reduce energy consumption.

[0010] Furthermore, the full rendering pipeline path performs the entire scene rendering process; the incremental rendering path only recalculates dynamic objects and reuses the rendering results of static elements; and the inter-frame interpolation path reconstructs the current frame from historical frames using a temporal reprojection method. The temporal reprojection method, a technique for reusing pixel information between consecutive frames, reconstructs the image by reprojecting the pixel and depth information of historical frames onto the viewpoint position of the current frame. The specific process includes calculating the view transformation matrix, performing pixel reprojection mapping, identifying invalid areas after reprojection (such as occluded areas or newly appearing content), and then rendering only these areas locally, ultimately synthesizing a complete current frame. This method significantly reduces the number of pixels that need to be recalculated, thereby reducing energy consumption.

[0011] Furthermore, the spatial consistency score of static scene elements is calculated, including: calculating the difference in the view matrix between the current game frame and the previous frame based on the camera pose parameters, as the amplitude of view change; calculating the lighting weight coefficient based on the changes in lighting environment parameters; encoding the position, size, and type of static objects into fixed-length feature codes through hash encoding based on scene graph structure data and the list of visible objects, to obtain static object hash codes; and calculating the spatial consistency score of static scene elements by comparing the static object hash codes of the current game frame with those of historical game frames, and combining the amplitude of view change and the lighting weight coefficient.

[0012] The view matrix difference value is a quantitative indicator of the degree of change in the camera's (player's viewpoint) position and orientation between consecutive game frames. In 3D graphics, the view matrix is ​​used to convert 3D world coordinates into a camera coordinate system. A smaller difference value indicates less change in the player's viewpoint, higher spatial consistency of the scene, and greater suitability for reusing previous rendering results. This is one of the important factors in evaluating the consistency of static scenes. Lighting environment parameters are a set of data describing the lighting conditions in the game scene, including light source position, light source color, light intensity, ambient light, and shadow parameters. In this application, the system calculates lighting weight coefficients by analyzing the changes in lighting environment parameters between consecutive frames, as part of the evaluation of the spatial consistency of static scene elements. Scenes with small lighting changes are more easily identified as "static," thus making them more suitable for applying optimized rendering paths. Scene graph structure data is a hierarchical tree structure that organizes objects in a 3D scene, describing the spatial and hierarchical relationships between objects in the scene. The scene graph contains information on the organization of objects, parent-child relationships, and spatial partitioning. In this application, scene graph structure data, together with the list of visible objects, is used to extract attribute data (position, size, and type) of static objects, and static object feature codes are generated through hash encoding for comparing the similarity of scenes between consecutive frames.

[0013] In particular, traditional scene similarity calculation methods require a complete scene graph decomposition and tree structure traversal in each frame, resulting in significant CPU computational overhead. In mobile game scenarios, this additional overhead can account for 15% to 20% of the single-frame computation budget, especially in complex 3D games with a large number of scene nodes (typically reaching 500 to 800 nodes). Traditional methods require performing complete attribute comparisons and recursive traversals for each node, and the computational complexity increases exponentially with scene complexity, making real-time scene analysis difficult to achieve on performance-constrained mobile devices. Therefore, this application adopts a scene representation method based on hash encoding, which... or The comparison operation for complex scenarios has been optimized to... By comparing the complexity of hash codes and introducing the amplitude of viewpoint changes and the lighting weight coefficient, the visual changes of the scene are accurately quantified.

[0014] Furthermore, obtaining the static object hash code involves: receiving scene graph structure data and a list of visible objects as input, extracting the original attribute data of the static objects, including 3D position coordinates, size parameters, type identifiers, material properties, and lighting response information; performing attribute standardization preprocessing to convert the extracted raw data into standardized values, where the position coordinates are normalized to a cube space of [-1, 1] through scene boundary normalization, the size parameters are converted into relative proportion values ​​by dividing by the corresponding dimension of the scene bounding box, the object type is mapped to a type number in the range of 0 to 255 through a lookup table, the material properties are quantized into floating-point values ​​in the range of [0-1] through linear transformation, and the lighting response features are converted into standard parameter representations through a feature extraction algorithm, thereby obtaining a standardized attribute set.

[0015] Feature encoding is generated based on a standardized attribute set. Position information is converted into a 24-bit position code that preserves spatial locality using a Z-order space-filling curve algorithm. Size information is compressed into a 12-bit size code using a quantization function. Type information is directly converted into an 8-bit type code. Material information is reduced to a 16-bit material code using principal component analysis. Lighting response information is converted into a 12-bit lighting response code using compressed sensing encoding, resulting in a multi-dimensional feature encoding set. The Z-order space-filling curve algorithm (also known as Morton coding or Z-curve) is a technique for mapping multi-dimensional spatial data to one-dimensional space while preserving the spatial locality of the data. In this application, this algorithm is used to encode the position information (x, y, z coordinates) of a 3D object into a 24-bit one-dimensional position code.

[0016] Feature weights are assigned based on the principle of visual perception importance. The position code is assigned a weight of 0.4, the size code 0.2, the type code 0.15, the material code 0.15, and the lighting response code 0.1. Based on these weights, the bit allocation of each feature in the final hash code is calculated, resulting in a weighted feature bit allocation scheme. The MurmurHash3 algorithm is used to perform hash calculations on the weighted feature codes, and an XOR perturbation function is used to reduce hash collisions. Locality-Sensitive Hashing (LSH) technology is combined to ensure visual similarity is preserved, generating intermediate hash values. These intermediate hash values ​​are then reassembled according to the weighted feature bit allocation scheme and concatenated into a 128-bit or 256-bit fixed-length static object hash code, serving as the basic data representation for static scene element consistency calculations. In the MurmurHash3 algorithm, after generating the initial hash value, the XOR perturbation function breaks the possible patterns and reduces the probability of collisions by performing an XOR operation on different parts of the hash value (such as the high and low bits). Typical implementations include performing an XOR operation on the high half and the low half of the hash value, or shifting the hash value to the right by different numbers and then performing an XOR operation on the original value.

[0017] Specifically, in a mobile game environment, a typical scene may contain hundreds of static objects, each with dozens of attribute parameters. The traditional method of comparing each object one by one has a computational complexity of [missing information]. This application optimizes a unified representation system for the multidimensional features of static objects by establishing such a system, combining standardized preprocessing, feature encoding compression, and efficient hash calculation using the MurmurHash3 algorithm. The hash code comparison operation enables real-time scene analysis.

[0018] On the other hand, traditional hashing methods directly process the original coordinate values, resulting in objects that are spatially close but have significantly different coordinate values ​​(such as objects crossing quadrant boundaries) generating completely different hash values. This leads to a false judgment rate as high as 30% to 40% in 3D game scene change detection. The Z-order encoding used in this application converts 3D coordinates into a one-dimensional sequence that preserves topological relationships through bit interleaving, while also preserving spatial locality, ensuring that objects that are close in physical space remain close in the encoded space. Specifically, the system quantizes the normalized [-1, 1]³ spatial coordinates into 10-bit precision integers, and then generates 30-bit Z-order codes through bit interleaving. This feature enables the system to accurately identify "visually similar" scene configurations, even if they differ in numerical representation, thereby achieving more accurate rendering reuse decisions in high-frequency game scenes such as smooth camera movement and slight object adjustments.

[0019] Furthermore, the calculation of the dynamic rendering object state change rate includes: extracting visible objects marked as dynamic in the current game frame from the list of visible objects and rendering command states, classifying dynamic objects into character classes, particle effect classes, and UI element classes; and setting weight coefficients for character classes, particle effect classes, and UI element classes respectively. ; Construct an enhanced state vector for each dynamic object, the enhanced state vector including position, rotation, and scaling parameters; Calculate the visibility coefficient of the dynamic object based on its position and rendering area, the visibility coefficient representing the visual importance of the dynamic object in the current view; Calculate the comprehensive weight coefficient for each dynamic object based on the set weight coefficient and visibility coefficient; Calculate the Euclidean distance between the enhanced state vectors of objects with the same ID in the current game frame and historical game frames, as the original difference value; Obtain the state change rate of the dynamically rendered object based on the original difference value and the comprehensive weight coefficient. .

[0020] The visible object list is a data set generated by the rendering engine before each frame is drawn. It includes all 3D objects that are determined to appear in the current view after frustum culling and occlusion culling. This list typically contains the object's unique identifier, spatial information, rendering priority, and basic attribute markers (such as static / dynamic flags). In mobile games, a typical scene's visible object list contains approximately 300 to 800 objects, with dynamic objects accounting for about 20% to 30%.

[0021] Rendering command state is a set of low-level commands in the graphics rendering pipeline used to control GPU behavior. It includes rendering state information such as shader binding, texture sampler state, blending mode settings, and depth test configuration. In modern graphics APIs such as Vulkan, Metal, or OpenGL ES, these commands are organized in the form of command buffers, which describe how to render each object in the scene.

[0022] Dynamic objects are game entities that undergo positional changes, shape changes, material changes, or state updates within a game scene. Unlike static elements such as backgrounds and buildings that remain static, dynamic objects require recalculation of their state and updates to the rendering results every frame. In this approach, dynamic objects are identified through explicit markers or behavioral characteristics (such as having animation or physics components) in the rendering command state and are categorized into different types (characters, particle effects, UI elements) to apply different weighting coefficients. The state changes of dynamic objects are one of the key factors determining energy consumption optimization strategies.

[0023] In this context, "character" refers to dynamic objects in games that possess a skeletal animation system and are typically represented as characters or creatures. Technically, character objects are characterized by: containing skeleton and skinning components, using skinning matrices calculated in vertex shaders, and usually having a complex animation state machine control system. Character objects typically feature multi-level Level of Detail (LOD), complex PBR materials and normal maps during rendering, consuming significant computational resources in games. Since characters are usually the focus of player attention and core interactive elements in games, their changes have the greatest impact on the visual experience; therefore, they are assigned the highest weighting coefficient. .

[0024] Particle effects refer to visual effects objects in games implemented using particle system technology. Technically, particle effect objects are characterized by: containing a particle emitter component, using GPU-accelerated particle simulation calculations, and typically employing billboarding or point sprite rendering techniques. Particle effects usually use additive or alpha blending modes and have unique parameters such as randomness, lifespan, and emission rate. Because particle effects have a significant visual impact but limited influence on gameplay, they are assigned a moderate weighting coefficient. .

[0025] UI element classes refer to user interface elements rendered in screen space. Technically, UI element objects are characterized by: using orthographic projection instead of perspective projection; typically being drawn using a Canvas system or a dedicated UI rendering pipeline; and using special UI shader programs. UI elements usually have fixed screen positions or relative anchor points, have higher rendering priority than 3D scene elements, and often use special depth testing settings to ensure they are always visible. Because UI elements primarily provide information and interactive functionality, changes to them have a relatively small impact on performance, and are assigned the lowest weight coefficient. .

[0026] The visibility coefficient is a numerical indicator that quantifies the visual importance of a dynamic object in the current view, with a value range of [0, 1]. This coefficient is based on the following calculation factors: 1) screen space occupied (object projection size); 2) screen center distance (reflecting the distribution pattern of visual attention); 3) occlusion degree (the degree to which it is occluded by other objects); and 4) movement speed (fast-moving objects attract more attention).

[0027] Furthermore, a computational resource allocation scheme is generated, including: when the spatial consistency score of static scene elements is greater than a first threshold and the state change rate of dynamic rendering objects is less than a second threshold, the resource allocation scheme is set to an incremental rendering path, reusing the rendering results of static elements and performing rendering calculations only on dynamic objects; when the spatial consistency score of static scene elements is greater than a third threshold and the state change rate of dynamic rendering objects is greater than a second threshold but less than a fourth threshold, the resource allocation scheme is set to an inter-frame interpolation path, reconstructing the current frame from historical frames using a temporal reprojection method; when the spatial consistency score of static scene elements is less than a first threshold, or the state change rate of dynamic rendering objects is greater than a fourth threshold, the resource allocation scheme is set to a full rendering pipeline path, executing a complete scene rendering process; based on the resource allocation scheme, a list of GPU rendering instructions and CPU physics calculation tasks is generated, and objects that need to be recalculated and reusable results are marked, and GPU rendering pipelines and CPU computing resources are configured.

[0028] Specifically, the first threshold With the third threshold The difference between these values ​​constitutes the "uncertainty interval" for static scene determination. Within this interval, the system makes a decision based on the rate of change of dynamic objects. Similarly, the second threshold... and the fourth threshold This constitutes a judgment interval for dynamic object changes. This dual-index cross-validation mechanism enhances the robustness of decision-making and avoids the shortcomings of single-index decision-making. This application achieves the optimal mapping from continuous rendering state space to discrete rendering path, achieving a theoretical balance between rendering quality and computational efficiency.

[0029] Furthermore, when the spatial consistency score of static scene elements is greater than the first threshold and the state change rate of dynamic rendering objects is less than the second threshold, the resource allocation scheme is set to incremental rendering path, reusing the rendering results of static elements, and performing rendering calculations only on dynamic objects, including: obtaining the static element rendering results of the previous frame from the rendering cache, wherein the static element rendering results include color cache and depth cache data; configuring the rendering pipeline to incremental rendering mode, disabling geometric calculations and shading calculations for camera scenes; identifying all dynamic objects in the current game frame, and performing rendering calculations only on the identified dynamic objects, wherein the rendering calculations include vertex processing, geometric processing, and pixel shading calculations; compositing the newly rendered dynamic object results with the reused static element rendering results to generate the complete image of the current game frame; updating the rendering cache, saving the static element rendering results of the current game frame for reuse in the next frame.

[0030] Specifically, when the spatial consistency score of static scene elements is high and the dynamic objects change little, the system performs selective rendering: only dynamic content is updated, and the results of static elements are reused. This application decomposes the traditional single rendering pipeline into two parts: a static pipeline and a dynamic pipeline, and achieves the final image through GPU buffer management and incremental compositing technology. This application solves the problems of depth conflict and lighting interaction between static / dynamic elements. The system maintains an additional G-Buffer to store the depth and material information of static elements, ensuring that dynamic objects can be correctly inserted into the static scene, including achieving correct occlusion relationships and lighting interactions.

[0031] Furthermore, when the spatial consistency score of static scene elements is greater than the third threshold, and the state change rate of dynamic rendering objects is greater than the second threshold but lower than the fourth threshold, the resource allocation scheme is set to inter-frame interpolation path, and the current frame is reconstructed from historical frames using the temporal reprojection method. This includes: calculating the view transformation matrix based on the camera pose parameters of the current game frame and historical game frames; using the view transformation matrix, reprojecting each pixel and its corresponding depth information in the historical game frames to the coordinate space of the current game frame to obtain the initial reprojected pixel mapping; based on the initial reprojected pixel mapping, identifying invalid regions and dynamic object regions that need to be updated after reprojection through depth comparison and edge detection; performing local rendering on the identified invalid regions and dynamic object regions that need to be updated to obtain the local rendering result; and obtaining the reconstructed current game frame based on the initial reprojected pixel mapping and the local rendering result.

[0032] Specifically, the inter-frame interpolation path transforms the 3D rendering problem into a temporal signal processing problem based on temporal coherence. Through temporal sampling and reconstruction techniques, the system can derive an approximate representation of the current frame from historical frames. This application's motion vector derivation algorithm based on historical frame information avoids the complete motion vector calculation process in traditional methods, further reducing CPU and GPU load.

[0033] Furthermore, the first threshold is greater than the third threshold; the first threshold ranges from 0.7 to 0.9; the third threshold ranges from 0.65 to 0.75; the fourth threshold is greater than the second threshold; the fourth threshold ranges from 0.55 to 0.65; and the second threshold ranges from 0.25 to 0.35.

[0034] Compared to existing technologies, the advantages of this application are:

[0035] 3D scene rendering in mobile games suffers from high energy consumption due to high-resolution texture processing and high-frequency frame updates. Existing technologies generally employ fixed frame rate control, simplified shaders, or reduced rendering precision, but these methods suffer from significant degradation in visual quality and high energy consumption. This application establishes a three-level rendering strategy selection mechanism based on scene variability: when scenes are highly similar, an incremental rendering path is used to update only dynamic content; when scenes undergo moderate changes, an inter-frame interpolation path is used to reconstruct the current frame through temporal reprojection; and only when the scene changes significantly is full rendering performed. This data-driven hierarchical rendering strategy avoids the blind full computation of traditional methods. By accurately quantifying the spatial consistency score of static scene elements and the state change rate of dynamic rendering objects, combined with dynamic object type weights and visibility evaluation, it achieves refined allocation of computational resources, significantly reducing GPU and CPU load while maintaining high visual quality. Attached Figure Description

[0036] This application will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0037] Figure 1 This is an exemplary flowchart illustrating a mobile phone power consumption optimization method according to some embodiments of this application;

[0038] Figure 2 This is an exemplary flowchart illustrating the calculation of the spatial consistency score of static scene elements according to some embodiments of this application;

[0039] Figure 3 This is an exemplary flowchart illustrating the calculation of the rate of change of the state of a dynamically rendered object according to some embodiments of this application;

[0040] Figure 4 This is an exemplary flowchart illustrating the calculation and rendering path according to some embodiments of this application. Detailed Implementation

[0041] The methods and systems provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0042] like Figure 1As shown, the current game frame of the mobile game application is obtained, and key rendering parameters of the current game frame are extracted. The key rendering parameters include scene graph structure data, visible object list, camera pose parameters, lighting environment parameters, and rendering command status. Based on the current game frame and historical game frames, the spatial consistency score of static scene elements and the state change rate of dynamic rendering objects are calculated. Based on the spatial consistency score of static scene elements and the state change rate of dynamic rendering objects, a computing resource allocation scheme is generated. The computing resource allocation scheme includes determining reusable visual rendering results. Based on the computing resource allocation scheme, the GPU rendering pipeline and CPU computing resources are configured, and the corresponding game computing execution path is selected. The computing execution path includes: a full rendering pipeline path, an incremental rendering path, or an inter-frame interpolation path.

[0043] In this embodiment, during the preprocessing phase of the game rendering loop, the system captures the underlying graphics API calls of the current rendering frame through an injected interceptor module. Taking the Vulkan API as an example, the system intercepts key rendering commands such as `vkCmd Begin Render Pass` and `vkCmd Bind Pipeline`, extracting rendering context information from them. For games using the Unity engine, the system obtains the Command Buffer content through the callback interface of `Graphics.Execute Command Buffer`; for games using the Unreal Engine, it obtains the rendering command queue through the hook function of `FRHI Command List Immediate`.

[0044] From the acquired rendering context, the system extracts the following key rendering parameters: Scene graph structure data: The system extracts the hierarchical structure information of the current scene from the game engine's scene management system, including parent-child relationships between nodes, spatial transformation inheritance chains, and render group assignments. For example, a typical mobile game scene contains approximately 150-500 scene nodes, forming a hierarchical structure of 5-8 levels. The system organizes this data into a compact tree structure, with each node containing 16 bytes of basic information and a variable-length list of child node indices.

[0045] Visible Object List: This is the set of visible objects obtained from the engine's visibility culling system after frustum culling. In moderately complex mobile game scenes, this list typically contains 300 to 800 rendered objects. The system records a unique identifier, spatial boundary information, material index, and dynamic / static markers for each object. Objects are categorized using 32-bit masks to distinguish different types such as terrain, buildings, characters, and effects.

[0046] Camera pose parameters: Records the camera's position vector (x, y, z) and orientation quaternions for the current frame. The system calculates and stores the camera's view matrix (4×4 floating-point matrix) and projection matrix (4×4 floating-point matrix) for subsequent calculations. This includes the field of view (FOV), near / far clipping plane distance, and projection type.

[0047] Lighting environment parameters: Extract global lighting information of the scene, including the direction of the main light source. The data includes the main light source color (r, g, b, intensity), ambient light color (r, g, b, intensity), indirect lighting intensity, and skybox high dynamic range (HDR) sample values. For games using physically based lighting models, the data also records the lighting probe density and reflection probe distribution.

[0048] Rendering command state: Captures the configuration state of the rendering pipeline, including shader procedural binding, texture sampler state, blending mode settings, depth test configuration, and stencil buffer settings. The system uses a 128-byte state vector to record this information, where each rendering state occupies a specific bit field for easy comparison and hash calculation.

[0049] like Figure 2 As shown, the static scene element spatial consistency score is first calculated: the system extracts the view matrix from the camera pose parameters of the current frame and the previous frame. and The magnitude of viewpoint change is quantified by calculating the difference between these two matrices: View Change Matrix .

[0050] The system from Extract translation components And the rotation component r (represented as a quaternion). The angle of view change is calculated as follows:

[0051] Translation amplitude ;

[0052] Rotation amplitude ;

[0053] Variation in perspective .

[0054] in, This is an estimate of the radius of the current scene (usually half the diagonal length of the scene bounding box). The magnitude of the viewpoint change is normalized to the range [0, 1], where 0 represents no change and 1 represents the maximum change.

[0055] The system compares the lighting environment parameters of the current frame with those of the previous frame to calculate the degree of lighting change.

[0056] Changes in the direction of the main light source ;

[0057] Color change of the main light source: ;

[0058] Changes in ambient light: .

[0059] The final illumination weighting coefficient is calculated as follows: .

[0060] The system generates static object hash codes and filters objects marked as static from the scene graph and the list of visible objects. For each static object, the following raw attribute data is extracted: Position: world space coordinates (x, y, z), with a precision of 32-bit floating-point numbers; Size: bounding box size (width, height, depth) or volume grid size; Type: object classification identifier (e.g., building, vegetation, rock, decoration, etc.); Material: master map ID, normal map ID, roughness / metallicity value; Lighting response: lightmap index, ambient occlusion factor, reflection probe index; In a typical mobile game scene, the number of static objects ranges from 150 to 400, totaling approximately 5-12MB of raw data.

[0061] Convert the raw attribute data to a normalized format: position coordinates are obtained using a formula. Mapped to [-1, 1]³ space; size parameters are normalized by dividing by the corresponding dimension of the scene bounding box; type identifiers are mapped to a compact enumeration value of 0-255; material properties are compressed to 32 feature values; lighting response features are reduced to 8 principal component values ​​by PCA; after standardization, the representation of each static object is compressed to approximately 120 bytes.

[0062] Convert the normalized position coordinates (x, y, z) ∈ [-1, 1]³ to integer coordinates: Similarly, calculate and Perform bit interleaving on these integers: take the i-th bit from the binary representation of each coordinate and combine them into a new sequence; for example, for , , The bit interleaving result is 10110. The encoding generated by bit interleaving maintains spatial locality, so that objects that are spatially close will generate similar encodings; for large objects, the system calculates the Z-order encoding of the 8 vertices of the bounding box and merges them into a single feature code through XOR operation.

[0063] Based on the principle of visual perception importance, feature weights are set as follows: position information: weight 0.4 (accounting for 40% of the total encoding); size information: weight 0.2 (accounting for 20% of the total encoding); type information: weight 0.15 (accounting for 15% of the total encoding); material information: weight 0.15 (accounting for 15% of the total encoding); illumination response: weight 0.1 (accounting for 10% of the total encoding).

[0064] In this embodiment, the improved Murmur Hash3 algorithm is used to process the weighted feature vector; the XOR perturbation function is used to reduce hash collisions; a 256-bit static object hash code is generated; to improve efficiency, the system divides the scene into an 8×8×8 spatial grid and generates an independent hash code for each grid cell.

[0065] The system calculates the similarity between the hash codes of static objects in the current frame and the previous frame: similarity = 1 - (different number of bits / total number of bits); for the implementation of grid division, the similarity of the hash codes of each corresponding grid cell is calculated, and then a weighted average is calculated: grid similarity = Σ (grid i similarity × grid i visible area ratio) / Σ (grid i visible area ratio); the final static scene element spatial consistency score is calculated as: static scene consistency score = grid similarity × (1 - 0.8 × viewpoint change amplitude) × (1 - 0.6 × illumination weight coefficient), where the score range is [0, 1], and the higher the value, the smaller the scene change.

[0066] like Figure 3 As shown, the system then filters objects marked as "dynamic" from the list of visible objects, which typically include characters, NPCs, moving objects, particle effects, and UI elements. Based on the object's type tag, the system categorizes them into three types: Characters (player characters, NPC characters, moving creatures, etc.); Particle Effects (magic effects, explosions, smoke, water flow, etc.); and UI Elements (floating damage numbers, status icons, interactive prompts, etc.). In a typical mobile game scenario, the number of dynamic objects usually ranges from 50 to 200, with Characters accounting for 20%–30%, Particle Effects for 40%–60%, and UI Elements for 20%–30%.

[0067] Based on the importance of various objects to visual perception, set different types of basic weight coefficients: Role class: (Highest weight, because characters are usually the focus of player attention); Particle effects: (Medium weight, particle effects usually have high visual salience); UI element class: (With lower weight, changes to UI elements usually have a smaller impact on rendering calculations).

[0068] For each dynamic object, the system constructs a 16-dimensional augmented state vector, containing: position: world space coordinates (x, y, z), 3 floating-point values; rotation: quaternion representation. 4 floating-point values; Scaling: Three-axis scaling factor 3 floating-point values; Animation state: current animation ID, playback progress percentage, blending weight, 3 floating-point values; Effect parameters: opacity, glow intensity, self-emitting color, 3 floating-point values; For inapplicable parameters (such as UI elements that do not need all animation states), default values ​​are filled. The enhanced state vector is normalized, and all components are mapped to the range [0, 1].

[0069] The system calculates the visibility coefficient based on the importance of dynamic objects in the view, considering the following factors: Screen space occupied area: Calculate the projected area A of the object on the screen (in pixels), and then use the formula... Quantification, among which, The baseline area is typically set to 5% of the screen area. Center distance factor: Calculate the standardized distance d∈[0,1] from the object's center to the screen center, then use the formula... Quantization gives higher weight to objects in the center of the screen. Occlusion factor: The visibility ratio v∈[0,1] of an object is calculated through depth buffer analysis, with 1 for fully visible and 0 for fully occluded.

[0070] The visibility coefficient is calculated as a weighted combination of these three factors: Visibility Coefficient: The visibility coefficient ranges from [0, 1], and a higher value indicates that the object is more visually important.

[0071] For each dynamic object, a comprehensive weight is calculated based on its type base weight and visibility coefficient: Comprehensive weight = base type weight × (0.7 + 0.3 × visibility coefficient); in this way, even objects of the same type will receive different weights based on their visibility.

[0072] The system compares the augmented state vectors of dynamic objects with the same ID in the current frame with those in the previous frame and calculates the Euclidean distance: Euclidean distance: For objects that appear in the current frame or disappear in the previous frame, set the maximum difference value to 1.0.

[0073] Based on the original difference values ​​and overall weights of all dynamic objects, the weighted average rate of change is calculated: Dynamic rendering object state change rate = Σ(difference value of object i × overall weight of object i) / Σ(overall weight of object i); the rate of change ranges from [0, 1], and the higher the value, the greater the change of the dynamic object.

[0074] like Figure 4As shown, the system automatically selects the most suitable rendering path based on the static scene consistency score and the dynamic object state change rate, combined with preset threshold parameters: Threshold settings: First threshold (high threshold for static consistency): 0.85; Second threshold (low threshold for dynamic change): 0.3; Third threshold (medium threshold for static consistency): 0.7; Fourth threshold (high threshold for dynamic change): 0.6.

[0075] When the static scene element spatial consistency score is >0.85 and the dynamic rendering object state change rate is <0.3, the system performs the following operation: read the static element rendering result of the previous frame from the rendering cache (usually implemented as two texture objects: an RGBA8 color buffer and a D24S8 depth stencil buffer).

[0076] Configure the rendering pipeline to incremental mode: Set the Color Mask to (0, 0, 0, 0) to disable color writing to static parts; set the depth test function to GL_EQUAL to ensure that rendering only occurs when the depth values ​​match perfectly; disable vertex and fragment shader calculations for static objects; extract all dynamic objects (approximately 50-200) from the list of visible objects and build a dedicated dynamic object rendering list.

[0077] Perform full rendering calculations on dynamic objects: Vertex processing: transformation, skinning calculations (for character models), animation interpolation; Geometry processing: tessellation, instantiation, geometry shader effects (if applicable); Pixel shading: material evaluation, lighting calculations, post-processing effects; Use blending operations to combine the results of newly rendered dynamic objects with the results of reused static elements: enable appropriate blending modes such as Blend Func (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); For semi-transparent objects, render from back to front to ensure correct transparency.

[0078] Update rendering cache: If the static part of the current frame is judged to be highly stable (consistency score > 0.95), the current composition result is saved as the static element cache for the next frame; at the same time, the depth buffer state is saved for depth testing in the next frame.

[0079] When the static scene element spatial consistency score is >0.7 and the dynamic rendering object state change rate is between 0.3 and 0.6, the system performs the following operations:

[0080] Calculate the view transformation matrix between the current frame and historical frames: .

[0081] Perform temporal reprojection: for each pixel of the historical frame and its depth value ,use Transform calculates its position in the current frame. ; Calculate the color value at the reprojection location using interpolation; Generate the initial reprojection image.

[0082] Identify problematic areas in reprojection using the following steps: Depth discontinuity detection: Calculate the depth difference between adjacent pixels and mark areas where the difference is greater than a threshold (typically 1% of the scene depth range); Motion vector analysis: Calculate the difference in motion direction between adjacent pixels and mark areas where the direction change is greater than 30 degrees; New visible area detection: Mark areas that are visible in the current view but not in the previous frame; Dynamic object regions: Mark the projection areas of all dynamic objects plus the surrounding 2-5 pixel boundaries.

[0083] Perform local rendering on the marked problem areas: organize the problem areas into rectangular or polygonal rendering regions; limit the rendering range using a clipping test (GL_SCISSOR_TEST); perform full rendering pipeline calculations on these regions. Combine the reprojected base image with the local rendering regions; apply a 2×2 pixel fast blur filter to handle boundary transition areas; for semi-transparent effects, apply time accumulation techniques to reduce flicker.

[0084] When the static scene element spatial consistency score is <0.7 or the dynamic rendering object state change rate is >0.6, the system executes the full rendering pipeline: processes the entire scene using the traditional forward or deferred rendering pipeline; executes all computation steps in the normal rendering order; does not reuse any historical rendering results; and saves the rendering results to the cache for possible reuse in the next frame.

[0085] S4, the system generates GPU rendering instructions and CPU physics calculation tasks based on the selected rendering path: For incremental rendering paths, GPU rendering instructions are optimized to skip most of the calculations for static elements, and the order of drawing calls submitted to the GPU is reallocated; for inter-frame interpolation paths, additional GPU computing units are arranged to perform reprojection calculations, while rendering tasks for local areas are scheduled; the CPU / GPU resource allocation ratio is dynamically adjusted according to the rendering path and scene complexity, ranging from 60:40 to 30:70; an instruction-optimized rendering task list is generated, clearly marking objects that need to be recalculated and reusable results; GPU thread group allocation and memory access modes are configured to optimize cache utilization and bandwidth efficiency. Through the above implementation methods, this method can reduce repetitive rendering calculations by 30% to 50% in medium-complexity mobile game scenes, significantly reducing GPU power consumption while maintaining consistent visual quality. In actual testing, for 60FPS games, the system's decision calculation overhead is typically less than 0.5ms, far less than the saved rendering time.

[0086] The foregoing illustrative description of the present application and its embodiments is not restrictive and can be implemented in other specific forms without departing from the spirit or essential characteristics of the present application. The accompanying drawings are only one embodiment of the present application, and the actual structure is not limited thereto. Therefore, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the present application, such designs should fall within the scope of protection of this application. Furthermore, the word "comprising" does not exclude other elements or steps, and the word "a" preceding an element does not exclude the inclusion of "a plurality" of that element. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A method for optimizing mobile phone power consumption, characterized in that, include: The current game frame of the mobile game application is obtained, and the key rendering parameters of the current game frame are extracted. The key rendering parameters include scene graph structure data, visible object list, camera pose parameters, lighting environment parameters, and rendering command status. Based on the current game frame and historical game frames, calculate the spatial consistency score of static scene elements and the state change rate of dynamic rendered objects; Based on the spatial consistency score of static scene elements and the state change rate of dynamic rendering objects, a computational resource allocation scheme is generated; the computational resource allocation scheme includes determining reusable visual rendering results. According to the computing resource allocation scheme, configure the GPU rendering pipeline and CPU computing resources, and select the corresponding game computing execution path. The computing execution path includes: full rendering pipeline path, incremental rendering path or inter-frame interpolation path.

2. The mobile phone power consumption optimization method according to claim 1, characterized in that: The entire rendering pipeline path executes the complete scene rendering process; Incremental rendering paths only recalculate and reuse the rendering results of static elements for dynamic objects; The inter-frame interpolation path reconstructs the current frame from historical frames using a temporal reprojection method.

3. The mobile phone power consumption optimization method according to claim 1 or 2, characterized in that: Calculate the spatial consistency score of static scene elements, including: Based on the camera pose parameters, calculate the difference in the view matrix between the current game frame and the previous frame, as the magnitude of the view change. Calculate the illumination weighting coefficient based on the changes in illumination environment parameters; Based on the scene graph structure data and the list of visible objects, the position, size and type of static objects are encoded into fixed-length feature codes through hash coding to obtain the static object hash code; By comparing the static object hash codes of the current game frame with those of historical game frames, and combining the perspective change magnitude and lighting weight coefficient, the spatial consistency score of static scene elements is calculated.

4. The mobile phone power consumption optimization method according to claim 3, characterized in that: Obtain the static object hash code, including: Extract attribute data of static objects from scene graph structure data and list of visible objects, the attribute data including position, size and type; The extracted attribute data is standardized. Based on the standardized attribute data, spatial index encoding is performed using the Z-order space filling curve algorithm to obtain a multidimensional feature encoding set; Set the weight coefficients for each feature in the multidimensional feature encoding set; The multidimensional feature encoding set is weighted and combined according to the weight coefficients to obtain the weighted feature vector; The weighted feature vector is hashed to obtain a static object hash code of fixed length.

5. The mobile phone power consumption optimization method according to claim 3, characterized in that: Calculate the rate of change of the state of dynamically rendered objects, including: Extract the visible objects marked as dynamic from the list of visible objects and the rendering command status of the current game frame, and classify the dynamic objects into character class, particle effect class and UI element class; Set the weight coefficients for character classes, particle effect classes, and UI element classes respectively. ; Construct an enhanced state vector for each dynamic object, the enhanced state vector including position, rotation, and scaling parameters; Based on the position and rendering area of ​​the dynamic object, the visibility coefficient of the dynamic object is calculated, which represents the visual importance of the dynamic object in the current view; Calculate the overall weight coefficient for each dynamic object based on the set weight coefficient and visibility coefficient; Calculate the Euclidean distance between the augmented state vectors of objects with the same ID in the current game frame and historical game frames, and use it as the original difference value; The rate of change of the state of the dynamically rendered object is obtained based on the original difference value and the comprehensive weight coefficient.

6. The mobile phone power consumption optimization method according to claim 5, characterized in that: 。 7. The mobile phone power consumption optimization method according to any one of claims 2 to 5, characterized in that: Generate a computing resource allocation scheme, including: When the spatial consistency score of static scene elements is greater than the first threshold and the state change rate of dynamic rendering objects is less than the second threshold, the resource allocation scheme is set to incremental rendering path, the rendering results of static elements are reused, and rendering calculations are only performed on dynamic objects. When the spatial consistency score of static scene elements is less than the first threshold but greater than the third threshold, and the state change rate of dynamic rendering objects is greater than the second threshold but less than the fourth threshold, the resource allocation scheme is set to inter-frame interpolation path, and the current frame is reconstructed from historical frames through the temporal reprojection method. When the spatial consistency score of static scene elements is less than the first threshold, or the state change rate of dynamic rendering objects is greater than the fourth threshold, the resource allocation scheme is set to the full rendering pipeline path, and the complete scene drawing process is executed. Based on the resource allocation scheme, generate a list of GPU rendering instructions and CPU physics calculation tasks, mark objects that need to be recalculated and reusable results, and configure the GPU rendering pipeline and CPU computing resources.

8. The mobile phone power consumption optimization method according to claim 7, characterized in that: When the spatial consistency score of static scene elements is greater than the first threshold and the state change rate of dynamically rendered objects is less than the second threshold, including: Retrieve the static element rendering result of the previous frame from the rendering cache, wherein the static element rendering result includes color cache area and depth cache area data; Configure the rendering pipeline to incremental rendering mode and disable geometry and shading calculations for the camera scene. Identify all dynamic objects in the current game frame and perform rendering calculations only on the identified dynamic objects. The rendering calculations include vertex processing, geometry processing, and pixel shading calculations. The newly rendered dynamic object results are combined with the reused static element rendering results to generate the complete image of the current game frame; Update the rendering cache to save the static element rendering results of the current game frame for reuse in the next frame.

9. The mobile phone power consumption optimization method according to claim 7, characterized in that: When the spatial consistency score of static scene elements is greater than the third threshold, and the state change rate of dynamically rendered objects is greater than the second threshold but less than the fourth threshold, including: Calculate the view transformation matrix based on the camera pose parameters of the current game frame and historical game frames; Using the view transformation matrix, each pixel and its corresponding depth information in the historical game frame are reprojected onto the coordinate space of the current game frame to obtain the initial reprojected pixel mapping; Based on the initial reprojection pixel map, invalid regions and dynamic object regions that need to be updated after reprojection are identified through depth comparison and edge detection. Perform local rendering on invalid regions and dynamic object regions that need to be updated at the identification point to obtain local rendering results; Based on the initial reprojection pixel mapping and local rendering results, the reconstructed current game frame is obtained.

10. The mobile phone power consumption optimization method according to claim 7, characterized in that: The first threshold is greater than the third threshold; The fourth threshold is greater than the second threshold.

Images