Visual API application interface hot loading method and system based on script engine

Abstract

The invention provides a visual API application interface hot loading method and system based on a script engine, and relates to the technical field of computer software developing.The method comprises the steps that runtime state data called by an API is collected and serialized through a core engine, and a state sequence data set is constructed; the hot reloading module generates an API calling dependency graph by using a graph theory dependency analysis algorithm, identifies an affected associated API module, and snapshots state data of the API module in a memory by taking a memory page as a unit; the network communication module receives a hot loading instruction, and the communication reflection module analyzes a target API identifier and parameters in the instruction and determines a loading sequence in combination with the dependency graph; hot loading is executed in sequence, after new codes are loaded, snapshots are read, the integrity is verified, the running state of the associated API module is recovered through memory copying and a register, hot loading can be completed in sequence, the running state of the associated API module can be recovered, and the visual hot loading of the API application interface is achieved.

Description

Technical Field

[0001] This application relates to the field of computer software development technology, and in particular to a method and system for hot-loading visual API application interfaces based on a script engine. Background Technology

[0002] In traditional game engine and visual application development, business logic is often deeply coupled with the engine's underlying code and is mostly written in compiled languages ​​such as C++. This leads to low development efficiency, as modifying business logic requires recompiling the entire project, which is time-consuming; hot updates are difficult, making it impossible to modify logic without restarting the application; debugging is complex, cross-platform compatibility is poor, and the entire team needs to be proficient in C++, limiting the scale of collaboration and making it difficult to meet the needs of efficient development.

[0003] Currently, some solutions introduce scripting engines to provide scripting language support, attempting to reduce dependence on compiled languages, alleviate code coupling issues, and improve development flexibility. While these solutions reduce the frequency of recompilation to some extent, they only address certain pain points and do not form a complete technical system to solve the core problems.

[0004] However, existing script engine solutions have significant shortcomings: script lifecycle management lacks a standardized process, and problems are prone to occur in the initialization, running, and destruction stages; the API reflection mechanism is imperfect and cannot fully expose the engine's functions; hot reloading is unstable and can easily lead to memory leaks or inconsistent states; and it lacks complete MVVM architecture support, with limited data binding capabilities, and still cannot meet the development needs of complex scenarios. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for hot-loading visual API application interfaces based on a script engine, so as to solve the problems of low development efficiency and difficulty in hot updating in the prior art.

[0006] To address the aforementioned technical problems, in a first aspect, this application provides a method for hot-loading a visual API application interface based on a script engine, comprising: The script engine includes a core engine module, a hot reload module, a network communication module, and a communication reflection module; The method includes: A state sequence dataset is constructed by collecting and serializing runtime state data during API application interface calls through the core engine module; By calling a graph theory-based dependency analysis algorithm through the hot reload module, the state sequence data is analyzed, an API call dependency graph is constructed, and the associated API modules affected by the hot reload operation are identified from the API call dependency graph. The runtime state data of the associated API module is divided into snapshot data in memory pages, and the snapshot data is stored in the memory area. The system receives hot-loading instructions from the visual interface via the network communication module, and parses the target API module identifier and loading parameters contained in the hot-loading instructions via the communication reflection module. Combined with the analysis results of the API call dependency graph, the module loading order is determined. According to the module loading order, the hot loading process is controlled to be executed in an orderly manner. After the new API code is loaded, the snapshot data is read from the memory area, the data integrity of the snapshot data is verified, and memory copy and register recovery operations are used to restore the runtime state of the associated API module based on the verified snapshot data.

[0007] Secondly, this application provides a script engine-based visual API application interface hot-loading system, including: The acquisition module is used to collect and serialize runtime state data during API application interface calls by the core engine module in order to build a state sequence dataset. The calling module is used to call a graph theory-based dependency analysis algorithm through the hot reload module to analyze the state sequence data, construct an API call dependency graph, and identify the associated API modules affected by the hot reload operation from the API call dependency graph. The runtime module is used to assemble the runtime state data of the associated API module into snapshot data in memory pages, and store the snapshot data in the memory area. The parsing module is used to receive hot-loading instructions from the visual interface through the network communication module, and to parse the target API module identifier and loading parameters contained in the hot-loading instructions through the communication reflection module. Combined with the analysis results of the API call dependency graph, the module loading order is determined. The verification module is used to control the orderly execution of the hot loading process according to the loading order of the modules. After the new API code is loaded, it reads the snapshot data from the memory area, verifies the data integrity of the snapshot data, and uses memory copy and register recovery operations to restore the runtime state of the associated API module based on the verified snapshot data.

[0008] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor, used to implement the steps of a script engine-based visual API application interface hot-loading method as described in the first aspect above when executing the computer program.

[0009] This application provides a script engine-based visual API hot-loading method. Through a core engine module, it collects and serializes runtime state data during API call processes, constructing a state sequence dataset. This provides complete and structured foundational data support for subsequent dependency analysis, snapshot storage, and state recovery, ensuring the accuracy of state tracking during hot loading. By using a graph theory-based dependency analysis algorithm through a hot reload module, the method analyzes the state sequence data, constructs an API call dependency graph, and identifies related API modules affected by hot loading. This accurately locates the impact range of hot loading operations, avoids redundant processing of unrelated modules, and improves hot loading efficiency. Finally, by assembling snapshot data from the runtime state data of related API modules into memory pages and storing them in memory, the method enables runtime... The efficient preservation of the current state provides a reliable data backup for subsequent state recovery, and the memory page-level storage facilitates fast access and operation. The network communication module receives hot-loading commands from the visual interface, and the communication reflection module parses the target API module identifier and loading parameters in the commands. Combined with the API call dependency graph, the module loading order is determined, ensuring accurate transmission and parsing of hot-loading commands. This ensures the loading process proceeds in an orderly manner according to dependency logic, avoiding conflicts between modules. By controlling the orderly execution of hot loading according to the module loading order, snapshot data is read and its integrity verified after the new API code is loaded. Memory copy and register recovery operations are used to restore the runtime state of the associated API modules, ensuring the stability and security of the hot-loading process. This achieves seamless transition of the running state after API module updates, allowing normal operation to resume without a restart. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating a script engine-based visual API application interface hot-loading method provided in this application embodiment; Figure 2 A scenario diagram illustrating a script engine-based visual API application interface hot-loading method provided in this application embodiment; Figure 3 This is a schematic diagram of a script engine-based visual API application interface hot-loading system provided in an embodiment of this application. Detailed Implementation

[0012] In traditional game engine and visual application development, business logic is deeply bound to the engine's underlying code, and compiled languages ​​such as C++ are commonly used. This not only requires recompiling the entire project to modify the logic, which is time-consuming, but also makes it difficult to update the logic without restarting the application. Furthermore, it presents challenges such as complex debugging, difficulty in cross-platform adaptation, and limited team collaboration. Even though some solutions have introduced script engines to alleviate some of these problems, they still suffer from shortcomings such as the lack of a standard process for script lifecycle management, incomplete API exposure, susceptibility to hot reloading failures, and weak data binding capabilities, failing to meet the development needs of complex scenarios.

[0013] To address the aforementioned issues, this application proposes a visual API application interface hot-loading method based on a script engine. This script engine comprises four main modules: a core engine, hot reload, network communication, and communication reflection. The core engine collects and organizes API runtime status data; the hot reload module analyzes module dependencies; and the network communication and communication reflection modules collaboratively process hot-loading commands and determine the loading order. Finally, the loading is completed in an orderly manner, and the states of associated modules are restored. This method updates API logic without recompiling or restarting the application, solving the problems of low efficiency and difficulty in hot updates in traditional development. It also standardizes the process, improves API function exposure, ensures stable hot loading, compensates for the shortcomings of existing script engines, reduces debugging difficulty through visual operation, and adapts to cross-platform and team collaboration needs.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The core of this application is to provide a method for hot-loading a visual API application interface based on a script engine. The script engine includes a core engine module, a hot reloading module, a network communication module, and a communication reflection module. A flowchart of one specific implementation is shown below. Figure 1 As shown, the method includes: S101. By collecting and serializing runtime state data during API application interface calls through the core engine module, a state sequence dataset is constructed. Optionally, step S101 may specifically include the following steps: S1011. Maintain the system instance registry through the system management unit in the core engine module to monitor the API call process of each system. S1012. Based on the monitored API call process, a serialization processor is used to convert the call stack information, parameter list and context environment data generated during the call process into a binary data stream; S1013. The binary data stream is time-stamped using a timestamp marking unit, and the marked data stream is organized into an ordered state sequence dataset using frame processing technology.

