An animation playing method, an electronic device, a storage medium and a program product

Abstract

The application provides an animation playing method, an electronic device, a storage medium and a program product, and belongs to the technical field of intelligent cockpits. The method comprises the following steps: playing an animation segment currently loaded by using a foreground animation view; a target view group comprises at least two animation views arranged in a display area, and a background animation view is hidden during the playing process of the animation segment; when a next animation segment exists, the next animation segment is preloaded in the background animation view; after the playing of the animation segment is completed, the foreground animation view is hidden, the background animation view is switched to a new foreground animation view, the step of playing the animation segment currently loaded by using the foreground animation view in the target view group is returned, and the process is repeated until the playing of all animation sequences is completed. Through parallel processing of the multi-view alternative playing and the background preloading, the application eliminates the playing gap caused by the sequential loading of a single view, realizes seamless connection playing between multiple animation segments, and significantly improves the user experience.

Description

Technical Field

[0001] This application relates to the field of smart cockpit technology, specifically to an animation playback method, electronic device, storage medium, and program product. Background Technology

[0002] In mobile terminal user interfaces, with the increasing richness of animated interactions, it is often necessary to play multiple independent animation segments continuously within a limited display area to deliver coherent visual feedback or guiding information to the user. To achieve this continuous playback process, related technologies typically aim for animation resources to be loaded and presented quickly and smoothly, thereby reducing the user's perceived waiting time or visual jumps and improving the smoothness of the interactive experience.

[0003] To achieve the aforementioned continuous playback goal, related technologies generally employ a sequential execution approach for individual animation view controls: first, the current animation segment is loaded and played; after its playback ends, the current resource is destroyed or unloaded, and then the loading and playback process for the next animation segment begins. The core of this approach lies in relying on the same view control to serially handle the loading and display tasks of different animation resources. However, since reading, parsing, and generating playback entities for animation files (especially complex animations) requires processing time, when a single control immediately switches to the next animation resource after completing one playback, the loading time inevitably results in a visible blank or pause between the end of the current animation and the start of the next, disrupting visual continuity. Summary of the Invention

[0004] In view of this, this application aims to provide an animation playback method, electronic device, storage medium, and program product to solve the technical problem of how to avoid playback interruption caused by resource loading time in interface scenarios that require continuous playback of multiple animation segments, and to achieve seamless connection between multiple animation segments.

[0005] The first aspect of this application provides an animation playback method, including: The currently loaded animation clip is played using the foreground animation view in the target view group, which includes at least two animation views set in the display area. During the playback of the animation clip, the background animation view in the target view group is hidden. If a next animation clip exists, preload the next animation clip in the background animation view; After the animation clip in the foreground animation view finishes playing, hide the foreground animation view, switch the background animation view to the new foreground animation view, and return to the step of playing the currently loaded animation clip using the foreground animation view in the target view group, until the entire animation sequence has finished playing.

[0006] In one embodiment, the at least two animated views set in the display area are arranged overlappingly at the same interface position, and the layout parameters of each animated view are consistent except for the Z-axis layer parameter.

[0007] In one embodiment, switching the background animation view to the foreground animation view includes: raising the Z-axis level of the background animation view to the top level, or setting the visibility attribute of the background animation view to visible.

[0008] In one embodiment, the preloading includes: reading and parsing the animation file to generate an animation playback entity.

[0009] In one embodiment, the resources for the animation clips come from local storage files or memory cache.

[0010] In one embodiment, switching the background animation view to a new foreground animation view includes: swapping the foreground / background identifiers of the foreground animation view and the background animation view.

[0011] In one embodiment, when the entire animation sequence has finished playing, the foreground animation view is kept displayed on the last frame of the animation, and the animation resources occupied by each animation view are released.

[0012] A second aspect of this application provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform the animation playback method provided in any of the first aspects above.

[0013] A third aspect of the embodiments of this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the animation playback method provided in any of the first aspects above.

[0014] The fourth aspect of this application provides a computer program product comprising: a computer program that, when executed by a processor, implements the animation playback method provided in any of the first aspects.

[0015] The animation playback method provided in this application offers a target view group with at least two animation views. While the foreground animation view of the target view group plays an animation segment, the background animation view preloads the next animation segment in the background and immediately switches views after the current segment finishes playing, achieving parallel processing of foreground playback and background preloading. This solution effectively solves the loading blocking and visual interruption problems caused by sequentially loading resources in a single animation view, eliminates the waiting gap when switching between multiple animation segments, and thus achieves seamless playback between animation segments, significantly improving the user experience. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the hardware structure of the electronic device in which the animation playback method provided in the embodiments of this application is applied.

