A visual API application interface hot loading method and system based on a script engine

Abstract

The application provides a script engine-based visual API application interface hot loading method and system, and relates to the technical field of computer software development. The core engine collects and serializes runtime state data of API calling to build a state sequence dataset. A hot reloading module generates an API calling dependency graph using a graph theory dependency analysis algorithm, identifies affected associated API modules, and takes snapshots of the state data of the modules in memory in units of memory pages. A network communication module receives a hot loading instruction, a communication reflection module analyzes target API identifiers and parameters in the instruction, and determines a loading sequence in combination with the dependency graph. The hot loading is performed in sequence, the snapshot is read and integrity is verified after the new code is loaded, and the runtime state of the associated API modules is restored through memory copying and register restoration. The API application interface visual hot loading is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software development, and in particular to a visual API application interface hot loading method and system based on a script engine. BACKGROUND

[0002] In traditional game engines and visual application development, business logic is often deeply coupled with engine underlying code, and is usually written in compiled languages such as C++. This results in low development efficiency, as modifying business logic requires recompiling the entire project, which is time-consuming. Hot updates are difficult to implement, as logic cannot be modified without restarting the application. Debugging is complex, cross-platform compatibility is poor, and the entire team needs to master C++, which limits collaboration size and makes it difficult to meet the needs of efficient development.

[0003] Currently, some solutions introduce script engines to provide script language support, in an attempt 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 some pain points and do not form a complete technical system to solve the core problem.

[0004] However, existing script engine solutions have obvious shortcomings: the script lifecycle management lacks standardized processes, and initialization, running, and destruction stages are prone to problems. The API reflection mechanism is not perfect and cannot fully expose engine functionality. Hot loading is unstable and can easily cause memory leaks or state inconsistencies. Moreover, there is a lack of complete MVVM architecture support, and data binding capabilities are limited, making it still difficult to meet the development needs of complex scenarios. SUMMARY

[0005] The present application aims to provide a visual API application interface hot loading method and system based on a script engine to solve the problems of low development efficiency and difficult hot updates in the prior art.

[0006] To solve the above technical problems, in a first aspect, the present application provides a visual API application interface hot loading method based on a script engine, comprising:

[0007] The script engine includes a core engine module, a hot reloading module, a network communication module, and a communication reflection module.

[0008] The method comprises:

[0009] The runtime state data during API application interface calling is collected and serialized by the core engine module to construct a state sequence dataset.

[0010] The state sequence data is analyzed by calling a graph theory-based dependency analysis algorithm through a hot reloading module, an API calling dependency graph is constructed, and an associated API module affected by a hot loading operation is identified from the API calling dependency graph;

[0011] The runtime state data of the associated API module is composed into snapshot data in units of memory pages, and the snapshot data is stored to a memory area;

[0012] A target API module identifier and loading parameters contained in the hot loading instruction are parsed through a communication reflection module, a module loading sequence is determined in combination with an analysis result of the API calling dependency graph, by receiving a hot loading instruction from a visual interface through a network communication module;

[0013] According to the module loading sequence, an ordered execution of a hot loading process is controlled, after new API code loading is completed, the snapshot data is read from the memory area, data integrity of the snapshot data is verified, and a runtime state of the associated API module is restored based on the verified snapshot data by using memory copying and register recovery operations.

[0014] In a second aspect, the application provides a visual API application interface hot loading system based on a script engine, comprising:

[0015] A collection module is configured to collect and serialize runtime state data in an API application interface calling process by a core engine module to construct a state sequence data set;

[0016] A calling module is configured to analyze the state sequence data by calling a graph theory-based dependency analysis algorithm through a hot reloading module, construct an API calling dependency graph, and identify an associated API module affected by a hot loading operation from the API calling dependency graph;

[0017] A running module is configured to compose the runtime state data of the associated API module into snapshot data in units of memory pages, and store the snapshot data to a memory area;

[0018] A parsing module is configured to receive a hot loading instruction from a visual interface through a network communication module, parse a target API module identifier and loading parameters contained in the hot loading instruction through a communication reflection module, and determine a module loading sequence in combination with an analysis result of the API calling dependency graph;

[0019] A verification module is configured to control the sequential execution of the hot loading process according to the module loading sequence, read the snapshot data from the memory region after the new API code loading is completed, verify the data integrity of the snapshot data, and restore the runtime state of the associated API module based on the verified snapshot data using memory copying and register recovery operations.

[0020] In a third aspect, the present application provides an electronic device, comprising:

[0021] A memory is configured to store a computer program.

[0022] A processor is configured to implement the steps of the script engine-based visual API application interface hot loading method according to the first aspect when executing the computer program.

[0023] The script engine-based visual API application interface hot loading method provided by the present application can collect and serialize the runtime state data in the API application interface calling process through the core engine module, construct a state sequence dataset, provide complete and structured basic data support for subsequent dependency analysis, snapshot storage and state recovery, and ensure the accuracy of state tracking in the hot loading process. The dependency analysis algorithm based on graph theory is called through the hot reloading module to analyze the state sequence data, construct an API calling dependency graph and identify the associated API module affected by the hot loading, accurately locate the influence range of the hot loading operation, avoid redundant processing of irrelevant modules, and improve the hot loading efficiency. The runtime state data of the associated API module is stored in the memory region in the form of memory pages to form snapshot data, which can realize efficient saving of the runtime state, provide reliable data backup for subsequent state recovery, and facilitate fast access and operation due to the memory page-level storage. The network communication module receives the visual interface hot loading instruction, the communication reflection module analyzes the target API module identifier and loading parameters in the instruction, and determines the module loading sequence in combination with the API calling dependency graph, which can realize accurate transmission and analysis of the hot loading instruction, ensure that the loading process is performed in order according to the dependency logic, and avoid calling conflicts between modules. The hot loading is sequentially executed according to the module loading sequence, the snapshot data is read after the new API code loading is completed, the integrity is verified, the runtime state of the associated API module is restored using memory copying and register recovery operations, which can ensure the stability and safety of the hot loading process, realize seamless connection of the runtime state after the API module is updated, and restore normal operation without restarting. BRIEF DESCRIPTION OF DRAWINGS

[0024] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0025] Figure 1 A flowchart of a visual API application interface hot loading method based on a script engine provided by an embodiment of the present application;

[0026] Figure 2 A scene diagram of a visual API application interface hot loading method based on a script engine provided by an embodiment of the present application;

[0027] Figure 3 A structural diagram of a visual API application interface hot loading system based on a script engine provided by an embodiment of the present application. DETAILED DESCRIPTION

[0028] In the development of traditional game engines and visual applications, the business logic and the engine bottom layer code are deeply bound, and are usually developed by using a compiled language such as C++. Not only is the entire project recompiled when the logic is modified, which is time-consuming, but it is also difficult to update the logic without restarting the application. At the same time, there are problems such as complex debugging, difficult cross-platform adaptation, and limited team collaboration. Even though some solutions introduce a script engine to alleviate some of the problems, they still face defects such as no standard process for script life cycle management, incomplete API function exposure, hot loading prone to failure, and weak data binding capability, which cannot meet the development needs of complex scenarios.

[0029] In view of the above problems, the present application provides a visual API application interface hot loading method based on a script engine. The script engine includes four modules: a core engine, a hot reloading module, a network communication module, and a communication reflection module. The core engine collects and organizes API running state data, the hot reloading module analyzes module dependency relationships, the network communication and communication reflection modules cooperatively process hot loading instructions and determine the loading order, and finally the loading is completed in order and the associated module state is restored. This method can update API logic without recompiling or restarting the application, solving the problems of low development efficiency and difficult hot updating in traditional development. At the same time, the process is standardized, the API function exposure is improved, the hot loading stability is ensured, the defects of existing script engines are made up, and the debugging difficulty is reduced through visual operation, which meets the needs of cross-platform adaptation and team collaboration.

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

[0031] 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:

[0032] S101. By collecting and serializing runtime state data during API application interface calls through the core engine module, a state sequence dataset is constructed.

[0033] Optionally, step S101 may specifically include the following steps:

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

[0035] 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;

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

[0037] In the above steps, the core engine module is the core processing unit of the script engine, responsible for collecting, processing and managing API runtime state data. The system management unit is a sub-unit in the core engine module for maintaining functional system instances and monitoring API calls. The functional system instance registry is a list that records all functional system instance information, including system name, instance reference, API interface list, and other data. The serialization processor is a tool that converts non-binary data in the API call process into binary data stream. Call stack information is data that records the hierarchical relationship of API calls, including call order, caller and callee information. The parameter list is the various parameter data passed in during API calls, including parameter name, type, and value. Context environment data is the environment information of API runtime, including current system state and resource occupation. Binary data stream is the data format after serialization processing, which is convenient for storage and transmission. The timestamp marking unit is a tool for adding time identifiers to data, used to record the time of data generation. The frame processing technology is a technology that divides continuous data stream into ordered data frames according to time or data volume. The state sequence data set is an ordered data set containing complete API runtime state after time sequence marking and frame processing.

