Animation synchronization method, device and system for segmented startup of vehicle-mounted multi-system

Abstract

The invention discloses an animation synchronization method, device and system for segmented startup of a vehicle-mounted multi-system. The method comprises the steps that in the process that a first vehicle-mounted system plays a startup animation, the starting state of a second vehicle-mounted system is obtained through a cross-system channel between the first vehicle-mounted system and the second vehicle-mounted system, and the first vehicle-mounted system is started earlier than the second vehicle-mounted system; under the condition that the starting state of the second vehicle-mounted system is not started, continuing to play the starting animation of the first vehicle-mounted system; and under the condition that the starting state of the second vehicle-mounted system is a starting state, switching the playing content from the starting animation of the first vehicle-mounted system to the starting animation of the second vehicle-mounted system. According to the method and the device, the technical problem of unsmooth connection of multi-system segmented startup animations in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of automotive control, and more specifically, to an animation synchronization method, device, and system for segmented startup of multiple in-vehicle systems. Background Technology

[0002] This section is intended to provide background or context for the content set forth in the claims or specification, and the content described herein is not acknowledged as prior art simply because it is included in this section.

[0003] In automotive multi-system solutions, a hypervisor, also known as a virtual machine monitor (VMM), is commonly used. It's the software, firmware, or hardware used to create and execute virtual machines. The computer used by the hypervisor to run one or more virtual machines is called the host machine, and these virtual machines are called guest machines. The hypervisor provides a virtual operating platform to execute guest operating systems and manages the execution phase of these guest operating systems; these guest operating systems share the virtualized hardware resources.

[0004] When multiple in-vehicle systems start up, they each play their own boot animation on the display. However, the boot duration of each system varies, which can lead to issues with the smooth transitions between these segmented boot animations. Currently, no effective solution has been proposed to address this technical problem of uneven transitions between these segmented boot animations. Summary of the Invention

[0005] This application provides an animation synchronization method, device, and system for segmented startup of multiple systems in a vehicle, so as to at least solve the technical problem of unsmooth transitions in segmented startup animations of multiple systems in related technologies.

[0006] According to one aspect of the embodiments of this application, a method for synchronizing the segmented startup animation of multiple vehicle systems is provided, comprising: during the playback of a startup animation of a first vehicle system, obtaining the startup status of the second vehicle system through a cross-system channel between the first vehicle system and the second vehicle system, wherein the first vehicle system starts before the second vehicle system; if the startup status of the second vehicle system is not started, continuing to play the startup animation of the first vehicle system; if the startup status of the second vehicle system is started, switching the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system.

[0007] Optionally, obtaining the startup status of the second vehicle system through a cross-system channel between the first vehicle system and the second vehicle system includes: on the second vehicle system side, using the cross-system channel to synchronize the startup status of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system; on the first vehicle system side, during the rendering cycle of each animation frame of the startup animation of the first vehicle system, using a status listener to listen for the startup status of the second vehicle system in the user space of the first vehicle system.

[0008] Optionally, using the cross-system channel to synchronize the startup status of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system includes: when the second vehicle system starts in normal mode, the process of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value, and generates a status coordination instruction to carry the system attribute as the second value. An attribute change trigger in the second vehicle system then uses the cross-system channel to send the status coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system. The system attribute is used to indicate the startup status of the second vehicle system; the first value indicates that the second vehicle system is not started, and the second value indicates that the second vehicle system is started. Alternatively, when the second vehicle system starts in recovery mode, the initialization script of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value during runtime, and generates a status coordination instruction to carry the system attribute as the second value. An attribute change trigger in the second vehicle system then uses the cross-system channel to send the status coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system.

[0009] Optionally, before synchronizing the startup state of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system using the cross-system channel, the method further includes: configuring system attributes in the second vehicle system and initializing the attribute values ​​of the system attributes to a first value.

[0010] Optionally, before synchronizing the startup state of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system using the cross-system channel, the method further includes: establishing a cross-system channel between the first vehicle system and the second vehicle system based on vsocket technology, wherein the cross-system channel is used as a transmission channel for state coordination instructions, and the state coordination instructions are used to carry the attribute values ​​of the system attributes.

