Method and related device for multi-engine view migration and lifecycle management based on assembly record

Abstract

This application relates to a method and related apparatus for multi-engine view migration and lifecycle management based on assembly records. The method registers graphics engine-independent logical view descriptions and engine adaptation descriptions for each graphics engine; when opening a view, it obtains the data model through a controlled query interface and creates or reuses the view model; it selects the engine adaptation description to create a unified view wrapper object and a graphics engine native object, generating a view assembly record holding the aforementioned objects, lifecycle states, and destruction action stacks as the runtime entry point; during migration, it freezes the assembly record while retaining the data model and view model, releases the original object, creates a new object, and reconnects; upon exit, it terminates the process in reverse order of the destruction action stack. This application uses view assembly records to uniformly carry out the creation, migration, and destruction of views, achieving cross-graphics engine migration while preserving runtime states, and ensuring symmetrical and orderly resource release across multiple exit paths.

Description

Technical Field

[0001] This application relates to the field of software frameworks, and in particular to a method and apparatus for multi-engine view migration and lifecycle management based on assembly records. Background Technology

[0002] The Model-View-View Model (MVVM) architecture separates the data logic from the presentation logic of the user interface, making it suitable for human-computer interaction (HCI) development. In fields such as automotive instruments, industrial control, and smart terminals, the same interface logic often needs to be presented across different graphics engines and operating platforms. For example, the same interface layout and interactions may need to be built using different graphics rendering engines. Therefore, cross-platform interface frameworks typically introduce adaptations for multiple graphics engines on top of the MVVM architecture, allowing the view model and data model of the interface to be reused across different graphics engines, while the native presentation of the interface is implemented separately by each graphics engine.

[0003] In actual operation, UI views not only need to be created and displayed, but may also switch from one graphics engine to another during runtime due to reasons such as platform switching, rendering performance adjustments, or loading and unloading of business plugins. At the same time, multiple views repeatedly request and release native graphics engine resources in scenarios such as opening, closing, parent-child nesting, creation exceptions, and plugin uninstallation. Therefore, the creation, migration, and destruction of UI views constitute a lifecycle management problem that runs through the entire operation.

[0004] Existing cross-platform UI frameworks lack a runtime fact source for each view instance to uniformly handle view creation, migration, and destruction. Because views are tightly coupled to native objects of specific graphics engines, and there's no mechanism to change the underlying graphics engine at runtime while preserving the data model and view model, switching graphics engines necessitates destroying and rebuilding the entire interface, resulting in lost runtime state and discontinuous switching processes. Furthermore, because cleanup logic is implemented separately for multiple exit paths—normal closure, creation failure rollback, parent view release, and business plugin uninstallation—there's a lack of unified and symmetrical destruction criteria. Consequently, the release of native graphics engine resources is overlooked upon exit, resulting in dangling references and handles, and inconsistent external operations are performed on views that haven't been completely destroyed. Summary of the Invention

[0005] In order to enable the creation, migration and destruction of views in a cross-platform multi-graphics engine interface framework with a unified runtime fact source, achieve cross-graphics engine migration while preserving runtime state, and ensure symmetrical and orderly resource release of multiple exit paths, this application provides a multi-engine view migration and lifecycle management method and related apparatus based on assembly records.

[0006] Firstly, this application provides a multi-engine view migration and lifecycle management method based on assembly records, which adopts the following technical solution:

[0007] A multi-engine view migration and lifecycle management method based on assembly records includes:

[0008] S1. Register the logical view description and engine adaptation description. The logical view description is used to express logical view requirements that are independent of the graphics engine, and the engine adaptation description is used to express how a specific graphics engine implements the logical view.

[0009] S2. In response to a request to open the target logical view, obtain or create the target data model through the controlled query interface based on the logical view description, and create or reuse the target view model;

[0010] S3. Select the target engine adaptation description based on the current graphics engine identifier, logical view description, and engine adaptation description, and create a unified view wrapper object and a graphics engine native object based on the target engine adaptation description;

[0011] S4. Generate a view assembly record. The view assembly record holds the target data model and target view model, unified view wrapper object, graphics engine native object, lifecycle state and destruction action stack, and serves as the runtime entry point for the display, migration, closing and plug-in unloading of the target logical view.

[0012] S5. Establish abstract interactive connections and parent-child assembly relationships between the unified view wrapper object and the target view model. After each resource request, connection or attachment is completed, the corresponding destruction action is added to the destruction action stack and the target logical view is displayed.

[0013] S6. In response to migrating the target logical view from the first graphics engine to the second graphics engine, freeze the view assembly record and retain the target data model and the target view model. Release the original unified view wrapper object and the original graphics engine native object according to the destruction action stack. Then, select a new engine adaptation description based on the logical view description to create a new unified view wrapper object and a new graphics engine native object, and reconnect the target view model and the new unified view wrapper object.

[0014] S7. In response to closing a view, releasing a parent view, creation failure, migration failure, or plugin uninstallation, perform cleanup actions in reverse order of the destruction action stack and update the lifecycle state.

[0015] By adopting the above technical solution, the view assembly record is used as the fact source for each view instance during runtime. The target data model, target view model, unified view wrapper object, graphics engine native object, lifecycle state, and destruction action stack are held uniformly, so that the display, migration, closing, and plug-in unloading of the view are all performed through the same entry point. When migrating across graphics engines, the assembly record is frozen and the target data model and target view model are retained. Only the unified view wrapper object and native object related to the graphics engine are replaced, so as to complete the engine switch without rebuilding the interface logic and maintain the continuity of the interface runtime state. At the same time, when a view requests a resource or establishes a connection during the creation process, the corresponding destruction action is pushed onto the destruction action stack. When exiting, the actions are executed in reverse order. This allows multiple exit paths, such as normal closing, creation failure rollback, parent release, and plug-in unloading, to reuse the same set of symmetrical destruction criteria, reducing the leakage and hanging references of graphics engine native resources.

[0016] Optionally, the view assembly record may also include a unique assembly record identifier, a business subsystem identifier, a logical view type, a graphics engine identifier, a set of connection handles, a parent assembly record identifier, a set of child assembly record identifiers, and error information.

[0017] By adopting the above technical solution, the assembly record further registers the unique identifier, business subsystem identifier, parent and child assembly record identifier, and error information, enabling the view to be located by identifier and the view to be aggregated by business subsystem during operation, and recording anomalies during migration and completion.

[0018] Optionally, the engine adaptation description may also include the supported logical view types, native object construction entry points, unified view wrapping entry points, capability tables, and lifecycle callbacks. Before selecting a target engine adaptation description, the capability table is used to verify whether the engine adaptation description covers the abstract interaction entry points required by the logical view description, and engine adaptation descriptions that do not cover the necessary entry points will not be selected.

[0019] By adopting the above technical solution, before selecting an engine adaptation description, it is verified according to the capability table whether it covers the abstract interaction entry required by the logical view. Engine adaptation descriptions that do not meet the requirements are not selected, thus avoiding the creation of views that cannot be properly connected on graphics engines that lack necessary entry points.