[0038] The following is the core part of the code for the core engine module:

[0039] The script engine architecture based on TypeScript / JavaScript is constructed, which includes:

[0040] 1.1 Core engine layer (QEngine) (i.e. the core engine module of the present application)

[0041] Design the QEngine core engine class, using the singleton pattern to manage the entire script system:

[0042] typescript

[0043] export class QEngine extends Sigleton {

[0044] public engineData: EngineData

[0045] private Systems: Array <qsystem>= new Array <qsystem>()

[0046] / / Engine type identification mechanism

[0047] static GetInstance(): QEngine {

[0048] if (global.EngineType === "EditorEngine") {

[0049] return super.TakeInstance(QEditorEngine)

[0050] } else if (global.EngineType === "APIEngine") {

[0051] return super.TakeInstance(QAPIEngine)

[0052] }

[0053] return super.TakeInstance(QEngine)

[0054] }

[0055] }

[0056] 1.2 System Management Layer (QSystem)

[0057] Design an abstract system base class QSystem, defining a standardized system lifecycle:

[0058] - PreInit(): Pre-initialization phase, when Unreal Engine is not fully initialized

[0059] - Init(): Initialization phase, perform internal system initialization

[0060] - PostInit(): Post-initialization phase, complete inter-system dependency establishment

[0061] - BeginPlay(): Start running phase, you can safely access Unreal Engine objects

[0062] - Tick(DeltaTime): Update per frame phase, handle real-time logic

[0063] - Shutdown(): Shutdown phase, clean up resources

[0064] Step 1: Environment preparation

[0065] 1. Install Unreal Engine 4 / 5 development environment

[0066] 2. Integrate Puerts plugin into the project

[0067] 3. Configure TypeScript compilation environment

[0068] 4. Set up project directory structure

[0069] Step 2: Core engine implementation

[0070] Create the QEngine core engine class (i.e., the core engine module of the present application):

[0071] typescript

[0072] / / QEngine.ts

[0073] export class QEngine extends Sigleton {

[0074] public engineData: EngineData

[0075] private Systems: Array <qsystem>= new Array <qsystem>( )

[0076] constructor(engineType: string) {

[0077] super()

[0078] this.engineData = new EngineData(engineType)

[0079] }

[0080] / / System creation

[0081] public CreateSystem(System: QSystem) {

[0082] let foundSystem = this.Systems.find((inSystem: QSystem) =>

[0083] inSystem.constructor.name === System.constructor.name)

[0084] if (foundSystem) {

[0085] WARNING(`${System.constructor.name} has register`)

[0086] return

[0087] }

[0088] if(System && System.ShouldInstantiate()) {

[0089] this.Systems.push(System)

[0090] }

[0091] }

[0092] / / Lifecycle management

[0093] public Init(engineType: string) {

[0094] if (this.engineData.engineType!== engineType) return

[0095] if (this.engineData.hasInit) return

[0096] this.engineData.hasInit = true

[0097] this.PreInit()

[0098] this.ForEachEverySystem((System) =>System.Init())

[0099] this.PostInit()

[0100] }

[0101] public Tick(DeltaTime: number, engineType: string) {

[0102] if (this.engineData.engineType!== engineType) return

[0103] this.ForEachEverySystem((System) =>{

[0104] if (System.CanTick()) System.Tick(DeltaTime)

[0105] })

[0106] }

[0107] }

[0108] Step 3: System base class implementation

[0109] Create the QSystem abstract base class:

[0110] typescript

[0111] / / System.ts

