Communication method and system based on instant messaging client

Abstract

The invention provides a communication method and system based on an instant messaging client, and the method comprises the steps: a host process responds to first user input information of the instant messaging client, calls an inter-process client communication code to convert the first user input information into a first data package, and transmits the first data package to an agent process; the agent process calls an inter-process server communication code to convert the first data packet into second user input information, calls a corresponding software development kit (SDK), and sends the second user input information to the SDK; the proxy process receives first response information fed back by the SDK, calls an inter-process server communication code to convert the first response information into a second data packet, and sends the second data packet to the host process; and the host process calls the inter-process client communication code to convert the second data packet into second response information. The instant messaging client and the SDK are decoupled into inter-process communication, the SDK is isolated, and the running robustness of the instant messaging client is improved.

Description

Technical Field

[0001] This application relates to the field of software design and development technology, and in particular to a communication method based on an instant messaging client, a communication system based on an instant messaging client, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Instant messaging products refer to software applications or services that enable real-time, two-way exchange of multimedia information such as text, voice, video, and files over the Internet or a dedicated network. To meet diverse user business needs, instant messaging products often integrate third-party functionalities.

[0003] Currently, the integration of third-party functions into instant messaging products is primarily achieved through the integration of Software Development Kits (SDKs). An SDK is a pre-built package of integrated software components for specific functions or services, constructed by software vendors or third-party developers. When integrating an SDK with an instant messaging product, a direct call approach is used. That is, the SDK's library files are directly compiled and linked into the main process of the instant messaging client, and its functionality is accessed directly through function call interfaces. In this traditional model, the main process and the SDK run in the same memory space and system process, resulting in a high degree of coupling between them in terms of technology stack, resource management, and error handling.

[0004] However, when the SDK experiences runtime failures due to its own defects, memory out-of-bounds errors, or resource deadlocks, the failure will be directly transmitted to the main process of the instant messaging client, causing the client to crash or become blocked uncontrollably, thereby reducing the stability of the instant messaging client. Summary of the Invention

[0005] The purpose of this application is to provide a communication method, a communication system, a computer device, a computer-readable storage medium, and a computer program product based on an instant messaging client, so as to improve the stability of the instant messaging client.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a communication method based on an instant messaging client. The method is applied to a communication system based on an instant messaging client, the system including a main process and a proxy process of the instant messaging client. The method includes: the main process responding to first user input information from the instant messaging client, calling inter-process client communication code to convert the first user input information into a first data packet, and sending the first data packet to the proxy process. The inter-process client communication code is used to serialize and encapsulate the first user input information based on the interface description between the main process and the proxy process. The proxy process calling inter-process server communication code to convert the first data packet into second user input information, calling the corresponding software development kit (SDK), and sending the second user input information to the SDK. The inter-process server communication code is used to deserialize and decapsulate the first data packet based on the interface description between the main process and the proxy process. The proxy process receiving first response information from the SDK, calling inter-process server communication code to convert the first response information into a second data packet, and sending the second data packet to the main process. The main process calling inter-process client communication code to convert the second data packet into second response information and outputting the second response information.

[0007] Compared to existing technologies, the communication method based on an instant messaging client provided in the first aspect of this application decouples the direct coupling between the traditional instant messaging client and SDK into a collaborative working mode of inter-process communication through client / process-server communication code generated by standardized interface description. This allows the main process and SDK to run in mutually isolated independent process spaces, which not only effectively isolates the direct impact of potential SDK crashes, memory leaks, or compatibility issues on the stability of the main client, but also enables unified and flexible access to SDKs with different technology stacks through the abstraction layer of interface description. Thus, while ensuring normal functional integration, it significantly improves the overall operational robustness and system compatibility of the instant messaging client.

[0008] In other embodiments provided in this application, the system further includes a compiler; prior to communication based on the instant messaging client, the method further includes: the compiler receiving an interface description file input by the user using a non-programming language, wherein the interface description file is used to describe the service interface, method signature, and data structure for interaction between the main process and the agent process; the compiler uses inter-process communication (IPC) logic to convert the interface description file into inter-process client communication code and inter-process server communication code respectively, so that the inter-process client communication code is deployed at the location corresponding to the main process, and the inter-process server communication code is deployed at the location corresponding to the agent process.

[0009] By introducing a dedicated compiler to parse interface description files written in non-programming languages ​​and automatically generating client and inter-process server communication code that precisely corresponds to the interface descriptions, the automated and standardized generation of communication bridging code between the main process and the proxy process is achieved. This mechanism simplifies the complex development of inter-process communication into a declarative description of SDK functional interfaces. This not only significantly reduces the development cost and technical threshold for building isolated proxies for SDKs with different technology stacks and interface specifications, but also ensures the correctness and consistency of the communication layer. From the engineering implementation perspective, it guarantees the reliable implementation and efficient deployment of multi-process isolation architecture, enabling instant messaging clients to quickly and securely integrate various third-party functions.

[0010] In other embodiments provided in this application, inter-process communication (IPC) logic is used to convert the interface description file into inter-process client communication code and inter-process server communication code, respectively. This includes: parsing the interface description file to generate an Abstract Syntax Tree (AST), which represents the hierarchical relationship between service interfaces, method signatures, and data structures; generating inter-process client communication code based on the AST, wherein the inter-process client communication code is configured to: provide a callable interface consistent with the method signature in the service interface; automatically serialize the input parameters into an inter-process communication data format when the callable interface is invoked, and send it to the proxy process via the IPC channel; receive response data from the proxy process, deserialize it into a local object, and return it; and generating inter-process server communication code based on the AST, wherein the inter-process server communication code is configured to: listen to the IPC channel and receive request data from the main process; deserialize the request data to identify the target method and parameters; invoke the business logic implementation corresponding to the service interface; and serialize the business logic execution result into an inter-process communication data format and return it to the main process via the IPC channel.

[0011] By defining an automated generation chain from interface description to abstract syntax tree, and then to the specific communication code at both ends, a complete description-interface development paradigm is constructed. This transparently maps the main process's calls to the SDK into secure inter-process communication, enabling developers to obtain type-safe, call-standardized isolated call capabilities without manually writing any low-level IPC code. This greatly improves integration efficiency and fundamentally eliminates the risk of coding errors caused by manually implementing communication bridging, ensuring the stability and robustness of the multi-process architecture.

[0012] In other embodiments provided in this application, after outputting the second response information, the method further includes: performing at least one of the following three items: obtaining the timestamp of the last time the proxy process was called; calculating the time difference between the timestamp and the current time; determining whether the time difference is greater than a preset time threshold; obtaining the status data corresponding to the proxy process; determining whether the status data indicates that the proxy process is abnormal; obtaining the remaining resources of the device where the proxy process is located; determining whether the remaining resources are less than a preset remaining resource threshold; if at least one of the above determinations is not true, then closing the proxy process.

[0013] By introducing an intelligent monitoring and recycling strategy based on timestamps, running status, and system resources, dynamic management of the agent process lifecycle is achieved. When SDK functions are idle, abnormal signs appear, or system resources are scarce, critical resources such as memory and CPU occupied by the agent process are automatically and promptly released. This effectively prevents system performance degradation and stability risks caused by agent process zombies, memory leaks, or resource exhaustion. While ensuring that functions are available on demand, the overall resource utilization and long-term operational stability of the client are optimized.

