A start-up animation playing method and vehicle

Abstract

The application belongs to the technical field of vehicle-mounted information entertainment, and provides a start-up animation playing method and a vehicle. The target player is set as an independent process and is started preferentially, so that the target player cannot be preempted by any ordinary system service during playing, and fast display of the start-up animation is realized. Lightweight decoding is adopted, so that resource occupation is significantly reduced, and playing is smooth without any lag or frame loss. After the display of the disclaimer is ended or skipped, the background source manager performs a source management operation on the current application data source according to state information, that is, when the disclaimer does not need to be displayed, the memory source can be directly switched to, and the intermediate interface is skipped, so that the time for entering the available state is further shortened. Therefore, fast and smooth playing of the start-up animation on a low-computing-power platform is realized.

Description

Technical Field

[0001] This invention belongs to the field of in-vehicle infotainment technology, specifically relating to a method for playing a boot animation and a vehicle. Background Technology

[0002] Currently, most in-vehicle infotainment (IVI) systems have the function of playing video animations upon startup. However, in low-end models with limited cost, the CPU computing power is low and only single-layer display is supported, thus presenting the following problems: (1) The startup timing is delayed, and the animation display is significantly delayed. IVIApp (in-vehicle application) is launched by AppManager (background source manager) according to the startup process, which results in a late loading time. In addition, the GUI decompression resource consumes CPU computing power, which causes the logo source to enter slowly. When the animation request is sent, the system is already in a high load state, resulting in a long waiting time for users.

[0003] (2) Resource competition causes animation playback stuttering. The animation playback is performed by MediaService (Multimedia Service). When the player is initialized, the CPU is preempted by other startup tasks, which causes slow loading of MP4 resources and stuttering or frame drops in the first few seconds of playback.

[0004] The above issues cause slow loading of the boot animation and stuttering playback, affecting the user experience. Summary of the Invention

[0005] The purpose of this invention is to disclose a boot animation playback method and vehicle, which solves the technical problems of slow loading, stuttering playback, and poor user experience of boot animations in existing in-vehicle infotainment systems.

[0006] To achieve the above objectives, this invention discloses a method for playing a boot-up animation, comprising: During system power-on and basic initialization, the independent process of the target player is launched first according to the boot script; The target player opens the animation resource in the preset path, performs lightweight decoding, and plays it. After the boot animation finishes playing, the target player reads the disclaimer display flag and selects to display the disclaimer based on the flag. A status message is issued after the disclaimer display ends or is skipped; The background source manager performs source management operations on the current application data source based on the status information.

[0007] This basic solution ensures that the target player is not preempted by any ordinary system services during playback by setting it as an independent process and prioritizing its startup, thus achieving fast display of the boot animation. The use of lightweight decoding significantly reduces resource consumption, resulting in smooth playback without stuttering or frame drops. After the disclaimer display ends or is skipped, the background source manager performs source management operations on the current application data source based on status information. This means that when the disclaimer is not needed, it can directly switch to the remembered source, skipping the intermediate interface and further shortening the time to reach a usable state. This enables fast and smooth playback of the boot animation on low-computing-power platforms.

[0008] As an optional implementation, during system power-on and basic initialization, the independent process of the target player is launched first according to the boot script, including: Set the target player as an independently running background process and set the corresponding process scheduling policy to real-time priority, giving it the highest real-time priority; After the system is powered on, the bootloader loads the operating system kernel, and the kernel completes the basic hardware initialization. Mount the root file system and start the first user-space process; The user-mode process executes the service startup command of the target player according to the configuration order of the startup script, prioritizing the startup of the target player's background process.

[0009] This solution sets the target player as an independently running background process and sets the corresponding process scheduling strategy to real-time priority, giving it the highest real-time priority to ensure that the target player's background process has absolute response priority. After kernel initialization, it directly connects to the priority startup strategy of the boot script, so that the target player can obtain CPU resources first after the system is powered on, effectively avoiding playback stuttering or delay caused by other processes competing for resources, and improving the real-time performance and smoothness of the boot animation playback.

[0010] As an optional implementation, the target player opens the animation resource in the preset path, performs lightweight decoding, and plays it, including: The target player opens the animation resource file in the preset path: The target player calls its built-in lightweight decoder to perform lightweight decoding on the animation resource file, decoding frame by frame to obtain the boot animation data; The target player writes the decoded boot animation data to the frame buffer device and plays the boot animation content.