[0016] In the above steps, the core engine module is the core processing unit of the script engine, responsible for the collection, processing, and management of API runtime state data. The system management unit is a sub-unit within the core engine module used to maintain functional system instances and monitor API calls. The functional system instance registry is a list recording information about all functional system instances, including system name, instance references, and API interface lists. The serialization processor is a tool that converts non-binary data during API calls into binary data streams. The call stack information records the API call hierarchy, including the call order, caller, and callee information. The parameter list contains various parameter data passed during API calls, including parameter names, types, and values. The context environment data is the environment information for API runtime, including the current system state and resource usage. The binary data stream is the data format after serialization, facilitating storage and transmission. The timestamp unit is a tool for adding time stamps to data, used to record the time the data was generated. Framing technology is a technique that divides continuous data streams into ordered data frames according to time or data volume. The state sequence dataset is an ordered dataset containing the complete API runtime state after time stamping and framing processing.

[0017] The following is the core code for the core engine module: Build a script engine architecture based on TypeScript / JavaScript, which includes: 1.1 Core Engine Layer (QEngine) (i.e., the core engine module of this application) The QEngine core engine class is designed to use the singleton pattern to manage the entire script system. TypeScript export class QEngine extends Sigleton { public engineData: EngineData private Systems: Array <qsystem>= new Array <qsystem>() / / Engine type identification mechanism static GetInstance(): QEngine { if (global.EngineType === "EditorEngine") { return super.TakeInstance(QEditorEngine) } else if (global.EngineType === "APIEngine") { return super.TakeInstance(QAPIEngine) } return super.TakeInstance(QEngine) } } 1.2 System Management Layer (QSystem) Design an abstract system base class QSystem to define a standardized system lifecycle: - PreInit(): The pre-initialization phase, at which point the Unreal Engine is not yet fully initialized. - Init(): The initialization phase, performing internal system initialization. - PostInit(): The post-initialization phase, which completes the establishment of inter-system dependencies. - BeginPlay(): The runtime phase begins, at which point Unreal Engine objects can be safely accessed. - Tick (DeltaTime): The update phase for each frame, handling real-time logic. - Shutdown(): Shutdown phase, cleans up resources Step 1: Environmental Preparation 1. Install Unreal Engine 4 / 5 development environment 2. Integrate the Puerts plugin into your project 3. Configure the TypeScript compilation environment 4. Set up the project directory structure Step 2: Core Engine Implementation Create the QEngine core engine class (i.e., the core engine module of this application): TypeScript / / QEngine.ts export class QEngine extends Sigleton { public engineData: EngineData private Systems: Array <qsystem>= new Array <qsystem>() constructor(engineType: string) { super() this.engineData = new EngineData(engineType) } / / System creation public CreateSystem(System: QSystem) { let foundSystem = this.Systems.find((inSystem: QSystem) => inSystem.constructor.name === System.constructor.name) if (foundSystem) { WARNING(`${System.constructor.name} has register`) return } if (System && System.ShouldInstantiate()) { this.Systems.push(System) } } / / Lifecycle management public Init(engineType: string) { if (this.engineData.engineType!== engineType) return if (this.engineData.hasInit) return this.engineData.hasInit = true this.PreInit() this.ForEachEverySystem((System) => System.Init()) this.PostInit() } public Tick(DeltaTime: number, engineType: string) { if (this.engineData.engineType !== engineType) return this.ForEachEverySystem((System) =>{ if (System.CanTick()) System.Tick(DeltaTime) }) } } Step 3: Implementation of the system base class Create the QSystem abstract base class: TypeScript / / System.ts export abstract class QSystem { Protected engine: QEngine protected canTick: boolean = false constructor(engine: QEngine) { this.engine = engine this.engine.CreateSystem(this) } / / Lifecycle methods public PreInit() {} public Init() {} public PostInit() {} public BeginPlay() {} public Tick(DeltaTime: number) {} public Shutdown() {} / / System Management public ShouldInstantiate(): boolean { return true} public CanTick() { return this.canTick} protected GetSystem<T extends QSystem>(TClass: TType <t>): T { return this.engine.GetSystem <t>(TClass) } } In this embodiment, step S1011, namely the system management unit in the core engine module, maintains the registry of functional system instances to monitor the API call process of each system. As seen in the code above, the Systems array in the QEngine class (i.e., the core engine module of this application) acts as the registry of functional system instances. The CreateSystem method is responsible for adding instances of QSystem subclasses, such as the character control system and item management system in the game, to the Systems array to avoid duplicate registration. Simultaneously, the Tick method of QEngine iterates through the tickable systems in the Systems array at fixed time intervals, determines their tick status using the CanTick method, and executes their Tick method. During this process, it captures the API call behavior of each system. For example, when the character control system calls the "character movement API," the Tick method monitors this call action and related process data. In game project A, when the QSystem subclass of the character control system (i.e., the system management layer in the script engine) is initialized, it is added to the Systems array through the CreateSystem method. During game runtime, the Tick method of QEngine calls the Tick method of the character control system every frame. When the player operates the character and triggers the "character movement API" call, the system management unit will monitor the API call initiation, parameter passing, execution process and other information, and record it in the monitoring log.

[0018] Secondly, through step S1012, which involves using a serialization processor to convert the call stack information, parameter list, and contextual data generated during the API call process into a binary data stream based on the monitored API call process. After capturing the API call process, the serialization processor first extracts the call stack information, such as the hierarchical relationship of "main program → character control module → character movement API", the parameter list, such as the movement direction "forward" and the movement speed "5m / s", and the contextual data, such as the character's current position "(100,200)" and the current scene resource occupancy rate "30%". Then, using a general serialization algorithm, such as the binary extension of JSON serialization, this structured data is converted into a binary data stream. This format reduces the data volume and facilitates subsequent storage and processing. In game project A, when the "Character Movement API" call is detected, the serialization processor will extract the call stack "game main loop → character control system → character movement API", the parameter list movement direction "forward", movement speed "5m / s", movement duration "2s" and context data, the character's current coordinates "(150,250)" and the current frame rate "60fps", and then convert this data into a binary data stream in the form of "01001011...00110101".

[0019] Next, in step S1013, the binary data stream is time-stamped using timestamp units, and frame processing technology is used to organize the stamped data stream into an ordered state sequence dataset. The timestamp units add a timestamp accurate to milliseconds to each segment of the binary data stream, such as "2024-10-01 14:30:00:123", to clearly define the time sequence of data generation. Then, the frame processing technology divides the timestamped binary data stream into data frames according to a fixed time window or a fixed data volume. Each data frame contains API runtime data within that time period. Finally, these data frames are organized into a state sequence dataset according to the timestamp order, ensuring the orderliness and integrity of the data. In Game A, the timestamp unit adds the timestamp "2024-10-01 14:30:00:123" to the binary data stream corresponding to the "Character Movement API". The frame processing technology integrates the binary data streams corresponding to the "Character Movement API" and "Item Use API" within the time window of 14:30:00:100-14:30:00:200 into a single frame of data, and finally sorts all data frames from earliest to latest according to the timestamp to form a state sequence dataset containing the running status of all APIs within that time period.

[0020] In the overall scheme of step S101 above, an ordered state sequence dataset is constructed through time-series marking and frame-segmentation processing to ensure the timeliness and integrity of the data. This provides accurate and complete basic data support for subsequent dependency analysis, snapshot storage and state recovery, ensuring accurate tracking and processing of API running status during hot loading.

[0021] S102. By calling a graph theory-based dependency analysis algorithm through the hot reload module, the state sequence data is analyzed, an API call dependency graph is constructed, and the associated API modules affected by the hot reload operation are identified from the API call dependency graph. Optionally, step S102 may specifically include the following steps: S1021. Monitor script file system events and detect file change operations through the file monitoring unit in the hot reload module; S1022. Based on the detected file change operations, use a dependency analyzer to parse the call relationship information in the state sequence dataset; S1023. Based on the parsed call relationship information, the relationship between API call nodes and edges is represented by an adjacency list data structure; S1024. Based on the adjacency list data structure, analyze the key nodes in the call path using a depth-first traversal algorithm; S1025. Based on the relevant information of the key nodes, determine the dependency priority between modules using a topology sorting algorithm, and construct an API call dependency graph.