[0011] Optionally, a status listener is used to listen to the startup status of the second vehicle system from the user space of the first vehicle system, including: running a playback service for the startup animation of the first vehicle system, wherein the playback service runs in an event-driven mode; and using the status listener in the playback service to continuously listen for status coordination instructions from the user space of the first vehicle system, wherein the status coordination instructions are used to indicate the startup status of the second vehicle system.

[0012] Optionally, when the second vehicle system is in an "off" state, the boot animation of the first vehicle system continues to play. Continuing to play the boot animation of the first vehicle system includes: if the system attribute carried by the state coordination instruction is a first value, and the boot animation of the first vehicle system has not reached its last frame, then continue playing the next frame of the boot animation of the first vehicle system; if the boot animation of the first vehicle system has reached its last frame, then continue playing the last frame of the boot animation of the first vehicle system. When the second vehicle system is in an "on" state, the playback content is switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system, including: if the system attribute carried by the state coordination instruction is a second value, then switch the playback content from the boot animation of the first vehicle system to the boot animation of the second vehicle system.

[0013] According to another aspect of the embodiments of this application, an animation synchronization device for segmented startup of multiple vehicle systems is also provided, comprising: an acquisition unit, configured to acquire the startup status of the second vehicle system through a cross-system channel between the first vehicle system and the second vehicle system during the playback of a startup animation of the first vehicle system, wherein the first vehicle system starts before the second vehicle system; a first playback unit, configured to continue playing the startup animation of the first vehicle system when the startup status of the second vehicle system is not started; and a second playback unit, configured to switch the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system when the startup status of the second vehicle system is started.

[0014] According to another aspect of the embodiments of this application, an animation synchronization system for segmented startup of multiple vehicle systems is also provided, including: a first vehicle system, a second vehicle system, and a cross-system channel located between the first vehicle system and the second vehicle system, wherein the first vehicle system starts before the second vehicle system; the second vehicle system is used to: transmit its own startup status to the first vehicle system through the cross-system channel; the first vehicle system is used to: continue playing the startup animation of the first vehicle system when the startup status of the second vehicle system is not started; and switch the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system when the startup status of the second vehicle system is started.

[0015] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the storage medium including a stored program that executes the above-described method when the program is run.

[0016] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor performs the above-described method through the computer program.

[0017] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the embodiments of the methods described above.

[0018] In this embodiment, during the playback of the boot animation of the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, with the first vehicle system starting before the second vehicle system. If the startup status of the second vehicle system is "not started," the boot animation of the first vehicle system continues to play. If the startup status of the second vehicle system is "started," the playback content is switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system. This allows the first vehicle system's boot animation to be played only before the second vehicle system starts, and the playback seamlessly switches to the second vehicle system's boot animation immediately upon startup, thus solving the technical problem of unsmooth transitions between segmented boot animations of multiple systems in related technologies. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of an animation synchronization scheme for segmented startup of multiple in-vehicle systems in a related technology. Figure 2 This is a schematic diagram of an animation synchronization system for segmented startup of multiple in-vehicle systems according to an embodiment of this application; Figure 3 This is a flowchart of an animation synchronization method for segmented startup of multiple vehicle systems according to an embodiment of this application; Figure 4 This is a schematic diagram of an animation synchronization scheme for segmented startup of multiple vehicle systems according to an embodiment of this application; Figure 5 This is a schematic diagram of an animation synchronization device for segmented startup of multiple in-vehicle systems according to an embodiment of this application; Figure 6 This is a structural block diagram of a terminal according to an embodiment of this application. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] In automotive multi-system solutions, taking the automotive Hypervisor multi-system solution as an example, Yocto (an open-source project that allows developers to customize Linux distributions, enabling the creation of a lightweight, highly configurable Linux distribution as a service operating system based on automotive needs) serves as the service operating system (SOS), typically responsible for managing critical system services such as hardware resource management, security monitoring, and system scheduling. Android (a free and open-source mobile operating system based on the Linux kernel) serves as the guest operating system (UOS, typically used to provide user interaction and entertainment functions, such as Android Auto and in-vehicle infotainment systems (IVI)). When the system boots up, the Yocto SOS, which starts first, plays the SOS logo for a period of time through the bootanimengine application. Then, the bootanimengine application exits, and the animation played during this period serves as the first stage of the boot animation. Afterward, the Android UOS, started by the Yocto SOS, launches the bootanimation process through the init initialization process to start playing the UOS logo. This continues until the Android Launcher is ready, at which point the bootanimation process exits and the UOS logo playback stops. The animation played during this period serves as the second stage of the boot animation.