[0112] export abstract class QSystem {

[0113] protected engine: QEngine

[0114] protected canTick: boolean = false

[0115] constructor(engine: QEngine) {

[0116] this.engine = engine

[0117] this.engine.CreateSystem(this)

[0118] }

[0119] / / Lifecycle methods

[0120] public PreInit() {}

[0121] public Init() {}

[0122] public PostInit() {}

[0123] public BeginPlay() {}

[0124] public Tick(DeltaTime: number) {}

[0125] public Shutdown() {}

[0126] / / System management

[0127] public ShouldInstantiate(): boolean { return true}

[0128] public CanTick() { return this.canTick}

[0129] protected GetSystem<T extends QSystem>(TClass: TType <t>: T {

[0130] return this.engine.GetSystem <t>(TClass)

[0131] }

[0132] }

[0133] In the embodiments of the present application, first, the system management unit in the core engine module maintains a function system instance registry through step S1011, and monitors the API calling process of each system. As can be seen from the above code, the Systems array in the QEngine class (i.e., the core engine module of the present application) acts as a function system instance registry, and the CreateSystem method is responsible for adding QSystem subclass instances, such as the character control system and the prop management system in the game, to the Systems array to avoid repeated registration. Meanwhile, the Tick method of QEngine will traverse the Systems array at fixed time intervals to execute the Tick method of each Tickable system through the CanTick method, and in this process, the behavior of each system calling an API is captured, such as when the character control system calls the "character movement API", the Tick method will monitor this calling action and related process data. In the A game project, the character control system QSystem subclass (i.e., the system management layer in the script engine) instance is added to the Systems array through the CreateSystem method when it is initialized; during the game running, the Tick method of QEngine calls the Tick method of the character control system every frame, and when the "character movement API" is triggered by the player's operation of the character, the system management unit will monitor the API calling initiation, parameter passing, execution process and other information, and record them in the monitoring log.

[0134] Secondly, through step S1012, based on the monitored API calling process, the calling stack information, parameter list and context environment data generated in the calling process are converted into binary data stream by using a serialization processor. After capturing the API calling process, the serialization processor will first extract the calling stack information of the calling, such as the hierarchical relationship of "main program→character control module→character movement API", the parameter list, such as the movement direction "forward", the movement speed "5 m / s", and the context environment data, such as the current position of the character "(100, 200)" and the current scene resource occupancy rate "30%", and then convert these structured data into binary data stream through a general serialization algorithm, such as the binary extension form of JSON serialization. This format can reduce the data volume and facilitate subsequent storage and processing. In the A game project, after monitoring the "character movement API" calling, the serialization processor will extract the calling stack "game main loop→character control system→character movement API", the parameter list movement direction "forward", movement speed "5 m / s", and the context environment data, character current coordinates "(150, 250)", and current frame rate "60 fps", and then convert these data into binary data stream in the form of "01001011...00110101".

[0135] Then, through step S1013, the binary data stream is time-stamped by a time-stamping unit and organized into an ordered state sequence data set by using a frame processing technology. The time-stamping unit will add a time stamp accurate to milliseconds, such as "2024-10-0114:30:00:123", to each binary data stream to clearly indicate the time sequence of data generation. Then the frame processing technology will divide the binary data stream with time stamp into data frames according to fixed time window or fixed data amount, each data frame containing API runtime data in that time period, and finally arrange these data frames into a state sequence data set in time stamp order to ensure the order and integrity of the data. In the A game project, the time-stamping unit adds a time stamp "2024-10-0114:30:00:123" to the binary data stream corresponding to "character movement API"; the frame processing technology integrates the binary data stream corresponding to "character movement API" and "prop use API" in the time period of 14:30:00:100-14:30:00:200 into a frame of data according to the time window of 100 milliseconds, and finally sorts all data frames in time stamp order from early to late to form a state sequence data set containing all API running states in that time period.

[0136] In the overall scheme of step S101, the ordered state sequence dataset is constructed through the time sequence mark and the frame processing, the time sequence and the integrity of the data are ensured, accurate and complete basic data support is provided for the subsequent dependence analysis, snapshot storage and state recovery, and the accurate tracing and processing of the API running state in the hot loading process are ensured.

[0137] S102, calling a dependence analysis algorithm based on graph theory through the hot reloading module, analyzing the state sequence data, constructing an API calling dependence graph, and identifying the associated API modules affected by the hot loading operation from the API calling dependence graph;

[0138] Optionally, step S102 can specifically include the following steps:

[0139] S1021, monitoring the script file system event through the file monitoring unit in the hot reloading module, and detecting the file change operation;

[0140] S1022, based on the detected file change operation, using the dependence analyzer to parse the calling relationship information in the state sequence dataset;

[0141] S1023, according to the calling relationship information obtained by parsing, using the adjacency list data structure to represent the relationship between the API calling nodes and edges;

[0142] S1024, based on the adjacency list data structure, analyzing the key nodes in the calling path through the depth-first search algorithm;

[0143] S1025, according to the related information of the key nodes, determining the dependence priority between the modules based on the topological sorting algorithm, and constructing the API calling dependence graph.

[0144] In the above steps, the hot-reloading module is the core unit in the script engine responsible for monitoring file changes, analyzing API dependencies, and building dependency graphs. The file monitoring unit is a sub-unit in the hot-reloading module used to monitor script file system events such as file modifications, additions, and deletions. Script file system events refer to various state change events that occur in the script file in the storage system. File change operations are specific operational behaviors of script files being modified, added, or deleted. The dependency relationship analyzer is a tool used to analyze API call relationships in the state sequence dataset and identify inter-module dependency associations. The state sequence dataset is an ordered dataset containing API runtime states built in step S101, where the call relationship information records 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 that stores other nodes directly called by the node, thereby embodying the relationship between nodes and edges. The depth-first search algorithm is a graph traversal algorithm that starts from the starting node and preferentially traverses all adjacent nodes of the current node until it cannot continue to backtrack, used to mine key nodes in the call path. Key nodes are API module nodes in the API call path that are in a core position and have a direct impact on the calling logic of other nodes. The topological sorting algorithm is an algorithm for sorting directed acyclic graphs, which determines the order of nodes according to their dependency relationships, used to clarify the dependency priority between modules. The API call dependency graph is a graph that visually displays the call dependency relationships between API modules, containing nodes (API modules) and edges (call relationships), and can intuitively present the dependency associations between modules.

[0145] The script engine architecture of the present application also includes a hot-reloading module, wherein the hot-reloading module includes the following hot-reloading mechanisms.

[0146] The following is a specific example code of the hot-reloading mechanism:

[0147] Step 1: File monitoring implementation

[0148] typescript

[0149] / / HotReloadManager.ts

[0150] export class HotReloadManager {

[0151] private fileWatcher: FileWatcher

[0152] private moduleCache: Map<string, any>= new Map()

[0153] constructor() {

[0154] this.fileWatcher = new FileWatcher()

[0155] this.fileWatcher.onFileChanged = this.onFileChanged.bind(this)

[0156] }

[0157] private onFileChanged(filePath: string) {

[0158] console.log(`File changed: ${filePath}`)

[0159] this.reloadModule(filePath)

[0160] }

[0161] private reloadModule(filePath: string) {

[0162] try {

[0163] / / Save the current state

[0164] const currentState = this.saveSystemState()

[0165] / / Clear the module cache

[0166] delete require.cache[require.resolve(filePath)]

[0167] / / Reload the module

[0168] const newModule = require(filePath)

[0169] / / Restore the state

[0170] this.restoreSystemState(currentState)

[0171] console.log(`Module reloaded: ${filePath}`)

[0172] } catch (error) {

[0173] console.error(`Failed to reload module: ${filePath}`,error)

[0174] }

[0175] }

[0176] }

[0177] Step 2: State management implementation

[0178] typescript

[0179] / / StateManager.ts

[0180] export class StateManager {

[0181] private stateSnapshot: Map<string, any>= new Map()

[0182] saveState(key: string, state: any) {

[0183] this.stateSnapshot.set(key, JSON.parse(JSON.stringify(state)))

[0184] }

[0185] restoreState(key: string): any {

[0186] return this.stateSnapshot.get(key)

[0187] }

[0188] clearState(key: string) {

[0189] this.stateSnapshot.delete(key)

[0190] }

[0191] }

[0192] In the embodiments of the present application, first, the file monitoring unit in the hot reload module monitors the script file system event through step S1021, i.e., detects the file change operation. As can be seen from the above code, the fileWatcher object in the HotReloadManager class (i.e., the hot reload module of the present application) is the file monitoring unit. After being initialized in the constructor of the class, the fileWatcher object listens to the state change of the file in the script file system by binding the onFileChanged method; when any script file such as the prop logic script file in the game is modified, added or deleted, the fileWatcher will capture the corresponding file system event and trigger the onFileChanged method, and pass the file path that has changed as a parameter, thereby completing the detection of the file change operation. For example, in the development process of the A game project, the developer modified the code content of the "prop effect calculation script", and the file monitoring unit immediately monitored the modification event of the script file and triggered the onFileChanged method to obtain the path " / scripts / prop / effectCalculate.ts" of the script file, and clearly detected the file change operation.

[0193] Secondly, based on the detected file change operation, the calling relationship information in the state sequence dataset is parsed by using the dependency relationship analyzer through step S1022. After detecting the file change operation and obtaining the changed file path, the dependency relationship analyzer will first locate the API module corresponding to the changed file, and then extract all calling records related to the API module from the state sequence dataset constructed in step S101. These records contain other modules called by the API module, other modules called by the API module, and parameter passing information at the time of calling; then the dependency relationship analyzer will sort out these calling records to identify the direct calling relationship between the API module and other API modules, and form a preliminary calling relationship list. For example, in the A game project, after detecting the change of the "prop effect calculation script", the dependency relationship analyzer extracts the calling records of the "prop effect calculation API" corresponding to the script from the state sequence dataset, finds that the API will call the "character attribute acquisition API" and the "prop inventory update API", and will be called by the "prop use trigger API", and then sorts out the direct calling relationship list of the "prop effect calculation API" and the three API modules.

[0194] Then, by step S1023, the relationship between API calling nodes and edges is represented by using an adjacency list data structure according to the parsed calling relationship information. After obtaining the preliminary calling relationship list, each API module is taken as a calling node, and the calling relationship between modules is taken as an edge. Then, according to the storage rule of the adjacency list, a list is created for each calling node, and the list stores the node identifiers directly called by the node, so as to establish the adjacency list and clearly record the direct calling association between each node and other nodes. For example, in the A game project, according to the calling relationship list of the "prop effect calculation API", when the adjacency list is constructed, the node identifiers of the "character attribute acquisition API" and the "prop inventory update API" are stored in the list corresponding to the "prop effect calculation API" node, the node identifier of the "prop effect calculation API" is stored in the list corresponding to the "prop use trigger API" node, and the node identifiers corresponding to the "character attribute acquisition API" and the "prop inventory update API" are stored in the list according to the calling relationship, so as to complete the representation of the relationship between API calling nodes and edges.

[0195] Then, by step S1024, the key nodes in the calling path are analyzed by using a depth-first traversal algorithm based on the adjacency list data structure. After the adjacency list is constructed, the API module node corresponding to the detected change file is taken as a starting node, and the depth-first traversal algorithm is started. The algorithm first accesses the starting node, and then accesses each node in the adjacency list of the starting node in turn. For each accessed node, the nodes in the adjacency list of the node are recursively accessed until all nodes having a direct or indirect calling relationship with the starting node are traversed. During the traversal process, the number of times each node is called and the position of the node in the calling path are recorded, and the node having a large number of calling times and being at the intersection of multiple calling paths is marked as a key node. For example, in the A game project, the "prop effect calculation API" node is taken as a starting node to start the depth-first traversal, the node is first accessed, then the "character attribute acquisition API" in the adjacency list of the node is accessed, then the "character level judgment API" in the adjacency list of the "character attribute acquisition API" is accessed, and then the "prop inventory update API" in the adjacency list of the "prop effect calculation API" is accessed. After the traversal is completed, it is found that the "prop effect calculation API" is called by the "prop use trigger API" and two other APIs, and the "character attribute acquisition API" is called by multiple effect calculation APIs, and both of them are marked as key nodes in the calling path.

[0196] Finally, by step S1025, the dependency priority between modules is determined based on the topological sorting algorithm according to the related information of the key node, and the API calling dependency graph is constructed. After identifying the key node, all nodes related to the changed API module and the calling relationship between them are collected to form the initial structure of the directed acyclic graph; then the topological sorting algorithm is used, and the calling dependency relationship between nodes is sorted, such as A node calling B node, B node depending on A node, and A node having higher priority than B node, to determine the dependency priority of each node; and then according to the sorting result and the calling relationship in the adjacency list, the API module is represented by a node, and the calling dependency relationship is represented by a directed edge from the calling party to the called party, to draw a complete API calling dependency graph. For example, in the A game project, after collecting "prop use trigger API", "prop effect calculation API", "character attribute acquisition API", "prop inventory update API", "character level judgment API" and their calling relationship, the priority order is determined by the topological sorting algorithm as "character level judgment API", "character attribute acquisition API", "prop inventory update API", "prop effect calculation API", and "prop use trigger API"; then the API is used as a node, and the calling relationship is represented by a directed edge from "character level judgment API" to "character attribute acquisition API", from "character attribute acquisition API" to "prop effect calculation API", and the like, to construct a complete API calling dependency graph.

[0197] In the overall scheme of the above step S102, the system sorts the dependency relationship between API modules, accurately identifies the associated API modules that may be affected by the hot loading operation, provides reliable dependency analysis support for subsequent ordered execution of hot loading and avoidance of module calling conflicts, and ensures the stability of the hot loading process.

[0198] Optionally, step S102 further includes the following process:

[0199] From the API calling dependency graph, the associated API modules affected by the hot loading operation are identified, including: based on the API calling dependency graph, the target API module node that is changed is located by a dependency relationship analyzer; starting from the target API module node, the API calling dependency graph is reverse-traversed 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 calling dependency graph is forward-traversed through a depth-first traversal algorithm to identify all downstream called modules directly or indirectly depended on by the target API module node; the identified upstream calling modules and downstream called modules are combined into a set of affected associated API modules; based on the dependency priority between modules determined by the topological sorting algorithm, the modules in the set of associated API modules are sorted in dependency relationship to generate an ordered list of affected associated API modules.

[0200] 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, and is the starting core node of dependency analysis. The upstream calling module refers to the API module that directly or indirectly calls the target API module node, and its running logic depends on the function implementation 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, and provides function support for the target API module. The associated API module set is formed after merging the upstream calling module and the downstream called module, and contains a set of all API modules that may be affected due to hot-loading of the target API module. The associated API module ordered list is an ordered module list obtained by sorting the modules in the associated API module set based on the topological sorting, and is used to clearly define the module processing order during hot-loading.

[0201] In the embodiments of the present application, first, based on the API calling dependency graph that has been constructed, the target API module node that has changed is located by a dependency relationship analyzer. The dependency relationship analyzer will find the node that matches the API module corresponding to the file change operation detected previously in the dependency graph, and this node is the starting point for subsequent analysis. For example, in the A game project, the "task reward calculation API" module corresponding to the file change will be located as the target API module node by the dependency relationship analyzer. Second, starting from the target API module node, the API calling dependency graph is traversed in reverse through an adjacency list data structure. The adjacency list stores the calling relationship of each node, and reverse traversal means starting from the target node, finding all nodes that call the target node, and recursively finding other nodes that call these nodes, so as to identify all upstream calling modules that directly or indirectly depend on the target node. For example, reverse traversal from the "task reward calculation API" node will find the "task completion judgment API" that directly calls it, and the "main line task management API" that indirectly calls it, which together constitute the upstream calling module. At the same time, the API calling dependency graph is traversed in forward direction through a depth-first traversal algorithm, starting from the target node, traversing its directly called nodes first, and then recursively traversing other nodes called by these nodes, to identify all downstream called modules that are directly or indirectly dependent on the target node. For example, 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, and the "player information storage API" called by the "player level detection API", which constitute the downstream called module. Then, the identified upstream calling module and downstream called module are merged to form the affected associated API module set.

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

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

[0204] Optionally, step S103 may specifically include the following steps:

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

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

[0207] S1033. Based on the memory layout information, the key data area is divided into multiple standard memory page units using a memory paging mechanism;

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

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

[0210] S1036. Use memory mapping technology to map the snapshot data in the temporary buffer to the non-volatile memory address space;

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

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

[0213] In the above steps, the memory page table entry is a table entry that records the memory page storage address and access permission. The write protection permission is a permission setting that restricts write operations on the memory page. The page fault exception handling mechanism is an exception handling process triggered by the system when a program accesses a memory page without permission or does not exist. The page fault exception handling program is a program that executes exception handling logic, used to capture memory access exceptions and perform data copying and other operations. The temporary buffer is a memory space that temporarily stores the contents of the original memory page after copying. The consistent memory snapshot is a memory data copy that contains the complete and consistent runtime state of the module. The memory mapping technology is a technology that maps disk files or memory regions to process address spaces to enable direct data access. The non-volatile memory address space is an address range that maps to non-volatile memory and does not lose data after power failure. The non-volatile memory controller is a hardware or software component that manages non-volatile memory read and write and persistent storage. The persistent storage interface is an interface provided by the controller for permanently saving data to non-volatile memory. Atomic commit is an operation characteristic that ensures that data is either completely saved or not saved, avoiding data corruption caused by partial writing. CRC32 cyclic redundancy check code is a code calculated by the CRC32 algorithm to verify data integrity, which can detect errors in data transmission or storage. The snapshot data index table is an index list that records the snapshot storage location, data size, and generation timestamp of each memory page, facilitating quick snapshot data lookup and management.

[0214] In the embodiments of the present application, first, step S1031 is performed, that is, based on the ordered list of affected associated API modules, the state management unit in the hot reload module traverses each associated API module in the list in turn. The state management unit will select 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 omission due to improper processing order. For example, in the A game project, the ordered list of associated API modules is "player information storage API" "player level detection API" "reward item configuration reading API" "task reward calculation API", and the state management unit will start from "player information storage API" and traverse each module in turn.

[0215] Secondly, through step S1032, that is, for each associated API module, the runtime memory layout information thereof is acquired by the memory management unit to determine the key data region that needs to be saved. The memory management unit interacts with the system memory management module to read the storage structure information of the current traversed module in the memory, including the address range of the data segment and the code segment, and screens out the key data region storing the runtime core state of the storage module from the redundant data that does not need to be saved. For example, for the "player information storage API", the memory management unit acquires that in the memory layout thereof, the 0x1000-0x2000 address segment stores the player basic information, and the 0x2001-0x3000 address segment stores the backpack data, and these two address segments are determined as the key data region.

[0216] Next, through step S1033, that is, according to the memory layout information, the key data region is divided into a plurality of standard memory page units by using the memory paging mechanism. The memory paging mechanism divides the key data region according to the standard memory page size set by the system, and if the size of the key data region is not an integer multiple of the standard page, the last page is padded according to the standard page size, so as to ensure that each page is of a uniform specification, facilitating subsequent batch processing and management. For example, the key data region of the "player information storage API" is 0x1000-0x2800, with a size of 6KB, which is divided into two standard memory page units according to the 4KB standard page size, the first one covers 0x1000-0x2000 (4KB), and the second one covers 0x2000-0x2800, 2KB, which is padded to 4KB.

[0217] Then, through step S1034, that is, the copy-on-write operation is performed on each memory page unit, the write protection permission is set in the memory page table entry, and the page error exception handling mechanism is triggered. The system creates a mapping relationship for each memory page unit, and modifies the access permission of the page in the memory page table entry to write protection. At this time, if a program attempts to modify the memory page data, a page error exception will be triggered due to insufficient permission, and then the exception handling process is started. For example, after the copy-on-write operation is performed on the memory page unit of the "player information storage API", the write permission of the page in the memory page table entry is closed, and when other modules attempt to modify the player level data in the page, the system immediately triggers a page error exception.

[0218] Afterwards, through step S1035, i.e. through the memory access exception capture by the page fault exception handler, the original memory page content is copied to the temporary buffer, and a consistent memory snapshot is generated. After the exception is captured, the page fault exception handler will first pause the current modification operation, and then copy the original data of the memory page unit to the pre-allocated temporary buffer. During the copying process, read and write operations on the original memory page are prohibited, ensuring that the copied data is completely consistent with the current running state of the module, forming a consistent snapshot of the memory page. For example, after the exception handler captures the access exception of the "player information storage API" memory page, the original data of the player ID "U001", level "50", backpack items "P001*3", etc. in the page is completely copied to the temporary buffer, generating a memory snapshot of the module.

[0219] Further, through step S1036, i.e. using memory mapping technology to map snapshot data in the temporary buffer to non-volatile memory address space. Memory mapping technology establishes a mapping relationship between the temporary buffer and the non-volatile memory address space, so that the program can access the snapshot data in the non-volatile memory as if it were accessing ordinary memory, without the need for file I / O operations, 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 segment of the non-volatile memory, and subsequent access to the snapshot data can directly operate the 0x8000-0x9000 address space.

[0220] Subsequently, through step S1037, i.e. through the persistent storage interface of the non-volatile memory controller, the mapped snapshot data is atomically submitted to the non-volatile memory area. The non-volatile memory controller will write the snapshot data in the mapped address space to the non-volatile memory through the persistent storage interface, and the entire writing process is atomic. If a power failure or fault occurs during the process, the data will either be completely written or not written, avoiding data corruption or incompleteness. For example, the controller atomically writes the "player information storage API" snapshot data of the 0x8000-0x9000 address segment to the specified area of the non-volatile memory through the interface, ensuring that the data is permanently saved and complete.

[0221] Finally, a CRC32 cyclic redundancy check code is generated for each stored memory page snapshot data in the embodiment of the application through step S1038, and the check code is stored in association with the corresponding snapshot data; 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 obtained by calculating the data content thereof through a CRC32 algorithm, and the check code is stored in the same location as the snapshot data for subsequent verification of data integrity; at the same time, a snapshot data index table is created, each record in the table corresponding to a memory page snapshot, containing the storage address of the snapshot in the non-volatile memory, the data size, and the generation timestamp, facilitating quick query and management. For example, a CRC32 check code "0x12345678" is calculated for the memory page snapshot of the "player information storage API", and is stored in association with the snapshot data; in the index table, the snapshot storage address "0xA000-0xB000", the size "4KB", and the timestamp "2024-10-01 16:30:00:789" are recorded.

[0222] In the overall scheme of the above step S103, complete, safe and efficient storage of the associated API module runtime state is achieved, providing a reliable data basis for state recovery after hot loading, ensuring that the module can accurately recover to the previous running state after hot loading, and maintaining system logical coherence.

[0223] S104, receiving a hot loading instruction from a visualization interface through a network communication module, and analyzing a target API module identifier and loading parameters contained in the hot loading instruction through a communication reflection module, determining a module loading order in combination with an analysis result of the API call dependency graph;

[0224] Optionally, step S104 can specifically include the following steps:

[0225] S1041, receiving and analyzing a hot loading instruction from a network communication module through an instruction analysis unit of a communication reflection module, and extracting a target API module identifier, version number information and loading parameter configuration information contained in the instruction;

[0226] S1042, based on the target API module identifier, locating a corresponding module node in the API call dependency graph, and querying the topological position of the node in the dependency relationship;

[0227] S1043, analyzing all direct and indirect dependent modules of the target API module according to the topological structure of the API call dependency graph, and constructing a dependency chain;

[0228] S1044, determining a priority rule for module loading based on a loading strategy specified in the loading parameter configuration information in combination with the topological relationship of the dependency chain;

[0229] S1045、Through a topological sorting algorithm, the modules in the dependency chain are sorted to ensure that each module is loaded after all its dependent modules;

[0230] S1046, when a circular dependency situation is detected, a dependency breaking mechanism is used to select the optimal decoupling point to generate a loop-free module loading sequence;

[0231] S1047, according to the version number information, verify the module version compatibility, generate version conflict warning for incompatible modules, to generate a complete hot loading execution plan containing module loading order, dependency relationship, version information and loading parameters.

[0232] In the above steps, the instruction parsing unit is a subunit of the communication reflection module responsible for receiving and parsing hot loading instructions, and can extract key information from the instructions. The target API module identifier is a string or code used to uniquely identify the target API module, which facilitates locating the module in the dependency graph. The version number is the information that marks the iteration version of the API module, which is used to verify the compatibility of the module. The loading parameter configuration information is the parameter setting contained in the hot loading instruction, including loading strategy, timeout time, etc. The topological position is the specific position of the module node in the API call dependency graph topology, reflecting the dependency level relationship between the module and 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 the dependency relationship. The loading strategy is the module loading rule specified in the loading parameter configuration information, such as "preferentially loading underlying dependencies" and "incrementally loading changed modules". The priority rule is the module loading order criterion determined based on the loading strategy and the dependency chain topology relationship. Circular dependency refers to the closed loop relationship formed by mutual dependency between two or more modules. The dependency breaking mechanism is a technical means for breaking the circular dependency, which breaks the closed loop into linear dependency by selecting a decoupling point. The loop-free module loading sequence is a list of module loading orders formed without closed loops after breaking the circular dependency. The version compatibility verification is the process of checking whether the versions of the modules to be loaded match the existing modules. The version conflict warning is a prompt message generated when the module versions are detected to be incompatible, which is used to inform the developer of the conflict situation. The hot loading execution plan is a complete plan containing module loading order, dependency relationship, version information and loading parameters, which guides the hot loading operation execution.

[0233] The script engine architecture also includes a communication reflection module, wherein the communication reflection module has an API full reflection mechanism.

[0234] Here are some core codes of specific examples:

[0235] Step 1: C++ side API processor

[0236] cpp

[0237] / / APIHandle.cpp

[0238] void UAPIHandle::BPCallAPI(FString InClass, FString InFunction,FString InData) {

[0239] / / Call Script-side API

[0240] InBlueprintCallAPI.ExecuteIfBound(InClass, InFunction, InData);

[0241] }

[0242] FString UAPIHandle::GetAPIModelData(FString APIClass, FString APIId){

[0243] if (APIHandleActor!= nullptr) {

[0244] return APIHandleActor->GetModelData(APIClass, APIId);

[0245] }

[0246] return "";

[0247] }

[0248] Step 2: Script-side API Registration

[0249] typescript

[0250] / / APIRegistry.ts

[0251] export class APIRegistry {

[0252] private static instance: APIRegistry

[0253] private apiHandlers: Map<string, Function>= new Map()

[0254] static getInstance(): APIRegistry {

[0255] if (!this.instance) {

[0256] this.instance = new APIRegistry()

[0257] }

[0258] return this.instance

[0259] }

[0260] registerAPI(className: string, methodName: string, handler:Function) {

[0261] const key = `${className}.${methodName}`

[0262] this.apiHandlers.set(key, handler)

[0263] }

[0264] callAPI(className: string, methodName: string, data: string):string {

[0265] const key = `${className}.${methodName}`

[0266] const handler = this.apiHandlers.get(key)

[0267] if (handler) {

[0268] try {

[0269] const params = JSON.parse(data)

[0270] const result = handler(params)

[0271] return JSON.stringify(result)

[0272] } catch (error) {

[0273] console.error(`API call failed: ${key}`, error)

[0274] return JSON.stringify({ error: error.message})

[0275] }

[0276] }

[0277] return JSON.stringify({ error: `API not found: ${key}`})

[0278] }

[0279] }

[0280] In the embodiments of the present application, first, the hot loading instruction from the network communication module is received and parsed by the instruction parsing unit of the communication reflection module through step S1041, and the target API module identifier, version number information and loading parameter configuration information contained in the instruction are extracted. In combination with the code, the callAPI method of the APIRegistry class (i.e. the communication reflection module of the present application, which has an API reflection mechanism) has data parsing capability, and the instruction parsing unit can refer to its parsing logic to first receive the hot loading instruction transmitted by the network communication module, which is usually in JSON format, and then extract the key information through a parsing algorithm, wherein 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 specifies the loading rule. For example, in the A game project, the hot loading instruction received by the instruction parsing unit is {"targetAPI":"TaskRewardCalculateAPI","version":"v2.1","loadParams":{"strategy":"loadBottomUp","timeout":3000}}, and after parsing, the target API module identifier "TaskRewardCalculateAPI", the version number information "v2.1", the loading parameter configuration information loading strategy "load from bottom to top", and the timeout time 3000 milliseconds are extracted.

[0281] Secondly, through step S1042, i.e. based on the target API module identifier, the corresponding module node is located in the API call dependency graph, and the topological position of the node in the dependency relationship is queried. By using the unique mapping relationship between the target API module identifier and the node in the API call dependency graph, the matching module node is found by traversing the identification information of the dependency graph node; and according to the topological structure of the dependency graph, such as the node level, the adjacent node relationship, the dependency level where the node is located is determined, and the position of the node in the overall dependency relationship is clarified. For example, in the A game project, according to the "TaskRewardCalculateAPI" identifier, the corresponding module node is located in the dependency graph, and it is found by querying that the node is located in the fourth layer of the dependency graph, and the nodes directly dependent on it are located in the third layer, and the second layer node is directly called, and the topological position of the node is clarified.

[0282] Next, through step S1043, i.e. according to the topological structure of the API call dependency graph, all direct and indirect dependent modules of the target API module are analyzed, and a dependency chain is constructed. Starting from the target API module node, the direct dependent modules directly calling the node are first identified, and then the dependent modules of these direct dependent modules, i.e. the indirect dependent modules of the target module, are recursively identified, and all dependent modules are connected in the order of "indirect dependent module→direct dependent module→target API module", forming a complete dependency chain. For example, in the A game project, the target API module "TaskRewardCalculateAPI" directly depends on "PlayerLevelCheckAPI" and "RewardConfigReadAPI", and "PlayerLevelCheckAPI" depends on "PlayerInfoStoreAPI", so the dependency chain constructed is "PlayerInfoStoreAPI→PlayerLevelCheckAPI→TaskRewardCalculateAPI" "RewardConfigReadAPI→TaskRewardCalculateAPI".

[0283] Then, through step S1044, i.e., based on the loading strategy specified in the loading parameter configuration information, the priority rules of module loading are determined in combination with the topology relationship of the dependency chain. First, the loading strategy in the loading parameter configuration information is parsed, and then the priority rules are formulated in combination with the hierarchical relationship of the dependency chain, such as the bottom layer module supporting the upper layer module. If the loading strategy is "loading from the bottom layer to the upper layer", the priority rule is "the lower the level of the module in the dependency chain, the higher the loading priority"; if the strategy is "incremental loading of changed modules", the rule is "only the modules with version changes and their direct dependent modules are loaded, and the bottom layer modules dependent on the changed modules are loaded first". For example, in the A game project, the loading strategy is "loading from the bottom layer to the upper layer", and in combination with the topology relationship of the dependency chain, the priority rule is determined as "PlayerInfoStoreAPI (the lowest layer) has the highest priority, followed by PlayerLevelCheckAPI and RewardConfigReadAPI, and finally TaskRewardCalculateAPI (the target module)".

[0284] After that, through step S1045, i.e., the modules in the dependency chain are sorted by the topological sorting algorithm, and it is ensured that each module is loaded after all its dependent modules. The topological sorting algorithm will arrange the modules in order according to the hierarchical relationship and priority rules of the dependency chain, traverse all the modules in the dependency chain, first add the modules with no pre-dependence or pre-dependence already sorted to the sequence, then process the subsequent modules that depend on the sorted modules, and finally get the order that meets the requirement that "each module is loaded after its dependent modules". For example, in the A game project, the topological sorting is performed on the dependency chain "PlayerInfoStoreAPI→PlayerLevelCheckAPI→TaskRewardCalculateAPI" and "RewardConfigReadAPI→TaskRewardCalculateAPI", and the loading order is "PlayerInfoStoreAPI→PlayerLevelCheckAPI→RewardConfigReadAPI→TaskRewardCalculateAPI", which ensures that "PlayerLevelCheckAPI" is loaded after "PlayerInfoStoreAPI", and "TaskRewardCalculateAPI" is loaded after "PlayerLevelCheckAPI" and "RewardConfigReadAPI".

[0285] Afterwards, through step S1046, when the circular dependency is detected, the optimal decoupling point is selected by using the dependency breaking mechanism to generate a loop-free module loading sequence. First, the dependency chain that has been constructed is traversed to check whether there is a closed loop relationship of "module A depends on module B, and module B depends on module A". If there is a circular dependency, the dependency breaking mechanism analyzes the functional independence and the calling frequency of each module in the loop, selects a module that is relatively independent in function and has a low calling frequency as a decoupling point, temporarily breaks the dependency between the module and other modules in the loop in the loading sequence, loads the modules outside the loop and the modules inside the loop that are not decoupling points first, and then loads the decoupling point module after the core module is loaded, to generate a loop-free sequence. For example, in the A game project, if the circular dependency of "TaskRewardCalculateAPI" depending on "TaskProgressCheckAPI" and "TaskProgressCheckAPI" depending on "TaskRewardCalculateAPI" is detected, it is found through analysis that "TaskProgressCheckAPI" is relatively independent in function and has a low calling frequency, and is set as a decoupling point, to generate a loop-free loading sequence "PlayerInfoStoreAPI→PlayerLevelCheckAPI→RewardConfigReadAPI→TaskRewardCalculateAPI→TaskProgressCheckAPI".

[0286] Finally, by step S1047, i.e., according to the version number information, the module version compatibility is verified, and a version conflict warning is generated for incompatible modules, so as to generate a complete hot loading execution plan containing the module loading order, dependency relationship, version information and loading parameter. First, the current version and the to-be-loaded version of each module in the dependency chain are obtained, and the version comparison algorithm such as semantic version comparison is used to check whether the major version number and the minor version number are matched to verify the compatibility; if the major version number of the to-be-loaded module version and the current module version is inconsistent, it is determined that they are incompatible, and a version conflict warning is generated, containing the conflict module name, the current version and the to-be-loaded version; then, the loading order, the dependency relationship in the dependency chain, the version information of each module and the loading parameter configuration information determined before are integrated to form a complete hot loading execution plan. For example, in the A game project, it is found by verification that the current version of "RewardConfigReadAPI" is "v1.8" and the to-be-loaded version is "v2.1", the major version numbers are consistent and it is determined that they are compatible; the current version "v2.0" of "PlayerInfoStoreAPI" and the to-be-loaded version "v2.1" are compatible and no conflict warning is generated, and finally the hot loading execution plan is generated, containing the loading order "PlayerInfoStoreAPI→PlayerLevelCheckAPI→RewardConfigReadAPI→TaskRewardCalculateAPI", the dependency relationship of each module, the version information such as "TaskRewardCalculateAPI" v2.1 and the loading parameter such as the loading strategy and the timeout time.

[0287] In the overall scheme of the above step S104, the hot loading key information is accurately extracted through instruction analysis, laying a foundation for subsequent operations; the dependency graph positioning and the dependency chain construction clearly comb the dependency relationship between modules; the priority rule formulation and the topological sorting ensure that the module loading order conforms to the dependency logic; the circular dependency processing and the version compatibility verification improve the stability and safety of the loading process; and finally the complete hot loading execution plan is generated, which provides a clear and executable scheme for the hot loading operation, avoids hot loading failure caused by chaotic loading order and version conflict, and ensures that the hot loading process is orderly, efficient and stable.

[0288] S105, according to the module loading order, control the orderly execution of the hot loading process, read the snapshot data from the memory area after completing the new API code loading, verify the data integrity of the snapshot data, and use memory copy and register recovery operations to recover the runtime state of the associated API module based on the verified snapshot data.

[0289] Optionally, step S105 can specifically include the following steps:

[0290] S1051, read the snapshot data and corresponding check code stored in the non-volatile memory area;

[0291] S1052, perform cyclic redundancy check calculation on the snapshot data, compare the calculation result with the check code to verify data integrity, when the check fails, trigger data retransmission mechanism to reacquire snapshot data from the backup storage area; when the check passes, start the direct memory access controller;

[0292] S1053, transfer the snapshot data that passes the verification to the target memory address space in memory page units through the DMA controller, and after the data transmission is completed, extract the processor and register state information from the snapshot data through the register recovery unit, including general registers, status registers and program counter values;

[0293] S1054, use the atomic operation instruction sequence to restore the extracted register state information to the corresponding registers of the target processor, and reconstruct the runtime context environment of the associated API module, including restoring the stack pointer, frame pointer and thread local storage data;

[0294] S1055, update the module state flag to inform the MVVM architecture module that the runtime state recovery is completed, and trigger the interface update process.

[0295] In the above steps, the cyclic redundancy check calculation is a process of calculating the snapshot data by a specific algorithm to generate a check value for verifying data integrity. The data retransmission mechanism is a mechanism for reacquiring complete snapshot data from the backup storage area when the snapshot data check fails, ensuring that usable data can be obtained. The backup storage area is an area specially used for storing snapshot data backups, independent of the main storage area, and is used for data recovery. The direct memory access controller is a hardware or software component that transfers data directly between memory and devices without CPU intervention, which can improve data transfer efficiency. The target memory address space is a memory address range used to store snapshot data after recovery, consistent with the memory address at runtime of the associated API module. The register recovery unit is a subunit responsible for extracting register state information from snapshot data and restoring it to the corresponding register. The general-purpose register is a register used to temporarily store operation data and addresses, the status register is a register recording the processor state, and the program counter value is a value recording the address of the next instruction to be executed. The atomic operation instruction sequence is a set of instructions that ensure that the register state recovery process cannot be interrupted, which can avoid data interference during the recovery process. The runtime context environment 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 of the stack memory, the frame pointer is used to identify the position of the current function call stack frame, and the thread local storage data is exclusive data accessible only by the current thread. The module state flag is used to mark the status of the associated API module. The MVVM architecture module is an architecture component that implements data and view separation, which can trigger interface updates according to module state changes. The interface update process is a process of synchronously updating the visual interface display content after the module runtime state recovery is completed.

[0296] In the embodiment of the present application, first, the snapshot data and the corresponding check code stored in the non-volatile memory area are read through step S1051. In combination with the code, the restoreState method of the StateManager class has the basic logic of reading the stored snapshot data. Based on this logic, this step can locate the snapshot data and its CRC32 check code corresponding to the associated API module to the memory buffer through the read interface of the non-volatile memory controller according to the storage location recorded in the snapshot data index table, and prepare for the subsequent integrity verification. For example, in the A game project, according to the "PlayerInfoStoreAPI" snapshot storage address "0xA000-0xB000" recorded in the index table, the snapshot data of the module is read from the non-volatile memory area, including the player ID "U001", the level "50", etc. and the corresponding check code "0x12345678".

[0297] Secondly, through step S1052, i.e. performing cyclic redundancy check calculation on the snapshot data, comparing the calculation result with the check code to verify the data integrity, when the check fails, triggering the data retransmission mechanism to reacquire the snapshot data from the backup storage area; when the check passes, starting the direct memory access controller. First, the CRC32 algorithm consistent with when the snapshot is generated is used to calculate the read snapshot data, and the current check value is obtained; then the current check value is compared with the original check code read, if they are consistent, it means that the data is complete and undamaged, and the DMA controller is started to prepare data transmission; if they are not consistent, it is determined that the data is damaged, and the data retransmission mechanism is triggered, according to the address information of the backup storage area, the backup snapshot data and the check code of the module are re-read, and the check process is executed again until the complete data is obtained. For example, in the A game project, the snapshot data of "PlayerInfoStoreAPI" is executed CRC32 calculation, and the result "0x12345678" is obtained, which is consistent with the original check code, and the DMA controller is started; if the calculation result is "0x87654321", which is inconsistent with the original check code, the data retransmission mechanism is triggered, and the snapshot data and check code of "PlayerInfoStoreAPI" are re-read from the backup storage area.

[0298] Next, through step S1053, i.e. through the DMA controller, the snapshot data that passes the verification is directly transmitted to the target memory address space in units of memory pages, and after the data transmission is completed, the processor and register state information, including general registers, status registers and program counter values, are extracted from the snapshot data by the register recovery unit. The DMA controller will transmit 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 division of memory pages, the whole process does not need CPU to participate, and the resource occupation is reduced; after the transmission is completed, the register recovery unit will analyze the field specially storing register information in the snapshot data, and extract the temporary operation data stored in the general register, the operation flags such as whether there is carry, overflow in the status register, and the next instruction address recorded by the program counter. For example, in the A game project, the snapshot data of "PlayerInfoStoreAPI" is transmitted to the target address space "0x1000-0x2000" by the DMA controller; the register recovery unit extracts the data such as "player level 50" and "backpack item quantity 3" stored in the general register, the "no operation overflow" flag recorded in the status register, and the program counter value "0x00001234" from the snapshot data.

[0299] Then, the extracted register state information is restored into the corresponding registers of the target processor and the runtime context environment of the associated API module is reconstructed, including restoring the stack pointer, frame pointer and thread local storage data, by step S1054, i.e. using an atomic operation instruction sequence. The atomic operation instruction sequence ensures that the register state restoration process is executed continuously and is not interrupted by other instructions, first writes the extracted general register data into the corresponding general registers, then updates the state register information to the target state register, and finally sets the program counter 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 the module is extracted from the thread local storage data field and written into the thread local storage area, and the reconstruction of the runtime context environment is completed. For example, in the A game project, the general register data of "PlayerInfoStoreAPI" is written into the corresponding registers by the atomic operation instruction, the state register is set to "no operation overflow", and the program counter is set to "0x00001234"; the stack pointer is restored to "0x30000000", the frame pointer is restored to "0x30000100", and the thread local storage data "player thread identifier T001" is written into the corresponding storage area.

[0300] Finally, the module state flag is updated by step S1055, i.e. notifying the MVVM architecture module that the runtime state restoration has been completed, triggering the interface update process. First, the state flag of the associated API module is updated from "restoring" to "restoration completed", which is used to inform the system that the module can be normally operated; then, the information of the completion of the state restoration is sent to the MVVM architecture module through the message notification mechanism, and after receiving the notification, the MVVM architecture module automatically updates the corresponding display content in the visual interface according to the runtime data of the module after the restoration, such as the player level and the backpack data in "PlayerInfoStoreAPI", such as the level number of the player information panel and the number of backpack item icons, and completes the synchronization of the interface and the data. For example, in the A game project, the state flag of "PlayerInfoStoreAPI" is updated to "restoration completed", and after notifying the MVVM architecture module, the player information panel in the interface automatically updates the level display from "loading" to "50", and the number of "P001" items in the backpack from "loading" to "3".

[0301] In the overall scheme of step S105, the integrity and availability of snapshot data are ensured through the cyclic redundancy check and data retransmission mechanism to avoid state recovery anomalies caused by data corruption; the transmission of data by the DMA controller reduces the CPU resource occupation and improves the transmission efficiency; the register state recovery and context environment reconstruction ensure that the associated API module can accurately recover to the running state before hot loading; the module state update and interface synchronization realize the linkage of data and visual interface, so that the user can obtain the information after state recovery in a timely manner. The entire process realizes the safe and accurate recovery of the runtime state of the associated API module, ensures that the module after hot loading can seamlessly connect the previous running logic, maintains the continuity and stability of the system function, and improves the user experience.

[0302] The following is a complete embodiment for steps S101 to S105:

[0303] As shown in Figure 2 , taking the hot loading of the "task reward calculation API" of the A game project as an example, the project uses a script engine including a core engine module, a hot reloading module, a network communication module, and a communication reflection module. First, the core engine module collects the runtime state data in the calling process of the "task reward calculation API", including the calling stack of "game main loop→task system→task reward calculation API", the parameter list of task ID T001 and player level 50, and the context data of current task progress 100%, and constructs a state sequence data set after serialization processing. Then, the hot reloading module calls a dependency relationship analysis algorithm based on graph theory, parses the state sequence data to construct an API calling dependency graph, and identifies the associated API modules of the "task reward calculation API" from the graph, including the upstream "task completion judgment API" and the downstream "player backpack management API" and "reward prop configuration API". Subsequently, the runtime state data of these associated API modules is stored in the non-volatile memory area in the form of memory pages. After the developer initiates a hot loading instruction on the visual interface, the network communication module receives the instruction, and the communication reflection module parses the target API module identifier "task reward calculation API" and the loading parameters in the instruction. The loading parameters are to load the underlying dependencies in priority, and the module loading order is determined as "reward prop configuration API→player backpack management API→task reward calculation API→task completion judgment API" in combination with the analysis result of the API calling dependency graph. Finally, the hot loading process is controlled to be executed in order according to the determined module loading order, and after the new API code is loaded, the snapshot data is read from the memory area, the data integrity is verified through the CRC32 algorithm, and after the verification is passed, the runtime state of the "player backpack management API" such as the number of props and the reward rule of the "task reward calculation API" is accurately recovered through the memory copy and register recovery operations. The entire hot loading process does not need to restart the game, and the player can normally view the task rewards.

[0304] The script engine-based visual API application interface hot loading method provided in the application can realize comprehensive collection and serialization of API runtime state through a core engine module, lay a data foundation for subsequent dependency analysis; a graph theory analysis algorithm of a hot reloading module can accurately identify associated modules, so as to avoid expansion of the influence range of hot loading; memory page-level snapshot storage can ensure the safety of state data; network communication and communication reflection modules can cooperate to ensure accurate analysis of hot loading instructions and reasonable loading sequence; integrity verification and state recovery operations can realize seamless connection of the runtime state of associated modules. The overall API hot loading can be completed without restarting the application, which greatly improves the development efficiency, ensures the continuity and stability of system operation, reduces the debugging and maintenance cost, and meets the development needs of large-scale visual applications.

[0305] Figure 3 A specific embodiment structure diagram of a script engine-based visual API application interface hot loading system provided in the application is shown in Figure 3 The system can include:

[0306] The collection module 31 is configured to collect and serialize the runtime state data in the API application interface calling process by the core engine module, so as to construct a state sequence data set.

[0307] The calling module 32 is configured to analyze the state sequence data by calling a graph theory-based dependency analysis algorithm of the hot reloading module, construct an API calling dependency graph, and identify the associated API modules affected by the hot loading operation from the API calling dependency graph.

[0308] The running module 33 is configured to group the runtime state data of the associated API modules into snapshot data in units of memory pages, and store the snapshot data in a memory area.

[0309] The analysis module 34 is configured to receive the hot loading instruction from the visual interface through the network communication module, analyze the target API module identifier and loading parameter contained in the hot loading instruction through the communication reflection module, determine the module loading sequence in combination with the analysis result of the API calling dependency graph.

[0310] The verification module 35 is configured to control the ordered execution of the hot loading process according to the module loading sequence, read the snapshot data from the memory area after the new API code is loaded, verify the data integrity of the snapshot data, and restore the runtime state of the associated API modules based on the snapshot data that passes the verification by using memory copying and register recovery operations.

[0311] The script engine-based visual API application interface hot loading system of the embodiments of the present application is used to implement the aforementioned script engine-based visual API application interface hot loading method, and therefore the specific embodiments of the script engine-based visual API application interface hot loading system can be found in the aforementioned embodiment part of the script engine-based visual API application interface hot loading method, and the specific embodiments can be referred to the description of the corresponding embodiment part, which will not be repeated here.

[0312] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the script engine-based visual API application interface hot loading method.

[0313] The present application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the script engine-based visual API application interface hot loading method.

[0314] In an exemplary embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory, a random access memory, a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0315] The embodiments of the present application also provide a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the script engine-based visual API application interface hot loading method.