[0022] In the above steps, the hot reload module is the core unit of the script engine responsible for monitoring file changes, analyzing API dependencies, and constructing a dependency graph. The file monitoring unit is a sub-unit within the hot reload module used to monitor script file system events such as file modification, addition, and deletion. Script file system events refer to various state change events that occur to script files in the storage system. File change operations are the specific actions of modifying, adding, or deleting script files. The dependency analyzer is a tool used to parse API call relationships in the state sequence dataset and identify dependencies between modules. The state sequence dataset is an ordered dataset containing API runtime states constructed in step S101, where call relationship information records data such as the call initiator, callee, and call frequency between APIs. The adjacency list data structure is a storage method used to represent graph structures, where each API call node corresponds to a list storing other nodes directly called by that node, thus reflecting the relationship between nodes and edges. The depth-first traversal algorithm is a graph traversal algorithm that starts from the starting node and prioritizes traversing all adjacent nodes of the current node until it is impossible to backtrack further, used to discover key nodes in the call path. Critical nodes are API module nodes that occupy a core position in the API call path and directly affect the call logic of other nodes. Topological sorting is an algorithm for sorting directed acyclic graphs, determining the order of nodes according to their dependencies to clarify the priority of dependencies between modules. An API call dependency graph is a graphical representation of the call dependencies between API modules, containing nodes (API modules) and edges (call relationships), providing a clear visual representation of the dependency relationships between modules.

[0023] The script engine architecture of this application also includes a hot reload module, which includes the following hot reload mechanism.

[0024] The following is a specific example code for the hot reload mechanism: Step 1: File monitoring implementation TypeScript / / HotReloadManager.ts export class HotReloadManager { private fileWatcher: FileWatcher private moduleCache: Map<string, any> = new Map() constructor() { this.fileWatcher = new FileWatcher() this.fileWatcher.onFileChanged = this.onFileChanged.bind(this) } private onFileChanged(filePath: string) { console.log(`File changed: ${filePath}`) this.reloadModule(filePath) } private reloadModule(filePath: string) { try { / / Save the current state const currentState = this.saveSystemState() / / Clear module cache delete require.cache[require.resolve(filePath)] / / Reload module const newModule = require(filePath) / / Restore status this.restoreSystemState(currentState) console.log(`Module reloaded: ${filePath}`) } catch (error) { console.error(`Failed to reload module: ${filePath}`,error) } } } Step 2: State Management Implementation TypeScript / / StateManager.ts export class StateManager { private stateSnapshot: Map<string, any> = new Map() saveState(key: string, state: any) { this.stateSnapshot.set(key, JSON.parse(JSON.stringify(state))) } restoreState(key: string): any { return this.stateSnapshot.get(key) } clearState(key: string) { this.stateSnapshot.delete(key) } } In this embodiment, step S1021, namely the file monitoring unit in the hot reload module, first monitors script file system events to detect file change operations. As seen in the code above, the fileWatcher object in the HotReloadManager class (i.e., the hot reload module of this application) is the file monitoring unit. After initialization in the class constructor, it listens for changes in the state of files in the script file system by binding the onFileChanged method. When any script file, such as an item logic script file in a game, is modified, added, or deleted, fileWatcher captures the corresponding file system event and triggers the onFileChanged method, passing the changed file path as a parameter to complete the detection of file change operations. For example, during the development of game project A, if the developers modify the code content of the "item effect calculation script," the file monitoring unit immediately detects the modification event of the script file, triggers the onFileChanged method, obtains the path of the script file " / scripts / prop / effectCalculate.ts," and clearly detects a file change operation.

[0025] Secondly, in step S1022, based on the detected file change operation, the dependency analyzer parses the call relationship information in the state sequence dataset. After detecting the file change operation and obtaining the path of the changed file, the dependency analyzer first locates the API module corresponding to the changed file, and then extracts all call records related to the API module from the state sequence dataset constructed in step S101. These records include other modules called by the API module, the situations in which it is called by other modules, and the parameter passing information during the call. Subsequently, the dependency analyzer sorts out these call records to identify the direct call relationships between the API module and other API modules, forming a preliminary call relationship list. For example, in game A, after detecting a change to the "item effect calculation script", the dependency analyzer extracts the call records of the "item effect calculation API" corresponding to the script from the state sequence dataset. It finds that this API calls the "character attribute acquisition API" and the "item inventory update API", and is also called by the "item use trigger API", thus sorting out the direct call relationship list between the "item effect calculation API" and these three API modules.

[0026] Next, in step S1023, based on the parsed call relationship information, an adjacency list data structure is used to represent the relationship between API call nodes and edges. After obtaining a preliminary call relationship list, each API module is treated as a call node, and the call relationships between modules are treated as edges. Then, according to the storage rules of the adjacency list, a list is created for each call node, storing the identifiers of all nodes directly called by that node. This establishes the adjacency list, clearly recording the direct call associations between each node and other nodes. For example, in game project A, when constructing the adjacency list based on the call relationship list of "Item Effect Calculation API", the list corresponding to the "Item Effect Calculation API" node will store the node identifiers of "Character Attribute Acquisition API" and "Item Inventory Update API", the list corresponding to the "Item Use Trigger API" node will store the node identifier of "Item Effect Calculation API", and the lists corresponding to the "Character Attribute Acquisition API" and "Item Inventory Update API" nodes will store the corresponding node identifiers according to their call relationships, thus completing the representation of the API call node and edge relationship.

[0027] Then, in step S1024, based on the adjacency list data structure, the key nodes in the call path are analyzed using a depth-first traversal algorithm. After constructing the adjacency list, the depth-first traversal algorithm is started with the API module node corresponding to the detected changed file as the starting node. The algorithm first visits the starting node, and then visits each node in the adjacency list of the starting node in turn. For each visited node, it recursively visits the nodes in its adjacency list until all nodes with direct or indirect call relationships with the starting node have been traversed. During the traversal, the number of times each node is called and its position in the call path are recorded. Nodes with a high number of calls and those located at the intersection of multiple call paths are marked as key nodes. For example, in game project A, a depth-first traversal is initiated starting with the "Item Effect Calculation API" node. First, this node is visited, then the "Character Attribute Acquisition API" in its adjacency list is visited, followed by the "Character Level Judgment API" in the adjacency list of "Character Attribute Acquisition API", and then the "Item Inventory Update API" in the adjacency list of "Item Effect Calculation API" is visited backtracking. After the traversal is completed, it is found that "Item Effect Calculation API" is called by "Item Use Trigger API" and two other APIs are called at the same time. "Character Attribute Acquisition API" is called by multiple effect calculation APIs. Both are marked as key nodes in the call path.

[0028] Finally, in step S1025, based on the relevant information of the key nodes, the dependency priority between modules is determined using the topological sorting algorithm, and an API call dependency graph is constructed. After identifying the key nodes, all nodes related to the changed API modules and their call relationships are collected to form the initial structure of a directed acyclic graph. Then, the topological sorting algorithm is used to sort all nodes according to the call dependencies between nodes. For example, if node A calls node B, then node B depends on node A, and node A has a higher priority than node B. The dependency priority of each node is determined. Then, based on the sorting results and the call relationships in the adjacency list, a complete API call dependency graph is drawn, with nodes representing API modules and directed edges representing call dependencies from the caller to the callee. For example, in game project A, after collecting the APIs "Item Use Trigger API", "Item Effect Calculation API", "Character Attribute Acquisition API", "Item Inventory Update API", and "Character Level Determination API" and their call relationships, the priority order is determined by a topological sorting algorithm as "Character Level Determination API", "Character Attribute Acquisition API", "Item Inventory Update API", "Item Effect Calculation API", and "Item Use Trigger API". Then, using these APIs as nodes, and with directed edges such as "Character Level Determination API" pointing to "Character Attribute Acquisition API" and "Character Attribute Acquisition API" pointing to "Item Effect Calculation API" to represent the call relationships, a complete API call dependency graph is constructed.

[0029] In the overall scheme of step S102 above, the system sorts out the dependencies between API modules, accurately identifies the related API modules that may be affected by the hot loading operation, provides reliable dependency analysis support for the subsequent orderly execution of hot loading and avoidance of module call conflicts, and ensures the stability of the hot loading process.

[0030] Optionally, step S102 further includes the following process: Identifying the associated API modules affected by the hot-reload operation from the API call dependency graph includes: locating the target API module node that has changed using a dependency analyzer based on the API call dependency graph; starting from the target API module node, traversing the API call dependency graph backwards using the adjacency list data structure to identify all upstream calling modules that directly or indirectly depend on the target API module node; simultaneously traversing the API call dependency graph forwards using a depth-first traversal algorithm to identify all downstream called modules that are directly or indirectly depended on by the target API module node; merging the identified upstream calling modules and downstream called modules into a set of affected associated API modules; and sorting the modules in the set of affected API modules according to their dependencies based on the inter-module dependency priority determined by the topology sorting algorithm to generate an ordered list of affected associated API modules.