[0014] In other embodiments provided in this application, the status data includes the corresponding memory size and the average time and failure rate of the most recent n calls, where n is an integer greater than 1; determining whether the status data indicates that the agent process is abnormal includes: determining whether the growth rate of the memory size exceeds a preset growth threshold; determining whether the average time exceeds a preset time threshold, wherein the preset time threshold is a dynamic change that is negatively correlated with the load of the device where the agent program is located; and determining whether the failure rate exceeds a preset failure threshold.

[0015] By defining a refined anomaly assessment indicator system consisting of memory growth rate, dynamic response time, and call failure rate, a precise and quantitative evaluation of the agent process's health is achieved. Specifically, the memory growth rate alerts for potential leaks, the dynamic response time threshold takes into account device load, and the failure rate directly reflects service reliability. The combination of these three indicators can keenly identify early signs of SDK malfunctions or resource overruns, thereby triggering preventative recycling or alerts. This transforms passive crash handling into proactive anomaly prevention, further enhancing the system's resilience and self-healing capabilities in complex operating environments.

[0016] In other embodiments provided in this application, after responding to the first user input information from the instant messaging client, the method further includes: determining a service type or SDK identifier based on the first user input information; searching an internal configuration table to determine the agent process identifier corresponding to the service type or SDK identifier, wherein the internal configuration table includes each service type or SDK identifier and its corresponding agent process identifier, and different agent processes correspond to different SDKs; sending a probe request to the agent process corresponding to the determined agent process identifier; if a response to the probe request is received within a preset time interval, then the step of sending a first data packet to the agent process is executed; if no response to the probe request is received within the preset time interval, then an error is reported to the user or a new agent process is started according to business requirements, and the library file of the SDK corresponding to the determined agent process identifier is loaded to communicate with the SDK corresponding to the determined agent process identifier.

[0017] By establishing a dynamic mapping and liveness detection mechanism between business / SDK processes and proxy processes, intelligent routing and high availability management of multi-SDK proxy clusters are achieved. Based on specific business requests, the system automatically locates and ensures the target proxy process is in a ready state. In the event of process anomalies, it can seamlessly rebuild the process, thus guaranteeing the availability of any SDK function and avoiding single-point failures affecting the overall service. Simultaneously, it supports the isolated parallel operation of multiple SDKs, greatly enhancing the system's service assurance capabilities and architectural resilience when facing complex function integration.

[0018] In other embodiments provided in this application, there are multiple SDKs, and different SDKs correspond to different proxy processes; after responding to the first user input information of the instant messaging client, the method further includes: determining a first target SDK associated with the SDK corresponding to the first user input information; and starting the proxy process corresponding to the first target SDK.

[0019] By establishing relationships between SDKs, when the main process calls the current SDK, it can pre-start the proxy processes corresponding to other SDKs associated with it. By leveraging the continuity of calls between functions, the initialization and resource loading of associated proxy processes are completed in advance, thereby eliminating the process startup delay that may be caused by subsequent calls, smoothing the user experience, and optimizing the response speed of associated function chains while ensuring strict on-demand startup to save resources.

[0020] In other embodiments provided in this application, there are multiple SDKs, and different SDKs correspond to different proxy processes; before responding to the first user input information of the instant messaging client, the method further includes: obtaining the user's usage habits for each SDK of the instant messaging client; if the usage habits indicate that the two SDKs are used sequentially, then after the proxy process corresponding to the first SDK is started, the proxy process corresponding to the second SDK is started; if the usage habits indicate that the proxy process corresponding to the second target SDK is started at a specified time, then the proxy process corresponding to the second target SDK is started before the specified time.

[0021] By analyzing historical user behavior data, the system intelligently predicts and pre-starts the proxy processes corresponding to SDKs that may be used subsequently. This shifts resource loading from the instant the user initiates a call to before the high-probability call indicated by usage habits, thus completing the function warm-up without the user's awareness. It effectively hides the waiting time for process startup and initialization, achieving further optimization of user experience response speed under the principle of on-demand resource allocation.

[0022] A second aspect of this application provides a communication system based on an instant messaging client. The system includes a main process and a proxy process of the instant messaging client. The main process is used to respond to first user input information from the instant messaging client, call inter-process client communication code to convert the first user input information into a first data packet, and send the first data packet to the proxy process. The inter-process client communication code is used to serialize and encapsulate the first user input information based on the interface description between the main process and the proxy process. The proxy process is used to call inter-process server communication code to convert the first data packet into second user input information, call the corresponding software development kit (SDK), and send the second user input information to the SDK. The inter-process server communication code is used to deserialize and decapsulate the first data packet based on the interface description between the main process and the proxy process. The proxy process is also used to receive first response information from the SDK, call inter-process server communication code to convert the first response information into a second data packet, and send the second data packet to the main process. The main process is also used to call inter-process client communication code to convert the second data packet into second response information and output the second response information.

[0023] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of the first aspect.

[0024] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of the first aspect.

[0025] The fifth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of the first aspect.

[0026] The communication system based on an instant messaging client provided in the second aspect of this application, the computer device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect have the same or similar beneficial effects as the communication method based on an instant messaging client provided in the first aspect. Attached Figure Description

[0027] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 This is a schematic diagram illustrating an application scenario of the communication method based on an instant messaging client in this application embodiment; Figure 2 This is a flowchart illustrating the communication method based on an instant messaging client in the embodiments of this application. Figure 1 ; Figure 3 This is a schematic diagram illustrating the call sequence of the communication method based on an instant messaging client in an embodiment of this application; Figure 4 This is a flowchart illustrating the communication method based on an instant messaging client in the embodiments of this application. Figure 2 ; Figure 5 This is a schematic diagram of the communication system based on an instant messaging client in the embodiments of this application. Figure 1 ; Figure 6 This is a schematic diagram of the communication system based on an instant messaging client in the embodiments of this application. Figure 2 ; Figure 7 This is a schematic diagram of the structure of the computer device in the embodiments of this application. Detailed Implementation

[0028] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0029] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0030] The current method of directly integrating the SDK into the main process of the instant messaging client means that runtime failures of the SDK can directly cause the main instant messaging process to crash, seriously threatening the overall stability of the client.

[0031] In view of this, embodiments of this application provide a communication method, a communication system, a computer device, a computer-readable storage medium, and a computer program product based on an instant messaging client. This decouples the traditional direct coupling between the instant messaging client and the SDK into a main process-proxy process separation architecture that interacts through standardized interface descriptions and automatically generated communication code. The main process initiates calls through a local proxy interface; after serialization, an independent proxy process actually executes the SDK functions and returns the results. This isolates potential SDK crashes and compatibility issues within the proxy process, ensuring the stable operation of the main client.

[0032] First, the application scenarios of the communication method based on an instant messaging client provided in the embodiments of this application will be described.

[0033] Figure 1 This is a schematic diagram illustrating an application scenario of the communication method based on an instant messaging client in this application embodiment. See [link / reference] Figure 1 As shown, this scenario may include: an instant messaging client 11 and an SDK 12. The instant messaging client 11 may include: a main process 111 and an agent process 112.

[0034] The main process 111 and the proxy process 112 also constitute the communication system based on the instant messaging client in this embodiment. The instant messaging client 11 may further include: inter-process client communication code, inter-process server communication code, process management and routing module, compiler and its artifacts, etc. These are not described in... Figure 1 The successful bidder will be detailed later.

[0035] The main process 111 is the primary execution entity that starts the instant messaging client 11 at the operating system level and directly carries out the core application logic (such as the user interface, contact list, and basic message sending and receiving functions) and user interaction. For example, in the Lanxin client, the chat window, contact list, and entry interface for initiating audio and video calls that the user sees after logging in are all rendered and responded to by the main process.

