Visual presentation method and system and electronic equipment

Abstract

The invention provides a visual presentation method and system and electronic equipment, and relates to the technical field of vehicle-mounted intelligent interaction. The method comprises the following steps: in response to a visual image customization operation on a vehicle-mounted voice assistant, generating target visual configuration data associated with a target driving situation; generating a visual presentation scheme based on the target visual configuration data; generating a target rendering strategy matched with the visual presentation scheme based on the visual presentation scheme and a detection result supported by the hardware capability and the bottom graphic interface of the target vehicle-mounted platform; and based on the target rendering strategy, converting a standardized rendering instruction corresponding to the visual presentation scheme into a bottom graphic interface instruction matched with the target vehicle-mounted platform to drive a rendering rear end of the target vehicle-mounted platform to execute rendering. Therefore, the standardized rendering instruction is dynamically converted into the instruction special for the target vehicle-mounted platform to drive rendering, cross-platform vision and performance consistency can be achieved without repeated development, and the development cost is reduced.

Description

Technical Field

[0001] This application relates to the field of in-vehicle intelligent interaction technology, and more specifically, to a visual presentation method, system, and electronic device. Background Technology

[0002] With the rapid development of smart cockpits, in-vehicle voice assistants have evolved from functional tools into important emotional interaction partners, and the personalized display of their visual image has become key to improving user experience.

[0003] Currently, existing technologies employ a solution of pre-installing fixed visual images and animations for specific vehicle models. By designing standardized virtual images, interface designs, and basic animations, visual feedback can be achieved during in-vehicle voice interaction.

[0004] However, existing technologies lack user-participatory customization capabilities, making it difficult to meet users' personalized needs. Furthermore, they do not consider the cross-platform adaptation requirements of different car models. When users try to expand personalized functions, the differences in hardware specifications and software interfaces between different car models will further exacerbate the adaptation problem, resulting in personalized content needing to be developed separately for different car models. This not only increases development costs but also fails to guarantee the consistency of visual effects and operating performance across multiple platforms. Summary of the Invention

[0005] The visual presentation method, system, and electronic device provided in this application dynamically convert standardized rendering instructions into dedicated instructions for the target vehicle platform to drive rendering, achieving cross-platform visual and performance consistency without repeated development and reducing development costs.

[0006] Firstly, a visual presentation method is provided, comprising: generating target visual configuration data associated with a target driving scenario in response to a visual image customization operation of an in-vehicle voice assistant; generating a visual presentation scheme based on the target visual configuration data, wherein the visual presentation scheme is a structured rendering scheme formed by managing the target visual components corresponding to the target visual configuration data; generating a target rendering strategy matching the visual presentation scheme based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target in-vehicle platform; and converting the standardized rendering instructions corresponding to the visual presentation scheme into underlying graphics interface instructions matching the target in-vehicle platform based on the target rendering strategy, so as to drive the rendering backend of the target in-vehicle platform to perform rendering.

[0007] In the aforementioned technical solution, in response to the visual image customization operation of the in-vehicle voice assistant, target visual configuration data associated with the target driving scenario is generated, thereby empowering users to deeply participate in personalized customization. Based on this target visual configuration data, the corresponding target visual components are scheduled and managed to form a structured visual presentation scheme, enabling flexible combination and replacement of visual elements. Next, a matching target rendering strategy is generated based on the real-time hardware capabilities and underlying graphics interface support of the target in-vehicle platform, solving the adaptation problem caused by hardware capabilities and software fragmentation. Finally, according to this target rendering strategy, the standardized rendering instructions of the visual presentation scheme are dynamically converted into underlying graphics interface instructions specific to the target in-vehicle platform and used to drive rendering. This allows the same personalized visual presentation scheme to be developed without repeated development for different vehicle models, presenting a voice assistant image with highly consistent visual effects and operational performance on various in-vehicle platforms, fundamentally reducing development costs and ensuring consistent cross-platform experience.

[0008] Secondly, a visual presentation device is provided, comprising: a first generation module for generating target visual configuration data associated with a target driving scenario in response to a visual image customization operation of an in-vehicle voice assistant; a second generation module for generating a visual presentation scheme based on the target visual configuration data, wherein the visual presentation scheme is a structured rendering scheme formed by managing the target visual components corresponding to the target visual configuration data; a third generation module for generating a target rendering strategy matching the visual presentation scheme based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target in-vehicle platform; and a conversion module for converting the standardized rendering instructions corresponding to the visual presentation scheme into underlying graphics interface instructions matching the target in-vehicle platform based on the target rendering strategy, so as to drive the rendering backend of the target in-vehicle platform to perform rendering.

[0009] Fourthly, a visual presentation system is provided, including: a component layer, an adaptation layer, a rendering layer, an editing layer, and a component manager; the editing layer is used to respond to user operations on visual image customization of the in-vehicle voice assistant and generate target visual configuration data; the component layer is communicatively connected to the editing layer and is used to receive the target visual configuration data to generate a visual presentation scheme based on the target visual configuration data; the component manager is integrated into the component layer and is used to manage the target visual components; the adaptation layer is communicatively connected to the component layer and is used to generate a target rendering strategy that matches the visual presentation scheme based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target in-vehicle platform; the rendering layer is communicatively connected to both the component layer and the adaptation layer and is used to receive standardized rendering instructions and the target rendering strategy corresponding to the visual presentation scheme, and convert the standardized rendering instructions into underlying graphics interface instructions that match the target in-vehicle platform based on the target rendering strategy.

[0010] Fourthly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic diagram of a visual presentation system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 3 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 1 ; Figure 4 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 2 ; Figure 5 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 3 ; Figure 6 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 4 ; Figure 7 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 5 ; Figure 8 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 6 ; Figure 9 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 7 ; Figure 10 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 8 ; Figure 11 This is a schematic diagram of the structure of a visual presentation device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0014] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0015] Before elaborating on the technical solutions, the technical terms used in this application will be explained to facilitate subsequent understanding.

[0016] The visual presentation methods, systems, and electronic devices of this application will be described in detail below with reference to the accompanying drawings and through multiple embodiments.

[0017] Figure 1 This is a schematic diagram of a visual presentation system provided in an embodiment of this application. Figure 1 As shown, the visual presentation system 100 includes: a component layer 110, an adaptation layer 120, a rendering layer 130, an editing layer 140, and a component manager 150.

[0018] The editing layer 140 provides users with a customized configuration interface for the visual image of the in-vehicle voice assistant, which can respond to the user's visual image customization operation and generate target visual configuration data. At the same time, the editing layer 140 also supports functions such as visual component assembly, intelligent preview and automated packaging related to driving scenarios, so as to improve the production efficiency of personalized visual content.

[0019] Specifically, the automated packaging function of editing layer 140 focuses on intelligent resource optimization and compression, automatic generation of multi-platform adaptation packages, and version management and release tracking. This automated packaging function can output package bodies in various formats, such as: a general distributable package containing adaptive vision components; specific binary files for platforms such as iOS, Android, QNX, and Linux IVI; a metadata list describing the capabilities that vision components depend on (e.g., in JSON / YAML format); compressed packages of pre-processed vision assets (e.g., in ZIP / TAR format); and automated deployment scripts suitable for various in-vehicle systems, thereby fully supporting the efficient development and cross-platform deployment of personalized vision components.

[0020] The integrated intelligent preview system in the editing layer 140 possesses multi-device simulation preview capabilities. It can comprehensively assess the impact on visual content performance through dynamic runtime simulation evaluation and simulated rendering performance testing. This runtime simulation evaluation includes at least: hardware compatibility assessment. The simulated rendering performance test follows a complete process: running the visual components in a simulated driving environment; recording the rendering time for each frame; calculating CPU and GPU usage; monitoring memory allocation and release; and measuring vehicle battery consumption.

[0021] The performance impact assessment implemented by this intelligent preview system covers the rendering performance of visual components, resource usage performance, battery power consumption performance, and compatibility performance, and is conducted based on clear quantitative standards, which include at least: The rendering performance standards should include at least the following: Frame rate standards: an average frame rate ≥ 55 FPS and a minimum instantaneous frame rate ≥ 30 FPS is rated as excellent; an average frame rate ≥ 45 FPS and a minimum instantaneous frame rate ≥ 25 FPS is rated as good; an average frame rate ≥ 30 FPS and a minimum instantaneous frame rate ≥ 20 FPS is rated as acceptable; an average frame rate < 30 FPS or a minimum instantaneous frame rate < 15 FPS is rated as unacceptable. Rendering latency standards are: interactive response latency should be less than 16ms (i.e., 1 frame time); average animation smoothness latency should be less than 33ms; and state transition latency should be less than 100ms.

[0022] Resource usage performance standards should include at least the following: memory usage standards, CPU utilization standards, and GPU utilization standards. Specifically, the memory usage standards should require: a single visual component texture memory usage ≤ 50MB; total memory increase during visual component runtime ≤ 100MB; and memory increase ≤ 5MB after 1 hour of continuous operation. The CPU utilization standards are: CPU utilization ≤ 5% is considered idle; CPU utilization ≤ 15% is considered normal interactive state; and CPU utilization ≤ 30% is considered complex animation processing state. The GPU utilization standards are: GPU utilization ≤ 20% is considered simple rendering; GPU utilization ≤ 50% is considered medium-complexity rendering; and GPU utilization ≤ 80% is considered complex rendering. Battery power consumption performance standards should include at least the following: a power consumption increase of ≤10% relative to the basic display is considered low power consumption; an increase of 10%-20% is considered medium power consumption; an increase of 20%-30% is considered high power consumption; and an increase of >30% is considered ultra-high power consumption.

[0023] The compatibility performance standards should include at least: cross-platform compatibility standards, evaluation result grading and recommendation standards, and intelligent optimization recommendation standards. The cross-platform compatibility standards should at least require: support for OpenGL ES 2.0 and above graphics APIs; adaptation to common automotive screen resolutions (such as 720p, 1080p, etc.); and compatibility with mainstream automotive operating system platforms such as Android Auto, CarPlay, and QNX. Evaluation result grading and recommendation standards are as follows: a rating of "green" (excellent) indicates direct use in a production environment; a rating of "yellow" (good) recommends use on mid-to-high-end devices, with optimization required for low-end devices; a rating of "orange" (acceptable) requires targeted optimization and is recommended for use in specific scenarios; a rating of "red" (unacceptable) requires significant optimization, otherwise use is not recommended.

[0024] Among them, the hardware compatibility assessment of the editing layer 140 is used to cover the configuration simulation of in-vehicle equipment at different performance levels, including at least: low-end in-vehicle equipment (such as those with limited simulated memory and low GPU performance), mid-range in-vehicle equipment (such as those simulating the performance level of mainstream in-vehicle equipment), and high-end in-vehicle equipment (such as those simulating high-performance environments), and to conduct compatibility tests across different operating systems and API (Application Programming Interface) environments.

