An interface interaction data mounting method and terminal

Abstract

The application provides a kind of interface interaction data mounting method and terminal. Including: interface interaction function module is packaged as editor component;Load editor component in target process, to make interface interaction function module effective;Based on the process identification of target process, create inter-process communication channel;Through inter-process communication channel, realize the dynamic configuration of interface interaction data by the interface interaction function module of target process. The application realizes the automatic discovery and collaborative work among multiple processes, supports the dynamic configuration mechanism based on interface operation, natural language instruction or configuration file through inter-process communication channel, realizes the real-time generation and flexible adjustment of interface layout and function call rule.

Description

Technical Field

[0001] This invention relates to the technical field of interface interaction auxiliary tools, and in particular to a method and terminal for mounting interface interaction data. Background Technology

[0002] In traditional testing, test programs usually need to rely on external tools to acquire and control the interactive data of the target program interface. Related technical solutions often face problems such as complex deployment, insufficient versatility, or lack of deep real-time interaction capabilities with the target process in terms of flexibly, dynamically, and non-intrusively mounting the interactive data of the program interface. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method and terminal for mounting interface interaction data, so as to realize lightweight, dynamically configurable functional expansion and multi-process collaboration of the interface of running application programs.

[0004] A method for mounting user interface interaction data, the method comprising: Encapsulate the interface interaction function modules as editor components; Load the editor component in the target process to enable the interface interaction function module; An inter-process communication channel is created based on the process identifier of the target process; The inter-process communication channel enables dynamic configuration of interface interaction data through the interface interaction function module of the target process.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A terminal for mounting user interface interaction data includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it performs the following steps: Encapsulate the interface interaction function modules as editor components; Load the editor component in the target process to enable the interface interaction function module; An inter-process communication channel is created based on the process identifier of the target process; The inter-process communication channel enables dynamic configuration of interface interaction data through the interface interaction function module of the target process.

[0006] The beneficial effects of this invention are as follows: By encapsulating the interface interaction function modules into editor components and loading them into the target process, a lightweight inter-process communication channel based on the target process identifier is constructed, and this channel is used to achieve dynamic configuration of interface interaction data. Deep integration of the function modules with the editor component framework enables non-intrusive, process-free function mounting of the target program interface, allowing the mounted functions to reside and take effect in any interface program along with the editor component. Simultaneously, this communication channel supports automatic cross-process discovery and data exchange, achieving interface state synchronization and operational collaboration among multiple processes. While ensuring deep integration and flexible invocation of functions, it reduces deployment complexity and improves the convenience of interface interaction testing, monitoring, and auxiliary function expansion, as well as multi-process collaborative work. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a method for mounting user interface interaction data according to an embodiment of the present invention; Figure 2 A flowchart illustrating the steps involved in creating and configuring an editor component, as provided in this embodiment of the invention. Figure 3 A flowchart illustrating the steps for establishing an inter-process communication channel provided in this embodiment of the invention; Figure 4 A flowchart illustrating the steps for configuring the function interface call rules in this embodiment of the invention; Figure 5 This is a flowchart illustrating the steps for dynamically invoking a decision when executing an exposed interface list, as provided in an embodiment of the present invention. Figure 6 A flowchart illustrating the configuration steps for dynamically generating a user interface, as provided in an embodiment of the present invention. Figure 7 This is a structural diagram illustrating the overall module composition and collaborative relationships of the system provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a terminal for mounting interface interaction data provided in an embodiment of the present invention; Label Explanation: 1. A terminal for mounting interface interaction data; 2. Processor; 3. Memory. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Please refer to Figure 1 A method for mounting interface interaction data includes steps 110 to 140.

[0010] Step 110: Encapsulate the interface interaction function modules into editor components. For example, encapsulate the interface interaction function modules used to implement interface testing, monitoring, or auxiliary functions into editor components that conform to the operating system input method framework specifications.

[0011] Step 120: Load the editor component in the target process to enable the UI interaction modules. For example, load the editor component as an optional input method into the target application process of any interface, so that its functional modules reside in the process along with the editor component and are in a callable state.