[0023] from Figure 1 It can be seen that the actions of Yocto SOS's bootanimengine playing the logo and Yocto SOS launching Android UOS can occur in parallel. This means that the time difference T between the start of the second-stage animation and the end of the first-stage animation is greatly affected by the Android UOS startup time, and may be greater than 0 or less than 0, thus causing the following two defects: 1) T is much greater than 0, meaning that Android UOS will start a long time after the first stage animation of Yocto SOS ends (Android UOS starts slowly), which will result in an excessively long interval between the two animations, i.e., an excessively long black screen time in the middle, affecting the boot experience; 2) If T is less than 0, it means that the first stage animation of Yocto SOS has a long time to go before it ends, while Android UOS has already started (i.e., UOS starts too fast). This will cause the second stage animation to start playing before the first stage animation ends, meaning that the two animations will overlap and play alternately, which will seriously affect the user experience.

[0024] To address the above problems, according to one aspect of the embodiments of this application, a method embodiment of an animation synchronization method for segmented startup of multiple in-vehicle systems is provided.

[0025] Optionally, in this embodiment, the above-described animation synchronization method for segmented startup of multiple vehicle systems can be applied to the animation synchronization system for segmented startup of multiple vehicle systems of this application, such as... Figure 2 As shown, the system includes a first vehicle system (i.e., the service operating system SOS), a second vehicle system (the client operating system UOS), and a cross-system channel between the first and second vehicle systems. The first vehicle system starts up before the second vehicle system. The second vehicle system transmits its startup status to the first vehicle system through the cross-system channel. If the second vehicle system is not started, the first vehicle system continues to play the startup animation of the first vehicle system. If the second vehicle system is started, the playback content is switched from the startup animation of the first vehicle system to the startup animation of the second vehicle system.

[0026] The first and second vehicle systems mentioned above can run as guest operating systems on a virtualized operating platform (such as a hypervisor). This operating platform runs on a host machine, which can consist of one or more computer devices. The animation synchronization method for segmented startup of the vehicle multi-systems in this application embodiment can be executed by this host machine.

[0027] Figure 3 This is a flowchart of an animation synchronization method for segmented startup of multiple in-vehicle systems according to an embodiment of this application, such as... Figure 3 As shown, the method may include the following steps: Step S302: During the boot animation playback of the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems. The first vehicle system starts up before the second vehicle system.

[0028] The first in-vehicle system is a service operating system (SOS), such as Yocto SOS, and the second in-vehicle system is a client operating system (UOS), such as Android as UOS.

[0029] On the second system side, system properties can be configured, and their values ​​can be initialized to a first value. This system property, such as `service.bootanim.sos.exit`, uses its value to represent the startup status of the second system. A first value (e.g., 0) indicates the system is not started, while a second value (e.g., 1) indicates it is started. On the first system side, a boot animation playback service for the first vehicle system is pre-deployed. This service operates in an event-driven mode and includes a status listener to monitor the startup status of the second vehicle system. A cross-system channel is pre-established between the first and second vehicle systems, such as using vsocket (a virtualization-based communication technology that allows direct communication between virtual machines). This cross-system channel serves as a transmission channel for status coordination instructions, which carry the system property values.

[0030] In the above steps, after the first vehicle system starts up, a playback service for the boot animation of the first vehicle system is run. This playback service will continuously play the boot animation of the first vehicle system. At the same time, the status listener in the playback service continuously listens for status coordination instructions from the user space of the first vehicle system. The status coordination instructions are used to indicate the startup status of the second vehicle system.

[0031] After the second vehicle system starts up, it will use a cross-system channel to send state coordination commands from the user space of the second vehicle system to the user space of the first vehicle system. The specific implementation methods include the following two: 1) When the second vehicle system starts in normal mode, the process of the second vehicle system (e.g., the bootanimation process) replaces the attribute value of the system attribute of the second vehicle system from the first value to the second value, and generates a state coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system (an event triggering mechanism in the Android initialization system init, which automatically executes a preset command or action when the specified system attribute value changes) uses a cross-system channel to send the state coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system. The system attribute is used to indicate the startup status of the second vehicle system. The first value indicates that the second vehicle system has not started, and the second value indicates that the second vehicle system has started. 2) When the second vehicle system starts in recovery mode, the initialization script of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from the first value to the second value during runtime, and generates a state coordination instruction for carrying the system attribute with the second value. The attribute change trigger in the second vehicle system uses a cross-system channel to send the state coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system.