[0316] The skilled person can further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in general terms in the above description. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0317] The above describes in detail the script engine-based visual API application interface hot loading method and system provided by the present application. The principles and implementation manners of the present application are described by using specific examples, and the above description of the embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that, for those skilled in the art, some improvements and modifications can be made to the present application without departing from the principles of the present application, and these improvements and modifications also fall within the protection scope of the present application.< / t> < / t> < / qsystem> < / qsystem> < / qsystem> < / qsystem>

Claims

1. A script engine-based visual API application interface hot loading method, characterized in that, The script engine comprises a core engine module, a hot reloading module, a network communication module, and a communication reflection module; The method comprises: By collecting and serializing runtime state data in the API application interface calling process by the core engine module, a state sequence dataset is constructed; By calling a dependency relationship analysis algorithm based on graph theory by the hot reloading module, the state sequence data is analyzed, an API calling dependency graph is constructed, and associated API modules affected by the hot loading operation are identified from the API calling dependency graph; The runtime state data of the associated API modules is composed into snapshot data in units of memory pages, and the snapshot data is stored to a memory area; By receiving a hot loading instruction from a visual interface through the network communication module, and analyzing target API module identifiers and loading parameters contained in the hot loading instruction through the communication reflection module, a module loading sequence is determined in combination with the analysis result of the API calling dependency graph; According to the module loading sequence, the ordered execution of the hot loading process is controlled, 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 the runtime state of the associated API modules is restored based on the snapshot data that passes the verification by using memory copying and register recovery operations; Wherein, the target API module identifiers and loading parameters contained in the hot loading instruction are analyzed by the communication reflection module, in combination with the analysis result of the API calling dependency graph, to determine the module loading sequence, comprising: The instruction analysis unit of the communication reflection module receives and analyzes the hot loading instruction from the network communication module, extracts the target API module identifiers, version number information, and loading parameter configuration information contained in the instruction; based on the target API module identifiers, the corresponding module nodes are located in the API calling dependency graph, and the topological position of the nodes in the dependency relationship is queried; according to the topological structure of the API calling dependency graph, all direct and indirect dependent modules of the target API module are analyzed, and a dependency chain is constructed; based on the loading strategy specified in the loading parameter configuration information, the topological relationship of the dependency chain is combined to determine the priority rules of module loading; the modules in the dependency chain are sorted by a topological sorting algorithm to ensure that each module is loaded after all its dependent modules; when a circular dependency situation is detected, a dependency breaking mechanism is used to select the optimal decoupling point to generate a loop-free module loading sequence; according to the version number information, the module version compatibility is verified, and a version conflict warning is generated for incompatible modules to generate a complete hot loading execution plan containing module loading sequence, dependency relationship, version information, and loading parameters.

