A UI framework iterative optimization method, device and storage medium

Abstract

The application discloses a UI framework iterative optimization method and device, and a storage medium, comprising: obtaining a to-be-renovated framework interface, determining a to-be-replaced UI control in the framework interface by traversing a UI control tree of the framework interface; changing the to-be-replaced UI control into a corresponding function code block according to a preset UI structure mapping rule, dividing the function code block into multiple independent code regions according to a function module division strategy; generating an interface control script based on each independent code region, and generating a renovated framework interface after binding the interface control script with a corresponding UI view resource; parsing the renovated framework interface by using an editor tool, generating a framework optimization configuration file based on a parsing result; in response to a running instruction, loading the framework optimization configuration file to obtain a page data object, and calling a corresponding business component to perform interface rendering to generate a dynamic component interface. The application realizes automatic renovation and compatibility conversion, improves development efficiency, supports dynamic configuration, and ensures consistent interface behavior.

Description

Technical Field

[0001] This application relates to the field of UI framework development technology, and in particular to a UI framework iterative optimization method, device and storage medium. Background Technology

[0002] In the iteration of existing UI frameworks, the interface of the old framework is usually revamped by manually rewriting or partially replacing it. However, old frameworks generally suffer from key-value pair data passing based on magic strings, tightly coupled event calls, and complex page stack state management. This makes it difficult for the revamped interface to maintain compatibility with the original data behavior, and it is prone to introducing stability defects such as interface switching timing errors and state loss. Manual processing is not only inefficient, but also relies on the experience of developers, making it difficult to guarantee the accuracy and consistency of the revamp process.

[0003] Existing methods lack systematic automation tools, and the replacement of UI controls, the division of code areas, and the assembly of functional modules largely rely on manual operations, failing to achieve effective separation of the interface and logic. The revamped interface is often fixed in the code, making it difficult to quickly respond to changes in business requirements through configuration. Effective auxiliary means are also lacking for animation debugging and code quality assurance, further increasing iteration costs and technical debt.

[0004] Therefore, how to automate control replacement and code area division when revamping old UI frameworks, ensure that the revamped interface is compatible with the original data behavior, and support configurable dynamic rendering to improve development efficiency and reduce error rate has become an urgent technical problem to be solved.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a method, device and storage medium for iterative optimization of a UI framework, which aims to solve the problems of poor compatibility, low automation and difficulty in configuration in the renovation of existing old UI frameworks.

[0007] To achieve the above objectives, this application proposes a UI framework iterative optimization method, the method comprising: Obtain the framework interface to be refurbished, and determine the UI controls to be replaced in the framework interface by traversing the UI control tree of the framework interface. By using preset UI structure mapping rules, the UI control to be replaced is changed into the corresponding functional code block, and the functional code block is divided into multiple independent code areas according to the functional module division strategy; The interface control script is generated based on each independent code area, and the interface control script is bound to the corresponding UI view resource to generate the revamped framework interface. After performing compatibility conversion on the refurbished framework interface, an editor tool is used to parse the refurbished framework interface, and a framework optimization configuration file is generated based on the parsing results. In response to the execution command, the framework optimization configuration file is loaded and parsed to obtain the page data object. The corresponding business components are called from the component library to render the interface and generate a dynamic component interface.

[0008] In one embodiment, the step of changing the UI control to be replaced into a corresponding functional code block according to a preset UI structure mapping rule, and dividing the functional code block into multiple independent code regions according to a functional module division strategy, includes: The function code block corresponding to the UI control is determined according to the preset UI structure mapping rules, and the UI control is replaced in batches with the function code block. In this process, the mapping records of historical renovation projects are obtained, and the frequency of each UI control type being successfully replaced with different function code blocks is counted. The default function code block type corresponding to the UI control type in the UI structure mapping table is dynamically adjusted according to the frequency, and the adjusted default function code block is given priority when performing UI control replacement. Based on the business function type of the functional code block, add a function identifier to the functional code block according to the preset area division rules, and divide the code area of ​​the framework interface into multiple functional modules through the function identifier; The corresponding function code block is called in the function module using the function identifier to assemble the interface function and generate the interface control script.

[0009] In one embodiment, the step of performing compatibility conversion on the refurbished framework interface includes: The magic string parameter in the general key-value pair data class based on CommonDataCollection in the framework interface is converted into a strongly typed property of the page-specific data class, and string, int, and float parameters are passed through the page-specific data class; Register event listeners for the business logic of the framework interface, and replace direct calls to business class methods with sending and receiving events. The state management method of the frame interface is converted to Popup snapshot state management based on the page lifecycle, so that when the pop-up is opened in the frame interface, the state of the pop-up is bound to the lifecycle of the current frame interface, and the pop-up is restored based on the bound state when the frame interface is returned.

[0010] In one embodiment, the step of using an editor tool to parse the revamped framework interface and generating a framework optimization configuration file based on the parsing results includes: The visual editor receives parameter configuration operations for the interface elements of the revamped framework interface, and generates the layout parameters, style parameters, and interaction parameters of the interface elements as key-value pair parameters. Save the key-value pair parameters as a JSON-formatted configuration file.

[0011] In one embodiment, the step of loading and parsing the framework optimization configuration file to obtain a page data object in response to a run instruction, and calling the corresponding business component from the component library to perform interface rendering and generate a dynamic component interface includes: The running command is triggered when the game starts or a hot update is completed, and the configuration file is loaded and parsed based on the running command to obtain a page data object. In response to the page generation instruction, the business component corresponding to the page data object is called in the component library through the pre-referenced dependency resolution chain. The dependency resolution chain is referenced through node tree, loader chain, component binding and business code. The component library includes general components and business components. The interface is rendered using the business components, and the dynamic component interface is generated based on the rendering results.

[0012] In one embodiment, the step of rendering the interface through the business component and generating the dynamic component interface based on the interface rendering result includes: Configure the IComponent interface for the business component, the IComponent interface including page initialization callback function and page lifecycle callback function; The business component is passed to the dynamic component interface through the IComponent interface to generate the dynamic component interface. When it is determined that the business component is called by the dynamic component interface, the state parameters of the business component are synchronized to the page parameters of the dynamic component through the page initialization callback function. When it is determined that the life cycle state of the dynamic component interface changes, the business component is notified to update its state through the page life cycle callback function. The business component communicates with the outside world through an event mechanism.

[0013] In one embodiment, after the step of generating the dynamic component interface, the method further includes: Configure an independent animation script for the dynamic component interface, and bind the dynamic target object through the independent script; Obtain the animation parameters of the dynamic target object, modify and debug the animation parameters using an editor tool, and obtain the animation configuration file; The animation configuration file is invoked through the framework interface to be optimized to improve the animation performance.

[0014] In one embodiment, before the step of parsing the refurbished framework interface using an editor tool after performing compatibility conversion on the refurbished framework interface, the method further includes: The interface control script is reviewed and repaired by calling a preset AI model via API, and the interface control script is updated based on the repair results. This includes reviewing and repairing the interface control script by calling a preset AI model via API, including: The component code of the interface control script is parsed, and a corresponding code dependency graph is generated based on the parsing results. The code dependency graph contains the reference relationships between classes, methods, and variables. The review prompts are generated based on the code dependency graph and received by the AI ​​model. The component code is reviewed using the review prompts, which instruct the AI ​​model to output optimization suggestions regarding the robustness, readability, and scalability of the code. The review results output by the AI ​​model are analyzed, and a set of optimization suggestions to be executed is generated based on the analysis results. The set of optimization suggestions includes multiple optimization suggestions, and each optimization suggestion includes suggestion type, modification location and modification content. The optimization suggestion set is traversed to execute the optimization suggestion repair component code in the optimization suggestion set, and after the optimization suggestions in the optimization suggestion set have been executed, the framework optimization result is output based on the repaired component code.