[0025] Optionally, this application also provides a schematic diagram of the tool architecture for the editing layer. Figure 2 This is a schematic diagram of the tool architecture for an editing layer provided in an embodiment of this application. Figure 2As shown, the tool architecture of this editing layer includes at least: a design canvas, an intelligent assistance module, a publishing management module, an automated packaging module, and an intelligent preview system. Among them, the design canvas and the intelligent assistance module are the main functional areas of the editing layer 140; the publishing management module, the automated packaging module, and the intelligent preview system are the main operation nodes of the editing layer 140.

[0026] Specifically, the design canvas, as the core area of ​​the editing operation, integrates a driving scenario simulation area, a visual component toolbox, and an attribute editing panel. These are used to simulate and construct emotion-aware driving scenarios, provide the selection and invocation of visual components, and edit and configure the attribute parameters of visual components and driving scenarios, respectively. The intelligent assistance function area is equipped with a driving scenario preset library, an intelligent recommendation engine, and a performance evaluator. The driving scenario preset library provides predefined emotion-aware driving scenario resources; the intelligent recommendation engine, based on AI technology, can intelligently recommend matching visual components according to the current design scenario and simultaneously support real-time evaluation of performance impact; the performance evaluator is mainly responsible for detecting and analyzing the running performance of the edited content. The publishing management module, automated packaging module, and intelligent preview system, among other operation nodes, respectively realize the control of the publishing process of the editing results, multi-platform adaptability packaging processing, and preview of the editing effect in the simulated driving scenario. In addition, this tool architecture also supports cross-device scenario simulation and visual design of voice interaction processes, comprehensively covering the entire process requirements for editing and adapting emotion-aware visual content.

[0027] The component layer 110 is communicatively connected to the editing layer 140 to receive target visual configuration data and generate a visual presentation scheme based on the target visual configuration data; the component manager 150 integrated into the component layer 110 is used to manage the entire lifecycle of the target visual components.

[0028] Optionally, this application also provides a schematic diagram of the component layer structure. Figure 3 This is a schematic diagram of a component layer structure provided in an embodiment of this application. For example... Figure 3 As shown, the component layer 110 includes at least: a visual component library, a component manager, a lifecycle controller, and a collaboration coordinator.

[0029] The component manager communicates with the visual component library, the lifecycle controller, and the collaboration coordinator.

[0030] The visual component library includes at least: basic graphic components, UI interface components, and animation effect components. Basic graphic components include at least: avatars, emoticons, and gestures; UI interface components include at least: dialog boxes, buttons, and progress bars; and animation effect components include at least: transition animations and special effects. All components in the visual component library support hot-swappable independent development and replacement.

[0031] In the context of in-vehicle voice assistants, specialized components can be built based on a visual component library. These specialized components include at least: character performance components, interactive feedback components, and context-adaptive components. The character performance components are facial expressions, postures, and actions specifically designed for the virtual in-vehicle voice assistant character, composed of basic graphic components and / or animation effect components. The interactive feedback components are visual elements (such as sound wave animations and understanding status indicators) specifically used for voice interaction feedback, composed of animation effect components. The context-adaptive components are visual components that automatically adjust according to driving scenarios (such as night mode and navigation mode), composed of UI interface components. For example, users can use these specialized voice assistant components to switch the voice assistant's image from a "business-style" emoji to a "cute-style" emoji while driving, or change the overall appearance theme according to different seasons.

[0032] The component manager's workflow covers the entire lifecycle of the visual presentation system, specifically as follows: First, upon system startup, it reads the system's global configuration parameters (such as default component paths and security policies), initializes the logging system and error handling mechanism, establishes a component registry and dependency database, and starts the event bus system to prepare the basic runtime environment. Second, it scans the preset component directories, traverses the dynamic library files (such as .so / .dll), verifies whether the dynamic library files conform to the component plugin format specifications, extracts metadata such as component ID, version, and dependencies, and adds valid components to the available component list. Third, it constructs a component dependency graph to analyze the relationships between visual components, detects conflicts such as circular dependencies, determines the loading priority of visual components using a preset topology sorting algorithm, and distinguishes the loading order of core visual components from optional visual components. Finally, it loads visual component plugins according to this loading order using a dynamic link library loading mechanism, calls component factory methods to create component instances, verifies the integrity and correctness of the visual component interfaces, and registers successfully loaded visual components to the component pool. Subsequently, the system calls initialization methods (such as `initialize()`) on the loaded visual components to complete internal initialization, sets component parameters according to configuration files, establishes service dependencies between visual components, and starts background tasks and service threads for the visual components. Afterward, during the operation of the visual presentation system, it continuously monitors the health status and resource usage of the visual components, listens for changes in the file system (including dynamic library files, configuration files, etc.) to detect visual component updates, handles event communication and data exchange between visual components, and maintains the state transitions of the visual component lifecycle. Furthermore, when responding to a runtime visual component change request, it first receives the visual component replacement or uninstallation instruction, safely stops the execution of the target visual component, resolves the dependencies of the new visual component and completes its loading, and completes the visual component replacement without affecting the operation of the visual presentation system.

[0033] In addition, the component manager is responsible for maintaining a unified event bus, forwarding messages between visual components, coordinating state synchronization and data sharing between visual components, handling dependent service calls between visual components, and standardizing the communication protocol of visual components. At the same time, it manages the activation / sleep state of visual components according to their usage frequency, implements dynamic allocation of memory and CPU resources, performs garbage collection and resource release, monitors the performance of the visual presentation system and makes corresponding adjustments. Finally, it captures crashes or error states during the operation of visual components, attempts to automatically recover or degrade, records error logs and notifies upper-layer applications, and isolates faulty components when necessary to prevent the impact from spreading.

[0034] The lifecycle controller, serving as the management unit for the visual components of the in-vehicle voice assistant, is primarily used to achieve standardized management of the entire lifecycle of these components. Specifically, it includes: managing the entire process of visual components from initialization, operation, and pause to uninstallation / destruction through an independent component loading / unloading mechanism; and automating the management of dependencies between visual components, encompassing dependency resolution, dependency injection, dynamic dependency adjustment, and version compatibility verification, thus supporting the smooth flow of the component lifecycle. Furthermore, this lifecycle controller is also used for hot-swappable status monitoring and anomaly handling. Here, hot-swappable refers to the ability to dynamically load, unload, and replace any visual component during the operation of the in-vehicle voice assistant without restarting the visual presentation system or voice assistant service.

[0035] The collaboration coordinator, acting as the scheduling unit for visual components, integrates a unified component communication protocol, an event-driven component interaction mode, and state synchronization and data sharing mechanisms to achieve efficient collaboration among various components, including role performance, interactive feedback, and context adaptation. The unified component communication protocol provides a standardized message carrier for visual component collaboration, defining structured message formats such as COMPONENT_SWAP (component replacement) and STATE_CHANGED (state change), covering key fields such as message type, component identifier, timestamp, and payload data, supporting precise and orderly communication for operations such as hot-plugging and state changes. Based on this unified component communication protocol, an event-driven component interaction mode is built, using user preference changes, driving scenario switching, and system resource adjustments as trigger conditions. Visual components achieve loosely coupled interaction through publish / subscribe events. For example, when a user switches to a "cute" emoji pack, the editing layer 140 publishes a preference change event; role performance components subscribing to this event can trigger the hot-plugging operation of the corresponding emoji component. The state synchronization and data sharing mechanism employs a distributed management process combining centralized state storage and local caching. When a visual component's state changes, it is first synchronized to the central storage, then broadcast to all associated visual components to update their local states. Simultaneously, a transactional state transition mechanism ensures state consistency during component switching and hot-swapping, preventing data conflicts or interface errors. These mechanisms are interconnected, supporting efficient collaboration and flexible interaction between visual components, ensuring smooth operation of visual components in automotive scenarios, and guaranteeing a superior user experience.

[0036] The adaptation layer 120 communicates with the component layer 110 to generate a target rendering strategy that matches the visual presentation scheme based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target vehicle platform.

[0037] The adaptation layer 120 is the driving unit of the in-vehicle voice assistant visual presentation system. Its goal is to achieve adaptive optimization of visual rendering under different in-vehicle hardware platforms and driving scenarios through preset cognitive algorithms and collaboration with multiple modules. The adaptation layer 120 integrates multiple rendering backends such as OpenGL ES, Vulkan, and Direct3D, and incorporates a variety of preset cognitive algorithms. These preset cognitive algorithms can be selected according to actual conditions. For example, they can be preset machine learning (neural network) algorithms, reinforcement learning algorithms for optimizing rendering path selection, rule-based performance optimization decision tree algorithms, genetic algorithms for evolving optimal resource allocation strategies, and fuzzy logic controllers for handling uncertain performance requirements.

[0038] Among them, the functional modules of the adaptation layer 120 include at least: a cognitive hardware detection module, an intelligent rendering path selector, and a cognitive performance adjustment mechanism.

[0039] Among them, the cognitive hardware detection module is based on preset priority standards (computing performance → memory bandwidth → power consumption limit → heat dissipation design constraints → user behavior patterns) to achieve machine learning-based hardware capability identification, real-time performance bottleneck analysis and prediction, and user behavior pattern learning and adaptation.

[0040] The intelligent rendering path selector uses multi-dimensional evaluation algorithms (such as overall performance, power consumption, and quality) and learning optimization based on historical data to complete dynamic path adjustment and optimization suggestions.

[0041] The cognitive performance tuning mechanism, serving as the feedback control layer of adaptation layer 120, connects to the cognitive hardware detection module on one end to receive real-time hardware status, performance bottlenecks, and user behavior data. On the other end, it connects to the intelligent rendering path selector to transmit tuning commands. Simultaneously, it receives performance feedback from the actual rendering process, forming a closed loop: hardware detection module → cognitive performance tuning mechanism → intelligent rendering path selector → actual rendering → performance feedback → hardware detection module. This closed loop is mainly reflected in the following three aspects: First, it employs Quality of Experience (QoE) perception adjustment, collecting QoE quantification indicators such as frame rate stability, rendering accuracy, and interaction latency in real time. After comparing these indicators with expected targets, it dynamically adjusts rendering parameters to resolve issues like animation stuttering. Second, it adjusts performance priorities based on driving status, integrating in-vehicle system driving status monitoring data. Performance priorities are reallocated in scenarios such as normal driving (balancing effect and performance), complex road conditions (prioritizing safety / navigation information), parking (enhancing visual effects), and emergencies (maximizing response speed). For example, it reduces assistant animation quality in navigation mode and enhances visual effects in parking mode. Third, it features predictive resource allocation and preloading. Based on a preset machine learning model, it analyzes user history and scene characteristics to preload necessary resources such as morning greeting animations and preheat the rendering pipeline, ensuring rapid response. This adaptation layer 120, through module collaboration and cognitive algorithms, achieves cross-hardware platform compatibility and ensures user experience and system stability in different driving scenarios through dynamic performance adjustment.

