A frame animation streaming and double buffering rendering method and system

Abstract

The application discloses a frame animation streaming loading and double-buffering rendering method and system, and belongs to the technical field of vehicle-mounted intelligent cockpits and graphical user interfaces, and comprises the following steps: decoding a first frame and immediately outputting display after obtaining a frame sequence; grouping and concurrently decoding the remaining frames in batches, outputting all decoded frames every time a batch is completed; playing by adopting a double-buffering mechanism, maintaining current frame and next frame references, recording actual drawing time consumption and dynamically compensating frame intervals; when a new animation request is received, immediately interrupting or waiting for the end of a cycle before switching is decided according to priority comparison. The application also adopts LRU caching and automatic life cycle binding. The application solves the problems of white screen during frame animation loading, high memory peak, unstable frame rate, harsh switching and resource leakage, and realizes the functions of instant display of the first frame, controllable memory, stable frame rate and smooth switching, and is suitable for resource-restricted environments such as vehicle-mounted central controls and vehicle networking intelligent cockpits.

Description

Technical Field

[0001] This invention belongs to the field of vehicle-mounted intelligent cockpit and graphical user interface technology, and particularly relates to a frame animation streaming loading and double buffer rendering method and system. Background Technology

[0002] In existing Android systems and in-vehicle central control systems, the typical implementation process for frame animation is as follows: developers place multiple frame images into a resource directory or code array, load all frames at once using `AnimationDrawable.start()` and start playback, or use a Handler or Timer to periodically update the image resources of an ImageView. Some third-party libraries provide asynchronous loading and caching capabilities, but the overall approach still follows the basic pattern of playing after a complete load or being timed. For character animations such as those of in-vehicle virtual assistants, different animation states are typically switched based on user interaction; when a state changes, the current animation is stopped and a new animation begins.

[0003] The existing technology has the following drawbacks: The loading white screen is specifically manifested in the fact that the image decoding time increases linearly with the number of frames when loading all frames, and the user experiences a long white screen wait after clicking, creating the illusion of lag. Excessive memory peaks are manifested by all frames being decoded simultaneously and remaining resident in memory. High-resolution images lead to high memory usage, which can easily cause memory overflow errors. The risk is even higher in the memory-constrained environment of in-vehicle central control. Meanwhile, the timed playback based on Handler is affected by the system message queue, causing frame interval drift, animation to be sometimes fast and sometimes slow, and unable to be precisely synchronized with sound effects. When switching between different animation states, the current animation is easily interrupted, resulting in abrupt visual jumps. When the page is paused, the animation continues to run in the background, wasting CPU and GPU resources and causing memory leaks.

[0004] Based on the above reasons, this invention designs a frame animation streaming loading and double-buffered rendering method and system. Summary of the Invention

[0005] The purpose of this invention is to solve the problems in the prior art, and to propose a frame animation streaming loading and double buffer rendering method and system.

[0006] This invention first discloses a method for frame animation streaming loading and double-buffered rendering, including the following steps: Obtain the frame sequence of the target animation, then decode the first frame in the frame sequence and output it immediately for display; The remaining frames in the frame sequence are grouped according to a preset batch size, and the frames in each group are decoded concurrently. After each group is decoded, all currently decoded frames are output. A double-buffering mechanism is used to play decoded frames, including: maintaining a reference to the current display frame and a reference to the next frame; after drawing the current display frame in the rendering loop, updating the reference to the next frame to the current display frame and obtaining a new reference to the next frame from the list of decoded frames; at the same time, recording the actual drawing time of each frame and dynamically adjusting the waiting time of the next frame according to the expected frame interval to compensate for the deviation between the actual drawing time and the expected frame interval. When a new animation playback request is received, the first priority of the current animation and the second priority of the new animation are obtained. If the second priority is higher than the first priority, the current animation is immediately interrupted and the new animation is started; otherwise, a stop request flag is set, and the loading and playback of the new animation are triggered after the current animation reaches the end of the loop.