[0015] In addition, to achieve the above objectives, this application also proposes a UI framework iterative optimization device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the UI framework iterative optimization method as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the UI framework iterative optimization method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: The technical solution of this application involves obtaining a framework interface to be refurbished, determining the UI controls to be replaced in the framework interface by traversing the UI control tree of the framework interface, changing the UI controls to be replaced to corresponding functional code blocks according to a preset UI structure mapping rule, and dividing the functional code blocks into multiple independent code areas according to a functional module division strategy, generating interface control scripts based on each independent code area, and binding the interface control scripts with corresponding UI view resources to generate the refurbished framework interface, performing compatibility conversion on the refurbished framework interface, parsing the refurbished framework interface using an editor tool, and generating a framework optimization configuration file based on the parsing results, and in response to a run command, loading and parsing the framework optimization configuration file to obtain a page data object, calling the corresponding business components from the component library to render the interface, and generating a dynamic component interface. This application achieves automated refurbishment and compatibility conversion, improves development efficiency, supports dynamic configuration, and ensures consistent interface behavior. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the UI framework iterative optimization method of this application; Figure 2 This is a detailed process diagram based on step S20 in the first embodiment; Figure 3 This is a detailed schematic diagram of step S40 based on the first embodiment; Figure 4 This is a schematic diagram of another detailed process based on step S40 in the first embodiment; Figure 5 This is a detailed process diagram based on step S50 in the first embodiment; Figure 6 This is a flowchart illustrating the second embodiment of the UI framework iterative optimization method of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the UI framework iterative optimization method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In related technologies, the iterative optimization of UI frameworks mainly follows two different technical paths, but each has its own inherent defects, making it difficult to meet the multiple needs for compatibility, automation and flexibility in the renovation of old projects.

[0024] The first type of method is represented by manual rewriting or partial replacement, including solutions such as developers manually refactoring the old framework interface and modifying control code page by page. This type of method involves manually identifying the UI controls that need to be replaced and rewriting the code and adapting the functionality based on experience. However, this method is highly dependent on the experience and meticulousness of the developers. The revamped interface often struggles to maintain compatibility with the original data behavior due to issues such as magic string parameter passing, tightly coupled event calls, and complex page stack state management. This can easily introduce stability defects such as interface switching timing errors and state loss. Real-world projects show that when the old framework is large or the business logic is complex, manual revamping is not only inefficient but also prone to omissions and errors, resulting in serious compatibility and reliability defects. Furthermore, this type of method only completes the interface reconstruction and lacks automated verification and dynamic adjustment mechanisms for the revamp effect, making it difficult to support the rapid iteration requirements of subsequent business needs.

[0025] The second type of approach attempts to improve upon this by introducing automation tools, including batch replacement tools or code generation plugins based on UI control recognition. These methods automatically replace controls using preset rules, improving renovation efficiency to some extent. While this approach can speed up replacement in specific scenarios, its deployment still has significant limitations: it only performs mechanical replacement at the control level, ignoring the functional division and structural optimization of the code area; it uses fixed mapping rules and lacks a mechanism to link historical replacement data with dynamic rule adjustments; and it lacks compatibility handling for the behavior, event responses, and state management of the renovated interface, making it difficult to ensure consistency between the renovated interface and the original framework. When dealing with older projects that have undergone multiple iterations and have complex business logic, automation tools often experience issues such as abnormal interface display and interaction failures, leading to a common technical problem where existing methods struggle to balance compatibility, flexibility, and practicality.

[0026] A comprehensive analysis reveals that the core dilemma faced by both approaches lies in the following: while manual revamping allows for fine-tuning, it suffers from low efficiency and poor compatibility; while automated tools improve efficiency, they lack specific solutions to the inherent flaws of older frameworks. Both struggle to achieve a balance between automated revamping, behavioral compatibility, and flexible configuration. More importantly, existing solutions generally employ static revamping logic, fixing the revamped interface in the code. This prevents dynamic adjustments through configuration when facing rapid changes in business requirements, resulting in a persistent technical challenge in balancing efficiency, compatibility, and adaptability in existing UI framework iteration methods.

[0027] Based on the aforementioned deficiencies in related technologies, this application proposes a UI framework iterative optimization method. This method addresses the core pain points of existing methods, such as low automation, poor compatibility, and difficulty in configuration. It automatically converts UI controls to be replaced into functional code blocks using preset UI structure mapping rules, and divides them into independent code regions according to a functional module division strategy. Interface control scripts are generated based on each region and bound to UI view resources to generate a revamped framework interface. Subsequently, the revamped interface undergoes compatibility conversion: magic string parameters are converted to strongly typed attributes, direct calls to business class methods are replaced with event decoupling, and state management is converted to Popup snapshot management based on the page lifecycle, ensuring compatibility between the revamped interface and the original data behavior. Finally, an editor tool is used to parse the revamped interface and generate a framework optimization configuration file. Upon responding to a runtime command, the parsed configuration file is loaded, and business components are called from the component library for interface rendering, generating a dynamic component interface. Through these technical means, this application achieves automated revamping while ensuring behavioral compatibility, and provides an effective technical solution to the comprehensive technical problems of low revamping efficiency, poor compatibility, and difficulty in configuration in existing technologies.

[0028] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0029] Based on this, embodiments of this application provide a UI framework iterative optimization method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the UI framework iterative optimization method of this application. In this embodiment, the UI framework iterative optimization method includes steps S10 to S50: Step S10: Obtain the frame interface to be refurbished, and determine the UI controls to be replaced in the frame interface by traversing the UI control tree of the frame interface. Obtaining the framework interface to be revamped is the first step in the entire process. In the project development environment, the old framework interface usually exists as a prefab or scene file, which developers load through the resource management system. After loading, the system obtains the root node object of the interface, which represents the top-level container of the entire interface. Starting from the root node, a recursive algorithm is used to traverse all its child nodes, forming a complete UI control tree. During the traversal, each node corresponds to a UI control instance, including buttons, text boxes, sliders, panels, etc. The system extracts the type name, instance name, attached script list, and a series of attribute values ​​such as position coordinates, size, and text content for each control.

[0030] To accurately identify controls that need to be replaced, the system pre-defines a control feature library. This library contains a list of control types that need to be phased out in the old framework, along with corresponding judgment rules. Judgment rules can be based on control type name, namespace, parent node structure characteristics, or specific script markers attached to the control. For example, the old framework uses an older version of the Button control, with the feature type name OldButton and the LegacyClickHandler script attached. When a control is encountered that matches any rule in the feature library, the system marks it as a control that needs to be replaced and records its complete hierarchical path. The hierarchical path is formed by concatenating all node names from the root node to the control, such as Canvas / MainPanel / Header / LoginButton. This path is used for accurate location during subsequent replacement operations.

[0031] After completing the full traversal, the system generates a list of controls to be replaced. Each item in the list is a structure containing a unique identifier, type name, hierarchical path, original property set, and mounted script information. This list serves as the input data source for subsequent automated replacement operations. During list generation, the system also analyzes the hierarchical relationships between controls, identifying nested structures to ensure that the original parent-child relationships are maintained during replacement. For example, if a panel contains multiple buttons, their relative positions within the panel must be preserved during replacement. Through this traversal and recording, a comprehensive check of the old framework interface is completed, laying the data foundation for subsequent accurate replacement.

[0032] Step S20: Using a preset UI structure mapping rule, the UI control to be replaced is changed to the corresponding functional code block, and the functional code block is divided into multiple independent code areas according to the functional module division strategy. After obtaining the list of controls to be replaced, the system begins the automated replacement process. First, a UI structure mapping table is constructed. This table, a configuration file, records the mapping relationship between old control types and new framework functional code blocks. The mapping table is stored in key-value pairs, where the key is the old control type identifier and the value is the corresponding new code block template identifier. For example, the key `OldButton` corresponds to the value `UIButtonEx`, and the key `OldSlider` corresponds to the value `UISliderEx`. Simultaneously, the mapping table also defines attribute conversion rules, mapping the attributes of old controls to the attributes of new code blocks. For example, the `text` attribute of an old control is directly mapped to the `label` attribute of a new code block, and the `onClick` event of an old control is mapped to the `clickEvent` event of a new code block. The system iterates through the list of controls to be replaced, searching for the corresponding new code block template in the mapping table for each control based on its type, and then uses a code generation engine to generate new functional code block instances in batches.

