Inter-process communication method, vehicle-mounted terminal and storage medium
By encapsulating communication instances and the underlying layer in the service process and providing centrally managed inter-process communication methods, the problems of low code reusability and poor scalability in the prior art are solved, and simplified communication processes and improved system performance are achieved.
Patent Information
- Application Number
- CN202411227821.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-03
- Publication Date
- 2025-02-07
AI Technical Summary
The existing inter-process communication methods have problems such as low code reusability and poor scalability, which makes the communication process complex and difficult to manage.
By encapsulating communication instances and communication underlying layers in the service process, a centrally managed inter-process communication method is provided, synchronous calls and asynchronous calls are supported, and the processing results are called back or notified to the client process through the callback interface and notification interface.
It simplifies the inter-process communication process, reduces complexity, improves code reusability and scalability, and enhances communication security and system concurrency performance.
Smart Images
Figure CN119396601A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of communication technology, and in particular to an inter-process communication method, a vehicle-mounted terminal and a storage medium. Background Art
[0002] There are many ways to communicate between processes. The current more efficient communication methods usually require the introduction of an interface description language to define the interface, and then convert it into a packaged communication interface to conveniently use the transmission capabilities of the communication component. The final effect is similar to that each interface represents a business logic, that is, one service process corresponds to one client process. This will generate more duplicate code, low code reusability, and is also difficult to expand. Summary of the invention
[0003] In order to solve the above technical problems, the present application provides an inter-process communication method, a vehicle-mounted terminal and a storage medium with high code reusability and convenient expansion.
[0004] Specifically, the present application provides an inter-process communication method, comprising the following steps: The service process receives the communication requests from each client process, creates a communication instance corresponding to the communication request, and provides a corresponding communication interface call to the communication bottom layer through the communication instance.
[0005] And the communication bottom layer determines whether to block the communication interface based on the communication type of the communication request, so as to call back or notify the corresponding client process of the processing result of the communication request through the communication interface or notification interface based on the blocking state.
[0006] Wherein, the communication instance and the communication bottom layer are both encapsulated in the service process.
[0007] In the above technical solution, since the communication instance and the communication bottom layer are encapsulated in the service process, all inter-process communications can be centrally managed, which simplifies the communication process, reduces complexity, and enables the client process to only care about the message itself without having to understand the specific implementation details of the service process; the service process creates a communication instance based on the communication request of the client process and provides a corresponding communication interface, which can provide flexible processing methods for different request types; at the same time, the service process can also support synchronous calls and asynchronous calls to provide flexible communication support.
[0008] In addition, since communication management and the implementation of the underlying communication layer are both performed in the service process, the direct interaction between the client process and the underlying communication mechanism is isolated, which improves the security of communication and prevents the client process from directly interfering with or maliciously operating the underlying communication layer.
[0009] Furthermore, it also includes: the communication bottom layer encapsulates the communication interface and the notification interface; wherein the communication interface includes a first callback interface and a second callback interface.
[0010] In the above technical solution, by encapsulating the communication interface and the notification interface, the complex underlying implementation details can be hidden inside the encapsulation, so that users only need to focus on the high-level interface without having to deeply understand the underlying specific implementation, thereby simplifying the development and maintenance work; the first callback interface and the second callback interface can be used to handle different types of callback events. For example, the first callback interface can handle the response to synchronous requests, while the second callback interface can handle asynchronous notifications. Such division of labor can improve the organization and maintainability of the code and avoid the mixing of complex callback logic.
[0011] In addition, the implementation of the callback interface can be adjusted according to actual application requirements. For example, more callback types can be added or the existing callback logic can be modified without affecting the communication mechanism of the entire system.
[0012] Furthermore, after providing the corresponding communication interface call to the communication bottom layer, it includes: The communication request is sent to the execution process through the communication interface, and the communication type of the communication request is obtained.
[0013] The execution process is a client process that processes the communication request.
[0014] In the above technical solution, the execution process, as a client process for processing communication requests, can focus on processing business logic, while the service process is responsible for managing communication requests and interface calls. This division of roles makes the vehicle terminal more modular, and each process can focus on its own responsibilities, thereby improving the overall maintainability and scalability of the vehicle terminal; by sending the communication request to the execution process through the communication interface and obtaining the type of the communication request, different types of requests can be flexibly processed, thereby improving the flexibility and adaptability of the vehicle terminal.
[0015] Furthermore, the communication type includes a first call request and a second call request.
[0016] When the communication type is a first call request, the first callback interface is blocked through the communication bottom layer, so that after the execution process completes the processing of the communication request, the first callback interface is opened and the processing result of the communication request is received, so that the processing result is called back to the target process through the first callback interface.
[0017] The target process is a client process that issues a communication request.
[0018] In the above technical solution, by blocking the first callback interface, it is ensured that the caller will not continue to execute before the execution process handles the request and returns the result. This mechanism can ensure the accuracy and consistency of the processing results, which is very important in scenarios where data integrity and consistency need to be guaranteed. The blocking interface simplifies the processing logic of the caller. The caller does not need to handle asynchronous callbacks or state management while waiting for the result. The logic is more direct and clear, which reduces programming complexity and helps improve the readability and maintainability of the code.
[0019] In addition, the blocking call pattern is very suitable for synchronous scenarios that need to wait for results; for example, when the processing time of the request is short or the result needs to be obtained immediately, the blocking pattern can effectively complete the task without introducing additional asynchronous processing complexity.
[0020] Further, when the communication type is a second call request, after the execution process completes processing of the communication request, the processing result is received through the notification interface, so as to notify the target process of the processing result through the notification interface.
[0021] In the above technical solution, the non-blocking notification interface allows the caller to continue other operations while the request is issued, instead of waiting for the result to be returned. This asynchronous communication can improve the concurrency performance of the entire system and is particularly suitable for high concurrency and high throughput scenarios.
[0022] Furthermore, the communication instance includes a client instance and a service instance, and further includes: The abnormal notification of the abnormal process is received through the notification interface, the abnormal flag is set through the customer instance, and the communication interface is disabled, and at the same time, a callback error code is fed back to the abnormal process through the notification interface.
[0023] The abnormal process is a client process that is in an abnormal state.
[0024] In the above technical solution, by timely receiving the abnormal notification of the abnormal process through the notification interface, it is possible to respond quickly to the abnormal situation, and when an abnormality is detected, the abnormal flag is set through the customer instance and the communication interface is disabled, which can effectively prevent invalid or erroneous communication requests from continuing to occupy system resources, help isolate the problem area, and protect other processes from being affected by the abnormality; the feedback callback error code helps to quickly locate the problem.
[0025] In addition, managing abnormal states through customer instances and service instances allows for more flexible handling of abnormal situations; for example, different handling strategies can be adopted based on different exception types or severities, such as restarting services, rolling back operations, or notifying administrators.
[0026] Furthermore, after receiving the abnormal notification, it also includes: An exception flag is set through the service instance, and the notification interface is disabled, and at the same time, a notification error code is fed back to the abnormal process through the first callback interface or the second callback interface.
[0027] In the above technical solution, the practice of setting the exception flag through the service instance, disabling the notification interface, and feeding back the error code through the callback interface can achieve rapid response to exceptions, prevent the spread of exceptions, provide detailed error information, maintain communication consistency, and improve user experience.
[0028] Furthermore, after the exception flag is set, it also includes: The abnormal process and the service process are reconnected, and after the connection is successful, the abnormal flag is deleted, and the communication interface or the notification interface is opened at the same time.
[0029] In the above technical solution, by reconnecting the abnormal process and the service process, the vehicle terminal can automatically try to restore the communication interrupted due to the abnormality. This automatic recovery mechanism reduces the need for manual intervention and improves the self-healing ability of the vehicle terminal; deleting the abnormal flag and reopening the communication interface or notification interface indicates that the vehicle terminal has successfully recovered to a normal state. This recovery mechanism ensures that the vehicle terminal can quickly return to a stable working state after the abnormality, thereby improving the overall stability.
[0030] Based on the same concept, the present application also provides a vehicle-mounted terminal, which is configured with at least one service process and multiple client processes. The service process and the client process, as well as the client processes, communicate with each other using the inter-process communication method.
[0031] In the above technical solution, the service process can centrally handle core services or shared resources, while the client process is responsible for specific functions or tasks. This modular design improves the organizational structure and code maintainability of the vehicle terminal. Through inter-process communication, each client process can be independently developed and updated without affecting the service process or other client processes. This design allows flexible expansion and maintenance of the vehicle terminal functions, allowing the vehicle terminal to easily adapt to future needs or changes. The isolation between the service process and the client process can improve the stability of the vehicle terminal. If a problem occurs in a client process, the service process and other client processes will not be affected.
[0032] Based on the same concept, the present application also provides a storage medium, in which a computer program is stored, wherein the computer program is configured to execute the inter-process communication method when running.
[0033] Compared with the prior art, the beneficial effects of this application are: In the present application, the service process receives the communication requests of each client process and creates a communication instance corresponding to the communication request. The corresponding communication interface call is provided to the communication bottom layer through the communication instance. The communication bottom layer determines whether to block the communication interface based on the communication type of the communication request, so as to call back or notify the corresponding client process of the processing result of the communication request through the communication interface or notification interface based on the blocking state.
[0034] In this application, since the communication instance and the communication bottom layer are encapsulated in the service process, all inter-process communications can be centrally managed, which simplifies the communication process and reduces complexity; the service process can provide flexible processing methods for different request types; at the same time, the service process can also support synchronous calls and asynchronous calls to provide flexible communication support. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Figure 1 This is a flow chart of the inter-process communication method described in Example 1.
[0036] Figure 2 This is a schematic diagram of the communication between the client process and the service process described in Example 1.
[0037] Figure 3 This is a schematic diagram of communication between client processes described in Example 1.
[0038] Figure 4 This is a schematic diagram of abnormal process processing described in Example 2. DETAILED DESCRIPTION
[0039] The following is a further detailed description of an inter-process communication method, a vehicle-mounted terminal and a storage medium of the present application in conjunction with specific embodiments and drawings.
[0040] Embodiment 1: See also Figure 1 , the present application provides an inter-process communication method, comprising the following steps: The service process receives the communication requests from each client process, creates a communication instance corresponding to the communication request, and provides a corresponding communication interface call to the communication bottom layer through the communication instance.
[0041] In this embodiment, the external management module runtime is used as the only transit context of the service process to create a communication instance corresponding to the communication request. The creation is that the external management module runtime makes a function call such as getClient() to create the communication instance.
[0042] Among them, the communication instance includes at least a service instance and a client instance, and the communication instance is used to encapsulate the proxy bottom layer and transfer the interface call provided by the API to the communication bottom layer.
[0043] The api includes the interface class and public type definition of the service process. When the client process needs to use the service process, it only needs to include the header file under the api in the external management module runtime.
[0044] In addition, the service process also includes a manager as an internal management module, which is responsible for managing and maintaining the internally encapsulated communication instances. External callers cannot perceive the management behavior of the manager.
[0045] Furthermore, the underlying communication layer, such as binder (an inter-process communication (IPC) mechanism in the Android operating system), is more efficient than the commonly used fdbus (Full-duplex Bus, an inter-process communication (IPC) mechanism for embedded systems), message queues, and other IPCs.
[0046] Furthermore, the binder is a C / S architecture. When a service instance is created, it corresponds to the binder server of the binder, and when a customer instance is created, it corresponds to the binder client of the binder.
[0047] It should be noted that the various components of the service process are independent of each other and can be partially modified to adapt to new requirements when necessary. Different components share memory in the service process, and the relationship between components is function call.
[0048] like Figure 2 As shown in the figure, the client process app obtains the corresponding communication instance proxy through the runtime, and then sends messages through the proxy. The service process ( Figure 2 There is no redundant message passing process inside, which guarantees efficiency to the greatest extent. When sending and receiving messages, the proxy will call the underlying communication binder to complete the communication between processes. The corresponding proxy is actually managed and maintained by the manager. The proxy initializes and calls the underlying communication binder, and the client process app cannot perceive the specific internal calling process. For the client process, it only needs to send a communication request such as syncSendMsg(), and the message can be sent to the other end and get a response.
[0049] Furthermore, the communication bottom layer determines whether to block the communication interface based on the communication type of the communication request, so as to call back or notify the corresponding client process of the processing result of the communication request through the communication interface or notification interface based on the blocking state.
[0050] Wherein, the communication instance and the communication bottom layer are both encapsulated in the service process.
[0051] Furthermore, it also includes: the communication bottom layer encapsulates the communication interface and the notification interface; wherein the communication interface includes a first callback interface and a second callback interface.
[0052] In the above technical solution, by encapsulating the communication interface and the notification interface, the complex underlying implementation details can be hidden inside the encapsulation, so that users only need to focus on the high-level interface without having to deeply understand the underlying specific implementation, thereby simplifying the development and maintenance work; the first callback interface and the second callback interface can be used to handle different types of callback events. For example, the first callback interface can handle the response to synchronous requests, while the second callback interface can handle asynchronous notifications. Such division of labor can improve the organization and maintainability of the code and avoid the mixing of complex callback logic.
[0053] In addition, the implementation of the callback interface can be adjusted according to actual application requirements. For example, more callback types can be added or the existing callback logic can be modified without affecting the communication mechanism of the entire system.
[0054] Furthermore, after providing the corresponding communication interface call to the communication bottom layer, it includes: The communication request is sent to the execution process through the communication interface, and the communication type of the communication request is obtained.
[0055] The execution process is a client process that processes the communication request.
[0056] In the above technical solution, the execution process, as a client process for processing communication requests, can focus on processing business logic, while the service process is responsible for managing communication requests and interface calls. This division of roles makes the vehicle terminal more modular, and each process can focus on its own responsibilities, thereby improving the overall maintainability and scalability of the vehicle terminal; by sending the communication request to the execution process through the communication interface and obtaining the type of the communication request, different types of requests can be flexibly processed, thereby improving the flexibility and adaptability of the vehicle terminal.
[0057] Furthermore, the communication type includes a first call request and a second call request.
[0058] When the communication type is a first call request, the first callback interface is blocked through the communication bottom layer, so that after the execution process completes the processing of the communication request, the first callback interface is opened and the processing result of the communication request is received, so that the processing result is called back to the target process through the first callback interface.
[0059] The target process is a client process that issues a communication request.
[0060] In the above technical solution, by blocking the first callback interface, it is ensured that the caller will not continue to execute before the execution process handles the request and returns the result. This mechanism can ensure the accuracy and consistency of the processing results, which is very important in scenarios where data integrity and consistency need to be guaranteed. The blocking interface simplifies the processing logic of the caller. The caller does not need to handle asynchronous callbacks or state management while waiting for the result. The logic is more direct and clear, which reduces programming complexity and helps improve the readability and maintainability of the code.
[0061] In addition, the blocking call pattern is very suitable for synchronous scenarios that need to wait for results; for example, when the processing time of the request is short or the result needs to be obtained immediately, the blocking pattern can effectively complete the task without introducing additional asynchronous processing complexity.
[0062] Further, when the communication type is a second call request, after the execution process completes processing of the communication request, the processing result is received through the notification interface, so as to notify the target process of the processing result through the notification interface.
[0063] In the above technical solution, the non-blocking notification interface allows the caller to continue other operations while the request is issued, instead of waiting for the result to be returned. This asynchronous communication can improve the concurrency performance of the entire system and is particularly suitable for high concurrency and high throughput scenarios.
[0064] like Figure 3 As shown in the figure, the external timing of some interface calls is shown; in a basic communication link, one party, as the client, calls the client instance through getClient(), and the other party, as the server, calls the service instance through asService. Figure 3 The left app sends a communication request such as syncSendMsg() (i.e. the first call request) to send a message to the right app. After the right app receives the message and processes it, it returns the result to the left app. This is a synchronous call.
[0065] If the left app sends a communication request such as asyncSendMsg() (the second call request) to send a message to the right app, the right app will not process the message and return immediately. Instead, after the subsequent processing is completed, it will notify the left app of the result by calling the notify() interface (the notification interface). This is an asynchronous call.
[0066] When the left app initiates a synchronous call, the syncSendMsg function will block until the right app completes the processing and returns.
[0067] When the left app initiates an asynchronous call, the function asyncSendMsg will not be blocked, but will be called immediately. When the right app processes the message and notifies the left app, the left app will receive the processing result in the asynchronous callback interface (i.e., the second callback interface).
[0068] Furthermore, when encoding the service process, technical personnel in this field use C++ multi-threaded safety technology to implement it, specifically including: std::mutex locks, smart pointers, thread pool consts with thread-safe queues, and local variables, etc., so that there will be no confusion, exceptions, or other problems when multiple threads call the interface of the service process.
[0069] Embodiment 2: like Figure 4 As shown, the present application also provides a process abnormal reconnection method, wherein the communication instance includes a client instance and a service instance, including: Receive an abnormal notification of an abnormal process through the notification interface, set an abnormal flag through the client instance, and disable the communication interface, and at the same time feedback a callback error code to the abnormal process through the notification interface; wherein the abnormal process is a client process that has an abnormal state.
[0070] In this embodiment, this side is the client. After the other side dies, the service process on this side obtains the death notification (i.e., the exception notification) through the notification interface, then sets the flag indicating that the other side has died (i.e., the exception flag), and then starts trying to reconnect.
[0071] During the reconnection period, the communication interface cannot be used whether it is used for synchronization or asynchronously, and an error code indicating that the other end has died (ie, the callback error code) is returned to the abnormal process.
[0072] In the above technical solution, by timely receiving the abnormal notification of the abnormal process through the notification interface, it is possible to respond quickly to the abnormal situation, and when an abnormality is detected, the abnormal flag is set through the customer instance and the communication interface is disabled, which can effectively prevent invalid or erroneous communication requests from continuing to occupy system resources, help isolate the problem area, and protect other processes from being affected by the abnormality; the feedback callback error code helps to quickly locate the problem.
[0073] In addition, managing abnormal states through customer instances and service instances allows for more flexible handling of abnormal situations; for example, different handling strategies can be adopted based on different exception types or severities, such as restarting services, rolling back operations, or notifying administrators.
[0074] Furthermore, after receiving the abnormal notification, it also includes: An exception flag is set through the service instance, and the notification interface is disabled, and at the same time, a notification error code is fed back to the abnormal process through the first callback interface or the second callback interface.
[0075] In this embodiment, if the local side is a server, after receiving the death notification of the other end, it only needs to set the abnormal flag bit to notify that the interface cannot be used, and return the notification error code to the abnormal process, and wait for the other end to reconnect.
[0076] In the above technical solution, the method of setting the exception flag through the service instance, disabling the notification interface, and feedback the error code through the callback interface can achieve rapid response to exceptions, prevent the spread of exceptions, provide detailed error information, maintain communication consistency and improve user experience.
[0077] Furthermore, after the exception flag is set, it also includes: Reconnect the abnormal process and the service process, and after the connection is successful, delete the abnormal flag bit and open the communication interface or notification interface.
[0078] In this embodiment, no matter the local end is a client or a server, after the abnormal flag is set, it starts to try to reconnect. After the reconnection is successful, the abnormal flag is restored and various interfaces (communication interface or notification interface) are allowed to be used.
[0079] In the above technical solution, by reconnecting the abnormal process and the service process, the vehicle terminal can automatically try to restore the communication interrupted due to the abnormality. This automatic recovery mechanism reduces the need for manual intervention and improves the self-healing ability of the vehicle terminal; deleting the abnormal flag and reopening the communication interface or notification interface indicates that the vehicle terminal has successfully recovered to a normal state. This recovery mechanism ensures that the vehicle terminal can quickly return to a stable working state after the abnormality, thereby improving the overall stability.
[0080] Embodiment three: The present application also provides a vehicle-mounted terminal, which is configured with at least one service process and multiple client processes. The service process and the client processes, as well as the client processes, communicate with each other using the inter-process communication method described in Example 1 and Example 2.
[0081] In the above technical solution, the service process can centrally handle core services or shared resources, while the client process is responsible for specific functions or tasks. This modular design improves the organizational structure and code maintainability of the vehicle terminal. Through inter-process communication, each client process can be independently developed and updated without affecting the service process or other client processes. This design allows flexible expansion and maintenance of the vehicle terminal functions, allowing the vehicle terminal to easily adapt to future needs or changes. The isolation between the service process and the client process can improve the stability of the vehicle terminal. If a problem occurs in a client process, the service process and other client processes will not be affected.
[0082] Embodiment 4: The present application also provides a storage medium, in which a computer program is stored, wherein the computer program is configured to execute the inter-process communication method described in Embodiment 1 and Embodiment 2 when running.
[0083] In this embodiment, the storage medium stores a number of computer programs for enabling the vehicle-mounted terminal to execute all or part of the steps of the method described in each embodiment of the present application.
[0084] The medium may include a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and other media that can store program codes.
[0085] In summary, the present application provides an inter-process communication method, a vehicle-mounted terminal, and a storage medium; the service process receives the communication requests of each client process, and creates a communication instance corresponding to the communication request, and provides a corresponding communication interface call to the communication bottom layer through the communication instance, and the communication bottom layer determines whether to block the communication interface based on the communication type of the communication request, so as to call back or notify the corresponding client process of the processing result of the communication request through the communication interface or notification interface based on the blocking state. In the present application, since the communication instance and the communication bottom layer are encapsulated in the service process, all inter-process communications can be centrally managed, which simplifies the communication process and reduces complexity; the service process can provide flexible processing methods for different request types; at the same time, the service process can also support synchronous calls and asynchronous calls to provide flexible communication support.
[0086] Although example embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above example embodiments are merely exemplary and are not intended to limit the scope of the present application to this. Those of ordinary skill in the art may make various changes and modifications therein without departing from the scope and spirit of the present application. All these changes and modifications are intended to be included within the scope of the present application as required by the appended claims.
[0087] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0088] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.
[0089] The various component embodiments of the present application can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) can be used in practice to implement some or all functions of some modules according to the embodiments of the present application. The application can also be implemented as a device program (e.g., computer program and computer program product) for executing a part or all of the methods described herein. Such a program implementing the present application can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.
[0090] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.
[0091] Although the description of the present application is carried out in conjunction with the above specific embodiments, it is obvious that those skilled in the art can make many substitutions, modifications and changes based on the above content. Therefore, all such substitutions, improvements and changes are included in the spirit and scope of the appended claims.
Claims
1. An inter-process communication method, characterized in that: The following steps are involved: The service process receives the communication requests from each client process, creates a communication instance corresponding to the communication request, and provides a corresponding communication interface call to the communication bottom layer through the communication instance; and The communication bottom layer determines whether to block the communication interface based on the communication type of the communication request, so as to call back or notify the corresponding client process of the processing result of the communication request through the communication interface or notification interface based on the blocking state; Wherein, the communication instance and the communication bottom layer are both encapsulated in the service process.
2. The inter-process communication method according to claim 1, characterized in that: Also includes: The communication bottom layer encapsulates the communication interface and the notification interface; wherein the communication interface includes a first callback interface and a second callback interface.
3. The inter-process communication method according to claim 2, characterized in that: After providing the corresponding communication interface call to the communication bottom layer, it includes: Sending the communication request to the execution process through the communication interface, and obtaining the communication type of the communication request; The execution process is a client process that processes the communication request.
4. The inter-process communication method according to claim 3, characterized in that: The communication type includes a first call request and a second call request; When the communication type is a first call request, the first callback interface is blocked through the communication bottom layer, so that after the execution process completes processing of the communication request, the first callback interface is opened and the processing result of the communication request is received, so that the processing result is called back to the target process through the first callback interface; The target process is a client process that issues a communication request.
5. The inter-process communication method according to claim 3, characterized in that: When the communication type is a second call request, after the execution process completes processing of the communication request, the processing result is received through the notification interface, so as to notify the target process of the processing result through the notification interface.
6. The inter-process communication method according to claim 1, characterized in that: The communication instance includes a client instance and a service instance, and also includes: Receive an abnormal notification of an abnormal process through the notification interface, set an abnormal flag through the client instance, disable the communication interface, and feed back a callback error code to the abnormal process through the notification interface; The abnormal process is a client process that is in an abnormal state.
7. The inter-process communication method according to claim 6, characterized in that: After receiving the exception notification, it also includes: An exception flag is set through the service instance, and the notification interface is disabled, and at the same time, a notification error code is fed back to the abnormal process through the first callback interface or the second callback interface.
8. The inter-process communication method according to claim 7, characterized in that: After setting the exception flag, it also includes: The abnormal process and the service process are reconnected, and after the connection is successful, the abnormal flag is deleted, and the communication interface or the notification interface is opened at the same time.
9. A vehicle-mounted terminal, characterized in that: The vehicle-mounted terminal is configured with at least one service process and multiple client processes, and the service process and the client processes, as well as the client processes, communicate with each other using the inter-process communication method as described in any one of claims 1-8.
10. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the inter-process communication method according to any one of claims 1 to 8 when running.