Method for controlling view component, controller and vehicle

Abstract

The invention provides a method for controlling a view component, a controller and a vehicle, and relates to the technical field of vehicle-mounted equipment control. According to the method, after the target control instruction is received, whether the current state of the target component is the registration state or not is determined, so that the ready opportunity of the target component can be accurately sensed. The target control instruction is stored to an instruction buffer when the target component is not registered (unready), which can ensure that the target control instruction is never lost. And the target control instructions are replayed after the target component is ready, so that complete recovery and synchronization of a correct state can be realized. Namely, according to the method, through a buffering mechanism of the instruction buffering area, the problems that the control instruction is lost due to the fact that the registration sequence is disordered and further the target component is in a false dead state or is abnormal in function can be thoroughly solved, and the control instruction loss is converted into acceptable display delay; and the target component is ensured to present the correct state which is completely the same as the expectation of the vehicle-mounted application.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted equipment control technology, and more specifically, to a method, controller, and vehicle for controlling a view component in the field of vehicle-mounted equipment control technology. Background Technology

[0002] Currently, in the existing software architecture of smart cockpits, view components run within the rendering process, which is isolated from the main process running the in-vehicle application. This ensures that a crash in a view component does not affect the entire in-vehicle application. For example, if a view component malfunctions, the entire vehicle system can still maintain stable operation.

[0003] However, this process isolation leads to a problem: the initialization of the rendering process and the main process is completely asynchronous. The in-vehicle application might send control commands to a view component before the view component has finished registering. These early control commands are then discarded because they cannot find a receiving target (the view component is not yet registered). When the view component finally completes registration, it will be in an undefined, "frozen" state because it missed the previous control commands. Specifically, for example, the area on the in-vehicle application that should display the view component will be blank.

[0004] Therefore, there is an urgent need for a method to control view components so as to ensure that the view components present the correct state exactly as expected by the vehicle application, regardless of the disordered registration order of the vehicle application and the view components, and that the state is not lost due to disordered registration order. Summary of the Invention

[0005] This application provides a method, controller, and vehicle for controlling a view component. The method ensures that the view component presents the correct state exactly as expected by the vehicle application when the registration order of the vehicle application and the view component is disordered, and the state is not lost due to the disordered registration order.

[0006] In a first aspect, a method for controlling a view component is provided, the method comprising: in response to a target control instruction, determining the current state of the target component, the target control instruction being a control instruction sent by an in-vehicle application to the target component, the in-vehicle application running in a first process, the target component running in a second process isolated from the first process, the in-vehicle application being used to provide a view display window for the target component; if the current state is not a registered state, storing the target control instruction in an instruction buffer, the registered state being used to indicate that the target component is ready to receive control instructions; in response to the target component being in a registered state, replaying the target control instruction in the instruction buffer to the target component, so that the target component performs the operation corresponding to the target control instruction.

[0007] In the above technical solution, after receiving the target control command, it is determined whether the current state of the target component is registered, which allows for precise perception of the target component's readiness timing. When the target component is not registered (not ready), the target control command is stored in the command buffer, ensuring that the target control command is never lost. Once the target component is ready, these target control commands are replayed, enabling complete restoration and synchronization of the correct state. In other words, this solution, through the buffering mechanism of the command buffer, completely solves the problem of control command loss caused by disordered registration order, as well as the further issues of the target component being in a frozen state (state loss) or functional abnormality. It transforms the loss of control commands into an acceptable display delay, ensuring that the target component presents the correct state exactly as expected by the in-vehicle application. Therefore, this solution transforms the original functional error into a performance optimization problem that only affects the initial loading time, significantly improving the robustness of in-vehicle applications and user experience.

[0008] In conjunction with the first aspect, in some possible implementations, determining the current state of the target component includes: obtaining a mapping table in a service component, which manages the registration state of view components. This mapping table includes the identification information and interface instance of the view component. The identification information is a composite key consisting of the view component's type identifier and the instance identifier under the corresponding type. The interface instance is used to trigger the view component to perform a corresponding operation. The process involves determining whether the composite key and interface instance of the target component exist in the mapping table. If the composite key and interface instance of the target component exist in the mapping table, the current state is determined to be the registration state. If the composite key and / or interface instance of the target component do not exist in the mapping table, the current state is determined not to be the registration state.

[0009] In the above technical solution, a composite key (type identifier + instance identifier) ​​can clearly distinguish different view components, ensuring the uniqueness and accuracy of managing the display state of view components in multiple view types and multiple instance scenarios, and avoiding state confusion between different view components. Furthermore, the interface instance provides the ability to directly trigger operations, creating a closed loop between state judgment and the execution of subsequent control commands. That is, based on the composite key of the target component in the mapping table and direct lookup of the interface instance, this solution can complete the state confirmation of the target component with a single query. This not only reduces communication overhead between processes but also ensures the real-time performance and reliability of state judgment, providing a solid state-aware foundation for the buffering mechanism of target control commands.

[0010] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the target control instruction includes multiple sub-control instructions. Storing the target control instruction in the instruction buffer includes: sorting the multiple sub-control instructions according to the reception time to obtain sorted multiple sub-control instructions, and storing the sorted multiple sub-control instructions in the instruction buffer; and replaying the target control instruction in the instruction buffer to the target component includes: replaying the sorted multiple sub-control instructions in the instruction buffer to the target component one by one through a single-channel communication method.

[0011] In the above technical solution, multiple sub-control commands are sorted according to their reception time, which ensures the timing consistency of the multiple sub-control commands. That is, regardless of the channel from which the sub-control commands originate, they can be queued in the command buffer according to their actual reception trigger order, eliminating the risk of out-of-order sub-control commands caused by concurrent use of multiple channels (the Binder channel for transmitting status commands and the Input channel for transmitting event commands (such as touch commands)). Furthermore, multiple sub-control commands are replayed to the target component one by one through single-channel communication. This forces all sub-control commands to follow the same communication path, utilizing the first-in-first-out characteristic of a single channel to ensure a strict timing of the sub-control commands arriving at the target component, avoiding command interleaving that may occur during parallel transmission across multiple channels. These two steps work together to transform the originally asynchronous sub-control command stream, scattered across multiple channels, into an ordered command sequence within a single channel, fundamentally eliminating command races and state misalignment caused by channel fragmentation, ensuring that the final display state of the view component is exactly the same as the expectations of the automotive application.