[0033] To improve mapping accuracy, the system introduces a dynamic adjustment mechanism. In historical renovation projects, the system records both successful and failed replacements. A successful replacement is defined as one where the new interface functionality passes testing without introducing bugs. The system tracks the frequency with which each control type is successfully replaced with different code blocks, creating historical statistics. For example, data shows a 95% success rate for replacing the OldButton control with UIButtonEx and an 80% success rate for replacing it with UIOldCompatibleButton. Based on this data, the system dynamically adjusts the default mapping relationships in the mapping table, prioritizing code block types with higher success rates. During the current replacement execution, the system automatically adopts the adjusted default mapping, thereby continuously optimizing the replacement effect.

[0034] After replacing the control code blocks, the system organizes the generated code blocks according to a functional module division strategy. This strategy decomposes the interface into regions based on business logic, such as title areas, content areas, operation areas, and pop-up areas. Each region corresponds to a set of related UI controls. The system adds a functional identifier to each code block; this identifier is a custom attribute or comment tag that indicates the region to which the code block belongs. When generating the code file, the system uses these identifiers to group code blocks in the same region together and wraps them with the #Region tag, forming independent code regions. For example, all code blocks belonging to the title area are placed within a #Region block named "Title Area". This division makes the final UI control script structure clear, isolating the code for different functions, allowing developers to quickly locate and modify the code for specific functions, much like assembling building blocks.

[0035] Step S30: Generate interface control scripts based on each independent code area, and bind the interface control scripts with the corresponding UI view resources to generate the revamped framework interface; Based on the pre-defined set of code blocks divided into regions, the system begins generating complete UI control scripts. Each UI control script is a C# class, typically named with the UI name followed by the suffix "Controller," such as `LoginPanelController`. The script class contains multiple member variables, each corresponding to a UI component. These variables will be used later when binding with view resources. The system iterates through the code blocks within each functional region. For each code block, it generates a corresponding variable declaration based on its type; for example, a variable of type `UIButtonEx` is declared as `public UIButtonExloginButton`. Simultaneously, the system generates region initialization methods, which call the initialization functions of each code block sequentially according to the region order. These initialization functions are responsible for setting the default state of controls, registering event listeners, etc. Furthermore, the script class also contains event handling methods for each region. These methods are triggered during UI interaction to execute business logic.

[0036] After generating the script code, the system compiles or saves it as a source file and prepares it for binding with UI view resources. UI view resources are prefabs created by artists or UI designers, containing visual elements of the interface but without any bound logic code. In the Unity editor, the system uses automated tools to add the generated script components to the root node of the prefab. Then, using reflection or serialization, it associates variables in the script with corresponding UI component instances on the prefab. For example, the system finds the button object named "loginButton" in the prefab and assigns it to the "loginButton" variable in the script. The binding process supports batch operations, quickly completing the assignment of all variables by iterating through the matching relationships between variable names and prefab node names. After binding, the new prefab is saved to a specified path, forming the revamped framework interface. This interface retains the original visual style while integrating the new framework's code structure, preparing for subsequent compatibility conversions and configurability.

[0037] Step S40: After performing compatibility conversion on the refurbished framework interface, use an editor tool to parse the refurbished framework interface and generate a framework optimization configuration file based on the parsing results. While the revamped framework interface has undergone a code structure update, its data transfer, event handling, and state management methods may still differ from the old framework, requiring compatibility conversion. Firstly, regarding data transfer, the old framework widely used the CommonDataCollection, a generic key-value collection, to transfer data. The keys were magic strings, prone to spelling errors and difficult to debug. During the compatibility conversion, the system defined a dedicated data class for each page, containing strongly typed properties such as `string UserName` and `int Score`. The system analyzed all read and write operations on CommonDataCollection in the original code, replacing these operations with direct access to the page-specific data class properties. Simultaneously, the system generated conversion code to map the data originally stored in CommonDataCollection to the corresponding properties of the new data class, ensuring that the old data remains usable in the new structure.

[0038] Event-driven transformation aims to address the tight coupling between business logic and the user interface in legacy frameworks. The old framework's code frequently contained statements directly calling static methods of business classes, such as `BusinessClass.DoSomeThing()`. This approach made UI replacement and testing difficult. During the transformation, a global event system was introduced, registering unified event listeners for the business logic. The original direct calls were rewritten as event sending, such as `EventSystem.Send(new DoSomeThingEvent())`, with event receiving logic written in appropriate locations to handle the events. The event receiver is responsible for calling the actual business methods, thus decoupling the UI from the business logic. After the transformation, the UI only needs to send events, without worrying about who handles them, improving code maintainability and extensibility.

[0039] State management transitions are a crucial aspect of compatibility handling. The old framework managed UI state using a page stack and active snapshots, storing all opened pages in the scene's hierarchy and controlling their display / hiding by switching their active state. This approach easily led to state inconsistencies when the UI hierarchy was complex. The system converted this to Popup snapshot state management based on page lifecycles. Specifically, a state snapshot is defined for each page, recording the page's identifier and state parameters for all popups it opened. When a popup opens on a page, the system binds its snapshot to the current page's lifecycle. When a page is paused or closed, the system saves its state snapshot; when the page resumes, the popup and its state are automatically reconstructed based on the snapshot. This mechanism ensures that the display state and data of all popups are accurately restored during page switching and returning, meeting user expectations.

[0040] After compatibility conversion, the system uses a custom editor tool to parse the prefab of the revamped interface. This tool iterates through all UI components on the prefab, extracting layout parameters such as anchor points, offsets, and dimensions of `RectTransform`, style parameters such as font, size, and color of text, source images and grid settings for images, and interaction parameters such as the list of button click events. The extracted parameters are organized as key-value pairs, for example, "loginButton.position.x" corresponds to a specific value. The tool also supports manual adjustment and preview, allowing developers to see the immediate effect after modifying parameters in the editor. Finally, all parameters are serialized into a JSON-formatted framework optimization configuration file. This file contains complete configuration information for the interface, allowing subsequent changes to the interface's appearance and behavior without modifying the code.

[0041] In step S50, in response to the run command, the framework optimization configuration file is loaded and parsed to obtain the page data object, and the corresponding business components are called from the component library to render the interface and generate a dynamic component interface.

[0042] When the game starts or a hot update completes, the system triggers a run command to begin loading the framework optimization configuration file. This configuration file is typically stored in StreamingAssets or on a remote server. The system asynchronously reads this file through the resource loading module and uses a JSON parsing library to deserialize it into a page data object in memory. The page data object is a hierarchical data container that contains the interface's layout parameters, style parameters, and type identifiers for required components. For example, for a login screen, the page data object might contain a root node of type "LoginPanel," with child nodes of type "UIButtonEx" attached, along with the button's coordinates and event binding information.

[0043] After obtaining the page data object, the system enters the interface rendering process. First, based on the component type identifier in the page data object, the system searches for the corresponding business component prefab from the pre-registered component library. The component library is a collection of resources, divided into two main categories: general components and business components. General components include prefabs of basic controls such as UIButtonEx, UITextEx, and UISliderEx, while business components are composite controls composed of multiple general components, such as sidebars, purchase buttons, and progress bars. The search process is completed through a dependency resolution chain, which consists of a node tree manager, a loader chain, a component binder, and business code references. The node tree manager is responsible for maintaining the UI node structure of the current scene, the loader chain attempts to load component resources from different paths according to priority, the component binder is responsible for binding the loaded component instance with the parameters in the page data object, and the business code references ensure that the component can access the necessary business logic services.

[0044] After locating the corresponding business component prefab, the system instantiates the prefab and adjusts its position and size according to the layout parameters in the page data object. Then, style parameters are applied to the component's various visual elements, such as setting button text color and background images. Finally, event listeners are registered for the component based on interaction parameters, enabling corresponding business events to be triggered when the user clicks a button or slides a slider. The entire rendering process is driven entirely by configuration files; the same UI prefab can exhibit different appearances and behaviors depending on different configuration files. After rendering, the dynamic component interface is added to the scene for user interaction. Because the UI logic is separated from the code, any subsequent adjustments only require modifying the configuration file and reloading, without recompiling the code, greatly improving development and iteration efficiency.