[0012] Step 130: Create an inter-process communication channel based on the process identifier of the target process. For example, obtain the process identifier of the target process and establish a dedicated, lightweight data channel based on inter-process communication for the target process.

[0013] Step 140: Through an inter-process communication channel, dynamically configure the interface interaction data via the interface interaction function module of the target process. For example, the configuration management terminal or other processes send configuration instructions to the target process through the communication channel; after receiving the instructions, the target process drives its internally loaded editor component to perform corresponding dynamic configuration operations on the interface interaction data.

[0014] As described above, the beneficial effects of this invention are as follows: By encapsulating the interface interaction function modules into editor components and integrating them into the target process, a lightweight inter-process communication channel based on the target process identifier is constructed, and this communication channel is used to achieve dynamic configuration of interface interaction data. Deep integration of the function modules with the editor component framework enables non-intrusive, process-free function mounting of the target program interface, allowing the mounted functions to reside and take effect in any interface program along with the editor component. Simultaneously, through the communication channel mechanism based on process identifier mapping ports, automatic discovery, data exchange, and state synchronization between multiple processes are achieved, supporting complex multi-instance collaborative testing and monitoring tasks. While ensuring deep integration and flexible invocation of functions, the complexity of deployment and configuration is reduced, the convenience of interface interaction testing, dynamic monitoring, and auxiliary function expansion is improved, and an efficient and reliable technical foundation is provided for cross-process collaborative work.

[0015] Further, step 130 includes steps 131 to 134.

[0016] Step 131: Obtain the process ID of the target process. For example, obtain the unique process ID of the target process that currently has the editor component loaded.

[0017] Step 132: Generate a unique communication port number based on the process identifier. For example, directly map the process identifier value to an available communication port number, establishing a one-to-one correspondence of "process ID = port number", thereby generating a globally unique communication address for each process.

[0018] Step 133: Create a local inter-process communication connection based on the communication port number. For example, based on a unique communication port number, create and bind a Socket locally, start a listening service, and make the target process a communication node that can be addressed and connected to by other processes.

[0019] Step 134: Through the communication connection, the target process can achieve bidirectional listening with other processes. For example, through the communication connection, the target process can receive connection requests and data from other processes through its listening port, and can also act as a client to actively initiate connections to other known ports and send data, thereby realizing bidirectional peer-to-peer interaction capabilities between processes that can both passively respond and actively communicate.

[0020] As described above, by directly and simply mapping process identifiers to unique communication port numbers, not only is a unique network identity assigned to each process instance, but a decentralized, self-organizing, lightweight process communication network is also constructed. This design enables automatic discovery, real-time connection, and efficient data exchange between multiple processes, providing solid underlying communication support for subsequent implementation of advanced functions such as cross-process interface state synchronization, test task collaboration, and unified monitoring and management.

[0021] Further, step 140 includes steps 141 to 143.

[0022] Step 141: Receive dynamic configuration instructions. For example, receive dynamic configuration instructions from the configuration management interface or other cooperating processes through an inter-process communication channel. These instructions are used to request modifications or control over the target process's interface layout, functional rules, or interactive behavior.

[0023] Step 142: Read the corresponding configuration rule file according to the dynamic configuration instructions. For example, read the corresponding configuration rule file according to the dynamic configuration instructions to provide a structured and interpretable execution basis for subsequent dynamic interface rendering, function interface binding, rule application, and parameter validation.

[0024] Step 143: Based on the configuration rule file, call the corresponding function interface in the editor component. For example, parse the configuration rule file to trigger the corresponding function interface within the loaded editor component in the target process, completing the dynamic reconfiguration operation of the target process's interface and interaction logic. It should be noted that the function interfaces mentioned in this document refer to callable program interfaces encapsulated in the editor component for implementing interface interaction functions. As described above, by establishing a standardized configuration response chain, the dynamic configuration process is abstracted into an interpretable, reusable, and versionable file-driven model. By defining clearly defined configuration rule files, specific implementation details such as interface layout, function interface call order, and parameter constraints are encapsulated, allowing users to flexibly express their configuration intentions through natural language commands, graphical interface operations, or programmatic commands. This file-driven configuration model not only ensures the interpretability and reusability of the configuration process but also supports version management and collaborative editing of configuration content. This not only improves the flexibility and maintainability of the configuration but also makes it possible to dynamically generate configurations, collaboratively edit configurations by multiple users, and quickly roll back and switch configurations, providing controllable dynamic adaptability for complex and ever-changing interface interaction testing and monitoring needs.