[0042] For example, the QoE monitoring process is a real-time closed-loop component of the cognitive performance tuning mechanism to achieve precise adaptation of user experience. Once the QoE monitoring process is initiated, the visual presentation system continuously collects rendering performance data (such as frame rate (FPS), interaction latency, and other core metrics). Based on this data, it analyzes quantitative metrics of user experience quality (QoE) such as visual smoothness, rendering accuracy, and response speed, and then compares these metrics with preset QoE target thresholds. If a deviation is detected between the actual metrics and the target, the system immediately and dynamically adjusts rendering parameters (such as reducing animation complexity or adjusting rendering frequency), and continuously iterates and optimizes until the experience quality returns to the target standard. For instance, when the visual presentation system detects stuttering when a user watches a virtual assistant's facial animation (e.g., the corresponding frame rate is below the threshold), the QoE tuning mechanism automatically simplifies animation details or lowers the rendering frame rate to ensure smooth interaction.

[0043] For example, the predictive adjustment process is a core component of the adaptation layer 120's pre-emptive resource scheduling. It first analyzes user behavior patterns (such as common time periods and frequently used functions) and uses a pre-set machine learning model to accurately predict potential needs within the next few seconds. Then, it pre-loads resources and visual components matching the demand, simultaneously warming up the rendering pipeline and preparing the cache. Finally, it dynamically adjusts the system's resource allocation strategy to ensure resources are prioritized for predicted needs. For instance, when the visual presentation system learns and recognizes that users typically use the voice assistant around 8 AM, it pre-loads the animation and components corresponding to the morning greeting before that time arrives, thus achieving a fast response when the user calls it and avoiding loading delays that could impact the user experience.

[0044] The rendering layer 130 is communicatively connected to the component layer 110 and the adaptation layer 120, respectively, and is used to receive standardized rendering instructions and target rendering strategies corresponding to the visual presentation scheme, and convert the standardized rendering instructions into underlying graphics interface instructions that match the target vehicle platform based on the target rendering strategy.

[0045] Among them, rendering layer 130 is the intelligent rendering interface and support unit of the visual presentation system. Its goal is to shield the underlying differences of different car manufacturers' in-vehicle systems by using an abstract rendering API interface optimized for the in-vehicle environment and relying on an intelligent adaptation mechanism. This allows developers to develop visual content compatible with multiple car models simply by following a unified specification. Rendering layer 130 uses the intelligent rendering interface as the execution body and works in conjunction with the rendering adapter and intelligent resource management system that are adapted to multiple platforms to achieve cross-platform and adaptive rendering capabilities.

[0046] The intelligent rendering interface, as the execution core, operates as follows: First, it receives rendering requests from upper-layer visual components (such as virtual assistant expressions and animation components). Then, it performs hardware (GPU model, memory capacity, supported graphics APIs, etc.) and software environment checks on the current device. Based on the check information, it scores rendering adapters such as Vulkan, OpenGL ES, and Direct3D from multiple dimensions (including weighted dimensions such as GPU performance matching, API support, and memory resources; for example, the Vulkan rendering adapter scores higher on high-end GPU devices due to its high performance matching, while the OpenGL ES rendering adapter scores higher on low-end devices due to its better compatibility). After selecting the optimal rendering adapter, it dynamically converts standardized rendering commands into platform-specific instructions that the adapter can execute, performs rendering operations, and provides performance data such as frame rate and GPU utilization for subsequent dynamic optimization. Among them, the intelligent rendering interface can be selected according to the actual situation. For example, the intelligent rendering interface can be selected as: component registration API (used to register new visual components), resource loading API (used to load visual resources according to priority), rendering context API (used to create a rendering environment suitable for the current hardware), event dispatch API (used to pass visual events between components), and performance monitoring API (used to obtain component performance metrics).

[0047] The adaptive multi-platform rendering adapter is a core component of the rendering layer, achieving cross-platform adaptation through three main functions: First, the rendering adapter is automatically selected based on the capabilities of the in-vehicle terminal device. The visual presentation system scores and optimizes the rendering adapter based on the hardware information of the in-vehicle terminal device from multiple dimensions, while supporting dynamic weight adjustment (such as increasing the performance efficiency weight in battery-powered mode) and avoiding frequent detection through a caching mechanism. Second, there is a dynamic balance between rendering quality and performance. Rendering indicators are continuously monitored. When the frame rate is too low, the texture resolution is reduced and shadow calculation is simplified to ensure smoothness. When performance is sufficient, the visual detail is improved. Third, cross-version compatibility is guaranteed. After detecting the API version of the target platform, unsupported advanced functions are mapped to basic functions (such as converting the geometry shader of OpenGL ES 3.0 to vertex and fragment shader combinations on 2.0 devices), ensuring that visual content can be displayed normally on both new and old devices.

[0048] This adaptive multi-platform rendering adapter is applicable to a wide range of hardware and interaction differences in in-vehicle terminals: at the display level, it can automatically adapt and scale to different resolution displays from 720p to 4K, ensuring the display ratio and clarity of visual content on various in-vehicle screens; at the graphics interface level, it can convert OpenGL ES rendering calls into equivalent implementations of Vulkan or Direct3D, adapting to the graphics API environments supported by different in-vehicle systems; at the interaction level, it can map touch gestures to physical button combinations, matching the in-vehicle interaction methods of different car models; at the resource management level, it dynamically adjusts the allocation strategy of rendering resources based on the available RAM capacity ranging from 1GB to 8GB; and at the performance adaptation level, it adjusts the fineness of rendering quality according to the actual processing power of the in-vehicle terminal's CPU / GPU, achieving a match between hardware capabilities and visual effects.

[0049] It should be noted that the intelligent rendering interface is implemented through an abstraction layer design, providing a standardized rendering command interface to the outside world. Internally, it integrates subsystems such as a rendering adapter selector and a compatibility manager. After receiving a request, it selects the optimal rendering adapter, completes compatibility mapping, and then delivers it for execution. It also supports dynamic switching of rendering adapters. The adaptive multi-platform rendering adapter shields the underlying differences through runtime dynamic translation, converting unified commands into the specific implementation of the target vehicle platform. When the target vehicle platform does not support the preferred API (such as Vulkan), the visual presentation system degrades according to the process of "Vulkan → OpenGL ES → software rendering → basic 2D rendering", while logging is recorded for optimization.

[0050] Furthermore, this rendering layer 130 and the intelligent resource management system are collaborative, complementary, and mutually supportive. Together, they constitute the infrastructure for the visual rendering of the in-vehicle voice assistant. Their hierarchical relationship follows: "Application layer (components, editing tools, etc.) → Intelligent rendering interface layer (abstract rendering API) → Intelligent resource management system (resource management and optimization) → Underlying rendering engine (OpenGL)". The architecture follows a top-down approach, similar to ES and Vulkan. The intelligent rendering interface layer provides a unified platform-independent rendering API, shields the technical differences between various rendering backends, handles the abstraction and forwarding of rendering commands, and implements context-aware rendering optimization. The intelligent resource management system focuses on the lifecycle management of rendering resources, memory usage and access efficiency optimization, implementation of intelligent preloading and recycling strategies, and monitoring and tuning of resource usage. The two systems collaborate efficiently through a clear mechanism and data flow: component rendering requests are first passed to the intelligent rendering interface layer, which performs resource requirement analysis and then forwards them to the intelligent resource management system. The system then performs resource availability checks and resource pool management, provides feedback on resource allocation decisions, and finally supports actual rendering execution by returning resource handles. The overall data flow is: "Input component rendering request → Intelligent rendering interface layer receives and abstracts → Intelligent resource management system processes and optimizes → Underlying rendering engine executes → Output rendering result."

[0051] As the core execution entity of the entire rendering system Figure 4 This application also provides a schematic diagram of the rendering layer structure. For example... Figure 4 As shown, the rendering layer includes at least: visual components, intelligent rendering interface, and at least two rendering adapters.

[0052] The intelligent rendering interface operates in an orderly manner as follows: First, it receives rendering commands from upper-layer visual components (such as virtual assistant expressions and animation components). Then, it performs a comprehensive analysis of the hardware (GPU model and performance, available memory, supported graphics APIs, etc.) and software environment of the current in-vehicle terminal device. Based on the detection results, it comprehensively scores available rendering adapters such as Vulkan, OpenGL ES, and Direct3D (considering factors such as hardware capability matching and API support) and selects the optimal adaptation scheme. Subsequently, it converts the standardized rendering commands into platform-specific instructions that the selected rendering adapter can recognize and passes them to the underlying rendering adapter to call the corresponding graphics API to complete the actual rendering. Finally, it collects performance data such as frame rate and GPU utilization and feeds them back to the quality balancing system for subsequent dynamic optimization. At the same time, the intelligent resource management system further improves the resource utilization efficiency of the collaboration between the two through strategies such as resource preloading based on usage frequency, resource reclamation based on memory pressure awareness, and multi-level caching mechanisms to optimize access efficiency, ensuring the smoothness and stability of the rendering process.

[0053] The visual presentation system provided in this application can be composed of a component layer, an adaptation layer, a rendering layer, an editing layer, and a component manager. The editing layer generates target visual configuration data in response to user customization operations for the in-vehicle voice assistant, thereby fulfilling the user's personalized needs and addressing the pain point of lacking customization in traditional visual presentation systems. The component layer communicates with the editing layer to receive the target visual configuration data and generate a visual presentation scheme based on it. The component manager, integrated into the component layer, manages the target visual components, ensuring the efficiency and stability of visual component invocation. The adaptation layer communicates with the component layer to adapt to the visual presentation scheme and generate a visual presentation scheme based on the target visual configuration data. The hardware capabilities of the target vehicle platform and the detection results supported by the underlying graphics interface generate a target rendering strategy that matches the visual presentation scheme. This effectively shields the underlying technical differences between different target vehicle platforms and solves the cross-platform adaptation problem. The rendering layer communicates with the component layer and the adaptation layer respectively to receive standardized rendering instructions and target rendering strategies corresponding to the visual presentation scheme. Based on the target rendering strategy, it converts the standardized rendering instructions into underlying graphics interface instructions that match the target vehicle platform. This ensures that the personalized visual presentation scheme can achieve consistent visual effects and smooth operation on different vehicle models, ultimately achieving the goal of flexible implementation of personalized customization and efficient and reliable cross-platform adaptation.