[0018] Figure 2 This is a flowchart illustrating the animation playback method provided in an embodiment of this application.

[0019] Figure 3 This is a schematic diagram illustrating the process of playing an animation continuously using two animation views, as provided in an embodiment of this application.

[0020] Figure 4 This is a schematic diagram illustrating the process of playing an animation continuously using three animation views, as provided in an embodiment of this application.

[0021] Figure 5 This is a schematic diagram of the structure of the animation playback system provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In the field of continuous playback technology for user interface animations, to achieve uninterrupted sequential playback of multiple animation clips, related technologies commonly use a single animation view control to sequentially load and play the clips. Specifically, this solution uses a LottieView control to sequentially read the animation file, parse resources, and generate the playback entity. After the current clip finishes playing, the next clip is loaded and playback begins. Its basic working principle is a serialized resource acquisition and rendering pipeline: after completing the entire playback process of the current animation, the view releases the current resources and then prepares for the next animation segment through steps such as IO reading, JSON parsing, and bitmap decoding. Its widespread application is mainly due to its ability to simplify control management and interface layout, avoid the nesting complexity and memory overhead caused by multiple controls, and its intuitive implementation logic and ease of maintenance.

[0024] However, this solution performs poorly when applied to interactive scenarios requiring continuous switching between multiple animation segments (such as multi-segment guided animations in in-vehicle gesture training applications). A fundamental contradiction lies in the fact that, in order to optimize control reuse and layout simplicity, the inherent design of this solution inevitably compromises the smoothness of animation transitions and can even cause visual interruptions. Specifically, during playback, after a single view completes its current animation, it must undergo a complete resource loading, parsing, and entity generation process before starting the next segment. This process can take hundreds of milliseconds or even longer when the resource size is large or the logic is complex. During this period, the interface cannot display any animation content, resulting in a noticeable black screen or stuttering phenomenon perceived by the user.

[0025] The aforementioned contradiction arises because the single-view serial architecture employed by the relevant technologies forcibly binds the foreground playback of animation clips and the background resource loading to the same time sequence. Playback and loading tasks share the same view's lifecycle, inevitably causing loading operations to block the playback process, preventing simultaneous execution. Furthermore, resource loading itself involves multiple steps, each consuming significant computation time and I / O bandwidth. The accumulated latency within a single thread directly translates into observable visual interruptions. Even optimizing the loading algorithm or compressing resource size cannot fundamentally eliminate the waiting gaps in the serial path.

[0026] To overcome the aforementioned contradictions, this application proposes a different technical approach. The core inventive concept of this application lies in introducing a target view group containing at least two animation views. While one view plays the current animation segment in the foreground, other backup views asynchronously preload the next animation segment in the background. Then, a view switching operation is used to switch the ready background view to the foreground for playback, while the original foreground view is switched to the background to load subsequent resources. This effectively eliminates loading blocking time caused by sequential loading of single views and avoids playback interruptions without significantly sacrificing control reuse and layout simplicity. The embodiments of this application solve the problem of visual interruption during continuous animation switching in related technologies, achieving a seamless playback effect between multiple animation segments.

[0027] Exemplary Implementation Environment Based on the inventive concept of the animation playback method according to the embodiments of this application, a corresponding implementation environment is provided. This animation playback method runs on an electronic device, such as... Figure 1 As shown, the electronic device includes at least one processor 101, a memory 102, a display screen 103, and an internal communication bus 104. The processor 101 and the memory 102 are connected via the bus 104. The memory 102 stores computer programs that can be executed by the processor. The display screen 103 is used to present user interface and animation content. The processor 101 controls the image output on the display screen 103 by executing the program in the memory 102. The electronic device may also include an input module for receiving user interaction commands, such as touch operations or key input. Furthermore, the electronic device can be connected to an in-vehicle network or local storage medium to obtain animation resource files.

[0028] The processor 101 is responsible for coordinating the work of various hardware modules and executing the operating system and applications. When continuous animation needs to be played, the processor reads the animation resources from memory or local files and drives the display screen to update the image according to the predetermined playback logic. The display screen 103 adopts a periodic refresh mechanism to provide a smooth visual experience. In addition to storing program code, the memory 102 also caches loaded animation files for fast retrieval.