[0036] Proxy process 112 is an independently running auxiliary process that provides specific third-party function call services to the main process 111 of the instant messaging client 11. Its core role is to act as a dedicated isolated container and communication intermediary for external SDKs. This process is created and managed by the main process 111 on demand. Inside, it loads, initializes, and actually runs the SDK code, and interacts with the main process 111 through inter-process communication. This confines potential instability, compatibility issues, or resource conflicts of the SDK within its own process space, preventing them from directly affecting the stability of the main process. For example, when a Lanxin user needs to perform unified identity authentication, the main process will start or wake up a proxy process dedicated to authentication.

[0037] In actual operation, when a user enters their username and password on the login screen of the main process 111, the main process 111 first checks whether the dedicated authentication proxy process 112 is alive. If it is not running, it immediately creates the process. After starting, the proxy process 112 loads and initializes the third-party authentication SDK 12. At this time, the main process 111 serializes the user credentials into a data packet and sends it to the proxy process 112 through internal communication bridging code. After receiving the data packet, the proxy process 112 deserializes it to obtain the original parameters and calls the actual authentication interface of SDK 12 for verification. After SDK 12 returns the authentication result, the proxy process 112 serializes the result and sends it back to the main process 111. Finally, the main process 111 deserializes the result and updates the login screen state. The entire process is completed through inter-process communication, which isolates any exceptions of the third-party authentication SDK within the proxy process, ensuring smooth and stable interaction of the main client.

[0038] In addition to the identity authentication scenarios mentioned above, the method provided in this application can also be applied to various SDK-related scenarios. For example, screen sharing and remote collaboration require calling a specific screen projection SDK; high-definition video conferencing requires access to a dedicated codec and device management SDK; secure file preview requires calling a format conversion and sandbox detection SDK; intelligent customer service dialogue requires integrating a natural language processing AI engine; hardware device connection (such as card readers and printers) requires calling a device driver SDK; and payment functions require integrating a financial-grade security encryption SDK. Each function can be carried by an independent proxy process, ensuring that any abnormality or resource monopoly of any functional module does not affect the continuity of the core instant messaging service.

[0039] Next, the communication method based on an instant messaging client provided in the embodiments of this application will be described in detail.

[0040] Figure 2 This is a flowchart illustrating the communication method based on an instant messaging client in the embodiments of this application. Figure 1 See Figure 2 As shown, the method may include: S21: In response to the first user input information from the instant messaging client, the main process calls the inter-process client communication code to convert the first user input information into a first data packet and sends the first data packet to the agent process.

[0041] When a user performs an operation through an instant messaging client, and the client needs to use the SDK to implement the corresponding function, the main process of the instant messaging client obtains the first user input information corresponding to the operation.

[0042] The first user input information refers to an initial interactive instruction initiated by a user of an instant messaging client through a graphical user interface (UI) to call a function provided by a third-party SDK. Essentially, it is a functional event triggered by the user within the client's main process, containing an identifier for the target function and necessary input parameters. For example, in a login scenario, a user enters "Account: zhangsan, Password: 123456" in the login box and clicks the "Login" button. The login action and the accompanying account and password data together constitute the first user input information. Another example is in a screen sharing scenario, where a user clicks the "Start Sharing" button in a video conferencing window and selects "Share Entire Screen" from the pop-up menu. The button click and the selected option here constitute the first user input information.

[0043] After the main process receives the first user input, it then calls the inter-process client communication code specifically generated to enable communication with the agent process, thus initiating the interaction process with the agent process.

[0044] The inter-process client communication code is used to serialize and encapsulate the first user input information based on the interface description between the main process and the agent process.

[0045] The interface description here is a crucial technical document. It doesn't refer to a regular interface in a programming language, but rather a structured declaration file predefined by the developer and written in a Domain-Specific Language (DSL). This file precisely describes the service interfaces (such as method names, parameter types, and return value structures) that the main process needs from the proxy process, but it doesn't contain any actual business logic. The inter-process client communication code is automatically generated at compile time based on the specifications of this interface description file. Its core function is to convert the first user input information (such as function calls and parameter objects) at the high-level language level, conforming to the interface specification, strictly following the format in the description, into a standardized, low-level byte sequence (i.e., the first data packet) that can be transmitted between processes, thereby ensuring type safety and data consistency in cross-process calls.

[0046] For example: / / Example of an API description file (auth_service.idl) namespace Im { interface Authentication { int32 Login(string username, string password); oneway void onAuthStatus(int32 status); }; }; / / Automatically generated inter-process client communication code (simplified example auth_service.h) can generate code in different programming languages ​​as needed to adapt to different technology stacks. namespace Im { / / Interface class definition for IPC, generated by IDL. Business logic that needs to respond to the onAuthStatus callback function needs to inherit this interface. class Authentication { int Login(std::string username, std::string password) { / / Construct the request data packet based on the interface description std::vector<uint8_t> request = Encode("Login", username,password); / / Serialization std::vector<uint8_t> response = SendToAgent(request); / / Inter-process communication return Decode<int32_t> (response); / / Deserialization } / / Used for callbacks, this is just for demonstration purposes. void onAuthStatus(int32 status) = 0 } } During the specific conversion, after receiving the first user input (such as the Login("user","pwd") function call), the inter-process client communication code first identifies the method name Login and the parameter list based on the pre-loaded interface description file. Then, according to the data structures defined in the description (such as field order, type, and length identifier), it encodes the string parameters "user" and "pwd" into byte sequences respectively, adds the method identifier and necessary protocol headers (such as packet length and request identifier (Identifier, ID)), and finally assembles them into a complete and standard-formatted binary data block, namely the first data packet. This data packet completely removes the type information of the high-level language, becoming a low-level message unit that can be transmitted losslessly in the inter-process communication channel.

[0047] When sending data, the client sends the first encapsulated or tagged data packet to the local agent process via a local socket or pipe.

[0048] S22: The agent process calls the inter-process server communication code to convert the first data packet into the second user input information, calls the corresponding software development kit (SDK), and sends the second user input information to the SDK.

[0049] The inter-process server communication code is used to deserialize and deseal the first data packet based on the interface description between the main process and the agent process.

[0050] In other words, the inter-process server communication code decodes and reassembles the received, serialized first data packet according to the data format and communication protocol rules specified in the predefined, standardized interface description file. Based on the interface description, the runtime decapsulation logic of the inter-process server communication code (including how to identify data packet boundaries, how to parse the byte stream to reconstruct the specific method call identifier and parameter object, etc.) is entirely generated or driven by the interface description file. This ensures that both communicating parties across processes can accurately and error-free reverse-convert the serialized binary data stream (first data packet) back into a program object (second user input information) that can be recognized and processed within the proxy process.

[0051] During the specific conversion, the proxy process locates the specific third-party SDK instance that has been loaded and initialized within it, based on the interface or business type identified in this communication. Then, it directly calls the API function provided by that SDK that matches the interface description. The proxy process passes the second user input information as parameters (such as the username and password fields in the login request object) to the corresponding entry function of the SDK through a local function call.

[0052] After receiving parameters from the proxy process, the SDK begins executing its predefined functional logic within its own process space. For example, for the authentication SDK, it uses the received username and password to perform network communication to connect to a remote authentication server, perform local credential verification, or call system security interfaces. After completing its core business logic (such as interacting with the server and verifying credentials), the SDK generates a processing result. This result is typically a structured data object or a simple status code (such as an authentication result object containing a success boolean value and a token string), and is then returned to the proxy process via a function return value or callback function.