[0045] In addition, before the step of parsing the revamped framework interface using an editor tool after performing compatibility conversion on the revamped framework interface, the following steps are also included: The interface control script is reviewed and repaired by calling a preset AI model via API, and the interface control script is updated based on the repair results. This includes reviewing and repairing the interface control script by calling a preset AI model via API, including: The component code of the interface control script is parsed, and a corresponding code dependency graph is generated based on the parsing results. The code dependency graph contains the reference relationships between classes, methods, and variables. The review prompts are generated based on the code dependency graph and received by the AI ​​model. The component code is reviewed using the review prompts, which instruct the AI ​​model to output optimization suggestions regarding the robustness, readability, and scalability of the code. The review results output by the AI ​​model are analyzed, and a set of optimization suggestions to be executed is generated based on the analysis results. The set of optimization suggestions includes multiple optimization suggestions, and each optimization suggestion includes suggestion type, modification location and modification content. The optimization suggestion set is traversed to execute the optimization suggestion repair component code in the optimization suggestion set, and after the optimization suggestions in the optimization suggestion set have been executed, the framework optimization result is output based on the repaired component code.

[0046] After completing the compatibility conversion of the revamped framework interface, the system introduces an AI-assisted review mechanism to ensure the quality of the generated interface control scripts. This step aims to leverage artificial intelligence technology to automatically discover potential defects in the code, improving its robustness, readability, and scalability. First, the system submits the component code of the interface control scripts to the AI ​​model for review. Since the AI ​​model cannot directly understand the semantics and structure of the original code, the system preprocesses the code to generate a structured representation that reflects the internal dependencies. By parsing the code's abstract syntax tree, the system extracts all class definitions, method declarations, variable definitions, and their reference relationships, constructing a complete code dependency graph. This graph uses nodes to represent code elements and edges to represent references or calls, providing a data foundation for subsequent review prompt generation.

[0047] Based on the code dependency graph, the system generates targeted review prompts. These prompts are natural language descriptions that guide the AI ​​model to focus on specific aspects of the code. The prompts include an overall functional overview of the code, the roles of key classes and methods, and the dimensions the system wants the AI ​​to focus on reviewing, such as whether the code's robustness handles boundary conditions and exceptions, whether its readability is based on naming conventions and is adequately commented, and whether its extensibility is based on well-designed interfaces and abstractions. The prompts also include a simplified representation of the code dependency graph to help the AI ​​understand the code's macro-structure. The system sends the review prompts to a pre-defined AI model via API. This AI model can be a general-purpose language model deployed in the cloud or a specialized model fine-tuned for code review tasks. The API call process includes authentication, request encapsulation, and result reception, ensuring secure data transmission.

[0048] After receiving review prompts, the AI ​​model performs a comprehensive analysis of the component code and outputs optimization suggestions. These suggestions are returned in structured data format, with each suggestion including its type (e.g., robustness optimization, readability improvement, scalability enhancement), the location of the modification (e.g., filename and line number), and a detailed description of the changes. The system parses the review results from the AI ​​model and converts them into a set of optimization suggestions to be executed. This set is a list, sorted by suggestion type and modification location. The system iterates through this set, automatically attempting to fix each suggestion. For simple modifications such as adding null checks, renaming variables, or adding comments, the system can directly execute code changes based on the modifications. For complex refactoring suggestions, the system may generate multiple candidate solutions, which are then confirmed and implemented by the developers. After the fix is ​​complete, the code files for the UI control scripts are updated, and a fix log is recorded.

[0049] After all optimization suggestions have been implemented, the system outputs framework optimization results based on the repaired component code. This result includes not only updated UI control scripts but also an optimization report detailing the original issues discovered by the AI, the suggested solutions, and the actual implementation status. The optimization results are saved to the version control system and associated with the corresponding framework optimization configuration file, ensuring that subsequent builds and deployments use high-quality code reviewed by AI. Through this AI review and repair process, the system can automatically discover and fix numerous low-level errors and potential risks early in development, significantly reducing the burden of manual code review and improving overall code quality and development efficiency.

[0050] Furthermore, you can also view Figure 2 , Figure 2 This is a detailed process diagram based on step S20 in the first embodiment. Figure 2 The steps of changing the UI control to be replaced into a corresponding functional code block according to a preset UI structure mapping rule, and dividing the functional code block into multiple independent code regions according to a functional module division strategy, include S21~23: Step S21: Determine the functional code block corresponding to the UI control according to the preset UI structure mapping rules, and replace the UI control with the functional code block in batches. In this step, the mapping records of historical renovation projects are obtained, and the frequency of each UI control type being successfully replaced with different functional code blocks is counted. The default functional code block type corresponding to the UI control type in the UI structure mapping table is dynamically adjusted according to the frequency, and the adjusted default functional code block is given priority when performing UI control replacement. Step S22: According to the business function type of the function code block, add a function identifier to the function code block according to the preset area division rules, and divide the code area of ​​the framework interface into multiple function modules through the function identifier; Step S23: Use the function identifier to call the corresponding function code block in the function module to assemble the interface function, so as to generate the interface control script.

[0051] When replacing controls according to preset UI structure mapping rules, the system first needs to establish and maintain a dynamically updated mapping table. The UI structure mapping table is stored in the form of a configuration file, recording the correspondence between old control types and new framework functional code blocks. Each entry in the table includes an old control type identifier (e.g., OldButton), a default mapped functional code block identifier (e.g., UIButtonEx), and a list of alternative mappings. To improve the accuracy and adaptability of the mapping, the system introduces a dynamic adjustment mechanism based on historical project data. After each renovation project is completed, the system collects the mapping records for that project, recording which functional code block each replaced control type actually used, and whether the replacement was deemed successful after functional testing. The criterion for success is that the new interface does not exhibit any functional defects or compatibility issues related to the replacement in subsequent tests.

[0052] The system stores historical mapping records in a database and performs periodic statistical analysis. For each control type, it counts the number of times it was successfully replaced by different functional code blocks and calculates the success frequency of each mapping. For example, for the OldButton control, historical data shows that it was successfully mapped to UIButtonEx 95 times and to UIOldCompatibleButton 5 times, so the success frequency of UIButtonEx is 95%. Based on this frequency data, the system dynamically adjusts the default functional code block types in the UI structure mapping table. When the success frequency of a certain mapping exceeds a preset threshold, such as 90%, the system promotes that mapping to the default mapping; if the success frequency of the current default mapping is lower than another threshold, such as 70%, the system automatically selects the highest success rate from the backup mapping list as the new default mapping. This dynamic adjustment process is triggered at each project start or periodically to ensure that the mapping rules can be continuously optimized.

[0053] When performing batch replacement of UI controls in the current project, the system iterates through the list of controls to be replaced. For each control, it first searches for the corresponding default function code block in the mapping table based on its type. If the default mapping exists and the success rate meets the requirements, the default mapping is used directly to generate the code block. If the default mapping does not exist or the success rate is low, the system will prompt the developer for manual confirmation, or provide multiple candidate options from the backup list. The replacement process uses a batch processing method, generating all new code block instances at once, and passing the attribute values ​​of the original controls to the new code blocks according to the attribute conversion definitions in the mapping rules. For example, the text content of the original OldButton is assigned to the label property of the new UIButtonEx, and the name of the original click event handling method is assigned to the onClick event field of the new button. After the replacement is completed, the system generates a replacement log, recording the replacement result of each control for subsequent tracking and auditing.

[0054] The generated functional code blocks from batch replacements are initially an unordered collection and need to be organized and categorized according to business functions. The system first needs to define a functional module division strategy, which splits the interface into multiple independent functional areas based on the commonalities of business logic. Common division methods include division according to interface layout areas, such as title area, content area, and navigation area, or division according to interactive functions, such as login module, settings module, and display module. The division strategy exists in the form of a rule file, which contains the criteria for determining the area to which various functional code blocks should belong. These criteria can be based on the type of code block, such as buttons or input boxes; the position coordinates of the original control on the interface; the name of the parent node of the original control; or the semantic label of the control in the business logic.