[0007] The above method also includes: using an LRU memory cache to store decoded frames, with the cache key containing at least the character identifier, animation status identifier, frame name, and display size, and the cache capacity being limited to a preset proportion of the device's available memory; binding the rendering view to the lifecycle of the host component, stopping the rendering loop, clearing the double buffer references, and canceling unfinished decoding tasks when the host component enters a paused state, and restarting the rendering loop if decoded frames exist when the host component resumes.

[0008] In the above method, the priority is divided into at least four levels: high priority, medium priority, low priority, and lowest priority; wherein, high priority animation can interrupt any priority animation, medium priority animation can interrupt low priority and lowest priority animation, and low priority animation can only interrupt the lowest priority animation.

[0009] In the above method, the steps of grouping the remaining frames according to a preset batch size, decoding them concurrently, and outputting them specifically include: dividing the remaining frame list into multiple batches in order of batch size; for each batch, concurrently starting the decoding task of each frame in that batch, and outputting all currently decoded frames after all decoding tasks in that batch are completed; actively yielding CPU time slices after each batch of decoding is completed; calculating the sampling rate based on the target display size during decoding and generating thumbnails.

[0010] In the above method, the use of a double-buffering mechanism to play decoded frames specifically includes the following loop steps: (1) Record the timestamp of the start of this loop; (2) Draw the current display frame onto the canvas; (3) Update the reference of the currently displayed frame to the reference of the next frame, and get the new reference of the next frame from the list of decoded frames. If the current frame is the last frame and the animation is looping, reset the frame index and get it again from the first frame of the list. (4) Calculate the dynamic waiting time, wherein the dynamic waiting time is the difference between the expected frame interval and the actual time consumed in the current loop, and the difference is at least one time unit, wherein the actual time consumed in the current loop is equal to the current timestamp minus the timestamp recorded in step S1. (5) After waiting for the dynamic waiting time, jump to step S1 to continue the loop until the stopping condition is met.

[0011] In the above method, when the first frame in the decoded frame sequence is immediately output and displayed, if the first frame has been hit in the memory cache, it is directly retrieved from the cache and output; if it has not been hit, the thumbnail is decoded, stored in the cache, and output.

[0012] The above method also includes: starting a timer in the idle state, temporarily switching to the interstitial state when triggered, and automatically returning to the idle state after playing once; and supporting a three-part music animation, that is, playing the start animation, looping the music animation, and playing the end animation in sequence, with the state automatically transitioning.

[0013] Secondly, the present invention provides a frame animation streaming loading and double-buffered rendering system, comprising: The streaming loading module is used to acquire the frame sequence of the target animation, decode the first frame and output it immediately, decode the remaining frames in batches and concurrently, and output all currently decoded frames after each batch is completed. The double-buffered rendering module is used to maintain references to the current display frame and the next frame. After drawing the current frame in the rendering loop, the pointer is updated, and the actual time is recorded to dynamically compensate for the frame interval. The dynamic compensation is carried out in the following way: the difference between the expected frame interval and the actual time consumed in this loop is used as the waiting time, and the waiting time is at least one time unit. The priority status management module is used to store the priorities of the current animation and the new animation, and decide whether to interrupt the current animation immediately or wait for the loop to end before switching based on the priority comparison result; The lifecycle management module is used to listen for lifecycle events of the host component, stop rendering and loading tasks when paused, and restart them when resumed.

[0014] The system also includes an LRU cache module for storing decoded frames. The cache key includes the role, status, frame name, and display size. The cache capacity is one-eighth of the device's maximum available memory. The system is deployed in an in-vehicle infotainment system or a vehicle-to-everything (V2X) smart cockpit domain controller. The rendering view uses TextureView or SurfaceView.