2. The method of claim 1, wherein, The script engine further comprises an MVVM architecture module; after verifying the data integrity of the snapshot data and restoring the runtime state of the associated API modules based on the verified snapshot data by using memory copying and register recovery operations, it further comprises: A data binding channel with the visual interface is established by the view model unit in the MVVM architecture module, and a runtime state recovery completion event is listened to; Capture state change information of the recovered runtime state through a responsive data agent mechanism; Based on the captured state change information, use the attribute change notifier to send interface update instructions to the view layer; Through the data binding parser, parse the interface update instructions, update the corresponding data binding elements in the visual interface, and feed back the hot loading result.

3. The method of claim 1, wherein, The runtime state data in the API application interface calling process is collected and serialized by the core engine module to construct a state sequence data set, including: The system management unit in the core engine module maintains the functional system instance registry and monitors the API calling process of each system; Based on the monitored API calling process, the calling stack information, parameter list and context environment data generated in the calling process are converted into binary data stream by the serialization processor; The binary data stream is time-stamped by the time-stamping unit and organized into an ordered state sequence data set by the frame processing technology.

4. The method of claim 1, wherein, The state sequence data is analyzed by the hot reloading module to construct an API calling dependency graph, including: The file monitoring unit in the hot reloading module monitors the script file system events and detects file change operations; Based on the detected file change operation, the calling relationship information in the state sequence data set is parsed by the dependency relationship analyzer; According to the parsed calling relationship information, the adjacency list data structure is used to represent the relationship between API calling nodes and edges; Based on the adjacency list data structure, the key nodes in the calling path are analyzed by the depth-first search algorithm; According to the related information of the key nodes, the dependency priority between modules is determined based on the topological sorting algorithm, and the API calling dependency graph is constructed.