[0055] The system iterates through all newly generated functional code blocks, applies a partitioning strategy to each block, and determines its corresponding functional module. Once assigned, the system adds a functional identifier to the code block. This identifier is a custom attribute or comment label, existing as an attribute or comment in the C# code. For example, the system adds the attribute `[FunctionRegion("NavigationArea")]` above the class or method generated from the code block, or adds the comment ` / / Region: NavigationArea`. For IDEs that support region collapsing, such as Visual Studio, the system also generates corresponding `#Region` preprocessor directives, wrapping multiple code blocks within the same region between `#Region` and `#EndRegion`. For example, all code blocks belonging to the navigation area are grouped together within a `#Region` block named "Navigation Area," which can be expanded or collapsed in the code editor to improve code readability.

[0056] Adding function identifiers not only aids in code organization but also provides a basis for subsequent automated assembly and referencing. During identifier generation, the system also records the list of code blocks corresponding to each identifier and their starting line number in the script, generating a region index table. This index table is subsequently used to quickly locate code in specific functional areas and to determine the order of regions when the interface controls script generation. To ensure accuracy, the system provides a visual interface that allows developers to review and manually adjust the results of the automatic partitioning. Developers can see the region labels assigned to each code block in the editor and move code blocks from one region to another by dragging and dropping; the system updates the identifiers and code organization in real time. This partitioning method, primarily automated with supplementary manual adjustments, improves efficiency while maintaining flexibility.

[0057] After adding the function identifiers, the system enters the stage of assembling and generating the UI control script. The UI control script is a complete C# class file that needs to combine the code blocks from various functional modules in a logical order to form compileable and executable code. The system first creates an empty script template containing necessary namespace references, class declarations, and basic framework code. Then, according to the predefined arrangement order of the functional modules, it loads the code block set corresponding to each module sequentially. The arrangement order usually follows the natural order of the interface layout, such as from top to bottom, from left to right, or according to the execution order of business logic, such as initialization first, then interaction. The system reads the area index table and traverses each functional module in the specified order.

[0058] For each functional module, the system assembles all its internal code blocks according to a specific internal order. This internal order can be the hierarchical order of the code blocks within the original control tree, or it can be the result of automatic sorting based on dependencies. The system analyzes the dependencies between code blocks; for example, if a button's event handler might reference data from another text box, the system ensures that the referenced code block is declared before the referrer. After assembly, the system inserts the entire module's code into the corresponding location in the script file as a #Region block. During insertion, the system also automatically generates module-level comments explaining the module's function and main controls. After all modules are inserted, the system generates the overall script structure, including member variable areas, initialization methods, event registration methods, and custom methods for each module.

[0059] After assembly, the system performs syntax checks and dependency verification on the generated script to ensure there are no missing references or conflicting names. If errors are found, the system logs the error message and prompts developers to manually correct them. Once verification is successful, the system saves the script as a .cs file and associates it with the corresponding UI view resource. The functional identifiers used during assembly not only serve for area division but also play a role in subsequent maintenance. When business requirements change and a function needs adjustment, developers can quickly locate the corresponding code area using the identifiers without searching the entire script. Simultaneously, because the code blocks are organized according to functional modules, team collaboration allows for clearer division of responsibilities, with different developers responsible for maintaining different areas of code, reducing conflicts. Through this assembly mechanism, previously scattered code blocks are integrated into a clearly structured and easily maintainable UI control script.

[0060] You can also view Figure 3 , Figure 3 This is a detailed process diagram based on step S40 in the first embodiment. Figure 3 The step of performing compatibility conversion on the refurbished framework interface includes S41-43: Step S41: Convert the magic string parameter in the general key-value pair data class based on CommonDataCollection in the framework interface into a strongly typed property of the page-specific data class, and pass string, int, and float parameters through the page-specific data class; Step S42: Register event listeners for the business logic of the framework interface, and replace the direct call to the business class method with the method of sending and receiving events; Step S43: Convert the state management method of the frame interface to Popup snapshot state management based on page lifecycle, so that when the popup is opened in the frame interface, the state of the popup is bound to the lifecycle of the current frame interface, and the popup is restored based on the bound state when the frame interface is returned.

[0061] After completing the generation of interface control scripts and the binding of view resources, the system enters the compatibility conversion phase, which aims to ensure that the revamped framework interface can maintain consistency with the data behavior of the old framework. This phase includes three core sub-steps, which respectively carry out in-depth transformations of data transmission, event response, and state management, resolving common problems in the old framework such as magic strings, tightly coupled calls, and state chaos.

[0062] Among them, the CommonDataCollection, a general key-value pair data class, is widely used in the old framework to transfer interface parameters. Its keys are hard-coded as magic strings throughout the code. For example, dataCollection.SetValue("userName", "张三"), and when retrieving values, dataCollection.GetString("userName") is used. Although this design is flexible, it is difficult to detect string spelling mistakes, and compilation checks cannot be passed during debugging, making it extremely easy to introduce hidden bugs. When the system performs compatibility conversion, it first analyzes all read and write operations on CommonDataCollection in the old interface, identifies all the magic string key names used and their corresponding data types. For each page, the system automatically generates a page-specific data class, which replaces the original key-value pair access with strongly typed properties. For example, for the login page, the LoginPageData class is generated, which contains properties such as string UserName, string Password, int LoginAttempts, etc. The system traverses the interface control script and replaces all calls to CommonDataCollection with access to the properties of the page-specific data class instance. At the same time, to ensure the smooth migration of old data, the system adds a conversion code during page initialization to read the existing data stored in CommonDataCollection and assign it to the corresponding properties of the new data class. This conversion enables subsequent code to enjoy compile-time type checking, the magic strings completely disappear, and the data flow becomes clearly traceable.

[0063] To decouple event response methods, the old framework often directly called methods of static business classes, such as defining them in button click events like `BusinessLogic.SubmitOrder(orderData)`. This approach tightly coupled the UI code with the specific business implementation, making any UI replacement or business modification a system-wide disruption. The new system introduces a global event system based on the observer pattern, providing event sending, listening, and broadcasting capabilities. First, corresponding event classes, such as `SubmitOrderEvent`, are defined for the business calls that need decoupling. These classes carry necessary parameters, such as order data. Then, in the original UI code, all direct calls to business methods are replaced with event sending statements, such as `EventSystem.Send(newSubmitOrderEvent(orderData))`. Simultaneously, event listeners are registered in the business logic layer to listen for corresponding events and execute the actual business method upon receiving an event. To ensure the integrity of the conversion, the system also analyzes the code for other forms of direct calls, such as accessing the business manager via a singleton pattern, also using event-based decoupling. After the transformation, the interface no longer depends on specific business classes; business logic can be triggered simply by sending events, improving code testability and module independence. Event listener registration is typically completed during system startup, automatically bound via scanning assemblies, or manually specified through configuration files.

[0064] During the reconstruction of the state management mechanism, the old framework used a page stack plus active snapshot approach to manage interface state. All previously opened pages were retained in the scene's hierarchy, and their display and hiding were controlled by setting the `active` attribute. As the number of pages increased, this approach easily led to excessive memory consumption, and the complex state dependencies between pages caused state inconsistencies upon returning. The system was converted to Popup snapshot state management based on the page lifecycle. First, a state snapshot object is defined for each page, recording the page's unique identifier, the identifiers of all pop-ups within the page, and their current state parameters. When a pop-up is opened, the system automatically captures a snapshot of that pop-up and binds it to the current page's lifecycle, storing it in the page's state stack. When a page is paused and switched to another page or closed, the system saves a complete state snapshot of the page to the global state manager. When the page is resumed, the system reconstructs the page and all its pop-ups based on the snapshot, restoring the pop-ups to their previous position, size, and data display state. Throughout this process, instances of pages and their pop-ups can be destroyed and reconstructed without the user perceiving any loss of state. This mechanism is particularly suitable for complex multi-level pop-up scenarios, such as when multiple levels of pop-ups are open within a settings page. After the user clicks back, all pop-ups can reappear in their original order and state. Through Popup snapshot state management, the system achieves accurate restoration of page state while reducing memory usage and improving the smoothness of interface transitions.