[0015] In the above system, the streaming loading module includes: a first frame extraction unit, used to extract the first frame of the frame sequence and decode and output it; a batch scheduling unit, used to divide the remaining frames into batches and create concurrent decoding tasks; a progressive emission unit, used to emit all currently accumulated decoded frames to the double-buffered rendering module after each batch of decoding is completed; and a time slice yielding unit, used to yield the CPU time slice after each batch of processing; the double-buffered rendering module adopts a coroutine-driven rendering loop and uses the coroutine's delay function to wait for the dynamic compensation duration.

[0016] The beneficial effects of this invention are as follows: 1. This invention prioritizes decoding and immediately displays the first frame, unlike existing technologies that require preloading multiple frames or decoding frame by frame. This eliminates the white screen waiting time after user clicks, achieving instant visual feedback. Simultaneously, the remaining frames are decoded in batches and output progressively after each batch, allowing the animation to gradually improve without blocking the first frame response. This mechanism resolves the conflict between startup latency and memory usage, resulting in shorter first frame display time in resource-constrained environments.

[0017] 2. This invention employs a double-buffering mechanism to maintain pointers to the current frame and the next frame, reducing the overhead of list indexing during playback of each frame. Combined with dynamic delay compensation driven by coroutines, it records the actual drawing time of each frame and uses the difference between the expected frame interval and the actual time as the waiting time for the next frame. This differs from the fixed delay method of the Handler timer, eliminating the cumulative drift of the frame interval, ensuring a stable animation frame rate, and achieving precise synchronization with sound effects.

[0018] 3. This invention defines multi-level animation priorities and determines whether to interrupt immediately or wait for the loop to end before switching based on the priority comparison result. This achieves smooth transitions and allows critical animations to respond instantly. Through LRU caching and automatic lifecycle binding, rendering is stopped and resources are released when the component is paused, reducing memory spikes and leakage risks. It is suitable for long-running scenarios such as in-vehicle central control systems. Attached Figure Description

[0019] Figure 1 This is a flowchart of the streaming loading process in a frame animation streaming loading and double-buffered rendering method disclosed in this invention.

[0020] Figure 2 This is a flowchart of the double-buffered rendering loop in a frame animation streaming loading and double-buffered rendering method disclosed in this invention.

[0021] Figure 3 This is a flowchart of priority state switching in a frame animation streaming loading and double-buffered rendering method disclosed in this invention.

[0022] Figure 4This is a flowchart of the timed insertion mechanism in a frame animation streaming loading and double-buffered rendering method disclosed in this invention.

[0023] Figure 5 This is a three-stage flowchart of music animation in a frame animation streaming loading and double buffer rendering method disclosed in this invention.

[0024] Figure 6 This is a block diagram illustrating the hardware and software modules of a frame animation streaming loading and double-buffered rendering method disclosed in this invention. Detailed Implementation

[0025] To facilitate understanding of this application and to make the aforementioned objectives, features, and advantages of this application more apparent, a detailed description of specific embodiments of this application is provided below in conjunction with the accompanying drawings. Numerous specific details are set forth in the following description to provide a thorough understanding of this application, and preferred embodiments are shown in the accompanying drawings. However, this application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of this application. This application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified. In the description of this application, "several" means at least one, such as one, two, etc., unless otherwise explicitly specified. It should be noted that when an element is referred to as being "fixed to" another element, it can be directly attached to the other element or there may be an intervening element. When an element is referred to as being "connected to" another element, it can be directly connected to the other element or there may be an intervening element. The terms "vertical," "horizontal," "left," "right," and similar expressions used herein are for illustrative purposes only and do not represent the only possible implementations. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is only for describing particular implementations and is not intended to limit the scope of this application. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0026] Reference Figures 1-6 This invention provides a method for frame animation streaming loading and double-buffered rendering, comprising the following steps: S1: Obtain the frame sequence of the target animation, then decode the first frame in the frame sequence and output it immediately for display.

[0027] S2: While displaying the first frame, group the remaining frames in the frame sequence into preset batch sizes, decode the frames in each group concurrently, and output all currently decoded frames after each group is decoded.