[0025] Further, step 143 includes steps 1431 and 1432.

[0026] Step 1431: Parse the configuration rule file to obtain the interface call sequence, interface identifiers, and corresponding parameter constraints. For example, perform syntax and structure parsing on the configuration rule file to extract the sequentially arranged list of interface identifiers defined therein, as well as the data type, value range, dependency relationships, and other constraints of the input parameters corresponding to each interface.

[0027] Step 1432: Based on the interface call sequence, call the function corresponding to the first interface identifier, and process the input parameters according to parameter constraints during the call. For example, locate the corresponding function interfaces registered in the editor component in the target process in sequence according to the call sequence. When calling each interface, perform type validation, format conversion or logical verification on the incoming real-time parameters according to the parameter constraints defined in the configuration to ensure the compliance of the call and the reliability of the execution result.

[0028] As described above, a highly controllable and predictable function scheduling mechanism is constructed by establishing a standardized call chain from configuration parsing and sequential execution to parameter validation. The structured call sequence ensures that multiple functional interfaces are precisely scheduled and executed according to a predefined logical order, meeting the stringent requirements of complex interactive tasks regarding step timing. Meanwhile, the embedded parameter constraint validation rules perform real-time validation, type conversion, and compliance checks on input parameters when interfaces are called, preventing runtime errors or functional deviations caused by abnormal parameters from the outset. This reduces the risk of function execution errors caused by configuration mistakes or environmental differences and provides a solid and reliable underlying support for the batch execution of automated test cases, the timed triggering of monitoring tasks, and the repeatable rehearsals of complex workflows.

[0029] Furthermore, step 140 also includes steps 144 to 147.

[0030] Step 144: Read the external configuration file. For example, load the XML-formatted configuration file that describes the interface structure and style from a local storage path or network configuration center.

[0031] Step 145: Parse the UI component definitions in the external configuration file. For example, parse the XML file (Extensible Markup Language data file) to extract the defined UI control types, layout hierarchy, style attributes, and relationships between controls, forming an internal representation of the UI structure.

[0032] Step 146: Generate the corresponding user interface in the target process based on the interface component definitions. For example, call the interface rendering interface provided by the operating system to dynamically generate the corresponding user interface based on the parsed interface component definitions, and arrange and display it according to a preset layout.

[0033] Step 147: Bind the interactive elements in the user interface to the functional interfaces in the editor component. For example, register an event callback for each interactive control in the interface, and associate the callback with the corresponding functional interface encapsulated in the editor component, so that user operations on the controls can trigger the execution of the corresponding function.

[0034] As described above, by introducing an interface generation mechanism driven by an external configuration file, the presentation logic and functional logic of the user interface are completely separated. The interface structure, layout, and style can all be flexibly adjusted by modifying the configuration file without recompiling or restarting the target process. Simultaneously, event callback binding seamlessly connects the interface interaction with the underlying functional interfaces, achieving a lightweight integration model where the interface is configured and the interaction is functional. This not only supports rapid customization of exclusive operation interfaces for different test scenarios or user roles but also facilitates version management of interface layouts, multi-theme switching, and seamless adaptation, improving the scalability and maintainability of interface interaction testing and auxiliary tools.

[0035] Furthermore, steps 150 to 153 are included before step 143.

[0036] Step 150: Determine if the configuration rule file contains a list of exposed interfaces. For example, before making a call, parse the configuration rule file to determine if there is a list of interfaces marked as "public" or "overridable," which is explicitly specified by the user during the configuration process and made available for external modification.

[0037] Step 151: If a list of exposed interfaces exists, the functional interfaces in the list will be called in the order specified in the list. For example, if a list of exposed interfaces is detected, the system will ignore the original default calling order in the configuration file and instead strictly execute the calls according to the interface identifiers and their order defined in the exposed list.