[0020] Optionally, creating or reusing the target view model includes parallel S2a and S2b: S2a. In response to multiple views sharing the same view model, a view model lease is generated for each view assembly record, and the shared view model is released after the last associated view assembly record is released; S2b. In response to a one-to-one correspondence between a view and a view model, the view model is released when the corresponding view assembly record is closed.

[0021] By adopting the above technical solution, lease counting is used for view models shared by multiple views. The shared view model is only released after the last associated view is released, so that the life cycle of the shared view model is consistent with its actual reference situation, avoiding premature release or duplicate release.

[0022] Optionally, lifecycle states include one or more of the following: declared, view model ready, native view ready, connected, displaying, frozen, migrating, closing, released, and failed; based on the lifecycle state, inconsistent external operations are rejected on view assembly records that are frozen, closed, or released.

[0023] By adopting the above technical solution, inconsistent external operations on views that are frozen, closed, or released are rejected based on their lifecycle status, ensuring that views during migration and destruction are not accessed by external parties in a contradictory manner.

[0024] Optionally, in response to the need for delayed deletion of the graphics engine native object, the destruction action of the graphics engine native object returns a delayed deletion token. The view assembly record remains closed and refuses external operations through the handle of the original graphics engine native object until the delayed deletion token is completed, and then updates its lifecycle state to released.

[0025] By adopting the above technical solution, a delayed deletion token is returned for graphics engine native objects that need to be delayed in deletion. The token is kept closed and access via the original handle is refused until the token is completed, so that the native objects are not misused during the delayed release period.

[0026] Optionally, displaying the target logical view includes: establishing a self-persistent reference to the top-level view in the display to remain alive during the display; saving weak references or invalidable handles in the view factory registry, parent control child list, or global index; and performing cleanup actions in the reverse order of the destruction action stack, including first blocking external entry points and connection handles, then performing the destruction actions of the graphics engine native objects, and finally releasing the self-persistent references and cleaning up the weak references.

[0027] By adopting the above technical solution, a self-retaining reference is established for the top-level view in the display to avoid premature recycling, and weak references in the registry table and parent list are used for indexing; during the final stage, the entry point and connection are blocked first, then the native object is destroyed, and finally the self-retaining reference is released and the weak references are cleaned up, so that the destruction process is carried out in an orderly manner according to the dependency relationship.

[0028] Optionally, the logical view description includes business subsystem identifier, logical view type, view model type, data model query rules, parent slot rules, abstract interaction entry set, reuse strategy and lifecycle strategy. The data model query rules include one or more of the following: query by name, query by business object identifier, query by parent object path, or create by context parameters.

[0029] By adopting the above technical solutions, the logical view description carries the view model type, data model query rules, parent slot rules and reuse strategies, providing a complete declaration basis for controlled creation.

[0030] Optionally, reuse strategies include one or more of the following: singleton view, one-to-one view per business object, temporary view, or view that can be opened multiple times.

[0031] By adopting the above technical solutions, the reuse strategy distinguishes between singletons, one-to-one with business objects, temporary and multiple instances, so that the same logical view can be reused or multiple instances can be created as needed in different business contexts.

[0032] Optionally, the abstract interactive connection includes an abstract attribute entry, an operation entry, and an event entry. The abstract attribute entry adopts two-way attribute binding, and the event entry adopts one-way signal transmission.

[0033] By adopting the above technical solution, the abstract interactive connection carries data presentation through two-way attribute binding and carries events through one-way signal transmission, making the interaction between the view model and the graphics engine's native objects independent of the specific graphics engine.

[0034] Optionally, this method also provides a view context and a data model context, enabling different business subsystems to initiate operations such as opening and closing the interface, querying the model, or broadcasting the status through the typed context entry point, without directly saving the bare pointer of the manager of other business subsystems.

[0035] By adopting the above technical solution, different business subsystems are isolated by view context and data model context, so that each business subsystem interacts through a typed entry point without holding each other's bare manager pointers, thereby reducing the coupling between business subsystems.

[0036] Optionally, in a parent-child assembly relationship, the parent view assembly record stores the child assembly record identifier and a weak reference or a detachable handle. The native parent-child relationship of the graphics engine is established through the hook lifecycle callback in the target engine adaptation description. When closing the parent view or uninstalling the plugin, the child view assembly record is closed first and then the parent view assembly record is closed.

[0037] By adopting the above technical solution, the parent assembly record saves the child identifier with a weak reference. When closing the parent or unloading the plug-in, the child is closed first and then the parent is closed, so that the nested views are released in an orderly manner according to the hierarchy.

[0038] Optionally, in response to plugin uninstallation, all view assembly records belonging to the plugin are searched based on the business subsystem identifier, and the shutdown process is executed from child to parent according to the parent-child assembly relationship. The logical view descriptions, related engine adaptation descriptions, and context entries registered by the plugin are also cleaned up.

[0039] By adopting the above technical solution, when a plugin is uninstalled, all its views are collected according to the business subsystem identifier, and the plugin is closed and its registered description and context entry are cleaned up from the child level to the parent level, so that the plugin-related resources are completely recycled.

[0040] Optionally, the destruction actions in the destruction action stack include one or more of the following: disconnecting the view from the view model, detaching the context, detaching from the parent native container, hiding the graphics engine native object, executing the native object destruction callback, releasing the view model lease, releasing self-retaining references, and cleaning up weak references.

[0041] By adopting the above technical solution, the actions in the destruction action stack cover disconnection, context removal, detachment from parent container, destruction of native objects, release of leases and self-retaining references, etc., so that all kinds of resources occupied by the view are included in symmetrical release.

[0042] Optionally, the migration can be performed either as a runtime hot migration or a cold migration that hides the original view and creates a new view, while preserving the target data model and the target view model.

[0043] By adopting the above technical solutions, migration can be performed as either a hot migration during runtime or a cold migration that first hides the original view and then creates a new view, adapting to different switching scenarios.

[0044] Optionally, in response to the failure of a certain finishing action during the finishing process, the failure information is written to the error information of the view assembly record, and subsequent finishing actions that do not depend on that finishing action are continued to be executed.

[0045] By adopting the above technical solution, when a certain action fails during the finishing process, the failure information is written into the assembly record and subsequent finishing actions that do not depend on that action are continued to be executed, so that individual abnormalities do not block the overall release.

[0046] Secondly, this application provides a multi-engine view migration and lifecycle management system based on assembly records, which adopts the following technical solution:

[0047] A multi-engine view migration and lifecycle management system based on assembly records, comprising:

[0048] The logical view description registration module is configured to register logical view descriptions that express graphics engine-independent logical view requirements.

[0049] The engine adaptation description registration module is configured to register engine adaptation descriptions that express specific graphics engine implementation methods and to perform adaptation capability verification based on the capability table.