[0065] You can also view Figure 4 , Figure 4 This is a schematic diagram of another detailed process based on step S40 in the first embodiment. Figure 4 The step of using an editor tool to parse the revamped framework interface and generating a framework optimization configuration file based on the parsing results includes steps S44-45: Step S44: Receive parameter configuration operations for the interface elements of the revamped framework interface through a visual editor, and generate layout parameters, style parameters, and interaction parameters of the interface elements as key-value pair parameters. Step S45: Save the key-value pair parameters as a JSON format configuration file.

[0066] After the compatibility conversion was completed, the revamped framework interface now exhibits behavior consistent with the old framework. To further improve development efficiency and flexibility, the system needs to extract the interface's appearance and interaction parameters into a configurable configuration file, allowing for subsequent adjustments without requiring code modifications.

[0067] The revamped framework interface can be configured using a visual editor. A custom interface parameter extraction tool was developed within the Unity editor and integrated as a plugin into the Inspector panel. When a developer selects a revamped interface prefab, the tool automatically iterates through all UI components on the prefab, identifying configurable parameters. Layout parameters include anchor point settings, relative position offsets, width, and height for RectTransform components; style parameters include font, size, color, and alignment for text components; source image, color, and 3x3 grid for image components; and interaction parameters include click event binding lists for button components, value ranges for slider components, and character limits for input boxes. The tool displays these parameters in a tree structure on the panel, allowing developers to directly modify the value of each parameter. For example, adjusting the width of the login button from 100 to 120, changing the title text color to red, or adding a new click event to the submit button. After each modification, the tool previews the effect in the scene in real time, allowing developers to intuitively see the adjusted interface presentation without rerunning the game. This WYSIWYG configuration method allows non-technical personnel, such as planners or artists, to participate in interface adjustments, reducing the burden on programmers.

[0068] Save the configured parameters as a JSON configuration file. Once the developers are satisfied with the current configuration, they can click the save button on the tool panel. The system will then collect all modified parameters and organize them into key-value pairs.

[0069] Key naming follows a hierarchical structure; for example, "loginButton.rectTransform.width" represents the width of the login button, and "titleText.textComponent.color.r" represents the red channel value of the title text. To ensure the readability and maintainability of the configuration file, the system supports grouping and comments, allowing developers to add explanatory text to the configuration file. Upon saving, the system displays a file save dialog box; the default filename is the interface name plus the ".json" suffix, such as "LoginPanel.json". The configuration file is stored in the project's Resources folder or StreamingAssets folder for easy runtime loading. Simultaneously, the system generates a corresponding C# data class for deserializing the configuration data at runtime, avoiding the hassle of manually parsing strings. If the project has multi-language requirements, the system also supports generating independent configuration files for different languages, loading the corresponding version at runtime based on the current language. Through this step, the interface parameters, originally fixed in the code, are completely externalized, thoroughly separating the interface from the logic implementation. Any subsequent minor adjustments to the interface only require modifying the JSON file and reloading, without recompiling and redeploying the program, greatly improving iteration efficiency and response speed.

[0070] Furthermore, you can also view Figure 5 , Figure 5 This is a detailed process diagram based on step S50 in the first embodiment. Figure 5 The steps of responding to the execution command, loading and parsing the framework optimization configuration file to obtain the page data object, calling the corresponding business component from the component library to render the interface, and generating a dynamic component interface include S51~53: Step S51: When the game starts or hot update is completed, the running instruction is triggered, and the configuration file is loaded and parsed based on the running instruction to obtain the page data object; Step S52: In response to the page generation instruction, the business component corresponding to the page data object is called in the component library through the pre-referenced dependency resolution chain. The dependency resolution chain is referenced through the node tree, loader chain, component binding and business code. The component library includes general components and business components. Step S53: Render the interface using the business component, and generate the dynamic component interface based on the rendering result.

[0071] In the dynamic component interface generation process, triggering the run command is the first step. The timing of triggering the run command is set to occur either upon game startup completion or after the hot update process ends. In game development projects, game startup typically involves resource loading, core module initialization, and entering the main menu. At the final stage of the initialization process, the system checks for the existence of framework optimization configuration files that need to be loaded. If the project supports hot updates, the same loading process will be triggered after the hot update engine completes resource downloads and version switching. This design ensures that whether it's the initial installation and subsequent updates, the interface can be rendered based on the latest configuration file.

[0072] Upon detecting the trigger condition, the system locates the configuration file using the resource management module. The configuration file may be stored in a local persistent path such as `Application.persistentDataPath`, in a read-only directory under `StreamingAssets`, or downloaded from a remote server and cached locally. The system attempts to load the configuration file sequentially based on its priority, for example, prioritizing the latest version downloaded via hot-update; if the latest version is not found, it reverts to the default version built into the package. The loading process is asynchronous to avoid blocking the main thread; execution resumes after loading is complete via callbacks or coroutines. The read configuration file content is a JSON string, which the system passes to a JSON parsing library.

[0073] The JSON parsing library deserializes strings into in-memory page data objects. A page data object is a hierarchical data structure, typically existing as a dictionary or a custom C# class instance. During parsing, the system converts key-value pairs in the JSON into strongly typed property values ​​according to predefined mapping rules. For example, the "panelType" field in the JSON maps to the enumeration type PanelType.Login, and each element in the components array corresponds to a description of a sub-component, including component type, position coordinates, style properties, etc. After parsing, the page data object is cached for use in subsequent UI rendering steps. The entire loading and parsing process records the time taken and potential errors. If the configuration file is corrupted or incorrectly formatted, the system throws an exception and loads an alternative configuration or default interface to ensure the game does not crash.

[0074] After obtaining the page data object, the system needs to respond to the page generation command to actually create the interface. The page generation command can be triggered by various situations, such as a user clicking the "Login" button, or the main interface automatically opening after the scene loads. When the command arrives, the system begins to call the corresponding business components from the component library. The component library is a resource repository that pre-registers all available UI components. The component library is divided into two main categories: general components and business components. General components include basic controls such as buttons, text boxes, sliders, and dropdown lists; these components encapsulate common interaction logic and visual styles. Business components are composed of multiple general components, representing composite controls with specific business functions, such as user information cards, product list items, and purchase pop-ups.

[0075] The process of obtaining a specific component instance from the component library relies on a pre-referenced dependency resolution chain. This chain is a mechanism responsible for resolving the dependencies required by a component at runtime, ensuring that the component can be correctly instantiated and obtain the necessary resources and services. The dependency resolution chain consists of several parts: a node tree maintains the hierarchical relationship of all UI nodes in the current scene, providing parent-child node lookup functionality; a loader chain is a resource loading pipeline that attempts to load component prefabs in the order of local resources, AssetBundles, and remote addresses; a component binder is responsible for binding the loaded prefab instance to parameters in the page data object, applying the configured attribute values ​​to the corresponding fields of the component; and business code references ensure that the component can access global business services, such as the network request manager and user data manager. Through this dependency resolution chain, the system can start from the component type identifier specified in the page data object and ultimately obtain a fully initialized and usable business component instance.

[0076] After obtaining a business component instance, the system does not immediately display it on the screen but temporarily stores it in the rendering queue, awaiting subsequent layout and rendering processing. This process supports batch processing; when multiple components need to be generated simultaneously, the system can resolve dependencies and load resources in parallel, improving rendering efficiency. Simultaneously, the system checks the component cache; for common components that have already been loaded, cached instances are used first to reduce the overhead of repeated loading. Through fine-grained control of the dependency resolution chain, the system achieves on-demand loading and efficient reuse of components, providing a solid foundation for dynamic interface rendering.

[0077] Once the business component instances are ready, the system enters the actual interface rendering phase. The rendering process first requires determining the specific position and size of each component on the screen. The system performs layout calculations on the component instances based on the layout parameters recorded in the page data object. Layout parameters may include absolute coordinates, offset relative to the parent node, anchor point alignment, and specific numerical or proportional values ​​for width and height. The system applies this layout information to the component's RectTransform component, setting its anchor point, pivot, size, and position to complete the component's positioning. For composite business components containing multiple sub-components, the layout process is recursively performed to ensure all child elements are placed according to the design.