[0038] Step 152: When calling each of the aforementioned functional interfaces, determine whether there are any exposed interface parameters that differ from the originally defined default parameters. For example, for each interface in the exposed list, compare its associated input parameters with the original default parameters defined for that interface in the configuration rule file to detect whether there are any inconsistencies in value, type, or structure with the second interface.

[0039] Step 153: If a difference exists, the exposed interface parameters will be used for the call; otherwise, the original default parameters will be used. For example, when a difference is detected, the system will use the parameter values ​​provided in the exposed list to override the default parameters and execute the interface call based on the overridden parameters; if no difference is detected, the original default parameters in the configuration rules file will continue to be used to complete the call.

[0040] As described above, by introducing two mechanisms—an exposed interface list and parameter difference overriding—configuration rules are given flexible and controllable runtime adjustment capabilities. Users can selectively expose certain interfaces and their calling order while preserving the integrity of the original configuration, and can dynamically inject modified parameters during invocation. This not only achieves a combination of configuration templates and personalization but also allows for flexible invocation needs in scenarios such as temporary testing and multi-environment adaptation without modifying the core rule file, enhancing the adaptability and efficiency of the configuration system.

[0041] Further, step 146 includes step 1461.

[0042] Step 1461: Based on the column structure information in the interface component definition, organize the functional interfaces into the corresponding columns according to their categories for display. For example, parse the column layout defined in the configuration rule file, identify the functional category labels corresponding to each column, and dynamically generate and arrange the functional interfaces related to that category in the editor component as controls within the corresponding column's interface area.

[0043] As described above, semantic organization of the user interface is achieved by logically associating the interface layout with the functional structure at the configuration level. The column-based mechanism not only makes the interface clearer and easier to use, but also intuitively reflects the logical relationships between functional modules, improving operational efficiency and user experience. This design supports the rapid customization of exclusive interfaces with different functional groups and layouts based on different test scenarios, user roles, or task types, further enhancing the system's configurability and scenario adaptability.

[0044] Furthermore, it also includes steps 160 to 162.

[0045] Step 160: When multiple processes have loaded the editor component, each process uses its own inter-process communication channel to use the process identifiers of other processes (excluding itself) as the communication nodes for those other processes' ports. For example, after starting the listening service, each process actively initiates a connection request to the local address using the port number of another known process to detect whether there are other active process instances that have loaded the same editor component.

[0046] Step 161: When the connection is successful, a peer-to-peer communication link is established between the corresponding processes. For example, if the connection is successfully established, the two processes confirm that they are communicable peer nodes and maintain a persistent session based on the established Socket connection, thus building a bidirectional, low-latency direct communication channel.

[0047] Step 162: Synchronize interface states or coordinate task execution among multiple processes via peer-to-peer communication links. For example, changes in the interface operation state, data updates, or task instructions in one process can be broadcast in real time to all connected peer processes through this link, thereby achieving interface view synchronization, test step collaboration, or load-balanced task scheduling among multiple processes.

[0048] As described above, a decentralized, self-organizing, lightweight process network is constructed through port mapping based on process identifiers and an automatic connection mechanism. This network enables multiple independently running process instances to automatically discover each other, establish direct connections, and achieve efficient state synchronization and task collaboration. This design is particularly suitable for scenarios such as multi-client testing, distributed interface monitoring, and cross-process debugging. It not only avoids the problems of requiring a central server or complex configuration in traditional solutions but also greatly improves the flexibility, real-time performance, and scalability of multi-process collaborative work, providing simple yet powerful underlying support for complex distributed interactive tasks.

[0049] Furthermore, it also includes steps 170 and 171.

[0050] Step 170: Receive and parse user input in natural language form. For example, by integrating a natural language processing module, receive user instructions in text or voice form, such as "create a test case for the login interface that includes username and password input", and perform word segmentation, semantic analysis, and intent recognition on the user input instruction.

[0051] Step 171: Map the parsed operation intent into configuration instructions or function call instructions for editor components. For example, match the identified intent with predefined configuration templates or function interfaces to generate corresponding structured instructions, such as calling the interface generation interface and passing in the specified control type and layout parameters, or triggering the test execution interface and binding the corresponding input data and validation logic.