[0029] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0030] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0031] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0032] Specifically, the electronic device can be a control unit of an in-vehicle infotainment system, or a smart device with a graphical user interface, such as a mobile terminal or tablet computer. Figure 1 The diagram schematically illustrates the processor 101, memory 102, display screen 103, and the data flow arrows between them, to explain the process of animation data being processed by the processor 101 from memory 102 and then sent to the display screen 103. Signals generated by input modules (such as touch sensors or physical buttons) are also processed by the processor and may trigger animation playback switching events. The entire system provides a general hardware support platform for the animation playback method described in subsequent embodiments.

[0033] Exemplary methods Figure 2The diagram shown is a schematic flowchart of an animation playback method according to an embodiment of this application. This control method is executed by the processor of an electronic device (such as an in-vehicle entertainment system, smartphone, tablet computer, etc.) and is implemented by calling a computer program stored in memory. The electronic device includes a display screen for presenting the user interface and animation content. This method mainly solves the problem of visual interruption caused by sequential resource loading when playing multiple animation segments continuously in the user interface. Figure 2 As shown, the method includes: S201, Play the currently loaded animation clip using the foreground animation view in the target view group. The target view group includes at least two animation views set in the display area. During the playback of the animation clip, hide the background animation view in the target view group.

[0034] Specifically, a display area for presenting the animation sequence is defined on the display screen of the implementation device, and a target view group including at least two animation views is created. This target view group can be regarded as a view collection used to manage the display status and lifecycle of these at least two animation views.

[0035] In this embodiment, an animation view refers to a view control capable of displaying animation content on the screen. It can refer to an animation playback control, a UI control capable of parsing and rendering animation files of a specific format. Each animation view has the independent ability to load and play animation files. As a specific implementation, these animation views are all Lottie animation playback controls, capable of parsing and rendering Lottie format animation files. Using at least two views provides a structural foundation for subsequent parallel processing.

[0036] In this embodiment, at any given time, only one animation view is in the foreground playback state, responsible for presenting the current animation content to the user. Initially, the foreground animation view is set to be visible and loads and plays the first segment of the animation sequence. Simultaneously, other animation views (i.e., background animation views) are hidden, placing them in an invisible background state. This embodiment ensures that the user interface is not disturbed by the loading or buffering process of background views through this hiding operation, avoiding visual clutter.

[0037] S202, if a next animation segment exists, preload the next animation segment in the background animation view.

[0038] Specifically, the preloading operation involves pre-loading resources, parsing data, and constructing animation playback entities for the next animation segment while the background animation view is invisible and does not interfere with foreground playback. This ensures the background animation view is ready for immediate playback, thus separating loading time from the playback sequence. When there are still unplayed subsequent animation segments in the playback sequence, the background animation view, which is currently invisible, asynchronously performs the preloading operation for the subsequent animation resources while the foreground animation view plays normally. This preloading process runs independently in the background, does not occupy the foreground playback thread, and does not affect the normal display and rendering of the current animation. By pre-loading, parsing, and constructing subsequent resources during playback intervals, the background animation view is ready for immediate playback before switching, allowing for instantaneous and seamless switching after the current animation finishes playing.

[0039] S203, after the animation segment in the foreground animation view has finished playing, hide the foreground animation view, switch the background animation view to the new foreground animation view, and return to the step of playing the currently loaded animation segment using the foreground animation view in the target view group, until the entire animation sequence has finished playing.

[0040] Specifically, when the currently playing animation segment finishes playing, the system immediately hides the original foreground animation view and switches the pre-loaded background animation view to the foreground animation view, making it the new foreground animation view and immediately starting playback. This instantaneous switching ensures uninterrupted, smooth, and stutter-free foreground animation playback, achieving a seamless transition between the two animation segments. After the switch is complete, the system returns to step S201, using the foreground animation view in the target view group to play the animation segment loaded in the foreground animation view, and repeats the above process until the entire animation sequence has finished playing. This loop enables parallel foreground playback and background preloading, fundamentally eliminating playback interruptions caused by resource loading.

[0041] In this embodiment, when the entire animation sequence has finished playing, the foreground animation view is kept displayed on the last frame of the animation, and the animation resources occupied by each animation view are released. Specifically, when all animation segments to be played have finished playing in sequence and there are no subsequent animations to be played, view switching and preloading operations are no longer performed. Instead, the animation view currently in the foreground is fixed at the last frame of its currently playing animation, keeping the interface display stable, without black screens or flickering, providing the user with a complete and natural ending screen. At the same time, to avoid memory occupation, prevent memory leaks, and reduce system load, the animation resources held by the foreground and background animation views are actively released after the animation sequence finishes playing. This includes, but is not limited to: clearing animation file data, destroying animation playback entities, releasing layer rendering resources, removing view references, and reclaiming memory cache. By combining the last frame holding with resource release, both the visual integrity at the end of animation playback is guaranteed, and timely reclamation and efficient utilization of memory resources are achieved, improving system operational stability.