[0031] In the above steps, the target API module node refers to the node corresponding to the API module that needs to be hot-loaded due to script file changes; it is the starting core node for dependency analysis. The upstream calling module refers to the API module that directly or indirectly calls the target API module node, and its operational logic depends on the functionality of the target API module. The downstream called module refers to the API module that is directly or indirectly called by the target API module node, providing functional support for the target API module. The associated API module set is formed by merging the upstream calling modules and the downstream called modules, and includes all API modules that may be affected by the hot loading of the target API module. The ordered list of associated API modules is an ordered list of modules obtained by sorting the modules in the associated API module set based on the dependency priority determined by topological sorting; it is used to clarify the module processing order during hot loading.

[0032] In this embodiment, firstly, based on the constructed API call dependency graph, the target API module node that has changed is located using a dependency analyzer. The dependency analyzer finds a matching node in the dependency graph based on the API module corresponding to the previously detected file change operation; this node becomes the starting point for subsequent analysis. For example, in game project A, the "Task Reward Calculation API" module corresponding to the file change will be located as the target API module node by the dependency analyzer. Secondly, starting from the target API module node, the API call dependency graph is traversed backwards using an adjacency list data structure. The adjacency list stores the call relationships of each node. Reverse traversal means starting from the target node, finding all nodes that call the target node, and then recursively searching for other nodes that call these nodes, thereby identifying all upstream calling modules that directly or indirectly depend on the target node. For example, traversing backwards from the "Task Reward Calculation API" node will find the "Task Completion Judgment API" that directly calls it, and the "Main Task Management API" that indirectly calls it; these together constitute the upstream calling modules. Simultaneously, a depth-first traversal algorithm is used to traverse the API call dependency graph in a forward direction. Starting from the target node, the nodes directly called by the target node are traversed first, and then other nodes called by these nodes are recursively traversed to identify all downstream called modules that are directly or indirectly dependent on by the target node. For example, a forward traversal from the "Task Reward Calculation API" node will find the "Player Level Detection API" and "Reward Item Configuration Reading API" that it directly calls, as well as the "Player Information Storage API" called by the "Player Level Detection API". These constitute the downstream called modules. Then, the identified upstream calling modules and downstream called modules are merged to form a set of affected related API modules.

[0033] In the complete solution described above, modules are merged into a set and sorted by dependency priority to generate an ordered list. This not only clarifies the module processing order during hot loading but also lays the foundation for subsequent orderly execution of hot loading and avoidance of inter-module call conflicts. It ensures that all related modules can be updated collaboratively during hot loading, maintains the continuity and stability of the system's operating logic, and further improves the reliability and efficiency of hot loading operations.

[0034] S103. The runtime status data of the associated API module is divided into snapshot data in memory pages, and the snapshot data is stored in the memory area. Optionally, step S103 may specifically include the following steps: S1031. Based on the ordered list of the affected associated API modules, each associated API module in the list is traversed sequentially by the state management unit in the hot reload module. S1032. For each associated API module, obtain its runtime memory layout information through the memory management unit to determine the key data areas that need to be saved. S1033. Based on the memory layout information, the key data area is divided into multiple standard memory page units using a memory paging mechanism; S1034. Perform a copy-on-write operation on each memory page unit, set write protection permissions in the memory page table entry, and trigger the page fault exception handling mechanism. S1035. Capture memory access exceptions through the page fault exception handler, copy the original memory page contents to a temporary buffer, and generate a consistent memory snapshot. S1036. Use memory mapping technology to map the snapshot data in the temporary buffer to the non-volatile memory address space; S1037. The mapped snapshot data is atomically committed to the non-volatile memory region through the persistent storage interface of the non-volatile memory controller. S1038, The method further includes: generating an independent CRC32 cyclic redundancy check code for each stored memory page snapshot data, and storing the check code in association with the corresponding snapshot data; establishing a snapshot data index table to record the storage location, size, and timestamp information of each memory page snapshot.

[0035] In the above steps, a page table entry records the memory page's storage address and access permissions. Write protection permissions restrict write operations to memory pages. The page fault exception handling mechanism is the exception handling process triggered by the system when a program accesses a memory page it does not have permission to or that does not exist. The page fault exception handler is the program that executes exception handling logic, used to catch memory access exceptions and perform operations such as data copying. A temporary buffer is memory space that temporarily stores the contents of the original memory page after copying. A consistent memory snapshot is a copy of memory data containing the complete and consistent runtime state of a module. Memory mapping technology is a technique that maps disk files or memory regions to the process address space, enabling direct data access. The non-volatile memory address space is the address range mapped to non-volatile memory, ensuring data is not lost after power failure. The non-volatile memory controller is a hardware or software component that manages non-volatile memory read / write and persistent storage. The persistent storage interface is the interface provided by the controller for permanently saving data to non-volatile memory. Atomicity commit is an operation characteristic that ensures data is either completely saved or not saved at all, preventing data corruption caused by partial writes. CRC32 Cyclic Redundancy Check (CRC32) is a code calculated using the CRC32 algorithm to verify data integrity and detect errors in data transmission or storage. A snapshot data index table is an index list recording the storage location, data size, and generation timestamp of each memory page snapshot, facilitating quick retrieval and management of snapshot data.

[0036] In this embodiment, firstly, through step S1031, based on the ordered list of affected associated API modules, the state management unit in the hot reload module sequentially traverses each associated API module in the list. The state management unit selects associated API modules one by one according to the dependency priority order of the ordered list, ensuring that subsequent data processing follows the dependency logic between modules and avoiding data omissions due to improper processing order. For example, in game project A, the ordered list of associated API modules is "Player Information Storage API", "Player Level Detection API", "Reward Item Configuration Reading API", and "Task Reward Calculation API". The state management unit will start from "Player Information Storage API" and sequentially traverse each module.

[0037] Secondly, through step S1032, for each associated API module, the memory management unit obtains its runtime memory layout information to determine the key data areas that need to be saved. The memory management unit interacts with the system memory management module to read the storage structure information of the currently traversed module in memory, including the address ranges of the data segment and code segment, and filters out the key data areas storing the core state of the module's runtime, excluding redundant data that does not need to be saved. For example, for the "Player Information Storage API", the memory management unit obtains that in its memory layout, the address range 0x1000-0x2000 stores basic player information, and the address range 0x2001-0x3000 stores backpack data. These two address ranges are determined to be key data areas.

[0038] Next, in step S1033, based on the memory layout information, the critical data region is divided into multiple standard memory page units using a memory paging mechanism. The memory paging mechanism divides the critical data region according to the standard memory page size set by the system. If the critical data region size is not an integer multiple of the standard page size, the last page will be padded to the standard page size to ensure that each page is of uniform size, facilitating subsequent batch processing and management. For example, the critical data region of the "Player Information Storage API" is 0x1000-0x2800, with a size of 6KB. When divided according to the 4KB standard page size, it will be divided into two standard memory page units: the first covers 0x1000-0x2000 (4KB), and the second covers 0x2000-0x2800, 2KB, padded to 4KB.

[0039] Then, in step S1034, a copy-on-write operation is performed on each memory page unit, write protection permissions are set in the memory page table entry, and the page fault exception handling mechanism is triggered. The system creates a copy mapping relationship for each memory page unit and modifies the access permission of that page in the memory page table entry to write protection. At this time, if a program attempts to modify the data of that memory page, it will trigger a page fault exception due to insufficient permissions, and then initiate the exception handling process. For example, after performing a copy-on-write operation on the memory page unit of "Player Information Storage API", the write permission of that page in the memory page table entry is closed. When other modules try to modify the player level data in that page, the system immediately triggers a page fault exception.

[0040] Next, in step S1035, the page fault exception handler captures the memory access exception and copies the original memory page content to a temporary buffer, generating a consistent memory snapshot. Upon capturing an exception, the page fault exception handler pauses the current modification operation and then completely copies the original data of the memory page unit to a pre-allocated temporary buffer. During the copying process, read and write operations on the original memory page are prohibited to ensure that the copied data is completely consistent with the module's current running state, forming a consistent snapshot of the memory page. For example, after the exception handler captures an access exception for the "Player Information Storage API" memory page, it completely copies the original data of that page, such as player ID "U001", level "50", and inventory items "P001*3", to the temporary buffer, generating a memory snapshot of the module.

[0041] Next, in step S1036, memory mapping technology is used to map the snapshot data in the temporary buffer to the non-volatile memory address space. Memory mapping establishes a mapping relationship between the temporary buffer and the non-volatile memory address space, allowing the program to access the snapshot data in non-volatile memory like accessing ordinary memory, without needing file I / O operations, thus improving data read / write efficiency. For example, the temporary buffer storing the snapshot data of the "Player Information Storage API" is mapped to the 0x8000-0x9000 address range of non-volatile memory, and subsequent access to this snapshot data can directly operate on the 0x8000-0x9000 address space.