[0054] Optionally, Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device 200 may include a processor 210 and a memory 220.

[0055] The memory 220 stores machine-executable instructions that can be executed by the processor 210. When the electronic device 200 is running, these machine-readable instructions are executed. The processor 210 and the memory 220 communicate via a bus. The processor 210 can execute these machine-executable instructions to implement the visual presentation method.

[0056] The memory 220, processor 210, and bus components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The mobile storage device includes at least one software functional module that can be stored in the memory 220 in the form of software or firmware or embedded in the operating system (OS) of the electronic device. The processor 210 is used to execute executable modules stored in the memory 220, such as software functional modules and computer programs included in the visual presentation method of the mobile storage medium.

[0057] The memory 220 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0058] The electronic device 200 can be selected according to the actual situation. Furthermore, the electronic device 200 has software capable of executing visual presentation methods.

[0059] The visual presentation method provided in this application embodiment can be executed by a processor in the electronic device 200. The visual presentation method provided in this application embodiment will be explained further below. Figure 6 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 1 .like Figure 6 As shown, the method may include: S310, in response to the visual image customization operation of the in-vehicle voice assistant, generates target visual configuration data associated with the target driving scenario.

[0060] The target driving scenario can be selected according to the actual situation. For example, the target driving scenario can be selected as navigation mode, night driving, parking mode, etc.

[0061] In one possible implementation, the visual presentation system provides users with a visual editing interface that integrates driving scenario simulation through an editing layer. This interface is not a blank canvas, but rather has an embedded driving scenario simulation area, allowing users to pre-select or simulate a specific target driving scenario.

[0062] When a user drags and drops components from the visual component library, such as character representation components and interactive feedback components, within the visual component toolbox in the target scenario simulation environment, and configures their visual component parameters through the attribute editing panel, every user's operational intent is captured by the tool architecture of the editing layer. This tool architecture can bind and associate these discrete component operations and attribute settings with the currently active target driving scenario. For example, when a user sets the glowing outline and soft expression of the in-car voice assistant in night mode, these configurations will be naturally labeled as related to the nighttime scenario.

[0063] Ultimately, when the user completes editing and confirms, the editing layer's tool architecture doesn't simply save a set of images or animations. Instead, it integrates and serializes this information into a structured set of target visual configuration data. This target visual configuration data fully records: which visual components were used; the combination methods and attribute parameters of these visual components; and the target driving scenarios to which the visual components are applicable. Therefore, the generated target visual configuration data carries target driving scenario-related information from its inception, enabling the subsequent visual presentation system to clearly know which specific visual solution should be invoked and presented in which driving scenario, thereby achieving a high degree of contextual adaptation between visual presentation and the in-vehicle environment.

[0064] S320: Generate a visual presentation scheme based on the target visual configuration data.

[0065] The visual presentation scheme is a structured rendering scheme formed by managing the target visual components corresponding to the target visual configuration data.

[0066] In one possible implementation, since the target visual configuration data is associated with a specific target driving scenario and specifies the required visual components and their combinations, attributes, and interaction logic, the component manager can accurately schedule and load the corresponding target visual components from a pre-built visual component library based on this target visual configuration data. Furthermore, by managing the target visual components, a structured rendering scheme, i.e., a visual presentation scheme, is generated.

[0067] Based on the visual presentation scheme and the detection results of the target vehicle platform's hardware capabilities and underlying graphics interface support, S330 generates a target rendering strategy that matches the visual presentation scheme.

[0068] The hardware capabilities and underlying graphics interface support of the target vehicle platform can be selected according to the actual situation. For example, hardware capabilities can be selected as GPU performance and memory capacity; the underlying graphics interface support can be selected as supported OpenGL ES or Vulkan versions.

[0069] In one possible approach, based on the visual presentation scheme, the hardware capabilities and underlying graphics interface support of the target vehicle platform are tested to determine the upper limit of the platform's rendering capabilities and compatibility. Simultaneously, the rendering requirements of the visual presentation scheme, such as complexity and special effects requirements, are analyzed. Then, based on these rendering requirements, a pre-set machine learning model is used to predict the performance, power consumption, and quality of different rendering paths (e.g., selecting a Vulkan or OpenGL ES backend and adjusting parameters such as texture quality and shadow levels) on the target vehicle platform. Finally, based on the multi-dimensional evaluation results, the optimal rendering backend, graphics quality parameters, and resource allocation scheme are dynamically selected to generate a target rendering strategy that matches both the capabilities of the target vehicle platform and the requirements of the visual presentation scheme.

[0070] S340: Based on the target rendering strategy, the standardized rendering instructions corresponding to the visual presentation scheme are converted into underlying graphics interface instructions that match the target vehicle platform, so as to drive the rendering backend of the target vehicle platform to perform rendering.

[0071] In one possible implementation, the adaptation layer generates a target rendering strategy from the detection results and sends it to the rendering layer. The rendering layer then dynamically translates the standardized rendering instructions corresponding to the visual rendering scheme into specific low-level graphics interface instructions (such as OpenGL ES API instructions) supported by the target automotive platform using an adaptive multi-platform rendering adapter, based on the target rendering strategy. When the target automotive platform does not support the preferred API, the visual rendering system automatically degrades (e.g., falls back to software rendering) to ensure that the low-level graphics interface instructions can be executed, thereby driving completely consistent and smooth visual rendering across different target automotive platforms.

[0072] The visual presentation method provided in this application, in response to the customization of the visual image of an in-vehicle voice assistant, generates target visual configuration data associated with the target driving scenario, thereby empowering users to deeply participate in personalized customization. Based on this target visual configuration data, the corresponding target visual components are scheduled and managed to form a structured visual presentation scheme, enabling flexible combination and replacement of visual elements. Next, a matching target rendering strategy is generated based on the real-time hardware capabilities and underlying graphics interface support of the target in-vehicle platform, solving the adaptation problem caused by hardware capabilities and software fragmentation. Finally, according to this target rendering strategy, the standardized rendering instructions of the visual presentation scheme are dynamically converted into underlying graphics interface instructions specific to the target in-vehicle platform and used to drive rendering. This allows the same personalized visual presentation scheme to be developed without repeated development for different vehicle models, presenting a voice assistant image with highly consistent visual effects and operational performance on various in-vehicle platforms, fundamentally reducing development costs and ensuring consistent cross-platform experience.

[0073] Figure 7A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 2 .like Figure 7 As shown, the above method generates a visual presentation scheme based on the target visual configuration data, including: S410. Based on the target vision configuration data, determine the target vision component corresponding to the target vision configuration data.

[0074] In one possible implementation, upon startup, the component manager first reads and parses the target visual configuration data generated by the user through the editing layer. This target visual configuration data explicitly lists the identifiers (IDs) of the components required to construct a specific visual identity. The component manager then scans and matches these identifiers in the visual presentation system's preset component directory to accurately determine the specific target visual component file to be invoked. The preset component directory can be selected based on actual needs.

[0075] S420: Through the component manager, scan and load the component plugin files corresponding to the target visual component from the preset component directory.

[0076] In one possible implementation, the component manager traverses its maintained pre-defined component directories, locating the specific dynamic link library file (such as a .so or .dll) based on the component identifier determined in the previous step. The visual rendering system checks the format of these dynamic link library files to ensure they are compliant with specifications, verifying their integrity as component plugins. Then, using the dynamic link library loading mechanism, it loads the dynamic link library file into memory, preparing for subsequent component instantiation.

[0077] S430: Parse and manage the dependency declarations of each component plugin file, and generate component instances corresponding to each component plugin file.

[0078] In one possible implementation, the component manager parses the dependency information (i.e., dependency declarations) declared in each loaded plugin file, constructing a directed acyclic graph (DAG) representing the dependencies between visual components. The visual rendering system then uses a topological sorting algorithm to analyze this DAG, automatically calculating the correct loading and initialization order of all component plugins, ensuring that dependent components are ready first. Finally, the factory function of each component plugin is called in this order to create concrete, runnable component instances.

[0079] S440. During the operation of the visual presentation system, manage the lifecycle and hot-swapping of each component instance, and drive each component instance to work to generate a visual presentation solution.

[0080] In one possible implementation, the component manager continuously monitors the state of each component instance (e.g., loading, ready, running, paused), forming a closed-loop management system throughout its entire lifecycle. When a hot-swap replacement command is received, the component manager coordinates an atomic operation: safely pausing the old instance, loading the new plugin, migrating the runtime state, and resuming execution—all without interrupting the visual presentation system. Simultaneously, the component manager, through a unified event communication protocol, drives all component instances to work collaboratively based on the target visual configuration data, ultimately organically combining these real-time managed visual components to output a complete, structured visual presentation solution.

[0081] The visual presentation method provided in this application, based on target visual configuration data, determines the target visual components corresponding to the target visual configuration data, achieving precise mapping from customized intents to specific components. Subsequently, the component manager scans and loads the corresponding component plugin files from a preset directory, completing the on-demand acquisition of modular visual component resources. Furthermore, the dependency declarations of each component plugin are parsed and managed, and corresponding component instances are generated sequentially, ensuring that the complex component system can be correctly and reliably initialized. During the operation of the visual presentation system, the lifecycle and hot-swapping of the aforementioned component instances are uniformly managed, driving their collaborative work to ultimately generate a visual presentation solution, thereby supporting dynamic updates and continuous service of visual effects.

[0082] Optionally, the above method parses and manages the dependency declarations of each component plugin file, generating component instances corresponding to each component plugin file, including: Parse the dependency declarations of each component plugin file and construct a component dependency graph.

[0083] In one possible implementation, when the visual rendering system loads or updates visual components, the component manager actively scans and reads the pre-defined dependency declarations within each component plugin file. These dependency declarations, in a standardized format (such as metadata), clearly define which other visual components the visual component requires to function correctly. After collecting these dependency declarations from all visual components, the component manager uses a pre-defined graph theory algorithm to construct a directed acyclic graph (DAG) from these dependencies. In this DAG, each node represents a visual component, and each directed edge (A -> B) indicates that "visual component A depends on visual component B." This DAG serves as a global map for the visual rendering system to understand the complex dependencies between all visual components, laying the foundation for subsequent intelligent scheduling.

[0084] Based on the component dependency graph, the component loading order of each component plugin file is determined.

[0085] In one possible implementation, after constructing the component dependency graph, the visual rendering system uses a topological sorting algorithm to analyze the graph. This algorithm automatically calculates one or more valid linear sequences, with the core rule being that any visual component must be listed after all its dependencies. This means that a dependent visual component is always loaded before the visual components that depend on it. Through this algorithm, the visual rendering system intelligently resolves the implicit hierarchy and order among all visual components, calculating a unique or optimal component loading order, thereby avoiding runtime errors or initialization failures caused by disordered component loading order.