[0042] It should be noted that the loop formed by steps S201 to S203 above utilizes at least two animated views to create a "double-buffered" or "multi-buffered" playback pipeline. While one view is playing, the other view has already pre-loaded its resources, achieving decoupling between playback and loading. This design allows the switching latency to be controlled at an extremely low level, such as within 10 milliseconds. This, combined with the persistence of vision, provides users with a seamless and smooth visual experience, effectively solving the loading blocking and visual interruption problems caused by sequential resource loading of a single view in related technologies. In one example, the code implementation is as follows: / / Playback completion listener callback frontView.addAnimatorListener(new AnimatorListener() { @Override void onAnimationEnd() { / / 1. Hide the foreground frontView.setVisibility(GONE); / / 2. Display the background (resources have been preloaded in the background at this point) backView.setVisibility(VISIBLE); / / 3. Start playing the background view backView.resumeAnimation(); / / 4. Exchange References LottieView temp = frontView; frontView = backView; backView = temp; / / 5. The original front-end (now back-end) begins preloading the next resource. preloadNextResource(backView); } }).

[0043] Building upon the above embodiments, to further optimize visual consistency during view switching, at least two animated views are overlapped in the same interface position, and all layout parameters of each animated view are consistent except for the Z-axis hierarchy parameter. In one embodiment, all layout attributes of the two animated views, such as coordinate origin, width, height, anchor point, padding, margin, scaling, and alignment, are set to the same value. The display priority is distinguished only by the Z-axis hierarchy parameter, thereby achieving a completely overlapping layout. The advantage of this setting is that when a background animated view is switched to the foreground, the animation is seamlessly presented within the same display area on the screen. There will be no visual jumps, misalignments, flickering, or stretching distortions due to view position shifts, size differences, scaling inconsistencies, or alignment deviations, ensuring an extremely smooth and seamless switching process from a visual perspective.

[0044] Those skilled in the art will understand that the above-mentioned methods for achieving a completely overlapping display effect include: placing two animated views within the same parent container and configuring identical container constraints, using the same constraint layout parameters, setting the same fill rules and clipping regions, and unifying view measurement and layout logic. Regardless of the specific layout method used, as long as the display area, rendering range, and visual position of the two animated views on the screen are completely overlapping, it constitutes a technical means substantially the same as this solution and falls within the protection scope of this application.

[0045] To address the issue of reliably executing the role switching between foreground and background views, this application provides the following preferred solution. The switching operation performed in step S204 includes exchanging the foreground / background identifiers of the foreground animation view and the background animation view. Specifically, the foreground / background identifier is marking information used to distinguish the current working role of a view, which can be implemented through view marker bits, state variables, object references, or hierarchical markers. After completing the view visibility switching and playback initiation, by exchanging the foreground / background identifiers, the working role of each view in the next cycle can be accurately marked and distinguished. That is, it clarifies which view will act as the new foreground animation view to undertake the playback task and which view will act as the new background animation view to undertake the background preloading task in the next cycle. This ensures that the two animation views alternate stably according to the "foreground playback - background preloading" cycle, guaranteeing the logical consistency, timing correctness, and execution reliability of the double-buffered pipeline's cyclic execution. It avoids loading conflicts, playback errors, or switching failures caused by role confusion, thereby ensuring the logical correctness of the cyclic alternation.

[0046] To further optimize the reliability and efficiency of view switching in the above embodiments, this application also provides the following preferred solution. In this preferred solution, the method of switching the background animation view to the foreground animation view includes: raising the Z-axis level of the background animation view to the top level, or setting the visibility attribute of the background animation view to visible.

[0047] Specifically, by elevating the Z-axis hierarchy of the background animation view, it can be placed at the top of the 3D interface hierarchy, directly covering the original foreground animation view and becoming visible. Conversely, by setting the visibility attribute of the background animation view to visible, its display state can be directly controlled, allowing it to quickly enter the playback interface. Both methods can complete the view switching action within 10 milliseconds. Combined with the persistence of vision effect, this achieves seamless animation transitions without perceptible delays or black screens, ensuring the smoothness and stability of continuous animation playback and effectively avoiding visual interruptions caused by resource loading and switching.