[0028] A double-buffering mechanism is used to play decoded frames, maintaining references to the current display frame and the next frame. In the rendering loop, after drawing the current display frame, the next frame reference is updated to the current display frame, and a new next frame reference is retrieved from the list of decoded frames. Simultaneously, the actual drawing time for each frame is recorded, and the waiting time for the next frame is dynamically adjusted based on the expected frame interval to compensate for the deviation between the actual drawing time and the expected frame interval.

[0029] S3: When a new animation playback request is received, obtain the first priority of the current animation and the second priority of the new animation. If the second priority is higher than the first priority, immediately interrupt the current animation and start playing the new animation; otherwise, set the stop request flag, wait for the current animation to play to the end of the loop, and then trigger the loading and playback of the new animation.

[0030] In implementation, when a user triggers a character animation, the system first reads the list of frame filenames corresponding to that animation from the configuration, immediately decodes the first filename, calculates the sampling rate based on the target display size to generate a thumbnail, and sends the first frame to the rendering view for display via the data channel. At this point, the user perceives that the animation has responded immediately. The remaining frames are then divided into groups of five, with concurrent tasks decoding each group simultaneously. Once a group is fully decoded, all accumulated frames are sent to the rendering view at once, and the CPU time slice is briefly relinquished before processing the next group. In the rendering loop, the start time is recorded at the beginning of each loop. After drawing the current frame, the current frame pointer is set to the next frame, and the new next frame is pre-fetched from the frame list. The actual time elapsed from the start of the loop to the current frame is calculated. If this time is less than the expected frame interval, the system waits for the difference; otherwise, it immediately proceeds to the next loop. When a user quickly clicks on different animations, priorities are compared: for example, if a greeting animation triggered by the user has higher priority than an idle loop animation, the current idle animation is immediately stopped and the greeting animation is loaded; if a high-priority greeting animation is currently playing and the user triggers another medium-priority music playback animation, only a stop request flag is set, and the music animation is switched to after the greeting animation finishes playing its last frame, avoiding screen jumps. The beneficial effects of this solution are: prioritizing the display of the first frame ensures that the user sees the animation feedback instantly after clicking, eliminating the white screen waiting in traditional solutions; batch concurrent decoding allows subsequent frames to be gradually completed without affecting the response of the first frame; double buffering and dynamic latency compensation ensure a stable frame rate, preventing sudden speed fluctuations; and the priority-based interruption and graceful stop mechanism makes animation transitions smooth and natural, with critical animations responding immediately and ordinary animations transitioning smoothly.

[0031] Furthermore, the present invention also includes using an LRU memory cache to store decoded frames. The cache key includes at least a character identifier, an animation status identifier, a frame name, and a display size. The cache capacity is limited to a preset proportion of the device's available memory. Simultaneously, the rendering view is bound to the lifecycle of the host component. When the host component enters a paused state, the rendering loop is stopped, double-buffered references are cleared, and unfinished decoding tasks are canceled. When the host component resumes, if decoded frames exist, the rendering loop is restarted.

[0032] During implementation, each time a frame is decoded, it is stored in LruCache with the key "role name_status name_frame name_target width_target height". The cache capacity is set to one-eighth of the maximum available memory, and the least used frame is automatically evicted when the cache capacity is exceeded. The rendering view implements the LifecycleObserver interface. In the onResume callback of the host Activity, if there is already a frame list and the Surface is available, a rendering coroutine is started; in the onPause callback, the animation loop flag is immediately set to false, the coroutine task is canceled, and the references to the current frame and the next frame are set to null. When the user switches the application to the background or the navigation interface covers it, the animation automatically stops and resources are released; playback automatically resumes when the user returns to the foreground. This solution avoids repeated decoding of the same frame through the caching mechanism, significantly reducing CPU and memory overhead; adding the size dimension to the cache key allows the same frame under different display sizes to be cached separately, avoiding image distortion after sampling. Automatic lifecycle management prevents background animations from consuming system resources, avoids rendering anomalies caused by Surface failure, and prevents memory leaks, making it particularly suitable for frequent interface switching scenarios in automotive environments.