[0086] Based on the component loading order, each component plugin file is loaded sequentially, generating a component instance corresponding to each component plugin file.

[0087] In one possible implementation, after obtaining a defined component loading order, the component manager, acting as the executor, loads the visual components one by one strictly according to this order. For each visual component in the linear sequence, the component manager loads it into memory by manipulating the dynamic link library mechanism of the visual rendering system (such as loading .so or .dll files). Next, it calls the standard factory method or initialization function exported by the visual component, executes its internal initialization routine, and sets it according to configuration parameters, ultimately creating a runnable instance of the visual component in memory. After all visual component instances are created, they are registered in the component pool of the visual rendering system, entering a ready state, thus forming a complete and collaborative collection of visual components, providing the runtime foundation for generating visual presentations.

[0088] The visual presentation method provided in this application first parses the dependency declarations of each component plugin file, automatically constructing a clear component dependency graph to visually represent the complex dependencies between components. Based on this component dependency graph, the visual presentation system uses a topological sorting algorithm to determine the optimal component loading order for each component plugin file, fundamentally preventing loading failures or initialization errors caused by chaotic component dependencies. Subsequently, the visual presentation system loads each component plugin file sequentially based on this component loading order, generating component instances corresponding to each component plugin file. Therefore, this application ensures that dependent visual components are ready first, enabling the modular visual component library with complex component dependencies to be safely and efficiently initialized and assembled, thus laying a reliable technical foundation for the dynamic customization and stable operation of in-vehicle voice assistants.

[0089] Optionally, the above method manages the lifecycle and hot-plugging of each component instance and drives each component instance to work in order to generate a visual presentation scheme, including: The component manager monitors the lifecycle of each component instance and determines the lifecycle stage of each component instance.

[0090] In one possible implementation, the component manager, as the core of the visual presentation system, maintains a defined lifecycle state machine for each component instance. This lifecycle state machine includes at least the following states: loading, ready, running, paused, and unloading. It determines and tracks the current lifecycle stage of each component instance through internal state variables and event mechanisms. This monitoring is continuous, providing a basis for decisions regarding hot-plugging, resource reclamation, and other operations.

[0091] Among them, the component lifecycle management takes standardization and automation as its core objectives. By building an independent visual component loading / unloading mechanism, it realizes autonomous control of the entire process of visual components from initialization to destruction. At the same time, it has the ability to automatically resolve the dependencies between visual components, ensuring that the loading order of visual components is compliant and dependency conflicts can be identified. It is further supplemented by real-time monitoring of hot-swappable status and a full-process exception handling mechanism to ensure the stability and fault tolerance of visual components during dynamic replacement and operation, and to provide support for the flexible expansion and reliable operation of the visual component system.

[0092] In response to a preset hot-plug command, the component manager determines the target component to be replaced and the new component plugin file to be used for the replacement.

[0093] The preset hot-plug instructions can be selected according to the actual situation. For example, the preset hot-plug instructions can be selected as instructions that include information such as target_component and new_component_v2.

[0094] In one possible implementation, when a user performs operations such as changing skins or switching driving modes, the visual presentation system generates a structured preset hot-plug instruction. The component manager, as the central hub for receiving and processing the preset hot-plug instruction, parses the preset hot-plug instruction to determine which existing visual component (target) should be replaced with which new component (identified by the plugin file).

[0095] The full lifecycle management of the vision component is dynamically triggered through multi-dimensional scenario-based conditions to adapt to different needs and system states: when a user adjusts their visual preferences in the settings interface, the change in user preferences automatically drives the lifecycle process of the vision component; when a driving scenario switch occurs (such as switching between day / night display modes, or enabling navigation), the lifecycle management actions of the vision component are also triggered simultaneously; if the visual presentation system experiences increased memory pressure or decreased performance, the resource status of the visual presentation system will trigger the reloading or unloading of the vision component; when a new version of the vision component is released and available, the version update will trigger a hot-swap replacement process to complete the iteration of the vision component; in addition, once a vision component malfunction is detected, the error recovery mechanism will automatically trigger the reloading or degradation of the vision component, thereby ensuring the adaptability and stability of the vision component throughout its lifecycle.

[0096] Based on the lifecycle stage of each component instance, determine the lifecycle stage of the target component to be replaced.

[0097] In one possible implementation, based on the lifecycle stage of each component instance, the component manager queries its maintained visual component state table to directly obtain the current lifecycle stage (such as running status) of the target visual component to be replaced. This lifecycle stage information is crucial for safely executing the next uninstallation operation (e.g., ensuring that the visual component is not forcibly terminated during critical execution processes).

[0098] Based on the lifecycle stage of the target component to be replaced, the target component is unloaded, and a new component instance corresponding to the new component plugin file is loaded to drive each component instance to work and generate a visual presentation scheme.

[0099] In one possible implementation, based on the lifecycle stage of the target visual component to be replaced, if the target visual component is running, the component manager first notifies it to pause or gracefully terminate its current task, then sets its state to unloading, and finally releases its resources. The lifecycle controller coordinates this process. Simultaneously, based on dependency declarations, the component manager loads the component plugin file corresponding to the new visual component, calls its initialization method, and generates a new component instance in a ready state. Subsequently, the component manager switches the internal references to the target visual component in the visual rendering system to the new instance and broadcasts a STATE_CHANGED event via a unified event communication protocol. A collaboration coordinator ensures that other dependent visual components are aware of this change, update their collaboration relationships, and ultimately, all visual component instances collaboratively output a new, coherent visual rendering scheme.

[0100] It should be noted that the hot-swap mechanism of this application is specifically designed to respond to the visual component change requirements during the operation of the visual presentation system. When a visual component replacement or uninstallation instruction is received, the operation of the target visual component will be safely terminated first to avoid resource leakage or functional conflicts. Then, the dependencies of the new visual component will be automatically resolved and the loading and deployment will be completed. The entire process efficiently completes the dynamic replacement of components without interrupting the service of the in-vehicle voice assistant or affecting the user interaction experience, thus ensuring the continuity and stability of the visual presentation system.

[0101] In addition, it should be noted that the visual presentation system has designed a layered exception handling mechanism for component hot-plugging and operation, supplemented by specific scenario-based exception handling processes and performance guarantee mechanisms, to ensure the stability of dynamic management of visual components and the continuity of user experience: The first layer is an instant rollback mechanism. When a serious error is detected during hot-plugging, the visual presentation system immediately suspends the loading of the new component, preserves the original component's running state, releases the allocated new component resources, restores the original component to normal operation, and records error logs and notifies the upper-layer application. The second layer is a degradation handling mechanism. If the new component cannot work properly but still needs to be replaced, the visual presentation system will first try to use a simplified version of the component. If the simplified version is unavailable, the default component will be used. If necessary, the functional scope of the new component will be restricted or the rendering quality will be reduced to ensure basic functionality. The third layer is an isolation recovery mechanism. When a visual component experiences a persistent failure, the visual presentation system will mark the failed visual component as unavailable, prevent subsequent calls, start a backup visual component or the default implementation, periodically attempt to recover the failed visual component, and notify users and system administrators.

[0102] For example, taking the replacement of the car window raindrop animation component with the rainy day scenario component, when the new raindrop animation component fails to load due to file corruption, the visual presentation system immediately triggers an instant rollback mechanism, rolling back to the original raindrop animation component, recording detailed error information, and notifying the rainy day scenario component to use the backup rendering scheme. Simultaneously, it displays a message to the user: "Custom raindrop effect failed to load, using the default effect." The background then attempts to re-download the component package, and after successful download, tries hot-plugging again. To further ensure that the hot-plugging process does not affect the user experience, the visual presentation system also features a robust performance guarantee mechanism, including a pre-loading mechanism that loads the components to be used in advance, a gradual switching mechanism that masks the component switching process with transition animations, a resource reservation mechanism that reserves necessary system resources for hot-plugging operations, and a priority management mechanism that delays the hot-plugging of non-critical components when the system load is high.

[0103] The visual presentation method provided in this application monitors the lifecycle stages of each visual component instance in real time through a component manager, enabling the visual presentation system to accurately perceive the status of visual components during operation. Upon receiving a preset hot-swap replacement command, the component manager accurately locates the target visual component to be replaced based on the command and the current lifecycle stages of each component instance, and obtains the corresponding component plugin file for the new visual component. Subsequently, the visual presentation system coordinates the safe unloading of the old visual component and the dynamic loading and initialization of the new visual component according to the specific lifecycle stage of the target visual component. Therefore, this mechanism enables the dynamic replacement and updating of in-vehicle voice assistant visual components without requiring a service restart. This not only ensures the continuous generation and output of the visual presentation solution but also significantly improves the flexibility and maintainability of the visual presentation system, supporting real-time personalized customization by users without interrupting the interactive experience.

[0104] Figure 8 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 3 .like Figure 8 As shown, the above method generates target visual configuration data associated with the target driving scenario, including: S510: Based on the user's selection of the target driving scenario, obtain the scenario simulation environment corresponding to the target driving scenario.

[0105] In one possible implementation, the tool architecture of the editing layer pre-defines several typical in-vehicle driving scenarios (such as "normal driving," "navigation mode," "nighttime," and "rainy weather"). When a user selects or switches to a target driving scenario (such as "navigation mode") in the driving scenario simulation area of ​​the editing layer, the visual component toolbox immediately loads and activates the driving scenario environment that matches that scenario. This target driving scenario environment not only changes the visual tone of the design canvas, such as the background and lighting, to simulate the visual atmosphere of a real driving scenario, but more importantly, it automatically loads and applies the constraint rules and initial component set related to the target driving scenario environment, providing context for subsequent context-aware design.

[0106] It should be noted that this step is implemented by the "Driving Scenario Simulation Area" in the tool architecture of the editing layer.

[0107] S520. In a scenario simulation environment, based on the user's drag-and-drop combination operation on the visual components, obtain the combined visual components.

[0108] In one possible implementation, a visual component toolbox on the design canvas categorizes and stores all available visual components (such as basic graphics, UI controls, animation effects, etc.) obtained from the visual component library. Users drag and drop selected target visual components (such as a virtual avatar, a sound wave animation, etc.) from the toolbox into the driving scenario simulation area in the center of the design canvas using mouse or touch gestures. The visual presentation system responds to this operation in real time, recording the type of the dragged visual component, its identifier ID, and its initial positional relationship within the driving scenario simulation area at the data structure level. By continuously dragging and arranging multiple visual components, the visual presentation system obtains a set of visual components freely combined by the user and ready for further configuration, forming a preliminary visual solution.