[0032] Step S304: If the second vehicle system is not started, continue playing the startup animation of the first vehicle system.

[0033] If the system attribute carried by the state coordination instruction is the first value, and the boot animation of the first vehicle system has not played to the last animation frame (i.e., the current animation frame is not the last animation frame), then the next animation frame in the boot animation of the first vehicle system (i.e. the animation frame after the aforementioned current animation frame) will continue to be played; if the boot animation of the first vehicle system has played to the last animation frame, then the last animation frame in the boot animation of the first vehicle system will continue to be played.

[0034] Step S306: When the second vehicle system is in the startup state, switch the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system.

[0035] When the system attribute carried by the state coordination instruction is the second value, the playback content will be switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system.

[0036] Through the above steps, during the playback of the boot animation of the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, and the first vehicle system starts before the second vehicle system. If the startup status of the second vehicle system is not started, the boot animation of the first vehicle system continues to play. If the startup status of the second vehicle system is started, the playback content is switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system. Thus, only the boot animation of the first vehicle system can be played before the second vehicle system starts, and the playback can be seamlessly switched to the boot animation of the second vehicle system immediately when the second vehicle system starts. This solves the technical problem of unsmooth transitions between segmented boot animations of multiple systems in related technologies.

[0037] As an optional embodiment, the following is combined with Figure 4 The technical solution of this application is further described in detail below: 1) Start Yocto SOS (i.e., the first vehicle system) using a hardware platform (such as the aforementioned main machine).

[0038] This solution introduces a unified cross-system channel (i.e., a collaborative state channel): through the system property service.bootanim.sos.exit, a state channel spanning Android UOS and Yocto SOS is implemented, thereby enabling the carrying of collaborative state commands for animation playback.

[0039] 2) Yocto SOS initializes the system daemon systemd (which is the init system and service manager in the operating system).

[0040] 3) Yocto SOS runs the bootanimengine process, which plays the Yocto SOS boot animation (the first stage animation begins).

[0041] 4) Yocto SOS boots Android UOS (i.e., the second in-vehicle system).

[0042] 5) Android UOS initializes SurfaceFlinger (which is the core display service process of the Android system, responsible for managing screen layer composition and display output).

[0043] 6) The Android UOS runs the bootanimation process and sets the value of the system property to 1.

[0044] On the Android UOS side, a cross-domain state synchronization mechanism is adopted. During its initialization phase, the bootanimation process actively sets the value of system attributes to 1. Then, through vsocket technology, the state coordination instructions (carrying system attribute values) are synchronized from the Android UOS user space to the Yocto SOS user space in a low-latency and highly reliable manner, ensuring the real-time nature of state awareness.

[0045] It should be noted that on the Android UOS side, full boot path compatibility is guaranteed. For Android Recovery boot mode (i.e., recovery mode, which is independent of the normal system and can be entered by restarting using commands during system runtime or by hardware during boot), it can be configured in init.recovery.mt6897.rc (Android Recovery initialization configuration file). During the init stage, the above system attribute is set to 1. The attribute change trigger is synchronized to Yocto SOS through vsocket technology to ensure that the animation display on the Yocto SOS side can be correctly terminated under all boot paths, avoiding the problem of continuously displaying the first stage animation in Android Recovery mode.

[0046] 7) Using vsocket cross-domain communication technology, state coordination instructions carrying system attribute values ​​are synchronized from the Android UOS user space to the Yocto SOS user space.

[0047] 8) When the bootanimengine process detects that the system property value is 1, it terminates the process, thus ending the first stage animation. At the same time, the bootanimation process plays the Android UOS boot animation (i.e., the second stage animation).