[0053] After receiving the processing result (i.e., the first response information) returned by the SDK, the proxy process immediately initiates the response feedback process. The proxy process calls the inter-process server communication code, taking the first response information (such as an authentication result object) as input, and serializes and encapsulates it according to the same interface description rules agreed upon with the main process, generating a formatted second data packet. Then, the proxy process sends the second data packet back to the main process through the established IPC channel (such as a socket or pipe), thus completing a full "request-response" proxy loop. Upon receiving this data packet, the main process continues deserialization and finally presents the result to the user.

[0054] S23: The agent process receives the first response information from the SDK, calls the inter-process server communication code to convert the first response information into a second data packet, and sends the second data packet to the main process.

[0055] Upon receiving the first response information (such as a structure object containing authentication status and token) returned by the SDK through a function call, the proxy process immediately invokes its internal inter-process server communication code to serialize and encapsulate the first response information. Specifically, after receiving the first response information, the inter-process server communication code first identifies the method name "Login" and the parameter list based on the preloaded interface description file. Then, according to the data structure defined in the description, it encodes the string parameters "user" and "pwd" into byte sequences respectively, adds the method identifier and necessary protocol headers, and finally assembles them into a complete and standard-formatted binary data block, i.e., the second data packet. Subsequently, the proxy process sends the second data packet to the main process through a predetermined IPC channel (such as a local socket connection or pipe).

[0056] S24: The main process calls the inter-process client communication code to convert the second data packet into the second response information and outputs the second response information.

[0057] After receiving the second data packet from the agent process through its monitored IPC channel, the main process immediately invokes its internal inter-process client communication code to parse the packet. The inter-process client communication code performs deserialization based on the same set of interface description rules shared with the agent process. First, it parses the packet header to confirm the transaction ID and method identifier. Then, it decodes the byte stream field by field according to a predefined data structure (such as a login response structure containing a status integer field), reconstructing it into a local program object that can be directly used in the main process's memory space—the second response information (such as a specific status code). Finally, the main process passes the second response information to the upper-layer business logic module, which then performs subsequent operations based on the information content (such as updating the user interface to display "Login successful" and redirecting to the main interface, or storing the authentication token for subsequent API calls).

[0058] As can be seen from the above, the communication method based on an instant messaging client provided in this application decouples the direct coupling between the traditional instant messaging client and SDK into a collaborative working mode of inter-process communication through client / process-server communication code generated by a standardized interface description. This allows the main process and the SDK to run in mutually isolated independent process spaces, which not only effectively isolates the direct impact of potential SDK crashes, memory leaks, or compatibility issues on the stability of the main client, but also enables unified and flexible access to SDKs with different technology stacks through the abstraction layer of the interface description. Thus, while ensuring normal functional integration, it significantly improves the overall operational robustness and system compatibility of the instant messaging client.

[0059] Furthermore, as a response to Figure 2 In a refinement and extension of the method shown, this application also provides a communication method based on an instant messaging client.

[0060] Figure 3 This is a schematic diagram illustrating the call sequence of the communication method based on an instant messaging client in an embodiment of this application. See [link / reference]. Figure 3 As shown, the timing sequence is as follows: The user initiates a login request by entering login information into the instant messaging product (i.e., the main process). Upon response, the main process checks and starts a proxy process in its own independent process space. Once started, the proxy process loads and initializes the third-party authentication SDK within its own process. Subsequently, the main process sends the user's login information to the proxy process via inter-process communication. After receiving the information, the proxy process calls the initialized SDK for authentication. Once the SDK completes processing, it returns the authentication result to the proxy process. The proxy process then transmits the result back to the main process via inter-process communication. Finally, the main process sends the final login result back to the user.

[0061] This multi-process interaction mechanism enables the SDK to run in isolation from the main process and to be invoked on demand.

[0062] Figure 4 This is a flowchart illustrating the communication method based on an instant messaging client in the embodiments of this application. Figure 2 See Figure 4 As shown, the method may include: S41: The compiler will use an interface description file written in a non-programming language to describe the interaction contract between the main process and the agent process, compile and generate client-process inter-server communication code with serialization / deserialization and IPC communication capabilities, which will be deployed on both ends of the main process and the agent process respectively.

[0063] To ensure that the communication interface between the main process and the agent process strictly adheres to the predefined contract and can automatically generate reliable communication code, a compiler is used to automatically convert the interface description file describing the interface, methods, and data structures into client and inter-process server communication code deployed on both ends.

[0064] Specifically, step S41 above may include: S411: The compiler receives interface description files from users in a non-programming language.

[0065] The interface description file is used to describe the service interface, method signature, and data structure for the interaction between the main process and the proxy process.

[0066] Here, "non-programming language" specifically refers to a Domain Specific Language (DSL) or Interface Description Language (IDL) used for declaratively describing the interfaces between software components. Unlike general-purpose programming languages ​​(such as C++ and Java) used to implement common business logic, its core syntactic elements focus on defining service interfaces, method signatures, and the data structures involved, without including specific algorithm implementations, flow control, or resource management code. Examples include the interface definition sections of Protocol Buffers (.proto files), Apache Thrift (.thrift files), or customized interface description formats like XML / JSON Schema. This language aims to unambiguously define contracts for cross-process or cross-component communication through a concise, standardized, and automatically parsable grammar.

[0067] S412: The compiler uses inter-process communication (IPC) logic to convert the interface description file into inter-process client communication code and inter-process server communication code respectively, so that the inter-process client communication code is deployed in the location corresponding to the main process, and the inter-process server communication code is deployed in the location corresponding to the agent process.

[0068] During the conversion process, the interface description file can be used as input, and code generation is performed based on a pre-defined communication template. Specifically, the compiler has built-in code templates for different IPC mechanisms (such as Socket, pipes, and shared memory) and serialization protocols (such as JSON, XML, and custom binary). By parsing the interface and method definitions in the interface description file, the compiler uses the declared service interface names, method signatures, and data structures as variables to populate the corresponding client and server templates, thereby directly generating inter-process client communication code and inter-process server communication code containing complete communication, serialization, and stub / skeleton code.

[0069] Alternatively, the description file can be parsed first to construct its structured AST, and then inter-process client communication code and inter-process server communication code that automatically integrate serialization / deserialization and IPC communication logic can be generated based on the AST.

[0070] Specifically, step S412 above may include: S4121: Perform syntax parsing on the interface description file to generate an AST.

[0071] The Abstract Syntax Tree (AST) is used to represent the hierarchical relationship between service interfaces, method signatures, and data structures. As a standardized intermediate representation of interface description files, the AST uniquely and unambiguously defines the logical structure of service interfaces, methods, and their parameters / return values ​​by parsing the text description into a tree-like data structure composed of explicit node types and hierarchical relationships. This provides precise and unified specification input for subsequent code generation.

[0072] During the parsing and generation of the AST, the compiler performs lexical and syntactic analysis on the received interface description file. First, the lexical analyzer converts the file's character stream into a series of meaningful lexical units, such as identifying keywords (e.g., service, interface, returns), identifiers (e.g., Authentication, Login), data types (e.g., string, int32), and delimiters (e.g., {,}, , ;). Then, the syntactic analyzer combines these tokens into syntactic units according to predefined grammar rules, constructing the AST. The top-level node of the entire file might be a namespace node, which contains all defined service interfaces. Each service interface node contains all its method nodes and related data structure definition nodes. This AST accurately captures the definitions, nesting relationships, and contextual information of all interface elements, eliminating the ambiguity that might arise from natural language or text formats.