[0050] The view assembly module is configured to select the target engine adaptation description based on the current graphics engine identifier, logical view description and engine adaptation description, obtain or create the target data model through a controlled query interface, create or reuse the target view model, and create a unified view wrapper object and a graphics engine native object.

[0051] The assembly record management module is configured to generate, update, query, and freeze view assembly records. The view assembly record holds the target data model and target view model, unified view wrapper object, graphics engine native object, lifecycle state, and destruction action stack, and serves as the runtime entry point for display, migration, closing, and plug-in uninstallation.

[0052] The lifecycle cleanup module is configured to maintain connection handles, parent-child assembly relationships, self-holding references, and a destruction action stack, and execute cleanup actions in reverse order of the destruction action stack; and

[0053] The migration control module is configured to freeze the view assembly record and retain the target data model and target view model when switching graphics engines, release the original unified view wrapper object and the original graphics engine native object, create a new unified view wrapper object and a new graphics engine native object, and reconnect the target view model and the new unified view wrapper object.

[0054] By adopting the above technical solution, each module works collaboratively around the view assembly record. The view assembly module completes controlled creation, the assembly record management module holds runtime objects uniformly with the assembly record, the migration control module replaces graphics engine-related objects while retaining the data model and view model, and the lifecycle closure module releases resources symmetrically according to the destruction action stack. This enables the system to achieve controlled creation, state-preserving migration, and orderly destruction of views across multiple graphics engines.

[0055] Thirdly, the computer device provided in this application adopts the following technical solution:

[0056] A computer device comprising:

[0057] One or more processors;

[0058] Memory;

[0059] One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to:

[0060] Perform the multi-engine view migration and lifecycle management method based on assembly records described above.

[0061] Fourthly, the computer-readable storage medium provided in this application adopts the following technical solution:

[0062] A computer-readable storage medium storing at least one instruction, at least one program, a code set, or an instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the following:

[0063] The above describes a multi-engine view migration and lifecycle management method based on assembly records.

[0064] In summary, this application includes at least one of the following beneficial technical effects:

[0065] 1. By using the view assembly record as the runtime fact source for each view instance, the creation, migration, and destruction of views are uniformly carried out. This allows the display, migration, closing, and plug-in uninstallation of views to be performed through the same entry point. Under the premise of preserving the target data model and the target view model, cross-graphics engine migration can be completed by only replacing graphics engine-related objects, thus maintaining the continuity of the interface runtime state.

[0066] 2. By registering destruction actions item by item during the creation process through the destruction action stack, and executing them symmetrically in reverse order upon exit, multiple exit paths such as normal closure, creation failure rollback, parent release, and plugin uninstallation reuse the same set of destruction criteria. Combined with lifecycle state verification, view model lease, and delayed deletion token, this reduces the leakage of native graphics engine resources, hanging references, and inconsistent operations on views that have not been completely destroyed.

[0067] 3. By separating logical view descriptions from engine adaptation descriptions and verifying capability tables, the same interface logic can be adapted to multiple graphics engines; by isolating view contexts from data model contexts and unloading plugins by business subsystem, multiple business subsystems can independently open, migrate, and release views within the same framework. Attached Figure Description

[0068] Figure 1 This is a schematic diagram illustrating the relationship between the logical view description, the engine adaptation description, and the view assembly record in one embodiment of this application.

[0069] Figure 2 This is a schematic diagram of a method for creating a view based on a logical view description and an engine adaptation description in one embodiment of this application.

[0070] Figure 3 This is a schematic diagram of a state-preserving cross-engine migration process in one embodiment of this application.

[0071] Figure 4 This is a schematic diagram of the self-holding reference, weak registration, and destruction action stack in the view assembly record in one embodiment of this application.

[0072] Figure 5 This is a schematic diagram illustrating the process of cleaning up the assembly record from child to parent level by view during plugin uninstallation in one embodiment of this application. Detailed Implementation

[0073] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the scope of the application.

[0074] This application discloses a method for multi-engine view migration and lifecycle management based on assembly records. (Refer to...) Figure 1 This method uses the view assembly record corresponding to each actually created interface instance as the runtime fact source. The same record carries the interface instance's data model, view model, unified view wrapper object, graphics engine native object, lifecycle state, and destruction action stack. This ensures that the display, cross-engine migration, closing, and plugin uninstallation of the interface are all controlled through this record. First, it registers the logical view description expressing the interface's logical requirements and the engine adaptation description expressing the specific engine implementation. Then, in response to an open request, it controllably obtains the data model and creates the view model; based on the current graphics engine, it selects the adaptation and creates the unified view wrapper object and the graphics engine native object; it generates the view assembly record and establishes connections and displays it. Finally, when switching graphics engines, it freezes the record, retains the data model and view model, and only replaces the view-side objects; it performs a reverse-order symmetrical termination on each exit path according to the destruction action stack. Thus, it can maintain the continuity of business data and interaction logic before and after switching graphics engines and ensure that the interface is consistently released under various exit paths. The following sections provide a detailed explanation of the terminology, main method flow, specific implementation of state-preserving migration and reverse-order termination, and device and equipment mapping.

[0075] The following section will first explain some of the technical terms involved in the embodiments of this application.

[0076] The logical view description is a description registered by the business subsystem with the framework to express the interface form required by the business side without expressing the specific graphics engine implementation. It includes the business subsystem identifier (moduleId), logical view type (logicalViewType), view model type (viewModelType), data model query rule (modelResolveRule), parent slot rule (parentSlotRule), abstract interaction entry set (abstractEndpointSet), reuse policy (reusePolicy), and lifecycle policy (lifecyclePolicy). The business subsystem declares its interface requirements based on this without registering any native control types of any specific graphics engine.

[0077] An engine adaptation description is a description registered with the framework by the graphics engine adaptation module, which expresses the specific implementation method of a certain graphics engine for a certain logical view type. It includes the graphics engine identifier (engineId), the supported logical view types, the native object construction entry point (nativeConstructor), the unified view wrapper entry point (wrapperConstructor), the capability table (capabilityTable), lifecycle callbacks (lifecycleCallbacks), the adaptation description version (adapterVersion), and the priority (priority). The same logical view type can be supported by multiple engine adaptation descriptions of different graphics engines or different versions.

[0078] A view assembly record is a record that represents a specific instance of a UI that has been created. It holds the instance's data model (Model), view model (ViewModel), unified view wrapper object, graphics engine native object, lifecycle state, and destruction action stack. It serves as the runtime fact source for the subsequent display, hiding, migration, closing, and plugin uninstallation of the UI instance. When an external system needs to operate on a UI, it requests the framework to operate through the unique identifier (assemblyId) of the assembly record, the logical view type, or the context entry point, instead of directly destroying the graphics engine native object.

[0079] The unified view wrapper object is an object that wraps the native graphics engine object into the framework's unified view interface. It supports the abstract interaction of the view model above and holds and drives the specific native graphics engine object below, so that the framework and the view model do not need to be aware of the differences between the specific graphics engine.