[0012] Combining the first aspect and the above implementation methods, in some possible implementation methods, the multiple sub-control instructions are sorted according to the reception time to obtain sorted multiple sub-control instructions, including: sorting the multiple sub-control instructions according to the reception time to obtain sorted multiple candidate sub-control instructions; for each candidate instruction in the sorted multiple candidate sub-control instructions, the candidate instruction is converted into a control instruction of a target format to obtain the sorted multiple sub-control instructions, the target format including a type identifier code and an instruction data packet, the type identifier code being used to identify the type of control instruction, and the instruction data packet being used to carry the instruction parameters of the control instruction.

[0013] In the above technical solution, for each candidate instruction among the sorted candidate sub-control instructions, the candidate instruction is converted into a control instruction containing a type identifier code and an instruction data packet, which enables standardized encoding and decoupling of sub-control instructions. The type identifier code provides a clear identifier for the instruction type, enabling the target component to quickly identify the instruction type and select the corresponding processing logic. The instruction data packet encapsulates all parameters of the control instruction, achieving decoupling between parameters and instruction type, and making parameter parsing logic reusable. In other words, the above format conversion process can unify sub-control instructions, which may originally have different formats, into a structured data packet. This allows the target component to process all types of instructions with only a unified parsing framework. Therefore, this solution can significantly simplify the processing complexity of sub-control instructions and ensure the integrity and consistency of sub-control instructions during transmission and parsing.

[0014] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the plurality of sub-control instructions include a plurality of state class instructions, which are used to control the state changes of the target component. Replaying the target control instructions in the instruction buffer to the target component includes: comparing the reception times of the plurality of state class instructions, determining the latest time, and determining the state class instruction corresponding to the latest time in the instruction buffer as the first state class instruction; and replaying the first state class instruction to the target component.

[0015] In the above technical solution, the reception times of multiple state-type instructions are compared to determine the state-type instruction corresponding to the latest time, i.e., the first state-type instruction. This can overwrite older intermediate state instructions, determine the optimal instruction reflecting the final state, and eliminate duplicate, invalid, or outdated state switching operations. This solution ensures that the view component directly obtains the latest target state during replay, avoiding redundant execution of intermediate state instructions. This not only significantly reduces the processing overhead of control instructions and the consumption of computing resources, but also avoids view flickering or instability that may be caused by frequent state jumps of the view component. In other words, by replaying only the latest state-type instructions, the above solution ensures the correctness of the final state while also achieving efficient resource optimization.

[0016] In combination with the first aspect and the above implementation methods, in some possible implementation methods, the second process is a process that is not attached to the target management component, which is used to manage the lifecycle of the target component, and the plurality of state class instructions includes a second state class instruction for controlling the lifecycle.

[0017] The aforementioned technical solution transforms the lifecycle control logic, originally dependent on the target management component, into a mechanism where a second process actively receives and executes state-based instructions. This means that the lifecycle of the view component is actively managed through state-based instructions. This allows view components running in independent processes, even when separated from the traditional target management component, to achieve precise switching and control of their display state by receiving and executing standardized lifecycle instructions, thus avoiding functional abnormalities caused by the loss of lifecycle control from the target management component. This solution provides reliable state synchronization capabilities for view components in rootless environments, ensuring that the display state of the view component remains consistent with the expectations of automotive applications, eliminating potential state inconsistencies caused by rootless environments at their source.

[0018] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the plurality of sub-control instructions further include a plurality of event-type instructions. These event-type instructions are used to trigger a change in the state of the target component and replay the target control instructions in the instruction buffer to the target component. This includes: sorting the plurality of event-type instructions in the instruction buffer according to the receiving time to obtain a sorted plurality of event-type instructions; selecting a preset number of event-type instructions with the lowest ranking from the sorted plurality of event-type instructions and clearing the remaining event-type instructions; and replaying the preset number of event-type instructions to the target component.

[0019] In the above technical solution, only a preset number of event-type instructions at the end of the order are retained. This effectively controls the queue length of sub-control instructions in extremely high-concurrency scenarios, preventing the instruction buffer from expanding indefinitely and exhausting memory due to the backlog of event-type instructions. In other words, this solution sets an upper limit on the number of event-type instructions buffered in the instruction buffer through a restricted append strategy, ensuring timing correctness while preventing the risk of memory overflow. This process enables the automatic discarding of outdated event-type instructions (such as touch events) when users continuously and rapidly operate the in-vehicle application, retaining only the most recently occurring limited number of critical events for replay. This not only ensures the timely response of the view component to the user's latest operations but also ensures the stability and reliability of the in-vehicle application under long-term operation or load fluctuations.

[0020] In combination with the first aspect and the above implementation methods, in some possible implementation methods, after the target component executes the operation corresponding to the target control instruction, the method further includes: determining whether the latest time control instruction in the target control instruction is a destruction instruction; if the latest time control instruction is a destruction instruction, clearing the control instruction corresponding to the target component in the instruction buffer.

[0021] In the above technical solution, after executing the operation corresponding to the target control instruction, the solution actively detects whether the latest control instruction is a destruction instruction. This can accurately identify the end point of the view component's lifecycle. When the latest control instruction is a destruction instruction, all control instructions corresponding to the view component in the instruction buffer are cleared. This completely removes invalid data associated with the destroyed view component, preventing zombie instructions from being held in the singleton's instruction buffer for a long time and continuously occupying memory. The above solution can ensure the purity of control instructions in the instruction buffer, realize dynamic reclamation and efficient reuse of memory resources, and fundamentally eliminate the risk of memory leaks caused by residual control instructions.

[0022] Secondly, an apparatus for controlling a view component is provided, the apparatus comprising: a determining module, configured to determine the current state of a target component in response to a target control command, the target control command being a control command sent by an in-vehicle application to the target component, the in-vehicle application running in a first process, and the target component running in a second process isolated from the first process, the in-vehicle application being configured to provide a view display window for the target component; a storage module, configured to store the target control command in an instruction buffer if the current state is not a registered state, the registered state being used to indicate that the target component is ready to receive control commands; and a replay module, configured to replay the target control command in the instruction buffer to the target component in response to the target component being in a registered state, so that the target component performs the operation corresponding to the target control command.

[0023] In conjunction with the second aspect, in some possible implementations, the apparatus further includes: an acquisition module, configured to acquire a mapping table in a service component, the service component being used to manage the registration status of view components, the mapping table including identification information and interface instances of view components, the identification information being a composite key composed of a type identifier of the view component and an instance identifier under the corresponding type, the interface instance being used to trigger the view component to perform a corresponding operation; and a determination module, specifically configured to: determine whether the composite key and interface instance of the target component exist in the mapping table; if the composite key and interface instance of the target component exist in the mapping table, determine that the current state is the registration state; if the composite key and / or interface instance of the target component do not exist in the mapping table, determine that the current state is not the registration state.