[0073] S4122: Based on AST, generate inter-process client communication code, wherein the inter-process client communication code is configured to: provide a callable interface with the same method signature as the service interface; when the callable interface is called, automatically serialize the input parameters into an inter-process communication data format and send them to the proxy process through the IPC channel; receive response data from the proxy process, deserialize it into a local object and return it.

[0074] In the specific generation process, firstly, the service interface nodes and their contained method definition nodes in the AST are traversed. For each method, a publicly callable function with a signature (method name, parameter types and order, return type) that is completely identical is generated, serving as the programming interface for the main process's business logic. Secondly, within the function's implementation, code logic is automatically inserted to serialize the parameter values ​​passed during the call into a predetermined inter-process communication data format according to the corresponding data structure defined in the AST. Next, code is generated to send this serialized data to the proxy process through the specified IPC channel. Simultaneously, code is generated to listen on the same IPC channel to receive responses from the proxy process. Finally, code is generated to deserialize the received response data, reconstruct it into a native programming language object (or tuple) according to the return value structure defined in the AST, and return it to the caller.

[0075] Inter-process client communication code can also be used to proactively establish IPC communication channels, maintain and monitor channel connectivity, and report the status of the IPC channel to the business.

[0076] S4123: Based on AST, generate inter-process server communication code, which is configured to: listen to the IPC channel and receive request data from the main process; deserialize the request data and identify the target method and parameters; call the business logic implementation corresponding to the service interface; serialize the business logic execution result into the inter-process communication data format and return it to the main process through the IPC channel.

[0077] The generation methods for inter-process server communication code and inter-process client communication code based on AST are logically symmetrical. They are roughly as follows: Generate code to listen to the IPC channel and receive requests; generate code to deserialize request data to identify the target method and parameters; generate scheduling code to call the corresponding business logic implementation; generate code to serialize the execution result; and generate code to return response data through the IPC channel.

[0078] For inter-process client communication code, it can be compiled and linked into the main process's executable file as a static library or source code, becoming a communication module used within the main process to initiate cross-process calls.

[0079] The inter-process server communication code can also be compiled and linked into the independent agent process executable file as a static library or source code, becoming a communication framework within the agent process for listening to, receiving, and processing cross-process requests.

[0080] In some cases, users have a habitual way of using the SDK. In order to reduce the waiting delay and improve the user experience during subsequent operations, the agent process corresponding to the SDK that may be used is predicted and started in advance by analyzing the user's historical usage habits.

[0081] In practical applications, there are multiple SDKs, each corresponding to a different proxy process. This allows different SDKs to run in independent proxy processes, achieving process-level isolation. This ensures that a crash, resource leak, or compatibility issue in a single SDK will not affect other SDKs or the main process, maximizing the overall stability and reliability of the client from an architectural perspective.

[0082] S42: The main process analyzes user history behavior to predict and start the agent process corresponding to SDKs that have usage order associations or are used at fixed times in advance.

[0083] Specifically, step S42 above may include: S421: Obtain the usage habits of instant messaging client users for each SDK.

[0084] User usage habits for various SDKs refer to the behavioral patterns, frequency distributions, and time preferences observed when different SDKs are called, derived by analyzing users' historical operation logs in instant messaging clients. For example, after a user routinely uses the "Screen Sharing SDK" for a morning meeting at 10:00 AM, there is an 80% probability that they will then call the "Document Collaboration SDK" to edit meeting minutes. Or, a user might use the "Video Conferencing SDK" separately between 3:00 PM and 4:00 PM on weekdays.

[0085] S422: If the usage convention indicates that the two SDKs are used sequentially, then the agent process corresponding to the second SDK will be started after the agent process corresponding to the first SDK is started.

[0086] The first SDK in the two SDKs can refer to the SDK corresponding to the first user input. When usage habits indicate a sequential relationship between the two SDKs (SDK A and SDK B), the user's current first input triggers a call to SDK A. The main process then starts the proxy process corresponding to SDK A (process A) and completes the interaction with SDK A. Almost simultaneously or immediately afterward, without waiting for the user to actually initiate a call to SDK B, the main process proactively and asynchronously starts the proxy process corresponding to SDK B (process B). After starting, process B loads and initializes SDKB, enters a standby state, and waits for subsequent call requests that the main process may send, thus achieving predictive sequential process startup.

[0087] S423: If the convention indicates that the agent process corresponding to the second target SDK should start at a specified time, then the agent process corresponding to the second target SDK should start before the specified time.

[0088] The specified time can refer to an advance time relative to the regular time when users habitually use a particular SDK, set to complete the predictive preloading operation. This advance time aims to ensure that the target SDK's agent process has sufficient startup and initialization time, so that the process is ready when the user reaches their usual usage time.

[0089] For example, suppose analysis of user history data reveals that a user has a greater than 90% probability of using the "Video Conferencing SDK" to join a departmental meeting between 3:00 PM and 3:30 PM every weekday. Therefore, at 2:55 PM daily, the dedicated agent process for the "Video Conferencing SDK" is proactively started. This agent process completes initialization and preparation, ensuring that when the user actually clicks the "Join Meeting" button at 3:05 PM, the video conferencing function is instantly invoked, avoiding delays caused by process startup and SDK initialization, and significantly improving the smoothness of the user experience.

[0090] S43: The main process responds to the first user input information from the instant messaging client, determines the first target SDK with an association relationship based on the SDK corresponding to the first user input information, and starts the agent process corresponding to the first target SDK.

[0091] This is predictive preloading, which means that when a user explicitly calls a certain SDK, the proxy process of the related SDKs that the user may use next is proactively started in advance based on the known correlation between SDKs, so as to eliminate the startup delay of subsequent function calls and improve the smoothness of user experience.

[0092] Specifically, step S43 above may include: S431: Determine the first target SDK associated with the SDK corresponding to the first user input information.

[0093] S432: Start the agent process corresponding to the first target SDK.

[0094] After receiving the first user input, the main process first parses the input intent to determine the specific SDK to be invoked (denoted as SDK X). Then, the main process queries a pre-defined relationship mapping table, which defines the logical relationships between different SDKs in terms of functionality or usage (for example, "screen sharing SDK" is often used in conjunction with "document annotation SDK"). Based on this mapping table, the main process determines the first target SDK (denoted as SDK Y) that has a pre-defined relationship with SDK X.

[0095] After the main process determines the first target SDK, it creates a new independent process space through its process management module, loads and initializes the library files of SDK Y, and then starts the independent agent process corresponding to the first target SDK (SDK Y) and puts it into a standby state.

[0096] S44: When the main process needs to call the SDK, it locates the target agent process through the configuration table and sends a probe request. If the process is alive, it communicates normally. If the process does not respond, it automatically restarts a new process and reloads the SDK.

[0097] This ensures that the corresponding agent process is available when the SDK is called, and can automatically recover if the process fails, thereby guaranteeing the success rate of function calls and the overall robustness of the client.

[0098] Specifically, step S44 above may include: S441: Determine the service type or SDK identifier based on the first user input information.

[0099] Business type refers to the abstract function category that the user intends to perform, such as "user login", "screen sharing" or "join video conference".

[0100] The SDK identifier refers to the name or unique code of the third-party SDK that implements the specific functions, such as "com.example.authsdk" (Unified Authentication SDK) or "ScreenShareSDK_v2".