[0011] This solution is based on a target player built with a lightweight decoder. It performs lightweight and efficient decoding of animation resource files, which reduces resource consumption. It decodes frame by frame and writes directly to the frame buffer, resulting in a short path and low latency, ensuring a smooth and stable boot animation.

[0012] As an optional implementation, it also includes: if the animation resource file fails to be obtained or the file decoding is incorrect, a preset static boot image is obtained and written to the frame buffer device for static display at boot.

[0013] This solution uses a preset static image as a reliable fallback option when animation loading fails, ensuring that the boot screen can be displayed normally under any abnormal circumstances, thereby improving the user experience and the robustness of the device startup process.

[0014] As an optional implementation, after the boot animation finishes playing, the target player reads the disclaimer display flag and selects to display the disclaimer based on the flag, including: After the boot animation finishes playing, the target player reads the disclaimer display flag sent by the MCU; When the disclaimer display flag indicates that the disclaimer is not displayed, the target player sends a boot animation end message to the background source manager based on the DBUS caching mechanism and exits to release resources. When the disclaimer display flag indicates that a disclaimer is to be displayed, the target player sends a boot animation end message to the in-vehicle application based on the DBUS caching mechanism, and then exits to release resources. After receiving the message that displays a disclaimer, the in-vehicle application enters the WARNING source, where the disclaimer is displayed.

[0015] As an optional implementation, a boot animation end message is sent based on the DBUS caching mechanism, including: Configure DBUS to enable the message caching mechanism; The target player sends a boot animation end message to the DBUS daemon; The DBUS daemon checks whether the target receiver has already registered on the bus. If so, it directly sends the boot animation end message to the target receiver; otherwise, it stores the boot animation end message in the cache queue and records the timestamp and retry counter. The DBUS daemon periodically delivers messages to the cache queue. If the delivery is successful, the boot animation end message is removed from the cache queue. If delivery still fails after reaching the maximum number of retries, the DBUS daemon logs an error and continues to run.

[0016] This solution utilizes a DBUS caching mechanism to achieve precise timing synchronization between the boot animation and the disclaimer display. It flexibly controls the disclaimer display process based on MCU flags, allowing for skipping the display process and quickly releasing resources based on the disclaimer display flag, or allowing the in-vehicle application to directly take over the WARNING source. This reduces intermediate waiting and interaction, significantly shortening the system's time to reach a usable state when the disclaimer is not needed, and ensuring timely presentation of the disclaimer when required. The target player exits and releases resources after sending the boot animation end message, ensuring thorough system resource reclamation and handover of screen control, avoiding memory leaks and resource consumption, thus guaranteeing the stability and smoothness of subsequent application startup processes.

[0017] As an optional implementation, the background source manager performs source management operations on the current application data source based on the status information, including: If the status information includes a boot animation end message, the background source manager notifies the vehicle application to skip the WARNING source and enter the HOME interface; If the status information includes a message indicating the end of the disclaimer display, then the in-vehicle application is notified to enter the HOME screen.

[0018] As an optional implementation, in the boot script, the startup command of the target player is placed before other startup commands, including startup commands for the corresponding in-vehicle application, background source manager, and multimedia service.

[0019] This solution places the target player's startup command before other startup commands in the boot script, ensuring that the target player starts first, which can shorten its readiness time and allow users to get audio and video playback response faster. At the same time, it avoids delays in player initialization due to other services occupying system resources.

[0020] The present invention also provides a vehicle, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement a boot animation playback method as described above. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a boot animation playback method provided in an embodiment of the present invention. Detailed Implementation

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

[0024] In this invention, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing the invention and its embodiments, and are not intended to limit the indicated devices, elements, or components to having a specific orientation, or to be constructed and operated in a specific orientation.

[0025] Furthermore, in addition to indicating direction or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in certain situations to indicate a dependency or connection. Those skilled in the art can understand the specific meaning of these terms in this invention based on the specific circumstances.

[0026] Furthermore, the terms "installation," "setup," "equipped with," "connection," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral structure; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of these terms in this invention based on the specific circumstances.

[0027] Furthermore, the terms "first," "second," etc., are primarily used to distinguish different devices, components, or parts (which may be the same or different in specific type and construction), and are not intended to indicate or imply the relative importance or quantity of the indicated devices, components, or parts. Unless otherwise stated, "a plurality of" means two or more.