[0024] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the target control instruction includes multiple sub-control instructions. The storage module is specifically used to sort the multiple sub-control instructions according to the receiving time to obtain sorted multiple sub-control instructions, and store the sorted multiple sub-control instructions in the instruction buffer; and the replay module is specifically used to replay the sorted multiple sub-control instructions in the instruction buffer one by one to the target component through a single-channel communication method.

[0025] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the determining module is further configured to: sort the multiple sub-control instructions according to the receiving time to obtain multiple candidate sub-control instructions after sorting; for each candidate instruction in the multiple candidate sub-control instructions after sorting, convert the candidate instruction into a control instruction of a target format to obtain the multiple sub-control instructions after sorting, wherein the target format includes a type identifier code and an instruction data packet, wherein the type identifier code is used to identify the type of the control instruction, and the instruction data packet is used to carry the instruction parameters of the control instruction.

[0026] In combination with the second aspect and the above implementation methods, in some possible implementation methods, the multiple sub-control instructions include multiple state-class instructions, which are used to control the state changes of the target component. The determining module is further used to compare the reception times of the multiple state-class instructions, determine the latest time, and determine the state-class instruction corresponding to the latest time in the instruction buffer as the first state-class instruction. The replay module is further used to replay the first state-class instruction to the target component.

[0027] In combination with the second aspect and the above implementation, in some possible implementations, the second process is a process that is not attached to the target management component, which is used to manage the lifecycle of the target component, and the plurality of state class instructions includes a second state class instruction for controlling the lifecycle.

[0028] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, the plurality of sub-control instructions further include a plurality of event-type instructions, which are used to trigger a change in the state of the target component. The determining module is further used to sort the plurality of event-type instructions in the instruction buffer according to the receiving time to obtain a sorted plurality of event-type instructions. The device further includes: a filtering module, used to filter out a preset number of event-type instructions with the lowest ranking from the sorted plurality of event-type instructions and clear the remaining event-type instructions; the replay module is further used to replay the preset number of event-type instructions to the target component.

[0029] In conjunction with the second aspect and the above implementation methods, in some possible implementation methods, after the target component executes the operation corresponding to the target control instruction, the determining module is further configured to determine whether the latest time control instruction in the target control instruction is a destruction instruction; the device further includes: a clearing module, which is further configured to clear the control instruction corresponding to the target component in the instruction buffer if the latest time control instruction is a destruction instruction.

[0030] Thirdly, a controller is provided, including a storage module and a processing module. The storage module is used to store executable program code, and the processing module is used to call and run the executable program code from the storage module, causing the controller to execute the methods in the first aspect or any possible implementation of the first aspect.

[0031] Fourthly, a vehicle 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 vehicle to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the system architecture of a control view component provided in an embodiment of this application; Figure 2 This is a schematic flowchart of a method for controlling a view component provided in an embodiment of this application; Figure 3 This is an interactive schematic diagram of a control view component provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a device for controlling a view component provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a controller provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0033] 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.

[0034] 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.

[0035] Currently, in the existing software architecture of smart cockpits, the view component runs within the rendering process, and this rendering process is isolated from the main process running the in-vehicle application. This prevents the entire in-vehicle application from being affected if the view component crashes. The in-vehicle application provides the view display window for the view component.

[0036] For example, the in-vehicle application is a navigation application, responsible for core logic such as route planning and location calculation. The view component is a map rendering component, responsible for color rendering of different geographical landmarks (such as buildings, parks, and lakes) and routes in the navigation application. If the map rendering component suddenly crashes due to insufficient memory when the user zooms in and out of the navigation application, it will only result in different geographical landmarks in the navigation application not being rendered in color, and each geographical landmark reverting to the default gray, etc. However, the core functions of the navigation application, such as navigation voice broadcast and route calculation, will still run normally and will not affect the basic usability of the navigation application.

[0037] However, this process isolation leads to a problem: the initialization of the rendering process and the main process (i.e., the process entering a ready state) is completely asynchronous. The in-vehicle application might send control commands to the view component before the view component has finished registering (i.e., the view component is not in a ready state, or it may be said that the view component is not ready to receive control commands sent by the in-vehicle application). At this time, these early control commands are directly discarded because they cannot find a receiving target (the view component has not finished registering and therefore cannot be found). When the view component finally completes registration, it still cannot receive control commands, which causes the view component to be in an undefined "dead" state. That is, the view component cannot clearly perform any operation, resulting in the area on the in-vehicle application that should display the view component being blank, i.e., state loss.

[0038] To clarify further, the aforementioned issues do not occur within the same process. That is, if the view component and the in-vehicle application run in the same process, the control commands (the control commands sent from the in-vehicle application to the view component) are not sent via a communication mechanism. Instead, the in-vehicle application directly calls the methods, eliminating the transmission and discarding stages of the control commands. Even if the view component experiences rendering blockage due to resource contention on the graphics processing unit (GPU), the method call process has already completed execution; only the execution result (rendering operation) is delayed. The control commands themselves are not lost. In other words, the view component will ultimately present the correct state exactly as expected by the in-vehicle application.

[0039] To address the aforementioned issues, this application proposes a method for controlling view components. This method ensures that the view component presents the correct state exactly as expected by the vehicle application when the initialization order of the in-vehicle application and the view component is disordered, preventing state loss due to the disordered initialization order. Specific steps are as follows: Figure 2 .

[0040] Figure 1 This is a schematic diagram of the system architecture of a control view component provided in an embodiment of this application. Figure 2 The implementation steps of the methods for controlling the view component in the middle depend on Figure 1 The system architecture in the following will be combined with Figure 1 The relevant content of this method will be described in detail.

[0041] For example, such as Figure 1 As shown, the in-vehicle device includes an in-vehicle application (Launcher), a view component (OrphanView), and a service component (Tunnel Layer). The in-vehicle application runs in the first process (HostProcess), which is the controller of the view component and the initiator of control commands. The target control commands sent by the HostProcess to the view component include the send(INIT), send(LIFECYCLE), and send(TOUCH) methods. The INIT command is an initialization command, belonging to the state class, used to create or prepare the resources required by the view component. The LIFECYCLE command is a lifecycle command, also belonging to the state class, used to control the state changes of the view component, such as activation / pause (including RESUME and PAUSE commands). The TOUCH command is a touch event command, belonging to the event class, used to transmit the coordinates and action information of the user's touch operation. This in-vehicle application provides the view display window for the aforementioned view component. The RESUME command is a restore / activate command, used to notify the view component to enter the active state. The PAUSE command is a pause / sleep command, used to notify the view component to enter the paused state.