[0101] Specifically, the type of business operation the user intends to perform (e.g., "user login") can be determined by parsing the UI control ID of the input source, the type of event being listened to, or by performing simple semantic analysis on the input content (e.g., determining whether the input box is a password box). Alternatively, in scenarios with tighter integration, specific user operations can be directly mapped to specific SDK identifiers based on pre-bound logic (e.g., clicking the "Login" button directly corresponds to "com.example.authsdk"). This can be done by querying a pre-defined "user operation - SDK / business type" mapping table or by executing a predefined conditional judgment logic.

[0102] S442: Locate the internal configuration table to determine the agent process identifier corresponding to the business type or SDK identifier.

[0103] The internal configuration table includes identifiers for each business type or SDK and their corresponding agent process identifiers. Different agent processes correspond to different SDKs. This internal configuration table is a static or dynamic configuration file that is manually written by developers during the system integration phase or automatically generated by compilation / deployment scripts. It records the binding relationship between each business type (or SDK identifier) ​​and a unique agent process identifier (such as process name, listening port, or executable file path).

[0104] S443: Send a probe request to the agent process corresponding to the determined agent process identifier.

[0105] A probe request is a lightweight heartbeat or liveness check message used to verify whether a target agent process is running normally and responsive. It typically does not contain specific business parameters; its core purpose is to quickly confirm the accessibility of the communication channel and the activity of the process. For example, it can be a predefined, empty data packet or a simple packet containing only a fixed command word (such as PING).

[0106] Upon receiving this request, a normal proxy process will immediately return a pre-defined response (such as PONG) to indicate that it is in a normal working state.

[0107] S444: If a response to a probe request is received within a preset time interval, then communicate with the SDK corresponding to the identified agent process identifier.

[0108] S445: If no response to the probe request is received within the preset time interval, report the error to the user or start a new agent process according to business needs, and load the library file of the SDK corresponding to the determined agent process identifier to communicate with the SDK corresponding to the determined agent process identifier.

[0109] The preset time interval refers to the maximum allowed waiting time from when the main process sends a probe request until it waits and expects to receive a valid response. This time interval is a pre-set threshold, and its specific value is usually determined based on the normal response processing time of the agent process and the system's tolerance for fault detection. For example, it can be set to 100 milliseconds, 500 milliseconds, or 1 second.

[0110] If a response to the probe request is received within the preset time interval, it means that the target agent process is in a normal standby state. The main process will then communicate with the corresponding SDK directly through the surviving agent process according to the established process.

[0111] If no response to the probe request is received within the preset time interval, it means that the target agent process has crashed, is unresponsive, or has not started. The main process will then report the error to the user or automatically create a new independent process space according to business needs, load and initialize the specified SDK library, thereby starting a new agent process and establishing communication with the corresponding SDK through this new process.

[0112] Business requirements refer to pre-defined error handling strategies based on the business criticality and user experience priority of SDK functions. When an unresponsive proxy process is detected, the fault tolerance policy flag corresponding to the SDK or business type in the internal configuration table can be used for judgment. If the function is a core critical path (such as login authentication or payment), business requirements typically require maximizing service availability and will choose to silently start a new proxy process to restore the function, avoiding interruption of user operations. If the function is a non-core or auxiliary function (such as screen sharing or weather widgets), and frequent restarts may lead to greater resource consumption or experience interference, business requirements allow reporting errors to users (such as prompting "Function is temporarily unavailable, please try again later"), allowing users to decide whether to retry, thus achieving a balance between stability and user experience.

[0113] S45: The main process calls the inter-process client communication code to convert the first user input information into the first data packet and sends the first data packet to the agent process.

[0114] S46: The agent process calls the inter-process server communication code to convert the first data packet into the second user input information, calls the corresponding software development kit (SDK), and sends the second user input information to the SDK.

[0115] S47: The agent process receives the first response information from the SDK, calls the inter-process server communication code to convert the first response information into a second data packet, and sends the second data packet to the main process.

[0116] S48: The main process calls the inter-process client communication code to convert the second data packet into the second response information and outputs the second response information.

[0117] Steps S45-S48 here are implemented in the same way as steps S21-S24 in the previous embodiments, and can be found in the relevant descriptions in the previous embodiments, which will not be repeated here.

[0118] At this point, a complete business call process, from the user initiating a request to the main process outputting the final response, has been completed.

[0119] After the SDK call is completed or during the system resource management phase, in order to reclaim idle resources in a timely manner, prevent abnormal processes from occupying system resources for a long time, and ensure the overall efficiency and stability of the client operation, the system periodically checks the idle time, running health, and device resource reserves of the agent process, and automatically shuts down those agent processes that are no longer needed or have become abnormal according to preset rules.

[0120] S49: The main process executes at least one of the following three items: obtain the timestamp of the last time the agent process was called; calculate the time difference between the timestamp and the current time; determine whether the time difference is greater than a preset time threshold; obtain the status data corresponding to the agent process; determine whether the status data indicates that the agent process is abnormal; obtain the remaining resources of the device where the agent process is located; determine whether the remaining resources are less than a preset remaining resource threshold; if at least one of the above determinations is not true, then the agent process is closed.

[0121] In the first judgment, the timestamp of the last time the proxy process was invoked refers to the system time record of the most recent successful processing and response of the proxy process to a business request from the main process. The main process can update and store this timestamp locally after each business interaction with the proxy process (i.e., receiving a valid response) for later retrieval. A time difference greater than a preset time threshold means the proxy process has been idle for a relatively long period and has not been used, while a time difference less than or equal to the threshold means the proxy process is still active and may still be needed. This preset time threshold is a configurable parameter, typically set according to the definition of idle time in the business scenario. For example, if being idle for more than 5 minutes is considered idle, the threshold can be set to 300 seconds.

[0122] In the second judgment, status data refers to a set of quantitative indicators reflecting the current health status and performance of the agent process. These include, but are not limited to: memory size (the amount of physical or virtual memory currently used by the agent process), average time taken for the last n calls (the average time spent by the agent process processing the last n business requests, where n is an integer greater than 1), and failure rate (the proportion of calls that failed to complete successfully or returned incorrect results in the most recent number of calls). By comparing these indicators with preset dynamic or static thresholds, it is possible to determine whether the agent process is in an abnormal state. Upon determining that the agent process is abnormal, the agent process is restarted, achieving automated fault isolation and rapid recovery.

[0123] Specifically, step S49 above may include: S491: Determine whether the growth rate of memory size exceeds the preset growth threshold.

[0124] The memory size growth rate refers to the ratio of the increase in memory occupied by the agent process within a specific monitoring time window to the initial memory size at the beginning of that time window. The formula is: (Current memory size - Initial memory size) / Initial memory size × 100%.

[0125] Preset growth thresholds are typically based on empirical values ​​of the range of memory usage fluctuations for a specific SDK or agent process under normal stress testing, and are set in conjunction with the system's tolerable level of memory leak risk.

[0126] The significance of this judgment lies in detecting whether the agent process has memory leaks or abnormal memory growth. If the growth rate exceeds the preset growth threshold, it means that the agent process (or its integrated third-party SDK) may be continuously requesting memory but not releasing it correctly, posing a memory leak risk. Over time, this will exhaust system resources and affect system stability. In this case, the system should mark the process as abnormal and trigger an alarm or restart the agent process to release the leaked memory. If the growth rate does not exceed the threshold, it indicates that the process's memory usage is within the normal fluctuation range, and there are no signs of memory leaks. The system will continue to monitor its subsequent status without immediate intervention.

[0127] S492: Determine whether the average time exceeds the preset time threshold.

[0128] Average processing time refers to the average time required for the proxy process to process the most recent n valid business requests.