[0042] Subsequently, in step S1037, the mapped snapshot data is atomically committed to the non-volatile memory region via the persistent storage interface of the non-volatile memory controller. The non-volatile memory controller writes the snapshot data from the mapped address space completely into the non-volatile memory through the persistent storage interface. The entire write process is atomic; if a power outage or failure occurs during the process, the data is either completely written or not written at all, preventing data corruption or incompleteness. For example, the controller atomically writes the "Player Information Storage API" snapshot data from the 0x8000-0x9000 address range into a designated area of ​​the non-volatile memory via the interface, ensuring the data is permanently stored and intact.

[0043] Finally, in step S1038, an independent CRC32 cyclic redundancy check code is generated for each stored memory page snapshot data in this embodiment, and the check code is associated with the corresponding snapshot data and stored. A snapshot data index table is established to record the storage location, size, and timestamp information of each memory page snapshot. For each memory page snapshot, a unique check code is calculated using the CRC32 algorithm. The check code and the snapshot data are stored in the same location for subsequent verification of data integrity. At the same time, a snapshot data index table is created, where each record corresponds to a memory page snapshot, including the storage address, data size, and generation timestamp of the snapshot in non-volatile memory, facilitating quick querying and management. For example, the CRC32 check code "0x12345678" is calculated for the memory page snapshot of "Player Information Storage API" and associated with the snapshot data. The index table records the snapshot storage address "0xA000-0xB000", size "4KB", and timestamp "2024-10-0116:30:00:789".

[0044] In the overall solution of step S103 above, the complete, secure and efficient storage of the runtime state of the associated API module is realized, which provides a reliable data foundation for the state recovery after hot loading, ensuring that the module can be accurately restored to the previous running state after hot loading and maintaining the logical continuity of the system.

[0045] S104. Receive hot-loading instructions from the visual interface through the network communication module, and parse the target API module identifier and loading parameters contained in the hot-loading instructions through the communication reflection module. Combine the analysis results of the API call dependency graph to determine the module loading order. Optionally, step S104 may specifically include the following steps: S1041. The instruction parsing unit of the communication reflection module receives and parses the hot-loading instruction from the network communication module, and extracts the target API module identifier, version number information and loading parameter configuration information contained in the instruction. S1042. Based on the target API module identifier, locate the corresponding module node in the API call dependency graph, and query the topological position of the node in the dependency relationship. S1043. Based on the topology of the API call dependency graph, analyze all direct and indirect dependent modules of the target API module and construct a dependency chain; S1044. Based on the loading strategy specified in the loading parameter configuration information and combined with the topological relationship of the dependency chain, determine the priority rules for module loading; S1045. Sort the modules in the dependency chain using a topological sorting algorithm to ensure that each module is loaded after all its dependent modules; S1046. When a circular dependency is detected, a dependency breaking mechanism is used to select the optimal decoupling point and generate an acyclic module loading sequence. S1047. Based on the version number information, verify the module version compatibility, generate version conflict warnings for incompatible modules, and generate a complete hot reloading execution plan that includes module loading order, dependencies, version information and loading parameters.

[0046] In the above steps, the instruction parsing unit is a subunit within the communication reflection module responsible for receiving and parsing hot-loading instructions, extracting key information from them. The target API module identifier is a string or code used to uniquely identify the target API module, facilitating module location in the dependency graph. The version number marks the API module's iterative version, used to verify module compatibility. Loading parameter configuration information consists of parameter settings included in the hot-loading instruction, including loading strategy and timeout. The topological position is the specific location of the module node in the API call dependency graph topology, reflecting the module's dependency hierarchy with other modules. The dependency chain is a chain structure formed by the target API module and all its direct and indirect dependent modules according to their dependency relationships. The loading strategy is the module loading rule specified in the loading parameter configuration information, such as "prioritize loading underlying dependencies" or "incrementally load changed modules." The priority rule is the module loading order determined based on the loading strategy and dependency chain topology. Circular dependency refers to a closed-loop relationship formed by mutual dependence between two or more modules. The dependency breaking mechanism is a technical means to break circular dependencies by selecting decoupling points to decompose the closed loop into linear dependencies. An acyclic module loading sequence is a list of modules loaded in a non-circular order based on dependencies after breaking circular dependencies. Version compatibility verification is the process of checking whether the versions of the module to be loaded match those of existing modules. Version conflict warnings are messages generated when incompatible module versions are detected, informing developers of the conflict. A hot reload execution plan is a complete scheme containing module loading order, dependencies, version information, and loading parameters, guiding the execution of hot reload operations.

[0047] The script engine architecture also includes a communication reflection module, which has an API full reflection mechanism.

[0048] The following is a portion of the core code for a specific example: Step 1: C++ side API processor cpp / / APIHandle.cpp void UAPIHandle::BPCallAPI(FString InClass, FString InFunction,FString InData) { / / Call the script-side API InBlueprintCallAPI.ExecuteIfBound(InClass, InFunction, InData); } FString UAPIHandle::GetAPIModelData(FString APIClass, FString APIId){ if (APIHandleActor != nullptr) { return APIHandleActor->GetModelData(APIClass, APIId); } return ""; } Step 2: Script-side API Registration TypeScript / / APIRegistry.ts export class APIRegistry { private static instance:APIRegistry private apiHandlers: Map<string, Function> = new Map() static getInstance(): APIRegistry { if (!this.instance) { this.instance = new APIRegistry() } return this.instance } registerAPI(className: string, methodName: string, handler:Function) { const key = `${className}.${methodName}` this.apiHandlers.set(key, handler) } callAPI(className: string, methodName: string, data: string):string { const key = `${className}.${methodName}` const handler = this.apiHandlers.get(key) if (handler) { try { const params = JSON.parse(data) const result = handler(params) return JSON.stringify(result) } catch (error) { console.error(`API call failed: ${key}`, error) return JSON.stringify({ error: error.message}) } } return JSON.stringify({ error: `API not found: ${key}`}) } } In this embodiment, step S1041 is first implemented by receiving and parsing the hot-loading instruction from the network communication module through the instruction parsing unit of the communication reflection module. The instruction extracts the target API module identifier, version number, and loading parameter configuration information contained within it. Looking at the code, the `callAPI` method of the `APIRegistry` class (i.e., the communication reflection module of this application, which has an API reflection mechanism) possesses data parsing capabilities. The instruction parsing unit can draw upon its parsing logic, first receiving the hot-loading instruction transmitted from the network communication module, typically in JSON format, and then extracting key information through a parsing algorithm. The target API module identifier is used to locate the module, the version number is used for subsequent compatibility verification, and the loading parameter configuration information clarifies the loading rules. For example, in game project A, the instruction parsing unit receives the hot-load instruction as {"targetAPI":"TaskRewardCalculateAPI","version":"v2.1","loadParams":{"strategy":"loadBottomUp","timeout":3000}}. After parsing, the target API module identifier "TaskRewardCalculateAPI", version number information "v2.1", loading parameter configuration information loading strategy "load from bottom to top", and timeout of 3000 milliseconds are extracted.

[0049] Secondly, through step S1042, which involves locating the corresponding module node in the API call dependency graph based on the target API module identifier and querying the topological position of this node in the dependency relationship. Utilizing the unique mapping relationship between the target API module identifier and nodes in the API call dependency graph, the matching module node is found by traversing the identification information of the nodes in the dependency graph. Then, based on the topological structure of the dependency graph, such as node hierarchy and adjacent node relationships, the dependency hierarchy of this node is determined, clarifying its position in the overall dependency relationship. For example, in game project A, based on the identifier "TaskRewardCalculateAPI", the corresponding module node is located in the dependency graph. A query reveals that this node is at the fourth level of the dependency graph, its directly dependent node is at the third level, and it is directly called by nodes at the second level, thus clarifying the topological position of this node.

[0050] Next, through step S1043, which involves analyzing all direct and indirect dependent modules of the target API module based on the topology of the API call dependency graph, a dependency chain is constructed. Starting from the target API module node, the direct dependent modules that directly call that node are first identified. Then, the dependent modules of these direct dependent modules, i.e., the indirect dependent modules of the target module, are recursively identified. All dependent modules are linked together in the order of "indirect dependent module → direct dependent module → target API module" to form a complete dependency chain. For example, in game project A, the target API module "TaskRewardCalculateAPI" directly depends on "PlayerLevelCheckAPI" and "RewardConfigReadAPI". "PlayerLevelCheckAPI" in turn depends on "PlayerInfoStoreAPI". Therefore, the constructed dependency chain is "PlayerInfoStoreAPI → PlayerLevelCheckAPI → TaskRewardCalculateAPI" and "RewardConfigReadAPI → TaskRewardCalculateAPI".