[0078] After layout is complete, the system applies style parameters to the visual elements of the component. Style parameters include text color, font size, background image, border style, etc. The system iterates through all stylable parts of the component, assigning values ​​one by one according to the key-value pairs in the page data object. For example, it sets the color of the text component on the button to the "buttonTextColor" value in the configuration, and replaces the source image of the image component with the resource path specified in the configuration. To improve performance, the system uses batch assignment to avoid updating frame by frame. After the styles are applied, the component's appearance is completely consistent with the design.

[0079] Finally, the system registers event listeners for the component based on the interaction parameters. These parameters describe the behaviors the component should trigger when the user interacts with it, such as the event type sent when a button is clicked or the callback function called when the input field changes. The system binds these events to the component's event system. When the user interacts with the interface, the component sends messages through the event mechanism, which are then responded to by the event handlers registered in the system. This event mechanism decouples the component from the business logic; the component only needs to declare which events it can emit, without worrying about who handles them. After rendering, the dynamic component interface is added to the specified parent node of the scene, becoming visible and interactive to the user. The entire process is driven by configuration files; the same component can present completely different appearances and behaviors based on different configurations, achieving a high degree of flexibility and configurability in interface presentation.

[0080] In addition, the above can also be applied to Figure 5 Step S53 is further refined, involving the rendering of the interface through the business component and the generation of the dynamic component interface based on the rendering result, including steps S53-1 to S53-2: Step S53-1: Configure the IComponent interface for the business component. The IComponent interface includes a page initialization callback function and a page lifecycle callback function. Step S53-2: The business component is passed to the dynamic component interface through the IComponent interface to generate the dynamic component interface. When it is determined that the business component is called by the dynamic component interface, the state parameters of the business component are synchronized to the page parameters of the dynamic component through the page initialization callback function. When it is determined that the life cycle state of the dynamic component interface changes, the business component is notified to update its state through the page life cycle callback function. The business component communicates with the outside world through an event mechanism.

[0081] To achieve standardized management and lifecycle control of business components, the system defines a unified interface, IComponent, for all business components. The IComponent interface acts as a contract for the components, specifying the methods implemented by each component and ensuring seamless collaboration between the components and the framework. The interface contains two core callback functions: a page initialization callback function and a page lifecycle callback function. The page initialization callback function is called when the component is added to the dynamic component interface, receiving a parameter object to pass page-level initialization data. The lifecycle callback function corresponds to different state changes of the component, including component startup, pause, resumption, and destruction, allowing the component to execute custom logic at these critical moments.

[0082] At the implementation level, the IComponent interface is defined as a C# interface, and all business component classes must explicitly implement this interface. The page initialization callback function is typically named OnPageInit, which accepts a parameter of type IPageInitData, carrying initialization information from the page data object. Components can set their internal state in OnPageInit, such as refreshing the displayed content based on the passed user information. Page lifecycle callback functions include methods such as OnPageStart, OnPagePause, OnPageResume, and OnPageDestroy, corresponding to the start, pause, resume, and destruction events of the page containing the component, respectively. Through these callbacks, components can perceive changes in the page's lifecycle and make corresponding adjustments, such as stopping animation playback to save performance when the page is paused, and reloading real-time data when the page resumes.

[0083] The interface design also considers the independence and testability of components. Since components depend only on the interface and not on the specific implementation, framework behavior can be easily simulated in unit tests, allowing for independent testing of components. Furthermore, the existence of the IComponent interface allows components to be dynamically loaded and unloaded like plugins; the framework only needs to hold an interface reference to operate on any component without needing to concern itself with its internal details. This interface-based design is the cornerstone of the component-based architecture, providing a unified entry point for subsequent feature expansion and third-party component integration.

[0084] During the dynamic component interface generation process, business components interact with the interface through the IComponent interface. When the system adds a business component instance to the dynamic component interface, it automatically calls the component's OnPageInit method, passing in the parameters from the page data object. Inside the OnPageInit method, the component parses the parameters and updates its own state. For example, a user information card component receives a parameter object containing data such as the user's nickname, avatar URL, and level, and displays this data on the corresponding UI elements. The synchronization of state parameters ensures that the component's initial display is completely consistent with the page's expected state.

[0085] As users interact with the interface or external data changes, the lifecycle state of dynamic component interfaces may change. For example, a user switching to another page may pause the current page, or returning from the background may resume the page. When these state changes occur, the system notifies all business components belonging to that page through the lifecycle callback function of the IComponent interface. Upon receiving the notification, the component executes the corresponding state update logic. For example, when the page is paused, a component that refreshes data in real time stops its timer requests; when the page resumes, it retrieves the latest data and refreshes the display. This synchronization mechanism ensures the consistency between component state and page lifecycle, avoiding display errors or resource waste caused by state lag.

[0086] In addition to lifecycle synchronization, business components also communicate with the outside world through an event mechanism. Components can define and trigger various events, such as button click events, input completion events, and data loading completion events. These events are broadcast through the framework's event system, and any external module that has registered a listener can receive and process them. The event mechanism design eliminates the need for components to directly reference other modules, reducing coupling. For example, after the login button component triggers a login event, the network module listens for the event, executes the login request, and then returns the result to the interface through another event. Components only need to focus on their appearance and interaction; complex business processes are handled by event-driven mechanisms. Through the standardized lifecycle management of the IComponent interface and the event-driven communication model, business components achieve high cohesion and reusability, enabling the flexible combination of various complex dynamic interfaces.

[0087] Furthermore, you can also view 6. Figure 6 This is a flowchart illustrating the second embodiment of the UI framework iterative optimization method of this application. In this embodiment, the UI framework iterative optimization method includes steps S60-S80: Step S60: Configure an independent animation script for the dynamic component interface, and bind the dynamic target object through the independent script; Step S70: Obtain the motion effect parameters of the dynamic target object, modify and debug the motion effect parameters using an editor tool, and obtain the motion effect configuration file; Step S80: Call the motion effect configuration file through the framework interface to be optimized to optimize the motion effect performance.

[0088] After the dynamic component interface is successfully generated, the system further adds animation support to enhance the user experience. First, the system configures an independent animation script for the dynamic component interface. This independent script is a dedicated component responsible for animation playback; it is decoupled from business logic and focuses on controlling the animation's performance. The system adds this script component to the root node of the interface or a specified container and binds a dynamic target object through the script's public interface. The dynamic target object can be any UI element on the interface, such as a button, panel, or text, or even a more complex composite object. The binding process is completed through drag-and-drop or code lookup, assigning a reference to the target object to a target variable in the script. For example, to bind a click-to-zoom animation to the login button, the button object is assigned to the `targetButton` field of the independent script.

[0089] After the animation script is bound to the target object, the system needs to obtain the animation parameters of that target object. Animation parameters include animation types such as translation, rotation, scaling, fade-in / fade-out, animation duration, easing curve, delay time, and loop count. These parameters can be hard-coded in the script or provided through an external configuration file. For ease of debugging and adjustment, the system uses an editor tool to modify and debug the animation parameters. Developers can select the game object with the animation script in the Unity editor, and the adjustable animation parameters will be visible in the Inspector panel. By adjusting the parameters in real time and clicking the preview button, the animation effect can be seen immediately in edit mode without running the game. Once the debugging is satisfactory, the system saves the current parameters as an animation configuration file. This configuration file is stored in JSON format and contains all the key-value pairs of parameters required by the animation script. The filename is usually associated with the interface name, such as LoginPanel_ButtonScale.json.

[0090] After saving the animation configuration file, the system incorporates it into resource management and associates it with the framework interface to be optimized. When the framework interface loads itself at runtime, it reads the corresponding animation configuration file based on the configuration and passes the parameters to the independent animation script. When the page triggers specific events, such as a button click or a panel opening, the script plays the corresponding animation based on the parameters in the configuration file. Because the animation parameters are entirely driven by the configuration file, developers can change the animation's behavior by adjusting the configuration file without modifying the code; for example, they can extend the animation duration, change the easing curve, or add a loop effect. This configurable animation mechanism greatly improves the flexibility and iteration speed of animation adjustments.