[0109] It should be noted that this step is performed on the "Design Canvas" within the tool architecture of the editing layer.

[0110] S530: Obtain the combined attribute configuration based on the user's attribute configuration operation on the combined visual components.

[0111] In one possible implementation, when a user selects a placed visual component in the driving scenario simulation area, the attribute editing panel on the design canvas dynamically loads and displays all configurable parameters of that visual component. These configurable parameters include at least: color, size, transparency, animation speed, and trigger conditions. The user modifies these parameter values ​​using controls such as input boxes, sliders, and drop-down menus in the design panel. The visual presentation system synchronously responds to each user input, updating the preview effect of the visual component on the design canvas in real time, and uses these configurable parameter values ​​as the combined attribute configuration corresponding to the target visual component. This combined attribute configuration is then bound and stored with the corresponding component instance to achieve fine-grained control over the details of the visual presentation.

[0112] S540. Perform interactive preview of the visual presentation effects corresponding to the combined visual components and combined attribute configurations, and obtain the association relationship with the target driving scenario.

[0113] In one possible implementation, during the editing process or when the user actively triggers an interactive preview, the visual presentation system invokes some capabilities of the rendering layer to perform real-time or simulated rendering based on the latest combined visual components and corresponding combined attribute configurations within the current target driving context. The user can see an approximate final effect of the in-vehicle voice assistant in a specific target driving context (such as nighttime navigation) and perform simple interactive tests (such as clicking to simulate voice wake-up). This interactive preview process records the crucial information that "this set of combined visual components and combined attribute configurations was designed and verified under the target driving context (such as night mode)," thereby obtaining the correlation between the design scheme and the specific target driving context. This correlation is an important basis for subsequent runtime context adaptation.

[0114] The rendering layer's capabilities refer to the reuse of the intelligent unified rendering interface layer's rendering and evaluation logic during the interactive preview and performance impact assessment phases, rather than the complete rendering process for the final target in-vehicle platform. This capability primarily includes rendering instruction conversion and simulation execution capabilities, and performance data acquisition and evaluation capabilities. Specifically, the rendering instruction conversion and simulation execution capability means that when a user triggers the interactive preview, the visual component toolbox generates standardized rendering instructions from the visual design. These instructions then call the intelligent rendering interface of the rendering layer and the adaptive multi-platform rendering adapter logic. Based on a preset or user-selected simulation target (such as a mid-range in-vehicle system and OpenGL ES 3.0), the rendering adapter dynamically translates the standardized instructions into corresponding underlying graphics interface commands, executing them in a locally controllable simulation rendering environment (not a real in-vehicle system). This achieves a WYSIWYG interactive preview effect, ensuring consistency with the final presentation logic of the actual device. This performance data acquisition and evaluation capability, during simulated rendering performance testing, drives the above process through the visual component toolbox, calls the rendering layer and underlying system performance monitoring interfaces, collects key data such as rendering time per frame, CPU / GPU usage, and memory allocation, provides analysis basis for the performance evaluator, and determines whether the design meets the hardware performance standards of different levels.

[0115] It should be noted that this step is driven by the "intelligent preview system" in the tool architecture of the editing layer.

[0116] S550 generates target visual configuration data based on combined visual components, combined attribute configurations, and relationships.