[0051] Then, through step S1044, which is based on the loading strategy specified in the loading parameter configuration information and combined with the topological relationship of the dependency chain, the priority rules for module loading are determined. First, the loading strategy in the loading parameter configuration information is parsed, and then the hierarchical relationship of the dependency chain is combined, such as the lower-level modules supporting the upper-level modules, to formulate priority rules. If the loading strategy is "load from bottom to top", then the priority rule is "the lower the level of the module in the dependency chain, the higher the loading priority"; if the strategy is "incrementally load changed modules", then the rule is "only load modules whose versions have changed and their direct dependent modules, and the lower-level modules that the changed modules depend on are loaded first". For example, in game project A, the loading strategy is "load from bottom to top", and combined with the dependency chain topology, the priority rule is determined as "PlayerInfoStoreAPI (bottom level) has the highest priority, followed by PlayerLevelCheckAPI and RewardConfigReadAPI, and finally TaskRewardCalculateAPI (target module)".

[0052] Next, step S1045 involves using a topological sorting algorithm to sort the modules in the dependency chain, ensuring that each module is loaded after all its dependent modules. The topological sorting algorithm arranges the modules in order according to the hierarchy and priority rules of the dependency chain. It traverses all modules in the dependency chain, first adding modules without prerequisite dependencies or whose prerequisite dependencies are already sorted to the sequence, and then processing subsequent modules that depend on sorted modules in turn, ultimately obtaining an order that satisfies the condition that "each module is loaded after its dependent modules". For example, in game project A, performing a topological sort on the dependency chain "PlayerInfoStoreAPI→PlayerLevelCheckAPI→TaskRewardCalculateAPI" and "RewardConfigReadAPI→TaskRewardCalculateAPI" results in the loading order "PlayerInfoStoreAPI→PlayerLevelCheckAPI→RewardConfigReadAPI→TaskRewardCalculateAPI", ensuring that "PlayerLevelCheckAPI" is loaded after "PlayerInfoStoreAPI", and "TaskRewardCalculateAPI" is loaded after both "PlayerLevelCheckAPI" and "RewardConfigReadAPI".

[0053] Next, in step S1046, when a circular dependency is detected, a dependency breaking mechanism is used to select the optimal decoupling point and generate an acyclic module loading sequence. First, the constructed dependency chain is traversed to check for closed-loop relationships such as "module A depends on module B, and module B depends on module A." If a circular dependency exists, the dependency breaking mechanism analyzes the functional independence and call frequency of each module in the loop, selecting a relatively independent module with a low call frequency as the decoupling point. In the loading sequence, the dependency of this module on other modules in the loop is temporarily broken, prioritizing the loading of modules outside the loop and non-decoupling point modules within the loop. After the core module is loaded, the decoupling point module is loaded, generating an acyclic sequence. For example, in game project A, if a circular dependency is detected where "TaskRewardCalculateAPI" depends on "TaskProgressCheckAPI", and "TaskProgressCheckAPI" in turn depends on "TaskRewardCalculateAPI", analysis reveals that "TaskProgressCheckAPI" is relatively independent and has a low call frequency. Therefore, it is set as the decoupling point, generating an acyclic loading sequence: "PlayerInfoStoreAPI→PlayerLevelCheckAPI→RewardConfigReadAPI→TaskRewardCalculateAPI→TaskProgressCheckAPI".

[0054] Finally, step S1047 verifies module version compatibility based on version number information, generates version conflict warnings for incompatible modules, and generates a complete hot-load execution plan containing module loading order, dependencies, version information, and loading parameters. First, the current version and the version to be loaded for each module in the dependency chain are obtained. A version comparison algorithm, such as semantic version comparison, is used to check if the major and minor version numbers match to verify compatibility. If the major version number of the module to be loaded is inconsistent with the major version number of the current module, incompatibility is determined, and a version conflict warning is generated, including the conflicting module name, current version, and version to be loaded. Then, the previously determined loading order, dependencies in the dependency chain, module version information, and loading parameter configuration information are integrated to form a complete hot-load execution plan. For example, in game project A, verification revealed that the current version of "RewardConfigReadAPI" is "v1.8", while the version to be loaded is "v2.1". The major version numbers are consistent, indicating compatibility. The current version of "PlayerInfoStoreAPI" is "v2.0", which is compatible with the version to be loaded "v2.1", with no conflict warning. The final generated hot reload execution plan includes the loading order "PlayerInfoStoreAPI→PlayerLevelCheckAPI→RewardConfigReadAPI→TaskRewardCalculateAPI", the dependencies of each module, version information such as "TaskRewardCalculateAPI" v2.1, and loading parameters such as loading strategy and timeout.

[0055] In the overall scheme of step S104 above, key information for hot loading is accurately extracted through instruction parsing, laying the foundation for subsequent operations; dependency graph location and dependency chain construction clearly sort out the dependency relationships between modules; priority rule formulation and topology sorting ensure that the module loading order conforms to the dependency logic; circular dependency handling and version compatibility verification improve the stability and security of the loading process; and the finally generated complete hot loading execution plan provides a clear and executable solution for hot loading operations, avoiding hot loading failures due to chaotic loading order or version conflicts, and ensuring that the hot loading process is orderly, efficient, and stable.

[0056] S105. According to the module loading order, control the orderly execution of the hot loading process. After the new API code is loaded, read the snapshot data from the memory area, verify the data integrity of the snapshot data, and use memory copy and register recovery operations to restore the runtime state of the associated API module based on the verified snapshot data.

[0057] Optionally, step S105 may specifically include the following steps: S1051. Read the snapshot data and corresponding checksum stored in the non-volatile memory area; S1052. Perform cyclic redundancy check calculation on the snapshot data, compare the calculation result with the check code to verify data integrity. If the verification fails, trigger the data retransmission mechanism to retrieve the snapshot data from the backup storage area again. If the verification passes, start the direct memory access controller. S1053. The verified snapshot data is directly transferred to the target memory address space in units of memory pages through the DMA controller. After the data transfer is completed, the processor and register status information, including the values ​​of general-purpose registers, status registers and program counter, is extracted from the snapshot data through the register recovery unit. S1054. Use atomic operation instruction sequence to restore the extracted register state information to the corresponding register of the target processor, and rebuild the runtime context of the associated API module, including restoring the stack pointer, frame pointer and thread local storage data. S1055. Update the module status flag to notify that the runtime state recovery of the MVVM architecture module has been completed, triggering the interface update process.

[0058] In the above steps, Cyclic Redundancy Check (CRC) calculation is the process of calculating a check value for verifying data integrity using a specific algorithm on the snapshot data. The data retransmission mechanism is a mechanism to retrieve complete snapshot data from the backup storage area when snapshot data verification fails, ensuring usable data is available. The backup storage area is a dedicated area for storing snapshot data backups, independent of the main storage area, and used for data recovery. The Direct Memory Access Controller (DMI) is a hardware or software component that transfers data directly between memory and the device without CPU intervention, improving data transfer efficiency. The target memory address space is the range of memory addresses used to store the recovered snapshot data, consistent with the memory addresses used by the associated API module during runtime. The register recovery unit is a subunit responsible for extracting register status information from the snapshot data and restoring it to the corresponding registers. General-purpose registers are registers used for temporary storage of operational data and addresses; the status register records the processor status; and the program counter value records the address of the next instruction to be executed. The atomic operation instruction sequence is a set of instructions that ensures the register status recovery process is uninterrupted, preventing data interference during recovery. The runtime context is the complete environment information required for the associated API module to run, including the stack pointer, frame pointer, and thread-local storage data. The stack pointer records the current position in the stack memory, the frame pointer identifies the position of the current function call stack frame, and thread-local storage data is exclusive data accessible only to the current thread. Module state flags are identifiers used to mark the state of the associated API module. The MVVM architecture module is an architectural component that implements the separation of data and view, and can trigger UI updates based on changes in module state. The UI update process is the process of synchronously updating the content displayed on the visual interface after the module's runtime state has been restored.

[0059] In this embodiment, step S1051 first reads the snapshot data and corresponding checksum stored in the non-volatile memory area. Looking at the code, the `restoreState` method of the `StateManager` class has the basic logic for reading stored snapshot data. This step, based on this logic, uses the read interface of the non-volatile memory controller to locate the snapshot data and its CRC32 checksum corresponding to the associated API module according to the storage location recorded in the snapshot data index table. Both are then completely read into the memory buffer, preparing for subsequent integrity verification. For example, in game A, based on the snapshot storage address "0xA000-0xB000" of "PlayerInfoStoreAPI" recorded in the index table, the snapshot data of this module, including player ID "U001", level "50", and the corresponding checksum "0x12345678", is read from the non-volatile memory area.