[0048] In one example, in the Android system, the Z-axis level can be adjusted by calling the `setElevation()` method, or visibility can be controlled using `setVisibility(View.VISIBLE)` and `setVisibility(View.GONE)`. As a specific implementation, the above process can be based on a container layer. This container layer (e.g., FrameLayout) manages the layout and Z-axis level of each animated view in the target view group. The two animated views, as child views of this container layer, have their positions and sizes uniformly constrained by the container layer. By adjusting the Z-axis level or visibility properties of the child views, the container layer can precisely control which animated view is in the foreground visible state and which is in the background, in a preloaded state. This switching method is simple to operate, responds quickly, and enables instantaneous switching of animated views, ensuring seamless playback of continuous animations.

[0049] In one specific implementation, when the foreground animation view finishes playing, the Z-axis layer of the background animation view is raised to its maximum, covering the original foreground animation view, while the Z-axis layer of the original foreground animation view is lowered or hidden. This design provides a clear and efficient switching control mechanism, enabling the pre-loaded background view to reliably cover the current view the instant the animation finishes playing, achieving foreground display without delay.

[0050] This application provides two direct and efficient switching methods for achieving the role transition between foreground and background views. In principle, for views in an overlapping layout, raising a view's Z-axis hierarchy (i.e., placing it on top of all overlapping views) allows it to immediately cover the lower-level views and be presented to the user. Similarly, resetting the visibility property of a view that was set to invisible (GONE or INVISIBLE) to visible will also make it immediately displayed. Both methods achieve instantaneous role switching. Neither operation involves the creation or destruction of views; they only modify a few view properties, resulting in minimal execution overhead, typically completed within milliseconds, thus ensuring real-time switching.

[0051] In one example, such as Figure 3 As shown, two overlapping animated view controls, LottieView1 and LottieView2, are set up in the same display area. They are located in the same container, and except for the Z-axis level, all other layout parameters such as width, height, coordinate position, anchor point, margin, and scaling ratio are completely identical to ensure that the two are completely overlapped in the visual display area without offset or misalignment.

[0052] Two animation view controls, controlled by Z-axis hierarchy or visibility properties, alternately act as the foreground playback view and the background preloading view, forming a double-buffered alternating working mechanism. Specifically, when LottieView1 is in the foreground display layer, it is visible and responsible for loading, rendering, and playing the current animation resource. Simultaneously, LottieView2 is in the background hidden layer, asynchronously executing the reading, parsing, and playback entity construction of the next animation resource without affecting the foreground display, and completing the background preloading operation.

[0053] When the current animation clip on LottieView1 finishes playing, immediately execute the view switching action: bring LottieView2 to the top foreground or make it visible, so that it can directly start playing the next animation that has been preloaded; at the same time, bring the original foreground LottieView1 down to the bottom background or make it hidden, and let it start preloading the animation resources to be played later.

[0054] Subsequently, LottieView1 and LottieView2 continue to work alternately in a loop according to the above rules, always keeping one view in the foreground and the other view in the background in a parallel processing state, avoiding playback gaps caused by resource loading, and finally achieving continuous and seamless playback between multiple animation segments without black screens, stutters, or delays.

[0055] In another embodiment, when faced with scenarios involving the continuous playback of extremely long animation sequences, or when the computing power of the vehicle's infotainment chip is limited and high-load tasks such as simultaneous camera recognition, vehicle network, and central control interface operation are running, animation loading time becomes unstable. Multi-view functionality is used to provide pre-loading redundancy and offset hardware fluctuations. In one example, such as... Figure 4 As shown, three animated view controls (LottieView1, LottieView2, and LottieView3) are overlapped in the same position on the interface, with all layout parameters identical except for the Z-axis hierarchy. The animation playback process is as follows: 1. In the initial state: LottieView1: Set as the foreground view to display and play the first animation clip; LottieView2: Set as the first background view, asynchronously preload the second animation clip; LottieView3: Set as the second background view, asynchronously preload the third animation clip.

[0056] 2. First switch (segment 1 complete): Hide LottieView1, bring LottieView2 to the foreground and start playing it immediately; move LottieView1 to the background and preload the 4th animation clip; LottieView3 continues to be preloaded.

[0057] 3. Second switch (second segment completed): Hide LottieView2, bring LottieView3 to the foreground and start playing it immediately; move LottieView2 to the background and preload the 5th animation clip. 4. The three views cycle in a loop, acting as the foreground in the order of LottieView1→LottieView2→LottieView3→LottieView1→LottieView2…, always maintaining: one foreground view playing and two background views preloading in parallel. The switching trigger condition is: the next switch is always triggered when the current foreground view finishes playing, without interruption, waiting, or loading gaps.