[0042] The aforementioned view component runs in a second process isolated from the first process. Therefore, this view component is also called a Remote View, responsible for rendering the content displayed on the in-vehicle application. This view component and the in-vehicle application belong to the same application layer. There are multiple calling methods for the view component, including the `onCreated()` method and the `registerCallback()` method. The `onCreated()` method is a callback method that is automatically triggered when the view component's initialization is complete. Calling the `registerCallback()` method within `onCreated()` registers the view component's interface instance for receiving control commands with the service component. The aforementioned callback method refers to a method that automatically calls a pre-registered function to handle an event when it occurs.

[0043] The aforementioned service component, also known as the intermediate service component (WidgetBinder), stores interface instances in its internal mapping table using the addCallback() method. This mapping table can also store composite keys for view components. When both the composite key and an interface instance of a view component (specifically, the first view component) are stored in the mapping table, it indicates that the first view component is in a registered state; that is, the service component can be used to manage the registration status of view components. The composite key specifically consists of the view component's type identifier and the corresponding instance identifier. Furthermore, the service component is used to receive and process target control commands sent by the in-vehicle application (such as format conversion) via the onTransact() method, and to store target control commands through its internal command buffer, specifically using the composite key as the key. Target control commands stored in the command buffer can be considered as pending events. The service component runs in a third process isolated from the first and second processes. The service component belongs to the smart buffer layer within the framework layer. It should be understood that the trigger condition for storing the target control command in the command buffer is that the view component is in an unregistered state. Once the view component is registered, the target control command is replayed to the view component. However, if the view component is registered when the target control command is initially sent, the target control command can be sent directly to the view component.

[0044] Figure 2 This is a schematic flowchart of a method for controlling a view component provided in an embodiment of this application.

[0045] It should be understood that the method for controlling a view component provided in this application embodiment can be applied to, for example... Figure 1 The vehicle to which the on-board equipment shown belongs, specifically, is a controller that can be applied in the vehicle.

[0046] For example, such as Figure 2 As shown, the method 200 includes the following steps 201 to 203.

[0047] Step 201: In response to the target control command, determine the current state of the target component. The target control command is a control command sent by the vehicle application to the target component. The vehicle application runs in a first process, and the target component runs in a second process isolated from the first process. The vehicle application is used to provide a view display window for the target component.

[0048] It should be understood that in step 201 above, the control instructions are used to control the display state of the view component, so that the view component performs the rendering task of the content displayed on the in-vehicle application. The current state refers to whether the target component has been registered (initialized or ready). The target component can be displayed on the view display window; that is, the target component is a view component. The target component runs in a second process isolated from the first process. The first process and the second process are different; that is, the target component does not run in the same process as the in-vehicle application. Therefore, from the perspective of the in-vehicle application, this target component is a remote component. In summary, the above-mentioned target component is a remote view component.

[0049] In one possible implementation, determining the current state of the target component in step 201 includes: obtaining a mapping table in a service component, which manages the registration state of view components. The mapping table includes the identification information and interface instance of the view component. The identification information is a composite key composed of the type identifier of the view component and the instance identifier under the corresponding type. The interface instance is used to trigger the view component to perform a corresponding operation. Determining whether the composite key and interface instance of the target component exist in the mapping table; if the composite key and interface instance of the target component exist in the mapping table, determining that the current state is the registration state; if the composite key and / or interface instance of the target component do not exist in the mapping table, determining that the current state is not the registration state.

[0050] It should be understood that in the above scheme, when the view component registration is complete, the composite key of the view component and the interface instance used to receive control commands are registered and stored in the mapping table of the service component. Therefore, it is only necessary to look up the composite key and interface instance of the corresponding target component in the mapping table to determine whether the target component has been registered successfully. Different view components may belong to the same component type. To distinguish / isolate different view components, method 200 sets two dimensions: type identifier and instance identifier. Method 200 does not directly use a single instance identifier because when the number of view components is large, the instance identifiers of all types of view components must be globally unique throughout the entire in-vehicle application, which would bring huge complexity and cause the instance identifiers of some view components to become very long and difficult to manage. The two-dimensional setting method can narrow the scope of uniqueness management to within each type, making the processes of composite key generation, management, and lookup much more efficient, and its structure is also clearer.

[0051] In the above technical solution, a composite key (type identifier + instance identifier) ​​can clearly distinguish different view components, ensuring the uniqueness and accuracy of managing the display state of view components in multiple view types and multiple instance scenarios, and avoiding state confusion between different view components. Furthermore, the interface instance provides the ability to directly trigger operations, creating a closed loop between state judgment and the execution of subsequent control commands. That is, based on the composite key of the target component in the mapping table and direct lookup of the interface instance, this solution can complete the state confirmation of the target component with a single query. This not only reduces communication overhead between processes but also ensures the real-time performance and reliability of state judgment, providing a solid state-aware foundation for the buffering mechanism of target control commands.

[0052] For example, the view components include types such as button A, text box B, and list C. The buttons include circular button 01, triangle button 02, rounded square button 03, and square button 04, etc. The text boxes include password text box 01, single-line text box 02, and multi-line text box 03, etc. The lists include vertical list 01, horizontal list 02, grid list 03, and waterfall list 04. In this example, optionally, the composite key is A03 or C04.

[0053] In some embodiments, the method 200 further includes: when the current state is the registration state, directly sending the target control instruction to the target component so that the target component performs the operation corresponding to the target control instruction.

[0054] It should be understood that the above solution describes a scenario where the target component is already in a registered state when the in-vehicle application initially sends the target control command to it. At this point, the target control command can be sent directly to the target component, which is in accordance with... Figure 1In the case of direct transmission or direct access (i.e., the target control command is directly transmitted to the target component).

[0055] Step 202: If the current state is not a registered state, the target control command is stored in the command buffer. The registered state is used to indicate that the target component is ready to receive control commands.

[0056] It should be understood that in step 202 above, when the target component is not currently in a registered state, the target component has not yet completed registration. At this time, the target component is not yet ready to receive target control instructions, and there is no target to receive the target control instructions. To avoid the target control instructions being discarded at this time, step 202 in method 200 temporarily stores the target control instructions in the instruction buffer in the service component.