[0060] Secondly, in step S1052, a cyclic redundancy check (CRC) calculation is performed on the snapshot data. The calculation result is compared with the checksum to verify data integrity. If the verification fails, a data retransmission mechanism is triggered to retrieve the snapshot data from the backup storage area. If the verification passes, the direct memory access controller (DMA controller) is started. First, the CRC32 algorithm, consistent with that used when the snapshot was generated, is used to calculate the current checksum on the read snapshot data to obtain the current checksum value. Then, the current checksum value is compared with the original checksum. If they match, the data is considered intact and undamaged, and the DMA controller is started to prepare for data transfer. If they do not match, the data is considered corrupted, and the data retransmission mechanism is triggered. Based on the address information of the backup storage area, the backup snapshot data and checksum of this module are reread, and the verification process is repeated until complete data is obtained. For example, in game project A, a CRC32 calculation is performed on the snapshot data of "PlayerInfoStoreAPI". If the result is "0x12345678", which is consistent with the original checksum, the verification passes and the DMA controller is started; if the calculation result is "0x87654321", which is inconsistent with the original checksum, the data retransmission mechanism is triggered, and the snapshot data and checksum of "PlayerInfoStoreAPI" are reread from the backup storage area.

[0061] Next, in step S1053, the DMA controller directly transfers the verified snapshot data to the target memory address space in units of memory pages. After the data transfer is complete, the register recovery unit extracts processor and register status information, including general-purpose registers, status registers, and program counter values, from the snapshot data. The DMA controller transfers the snapshot data directly from the current buffer to the target memory address space corresponding to the runtime of the associated API module, according to the memory page division. The entire process does not require CPU involvement, reducing resource consumption. After the transfer is complete, the register recovery unit parses the fields in the snapshot data that specifically store register information, extracting the temporary operation data stored in the general-purpose registers, the operation flags in the status register such as whether there is a carry or overflow, and the address of the next instruction recorded by the program counter. For example, in game A, the DMA controller transfers the snapshot data of "PlayerInfoStoreAPI" to the target address space "0x1000-0x2000" by memory pages; the register recovery unit extracts data such as "player level 50" and "item quantity in backpack 3" stored in the general-purpose register from the snapshot data, the "no overflow" flag recorded in the status register, and the program counter value "0x00001234".

[0062] Then, in step S1054, the extracted register state information is restored to the corresponding registers of the target processor using an atomic operation instruction sequence, and the runtime context of the associated API module is reconstructed, including restoring the stack pointer, frame pointer, and thread-local storage data. The atomic operation instruction sequence ensures that the register state restoration process is executed continuously without being interrupted by other instructions. First, the extracted general-purpose register data is written to the corresponding general-purpose register, then the status register information is updated to the target status register, and finally the program counter is set to the extracted value. At the same time, the recorded values ​​of the stack pointer and frame pointer are read from the snapshot data and updated to the corresponding memory pointer registers, respectively. The thread data specific to this module is extracted from the thread-local storage data field and written to the thread-local storage area, completing the reconstruction of the runtime context environment. For example, in game A, atomic operation instructions write the general-purpose register data of "PlayerInfoStoreAPI" to the corresponding register, set the status register to "no arithmetic overflow", and the program counter to "0x00001234"; restore the stack pointer to "0x30000000", restore the frame pointer to "0x30000100", and write the thread-local storage data "player thread identifier T001" to the corresponding storage area.

[0063] Finally, step S1055, which updates the module status flag, notifies the MVVM architecture module that the runtime state recovery is complete, triggering the interface update process. First, the status flag of the associated API module is updated from "Recovering" to "Recovery Completed," informing the system that the module is now running normally. Then, the message notification mechanism sends the information about the completed recovery to the MVVM architecture module. Upon receiving the notification, the MVVM architecture module automatically updates the corresponding display content in the visualization interface, such as the level number in the player information panel and the number of item icons in the inventory, based on the restored runtime data, such as the player level and inventory data in "PlayerInfoStoreAPI," thus synchronizing the interface with the data. For example, in game A, after updating the status flag of "PlayerInfoStoreAPI" to "Recovery Completed" and notifying the MVVM architecture module, the player information panel in the interface automatically updates the level display from "Loading" to "50," and the quantity display of the "P001" item in the inventory from "Loading" to "3."

[0064] In the overall scheme of step S105 above, the integrity and availability of snapshot data are ensured through cyclic redundancy check and data retransmission mechanisms, avoiding abnormal state recovery due to data corruption; the DMA controller reduces CPU resource consumption and improves transmission efficiency when transmitting data; register state recovery and context environment reconstruction ensure that the associated API module can accurately recover to its running state before hot loading; module state updates and interface synchronization realize the linkage between data and the visualization interface, allowing users to obtain information after state recovery in a timely manner. The entire process achieves safe and accurate recovery of the runtime state of the associated API module, ensuring that the module can seamlessly connect to the previous running logic after hot loading, maintaining the continuity and stability of system functions, and improving the user experience.

[0065] The following is a complete embodiment for steps S101 to S105: like Figure 2 As shown, taking the hot reloading of the "Task Reward Calculation API" in game project A as an example, this project uses a script engine that includes a core engine module, a hot reload module, a network communication module, and a communication reflection module. First, the core engine module collects runtime state data during the "Task Reward Calculation API" call process, including the call stack of "Game Main Loop → Task System → Task Reward Calculation API", a parameter list with task ID T001 and player level 50, and context data indicating the current task progress is 100%. After serialization, a state sequence dataset is constructed. Next, the hot reload module calls a graph-based dependency analysis algorithm to parse the state sequence data and construct an API call dependency graph. From this graph, the associated API modules of the "Task Reward Calculation API" are identified, including the upstream "Task Completion Judgment API" and the downstream "Player Backpack Management API" and "Reward Item Configuration API". Subsequently, the runtime state data of these associated API modules are grouped into snapshot data in memory pages and stored in a non-volatile memory area. After the developers initiate a hot-load command through the visual interface, the network communication module receives the command. The communication reflection module parses the target API module identifier "Task Reward Calculation API" and loading parameters from the command. The loading parameters prioritize loading underlying dependencies. Based on the analysis results of the API call dependency graph, the module loading order is determined to be "Reward Item Configuration API → Player Inventory Management API → Task Reward Calculation API → Task Completion Judgment API". Finally, the hot-load process is controlled to execute in an orderly manner according to the determined module loading order. After the new API code is loaded, snapshot data is read from the memory area, and the data integrity is verified by the CRC32 algorithm. After successful verification, memory copy and register recovery operations are used to accurately restore the runtime state of the "Player Inventory Management API" item quantity, the "Task Reward Calculation API" reward rules, etc. The entire hot-load process does not require restarting the game, and players can view task rewards normally.

[0066] The script engine-based visual API hot-loading method provided in this application achieves comprehensive collection and serialization of API runtime states through the core engine module, laying a data foundation for subsequent dependency analysis; the graph theory analysis algorithm of the hot reload module accurately identifies related modules, preventing the scope of hot loading from expanding; memory page-level snapshot storage ensures the security of state data; network communication and communication reflection modules work together to ensure accurate parsing of hot-loading instructions and reasonable loading order; integrity verification and state recovery operations achieve seamless connection of runtime states of related modules. The entire process can complete API hot loading without restarting the application, significantly improving development efficiency while ensuring system continuity and stability, reducing debugging and maintenance costs, and adapting to the development needs of large-scale visual applications.

[0067] Figure 3 This application provides a schematic diagram illustrating a specific implementation of a script engine-based visual API application interface hot-loading system, with reference to... Figure 3 The system may include: The acquisition module 31 is used to collect and serialize runtime state data during API application interface calls by the core engine module in order to build a state sequence dataset. Call module 32 is used to call a graph theory-based dependency analysis algorithm through the hot reload module to analyze the state sequence data, construct an API call dependency graph, and identify the associated API modules affected by the hot reload operation from the API call dependency graph. The running module 33 is used to assemble the runtime state data of the associated API module into snapshot data in memory pages, and store the snapshot data in the memory area; The parsing module 34 is used to receive hot-loading instructions from the visual interface through the network communication module, and to parse the target API module identifier and loading parameters contained in the hot-loading instructions through the communication reflection module. Combined with the analysis results of the API call dependency graph, the module loading order is determined. The verification module 35 is used to control the orderly execution of the hot loading process according to the loading order of the modules. After the new API code is loaded, it reads the snapshot data from the memory area, verifies the data integrity of the snapshot data, and uses memory copy and register recovery operations to restore the runtime state of the associated API module based on the verified snapshot data.

[0068] The script engine-based visual API application interface hot-loading system of this application embodiment is used to implement the aforementioned script engine-based visual API application interface hot-loading method. Therefore, the specific implementation of the script engine-based visual API application interface hot-loading system can be found in the embodiment section of the script engine-based visual API application interface hot-loading method above. The specific implementation can be referred to the description of the corresponding embodiment, and will not be repeated here.