[0080] Native graphics engine objects are native interface objects created by a specific graphics engine based on the engine adaptation description. These include windows, controls, scene nodes, blueprint controls, or prefabs. Their creation and destruction are controlled by the unified view wrapper object and the engine adaptation description.

[0081] The destruction action stack is a stack structure registered in the view assembly record, which adds destruction actions in the order of resource request and connection during the assembly process. When closing, creation failure, migration failure and plug-in uninstallation occur, the cleanup is performed in the reverse order, so that failure in the middle, normal closing and plug-in uninstallation can reuse the same cleanup mechanism.

[0082] In this application, the data model stores the pure data state of the interface, while the view model carries the interface interaction logic; together, they constitute the business-side object. The unified view wrapper object and the graphics engine's native object constitute the view-side object. This application achieves cross-graphics engine state preservation by retaining the business-side object during migration and replacing only the view-side object.

[0083] The following describes the application environment of this method. This method can be applied to scenarios where the same business interface needs to be presented or switched between multiple graphics engines. For example, in an in-vehicle human-machine interface toolchain, the same parameter panel needs to be presented in the desktop debugging tool with the first graphics engine, in the 3D simulation environment with the second graphics engine, and in the embedded delivery version with the third graphics engine.

[0084] To facilitate understanding of the role of this method compared to implementations without a unified runtime fact source, we will use a single parameter panel as an example. In the implementation without a view assembly record, after a parameter panel is created by the first graphics engine, its data model, view model, and references to native controls are scattered across multiple locations, including business code, view factory, and parent container. When switching the panel to the second graphics engine, due to the lack of a unified record to carry the creation artifacts, the original interface is usually destroyed and the entire panel is recreated according to the second graphics engine, causing the parameter state and interaction logic to be reconstructed along with the original interface. When the panel is closed, due to the scattered references and inconsistent release order, situations can easily arise where native objects have been destroyed but the upper layer still holds invalid handles, or a reference is missed, leading to resource leaks. This method, by establishing a unified view assembly record for the panel to carry all its creation artifacts, allows graphics engine switching to replace only the view-side objects while retaining the business-side objects, and allows interface release to be completed consistently in reverse order along the destruction action stack, thereby avoiding the aforementioned state loss and inconsistency in release.

[0085] The overall process of this method is explained in detail below. (Refer to...) Figure 2 This method includes steps S1 to S7.

[0086] S1. Register logical view descriptions and engine adaptation descriptions. Logical view descriptions express logical view requirements independent of the graphics engine, while engine adaptation descriptions express how a specific graphics engine implements the logical view. In the implementation, the business subsystem does not directly register any native controls of a specific graphics engine. Instead, it registers logical view descriptions with the framework to declare its required logical view type, required view model type, data model query rules, parent slot rules, abstract interaction entry point, and lifecycle strategy. One or more engine adaptation modules corresponding to each graphics engine register engine adaptation descriptions with the framework during loading to declare the engine's native object construction entry point, unified view wrapping entry point, capability table, and lifecycle callback for each logical view type. Logical view descriptions and engine adaptation descriptions each bear different responsibilities: the former expresses business interface requirements independent of the graphics engine, while the latter expresses the graphics engine implementation independent of specific business logic. They are associated through the same logical view type. Thus, business-side interface requirements and graphics engine-side implementations are decoupled, and the same logical view description can be implemented by multiple engine adaptation descriptions, thereby supporting the reuse of the same business interface across multiple graphics engines. Engine adaptation descriptions can be dynamically registered by the engine adaptation module during loading, or they can be pre-defined in a static adaptation table during framework construction. Both are included in the engine adaptation description table for subsequent selection.

[0087] The logical view description includes a business subsystem identifier, logical view type, view model type, data model query rules, parent slot rules, abstract interaction entry set, reuse strategy, and lifecycle strategy. The data model query rules include one or more of the following: query by name, query by business object identifier, query by parent object path, or creation by context parameters. Specifically, the business subsystem identifier identifies the business subsystem or plugin to which the logical view description belongs; the logical view type is the type identifier of the interface; the view model type indicates the type of view model to be created or reused; the parent slot rules specify the view area to be inserted into the interface; and the abstract interaction entry set specifies the attribute entry, operation entry, or event entry that needs to be aligned between the interface and the view model. The logical view description can be generated from one or more of the following: macros, metaclass registry, JSON configuration, XML configuration, script configuration, or visual interface description file. Regardless of the method used, the registration result is entered into the logical view description table. The framework subsequently creates the interface based on the logical view description, thus preventing the business side from bypassing the description table and directly creating native controls.

[0088] In some embodiments, the reuse strategy includes one or more of the following: singleton view, one-to-one view by business object, temporary view, or multiple-openable view. A singleton view maintains only one instance throughout the entire business subsystem, a one-to-one view by business object maintains a corresponding instance for each business object, a temporary view is used for temporary pop-ups and is released after being closed, and a multiple-openable view allows multiple instances of the same logical view type to exist simultaneously.

[0089] In other embodiments, the engine adaptation description also includes supported logical view types, native object construction entry points, unified view wrapper entry points, capability tables, and lifecycle callbacks. Before selecting a target engine adaptation description, the capability table is used to verify whether the engine adaptation description covers the abstract interaction entry points required by the logical view description, and engine adaptation descriptions that do not cover the necessary entry points are not selected. The capability table describes the abstract attribute entry points, operation entry points, event entry points, parent-child connection methods, display / hide methods, and destruction methods supported by the graphics engine implementation. In specific implementations, when multiple engine adaptation descriptions exist for the same logical view type, the framework compares the capability table of each engine adaptation description with the set of abstract interaction entry points declared by the logical view description before selection: if the capability table of an engine adaptation description covers all the abstract interaction entry points required by the logical view description, then the engine adaptation description can be selected; if the necessary entry points are missing, the engine adaptation description is marked as unavailable or downgraded to available, and the framework does not select engine adaptation descriptions marked as unavailable when creating the interface. The capability table can be expressed as one or more of the following: Boolean capability table, version range, interface set, enumeration set, or function pointer set.

[0090] S2. In response to a request to open a target logical view, the framework retrieves or creates the target data model through a controlled query interface based on the logical view description, and then creates or reuses the target view model. In the specific implementation, when a logical view needs to be opened, the caller submits the logical view type and necessary context parameters. The framework retrieves the target data model through the controlled query interface of the Data Model Manager based on the data model query rules in the logical view description. If the query rules allow creation and the target data model does not exist, the Data Model Manager creates the data model in a controlled manner according to the type identifier and construction parameters and registers it in its object table. The framework then creates or reuses the target view model based on the view model type. Both the retrieval and creation of the data model are performed through the controlled query interface, rather than being directly constructed by the business side, thus ensuring that the lifecycle and consistency of the data model are uniformly managed by the framework.