[0117] In one possible implementation, once the user completes and confirms the design, the visual component toolkit initiates the corresponding process of the automated packaging module. The visual presentation system serializes all the information collected in the above steps, including which specific combined visual components are referenced (e.g., by the visual component's identifier ID), the combined attribute configuration of each visual component (e.g., key-value pair parameters), and the target driving scenario bound to the entire solution, into a structured, machine-readable data file (e.g., JSON / XML format). This file is the target visual configuration data. This file does not contain specific image, texture, or other resource binary data; instead, it describes the recipe or blueprint for the visual effect, specifying which visual components are used in which context, and with what parameters, for combination and presentation.

[0118] The visual presentation method provided in this application allows users to first select a target driving scenario in the editing layer. The visual presentation system then loads the corresponding driving scenario simulation environment, providing a realistic context for subsequent processing. Within this target driving scenario, users can intuitively drag and drop to combine visual components and configure details through the attribute editing panel, significantly lowering the creative threshold for non-professional users. All adjustments can be viewed immediately through the real-time interactive preview function, ensuring the accurate presentation of design intent. Finally, the visual presentation system integrates the complete combination of visual components, combined attribute configurations, and their relationship with the target driving scenario to generate a structured target visual configuration data. Thus, the visual editing workflow of this application makes the creation of personalized visual content simple and efficient, fundamentally solving the problem of high content creation thresholds and difficulty in meeting users' personalized needs caused by the lack of intuitive tools in traditional solutions.

[0119] Figure 9 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 3 .like Figure 9 As shown, the above method generates a target rendering strategy that matches the visual presentation scheme based on the detection results of the target vehicle platform's hardware capabilities and underlying graphics interface support, including: S610, based on the rendering requirements corresponding to the visual presentation scheme, performs hardware capability and underlying graphics interface support detection on the target vehicle platform, and obtains the detection results of the target vehicle platform.

[0120] The test results include at least: the graphics processor's computing performance data, memory bandwidth data, and the set of graphics API features it supports.

[0121] In one possible implementation, based on the rendering requirements corresponding to the visual presentation scheme, when the visual presentation system needs to run on a target in-vehicle platform for a specific visual presentation scheme (e.g., a rain mode assistant image with complex particle effects), the cognitive hardware detection module initiates a comprehensive hardware and software environment probe. It obtains the measured computational performance score of the GPU and available memory bandwidth by running lightweight benchmark programs. Simultaneously, it queries visual presentation system information to accurately detect the types of graphics APIs (such as Vulkan, OpenGL ES) supported by the target in-vehicle platform, their specific versions, and available extensions, forming a complete set of graphics API features. This data collectively constitutes a quantitative profile of the target in-vehicle platform's rendering capabilities, providing an objective basis for subsequent intelligent decision-making.

[0122] It should be noted that this step is performed by the cognitive hardware detection module of the adaptation layer.

[0123] S620 inputs computational performance data, memory bandwidth data, graphics API feature set, and visual presentation scheme into a pre-trained machine learning model for processing.

[0124] In one possible implementation, the visual rendering system combines the hardware profile data collected in the previous step (i.e., computational performance data, memory bandwidth data, and graphics API feature sets) with the rendering complexity information inherent in the visual rendering solution itself (such as required shader complexity, texture resolution, number of draw calls, etc.) as a feature vector, and inputs it into a machine learning model pre-trained with a large amount of historical performance data. This model has learned the actual performance of visual solutions of various complexities running on different hardware configurations, and therefore is capable of predictive inference.

[0125] Among them, the pre-trained machine learning model can be selected according to the actual situation.

[0126] S630 receives the prediction results output by the machine learning model.

[0127] The prediction results include at least the expected performance bottlenecks and resource requirements of the visual presentation solution on the target vehicle platform.

[0128] In one possible implementation, a pre-trained machine learning model completes inference and outputs structured predictions. These predictions specifically identify prefetching performance bottlenecks (e.g., predicting that pixel fill rate will be the primary bottleneck limiting frame rate when running a specific effect on the platform's GPU) and detailed resource requirements for completing this visual rendering scheme (e.g., predicting that at least XXMB of video memory is needed to store textures). These predictions provide more advanced and instructive information than raw hardware data, directly indicating the direction for optimization and adaptation.

[0129] S640: Based on the prediction results, a comprehensive evaluation is performed on multiple candidate rendering paths.

[0130] In one possible implementation, the visual rendering system evaluates all feasible rendering paths for the current target in-vehicle platform based on predicted performance bottlenecks and resource requirements. These paths might include: using a high-performance Vulkan backend but reducing shadow quality; using an OpenGL ES compatible backend with partial optimizations; or using a simplified rendering scheme that saves more memory. The evaluation employs a multi-dimensional algorithm, calculating a comprehensive score for each path based on three core dimensions: performance (such as predicted frame rate and latency), power consumption (such as predicted energy consumption), and final rendering quality.

[0131] It should be noted that this step is completed by the intelligent rendering path selector of the adaptation layer.

[0132] S650. Based on the comprehensive evaluation results, determine the target rendering path from multiple candidate rendering paths.

[0133] In one possible implementation, after completing multi-dimensional scoring of all rendering paths, the visual rendering system executes a decision algorithm. This typically involves ranking the overall scores of each rendering path based on preset optimization goals (e.g., in automotive scenarios, power consumption and stability might be given higher weights). Ultimately, the candidate rendering path with the highest overall evaluation score (e.g., the most energy-efficient OpenGL ES path while ensuring smoothness) is determined as the "target rendering path" for the current hardware and software combination.

[0134] S660: Generate a target rendering strategy based on the target rendering path and prediction results.

[0135] The target rendering strategy is a set of visual configuration instructions used to guide the rendering process on the target vehicle platform.

[0136] In one possible implementation, the visual rendering system concretizes the decision into an executable target rendering strategy. This target rendering strategy explicitly includes: the selected rendering backend (e.g., using OpenGL ES 3.1), specific graphics quality parameters set according to predicted resource requirements (e.g., limiting texture resolution to 1024x1024 and disabling dynamic shadows), and the corresponding resource allocation scheme (e.g., pre-allocating 150MB of graphics memory). This set of visual configuration instructions constitutes a complete action plan, which is sent to the rendering layer, which precisely configures and executes all subsequent rendering operations according to this target rendering strategy, thereby achieving the predicted optimal effect on the given hardware.

[0137] It should be noted that this step is the encapsulation stage of the target rendering strategy.

[0138] To ensure smooth and consistent operation of the same visual rendering solution across different vehicle models with varying hardware, the visual rendering method provided in this application first performs comprehensive hardware capability and graphics interface support detection on the target vehicle platform based on the rendering requirements of the visual rendering solution. This accurately obtains key data such as the computing performance of its graphics processor, memory bandwidth, and supported graphics API feature sets. Subsequently, this detection data, along with the visual rendering solution itself, is input into a pre-defined machine learning model for analysis. This model intelligently predicts the expected performance bottlenecks and resource requirements of the visual rendering solution on the current vehicle platform. Based on this prediction, the visual rendering system comprehensively evaluates multiple candidate rendering paths, including Vulkan and OpenGL ES, considering the balance between performance, power consumption, and rendering quality. Finally, the visual rendering system selects the optimal target rendering path based on the evaluation results and generates a target rendering strategy that includes a specific rendering backend, graphics quality parameters, and resource allocation scheme. Therefore, this intelligent detection-prediction-evaluation-decision process has for the first time achieved automatic optimization of the rendering path based on hardware perception in the field of in-vehicle voice assistants. It fundamentally solves the problem of one-time development and multi-terminal adaptation caused by hardware fragmentation, so that personalized visual design does not need to repeat performance tuning and adaptation development for different car models. While ensuring visual performance and smooth operation, it greatly reduces development costs and complexity.

[0139] Optionally, the above method comprehensively evaluates multiple candidate rendering paths based on the prediction results, including: Based on the prediction results, the evaluation scores of each candidate rendering path in terms of visual performance, energy consumption, and rendering quality are calculated to obtain the comprehensive evaluation results.

[0140] The visual performance evaluation score is based on the predicted frame rate or interaction latency of the prediction results. The score is determined by referring to a pre-defined scoring table or calculation formula; for example, a higher predicted frame rate and lower latency result in a higher visual performance evaluation score. This visual performance evaluation score is directly related to the smoothness of the user experience.

[0141] The energy consumption assessment score is based on the estimated power overhead or energy consumption added to the implementation of the visual presentation solution, as predicted in the forecast results. In the target automotive environment, power consumption directly impacts range and heat dissipation, making it a critical evaluation item. The lower the predicted energy consumption, the higher the energy consumption assessment score.

[0142] In one possible implementation, the intelligent rendering path selector executes a multi-dimensional evaluation algorithm. The visual rendering system first lists all candidate rendering paths available on the current target in-vehicle platform, such as pure Vulkan paths, Vulkan paths combined with specific extensions, pure OpenGL ES paths, and software rendering paths with different quality levels. For each rendering path, the selector calls the prediction results obtained by the cognitive hardware detection module through a machine learning model. Based on a set of preset, dynamically adjustable scoring rules, the intelligent rendering path selector maps these predicted quantitative indicators (such as a predicted frame rate of 55 FPS) to three dimensions: visual performance, energy consumption, and rendering quality, calculating corresponding evaluation scores. The evaluation score for the rendering quality dimension may be determined based on the set of graphics API features supported by the rendering path (such as whether it supports advanced shaders, HDR, etc.) and the image quality level allowed by the predicted performance margin. Finally, a comprehensive evaluation result containing scores across the three dimensions is generated for each rendering path.

[0143] The above method determines the target rendering path from multiple candidate rendering paths based on the comprehensive evaluation results, including: The candidate rendering path with the highest evaluation score among multiple candidate rendering paths is selected as the target rendering path.

[0144] In one possible implementation, after completing multi-dimensional scoring of all candidate rendering paths, the intelligent rendering path selector enters the final decision-making stage. The visual rendering system summarizes and calculates the comprehensive evaluation results of each rendering path according to a pre-set strategy (e.g., assigning different weights to the scores of the three dimensions, potentially increasing the weight of energy consumption in battery mode, and potentially increasing the weight of rendering quality in parking entertainment mode), resulting in a final total score representing the quality of the rendering path. This process can be optimized based on learning from historical data, that is, fine-tuning its total score by referring to the historical performance data of the rendering path on similar hardware configurations. Finally, the visual rendering system simply compares the final total scores of all candidate rendering paths, selects the rendering path with the highest total score, and officially determines it as the target rendering path to be adopted by the visual rendering system. This target rendering path specifies which graphics API features, quality presets, and resource allocation schemes to use, and is the direct basis for generating the subsequent target rendering strategy, as well as a direct manifestation of cognitive decision-making.

[0145] The visual rendering method provided in this application, based on prediction results, uses an intelligent rendering path selector in the adaptation layer and a multi-dimensional evaluation algorithm to calculate quantitative evaluation scores for each candidate rendering path in three core dimensions: performance, power consumption, and rendering quality, thereby obtaining a comprehensive evaluation result. The performance score is primarily based on frame rate and latency metrics predicted by the machine learning model, while the power consumption score is based on predicted energy consumption data. Finally, the visual rendering system automatically selects the candidate rendering path with the highest comprehensive evaluation score and identifies it as the target rendering path. This intelligent evaluation and decision-making process fundamentally achieves a dynamic optimal balance between rendering quality, system performance, and energy consumption, ensuring that the rendering strategy selected for the current specific automotive hardware platform can maximize operational smoothness and energy efficiency while meeting visual performance requirements, thus providing a consistent and excellent user experience across vehicles with varying hardware resources.

[0146] Figure 10 A flowchart illustrating a visual presentation method provided in this application embodiment. Figure 4 .like Figure 10 As shown, the above method, based on the target rendering strategy, converts the standardized rendering instructions corresponding to the visual presentation scheme into low-level graphics interface instructions that match the target vehicle platform, including: S710: Analyze the target rendering strategy and determine the preferred rendering backend corresponding to the target rendering strategy.

[0147] In one possible implementation, after the adaptation layer generates a target rendering strategy based on the cognitive hardware detection module and intelligent decision-making, this target rendering strategy is passed to the rendering layer. One of the tasks of the intelligent rendering interface is to receive unified commands and parse the accompanying rendering strategy information. This target rendering strategy explicitly includes the optimal rendering path selected by the intelligent rendering path selector based on multi-dimensional evaluations (such as performance, power consumption, and quality). Its core is specifying the specific rendering backend type that should be used preferentially (e.g., the preferred Vulkan adapter). The parsing process involves reading this target rendering strategy instruction, preparing for subsequent calls to the specific target automotive platform adapter.

[0148] It should be noted that this step is performed by the intelligent rendering interface in the rendering layer.

[0149] S720: Detect whether the target vehicle platform supports the preferred rendering backend.

[0150] In one possible implementation, the detection logic in the rendering adapter or intelligent rendering interface of the visual rendering system performs real-time detection on the current target vehicle platform based on the preferred rendering backend type (such as Vulkan) determined in the previous step. The detection includes at least: confirming whether the target vehicle platform's hardware driver has the support library for this graphics API (Vulkan) installed, querying the highest supported API version, and checking whether the necessary extended functions are available. This process is dynamic, ensuring that decisions are based on the latest, real-world capabilities of the target vehicle platform, rather than static assumptions.

[0151] It should be noted that this step is a key component of the automatic adapter selection based on device capabilities, one of the three core functions of the adaptive multi-platform adapter.

[0152] S730, if supported, calls the first adapter corresponding to the preferred rendering backend to convert the standardized rendering instructions corresponding to the visual presentation scheme into the underlying graphics interface instructions of the preferred rendering backend.

[0153] In one possible implementation, once support is confirmed—that is, the target vehicle platform supports the preferred rendering backend—the intelligent rendering interface loads and invokes the first adapter bound to the preferred rendering backend (e.g., the Vulkan adapter dynamic library implemented in the visual rendering system). This rendering adapter is essentially a complete translator implemented for a specific graphics API (such as Vulkan). It receives standardized rendering instructions from the upper layer and then, strictly following the Vulkan API specification, translates and assembles these standardized rendering instructions line by line into actual low-level driver call commands (i.e., low-level graphics interface instructions) that conform to Vulkan syntax. Subsequently, these low-level graphics interface instructions are submitted to the visual rendering system and ultimately executed by the GPU driver to complete efficient rendering.

[0154] It should be noted that this step is the standard path in the runtime dynamic translation process.

[0155] If S740 does not support it, it will sequentially detect and select the alternative rendering backends supported by the target vehicle platform according to the preset downgrade mechanism, and call the alternative adapter corresponding to the alternative rendering backend to convert the standardized rendering instructions into the underlying graphics interface instructions of the alternative rendering backend.

[0156] In one possible implementation, when the preferred API (such as Vulkan) is detected to be unavailable—that is, when the target vehicle platform is detected to not support the preferred rendering backend—the visual rendering system will not crash or stop. Instead, it will attempt rendering in a predetermined fallback order. This fallback order could be, for example, Vulkan → OpenGL ES → software rendering.

[0157] The visual rendering system follows this sequence, using the next alternative rendering backend (such as OpenGL ES) as the new detection target and repeating the detection process in step two. Once a candidate rendering backend (such as OpenGL ES) is found to be supported, the corresponding alternative rendering adapter (such as the OpenGL ES adapter) is immediately loaded and invoked. This alternative rendering adapter also has the ability to translate standardized instructions into OpenGL ES API instructions. In this way, the visual rendering system ensures that even on hardware with lower performance or poor compatibility, the same visual rendering scheme can be translated into the lowest-level graphics interface instructions executable by the current target vehicle platform through function mapping and fallback. This guarantees the availability of basic functions and the bottom-line consistency of visual rendering, ultimately ensuring cross-platform compatibility.

[0158] The visual rendering method provided in this application intelligently determines the preferred rendering backend by dynamically analyzing the target rendering strategy to select the optimal rendering path under the current hardware platform. Subsequently, the visual rendering system automatically detects the actual support of the target vehicle platform for the preferred rendering backend: if supported, the corresponding first adapter is invoked to convert the standardized rendering instructions of the visual rendering scheme into the underlying graphics API instructions of the backend in real time, thereby fully utilizing the hardware potential and achieving high-efficiency, high-quality visual rendering; if not supported, a preset degradation mechanism is immediately used to sequentially detect and select a scheme supported by the target vehicle platform from multiple alternative rendering backends, and the corresponding alternative rendering adapter is invoked to complete the standardized rendering instruction conversion and rendering, ensuring that the visual rendering system maintains reliable operation and consistent visual output in diverse and fragmented target vehicle hardware environments. Thus, this application fundamentally solves the industry problems of repetitive development of personalized content, inconsistent rendering performance, and difficulty in guaranteeing performance caused by differences in hardware and software interfaces between vehicle models.

[0159] Based on the same inventive concept, this application also provides a visual presentation device. Since the principle of the device in this application is similar to the visual presentation method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0160] Figure 11 This is a schematic diagram of the structure of a visual presentation device provided in an embodiment of this application. Figure 11 As shown, the visual presentation device 800 may include: The first generation module 801 is used to generate target visual configuration data associated with the target driving scenario in response to the visual image customization operation of the in-vehicle voice assistant. The second generation module 802 is used to generate a visual presentation scheme based on the target visual configuration data. The visual presentation scheme is a structured rendering scheme formed by managing the target visual components corresponding to the target visual configuration data. The third generation module 803 is used to generate a target rendering strategy that matches the visual presentation scheme based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target vehicle platform. The conversion module 804 is used to convert the standardized rendering instructions corresponding to the visual presentation scheme into low-level graphics interface instructions that match the target vehicle platform, based on the target rendering strategy, so as to drive the rendering backend of the target vehicle platform to perform rendering.

[0161] In one optional implementation, the second generation module 802 is specifically used for: determining the target visual component corresponding to the target visual configuration data based on the target visual configuration data; scanning and loading the component plugin files corresponding to the target visual component from the preset component directory through the component manager; parsing and managing the dependency declarations of each component plugin file to generate component instances corresponding to each component plugin file; and managing the lifecycle and hot-plugging of each component instance during the operation of the visual presentation system, and driving each component instance to work to generate a visual presentation scheme.

[0162] In one optional implementation, the second generation module 802 is specifically used to: parse the dependency declarations of each component plugin file and construct a component dependency graph; determine the component loading order of each component plugin file based on the component dependency graph; and load each component plugin file sequentially based on the component loading order to generate a component instance corresponding to each component plugin file.

[0163] In one optional implementation, the second generation module 802 is specifically configured to: monitor the lifecycle of each component instance through the component manager and determine the lifecycle stage of each component instance; in response to a preset hot-plug command, the component manager determines the target component to be replaced and the new component plugin file to be replaced; based on the lifecycle stage of each component instance, determine the lifecycle stage of the target component to be replaced; based on the lifecycle stage of the target component to be replaced, unload the target component and load the new component instance corresponding to the new component plugin file to drive each component instance to work and generate a visual presentation scheme.

[0164] In one optional implementation, the first generation module 801 is specifically configured to: obtain a scenario simulation environment corresponding to the target driving scenario based on the user's selection operation of the target driving scenario; obtain a combined visual component based on the user's drag-and-drop combination operation of the visual component in the scenario simulation environment; obtain a combined attribute configuration based on the user's attribute configuration operation of the combined visual component; perform an interactive preview of the visual presentation effect corresponding to the combined visual component and the combined attribute configuration to obtain the association relationship with the target driving scenario; and generate target visual configuration data based on the combined visual component, the combined attribute configuration and the association relationship.

[0165] In an optional implementation, the third generation module 803 is specifically configured to: detect the hardware capabilities and underlying graphics interface support of the target vehicle platform based on the rendering requirements corresponding to the visual presentation scheme; obtain the detection results of the target vehicle platform, the detection results including at least: the computing performance data of the graphics processor, memory bandwidth data, and the supported graphics API feature set; input the computing performance data, memory bandwidth data, graphics API feature set, and visual presentation scheme into a pre-trained machine learning model for processing; receive the prediction results output by the machine learning model, the prediction results including at least: the expected performance bottleneck and resource requirements of the visual presentation scheme on the target vehicle platform; comprehensively evaluate multiple candidate rendering paths based on the prediction results; determine the target rendering path from the multiple candidate rendering paths according to the comprehensive evaluation results; and generate a target rendering strategy according to the target rendering path and the prediction results, wherein the target rendering strategy is a set of visual configuration instructions used to guide the rendering process on the target vehicle platform.

[0166] In an optional implementation, the third generation module 803 is specifically used to: calculate the evaluation scores of each candidate rendering path in terms of visual performance, energy consumption, and rendering quality according to the prediction results, and obtain a comprehensive evaluation result; wherein, the evaluation score of visual performance is determined based on the predicted frame rate or latency, and the evaluation score of energy consumption is determined based on the predicted energy consumption; the third generation module 803 is specifically used to: filter the candidate rendering path with the highest evaluation score in the comprehensive evaluation results of multiple candidate rendering paths, and determine it as the target rendering path.

[0167] In one optional implementation, the conversion module 804 is specifically used for: parsing the target rendering strategy and determining the preferred rendering backend corresponding to the target rendering strategy; detecting whether the target vehicle platform supports the preferred rendering backend; if it supports it, calling the first adapter corresponding to the preferred rendering backend to convert the standardized rendering instructions corresponding to the visual presentation scheme into the underlying graphics interface instructions of the preferred rendering backend; if it does not support it, according to the preset degradation mechanism, sequentially detecting and selecting the alternative rendering backends supported by the target vehicle platform, and calling the alternative adapter corresponding to the alternative rendering backend to convert the standardized rendering instructions into the underlying graphics interface instructions of the alternative rendering backend.

[0168] It should be noted that for details not disclosed in the visual presentation device of this application embodiment, please refer to the details disclosed in the visual presentation method of this application embodiment, which will not be repeated here.

[0169] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).