[0057] In some embodiments, storing the target control instruction to the instruction buffer in step 202 includes: using the composite key of the target control instruction as the key, and storing the composite key of the target control instruction and the target control instruction to the instruction buffer.

[0058] It should be understood that in the above scheme, the service component runs in a third process, which is different from the first and second processes. The service component connects the vehicle application and the target component to buffer the target control commands sent by the vehicle application and replay them after the target component has completed registration.

[0059] It should also be understood that after the in-vehicle application sends the target control command to the target component, the service component receives and processes it (such as format conversion) through its internal onTransact() method, and stores it in the command buffer when the target component is not currently in a registered state.

[0060] Step 203: In response to the target component being in a registered state, the target control instruction in the instruction buffer is replayed to the target component so that the target component executes the operation corresponding to the target control instruction.

[0061] It should be understood that in step 203 above, when the target component registration is complete, the `onCreated()` method is automatically triggered. Inside the `onCreated()` method, the `registerCallback()` method registers the target component's interface instance for receiving control commands with the service component. The service component then stores the interface instance in its internal mapping table using the `addCallback()` method. Simultaneously, the target component's composite key is also stored in the mapping table. Immediately after the target component's registration, the service component uses the target component's composite key to check if the target component's target control command is present in the command buffer. If the target component's target control command is present, it immediately replays the target component's target control command from the command buffer to the target component through the target component's interface instance.

[0062] In some embodiments, step 203 includes: freezing the instruction buffer in response to the target component being in a registered state; and replaying the target control instructions in the instruction buffer to the target component after the instruction buffer is frozen.

[0063] It should be understood that freezing the instruction buffer means that no more control instructions can be stored in the instruction buffer.

[0064] In one possible implementation, the target control instruction includes multiple sub-control instructions. Step 202, storing the target control instruction in the instruction buffer, includes: sorting the multiple sub-control instructions according to the reception time to obtain sorted multiple sub-control instructions, and storing the sorted multiple sub-control instructions in the instruction buffer; and step 203, replaying the target control instruction in the instruction buffer to the target component, includes: replaying the sorted multiple sub-control instructions in the instruction buffer to the target component one by one through a single-channel communication method.

[0065] It should be understood that in the above scheme, the aforementioned receiving time refers to the time when the sub-control command is generated in the in-vehicle application. For example, if the sub-control command is an event-type command, the receiving time is the time the user touches the in-vehicle application after the user does so. If the sub-control command is a status-type command, the receiving time is the time when the in-vehicle application (such as a navigation application) switches to the background after the user does so, and the receiving time is the time when the in-vehicle application sends the PAUSE command to the view component.

[0066] It should also be understood that replaying multiple sorted sub-control commands in the instruction buffer to the target component one by one via single-channel communication means transmitting the sorted sub-control commands to the target component according to the first-in-first-out (FIFO) characteristic (the sub-control command received earliest should be replayed earliest) through a single channel. Furthermore, replay refers to the process of redistributing the target control commands from the instruction buffer to the target control command after the transmission of the target control commands originally intended for the vehicle application to the target component has been interrupted.

[0067] In the above technical solution, multiple sub-control commands are sorted according to their reception time, which ensures the timing consistency of the multiple sub-control commands. That is, regardless of the channel from which the sub-control commands originate, they can be queued in the command buffer according to their actual reception trigger order, eliminating the risk of out-of-order sub-control commands caused by concurrent use of multiple channels (the Binder channel for transmitting status commands and the Input channel for transmitting event commands (such as touch commands)). Furthermore, multiple sub-control commands are replayed to the target component one by one through single-channel communication. This forces all sub-control commands to follow the same communication path, utilizing the first-in-first-out characteristic of a single channel to ensure a strict timing of the sub-control commands arriving at the target component, avoiding command interleaving that may occur during parallel transmission across multiple channels. These two steps work together to transform the originally asynchronous sub-control command stream, scattered across multiple channels, into an ordered command sequence within a single channel, fundamentally eliminating command races and state misalignment caused by channel fragmentation, ensuring that the final display state of the view component is exactly the same as the expectations of the automotive application.

[0068] It is important to explain here that the following time-series scenarios exist in related technologies (represented by a timeline): Time point T0: The user clicks on a location on the in-vehicle application displayed on the vehicle screen, generating a touch command; Time point T1: The user immediately triggers the Home button. At this time, the in-vehicle application should switch to the background and send a PAUSE command to the remote view component; Time point T3: The PAUSE command reaches the remote view component through the Binder channel; Time point T4: The touch command reaches the remote view component through the Input channel. In the above process, even if T0 is earlier than T1, T4 may be later than T3, possibly due to the longer transmission path of the touch command. This raises a problem: the in-vehicle application is already running in the background, but the remote view component is still responding to the touch command, causing a mismatch between the actual state and the demand, leading the in-vehicle system to determine that the current state of the in-vehicle application is abnormal. This problem arises because the Binder channel and the Input channel are two separate channels with different transmission mechanisms. Using the solution corresponding to weight 3 above, the touch command and PAUSE command can be replayed to the remote view component one by one through a single channel according to the reception time, ensuring that the touch command is always transmitted to the remote view component before the PAUSE command.

[0069] In one possible implementation, the multiple sub-control instructions are sorted according to their reception time to obtain sorted multiple sub-control instructions, including: sorting the multiple sub-control instructions according to their reception time to obtain sorted multiple candidate sub-control instructions; for each candidate instruction in the sorted multiple candidate sub-control instructions, the candidate instruction is converted into a control instruction of a target format to obtain the sorted multiple sub-control instructions, wherein the target format includes a type identifier code and an instruction data packet, the type identifier code is used to identify the type of control instruction, and the instruction data packet is used to carry the instruction parameters of the control instruction.

[0070] It should be understood that the above scheme only transforms the format of the original candidate instructions and adds type identifier codes; it does not change the instruction content. Specifically, the above types include status types and event types. Status type control instructions are status type instructions, and event type control instructions are event type instructions.

[0071] In the above technical solution, for each candidate instruction among the sorted candidate sub-control instructions, the candidate instruction is converted into a control instruction containing a type identifier code and an instruction data packet, which enables standardized encoding and decoupling of sub-control instructions. The type identifier code provides a clear identifier for the instruction type, enabling the target component to quickly identify the instruction type and select the corresponding processing logic. The instruction data packet encapsulates all parameters of the control instruction, achieving decoupling between parameters and instruction type, and making parameter parsing logic reusable. In other words, the above format conversion process can unify sub-control instructions, which may originally have different formats, into a structured data packet. This allows the target component to process all types of instructions with only a unified parsing framework. Therefore, this solution can significantly simplify the processing complexity of sub-control instructions and ensure the integrity and consistency of sub-control instructions during transmission and parsing.