[0091] Creating or reusing a target view model includes parallel steps S2a and S2b.

[0092] S2a. In response to multiple views sharing the same view model, a view model lease is generated for each view assembly record, and the shared view model is released after the last associated view assembly record is released.

[0093] S2b. Responding to the one-to-one correspondence between views and view models, the view model is released when the corresponding view assembly record is closed.

[0094] In its implementation, the view model lease is used to record the holding relationship between the view assembly record and the view model. When the reuse strategy indicates that multiple views can share the same view model, the framework requests a lease from the view model lease module and writes it to the corresponding view assembly record. This keeps the shared view model alive as long as it is held by any view assembly record, until the last associated lease is released. When the reuse strategy indicates that the view model and the view assembly record can share the same view model, the framework requests a lease from the view model lease module and writes it to the corresponding view assembly record. This keeps the shared view model alive while it is still held by any view assembly record, until the last associated lease is released. Figure 1 When a one-to-one correspondence is established, the view model is released when the corresponding view assembly record is closed. View model leases can be implemented using one or more of the following methods: reference counting, scope tokens, shared pointer wrapping, weak pointer promotion, or manager internal counting.

[0095] S3. Select the target engine adaptation description based on the current graphics engine identifier, logical view description, and engine adaptation description, and create a unified view wrapper object and a graphics engine native object based on the target engine adaptation description. The unified view wrapper object and the graphics engine native object constitute a binary structure on the view side. The former provides a unified interface to the framework and view model, while the latter is the native interface object of the specific graphics engine. This binary separation allows the graphics engine native object to be replaced at runtime while retaining the interface provided by the unified view wrapper object, thus laying the foundation for subsequent cross-graphics engine migration. Specifically, S3 includes sub-steps S31 to S33:

[0096] S31. Based on the current operating environment's graphics engine identifier, logical view type, adaptation description version, priority, and capability table, select the target engine adaptation description from the registered engine adaptation descriptions.

[0097] S32. Call the unified view wrapper entry described in the target engine adaptation to create a unified view wrapper object.

[0098] S33. The native object of the graphics engine is created by calling the native object construction entry point from the unified view wrapper object or the target engine adaptation description.

[0099] In practical implementation, the construction entry point of the graphics engine's native object can create windows, controls, scene nodes, blueprint controls, prefabs, or other graphics engine objects. For example, the logical view type of the same parameter panel can be created as a control for the first graphics engine through its construction entry point, as an interface control for the second graphics engine, and as a scene node for the third graphics engine. The unified view wrapper object of the three provides a consistent interface to the framework, while their graphics engine native objects correspond to different native forms of each engine. Thus, the same logical view description can be used to create interface objects with different forms but consistent interfaces under different graphics engines through different engine adaptation descriptions.

[0100] S4. Generate a view assembly record. This record holds the target data model and target view model, the unified view wrapper object, the graphics engine native object, lifecycle states, and the destruction action stack. It serves as the runtime entry point for displaying, migrating, closing, and unloading plugins in the target logical view. In the implementation, once the unified view wrapper object, graphics engine native object, target view model, and parent-child relationships for a single interface creation are created, the framework solidifies all artifacts of that creation into a single view assembly record. This ensures that all subsequent operations on that interface instance use this record as the runtime fact source. Because displaying, hiding, migrating, closing, and unloading plugins are all performed through this record, rather than the caller directly holding and destroying the graphics engine native object, various operations on the same interface are converged to a single entry point: external requests for operations are made through this record, and the framework completes the corresponding actions and updates the record based on the objects and states held by this record. This avoids inconsistencies in reference hanging and release caused by multiple references to the creation artifacts of the same interface being scattered across multiple places such as business code, view factories, and parent containers. Compared to implementations that scatter references to various created artifacts without a unified record, this step consolidates all artifacts created in a single interface into a single record, providing a single and consistent entry point for displaying, migrating, and releasing the interface. The view assembly record can be stored as an item in an independent assembly record management table, or it can be stored as an embedded field of the interface instance object along with the instance; neither method changes its role as a runtime fact source.

[0101] The view assembly record also includes a unique assembly record identifier, a business subsystem identifier, a logical view type, a graphics engine identifier, a set of connection handles, a parent assembly record identifier, a set of child assembly record identifiers, and error information. Specifically, the assembly record unique identifier (assemblyId) uniquely identifies the record; the business subsystem identifier, logical view type, and graphics engine identifier identify which business subsystem the record originates from, which logical view it corresponds to, and which graphics engine is currently being used; the set of connection handles (connectionHandles) records the handles of established connections between the framework and the view, view model, context, or engine adapter object; the parent assembly record identifier and the set of child assembly record identifiers express the parent-child assembly relationship between view assembly records; and the error information (errorInfo) records errors that occur when creation, migration, or destruction fails. In addition, the view assembly record can also record the data model reference (modelRef), view model lease (viewModelLease), unified view wrapper object reference (viewWrapperRef), and graphics engine native object handle (nativeHandle) returned by the data model manager, so as to respectively take over the data model, view model, unified view wrapper object, and graphics engine native object it holds.

[0102] Lifecycle states include one or more of the following: declared, view model ready, native view ready, connected, displaying, frozen, migrating, closing, released, and failed. The framework rejects inconsistent external operations on view assembly records that are frozen, closed, or released based on their lifecycle states. In practice, the lifecycle state of a view assembly record progresses through creation, display, migration, and cleanup: the interface goes through declaration, data model parsing, view model ready, native view ready, and connection establishment before reaching the displaying stage; during migration, it goes through the frozen and migration stages before returning to the displaying stage; during cleanup, it goes through the closed stage before being released; and if creation or migration fails, it is set to failed. Because the view assembly record carries the current lifecycle state, the framework can use this state to determine the consistency of external operations. For example, it rejects new display switching and closing requests for records that are frozen or migrating, and rejects operations performed through the original handle for records that are closed or released, thereby preventing inconsistencies caused by concurrent external operations during migration or release.