[0129] The preset time-consuming threshold is dynamically changed in a negative correlation with the load of the device on which the agent program resides. In other words, the preset time-consuming threshold is not a fixed value, but is dynamically calculated based on real-time load metrics of the device on which the agent process resides (such as CPU utilization, system memory pressure, or I / O wait queue length). Specifically, a baseline time-consuming threshold is first defined, and then a decay coefficient positively correlated with the load is introduced. For example, it can be set that when CPU utilization exceeds 50%, for every 10% increase in load, the preset time-consuming threshold decreases by 10% from the baseline value.

[0130] The significance of this judgment lies in monitoring whether the response performance of the agent process is within an acceptable range. If the average latency exceeds the current dynamic latency threshold, it means that under the current system load, the agent process's response speed is no longer up to standard, possibly due to its own processing bottlenecks, resource contention, or inefficient SDK. In this case, the system should mark it as a performance anomaly and may trigger optimization alerts, resource scheduling, or consider restarting the agent process. If the average latency does not exceed the current dynamic latency threshold, it means that the agent process's response performance is normal under the current load, and the system can continue to maintain its running state.

[0131] Automatically tighten performance tolerance under high load and appropriately loosen it under low load, thereby more intelligently and fairly evaluating the response performance of agent processes, avoiding misjudging normal processes as abnormal when the system is busy due to fixed thresholds, or letting actually degraded processes go unchecked when the system is idle.

[0132] S493: Determine whether the failure rate exceeds the preset failure threshold.

[0133] Failure rate refers to the proportion of the number of business calls to the proxy process that failed to complete successfully (including call timeout, return of error code, or process unresponsiveness) out of the total number of calls in the most recent business calls to the proxy process.

[0134] Preset failure thresholds are typically set based on a combination of business reliability requirements, historical stability data of the SDK, and the system's tolerable level of failure.

[0135] The significance of this judgment lies in assessing the functional reliability and service availability of the proxy process (and its integrated SDK). If the failure rate exceeds the preset failure threshold, it means that the process or SDK has been frequently failing recently and can no longer provide stable and reliable services. In this case, the system should mark it as functionally abnormal and may trigger alarms, initiate fault recovery procedures (such as restarting the proxy process), or perform service degradation. If the failure rate does not exceed the threshold, it means that its service reliability is within an acceptable range, and the system can continue to trust and use the proxy process.

[0136] This concludes the description of the communication method based on an instant messaging client provided in the embodiments of this application.

[0137] Based on the same inventive concept, embodiments of this application also provide a communication system based on an instant messaging client.

[0138] Figure 5 This is a schematic diagram of the communication system based on an instant messaging client in the embodiments of this application. Figure 1 See Figure 5 As shown, the system may include: a main process 111 of the instant messaging client and an agent process 112.

[0139] The main process 111 is used to respond to the first user input information from the instant messaging client, call the inter-process client communication code to convert the first user input information into a first data packet, and send the first data packet to the agent process. The inter-process client communication code is used to serialize and encapsulate the first user input information based on the interface description between the main process and the agent process.

[0140] Agent process 112 is used to call inter-process server communication code to convert the first data packet into second user input information, call the corresponding software development kit (SDK), and send the second user input information to the SDK. The inter-process server communication code is used to deserialize and deseal the first data packet based on the interface description between the main process and the agent process.

[0141] Agent process 112 is also used to receive the first response information from the SDK, call the inter-process server communication code to convert the first response information into a second data packet, and send the second data packet to the main process.

[0142] The main process 111 is also used to call inter-process client communication code to convert the second data packet into the second response information and output the second response information.

[0143] Furthermore, as a response to Figure 5 In addition to refining and expanding the system shown, this application also provides a communication system based on an instant messaging client.

[0144] Figure 6 This is a schematic diagram of the communication system based on an instant messaging client in the embodiments of this application. Figure 2 See Figure 6 As shown, the system may include: a main process 111 of the instant messaging client, a proxy process 112, inter-process client communication code 113, and inter-process server communication code 114.

[0145] Before actual operation, the compiler receives interface description files input by the user in a non-programming language. The interface description files describe the service interfaces, method signatures, and data structures for interaction between the main process and the agent process. Inter-process communication (IPC) logic is used to convert the interface description files into inter-process client communication code 113 and inter-process server communication code 114, respectively, so that the inter-process client communication code 113 is deployed in the corresponding position of the main process, and the inter-process server communication code 114 is deployed in the corresponding position of the agent process.

[0146] The compiler is specifically used to parse the interface description file and generate an Abstract Syntax Tree (AST). The AST represents the hierarchical relationship between service interfaces, method signatures, and data structures. Based on the AST, inter-process client communication code 113 is generated. This code is configured to: provide a callable interface with the same method signature as the service interface; automatically serialize the input parameters into an inter-process communication data format and send them to the proxy process via the IPC channel when the callable interface is invoked; receive response data from the proxy process, deserialize it into a local object, and return it. Based on the AST, inter-process server communication code 114 is generated. This code is configured to: listen to the IPC channel and receive request data from the main process; deserialize the request data and identify the target method and parameters; invoke the business logic implementation corresponding to the service interface; serialize the business logic execution result into an inter-process communication data format and return it to the main process via the IPC channel.

[0147] In actual operation, there are multiple SDKs, and different SDKs correspond to different agent processes. The main process 111 is used to obtain the user's usage habits of each SDK in the instant messaging client. If the usage habits indicate that two SDKs should be used in sequence, the agent process corresponding to the first SDK will be started after the agent process corresponding to the first SDK is started. If the usage habits indicate that the agent process corresponding to the second target SDK should be started at a specified time, the agent process corresponding to the second target SDK will be started before the specified time.

[0148] The main process 111 is also used to determine the first target SDK associated with the SDK corresponding to the first user input information; and to start the agent process corresponding to the first target SDK.

[0149] The main process 111 is also used to determine the service type or SDK identifier based on the first user input information; look up the internal configuration table to determine the agent process identifier corresponding to the service type or SDK identifier. The internal configuration table includes each service type or SDK identifier and its corresponding agent process identifier. Different agent processes correspond to different SDKs. A probe request is sent to the agent process corresponding to the determined agent process identifier. If a response to the probe request is received within a preset time interval, the step of sending the first data packet to the agent process is executed. If no response to the probe request is received within the preset time interval, a new agent process is started and the library file of the SDK corresponding to the determined agent process identifier is loaded to communicate with the SDK corresponding to the determined agent process identifier.

[0150] The main process 111 is also used to respond to the first user input information from the instant messaging client, call the inter-process client communication code 113 to convert the first user input information into a first data packet, and send the first data packet to the agent process. The inter-process client communication code 113 is used to serialize and encapsulate the first user input information based on the interface description between the main process and the agent process.

[0151] The agent process 112 is used to call the inter-process server communication code 114 to convert the first data packet into the second user input information, call the corresponding software development kit (SDK), and send the second user input information to the SDK. The inter-process server communication code 114 is used to deserialize and deseal the first data packet based on the interface description between the main process and the agent process. The proxy process 112 is also used to receive the first response information fed back by the SDK, call the inter-process server communication code 114 to convert the first response information into a second data packet, and send the second data packet to the main process; The main process 111 is also used to call the inter-process client communication code 113 to convert the second data packet into the second response information and output the second response information.

[0152] The main process 111 is also used to perform at least one of the following three tasks: obtain the timestamp of the last time the agent process was called; calculate the time difference between the timestamp and the current time; determine whether the time difference is greater than a preset time threshold; obtain the status data corresponding to the agent process; determine whether the status data indicates that the agent process is abnormal; obtain the remaining resources of the device where the agent process is located; determine whether the remaining resources are less than a preset remaining resource threshold; if at least one of the above determinations is not true, then close the agent process.