5. The method of claim 4, wherein, From the API calling dependency graph, the affected associated API modules affected by the hot loading operation are identified, including: Based on the API calling dependency graph, the target API module node that has changed is located by the dependency relationship analyzer; Taking the target API module node as the starting point, the API calling 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 calling dependency graph is traversed in forward direction by the depth-first search algorithm to identify all downstream called modules directly or indirectly dependent on the target API module node; The identified upstream calling modules and downstream called modules are merged into an affected associated API module set; Based on the dependency priority between modules determined by the topological sorting algorithm, the modules in the associated API module set are sorted according to the dependency relationship to generate an ordered list of affected associated API modules.

6. The method of claim 5, wherein, The runtime state data of the associated API modules is stored in the memory area by the hot loading module, including: Based on the ordered list of affected associated API modules, the state management unit in the hot reloading module traverses each associated API module in the list in turn; For each associated API module, obtain its runtime memory layout information through the memory management unit, determine the key data area that needs to be saved; According to the memory layout information, the key data area is divided into multiple standard memory page units by using the memory paging mechanism; For each memory page unit, perform a write-once copy operation, set write protection permissions in the memory page table entry, and trigger the page error exception handling mechanism; Capture the memory access exception through the page error exception handling program, copy the original memory page content to the temporary buffer, and generate a consistent memory snapshot; Map the snapshot data in the temporary buffer to the non-volatile memory address space using the memory mapping technology; Through the persistent storage interface of the non-volatile memory controller, the mapped snapshot data is atomically submitted to the non-volatile memory area; The method further comprises: For each stored memory page snapshot data, generate an independent CRC32 cyclic redundancy check code, and store the check code in association with the corresponding snapshot data; Establish a snapshot data index table to record the storage location, size and timestamp information of each memory page snapshot.