[0048] On the Yocto SOS side, an event-driven SOS animation service is used. The bootanimengine service adopts an event-driven architecture. In the main rendering loop, the original animation exit condition of "playing to the last frame" is adjusted to "meeting the exit state". A state listener is integrated to monitor the above-mentioned collaborative state (i.e., state collaborative instructions) in the frame rendering loop. Its behavior logic is as follows: if the state value is 0 (false), playback continues; if the state value is 1 (true), the exit state is immediately set, and the first stage animation stops playing. When Android UOS starts up quickly, the exit state is set to true by the state listener before the Yocto SOS bootanimengine has finished playing the last frame, the screen stops playing the first stage animation, and starts playing the second stage animation to avoid the two animations overlapping. When Android UOS starts up slowly, the SOS bootanimengine, which has already played the last frame of the animation, will continue playing the last frame (because the exit state is false) until the exit state is true before exiting playback and starting the second stage animation to avoid the black screen time between the two animations being too long.

[0049] The technical solution of this application provides a multi-system segmented boot animation mechanism based on an in-vehicle Hypervisor. With a standardized communication channel as the foundation, it solves the problems of long black screen and overlapping display between two boot animations by constructing a collaborative state channel, reconstructing the SOS animation service as an event-driven model, establishing a low-latency cross-domain state synchronization system, and achieving full boot path compatibility assurance. This enables a natural connection between the two animations and optimizes the user's boot experience.

[0050] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0051] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (i.e., an in-vehicle device, such as an in-vehicle computer device) to execute the methods of the various embodiments of this application.

[0052] According to another aspect of the embodiments of this application, an animation synchronization device for implementing the above-described animation synchronization method for segmented startup of vehicle multi-systems is also provided. Figure 5 This is a schematic diagram of an animation synchronization device for segmented startup of multiple in-vehicle systems according to an embodiment of this application, as shown below. Figure 5 As shown, the device may include: The acquisition unit 501 is used to acquire the startup status of the second vehicle system through the cross-system channel between the first vehicle system and the second vehicle system during the process of the first vehicle system playing the startup animation, wherein the first vehicle system starts before the second vehicle system.

[0053] The first in-vehicle system is a service operating system (SOS), such as Yocto SOS, and the second in-vehicle system is a client operating system (UOS), such as Android as UOS.

[0054] On the second system side, system properties can be configured, and their values ​​can be initialized to a first value. This system property, such as `service.bootanim.sos.exit`, uses its value to represent the startup status of the second system. A first value (e.g., 0) indicates the system is not started, while a second value (e.g., 1) indicates it is started. On the first system side, a boot animation playback service for the first vehicle system is pre-deployed. This service operates in an event-driven mode and includes a status listener to monitor the startup status of the second vehicle system. A cross-system channel, such as using vsocket technology, is pre-established between the first and second vehicle systems. This cross-system channel serves as a transmission channel for status coordination instructions, which carry the system property values.

[0055] In the above scheme, after the first vehicle system starts up, a playback service for the boot animation of the first vehicle system is run. This playback service will continuously play the boot animation of the first vehicle system. At the same time, the status listener in the playback service will continuously listen for status coordination instructions from the user space of the first vehicle system. The status coordination instructions are used to indicate the startup status of the second vehicle system.

[0056] After the second vehicle system starts up, it will use a cross-system channel to send state coordination commands from the user space of the second vehicle system to the user space of the first vehicle system. The specific implementation methods include the following two: 1) When the second vehicle system starts in normal mode, the process of the second vehicle system (e.g., the bootanimation process) replaces the attribute value of the system attribute of the second vehicle system from the first value to the second value, and generates a state coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses a cross-system channel to send the state coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system. The system attribute is used to indicate the startup status of the second vehicle system. The first value indicates that the second vehicle system has not started, and the second value indicates that the second vehicle system has started. 2) When the second vehicle system starts in recovery mode, the initialization script of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from the first value to the second value during runtime, and generates a state coordination instruction for carrying the system attribute with the second value. The attribute change trigger in the second vehicle system uses a cross-system channel to send the state coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system.

[0057] The first playback unit 503 is used to continue playing the startup animation of the first vehicle system when the startup state of the second vehicle system is not started.

[0058] The aforementioned first playback unit is also used to: when the system attribute carried by the state coordination instruction is a first value, if the boot animation of the first vehicle system has not played to the last animation frame (i.e., the current animation frame is not the last animation frame), then continue playing the next animation frame in the boot animation of the first vehicle system (i.e., the animation frame after the aforementioned current animation frame); if the boot animation of the first vehicle system has played to the last animation frame, then continue playing the last animation frame in the boot animation of the first vehicle system.