[0072] Optionally, the candidate instructions can be converted into control instructions of the target format through the onTransact() method in the service component to obtain multiple sorted sub-control instructions.

[0073] It should be understood that the control instructions sent to the target component include various types of control instructions, specifically including status-based instructions and event-based instructions. The replay process of these two types of control instructions will be described below through specific embodiments.

[0074] The first type: Status instructions.

[0075] In one possible implementation, the plurality of sub-control instructions include a plurality of status class instructions, which are used to control the state changes of the target component. Step 203, replaying the target control instructions in the instruction buffer to the target component, includes: comparing the reception times of the plurality of status class instructions, determining the latest time, and determining the status class instruction corresponding to the latest time in the instruction buffer as the first status class instruction; and replaying the first status class instruction to the target component.

[0076] It should be understood that in the above scheme, for state-type instructions, if the instruction buffer temporarily stores multiple state-type instructions for the target component, method 200 replays the most recent first state-type instruction to the target component. This is an overwrite update strategy, which avoids replaying some meaningless intermediate state instructions to the target component.

[0077] In the above technical solution, the reception times of multiple state-type instructions are compared to determine the state-type instruction corresponding to the latest time, i.e., the first state-type instruction. This can overwrite older intermediate state instructions, determine the optimal instruction reflecting the final state, and eliminate duplicate, invalid, or outdated state switching operations. This solution ensures that the view component directly obtains the latest target state during replay, avoiding redundant execution of intermediate state instructions. This not only significantly reduces the processing overhead of control instructions and the consumption of computing resources, but also avoids view flickering or instability that may be caused by frequent state jumps of the view component. In other words, by replaying only the latest state-type instructions, the above solution ensures the correctness of the final state while also achieving efficient resource optimization.

[0078] In one possible implementation, the second process is a process that is not attached to the target management component, which manages the lifecycle of the target component, and the plurality of status instructions include a second status instruction for controlling the lifecycle.

[0079] It should be understood that in the above scheme, the target management component is used to manage the lifecycle of the target component. When the second process running the target component is not attached to the target management component, the lifecycle of the target component will not be managed by the target management component. In this case, the target component is in a rootless environment, which is equivalent to the target component losing its "manager". Method 200 sends a second state class instruction to the target component through the vehicle application to ensure that the lifecycle of the target component can be managed by the second state class instruction.

[0080] The aforementioned technical solution transforms the lifecycle control logic, originally dependent on the target management component, into a mechanism where a second process actively receives and executes state-based instructions. This means that the lifecycle of the view component is actively managed through state-based instructions. This allows view components running in independent processes, even when separated from the traditional target management component, to achieve precise switching and control of their display state by receiving and executing standardized lifecycle instructions, thus avoiding functional abnormalities caused by the loss of lifecycle control from the target management component. This solution provides reliable state synchronization capabilities for view components in rootless environments, ensuring that the display state of the view component remains consistent with the expectations of automotive applications, eliminating potential state inconsistencies caused by rootless environments at their source.

[0081] The second type: event-based instructions.

[0082] In one possible implementation, the plurality of sub-control instructions further include a plurality of event-type instructions, which are used to trigger a change in the state of the target component. Step 203, replaying the target control instructions in the instruction buffer to the target component, includes: sorting the plurality of event-type instructions in the instruction buffer according to the receiving time to obtain a sorted plurality of event-type instructions; selecting a preset number of event-type instructions with the lowest ranking from the sorted plurality of event-type instructions and clearing the remaining event-type instructions; and replaying the preset number of event-type instructions to the target component.

[0083] It should be understood that in the above scheme, for event-type instructions, if the instruction buffer temporarily stores multiple event-type instructions for the target component, method 200 replays a preset number of event-type instructions with the most recent reception time and in the correct order (i.e., a preset number of event-type instructions with the later ranking) to the target component, while simultaneously clearing the remaining event-type instructions. This is a restricted append strategy, which can replay a limited number of recently occurring critical event-type instructions to the target component, while also preventing the instruction buffer from expanding indefinitely and exhausting memory.

[0084] In the above technical solution, only a preset number of event-type instructions at the end of the order are retained. This effectively controls the queue length of sub-control instructions in extremely high-concurrency scenarios, preventing the instruction buffer from expanding indefinitely and exhausting memory due to the backlog of event-type instructions. In other words, this solution sets an upper limit on the number of event-type instructions buffered in the instruction buffer through a restricted append strategy, ensuring timing correctness while preventing the risk of memory overflow. This process enables the automatic discarding of outdated event-type instructions (such as touch events) when users continuously and rapidly operate the in-vehicle application, retaining only the most recently occurring limited number of critical events for replay. This not only ensures the timely response of the view component to the user's latest operations but also ensures the stability and reliability of the in-vehicle application under long-term operation or load fluctuations.

[0085] Here's an additional explanation of why an overwrite update strategy is used for status instructions, while a restricted append strategy is used for event instructions. This is because: the status instructions corresponding to the latest time represent the most accurate display state of the target component. The overwrite update strategy discards outdated status instructions, retaining only the latest valid control instructions. Furthermore, the final state of the target component depends only on the status instructions corresponding to the latest time, ensuring the correctness of the final state. However, event instructions represent a sequence of user operations, are time-sensitive, and must be executed in chronological order. Moreover, each event instruction is independent; older event instructions cannot be discarded simply because a new one arrives. Therefore, a restricted append strategy is adopted. While ensuring correct timing, truncation prevents the instruction buffer from expanding indefinitely, thus ensuring both functional correctness and memory safety of the instruction buffer.

[0086] In one possible implementation, after the target component executes the operation corresponding to the target control instruction in step 203, the method 200 further includes: determining whether the latest time control instruction in the target control instruction is a destruction instruction; if the latest time control instruction is a destruction instruction, clearing the control instruction corresponding to the target component in the instruction buffer.

[0087] It should be understood that in the above scheme, the destruction instruction is a status instruction, used to indicate the end of the target component's lifecycle. Clearing the control instructions corresponding to the target component from the instruction buffer means thoroughly clearing all control instructions corresponding to the target component to prevent invalid control instructions from continuously occupying memory.