[0103] S5. Establish abstract interactive connections and parent-child assembly relationships between the unified view wrapper object and the target view model. Each completed resource request, connection, or attachment adds a corresponding destruction action to the destruction action stack, and the target logical view is displayed. In the specific implementation, the framework aligns the unified view wrapper object with the abstract interactive entry points of the target view model based on the set of abstract interactive entry points in the logical view description, enabling the interface to present the state of the view model and pass user operations to the view model. The framework finds the parent assembly record or parent native container according to the parent slot rules, and attaches the graphics engine native object through the parent-child attachment lifecycle callback described in the target engine adaptation, thereby establishing the parent-child assembly relationship. During the assembly process described above, for each resource request, connection, or attachment that may require release—such as creating a native graphics engine object, registering event entry points, attaching parent-child relationships, establishing context connections, or requesting a shared view model lease—the framework adds a corresponding destruction action to the teardown stack recorded in the view assembly. Since destruction actions are pushed onto the stack sequentially according to the order in which resource requests and connections occur, subsequent actions such as closing, creation failures, migration failures, or plugin uninstallation are executed in reverse order. This ensures that the cleanup process is naturally symmetrical to the assembly process, neither omitting requested resources nor repeatedly releasing unrequested resources. Once the unified view wrapper object, the native graphics engine object, the target view model, and parent-child relationships are all created, the framework displays the target logical view. For example, during a UI creation process, the framework sequentially requests the native graphics engine object, registers event entry points, attaches parent-child relationships, and establishes connections, with corresponding destruction actions pushed onto the stack in sequence. If the connection establishment step fails, the framework unattaches the attached parent-child relationships, unregisters the registered event entry points, and destroys the created native graphics engine object in the reverse order of the destruction actions registered on the stack, ensuring that the incomplete creation is consistently rolled back. Destruction actions can be added individually and immediately upon completion of each resource request or connection, or they can be grouped and registered according to different stages of assembly and then added as a whole; both methods maintain the correspondence between destruction actions and resource requests.

[0104] Abstract interaction connections include abstract attribute entry points, operation entry points, and event entry points. Abstract attribute entry points employ two-way attribute binding, while event entry points use one-way signal transmission. In the specific implementation, abstract attribute entry points are used to bidirectionally synchronize UI attributes between the unified view wrapper object and the view model, ensuring that changes to view model attributes are reflected in the UI, and attribute edits on the UI are written back to the view model. Operation entry points are used to convert user actions on the UI into operation calls to the view model. Event entry points are used to unidirectionally notify the UI of events generated by the view model via signals. Because the UI and view model are aligned only through abstract interaction entry points, without relying on the control interfaces of a specific graphics engine, the same view model can establish consistent abstract interaction connections with unified view wrapper objects under different graphics engines.

[0105] In a parent-child assembly relationship, the parent view assembly record stores the child assembly record identifier and a weak reference or a handle that may become invalid. The native parent-child relationship of the graphics engine is established through the hook lifecycle callback in the target engine adaptation description. When closing the parent view or unloading the plugin, the child view assembly record is closed first, followed by the parent view assembly record. In the specific implementation, the parent view assembly record references its child through the child assembly record identifier and a weak reference, rather than holding the child with a strong reference, so that the survival of the child is determined by its own lifecycle. The framework hooks the child graphics engine native object to the parent native container through the hook callback in the target engine adaptation description, thereby establishing a native parent-child relationship at the graphics engine level. When closing the parent view or unloading the plugin, the framework closes the parent-child assembly relationship sequentially from child to parent, that is, it completes the closing of each child view assembly record first, and then completes the closing of the parent view assembly record, to avoid the parent being released before the child, causing the child to access the released parent during the closing process.

[0106] In some embodiments, displaying a target logical view includes: establishing a self-holding reference to the top-level view in the display to ensure its survival during display, and storing weak references or invalidable handles in the view factory registry, parent control sublist, or global index. In a specific implementation, the framework establishes a self-holding reference to the top-level view in the view assembly record to ensure that the top-level view is not released during its visibility period; simultaneously, the view factory registry, parent control sublist, and global index only store weak references, object identifiers, or invalidable handles for the view, and do not hold them with strong references. Because the survival of the top-level view is determined solely by the self-holding reference in the view assembly record, and all other locations use weak references, the top-level view will not be prematurely released simply because the view factory or parent only holds a weak reference; and releasing the self-holding reference at the end allows the view to be released, and the weak references stored elsewhere become invalid without becoming dangling references. The self-holding reference can be held by the view assembly record, a unified view wrapper object, or a dedicated lifecycle manager, and the weak registry can use one or more of weak pointers, object identifiers, invalidable handles, or weak object references provided by the graphics engine.

[0107] The destruction actions in the destruction action stack include one or more of the following: disconnecting the view from the view model, releasing the context connection, detaching from the parent native container, hiding the graphics engine native object, executing the native object destruction callback, releasing the view model lease, releasing self-holding references, and clearing weak references. In the specific implementation, each of these destruction actions corresponds inversely to the resource allocation or connection establishment during the assembly process: disconnecting the view from the view model corresponds to establishing an abstract interaction connection; releasing the context connection corresponds to establishing a context connection; detaching from the parent native container corresponds to establishing a parent-child relationship; executing the native object destruction callback corresponds to creating the graphics engine native object; releasing the view model lease corresponds to applying for a shared view model lease; and releasing self-holding references and clearing weak references correspond to the self-holding and weak registrations established during display. Since the destruction actions are appended when resource allocation or connection establishment occurs according to the above correspondence, they can be executed in reverse order at the end to cancel the allocated resources and established connections one by one.

[0108] S6. In response to migrating the target logical view from the first graphics engine to the second graphics engine, freeze the view assembly record and retain the target data model and target view model. Release the original unified view wrapper object and the original graphics engine native object according to the destruction action stack. Then, based on the logical view description, select a new engine adaptation description to create a new unified view wrapper object and a new graphics engine native object, and reconnect the target view model and the new unified view wrapper object. (See reference...) Figure 3 This step is initiated when a change in the graphics engine implementation is required, such as switching graphics engines, replacing view skins, upgrading layout implementations, or switching from a 2D control interface to a 3D engine interface. Since the data model and view model are preserved before and after the migration, business data and main interaction logic remain continuous. Changes are concentrated only in the unified view wrapper object, the graphics engine's native object, and the engine adaptation description. Specifically, S6 includes sub-steps S61 to S64:

[0109] S61. Update the lifecycle status of the target view assembly record from "Display" to "Frozen" or "Migration", temporarily reject new display switching and closing requests for the record, and read the data model references, view model leases, logical view descriptions and context parameters retained in the record.

[0110] S62. According to the destruction actions related to the original unified view wrapper object, the original graphics engine native object and the original engine adaptation in the destruction action stack, disconnect, detach from the parent, hide the original control and destroy the original graphics engine native object, but do not release the data model and view model lease that need to be retained.

[0111] S63. Based on the new graphics engine identifier or the new adaptation description version, reselect the engine adaptation description, create a new unified view wrapper object and a new graphics engine native object, and write them to the same view assembly record.

[0112] S64. Based on the logical view description, re-establish the abstract interaction connection and parent-child assembly relationship between the new unified view wrapper object and the target view model, display the new target logical view, and update the lifecycle status of the view assembly record to "displaying".

[0113] In practice, since the migration is performed on the same view assembly record, the retained data model and view model do not need to be reconstructed, and business data, parameter states, and interaction logic remain continuous before and after the migration. The migration described in this step can be used to switch between different graphics engines, or to switch to a new adaptation description version under the same graphics engine to achieve view skin replacement or layout upgrade.