[0059] The second playback unit 505 is used to switch the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system when the startup state of the second vehicle system is "started".

[0060] The aforementioned second playback unit is also used to: switch the playback content from the boot animation of the first vehicle system to the boot animation of the second vehicle system when the system attribute carried by the state coordination instruction is a second value.

[0061] Through the aforementioned module, during the playback of the boot animation on the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, with the first vehicle system starting before the second vehicle system. If the startup status of the second vehicle system is not started, the boot animation of the first vehicle system continues to play. If the startup status of the second vehicle system is started, the playback content is switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system. This allows the first vehicle system's boot animation to be played only before the second vehicle system starts, and the playback seamlessly switches to the second vehicle system's boot animation immediately upon startup, thus solving the technical problem of unsmooth transitions between segmented boot animations of multiple systems in related technologies.

[0062] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run in a corresponding hardware environment, and can be implemented through software or hardware, wherein the hardware environment includes a network environment.

[0063] According to another aspect of the embodiments of this application, a terminal for implementing the above-described animation synchronization method for segmented startup of multiple vehicle systems is also provided.

[0064] Figure 6 This is a structural block diagram of a terminal according to an embodiment of this application, such as... Figure 6 As shown, the terminal may include: one or more (only one is shown in the figure) processors 601, memory 603, and transmission devices 605, such as... Figure 6 As shown, the terminal may also include input / output devices 607.

[0065] The memory 603 can be used to store software programs and modules, such as the program instructions / modules corresponding to the animation synchronization method and device for segmented power-on of multiple vehicle systems in this embodiment. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 603, thereby realizing the aforementioned animation synchronization method for segmented power-on of multiple vehicle systems. The memory 603 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 603 may further include memory remotely located relative to the processor 601, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0066] The aforementioned transmission device 605 is used to receive or send data via a network, and can also be used for data transfer between the processor and memory. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 605 includes a Network Interface Controller (NIC), which can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 605 is a radio frequency (RF) module used for wireless communication with the Internet.

[0067] Specifically, memory 603 is used to store application programs.

[0068] The processor 601 can invoke the application program stored in the memory 603 via the transmission device 605 to perform the following steps: During the playback of the boot animation on the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, wherein the first vehicle system starts before the second vehicle system. If the startup status of the second vehicle system is not started, the boot animation of the first vehicle system continues to play. If the startup status of the second vehicle system is started, the playback content is switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system.

[0069] Processor 601 is also used to perform the following steps: When the second vehicle system starts in normal mode, the process of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value, and generates a status coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses the cross-system channel to send the status coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system. The system attribute is used to indicate the startup status of the second vehicle system. The first value indicates that the second vehicle system is not started, and the second value indicates that the second vehicle system is started. Alternatively, when the second vehicle system starts in recovery mode, the initialization script of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value during runtime, and generates a status coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses the cross-system channel to send the status coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system.

[0070] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0071] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. The terminal can be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, the terminal may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0072] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0073] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to execute program code for an animation synchronization method for segmented startup of multiple vehicle systems.

[0074] Optionally, in this embodiment, the storage medium may be located on at least one of the network devices in the network shown in the above embodiment.

[0075] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: The processor 601 can invoke the application program stored in the memory 603 via the transmission device 605 to perform the following steps: During the playback of the boot animation on the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, wherein the first vehicle system starts before the second vehicle system. If the startup status of the second vehicle system is not started, the boot animation of the first vehicle system continues to play. If the startup status of the second vehicle system is started, the playback content is switched from the boot animation of the first vehicle system to the boot animation of the second vehicle system.

[0076] Optionally, the storage medium is also configured to store program code for performing the following steps: When the second vehicle system starts in normal mode, the process of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value, and generates a status coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses the cross-system channel to send the status coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system. The system attribute is used to indicate the startup status of the second vehicle system. The first value indicates that the second vehicle system is not started, and the second value indicates that the second vehicle system is started. Alternatively, when the second vehicle system starts in recovery mode, the initialization script of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value during runtime, and generates a status coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses the cross-system channel to send the status coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system.