[0033] Furthermore, this invention divides priorities into four levels: high priority corresponds to user-triggered response animations, medium priority corresponds to looping animations, low priority corresponds to idle interstitial animations, and lowest priority corresponds to idle looping animations. High-priority animations can interrupt any priority animation, medium-priority animations can interrupt low-priority and lowest-priority animations, and low-priority animations can only interrupt the lowest-priority animation. In implementation, a priority value is configured for each animation state: 0 for high priority, 1 for medium priority, 2 for low priority, and 3 for lowest priority. When a new animation request arrives, the current animation priority value is compared with the new animation priority value. If the new animation value is smaller (i.e., higher priority), an interrupt switch is immediately executed; otherwise, only a stop request is set. For example, if the idle state priority is 3, and the user clicks the voice button to trigger a greeting animation with a priority of 0, the idle animation is immediately stopped and the greeting is played. As another example, if the music looping state priority is 1, and the timer-triggered idle interstitial animation has a priority of 2, since the new animation has a lower priority, the system will not immediately interrupt the music animation but will wait for the current loop to finish before interstitiating. This hierarchical strategy ensures that users receive immediate feedback on critical actions, while non-critical animations do not interfere with currently ongoing key animations, and avoids flickering caused by repeated interruptions to animations.

[0034] In one feasible embodiment, the specific process of grouping, concurrently decoding, and outputting the remaining frames according to a preset batch size is as follows: First, the remaining frame list is divided into multiple batches in order of batch size. For each batch, the decoding tasks of each frame within that batch are started concurrently. After all decoding tasks in that batch are completed, all currently decoded frames are output. CPU time slices are actively yielded after each batch is decoded. During decoding, the sampling rate is calculated based on the target display size to generate thumbnails. Specifically, the batch size is set to 5, and the frame list excluding the first frame is grouped into groups of 5. For each group, the decoding of each frame within the group is started concurrently using a coroutine's async function. After all deferred frames are completed, all currently accumulated frames (including frames decoded in previous batches) are emitted through the data stream. After each group is processed, the delay function is called to yield a 1-millisecond CPU time slice. During decoding, inSampleSize is calculated based on the input target width and height, ensuring that the size of the decoded bitmap is exactly greater than or equal to the target size, avoiding loading the original large image. This solution significantly shortens the total loading time of the complete animation by using batch concurrent decoding, while the time slices after each batch avoid prolonged occupation of the I / O thread, which could cause the main thread to lag. Generating thumbnails instead of the original images greatly reduces memory usage per frame, and effectively controls the memory peaks accumulated over multiple frames.

[0035] In one feasible embodiment, the specific loop steps of double-buffered playback are as follows: (1) Record the timestamp of the start of this loop; (2) Draw the current display frame onto the canvas; (3) Update the reference of the currently displayed frame to the reference of the next frame, and get the new reference of the next frame from the list of decoded frames. If the current frame is the last frame and the animation is looping, reset the frame index and get it again from the first frame of the list. (4) Calculate the dynamic waiting time, which is the difference between the expected frame interval and the actual time consumed in the current loop, and the difference is at least one time unit, wherein the actual time consumed in the current loop is equal to the current timestamp minus the timestamp recorded in step (1). (5) After waiting for the dynamic waiting time, jump to step (1) to continue the loop until the stopping condition is met.

[0036] In the actual rendering loop, the system maintains two variables: `currentBitmap` and `nextBitmap`. At the start of each loop, `startTime` is recorded, the canvas is acquired via `lockCanvas`, the canvas is cleared, and `currentBitmap` is drawn according to the scaling matrix, then the drawing is committed. Subsequently, `currentBitmap` is set to point to `nextBitmap`, and a new bitmap is retrieved from the next index position in the frame list and assigned to `nextBitmap`. `elapsed` is calculated as the current time minus `startTime`. If `elapsed` is less than `frameDuration`, then `delay(frameDuration - elapsed)` milliseconds is applied; otherwise, the next frame begins immediately. This scheme reduces the overhead of index lookup in the frame list for each frame through double buffering, and preloading the next frame makes frame switching almost latency-free. Dynamic compensation eliminates accumulated errors caused by excessive system scheduling or drawing time, ensuring the accuracy of the overall animation duration.