[0052] As described above, by introducing a natural language interaction layer, the user threshold is lowered, enabling non-technical personnel to quickly configure complex test scenarios or auxiliary functions through intuitive language descriptions. This system semantically aligns natural language intents with underlying functional interfaces, achieving automated conversion from high-level descriptions to executable instructions. This not only improves the convenience and intelligence of configuration but also provides a technological foundation for more natural operating modes such as voice control and conversational interaction. This design further expands the system's applicable scenarios and human-computer interaction dimensions, giving it greater usability and widespread potential in areas such as automated testing and auxiliary tools.

[0053] Please refer to Figure 2The following describes specific application embodiments of this application. This application can apply the above solution to the functional testing and interface monitoring scenarios of game clients, including the following steps: S1. In the development environment, testers encapsulate functional modules such as test case generation, interface operation recording, and performance monitoring into IME (Input Method Editors) files that conform to the Windows input method framework specification, and register them as optional input methods through the system input method manager. This is equivalent to step 110 above.

[0054] S2. Start the target game client process. In the game process, activate the input method editor component registered in this application through the system input method switching interface, so that the test function module resides and takes effect in the game process along with the input method. This is equivalent to step 120 above.

[0055] S3. The system automatically obtains the process ID of the current game process (i.e., the process identifier mentioned above), and uses this ID as the communication port number to create a Socket listening service locally, establishing a unique inter-process communication channel for this game process. This is equivalent to step 130 above.

[0056] S4. Based on the testing requirements, decide whether to create an interface configuration file: if so, create an XML file describing the interface structure such as floating windows and charts (i.e., the aforementioned external file); at the same time, create corresponding functional extension interfaces for the testing functions. This corresponds to the judgment and execution branches of "Should we create an interface file?" and "Should we extend the interface?" in the diagram, which is equivalent to providing resource preparation for dynamic configuration in step 140 above.

[0057] S5. The test management terminal establishes a communication link with the game process by initiating a connection to this port. Testers send configuration commands through the management interface or custom quick statements to request the dynamic generation of a performance monitoring floating window interface. This is equivalent to the part in step 140 above that receives dynamic configuration commands through the inter-process communication channel.

[0058] S6. After receiving the instruction through the communication channel, the game process reads the preset XML interface configuration file, parses the layout and control information defined therein, and calls the interface rendering and function interfaces in the loaded editor component to dynamically draw the monitoring interface and bind interactive elements with corresponding functions, such as start recording and export data. This is equivalent to steps 144 to 147 above.

[0059] Through the above application examples, the present invention realizes a complete interface interaction data mounting process from function encapsulation, process embedding, communication establishment, dynamic configuration to multi-instance collaboration. It effectively solves the problems of traditional game testing tools being highly invasive, complex to deploy, and unable to collaborate across processes. While ensuring the stability of the target process, it provides highly flexible and real-time configurable testing and monitoring support, improving the efficiency and depth of game testing and debugging.

[0060] Please refer to Figure 3 The following describes a specific application embodiment of this application. This application can establish inter-process communication during game testing using the above solution, including the following steps: S21. Obtain the process ID (i.e., the process identifier mentioned above) of the current game client process. The system calls the operating system API to obtain the unique identifier of the target process that currently loads the input method editor component. Determine whether the process ID was successfully obtained. If successfully obtained, further detailed information about the process is obtained based on the process ID, including process name, window handle, executable file path, and other characteristic information. If the acquisition fails, the process terminates. This is equivalent to the process identifier acquisition step in step 130 above.

[0061] S22. Based on the acquired process ID, create an inter-process communication mechanism identified by that ID. Determine whether to use Socket communication: if yes, directly create and bind a local Socket using the process ID as the port number, serving as the dedicated communication endpoint for that process; if not, use other inter-process communication methods, such as named pipes or shared memory. This is equivalent to the specific implementation process of creating an inter-process communication channel based on the process identifier in step 130 above.