[0058] To clarify the specific steps of background preloading and ensure that the animation can play immediately upon switching, this preferred solution defines the preloading process. Preloading includes: reading and parsing the animation file, and generating the animation playback entity. Specifically, reading the animation file refers to reading the JSON or binary file of the Lottie animation; parsing the animation file refers to performing structured decoding on the read data, including parsing layers, keyframes, color attributes, transformation attributes, etc.; generating the animation playback entity refers to constructing an internal entity object (such as LottieComposition or a similar entity) based on the parsing results, which can be directly called, rendered, and played by the Lottie animation control. By sequentially performing the three steps of file reading, data parsing, and entity construction, the background animation view completes the entire process of preparing the animation resources from file data to a playable entity before being switched to the foreground, rather than just completing file reading or partial parsing. This ensures that after a view switch, the new foreground animation view can start playing instantly, without waiting for IO reading, JSON parsing, or object construction. The animation switching time is controlled within 10 milliseconds. Combined with the persistence of vision effect, this truly achieves a seamless, continuous animation switching experience without waiting, stuttering, or black screens, fundamentally solving the playback interruption and visual stuttering problems caused by the traditional single-control serial loading mode.

[0059] Optionally, preloading can include more steps, such as decoding bitmap resources and building a rendering object tree, but it must include at least the three core steps mentioned above. The principle is that directly mapping the animation file to a playable entity usable by the view is equivalent to completing the entire "loading-parsing-preparation" process. If only the file is read without parsing and entity generation, the view will still need to spend time parsing after switching, which will disrupt the seamless transition. By clearly defining the criteria for preloading completion—that is, a usable animation playable entity must be generated—the animation resources of the background view are fully ready, and the user will not perceive any loading delay.

[0060] To further optimize the speed and stability of background preloading in the above embodiments, this application also provides the following preferred solution. In this preferred solution, the animation clip resources come from local storage files or memory cache. Specifically, local storage files include animation resource files pre-stored in the device's local disk and built-in flash memory; the memory cache is a dedicated cache area allocated in the device's running memory, used to store loaded and parsed animation entity objects, enabling instantaneous reading and reuse. The above limitations clearly define the acquisition path and storage medium of animation resources, ensuring from the source that the background preloading process has the characteristics of low latency, high stability, and high reliability.

[0061] Compared to fetching resources from the network, cloud, or other slow remote storage media, local storage and memory caching offer high-speed read and write capabilities at the nanosecond to microsecond level. Resource retrieval time is extremely short, predictable, and negligible, stably meeting the stringent timing and speed requirements of preloading. This setting effectively avoids problems such as preloading failures, loading timeouts, resource missing, or playback stuttering caused by uncontrollable external factors such as network fluctuations, insufficient bandwidth, signal interruptions, remote server response delays, or connection timeouts. It constrains resource acquisition time within a deterministic, controllable, and extremely low range, thereby ensuring the stability and smoothness of the entire animation playback solution.

[0062] This ensures the stable execution of the background preloading process under the dual buffering mechanism, allowing the animation view to play immediately when switched to the foreground. This further guarantees that continuous animation playback is free of black screens, stutters, and waiting, significantly improving the stability, smoothness, and consistency of user experience.

[0063] In one example, within an in-vehicle infotainment system, all gesture training animation resources are pre-stored in local files in the vehicle's storage or cached in memory for reuse after the initial load. In this scenario, the preloading process of the background view only involves fixed, controllable, and predictable time consumption for file reading, data parsing, and animation entity construction. There are no uncontrollable variables such as network latency, bandwidth fluctuations, or weak signals. This ensures stable performance that meets the stringent timing and speed requirements for seamless animation transitions, making it particularly suitable for the smooth operation of in-vehicle systems under high loads (such as camera gesture recognition and multi-tasking in the vehicle system).

[0064] Those skilled in the art will understand that animation resources can theoretically also originate from the network or a remote server. However, when using the seamless transition method for continuous animation provided in this application, to avoid network transmission delays, packet loss, connection timeouts, and other factors disrupting the seamless playback effect, an additional resource pre-caching mechanism must be added: before the animation playback sequence starts, the network resources are completely downloaded to local storage, or parsed and stored in a memory cache, so that the resources actually involved in preloading and playback are still local files or memory cache objects. Its resource acquisition and loading logic, time consumption characteristics, and implementation effect are completely equivalent to resources directly originating from the local storage, and thus still fall within the protection scope of this application.