[0037] Furthermore, when decoding the first frame and immediately outputting it for display, if the first frame is already in the memory cache, it is directly retrieved from the cache and output; if it is not, a thumbnail is generated after decoding and simultaneously stored in the cache before outputting. This first-frame caching optimization means that when the animation of the same character in the same state is played multiple times, the first frame does not need to be decoded repeatedly, further shortening the response time. For example, if a user clicks on the same virtual assistant character multiple times, the first frame is directly read from the cache for the second and subsequent clicks, and the display speed can be improved to almost instantaneous.

[0038] In one feasible embodiment, the system also supports timed interruptions and a three-segment music animation flow. Timed interruptions refer to starting a timer in an idle state, temporarily switching to the interruption state when triggered, and automatically returning to idle after playing once. The three-segment music animation refers to playing a start animation, a looping music animation, and an end animation in sequence, with automatic state transitions. In specific implementation, when the character is in an idle state, a 15-second timer is started. Each time the timer is triggered, it checks whether the current state is still idle. If so, the state is temporarily switched to IdleInterrupt, and the interruption animation is played once. After playback, it automatically switches back to Idle. For music playback scenarios, after the user clicks the music button, the system first plays the MusicStart animation once, and then automatically switches to the MusicPlaying state and loops the music. When the user clicks to stop the music again, if the current state is MusicPlaying or MusicStart, it first switches to the MusicEnd state and plays the end animation once, and then automatically switches back to Idle. This solution enriches the animation expressiveness, enabling the in-vehicle virtual assistant to achieve timed proactive interaction and complete visual feedback during music playback, and the state transitions are fully automated, requiring no manual writing of switching logic by the developer.

[0039] This invention also provides a frame animation streaming loading and double-buffered rendering system, which includes a streaming loading module, a double-buffered rendering module, a priority state management module, and a lifecycle management module. The streaming loading module acquires the frame sequence of the target animation, decodes the first frame and outputs it immediately, decodes the remaining frames in batches concurrently, and outputs all currently decoded frames after each batch is completed. The double-buffered rendering module maintains references to the currently displayed frame and the next frame, updates the pointer after drawing the current frame in the rendering loop, and records the actual time consumption to dynamically compensate for frame intervals. Dynamic compensation is achieved by subtracting the actual time consumption of the current loop from the expected frame interval as the waiting time, which is at least one time unit. The priority state management module stores the priorities of the current animation and the new animation, and decides whether to immediately interrupt the current animation or wait for the loop to end before switching based on the priority comparison result. The lifecycle management module listens to the lifecycle events of the host component, stops rendering and loading tasks when paused, and restarts them when resumed. This system can be deployed at the Android application layer, and the modules communicate with each other through data streams and state callbacks. For example, in the main interface of the vehicle's central control system, MainViewModel holds the animation state and sends a list of frames to TextureAnimationView via StateFlow; TextureAnimationView internally implements the rendering loop and lifecycle monitoring. The beneficial effects of this system are that the modular design decouples the functions, and streaming loading and rendering can be optimized independently; priority state management allows upper-layer business only to send animation requests, and the lower layer automatically decides to switch strategies; lifecycle management eliminates the need for manual release calls from the upper layer, reducing the barrier to entry and the probability of errors.