[0114] In some embodiments, the migration is performed using either runtime hot migration or cold migration (hiding the original view and then creating a new view) while preserving the target data model and target view model. Runtime hot migration directly replaces the original view with the new view during the migration process; cold migration hides the original view first, and then displays it after the new view is created and connected. Both methods preserve the data model and view model, and only replace the unified view wrapper object and the graphics engine's native object, therefore both can be considered optional implementations of this application.

[0115] S7. In response to view closure, parent view release, creation failure, migration failure, or plugin uninstallation, perform cleanup actions in reverse order of the destruction action stack and update the lifecycle state. (See also...) Figure 4In its implementation, the five exit scenarios—view closure, parent view release, creation failure, migration failure, and plugin uninstallation—although triggered by different reasons, all rely on the same view assembly record's destruction action stack, executing the cleanup actions in reverse order. Since destruction actions are pushed onto the stack during assembly in the order of resource request and connection attachment, executing them in reverse order allows for the revocation of established connections and requested resources, enabling the five exit scenarios to reuse the same cleanup mechanism without requiring separate release logic for each scenario. After cleanup, the framework updates the lifecycle state of the view assembly record to "released." For example, in a normal closure scenario, the framework completes the cleanup in reverse order of the destruction action stack and sets the state to "released"; in a creation failure scenario, the framework reverses the completed assembly in reverse order of the registered destruction actions in the destruction action stack and sets the state to "failed"; in a plugin uninstallation scenario, the framework executes the above cleanup process sequentially on all view assembly records belonging to that plugin. The order of cleanup actions can be determined either by strictly reversing the order of the destruction action stack, or by reversing the topological order of resource dependencies if the dependencies between resources are recorded. Both methods ensure that the dependent resource is released after the resources that depend on it.

[0116] When executing cleanup actions in reverse order of the destruction action stack, external entry points and connection handles are blocked first, then the destruction of the graphics engine's native objects is performed, and finally, self-retaining references are released and weak references are cleaned up. In the specific implementation, cleanup first blocks the entry points exposed by the view assembly record and disconnects established connection handles, preventing external operations from being initiated through this interface; then, the native object destruction callback in the engine adaptation description is called to destroy the graphics engine's native objects; finally, the self-retaining references to the top-level view in the view assembly record are released, and weak references stored in the view factory registry, parent control child list, and global index are cleaned up. The order of blocking external entry points ensures that external access to objects in a half-released state is not possible during cleanup, and the order of releasing self-retaining references and cleaning up weak references ensures that objects are finally released only after they are no longer referenced by any entry point. Even if a step in the cleanup process fails, the framework can still continue to execute subsequent cleanup steps that do not depend on the failed step because subsequent steps are organized according to dependencies. Blocking external entry points can be achieved by setting an invalidation flag for the corresponding entry point in the view assembly record, or by removing the corresponding connection handle from the connection handle set.

[0117] In some embodiments, in response to the need for delayed deletion of the graphics engine's native object, the destruction action of the graphics engine's native object returns a delayed deletion token. The view assembly record remains closed and refuses external operations via the handle of the original graphics engine's native object until the delayed deletion token is completed, at which point its lifecycle state is updated to released. In a specific implementation, for graphics engines that do not support immediate release of native objects, the native object destruction callback does not immediately release the native object but returns a delayed deletion token. Before this token is completed, the view assembly record remains closed and refuses external operations initiated via the handle of the original graphics engine's native object, thereby preventing external access while the native object has not been truly released. After the delayed deletion is completed and the token is set, the framework updates the lifecycle state of the record to released.

[0118] In some embodiments, in response to the failure of a certain cleanup action during the cleanup process, the failure information is written to the error information of the view assembly record, and subsequent cleanup actions that do not depend on the failed cleanup action continue to be executed. In a specific implementation, when a cleanup action fails, the framework writes the relevant information about the failure to the error information field of the view assembly record, and continues to execute other cleanup actions that do not depend on the failed action, so as to ensure that relevant resources can be released when the plugin is uninstalled or the interface is closed, and that the entire cleanup process is not interrupted due to the failure of a single cleanup action.

[0119] Reference Figure 5 In some embodiments, in response to plugin uninstallation, the framework locates all view assembly records belonging to the plugin based on the business subsystem identifier, executes the shutdown process from child to parent according to the parent-child assembly relationship, and cleans up the logical view descriptions, related engine adaptation descriptions, and context entries registered by the plugin. In a specific implementation, when a business plugin is uninstalled, the framework locates all view assembly records belonging to the plugin based on the plugin's business subsystem identifier, and executes the aforementioned cleanup process sequentially from child to parent according to the parent-child assembly relationship; after shutdown, the framework cleans up the logical view descriptions registered by the plugin, and cleans up the engine adaptation descriptions and context entries registered by the plugin or its engine adaptation module. Therefore, the same cleanup mechanism can be used for both closing a single interface and batch uninstalling all interfaces involved in a plugin.

[0120] This application also provides view contexts and data model contexts, enabling different business subsystems to initiate operations such as opening / closing interfaces, querying models, or broadcasting status through typed context entry points, without directly storing raw pointers to the managers of other business subsystems. In the specific implementation, the view context and data model context provide agreed-upon typed entry points to each business subsystem. Business subsystems initiate operations such as opening / closing interfaces, querying models, or broadcasting status through these typed entry points, without storing raw pointers to each other's managers. When a business subsystem is uninstalled, its entry points registered in the view context and data model context are synchronously removed. Other business subsystems, upon subsequent calls, receive a clear error indicating that the entry point does not exist or the module has been uninstalled, rather than accessing a released object. The view context and data model context can provide one or more forms of synchronous invocation, asynchronous delivery, request-response, or service location, as long as it does not require business subsystems to directly store raw pointers to each other's managers.

[0121] The following example uses an in-vehicle human-machine interface toolchain to illustrate a complete application process of the above method. In this example, the same business subsystem needs to display a parameter panel using a first graphics engine in the desktop debugging tool, a second graphics engine in the 3D simulation environment, and a third graphics engine in the embedded delivery version. This business subsystem registers a logical view description of a parameter panel, declaring that it requires a parameter view model, queries parameter data models by engineering object identifier, and exposes several abstract interaction entry points. The adaptation modules of the first, second, and third graphics engines each register their respective parameter panel engine adaptation descriptions. All three engine adaptation descriptions support the parameter panel, but their native object construction entry points correspond to the controls of the first graphics engine, the interface controls of the second graphics engine, and the scene nodes of the third graphics engine, respectively.