[0065] Exemplary application scenarios In one application scenario, within an in-vehicle smart cockpit system, a gesture training application provides users with a series of continuous animated instructions to learn air gestures, such as swiping left and right, clenching a fist, or pressing with the palm. This application requires playing multiple Lottie animation clips sequentially, each demonstrating a gesture. In traditional solutions, individual animation views must be loaded and played sequentially, resulting in noticeable black screens or stutters during animation transitions. Users often miss key action prompts due to visual interruptions, significantly diminishing the training experience.

[0066] After adopting the animation playback method provided in this application, a target view group is created in the display area. This view group contains two Lottie animation views that overlap in the same interface position, denoted as the first animation view and the second animation view. Except for the Z-axis layer parameter, the layout parameters of these two views, such as coordinates, width, and height, are consistent, thereby ensuring that the animation content is seamlessly connected in the same physical position on the screen during switching, without causing visual jumps.

[0067] When a user first enters the gesture training interface, the electronic device sets the first animation view as the foreground animation view, loading and playing the first gesture animation clip, such as "raising the palm." Simultaneously, the second animation view is hidden, and a preloading operation is performed asynchronously in the background: reading the second gesture animation resource from a local storage file, parsing its JSON description file, decoding the bitmap resource, and generating an animation playback entity that can be played immediately. The entire preloading process involves only local files or memory caching, avoiding network latency and ensuring that the background view is ready before switching.

[0068] Once the first animated view finishes playing, the system triggers a switching operation. At the instant of switching, the processor elevates the second animated view to the top of the Z-axis hierarchy while simultaneously lowering the first animated view to the bottom, thus instantly swapping the foreground and background views. After the switch, the second animated view becomes the new foreground animated view and begins playing the second gesture animation, while the original first animated view becomes the background animated view, preloading the next animation resource in the background. During this process, the system synchronously swaps the foreground and background identifiers of the two views to ensure that subsequent preloading and switching operations always point to the correct view object.

[0069] This method allows two animated views to work alternately like a relay race, always ensuring that there is animation playing in the foreground and resources preloading in the background. In this scenario, the user cannot perceive the loading gaps, the gesture training process is seamless, and the switching latency between all animation segments is controlled within 10 milliseconds, completely imperceptible to the human eye. This allows the user to focus on learning gesture movements, significantly improving the immersion and smoothness of in-vehicle human-machine interaction. Even when the vehicle's processor is under high load, such as running a camera recognition module simultaneously, the method provided in this application can still maintain stable animation continuity performance, completely eliminating visual interruptions caused by resource loading.

[0070] Exemplary System Figure 5 The diagram shows the structure of an animation playback system provided in an embodiment of this application. The system includes a target view group 501, a preloading control module 502, and a switching control module 503. Wherein: The target view group 501 includes at least two animation views set in the display area. The animation views are used to independently complete the loading, parsing, rendering and playback of animation resources.

[0071] The preloading control module 502 is used to control the background animation view to asynchronously preload the next animation segment during the playback of the foreground animation view, complete resource reading, data parsing and animation playback entity construction, so that the background animation view is in a ready state that can be played immediately.

[0072] The switching control module 503 is used to switch the background animation view to the foreground animation view and start playback when the foreground animation view finishes playing. At the same time, it switches the original foreground animation view to the background animation view and triggers its preloading of subsequent animation segments.

[0073] See Figure 1 The hardware environment shown can be implemented by a processor executing computer programs from memory, or by hardware logic such as application-specific integrated circuits (ASICs) and field-programmable gate arrays (FPGAs), exhibiting excellent hardware and software adaptability and portability. Through modular division of labor, the system decouples playback control, preloading control, and switching control, ensuring operational efficiency while achieving parallel processing of foreground playback and background preloading. This fundamentally eliminates loading gaps, achieving a seamless animation transition effect.

[0074] To further optimize the system architecture and improve the stability and standardization of layout management and view switching, the animation playback system also includes a container layer.

[0075] The container layer is used to uniformly manage the layout parameters, display position, size, and Z-axis hierarchy of each animated view in the target view group, ensuring that all animated views are completely overlapped within the same display area. For example, the container layer can use standard view containers such as FrameLayout, RelativeLayout, or ConstraintLayout to accommodate and constrain the position and hierarchy of two animated views. The switching control module 503 performs switching operations by controlling the Z-axis hierarchy of each animated view in the container layer or by calling the view visibility property. Specifically, the switching control module 503 can call the bringChildToFront() method provided by the container layer to promote a specified child view to the top level, or call the setVisibility() method to directly switch the view's display / hide state, achieving fast, stable, and low-latency view switching. This architectural design separates the switching logic from the view layout, reduces the coupling between modules, and significantly improves the maintainability, scalability, and reusability of the code.