[0088] In the above technical solution, after executing the operation corresponding to the target control instruction, the solution actively detects whether the latest control instruction is a destruction instruction. This can accurately identify the end point of the view component's lifecycle. When the latest control instruction is a destruction instruction, all control instructions corresponding to the view component in the instruction buffer are cleared. This completely removes invalid data associated with the destroyed view component, preventing zombie instructions from being held in the singleton's instruction buffer for a long time and continuously occupying memory. The above solution can ensure the purity of control instructions in the instruction buffer, realize dynamic reclamation and efficient reuse of memory resources, and fundamentally eliminate the risk of memory leaks caused by residual control instructions.

[0089] In some embodiments, after clearing the control instructions corresponding to the target component in the instruction buffer, the method 200 further includes: clearing the composite key and interface instance of the target component in the mapping table.

[0090] It should be understood that the above solution, by actively cleaning up zombie data, can ensure that no registration information of the target component remains in the mapping table, thereby achieving memory safety after the target component is destroyed and timely recovery of system resources.

[0091] Figure 3 This is an interactive schematic diagram of a control view component provided in an embodiment of this application.

[0092] For example, such as Figure 3 As shown, the system includes an in-vehicle application, an instruction buffer, and a target component. The composite key of the target component is "555-C", where C is the type identifier and 555 is the instance identifier. In Phase 1, the in-vehicle application sends the INIT instruction to the target component. At this time, the target component's current state is unregistered. Therefore, the INIT instruction is stored in the instruction buffer. The in-vehicle application sends the LIFECYCLE instruction to the target component. At this time, the target component's current state is still unregistered. Therefore, the LIFECYCLE instruction is also stored in the instruction buffer. After that, the target component registration is complete, and we are now in Phase 2. The service component will register the target component's interface instance to the mapping table using the addCallback() method. Simultaneously, the target component's composite key is also registered to the mapping table. Then, we enter Phase 3, which is instruction replay. Specifically, the INIT and LIFECYCLE instructions in the instruction buffer are replayed to the target component, causing the target component to perform the corresponding operation.

[0093] The following are three other ways to address the state loss problem in the software architecture of existing smart cockpits.

[0094] The first type: In some embodiments, the in-vehicle application and the target component are bound together. The in-vehicle application has a registered callback listener component that, in response to a first control command, determines whether the target component is started and whether the channel between the in-vehicle application and the target component is ready. The first control command is a control command sent by the in-vehicle application to the target component. When the target component is started and the channel between the in-vehicle application and the target component is ready, the first control command is sent to the target component so that the target component performs the operation corresponding to the first control command.

[0095] It should be understood that the aforementioned callback listener component (ServiceConnection) is implemented through the onServiceConnected() method. Whether the target component has started and whether the channel between the in-vehicle application and the target component is in a ready state can be determined by whether the onServiceConnected() method is called. The above scheme assumes that the target component has started and the channel between the in-vehicle application and the target component is in a ready state when the onServiceConnected() method is called.

[0096] The second type: In some embodiments, in response to a second control command, a second control command is sent to a target component once every preset time interval. The second control command is a control command sent by an in-vehicle application to the target component. Upon receiving a response command to the second control command sent by the target component, the sending of the second control command to the target component is stopped.

[0097] It should be understood that the above scheme describes a process of continuously sending control commands to the target component until the vehicle application receives a response command to the second control command.

[0098] The third type: In some embodiments, in response to a third control command, it is determined whether the target component is started and whether the channel between the vehicle application and the target component is in a ready state, and whether a ready command from the target component is received, wherein the third control command is a control command sent by the vehicle application to the target component; if the target component is started and the channel between the vehicle application and the target component is in a ready state and a ready command from the target component is received, a third control command is sent to the target component so that the target component performs the operation corresponding to the third control command.

[0099] It should be understood that in the above solution, whether the `notifyViewReady()` method is called can be used to determine whether the target component's ready instruction has been received. The above solution assumes that the target component's ready instruction has been received when the `notifyViewReady()` method is called.

[0100] Figure 4 This is a schematic diagram of the structure of a device for controlling a view component provided in an embodiment of this application.

[0101] For example, such as Figure 4 As shown, the device 400 includes: The determination module 401 is used to determine the current state of the target component in response to the target control command. The target control command is a control command sent by the vehicle application to the target component. The vehicle application runs in a first process, and the target component runs in a second process isolated from the first process. The vehicle application is used to provide a view display window for the target component. Storage module 402 is used to store the target control command to the command buffer when the current state is not the registration state. The registration state is used to indicate that the target component is ready to receive control commands. The replay module 403 is used to replay the target control instruction in the instruction buffer to the target component in response to the target component being in the registered state, so that the target component performs the operation corresponding to the target control instruction.

[0102] Optionally, the device 400 further includes: an acquisition module, configured to acquire a mapping table in a service component, the service component being used to manage the registration status of view components, the mapping table including identification information and interface instances of view components, the identification information being a composite key composed of a type identifier of the view component and an instance identifier under the corresponding type, and the interface instance being used to trigger the view component to perform a corresponding operation; the determination module 401 is specifically configured to: determine whether the composite key and interface instance of the target component exist in the mapping table; if the composite key and interface instance of the target component exist in the mapping table, determine that the current state is the registration state; if the composite key and / or interface instance of the target component do not exist in the mapping table, determine that the current state is not the registration state.

[0103] Optionally, the target control instruction includes multiple sub-control instructions. The storage module 402 is specifically used to sort the multiple sub-control instructions according to the receiving time to obtain sorted multiple sub-control instructions, and store the sorted multiple sub-control instructions in the instruction buffer. The replay module 403 is specifically used to replay the sorted multiple sub-control instructions in the instruction buffer to the target component one by one through a single-channel communication method.

[0104] Optionally, the determining module 401 is further configured to: sort the multiple sub-control instructions according to the receiving time to obtain multiple candidate sub-control instructions after sorting; for each candidate instruction in the multiple candidate sub-control instructions after sorting, convert the candidate instruction into a control instruction of a target format to obtain the multiple sub-control instructions after sorting, wherein the target format includes a type identifier code and an instruction data packet, wherein the type identifier code is used to identify the type of the control instruction, and the instruction data packet is used to carry the instruction parameters of the control instruction.

[0105] Optionally, the plurality of sub-control instructions include a plurality of status class instructions, which are used to control the state changes of the target component. The determining module 401 is further used to compare the receiving times of the plurality of status class instructions, determine the latest time, and determine the status class instruction corresponding to the latest time in the instruction buffer as the first status class instruction. The replay module 403 is further used to replay the first status class instruction to the target component.