[0040] Furthermore, the system includes an LRU cache module for storing decoded frames. The cache key contains the role, status, frame name, and display size, and the cache capacity is one-eighth of the device's maximum available memory. The system is deployed in the in-vehicle infotainment system or the domain controller of the connected vehicle intelligent cockpit, using TextureView or SurfaceView for rendering. In specific hardware environments, such as a vehicle infotainment system equipped with 2GB of memory, the system sets the cache capacity to 256MB. When decoding frames, if the cache is full, the least recently used frame is evicted. Due to the high resolution of in-vehicle displays, the size information in the cache key ensures that frames for different display areas (such as the central control screen and the instrument panel window) are cached separately, avoiding scaling distortion. TextureView is used as the rendering carrier, leveraging its independent SurfaceTexture and hardware acceleration capabilities to improve rendering performance.

[0041] In one feasible embodiment, the streaming loading module further includes a first frame extraction unit, a batch scheduling unit, a progressive emission unit, and a time slice yielding unit. The first frame extraction unit is used to extract the first frame of the frame sequence and decode and output it. The batch scheduling unit is used to divide the remaining frames into batches and create concurrent decoding tasks. The progressive emission unit is used to emit all currently accumulated decoded frames to the double-buffered rendering module after each batch is decoded. The time slice yielding unit is used to yield the CPU time slice after each batch is processed. The double-buffered rendering module uses a coroutine-driven rendering loop and utilizes the coroutine's delay function to wait for dynamic compensation duration. Specifically, the first frame extraction unit immediately reads the first frame from the cache or file system after receiving the loading request, decodes it, and emits it through Kotlin's SharedFlow. The batch scheduling unit divides the remaining frame list into multiple sub-lists, and each sub-list creates a CoroutineScope, which internally uses async concurrent decoding. The progressive emission unit emits a complete copy of the current frames list after each batch is completed. The time slice yielding unit calls delay(1) after each batch is processed. The double-buffered rendering module executes a while loop within a coroutine, dynamically calculating the time using `delay` after each rendering iteration. This modular implementation clarifies responsibilities, facilitates unit testing and feature replacement, and avoids the message queue latency issues of traditional Handlers.

[0042] As is known from common technical knowledge, this invention can be implemented through other embodiments that do not depart from its spirit or essential characteristics. Therefore, the disclosed embodiments described above are merely illustrative and not exhaustive. All modifications within the scope of this invention or its equivalents are included in this invention.

Claims

1. A method for frame animation streaming and double buffering rendering, the method comprising: Includes the following steps: Obtain the frame sequence of the target animation, then decode the first frame in the frame sequence and output it immediately for display; The remaining frames in the frame sequence are grouped according to a preset batch size, and the frames in each group are decoded concurrently. After each group is decoded, all currently decoded frames are output. A double-buffering mechanism is used to play decoded frames, including: maintaining a reference to the current display frame and a reference to the next frame; after drawing the current display frame in the rendering loop, updating the reference to the next frame to the current display frame and obtaining a new reference to the next frame from the list of decoded frames; at the same time, recording the actual drawing time of each frame and dynamically adjusting the waiting time of the next frame according to the expected frame interval to compensate for the deviation between the actual drawing time and the expected frame interval. When a new animation playback request is received, the first priority of the current animation and the second priority of the new animation are obtained. If the second priority is higher than the first priority, the current animation is immediately interrupted and the new animation is started; otherwise, a stop request flag is set, and the loading and playback of the new animation are triggered after the current animation reaches the end of the loop.

2. The frame animation streaming loading and double-buffered rendering method according to claim 1, characterized in that, It also includes: using an LRU memory cache to store decoded frames, with the cache key containing at least the character identifier, animation status identifier, frame name, and display size, and the cache capacity being limited to a preset proportion of the device's available memory; binding the rendering view to the lifecycle of the host component, stopping the rendering loop, clearing double buffer references, and canceling unfinished decoding tasks when the host component enters a paused state, and restarting the rendering loop if decoded frames exist when the host component resumes.

3. The method of claim 1, wherein, The priority is divided into at least four levels: high priority, medium priority, low priority, and lowest priority; among them, high priority animations can interrupt any priority animation, medium priority animations can interrupt low priority and lowest priority animations, and low priority animations can only interrupt the lowest priority animations.