[0076] In a preferred embodiment, the container layer employs a custom container specifically designed to manage double-buffering logic. This container encapsulates the complete logic for creating, initializing, overlapping layouts, hierarchical control, state switching, and resource management of the two views, shielding them from the complex details of double-buffering alternation. Each animated view in the target view group is a Lottie animation playback control. The two controls are completely overlapping in the same position, with identical layout parameters such as size, position, alignment, and anchor points. The foreground and background display priorities are distinguished only by the Z-axis hierarchy or the elevation property.

[0077] In a preferred embodiment, the container layer employs a container that manages double-buffering logic. This container encapsulates the logic for creating, laying out, switching, and managing resources for both views. Each animated view in the target view group is a Lottie animation playback control, overlapping in the same position with only the Z-axis parameter differing. For example, the container layer is specifically a `DoubleBufferLottieContainer` class, which contains two `LottieView` instances. It holds and manages these two `LottieView` instances, automatically maintaining the alternation of roles between the foreground and background views. This custom container provides standardized interfaces for setting the animation resource list, starting playback, pausing playback, stopping playback, and looping playback, eliminating the need for external callers to concern themselves with underlying logic such as preloading timing, switching timing, and view reference exchange. This design deeply integrates the double-buffering concept with UI animation playback scenarios, effectively solving problems such as playback blocking, visual interruption, stuttering, and black screens caused by sequential resource loading of a single view. It also simplifies upper-level calling logic, significantly enhancing code reusability, stability, and portability, making it particularly suitable for application environments with stringent smoothness requirements, such as in-vehicle infotainment systems and high-load UI interaction scenarios.

[0078] Exemplary media and products This application also provides a computer storage medium storing computer execution instructions. When the processor executes the computer execution instructions, the above-described animation playback method is implemented.

[0079] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the above-described animation playback method.

[0080] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0081] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0082] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0083] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0084] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0085] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. Both the processor and the storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.

[0086] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0087] This application also provides an in-vehicle entertainment device. This in-vehicle entertainment device includes any embodiment of the aforementioned animation playback system. Specifically, the animation playback system is installed in the vehicle's center console or rear-seat entertainment system, presenting continuous, seamless animations to the user via the in-vehicle screen, such as guidance animations for gesture training, dynamic navigation route displays, and dashboard transition animations. Due to the limited processor performance and high real-time requirements in the in-vehicle environment, this application significantly reduces visual stuttering caused by resource loading and improves the smoothness of user interaction in in-vehicle scenarios through a multi-view alternating preloading mechanism. This in-vehicle entertainment device can also be linked with vehicle cameras, sensors, and other components to maintain stable animation playback performance even under high-load scenarios.

[0088] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An animation playback method, characterized in that, include: The currently loaded animation clip is played using the foreground animation view in the target view group, which includes at least two animation views set in the display area. During the playback of the animation clip, the background animation view in the target view group is hidden. If a next animation clip exists, preload the next animation clip in the background animation view; After the animation clip in the foreground animation view finishes playing, hide the foreground animation view, switch the background animation view to the new foreground animation view, and return to the step of playing the currently loaded animation clip using the foreground animation view in the target view group, until the entire animation sequence has finished playing.

2. The animation playback method according to claim 1, characterized in that, The at least two animated views set in the display area are laid out overlapping in the same interface position, and the layout parameters of each animated view are consistent except for the Z-axis layer parameter.

3. The animation playback method according to claim 2, characterized in that, The methods for switching the background animation view to the foreground animation view include: raising the Z-axis level of the background animation view to the top level, or setting the visibility property of the background animation view to visible.

4. The animation playback method according to claim 1, characterized in that, The preloading includes: reading and parsing the animation file to generate an animation playback entity.

5. The animation playback method according to claim 1, characterized in that, The animated clips are sourced from local storage files or memory cache.

6. The animation playback method according to any one of claims 1-5, characterized in that, Switching the background animation view to a new foreground animation view includes: swapping the foreground / background identifiers of the foreground animation view and the background animation view.

7. The animation playback method according to claim 1, characterized in that, Also includes: When the entire animation sequence has finished playing, control the foreground animation view to remain displayed on the last frame of the animation, and release the animation resources occupied by each animation view.

8. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform the animation playback method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the animation playback method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, include: A computer program that, when executed by a processor, implements the animation playback method as described in any one of claims 1 to 7.

Images