[0077] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0078] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0079] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0080] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0081] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0082] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components 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 through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0083] The units described as separate components may or may not be physically separate. The components shown as units 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0085] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for animation synchronization of segmented startup of multiple vehicle systems, characterized in that, include: During the boot animation playback of the first vehicle system, the startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, wherein the first vehicle system starts before the second vehicle system. If the second vehicle system is in an inactive state, the startup animation of the first vehicle system continues to play. When the second vehicle system is in the "start" state, the playback content will be switched from the startup animation of the first vehicle system to the startup animation of the second vehicle system.

2. The method according to claim 1, characterized in that, The startup status of the second vehicle system is obtained through the cross-system channel between the first and second vehicle systems, including: On the second vehicle system side, the cross-system channel is used to synchronize the startup status of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system. On the first vehicle system side, during the rendering cycle of each animation frame of the first vehicle system's startup animation, a status listener is used to listen for the startup status of the second vehicle system from the user space of the first vehicle system.

3. The method according to claim 2, characterized in that, Using the cross-system channel, the startup status of the second vehicle system is synchronized from the user space of the second vehicle system to the user space of the first vehicle system, including: When the second vehicle system starts in normal mode, the process of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from a first value to a second value, and generates a state coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses the cross-system channel to send the state coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system. The system attribute is used to indicate the startup status of the second vehicle system; the first value indicates that the second vehicle system is not started, and the second value indicates that the second vehicle system is started; or, When the second vehicle system starts in recovery mode, the initialization script of the second vehicle system replaces the attribute value of the system attribute of the second vehicle system from the first value to the second value during runtime, and generates a state coordination instruction to carry the system attribute with the second value. The attribute change trigger in the second vehicle system uses the cross-system channel to send the state coordination instruction from the user space of the second vehicle system to the user space of the first vehicle system.

4. The method according to claim 3, characterized in that, Before synchronizing the startup state of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system using the cross-system channel, the method further includes: Configure system attributes in the second vehicle system and initialize the attribute values ​​of the system attributes to a first value.

5. The method according to claim 3, characterized in that, Before synchronizing the startup state of the second vehicle system from the user space of the second vehicle system to the user space of the first vehicle system using the cross-system channel, the method further includes: A cross-system channel is established between the first vehicle system and the second vehicle system based on vsocket technology. The cross-system channel is used as a transmission channel for state coordination instructions, which are used to carry the attribute values ​​of the system attributes.

6. The method according to any one of claims 2 to 5, characterized in that, Using a status listener to monitor the startup status of the second vehicle system from the user space of the first vehicle system, including: A playback service for the boot animation of the first vehicle system is run, wherein the playback service operates in an event-driven mode; Using the status listener in the playback service, the system continuously listens for status coordination instructions from the user space of the first vehicle system, wherein the status coordination instructions are used to indicate the startup status of the second vehicle system.

7. The method according to claim 6, characterized in that, When the startup status of the second vehicle system is not started, the startup animation of the first vehicle system continues to play. This includes: when the system attribute carried by the status coordination instruction is a first value, if the startup animation of the first vehicle system has not played to the last animation frame, then the next animation frame in the startup animation of the first vehicle system continues to play; if the startup animation of the first vehicle system has played to the last animation frame, then the last animation frame in the startup animation of the first vehicle system continues to play. When the startup state of the second vehicle system is "started", switching the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system includes: when the system attribute carried by the state coordination instruction is a second value, switching the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system.

8. An animation synchronization device for segmented startup of multiple systems in a vehicle, characterized in that, include: The acquisition unit is used to acquire the startup status of the second vehicle system through the cross-system channel between the first vehicle system and the second vehicle system during the process of the first vehicle system playing the startup animation, wherein the first vehicle system starts before the second vehicle system. The first playback unit is used to continue playing the startup animation of the first vehicle system when the startup state of the second vehicle system is not started. The second playback unit is used to switch the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system when the startup state of the second vehicle system is "started".

9. An animation synchronization system for segmented startup of multiple vehicle systems, characterized in that, include: A first vehicle system, a second vehicle system, and a cross-system channel located between the first vehicle system and the second vehicle system, wherein the first vehicle system starts up before the second vehicle system; The second vehicle system is used to: transmit its own startup status to the first vehicle system through the cross-system channel; The first vehicle system is configured to: continue playing the startup animation of the first vehicle system when the startup state of the second vehicle system is not started; and switch the playback content from the startup animation of the first vehicle system to the startup animation of the second vehicle system when the startup state of the second vehicle system is started.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the method described in any one of claims 1 to 7 through the computer program.

Images