[0170] Optionally, embodiments of this application also provide a computer-readable storage medium storing a computer program. When the computer program is run by a processor, the processor executes the steps of the visual presentation method for the mobile storage medium described in the above embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, 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 functional units in the various embodiments of this application can be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0172] Optionally, this embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a visual presentation method provided in the above embodiment.

[0173] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0174] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0175] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or 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 device, 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; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0176] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A visual presentation method, characterized in that, include: In response to the visual image customization operation of the in-vehicle voice assistant, target visual configuration data associated with the target driving scenario is generated; Based on the target visual configuration data, a visual presentation scheme is generated. The visual presentation scheme is a structured rendering scheme formed by managing the target visual components corresponding to the target visual configuration data. Based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target vehicle platform, a target rendering strategy matching the visual presentation scheme is generated. Based on the target rendering strategy, the standardized rendering instructions corresponding to the visual presentation scheme are converted into underlying graphics interface instructions that match the target vehicle platform, so as to drive the rendering backend of the target vehicle platform to perform rendering.

2. The method according to claim 1, characterized in that, The step of generating a visual presentation scheme based on the target visual configuration data includes: Based on the target vision configuration data, determine the target vision component corresponding to the target vision configuration data; The component manager scans and loads the component plugin files corresponding to the target visual component from the preset component directory. The dependency declarations of each component plugin file are parsed and managed to generate component instances corresponding to each component plugin file. During the operation of the visual presentation system, the lifecycle and hot-plugging of each component instance are managed, and each component instance is driven to work to generate the visual presentation scheme.

3. The method according to claim 2, characterized in that, The process of parsing and managing the dependency declarations of each component plugin file to generate component instances corresponding to each component plugin file includes: Parse the dependency declarations of each component plugin file and construct a component dependency graph; Based on the component dependency graph, the component loading order of each component plugin file is determined; Based on the component loading order, the component plugin files are loaded sequentially, and component instances corresponding to each component plugin file are generated.

4. The method according to claim 2, characterized in that, The management of the lifecycle and hot-swapping of each component instance, and the driving of each component instance to generate the visual presentation scheme, includes: The component manager monitors the lifecycle of each component instance and determines the lifecycle stage of each component instance. In response to a preset hot-plug command, the component manager determines the target component to be replaced and the new component plugin file to be replaced; Based on the lifecycle stage of each component instance, the lifecycle stage of the target component to be replaced is determined. Based on the lifecycle stage of the target component to be replaced, the target component is uninstalled, and a new component instance corresponding to the new component plugin file is loaded to drive each component instance to work and generate the visual presentation scheme.

5. The method according to claim 1, characterized in that, The generation of target visual configuration data associated with the target driving scenario includes: Based on the user's selection of the target driving scenario, the scenario simulation environment corresponding to the target driving scenario is obtained; In the simulated environment, the combined visual components are obtained based on the drag-and-drop combination operation performed by the user on the visual components; Based on the user's attribute configuration operation on the combined visual components, obtain the combined attribute configuration; Interactively preview the visual presentation effects corresponding to the combined visual components and the combined attribute configurations to obtain the association relationship with the target driving scenario; Based on the combined visual components, the combined attribute configuration, and the association relationship, the target visual configuration data is generated.

6. The method according to claim 1, characterized in that, The step of generating a target rendering strategy that matches the visual presentation scheme, based on the detection results of the target vehicle platform's hardware capabilities and underlying graphics interface support, includes: Based on the rendering requirements corresponding to the visual presentation scheme, the hardware capabilities and underlying graphics interface support of the target vehicle platform are tested, and the test results of the target vehicle platform are obtained. The test results include at least: the computing performance data of the graphics processor, the memory bandwidth data, and the set of graphics API features supported. The computational performance data, the memory bandwidth data, the graphics API feature set, and the visual presentation scheme are input into a pre-trained machine learning model for processing. The prediction results output by the machine learning model are received, and the prediction results include at least the expected performance bottlenecks and resource requirements of the visual presentation scheme on the target vehicle platform. Based on the prediction results, a comprehensive evaluation is performed on multiple candidate rendering paths; Based on the comprehensive evaluation results, the target rendering path is determined from the multiple candidate rendering paths; Based on the target rendering path and the prediction result, the target rendering strategy is generated, wherein the target rendering strategy is a set of visual configuration instructions used to guide the rendering process on the target vehicle platform.

7. The method according to claim 6, characterized in that, The comprehensive evaluation of multiple candidate rendering paths based on the prediction results includes: Based on the prediction results, the evaluation scores of each candidate rendering path in terms of visual performance, energy consumption and rendering quality are calculated to obtain the comprehensive evaluation result. The visual performance evaluation score is determined based on the predicted frame rate or latency, and the energy consumption evaluation score is determined based on the predicted energy consumption. The step of determining the target rendering path from the multiple candidate rendering paths based on the comprehensive evaluation results includes: The candidate rendering path with the highest evaluation score among the multiple candidate rendering paths is selected and determined as the target rendering path.

8. The method according to claim 1, characterized in that, The step of converting the standardized rendering instructions corresponding to the visual presentation scheme into low-level graphics interface instructions that match the target vehicle platform, based on the target rendering strategy, includes: Analyze the target rendering strategy and determine the preferred rendering backend corresponding to the target rendering strategy; Detect whether the target vehicle platform supports the preferred rendering backend; If supported, the first adapter corresponding to the preferred rendering backend is invoked to convert the standardized rendering instructions corresponding to the visual presentation scheme into the underlying graphics interface instructions of the preferred rendering backend. If not supported, then according to the preset degradation mechanism, the alternative rendering backends supported by the target vehicle platform are detected and selected in sequence, and the alternative adapters corresponding to the alternative rendering backends are called to convert the standardized rendering instructions into the underlying graphics interface instructions of the alternative rendering backends.

9. A visual presentation system, characterized in that, include: Component layer, adaptation layer, rendering layer, editing layer, and component manager; The editing layer is used to respond to the user's operation of customizing the visual image of the in-vehicle voice assistant and generate target visual configuration data; The component layer is communicatively connected to the editing layer and is used to receive the target visual configuration data in order to generate a visual presentation scheme based on the target visual configuration data. The component manager is integrated into the component layer and is used to manage the target visual components; The adaptation layer is communicatively connected to the component layer and is used to generate a target rendering strategy that matches the visual presentation scheme based on the visual presentation scheme and the detection results of the hardware capabilities and underlying graphics interface support of the target vehicle platform. The rendering layer is communicatively connected to the component layer and the adaptation layer, respectively, and is used to receive the standardized rendering instructions corresponding to the visual presentation scheme and the target rendering strategy, and convert the standardized rendering instructions into underlying graphics interface instructions that match the target vehicle platform based on the target rendering strategy.

10. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in any one of claims 1 to 8.

Images