[0069] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the script engine-based visual API application interface hot-loading method described above when executing the computer program.

[0070] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-described script engine-based visual API application interface hot-loading methods.

[0071] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0072] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the script engine-based visual API application interface hot-loading method.

[0073] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0074] The foregoing has provided a detailed description of a script engine-based visual API application interface hot-loading method and system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.< / t> < / t> < / qsystem> < / qsystem> < / qsystem> < / qsystem>

Claims

1. A method for hot-loading a visual API application interface based on a script engine, characterized in that, The script engine includes a core engine module, a hot reload module, a network communication module, and a communication reflection module; The method includes: A state sequence dataset is constructed by collecting and serializing runtime state data during API application interface calls through the core engine module; By calling a graph theory-based dependency analysis algorithm through the hot reload module, the state sequence data is analyzed, an API call dependency graph is constructed, and the associated API modules affected by the hot reload operation are identified from the API call dependency graph. The runtime state data of the associated API module is divided into snapshot data in memory pages, and the snapshot data is stored in the memory area. The system receives hot-loading instructions from the visual interface via the network communication module, and parses the target API module identifier and loading parameters contained in the hot-loading instructions via the communication reflection module. Combined with the analysis results of the API call dependency graph, the module loading order is determined. According to the module loading order, the hot loading process is controlled to be executed in an orderly manner. After the new API code is loaded, the snapshot data is read from the memory area, the data integrity of the snapshot data is verified, and memory copy and register recovery operations are used to restore the runtime state of the associated API module based on the verified snapshot data.

2. The method according to claim 1, characterized in that, The script engine also includes an MVVM architecture module; after verifying the data integrity of the snapshot data and restoring the runtime state of the associated API module based on the verified snapshot data using memory copy and register recovery operations, it further includes: Establish a data binding channel between the view model unit in the MVVM architecture module and the visual interface, and listen for runtime state recovery completion events; The state change information of the restored runtime state is captured through a reactive data proxy mechanism; Based on the captured state change information, an attribute change notification is used to send an interface update instruction to the view layer; The interface update command is parsed by the data binding parser, and the corresponding data binding elements in the visualization interface are updated to provide feedback on the hot reloading result.

3. The method according to claim 1, characterized in that, The process of collecting and serializing runtime state data during API application interface calls by the core engine module to construct a state sequence dataset includes: The system instance registry is maintained through the system management unit in the core engine module, and the API call process of each system is monitored. Based on the monitored API call process, a serialization processor is used to convert the call stack information, parameter list and context environment data generated during the call into a binary data stream; The binary data stream is time-stamped using timestamp marking units, and the marked data stream is organized into an ordered state sequence dataset using frame processing technology.

4. The method according to claim 1, characterized in that, The process of using a graph theory-based dependency analysis algorithm via the hot reload module to analyze state sequence data and construct an API call dependency graph includes: The file monitoring unit in the hot reload module monitors script file system events and detects file change operations. Based on the detected file change operations, the call relationship information in the state sequence dataset is parsed using a dependency analyzer. Based on the parsed call relationship information, an adjacency list data structure is used to represent the relationship between API call nodes and edges; Based on the adjacency list data structure, the key nodes in the call path are analyzed using a depth-first traversal algorithm; Based on the relevant information of the key nodes, the dependency priority between modules is determined using a topology sorting algorithm, and an API call dependency graph is constructed.

5. The method according to claim 4, characterized in that, Identify the associated API modules affected by the hot reload operation from the API call dependency graph, including: Based on the API call dependency graph, the target API module node that has changed is located using the dependency analyzer. Starting from the target API module node, the API call dependency graph is traversed in reverse through the adjacency list data structure to identify all upstream calling modules that directly or indirectly depend on the target API module node; At the same time, the API call dependency graph is traversed forward by a depth-first traversal algorithm to identify all downstream called modules that are directly or indirectly dependent on the target API module node; The identified upstream calling modules and downstream called modules are merged into a set of affected associated API modules; Based on the inter-module dependency priority determined by the topology sorting algorithm, the modules in the set of associated API modules are sorted according to their dependencies to generate an ordered list of affected associated API modules.

6. The method according to claim 5, characterized in that, The hot-loading module assembles the runtime state data of the associated API module into snapshot data, using memory pages as units, and stores the snapshot data in the memory area, including: Based on the ordered list of affected associated API modules, each associated API module in the list is traversed sequentially by the state management unit in the hot reload module. For each associated API module, its runtime memory layout information is obtained through the memory management unit to determine the key data areas that need to be saved. Based on the memory layout information, the key data area is divided into multiple standard memory page units using a memory paging mechanism. Perform a copy-on-write operation on each memory page unit, set write protection permissions in the memory page table entry, and trigger the page fault exception handling mechanism; Memory access exceptions are captured by the page fault exception handler, the original memory page contents are copied to a temporary buffer, and a consistent memory snapshot is generated. Memory mapping technology is used to map snapshot data in a temporary buffer to a non-volatile memory address space; The mapped snapshot data is atomically committed to the non-volatile memory region through the persistent storage interface of the non-volatile memory controller. The method further includes: Generate an independent CRC32 cyclic redundancy check code for each stored memory page snapshot data, and associate the check code with the corresponding snapshot data for storage; Create a snapshot data index table to record the storage location, size, and timestamp information of each memory page snapshot.

7. The method according to claim 1, characterized in that, The process involves parsing the target API module identifier and loading parameters contained in the hot-loading instruction using the communication reflection module, and combining this with the analysis results of the API call dependency graph to determine the module loading order, including: The instruction parsing unit of the communication reflection module receives and parses the hot-loading instruction from the network communication module, and extracts the target API module identifier, version number information and loading parameter configuration information contained in the instruction; Based on the target API module identifier, locate the corresponding module node in the API call dependency graph and query the topological position of the node in the dependency relationship; Based on the topology of the API call dependency graph, analyze all direct and indirect dependent modules of the target API module and construct a dependency chain; Based on the loading strategy specified in the loading parameter configuration information and combined with the topological relationship of the dependency chain, the priority rules for module loading are determined. The modules in the dependency chain are sorted using a topological sorting algorithm to ensure that each module is loaded after all its dependent modules. When a circular dependency is detected, a dependency breaking mechanism is used to select the optimal decoupling point and generate an acyclic module loading sequence. Based on the version number information, verify module version compatibility, generate version conflict warnings for incompatible modules, and generate a complete hot reload execution plan that includes module loading order, dependencies, version information, and loading parameters.

8. The method according to claim 1, characterized in that, The process of verifying the data integrity of the snapshot data and restoring the runtime state of the associated API module based on the verified snapshot data includes: Read the snapshot data and corresponding checksum stored in the non-volatile memory area; Cyclic redundancy check (CR) calculations are performed on the snapshot data, and the calculation results are compared with the checksum to verify data integrity. If the verification fails, a data retransmission mechanism is triggered to retrieve the snapshot data from the backup storage area. If the verification passes, the direct memory access controller is started. The DMA controller directly transfers the verified snapshot data to the target memory address space in units of memory pages. After the data transfer is completed, the register recovery unit extracts the processor and register status information from the snapshot data, including the values ​​of general-purpose registers, status registers, and program counter. The extracted register state information is restored to the corresponding registers of the target processor using a sequence of atomic operation instructions, and the runtime context of the associated API module is rebuilt, including the restoration of the stack pointer, frame pointer and thread-local storage data. Update the module status flags to notify that the runtime state recovery of the MVVM architecture module is complete, triggering the interface update process.

9. A script engine-based visual API application interface hot-loading system, characterized in that, include: The acquisition module is used to collect and serialize runtime state data during API application interface calls by the core engine module in order to build a state sequence dataset. The calling module is used to call a graph theory-based dependency analysis algorithm through the hot reload module to analyze the state sequence data, construct an API call dependency graph, and identify the associated API modules affected by the hot reload operation from the API call dependency graph. The runtime module is used to assemble the runtime state data of the associated API module into snapshot data in memory pages, and store the snapshot data in the memory area. The parsing module is used to receive hot-loading instructions from the visual interface through the network communication module, and to parse the target API module identifier and loading parameters contained in the hot-loading instructions through the communication reflection module. Combined with the analysis results of the API call dependency graph, the module loading order is determined. The verification module is used to control the orderly execution of the hot loading process according to the loading order of the modules. After the new API code is loaded, it reads the snapshot data from the memory area, verifies the data integrity of the snapshot data, and uses memory copy and register recovery operations to restore the runtime state of the associated API module based on the verified snapshot data.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the script engine-based visual API application interface hot-loading method as described in any one of claims 1 to 8 when executing the computer program.

Images