4. The frame animation streaming loading and double-buffered rendering method according to claim 1, characterized in that, The steps of grouping the remaining frames according to a preset batch size, decoding them concurrently, and outputting them specifically include: dividing the remaining frame list into multiple batches in order of batch size; for each batch, concurrently starting the decoding tasks of each frame in that batch, waiting for all decoding tasks in that batch to be completed, and outputting all currently decoded frames; actively yielding CPU time slices after each batch of decoding is completed; calculating the sampling rate based on the target display size during decoding and generating thumbnails.

5. The frame animation streaming loading and double-buffered rendering method according to claim 1, characterized in that, The method of playing decoded frames using a double-buffering mechanism specifically includes the following loop steps: (1) Record the timestamp of the start of this loop; (2) Draw the current display frame onto the canvas; (3) Update the reference of the currently displayed frame to the reference of the next frame, and get the new reference of the next frame from the list of decoded frames. If the current frame is the last frame and the animation is looping, reset the frame index and get it again from the first frame of the list. (4) Calculate the dynamic waiting time, wherein the dynamic waiting time is the difference between the expected frame interval and the actual time consumed in the current loop, and the difference is at least one time unit, wherein the actual time consumed in the current loop is equal to the current timestamp minus the timestamp recorded in step S1. (5) After waiting for the dynamic waiting time, jump to step S1 to continue the loop until the stopping condition is met.

6. The frame animation streaming loading and double-buffered rendering method according to claim 5, characterized in that, When the first frame in the decoded frame sequence is output and displayed immediately, if the first frame has been hit in the memory cache, it is directly retrieved from the cache and output; if it has not been hit, the thumbnail is decoded, stored in the cache, and output.

7. The frame animation streaming loading and double-buffered rendering method according to claim 2, characterized in that, Also includes: Start a timer when the device is idle. When triggered, the device will temporarily switch to interstitial mode and automatically return to idle mode after playing once. It also supports three-part music animation, which plays the start animation, loops the music animation, and plays the end animation in sequence, with the state automatically transitioning.

8. A frame animation streaming loading and double-buffered rendering system, characterized in that, include: The streaming loading module is used to acquire the frame sequence of the target animation, decode the first frame and output it immediately, decode the remaining frames in batches and concurrently, and output all currently decoded frames after each batch is completed. The double-buffered rendering module is used to maintain references to the current display frame and the next frame. After drawing the current frame in the rendering loop, the pointer is updated, and the actual time is recorded to dynamically compensate for the frame interval. The dynamic compensation is carried out in the following way: the difference between the expected frame interval and the actual time consumed in this loop is used as the waiting time, and the waiting time is at least one time unit. The priority status management module is used to store the priorities of the current animation and the new animation, and decide whether to interrupt the current animation immediately or wait for the loop to end before switching based on the priority comparison result; The lifecycle management module is used to listen for lifecycle events of the host component, stop rendering and loading tasks when paused, and restart them when resumed.

9. The system according to claim 8, characterized in that, It also includes an LRU cache module for storing decoded frames. The cache key contains the role, status, frame name, and display size. The cache capacity is one-eighth of the device's maximum available memory. The system is deployed in an in-vehicle infotainment system or a vehicle-to-everything (V2X) smart cockpit domain controller. The rendering view uses TextureView or SurfaceView.

10. The system according to claim 8, characterized in that, The streaming loading module includes: The first frame extraction unit is used to extract the first frame of the frame sequence and decode and output it. The batch scheduling unit is used to divide the remaining frames into batches and create concurrent decoding tasks; The progressive emission unit is used to emit all currently accumulated decoded frames to the double-buffered rendering module after each batch of decoding is completed; Time slice yielding unit, used to yield CPU time slice after each batch processing; The double-buffered rendering module uses a coroutine-driven rendering loop and utilizes the coroutine's delay function to wait for the dynamic compensation duration.

Images