[0106] Optionally, the second process is a process that is not attached to the target management component, which is used to manage the lifecycle of the target component, and the plurality of status class instructions includes a second status class instruction for controlling the lifecycle.

[0107] Optionally, the plurality of sub-control instructions also include a plurality of event-type instructions, which are used to trigger a change in the state of the target component. The determining module 401 is further used to sort the plurality of event-type instructions in the instruction buffer according to the receiving time to obtain a sorted plurality of event-type instructions. The device 400 also includes: a filtering module, used to filter out a preset number of event-type instructions with the lowest ranking from the sorted plurality of event-type instructions and clear the remaining event-type instructions; the replay module 403 is further used to replay the preset number of event-type instructions to the target component.

[0108] Optionally, after the target component executes the operation corresponding to the target control instruction, the determining module 401 is further configured to determine whether the latest time control instruction in the target control instruction is a destruction instruction; the device 400 further includes a clearing module, which is further configured to clear the control instruction corresponding to the target component in the instruction buffer if the latest time control instruction is a destruction instruction.

[0109] Figure 5 This is a schematic diagram of the structure of a controller provided in an embodiment of this application.

[0110] For example, such as Figure 5 As shown, the controller 500 includes a storage module 501 and a processing module 502. The storage module 501 stores executable program code 503, and the processing module 502 is used to call and execute the executable program code 503 to perform a method for controlling a view component.

[0111] Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0112] For example, such as Figure 6As shown, the vehicle 600 includes a memory 601 and a processor 602, wherein the memory 601 stores executable program code 603, and the processor 602 is used to call and execute the executable program code 603 to perform a method for controlling a view component.

[0113] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a method for controlling a view component provided in embodiments of this application.

[0114] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0115] When each functional module is divided according to its corresponding function, the device may further include a determination module, a storage module, a replay module, an acquisition module, a filtering module, and a clearing module. It should be noted that all relevant content in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0116] It should be understood that the apparatus provided in this embodiment is used to execute the method for controlling a view component described above, and therefore can achieve the same effect as the implementation method described above.

[0117] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant executable program code.

[0118] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0119] In addition, the apparatus provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a method for controlling a view component provided in the above embodiments.

[0120] This embodiment also provides a computer-readable storage medium storing executable program code. When the executable program code is run on a computer, it causes the computer to perform the aforementioned method steps to implement a method for controlling a view component provided in the above embodiment.

[0121] 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 method for controlling a view component provided in the above embodiment.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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 method for controlling a view component, characterized in that, The method includes: In response to a target control command, the current state of the target component is determined. The target control command is a control command sent by the vehicle application to the target component. The vehicle application runs in a first process, and the target component runs in a second process isolated from the first process. The vehicle application is used to provide a view display window for the target component. If the current state is not a registered state, the target control command is stored in the command buffer. The registered state is used to indicate that the target component is ready to receive control commands. In response to the target component being in a registered state, the target control instruction in the instruction buffer is replayed to the target component, so that the target component executes the operation corresponding to the target control instruction.

2. The method according to claim 1, characterized in that, Determining the current state of the target component includes: Obtain the mapping table in the service component. The service component is used to manage the registration status of the view component. The mapping table includes the identification information and interface instance of the view component. The identification information is a composite key composed of the type identifier of the view component and the instance identifier under the corresponding type. The interface instance is used to trigger the view component to perform the corresponding operation. Determine whether the composite key and interface instance of the target component exist in the mapping table; If the composite key and interface instance of the target component exist in the mapping table, the current state is determined to be the registration state; If the composite key and / or interface instance of the target component does not exist in the mapping table, it is determined that the current state is not the registration state.

3. The method according to claim 1, characterized in that, The target control instruction includes multiple sub-control instructions, and storing the target control instruction into the instruction buffer includes: The multiple sub-control instructions are sorted according to their reception time to obtain sorted multiple sub-control instructions, and the sorted multiple sub-control instructions are stored in the instruction buffer; And, the replaying of the target control instructions in the instruction buffer to the target component includes: Using a single-channel communication method, multiple sorted sub-control instructions in the instruction buffer are replayed one by one to the target component.

4. The method according to claim 3, characterized in that, The step of sorting the plurality of sub-control instructions according to their reception time to obtain a sorted plurality of sub-control instructions includes: The multiple sub-control instructions are sorted according to their reception time to obtain multiple candidate sub-control instructions after sorting. For each candidate instruction in the sorted plurality of candidate sub-control instructions, the candidate instruction is converted into a control instruction in a target format to obtain the sorted plurality of sub-control instructions. The target format includes a type identifier code and an instruction data packet. The type identifier code is used to identify the type of the control instruction, and the instruction data packet is used to carry the instruction parameters of the control instruction.

5. The method according to claim 3, characterized in that, The plurality of sub-control instructions include a plurality of status-type instructions, which are used to control the state changes of the target component. The step of replaying the target control instructions in the instruction buffer to the target component includes: The receiving times of the multiple status-type instructions are compared to determine the latest time, and the status-type instruction corresponding to the latest time in the instruction buffer is determined as the first status-type instruction. Replay the first state class instruction to the target component.

6. The method according to claim 5, characterized in that, The second process is a process that is not attached to the target management component, which is used to manage the lifecycle of the target component, and the plurality of status instructions include a second status instruction for controlling the lifecycle.

7. The method according to claim 3, characterized in that, The plurality of sub-control instructions also include a plurality of event-type instructions, which are used to trigger a change in the state of the target component. The step of replaying the target control instructions in the instruction buffer to the target component includes: According to the receiving time, the multiple event-type instructions in the instruction buffer are sorted to obtain the sorted multiple event-type instructions; From the sorted event-type instructions, a preset number of event-type instructions with the lowest ranking are selected, and the remaining event-type instructions are cleared. Replay the preset number of event-type instructions to the target component.

8. The method according to any one of claims 1-7, characterized in that, After the target component executes the operation corresponding to the target control command, the method further includes: Determine whether the latest control instruction in the target control instructions is a destroy instruction; If the latest control command is a destroy command, the control command corresponding to the target component in the command buffer will be cleared.

9. A controller, characterized in that, The controller includes: The storage module is used to store executable program code; A processing module is configured to call and run the executable program code from the storage module, causing the controller to perform the method as described in any one of claims 1 to 8.

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

Images