[0091] Furthermore, the system supports version management and hot updates for animation configuration files. When designers or artists optimize animation effects, they only need to replace the configuration file on the server, and the game will apply the new effects the next time it starts or is hot-updated, without needing to repackage and release. Simultaneously, the system records performance data for animation playback, such as frame time and memory usage, helping developers assess the impact of animations on performance and adjust parameters as needed to achieve the optimal balance. Through the implementation of steps S60 to S80, the dynamic component interface not only possesses rich animation performance, but the adjustment and optimization of these animations also become lightweight and efficient, powerfully supporting the rapid implementation of complex interaction requirements.

[0092] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the UI framework iterative optimization method of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0093] This application provides a UI framework iteration optimization device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the UI framework iteration optimization method in the above embodiment 1.

[0094] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the UI framework iterative optimization device of the embodiments of this application. The UI framework iterative optimization device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The UI framework iterative optimization device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0095] like Figure 7 As shown, the UI framework iterative optimization device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the UI framework iterative optimization device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the UI framework iteration optimization device to communicate wirelessly or wiredly with other devices to exchange data. While various UI framework iteration optimization devices are shown in the figures, it should be understood that implementation or possession of all of them is not required. More or fewer may be implemented alternatively.

[0096] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0097] The UI framework iteration optimization device provided in this application, employing the UI framework iteration optimization method in the above embodiments, can solve the technical problems of low iteration efficiency and difficulty in guaranteeing quality in existing framework interfaces. Compared with the prior art, the beneficial effects of the UI framework iteration optimization device provided in this application are the same as those of the UI framework iteration optimization method provided in the above embodiments, and other technical features in this UI framework iteration optimization device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0098] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0100] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the UI framework iterative optimization method in the above embodiments.

[0101] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be executed by instructions, used by a device, or used in conjunction with it. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0102] The aforementioned computer-readable storage medium may be included in the UI framework iteration optimization device; or it may exist independently and not assembled into the UI framework iteration optimization device.

[0103] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the UI framework iteration optimization device, the UI framework iteration optimization device implements the technical content of the UI framework iteration optimization method embodiment shown above.

[0104] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using dedicated hardware-based implementations that perform the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions.

[0106] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0107] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described UI framework iterative optimization method. This solves the technical problems of low efficiency and difficulty in guaranteeing the quality of existing framework interface iterations. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the UI framework iterative optimization method provided in the above embodiments, and will not be elaborated upon here.

Claims

1. A method for iterative optimization of a UI framework, characterized in that, The UI framework iterative optimization method includes the following steps: Obtain the framework interface to be refurbished, and determine the UI controls to be replaced in the framework interface by traversing the UI control tree of the framework interface. By using preset UI structure mapping rules, the UI control to be replaced is changed into the corresponding functional code block, and the functional code block is divided into multiple independent code areas according to the functional module division strategy; The interface control script is generated based on each independent code area, and the interface control script is bound to the corresponding UI view resource to generate the revamped framework interface. After performing compatibility conversion on the refurbished framework interface, an editor tool is used to parse the refurbished framework interface, and a framework optimization configuration file is generated based on the parsing results. In response to the execution command, the framework optimization configuration file is loaded and parsed to obtain the page data object. The corresponding business components are called from the component library to render the interface and generate a dynamic component interface.

2. The UI framework iterative optimization method as described in claim 1, characterized in that, The step of changing the UI control to be replaced into a corresponding functional code block according to a preset UI structure mapping rule, and dividing the functional code block into multiple independent code regions according to a functional module division strategy, includes: The function code block corresponding to the UI control is determined according to the preset UI structure mapping rule, and the UI control is replaced in batches with the function code block. In this process, the mapping records of historical renovation projects are obtained, and the frequency of each UI control type being successfully replaced with different function code blocks is counted. The default function code block type corresponding to the UI control type in the UI structure mapping rule is dynamically adjusted according to the frequency, and the adjusted default function code block is given priority when performing UI control replacement. Based on the business function type of the functional code block, add a function identifier to the functional code block according to the preset area division rules, and divide the code area of ​​the framework interface into multiple functional modules through the function identifier; The corresponding function code block is called in the function module using the function identifier to assemble the interface function and generate the interface control script.

3. The UI framework iterative optimization method as described in claim 1, characterized in that, The step of performing compatibility conversion on the refurbished framework interface includes: The magic string parameter in the general key-value pair data class based on CommonDataCollection in the framework interface is converted into a strongly typed property of the page-specific data class, and string, int, and float parameters are passed through the page-specific data class; Register event listeners for the business logic of the framework interface, and replace direct calls to business class methods with sending and receiving events. The state management method of the frame interface is converted to Popup snapshot state management based on the page lifecycle, so that when the pop-up is opened in the frame interface, the state of the pop-up is bound to the lifecycle of the current frame interface, and the pop-up is restored based on the bound state when the frame interface is returned.

4. The UI framework iterative optimization method as described in claim 1, characterized in that, The step of using an editor tool to parse the revamped framework interface and generating a framework optimization configuration file based on the parsing results includes: The visual editor receives parameter configuration operations for the interface elements of the revamped framework interface, and generates the layout parameters, style parameters, and interaction parameters of the interface elements as key-value pair parameters. Save the key-value pair parameters as a JSON-formatted configuration file.

5. The UI framework iterative optimization method as described in claim 1, characterized in that, The steps of responding to the execution command, loading and parsing the framework optimization configuration file to obtain the page data object, calling the corresponding business component from the component library to render the interface, and generating a dynamic component interface include: The running command is triggered when the game starts or a hot update is completed, and the configuration file is loaded and parsed based on the running command to obtain a page data object. In response to the page generation instruction, the business component corresponding to the page data object is called in the component library through the pre-referenced dependency resolution chain. The dependency resolution chain is referenced through node tree, loader chain, component binding and business code. The component library includes general components and business components. The interface is rendered using the business components, and the dynamic component interface is generated based on the rendering results.

6. The UI framework iterative optimization method as described in claim 5, characterized in that, The steps of rendering the interface through the business component and generating the dynamic component interface based on the rendering result include: Configure the IComponent interface for the business component, the IComponent interface including page initialization callback function and page lifecycle callback function; The business component is passed to the dynamic component interface through the IComponent interface to generate the dynamic component interface. When it is determined that the business component is called by the dynamic component interface, the state parameters of the business component are synchronized to the page parameters of the dynamic component through the page initialization callback function. When it is determined that the life cycle state of the dynamic component interface changes, the business component is notified to update its state through the page life cycle callback function. The business component communicates with the outside world through an event mechanism.

7. The UI framework iterative optimization method as described in claim 1, characterized in that, Following the step of generating the dynamic component interface, the method further includes: Configure an independent animation script for the dynamic component interface, and bind the dynamic target object through the independent script; Obtain the animation parameters of the dynamic target object, modify and debug the animation parameters using an editor tool, and obtain the animation configuration file; The animation configuration file is invoked through the framework interface to be optimized to improve the animation performance.

8. The UI framework iterative optimization method as described in claim 1, characterized in that, Before the step of parsing the refurbished framework interface using an editor tool after performing compatibility conversion on the refurbished framework interface, the method further includes: The interface control script is reviewed and repaired by calling a preset AI model via API, and the interface control script is updated based on the repair results. This includes reviewing and repairing the interface control script by calling a preset AI model via API, including: The component code of the interface control script is parsed, and a corresponding code dependency graph is generated based on the parsing results. The code dependency graph contains the reference relationships between classes, methods, and variables. The review prompts are generated based on the code dependency graph and received by the AI ​​model. The component code is reviewed using the review prompts, which instruct the AI ​​model to output optimization suggestions regarding the robustness, readability, and scalability of the code. The review results output by the AI ​​model are analyzed, and a set of optimization suggestions to be executed is generated based on the analysis results. The set of optimization suggestions includes multiple optimization suggestions, and each optimization suggestion includes suggestion type, modification location and modification content. The optimization suggestion set is traversed to execute the optimization suggestion repair component code in the optimization suggestion set, and after the optimization suggestions in the optimization suggestion set have been executed, the framework optimization result is output based on the repaired component code.

9. A UI framework iterative optimization device, characterized in that, The UI framework iterative optimization device stores a computer program, which, when executed by a processor, implements the UI framework iterative optimization method according to any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the UI framework iterative optimization method according to any one of claims 1-8.

Images