[0062] S23. After successfully creating the communication endpoint, the listening service is started. This process begins listening for other possible processes that have also loaded this input method editor component, i.e., listening for other Socket or IPC (International Patent Classification) endpoints with their respective process IDs as port numbers. Through the communication channel established in the above steps, the game process can establish connections with other discovered processes, enabling cross-process forwarding of test commands, real-time synchronization of monitoring data, and collaborative execution of multi-client test tasks. This is equivalent to the process in step 160 above that attempts to connect and form a peer-to-peer link.

[0063] Through the above application examples, this invention demonstrates how to automatically and reliably construct a lightweight inter-process communication network based on process IDs. This mechanism enables each game client instance to obtain a unique network identity and automatically integrate into a decentralized communication mesh, providing crucial underlying communication guarantees for subsequent distributed testing, unified monitoring, and cross-process debugging.

[0064] Please refer to Figure 4 The following describes a specific application embodiment of this application. This application can configure the function interface call rules in game testing using the above solution, including the following steps: S31. Create a configuration rule file for function interface calls. Based on testing requirements, define a set of call logic for function interfaces, including interface identifiers, call order, parameter constraints, and execution conditions. Determine whether the created rules are affected by AI. If marked as affected by AI, the AI ​​module is allowed to dynamically optimize and adjust the call parameters, order, or logic during rule execution; if not affected by AI, the rules will be strictly executed according to the static definition. This is equivalent to step 140 above.

[0065] S32. Determine whether to expose the rule list to the outside. If the rule list is exposed, it, along with its included interface identifiers and parameter structures, will be made available to external programs, such as the test management console or other processes, allowing them to view and fine-tune the list. If the rule list is not exposed, it will remain private and be used only within the current process. Perform the corresponding operation based on the exposure policy: If the rule list is exposed, external programs can access it through inter-process communication channels and temporarily override or adjust the interface parameters to achieve flexible runtime configuration; if the rule list is not exposed, all interface calls will strictly adhere to the original rule definitions, ensuring consistency and secrecy in the execution process. This is equivalent to steps 150 to 153 above.

[0066] Through the above application examples, this invention demonstrates how to structurally define and flexibly control the calling rules of functional interfaces. By introducing a rule exposure mechanism, it supports intelligent and adaptive call optimization, and provides multi-level permission management from completely closed to controllable open. This ensures that the test logic can guarantee the reliability of the core process while meeting the needs of dynamic adjustment and cross-process collaboration in complex scenarios, greatly enhancing the adaptability and maintainability of the testing framework.

[0067] Please refer to Figure 5 The following describes a specific application embodiment of this application. This application can implement the above solution in the dynamic invocation decision process when executing an exposed interface list, including the following steps: S41. Obtain the list of exposed interfaces and determine whether the call order should follow the order of this list. If yes, execute the calls strictly according to the order of the interfaces in the exposed list; if no, maintain the original call order defined in the configuration file or rules. This is equivalent to step 151 above.

[0068] S42. When calling each interface, determine whether there is any exposed interface data that differs from the original definition. If there is a difference, use the interface parameter data provided in the exposed list for the call; otherwise, continue to use the default parameter data of the original definition for the call. This is equivalent to steps 152 and 153 above.

[0069] Through the above application examples, this invention demonstrates how to dynamically apply exposure rules during the interface call execution phase. This decision-making process ensures that the system can intelligently integrate static configuration and dynamic coverage during execution: respecting the flexible adjustment intentions provided by the external exposure list while maintaining the stability of the original configuration when there are no differences. This mechanism is particularly suitable for scenarios requiring A / B testing, multi-environment parameter switching, or runtime hotfixes. While ensuring the controllability of the main call process, it provides fine-grained, real-time intervention capabilities for testing and operations, thereby improving the system's response speed to external changes and the overall configuration flexibility.

[0070] Please refer to Figure 6 The following describes a specific application embodiment of this application. This application can incorporate the above solution into the configuration process of dynamically generating a game test monitoring interface, including the following steps: S51. Define the XML structure of the interface components and determine whether to use existing encapsulated functional interfaces: if yes, automatically generate a compliant XML component description by calling the corresponding interface, such as the interface control generation interface; if no, manually edit and build the XML file to explicitly define the control type, attributes, and hierarchical relationship. This is equivalent to steps 144 and 145 above.