7. The method of claim 1 wherein, The method further comprises: Read the snapshot data stored in the non-volatile memory area and the corresponding check code; Perform a cyclic redundancy check calculation on the snapshot data, compare the calculation result with the check code to verify data integrity, and when the check fails, trigger a data retransmission mechanism to reacquire snapshot data from the backup storage area; when the check passes, start the direct memory access controller; Through the DMA controller, the snapshot data that passes the verification is directly transmitted to the target memory address space in memory page units, and after the data transmission is completed, the processor and register state information, including general registers, status registers and program counter values, are extracted from the snapshot data through the register recovery unit; Use the atomic operation instruction sequence to restore the extracted register state information to the corresponding registers of the target processor, and rebuild the runtime context environment of the associated API module, including restoring the stack pointer, frame pointer and thread local storage data; Update the module state flag to notify the MVVM architecture module that the runtime state recovery is complete, and trigger the interface update process.

8. A script engine-based visual API application interface hot loading system for implementing the script engine-based visual API application interface hot loading method of any one of claims 1-7. The method comprises: The acquisition module is configured to collect and serialize runtime state data during API application interface calling process by the core engine module to construct state sequence data set; The calling module is configured to analyze the state sequence data by calling a graph theory-based dependency analysis algorithm through the hot reloading module, construct an API calling dependency graph, and identify the associated API module affected by the hot loading operation from the API calling dependency graph; The running module is configured to store the snapshot data in the memory area by grouping the runtime state data of the associated API module into snapshot data in memory page units. The analysis module is configured to receive the hot loading instruction from the visualization interface through the network communication module, and analyze the target API module identifier and loading parameter contained in the hot loading instruction through the communication reflection module, and determine the module loading sequence in combination with the analysis result of the API calling dependency graph. The verification module is configured to control the ordered execution of the hot loading process according to the module loading sequence, read the snapshot data from the memory area after completing the new API code loading, verify the data integrity of the snapshot data, and restore the runtime state of the associated API module based on the verified snapshot data using the memory copy and register recovery operation.

9. An electronic device, comprising: The computer program product comprises: a memory configured to store a computer program; a processor configured to execute the computer program to implement the steps of the hot loading method of the visualization API application interface based on the script engine according to any one of claims 1 to 7.

Images