[0122] In the desktop debugging tool, the current graphics engine is identified as the first graphics engine. The framework queries the parameter data model via a controlled query interface based on the parameter panel logical view description, creates a parameter view model, selects the parameter panel engine adaptation description for the first graphics engine, creates the native controls and unified view wrapper object for the first graphics engine, generates a view assembly record, and sequentially appends each destruction action to the destruction action stack of this record during the assembly process. When the user switches to the 3D simulation environment, the framework initiates a migration process for this view assembly record: freezing the record, retaining the parameter data model and parameter view model, disconnecting the native controls of the first graphics engine according to the destruction action stack and destroying the native controls, then selecting the parameter panel engine adaptation description for the second graphics engine, creating the interface controls for the second graphics engine, realigning the same parameter view model with the new unified view wrapper object, and finally displaying the new 3D parameter panel; during this process, business data, parameter states, and interaction logic do not need to be reconstructed. When the parameter panel is closed, the framework executes the cleanup actions in reverse order according to the destruction action stack of the view assembly record. First, it disconnects the view from the view model, then detaches it from the parent container, calls the native object destruction callback described by the second graphics engine adapter, releases the view model lease, releases self-holding references, and cleans up weak references. If the business subsystem is uninstalled as a plugin, the framework finds all relevant view assembly records based on its business subsystem identifier and executes the same shutdown process.

[0123] The above functions can be implemented, in whole or in part, through software, hardware, or a combination thereof. In one embodiment, a computer device is provided, comprising a processor, a memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. When the computer program is executed by the processor, it implements the above-described multi-engine view migration and lifecycle management method based on assembly records. In one embodiment, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the multi-engine view migration and lifecycle management method based on assembly records of the above embodiments. In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it implements the multi-engine view migration and lifecycle management method based on assembly records of the above embodiments. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by hardware related to computer program instructions. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, the computer program can include the processes of the above method embodiments.

[0124] The same or similar parts in the various embodiments of this application can be referenced to each other, and the technical features in the various embodiments can be combined with each other to form new embodiments without conflict.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for multi-engine view migration and lifecycle management based on assembly records, characterized in that, include: S1. Register the logical view description and engine adaptation description. The logical view description is used to express logical view requirements that are independent of the graphics engine, and the engine adaptation description is used to express the implementation method of the logical view for a specific graphics engine. S2. In response to a request to open a target logical view, obtain or create a target data model through a controlled query interface based on the logical view description, and create or reuse a target view model; S3. Select a target engine adaptation description based on the current graphics engine identifier, the logical view description, and the engine adaptation description, and create a unified view wrapper object and a graphics engine native object based on the target engine adaptation description; S4. Generate a view assembly record, which holds the target data model and the target view model, the unified view wrapper object, the graphics engine native object, the lifecycle state and the destruction action stack, and serves as the runtime entry point for the display, migration, closing and plug-in uninstallation of the target logical view; S5. Establish an abstract interactive connection and parent-child assembly relationship between the unified view wrapper object and the target view model. After each resource request, connection or attachment is completed, add the corresponding destruction action to the destruction action stack and display the target logical view. S6. In response to migrating the target logical view from the first graphics engine to the second graphics engine, freeze the view assembly record and retain the target data model and the target view model, release the original unified view wrapper object and the original graphics engine native object according to the destruction action stack, then select a new engine adaptation description based on the logical view description to create a new unified view wrapper object and a new graphics engine native object, and reconnect the target view model and the new unified view wrapper object; S7. In response to closing a view, releasing a parent view, creation failure, migration failure, or plugin uninstallation, perform cleanup actions in reverse order of the destruction action stack and update the lifecycle state.

2. The multi-engine view migration and lifecycle management method based on assembly records according to claim 1, characterized in that, The view assembly record also includes a unique assembly record identifier, a business subsystem identifier, a logical view type, a graphics engine identifier, a set of connection handles, a parent assembly record identifier, a set of child assembly record identifiers, and error information.

3. The multi-engine view migration and lifecycle management method based on assembly records according to claim 1, characterized in that, The engine adaptation description also includes the supported logical view types, native object construction entry, unified view wrapper entry, capability table, and lifecycle callbacks; Before selecting the target engine adaptation description, the engine adaptation description is checked against the capability table to see if it covers the abstract interaction entry required by the logical view description. Engine adaptation descriptions that do not cover the necessary entry are not selected.

4. The multi-engine view migration and lifecycle management method based on assembly records according to claim 1, characterized in that, The creation or reuse of the target view model includes parallel S2a and S2b: S2a. In response to multiple views sharing the same view model, a view model lease is generated for each view assembly record, and the shared view model is released after the last associated view assembly record is released; S2b. In response to the one-to-one correspondence between views and view models, the view model is released when the corresponding view assembly record is closed.

5. The multi-engine view migration and lifecycle management method based on assembly records according to claim 1, characterized in that, The lifecycle states include one or more of the following: declared, view model ready, native view ready, connected, displaying, frozen, migrating, closing, released, and failed; based on the lifecycle states, inconsistent external operations are refused on view assembly records that are frozen, closed, or released.

6. The multi-engine view migration and lifecycle management method based on assembly records according to claim 1, characterized in that, In response to the need for delayed deletion of the graphics engine native object, the destruction action of the graphics engine native object returns a delayed deletion token. The view assembly record remains in a closed state and refuses external operations through the handle of the original graphics engine native object until the delayed deletion token is completed, at which point the lifecycle state is updated to released.

7. The multi-engine view migration and lifecycle management method based on assembly records according to claim 1, characterized in that, The process of displaying the target logical view includes: establishing a self-persistent reference to the top-level view in the display to remain alive during the display period; and storing weak references or invalidable handles in the view factory registry, the parent control child list, or the global index. The process of executing the cleanup actions in the reverse order of the destruction action stack includes first blocking the external entry point and connection handle, then executing the destruction action of the graphics engine native object, and finally releasing the self-persistent reference and cleaning up the weak reference.

8. A multi-engine view migration and lifecycle management system based on assembly records, characterized in that, include: The logical view description registration module is configured to register logical view descriptions that express graphics engine-independent logical view requirements. The engine adaptation description registration module is configured to register engine adaptation descriptions that express specific graphics engine implementation methods and to perform adaptation capability verification based on the capability table. The view assembly module is configured to select a target engine adaptation description based on the current graphics engine identifier, the logical view description and the engine adaptation description, obtain or create a target data model through a controlled query interface, create or reuse a target view model, and create a unified view wrapper object and a graphics engine native object. The assembly record management module is configured to generate, update, query, and freeze view assembly records. The view assembly records hold the target data model and the target view model, the unified view wrapper object, the graphics engine native object, the lifecycle state, and the destruction action stack, and serve as the runtime entry point for display, migration, closing, and plugin uninstallation. The lifecycle cleanup module is configured to maintain connection handles, parent-child assembly relationships, self-holding references and the destruction action stack, and execute cleanup actions in the reverse order of the destruction action stack; as well as The migration control module is configured to freeze the view assembly record and retain the target data model and the target view model when switching graphics engines, release the original unified view wrapper object and the original graphics engine native object, create a new unified view wrapper object and a new graphics engine native object, and reconnect the target view model and the new unified view wrapper object.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores executable program code, and the processor reads and runs the executable program code to execute the multi-engine view migration and lifecycle management method based on assembly records according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement: the multi-engine view migration and lifecycle management method based on assembly records as described in any one of claims 1 to 7.

Images