[0028] The technical solution of the present invention will be further described below with reference to the embodiments and accompanying drawings.

[0029] Example 1 Please see Figure 1 As shown in the figure, this application embodiment provides a method for playing a boot animation, including: S0. Set the target player as an independently running background process and set the corresponding process scheduling policy to real-time priority, giving it the highest real-time priority; Specifically, to ensure that the animation playback is not interfered with by other system services, the target player is set as an independent service, the process scheduling policy is set to real-time priority (such as SCHED_FIFO), and the highest real-time priority is given to ensure that it will not be preempted by any ordinary system service during playback.

[0030] S1. System power-on and basic initialization, including: After the system is powered on, the bootloader loads the operating system kernel, and the kernel completes the basic hardware initialization. Mount the root file system and start the first user-space process; Specifically, after the system powers on, the bootloader loads the operating system kernel, which completes basic hardware initialization, including the CPU, memory, interrupt controller, and storage controller. Then, the root file system is mounted, and the first user-mode process (such as the init process) is started.

[0031] This solution sets the target player as an independently running background process and sets the corresponding process scheduling strategy to real-time priority, giving it the highest real-time priority to ensure that the target player's background process has absolute response priority. After kernel initialization, it directly connects to the priority startup strategy of the boot script, so that the target player can obtain CPU resources first after the system is powered on, effectively avoiding playback stuttering or delay caused by other processes competing for resources, and improving the real-time performance and smoothness of the boot animation playback.

[0032] S2. Based on the startup script, prioritize starting the target player's independent process, specifically: The user-mode process executes the service startup command of the target player according to the configuration order of the startup script, prioritizing the startup of the target player's background process.

[0033] In this embodiment, in the boot script, the startup command for the target player is placed before other startup commands, including the startup commands for the corresponding in-vehicle application (IVIApp), the background source manager (AppManager), and the multimedia service (MediaService). The user-mode process executes the service startup commands according to the configuration order of the boot script.

[0034] In this embodiment, APPManager is the background source manager, and IVIApp is the GUI (graphical user interface), which includes the various sources that are actually displayed: WARNING, HOME, RADIO, USB, etc. The default source at startup is WARNING.

[0035] Specifically, the LogoPlayer process is started immediately after the file system is mounted and the frame buffer device ( / dev / fb0) is initialized. At this time, high-load processes such as AppManager, IVIApp, and MediaService are not yet running in the system.

[0036] This solution places the target player's startup command before other startup commands in the boot script, ensuring that the target player starts first, which can shorten its readiness time and allow users to get audio and video playback response faster. At the same time, it avoids delays in player initialization due to other services occupying system resources.

[0037] S3. The target player opens the animation resource in the preset path, performs lightweight decoding, and plays it, including: S31. The target player opens the animation resource file in the preset path: The animation resource files include an MP4 format boot logo animation, which is stored in a read-only partition accessible early in the boot process. The resolution of the animation resource files does not exceed the screen's physical resolution (e.g., no more than 800×480), the video encoding is H.264, the bitrate does not exceed 1.5Mbps, and the frame rate does not exceed 30fps.

[0038] S32. The target player calls the built-in lightweight decoder to perform lightweight decoding on the animation resource file, and decodes frame by frame to obtain the boot animation data. The lightweight decoder does not rely on any system multimedia framework and directly outputs raw pixel data. It uses a trimmed lightweight decoding library (such as a simplified version of libavcodec) and disables post-processing filtering to reduce CPU load.

[0039] S33. The target player writes the decoded boot animation data to the frame buffer device and displays the boot animation content in full screen starting from the first frame.

[0040] Since no other processes are competing for CPU and display resources at this time, the boot animation plays smoothly without any stuttering.

[0041] S34. If the animation resource file fails to be obtained or the file decoding is incorrect, the preset static boot image is obtained and written to the frame buffer device for static display at boot.