[0153] Given that the status data includes the corresponding memory size and the average time and failure rate of the last n calls, where n is an integer greater than 1, the main process 111 is specifically used to determine whether the growth rate of memory size exceeds a preset growth threshold; to determine whether the average time exceeds a preset time threshold, wherein the preset time threshold is dynamically changed in a negative correlation with the load of the device where the agent program is located; and to determine whether the failure rate exceeds a preset failure threshold.

[0154] It should be noted that the description of the system embodiments above is similar to the description of the method embodiments above, and has similar beneficial effects. For technical details not disclosed in the system embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0155] Based on the same inventive concept, this application also provides a computer device.

[0156] Figure 7 This is a schematic diagram of the structure of the computer device in an embodiment of this application. See also... Figure 7 As shown, the computer device may include: a memory 71, a processor 72, and a computer program stored on the memory 71, wherein the processor 72 executes the computer program to implement the methods described in the foregoing embodiments.

[0157] It should be noted that the description of the above computer device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0158] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the methods described in the foregoing embodiments.

[0159] It should be noted that the description of the above computer-readable storage medium embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0160] Based on the same inventive concept, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described in the foregoing embodiments.

[0161] It should be noted that the descriptions of the above computer program product embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the computer program product embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0162] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method based on an instant messaging client, characterized by, The method is applied to a communication system based on an instant messaging client, the system comprising a main process and a proxy process of the instant messaging client, and the method comprises: The main process, in response to first user input information of the instant messaging client, invokes inter-process client communication code to convert the first user input information into a first data packet and sends the first data packet to the proxy process, wherein the inter-process client communication code is configured to serialize and package the first user input information based on an interface description between the main process and the proxy process; The proxy process invokes inter-process server communication code to convert the first data packet into second user input information, invokes a corresponding software development kit (SDK), and sends the second user input information to the SDK, wherein the inter-process server communication code is configured to deserialize and unpack the first data packet based on the interface description between the main process and the proxy process; The proxy process receives first response information fed back by the SDK, invokes the inter-process server communication code to convert the first response information into a second data packet, and sends the second data packet to the main process; The main process invokes the inter-process client communication code to convert the second data packet into second response information and outputs the second response information.

2. The method of claim 1, wherein, The system further comprises a compiler; before the communication based on the instant messaging client, the method further comprises: The compiler receives an interface description file input by a user in a non-programming language, wherein the interface description file is used to describe a service interface, a method signature, and a data structure for interaction between the main process and the proxy process; The compiler converts the interface description file into the inter-process client communication code and the inter-process server communication code respectively by using inter-process communication (IPC) logic, so that the inter-process client communication code is deployed in a corresponding position of the main process and the inter-process server communication code is deployed in a corresponding position of the proxy process.

3. The method of claim 2, wherein, Converting the interface description file into the inter-process client communication code and the inter-process server communication code by using the inter-process communication (IPC) logic comprises: Performing syntax analysis on the interface description file to generate an abstract syntax tree (AST), wherein the AST is used to represent a hierarchical relationship between the service interface, the method signature, and the data structure; Based on the AST, the inter-process client communication code is generated, wherein the inter-process client communication code is configured to: provide a callable interface consistent with the method signature in the service interface; when the callable interface is invoked, automatically serialize input parameters into an inter-process communication data format and send them to the proxy process through an IPC channel; receive response data from the proxy process and return them after being deserialized into local objects. Based on the AST, the inter-process server communication code is generated, wherein the inter-process server communication code is configured to: listen to the IPC channel, receive request data from the main process; deserialize the request data, identify the target method and parameters; call the business logic implementation corresponding to the service interface; serialize the business logic execution result into an inter-process communication data format, and return it to the main process through the IPC channel.

4. The method according to any one of claims 1 to 3, characterized in that, After outputting the second response information, the method further comprises: At least one of the following three is performed: Obtain the timestamp of the last call of the proxy process; calculate the time difference between the timestamp and the current time; determine whether the time difference is greater than a preset time threshold; Obtain the state data corresponding to the proxy process; determine whether the state data indicates that the proxy process is abnormal; Obtain the remaining resource amount of the device where the proxy process is located; determine whether the remaining resource amount is less than a preset remaining resource threshold; If at least one of the above is false, the proxy process is closed.

5. The method of claim 4, wherein, The state data includes the corresponding memory size, and the average time consumption and failure rate of the last n times of calling, and n is an integer greater than 1; The determination of whether the state data indicates that the proxy process is abnormal comprises: Determine whether the growth rate of the memory size exceeds a preset growth threshold; Determine whether the average time consumption exceeds a preset time consumption threshold, wherein the preset time consumption threshold dynamically changes in negative correlation with the load amount of the device where the proxy process is located; Determine whether the failure rate exceeds a preset failure threshold.

6. The method according to any one of claims 1 to 3, characterized in that, After responding to the first user input information of the instant messaging client, the method further comprises: Determine the business type or SDK identifier according to the first user input information; Find an internal configuration table to determine the proxy process identifier corresponding to the business type or SDK identifier, wherein the internal configuration table includes various business types or SDK identifiers and their corresponding proxy process identifiers, and different proxy processes correspond to different SDKs; Send a probe request to the proxy process corresponding to the determined proxy process identifier; If a response to the probe request is received within a preset time interval, the step of sending the first data packet to the proxy process is performed; If no response to the probe request is received within a preset time interval, an error is reported to the user according to the business requirements or a new proxy process is started, and the library file of the SDK corresponding to the determined proxy process identifier is loaded to communicate with the SDK corresponding to the determined proxy process identifier.

7. The method according to any one of claims 1 to 3, characterized in that, The number of SDKs is multiple, and different SDKs correspond to different proxy processes; after responding to the first user input information of the instant messaging client, the method further comprises: Determine the first target SDK associated with the SDK corresponding to the first user input information; Start the proxy process corresponding to the first target SDK.

8. The method according to any one of claims 1 to 3, characterized in that, The number of SDKs is multiple, and different SDKs correspond to different proxy processes; before responding to the first user input information of the instant messaging client, the method further comprises: acquire a use habit of a user of the instant messaging client for each SDK; if the use habit indicates that two SDKs are used in sequence, start an agent process corresponding to a second SDK of the two SDKs after starting an agent process corresponding to a first SDK of the two SDKs; if the use habit indicates that an agent process corresponding to a second target SDK is started at a specified time, start the agent process corresponding to the second target SDK before the specified time.

9. A communication system based on an instant messaging client, characterized by The system comprises a main process and an agent process of an instant messaging client; The main process is configured to, in response to first user input information of the instant messaging client, invoke inter-process client communication code to convert the first user input information into a first data packet, and send the first data packet to the agent process, wherein the inter-process client communication code is configured to serialize and package the first user input information based on an interface description between the main process and the agent process; The agent process is configured to, invoke inter-process server communication code to convert the first data packet into second user input information, invoke a corresponding software development kit (SDK), and send the second user input information to the SDK, wherein the inter-process server communication code is configured to deserialize and unpack the first data packet based on the interface description between the main process and the agent process; The agent process is further configured to receive first response information fed back by the SDK, invoke the inter-process server communication code to convert the first response information into a second data packet, and send the second data packet to the main process; The main process is further configured to invoke the inter-process client communication code to convert the second data packet into second response information, and output the second response information.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the method in any one of claims 1 to 8.

Images