[0071] S52. Lay out the defined interface components and further determine whether the interface needs to be organized by function columns: if so, the AI ​​module can be called to automatically create a column structure based on functional logic and classify the relevant components into the corresponding columns; if not, a tiling or preset layout method can be directly used. After completing the layout, save or import the final interface configuration as an XML file. This is equivalent to steps 146 and 1461 above.

[0072] Through the above application examples, this invention provides a method for flexibly and efficiently defining and laying out user interfaces. This process supports automated configuration generation by calling existing interfaces, and also allows for manual fine-tuning. Furthermore, it introduces AI-powered intelligent column layout, enabling the interface layout to not only reflect visual structure but also embody the inherent functional logic. This simplifies the construction and maintenance of complex monitoring interfaces, test panels, and other interactive interfaces, allowing testers to quickly respond to interface customization needs in different test scenarios, and improving the usability and adaptability of the testing tools themselves.

[0073] Please refer to Figure 7 The following describes specific application embodiments of this application. This application can explain the composition and cooperation relationship of each module at the overall architecture level of the above solution, including the following steps: S61. The input method editor consists of an IME file, which serves as a functional carrier and contains all the logic and resources required to implement interface interaction data mounting.

[0074] S62. Determine whether the IME file is assembled from a dataset. If so, the dataset is a structured collection of functions, containing at least the following core modules: a communication module for establishing connections, a rule module for managing call logic, a UI module for dynamically generating interfaces, and an AI module for intelligent expansion. Furthermore, if it is necessary to filter inter-process communication methods, a suitable one can be selected from communication series such as Socket, pipes, and shared memory as the default implementation.

[0075] S63. Collaborative Work Among Modules: The rules module consists of a series of functional interfaces and their calling rules, and the visibility and calling priority of these interfaces can be controlled by an exposure list; the interface module dynamically renders and generates the user interface based on the XML configuration file and the registered functional interfaces; simultaneously, the AI ​​module provides intelligent extensions and auxiliary decision-making services for rule configuration, interface generation, and natural language interaction. Specifically, the establishment of the communication module corresponds to step 130 above, the definition and application of the rules module corresponds to steps 140 to 143 and steps 150 to 153, the operation of the interface module corresponds to steps 144 to 147, and the integration of the AI ​​module corresponds to steps 170 and 171.

[0076] Through the above application examples, this solution architecture, packaged in an input method file, integrates four major functional modules—communication, rules, interface, and AI—in a highly cohesive and loosely coupled manner. Each module has a clear division of labor and can collaborate flexibly: the communication module is responsible for establishing crucial channels between processes, the rules module defines behavioral logic, the interface module provides the interactive appearance, and the AI ​​module injects intelligent decision-making. This design not only ensures the overall scalability and maintainability of the system but also enables this solution to adapt to a wide range of application scenarios, from simple interface operation recording to complex multi-process intelligent testing, demonstrating the versatility and forward-thinking nature of the system design.

[0077] Please refer to Figure 8 A terminal 1 for mounting interface interaction data includes a memory 3, a processor 2, and a computer program stored on the memory 3 and running on the processor 2. When the processor 2 executes the computer program, it implements each step of the above-mentioned method for mounting interface interaction data.

[0078] In summary, this invention provides a method and terminal for mounting interface interaction data based on an input method framework, constructing a lightweight functional extension system with an editor component as the carrier, process-identified communication as the link, and dynamic configuration as the core. This method encapsulates interactive functional modules such as testing and monitoring into standard input method components, achieving zero-intrusion, deployment-free functional mounting of the target application interface, fundamentally avoiding the stability risks and compatibility burdens brought about by traditional technology injection or independent process solutions.

[0079] The system constructs a lightweight inter-process communication channel based on the unique identifier of the target process, forming a decentralized, self-discovering process collaboration network. It supports automatic networking, state synchronization, and task coordination among multiple instances, providing native support for distributed testing and unified monitoring. At the functional execution level, the system, driven by structured configuration rule files, dynamically generates the interface layout, serializes calls to functional interfaces, and performs constraint validation on input parameters, ensuring the controllability, repeatability, and predictability of the interaction process.