[0042] Specifically, if the target player fails to open the boot animation file (e.g., file does not exist, format is not supported) or an unrecoverable error occurs during decoding, it will not attempt to continue playing the boot animation. Instead, it will directly draw a preset static boot image on the frame buffer device (stored in the target player's program segment) and display it for a fixed time (e.g., 500 milliseconds). Then, it will send a boot animation end message according to the subsequent steps and exit normally, ensuring that the system startup process is not blocked.

[0043] This solution uses a preset static image as a reliable fallback option when animation loading fails, ensuring that the boot screen can be displayed normally under any abnormal circumstances, thereby improving the user experience and the robustness of the device startup process.

[0044] This solution is based on a target player built with a lightweight decoder. It performs lightweight and efficient decoding of animation resource files, which reduces resource consumption. It decodes frame by frame and writes directly to the frame buffer, resulting in a short path and low latency, ensuring a smooth and stable boot animation.

[0045] S4. After the boot animation finishes playing, the target player reads the disclaimer display flag and selects to display the disclaimer according to the flag, including: After the boot animation finishes playing, the target player reads the disclaimer display flag sent by the MCU; for example, the disclaimer display flag value is 0 or 1.

[0046] When the disclaimer display flag indicates that the disclaimer is not displayed, the target player sends a boot animation end message to the background source manager based on the DBUS caching mechanism and exits to release resources. When the disclaimer display flag indicates that a disclaimer is to be displayed, the target player sends a boot animation end message to the in-vehicle application based on the DBUS caching mechanism, and then exits to release resources. After receiving the message that displays a disclaimer, the in-vehicle application enters the WARNING source, where the disclaimer is displayed.

[0047] In this embodiment, specifically: After receiving the message to display the disclaimer, the in-vehicle application enters the WARNING source, where the disclaimer is displayed. The WARNING source waits for the user to click to confirm or for the countdown to end before sending a confirmation message or a countdown end message to the background source manager.

[0048] After the target player completes message sending (or times out), it proactively releases the memory occupied by the decoder, closes the animation file handle, closes the frame buffer device reference, and exits its own process. Afterward, screen control is completely transferred to the background source manager or in-vehicle application, and the system continues its subsequent startup process.

[0049] In this embodiment, sending the boot animation end message based on the DBUS caching mechanism includes: A0. Configure DBUS to enable the message caching mechanism; A1. The target player sends a boot animation end message to the DBUS daemon process; A2. The DBUS daemon checks whether the target receiver has already registered on the bus. If so, it directly sends the boot animation end message to the target receiver. Otherwise, it stores the boot animation end message in the cache queue and records the timestamp and retry counter. The target recipient is either a background source manager or an in-vehicle application, depending on whether a disclaimer needs to be displayed. The cache queue operates on a first-in, first-out (FIFO) principle.

[0050] A3. The DBUS daemon periodically delivers messages to the cache queue. If the delivery is successful, the boot animation end message is removed from the cache queue. Specifically, the DBUS daemon attempts to redeliver the message every 100 milliseconds, up to a maximum of three times; it continuously attempts to send the end-of-boot animation message to the target receiver. Once the target receiver has registered and come online, the message is immediately delivered successfully and removed from the cache queue.

[0051] A4. If delivery still fails after reaching the maximum number of retries, the DBUS daemon logs the error and continues to run without blocking system startup.

[0052] This solution utilizes a DBUS caching mechanism to achieve precise timing synchronization between the boot animation and the disclaimer display. It flexibly controls the disclaimer display process based on MCU flags, allowing for skipping the display process and quickly releasing resources based on the disclaimer display flag, or allowing the in-vehicle application to directly take over the WARNING source. This reduces intermediate waiting and interaction, significantly shortening the system's time to reach a usable state when the disclaimer is not needed, and ensuring timely presentation of the disclaimer when required. The target player exits and releases resources after sending the boot animation end message, ensuring thorough system resource reclamation and handover of screen control, avoiding memory leaks and resource consumption, thus guaranteeing the stability and smoothness of subsequent application startup processes.

[0053] S5. Issue a status message after the disclaimer display ends or is skipped; Specifically, if a disclaimer needs to be displayed, the WARNING source will send the user confirmation message or countdown end message as status information to the background source manager after the user clicks to confirm or the countdown ends. If the disclaimer display flag indicates that it should not be displayed, the target player will directly send the boot animation end message as status information to the background source manager.

[0054] S6. The background source manager performs source management operations on the current application data source based on the status information, including: If the status information includes a boot animation end message, the background source manager notifies the in-vehicle application to skip the WARNING source and enter the HOME interface (i.e., the overview home screen). If the status information includes a message indicating the end of the disclaimer display, then the in-vehicle application is notified to enter the HOME screen.

[0055] Example 2 This invention also provides a vehicle, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements a boot animation playback method as described in Embodiment 1 above.

[0056] This invention achieves rapid boot animation display by setting the target player as an independent process and prioritizing its startup, ensuring it is not preempted by any ordinary system services during playback. The use of lightweight decoding significantly reduces resource consumption, resulting in smooth playback without stuttering or frame drops. After ending or skipping the disclaimer display, the background source manager performs source management operations on the current application data source based on status information. That is, when the disclaimer is not needed, it can directly switch to the remembered source, skipping the intermediate interface and further shortening the time to reach an available state. This enables fast and smooth boot animation playback on low-computing-power platforms.

[0057] The technical means disclosed in this invention are not limited to those disclosed in the above embodiments, but also include technical solutions composed of any combination of the above technical features. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications are also considered within the scope of protection of this invention.

Claims

1. A method for playing a boot animation, characterized in that, include: During system power-on and basic initialization, the independent process of the target player is launched first according to the boot script; The target player opens the animation resource in the preset path, performs lightweight decoding, and plays it. After the boot animation finishes playing, the target player reads the disclaimer display flag and selects to display the disclaimer based on the flag. A status message is issued after the disclaimer display ends or is skipped; The background source manager performs source management operations on the current application data source based on the status information.

2. The boot animation playback method as described in claim 1, characterized in that, During system power-on and basic initialization, the target player's independent process is launched first according to the boot script, including: Set the target player as an independently running background process and set the corresponding process scheduling policy to real-time priority, giving it the highest real-time priority; After the system is powered on, the bootloader loads the operating system kernel, and the kernel completes the basic hardware initialization. Mount the root file system and start the first user-space process; The user-mode process executes the service startup command of the target player according to the configuration order of the startup script, prioritizing the startup of the target player's background process.

3. The boot animation playback method as described in claim 1, characterized in that, The target player opens the animation resource in the preset path, performs lightweight decoding, and plays it, including: The target player opens the animation resource file in the preset path: The target player calls its built-in lightweight decoder to perform lightweight decoding on the animation resource file, decoding frame by frame to obtain the boot animation data; The target player writes the decoded boot animation data to the frame buffer device and plays the boot animation content.

4. The boot animation playback method as described in claim 3, characterized in that, Also includes: If the animation resource file fails to be obtained or the file decoding fails, a preset static boot image is obtained and written to the frame buffer device for static display at boot.

5. The boot animation playback method as described in claim 1, characterized in that, After the boot animation finishes playing, the target player reads the disclaimer display flag and selects to display the disclaimer based on the flag, including: After the boot animation finishes playing, the target player reads the disclaimer display flag sent by the MCU; When the disclaimer display flag indicates that the disclaimer is not displayed, the target player sends a boot animation end message to the background source manager based on the DBUS caching mechanism and exits to release resources. When the disclaimer display flag indicates that a disclaimer is to be displayed, the target player sends a boot animation end message to the in-vehicle application based on the DBUS caching mechanism, and then exits to release resources. After receiving the message that displays a disclaimer, the in-vehicle application enters the WARNING source, where the disclaimer is displayed.

6. The boot animation playback method as described in claim 5, characterized in that, Sending the boot animation end message based on the DBUS caching mechanism, including: Configure DBUS to enable the message caching mechanism; The target player sends a boot animation end message to the DBUS daemon; The DBUS daemon checks whether the target receiver has already registered on the bus. If so, it directly sends the boot animation end message to the target receiver; otherwise, it stores the boot animation end message in the cache queue and records the timestamp and retry counter. The DBUS daemon periodically delivers messages to the cache queue. If the delivery is successful, the boot animation end message is removed from the cache queue. If delivery still fails after reaching the maximum number of retries, the DBUS daemon logs an error and continues to run.

7. The boot animation playback method as described in claim 5, characterized in that, The background source manager performs source management operations on the current application data source based on the status information, including: If the status information includes a boot animation end message, the background source manager notifies the vehicle application to skip the WARNING source and enter the HOME interface; If the status information includes a message indicating the end of the disclaimer display, then the in-vehicle application is notified to enter the HOME screen.

8. The boot animation playback method as described in claim 2, characterized in that: In the startup script, the startup command for the target player is placed before other startup commands, including startup commands for the corresponding in-vehicle application, background source manager, and multimedia service.

9. A vehicle comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements a boot animation playback method as described in any one of claims 1 to 8.

Images