[0080] Furthermore, by introducing a rule exposure mechanism and an AI extension module, the system provides multi-level flexible control capabilities, ranging from static configuration to dynamic adjustment, and from manual operation to intelligent interaction. Users can modify the interface layout, adjust test logic, or trigger complex tasks in real time without restarting the target program through a graphical interface, natural language commands, or configuration files, thereby improving the responsiveness and adaptability of testing and monitoring activities.

[0081] This system is suitable for scenarios such as game testing, software debugging, automation assistance, and interactive monitoring. By building a complete, lightweight, and intelligent interface interaction mounting and collaboration framework, it effectively solves the long-standing technical pain points of traditional solutions, such as low scalability and security complexity, and improves the operational efficiency, system maintainability, and cross-process collaboration capabilities in related fields.

[0082] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for mounting interface interaction data, characterized in that, include: Encapsulate the interface interaction function modules as editor components; Load the editor component in the target process to enable the interface interaction function module; An inter-process communication channel is created based on the process identifier of the target process; The inter-process communication channel enables dynamic configuration of interface interaction data through the interface interaction function module of the target process.

2. The method for mounting interface interaction data according to claim 1, characterized in that, The step of creating an inter-process communication channel based on the process identifier of the target process includes: Obtain the process identifier of the target process; A unique communication port number is generated based on the process identifier; A local inter-process communication connection is created based on the communication port number; The communication connection enables bidirectional monitoring between the target process and other processes.

3. The method for mounting interface interaction data according to claim 1, characterized in that, The step of dynamically configuring interface interaction data through the interface interaction function module of the target process via the inter-process communication channel includes: Receive dynamic configuration commands; Read the corresponding configuration rule file according to the dynamic configuration instructions; Based on the configuration rule file, the corresponding function interface in the editor component is called.

4. The method for mounting interface interaction data according to claim 3, characterized in that, The step of calling the corresponding function interface in the editor component based on the configuration rule file includes: Parse the configuration rule file to obtain the interface call sequence, interface identifier, and corresponding parameter constraints; Based on the interface call sequence, the function corresponding to the first interface identifier is called, and the input parameters are processed according to the parameter constraints during the call process.

5. The method for mounting interface interaction data according to claim 1, characterized in that, The method of dynamically configuring interface interaction data through the interface interaction function module of the target process via the inter-process communication channel further includes: Read external configuration files; Parse the UI component definitions in the external configuration file; Based on the interface component definition, a corresponding user interface is generated in the target process; Bind the interactive elements in the user interface to the functional interfaces in the editor component.

6. The method for mounting interface interaction data according to claim 3, characterized in that, Before calling the corresponding function interface in the editor component based on the configuration rule file, the following steps are included: Determine whether the configuration rule file contains a list of exposed interfaces; If the list of exposed interfaces exists, the functional interfaces in the list will be called in the order specified in the list. When calling each of the aforementioned functional interfaces, it is determined whether there are any exposed interface parameters that differ from the originally defined default parameters; If the interface exists, the exposed interface parameters will be used for the call; otherwise, the default parameters defined in the original interface will be used.

7. The method for mounting interface interaction data according to claim 5, characterized in that, The step of generating a corresponding user interface in the target process according to the interface component definition includes: Based on the column structure information in the interface component definition, the functional interfaces are organized into the corresponding columns according to their categories for display.

8. The method for mounting interface interaction data according to claim 1, characterized in that, Also includes: When there are multiple processes that have loaded the editor component, each process uses its own inter-process communication channel to use the process identifier of other processes (excluding itself) as the communication node of the other processes' ports. When the connection is successful, a peer-to-peer communication link is established between the corresponding processes; Through the peer-to-peer communication link, interface states can be synchronized or tasks can be coordinated among multiple processes.

9. The method for mounting interface interaction data according to claim 1, characterized in that, Also includes: Receive and parse user input in natural language form; The parsed operation intent is mapped into configuration instructions or function call instructions for the editor component.

10. A terminal for mounting interface interaction data, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps of the interface interaction data mounting method according to any one of claims 1 to 9.

Images