Cross-process communication method, electronic device, and computer-readable storage medium
Cross-process communication is achieved by using the call method of ContentProvider, which solves the problems of high development cost and low efficiency of cross-process communication in the Android system in the smart cockpit scenario, and realizes fast response and high stability communication.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI VISTEON AUTOMOTIVE ELECTRONICS SYST
- Filing Date
- 2026-04-22
- Publication Date
- 2026-07-21
AI Technical Summary
Existing cross-process communication methods in Android systems are costly to develop and adapt for concurrent operation of multiple applications in smart cockpits, have poor scalability, complex and time-consuming communication processes, are easily affected by service status, and result in low interaction efficiency.
Cross-process communication is achieved using the `call` method of ContentProvider. Requests are encapsulated using a unified resource identifier (URI) and a `Bundle` parameter, allowing for direct initiation and processing of cross-process requests. This simplifies the interface definition and binding process and reduces intermediate steps.
It reduces development and adaptation costs, improves system expansion flexibility, shortens development cycle, increases response speed to millisecond level, adapts to the low latency requirements of high-frequency interaction of multiple cockpit applications, and improves communication stability to 99.5%.
Smart Images
Figure CN122431913A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of inter-process communication technology, and particularly relates to an inter-process communication method, electronic device, and computer-readable storage medium. Background Technology
[0002] With the advancement of automotive intelligence, the modern cockpit has evolved from a single control platform into a multi-module collaborative intelligent interaction hub. The parallel operation of various applications, such as in-vehicle navigation, entertainment, and driver assistance, has become the norm. Frequent interaction between applications is required to achieve functional linkage (such as synchronizing navigation traffic information to the instrument panel and adaptively adjusting entertainment volume according to driving scenarios). The efficiency and convenience of inter-process communication (IPC) have become core indicators determining the cockpit interaction experience, highlighting the increasing limitations of existing communication solutions.
[0003] Currently, in the Android system, cross-process communication between applications is typically implemented using AIDL (Android Interface Definition Language). When using this method, the communicating parties usually need to pre-agree on the interface definition. The requesting party establishes a connection with the target party through a binding service (bindService), obtains an IBinder object after the connection is established, and then completes the cross-process call based on the IBinder object.
[0004] However, in scenarios where multiple applications operate concurrently and functional linkages occur frequently in intelligent cockpits, the aforementioned AIDL-based cross-process communication method has gradually revealed the following problems: First, AIDL typically requires developers to pre-write and maintain interface files, and the requesting and server sides need to adapt to each other based on interface names, method definitions, parameter types, and other details. When business logic is adjusted or new features are added, it is often necessary to synchronously modify the interface definition and the code implementation on both sides, resulting in high development and adaptation costs and poor scalability.
[0005] Secondly, the AIDL method usually requires two core operations: binding the service (bindService) and obtaining the IBinder object, before further initiating cross-process calls. This process involves many steps, is time-consuming, and the binding process is easily affected by the service status, leading to errors.
[0006] Furthermore, existing AIDL methods typically require additional callback interfaces to return execution results, further complicating the communication process and increasing development and maintenance costs. Summary of the Invention
[0007] Based on this, and in response to the aforementioned technical problems, a cross-process communication method, an electronic device, and a computer-readable storage medium are provided.
[0008] The technical solution adopted in this invention is as follows: As a first aspect of the present invention, a cross-process communication method is provided, applied to a request-initiating process, characterized in that it includes: Based on the business logic to be executed, determine the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process; An identifier corresponding to the service to be executed is generated, and the request parameters corresponding to the service to be executed are determined to form a cross-process request, wherein the cross-process request includes the identifier and the request parameters; The cross-process request is initiated to the request receiving and processing process via the `call` method of the ContentProvider, based on the URI. The request receiving and processing process then: receives the cross-process request via the `call` method of the ContentProvider; determines the corresponding request processing logic based on the Uniform Resource Identifier (URI) corresponding to the cross-process request; parses the cross-process request using the request processing logic and distributes it to the corresponding business interface based on the identifier, so that the business interface processes the request based on the request parameters; obtains the processing result of the business interface; generates a result notification based on the processing result; and returns the result notification to the request initiating process via the `call` method. The request is received, and the result notification returned by the processing process is received.
[0009] As a second aspect of the present invention, a cross-process communication method is provided, applied to a request receiving and processing process, characterized in that it includes: The cross-process request sent by the request initiating process is received through the `call` method of the ContentProvider. The request initiating process: determines the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process based on the business logic to be executed; generates an identifier corresponding to the business logic to be executed and determines the request parameters corresponding to the business logic to be executed, thereby forming the cross-process request, which includes the identifier and request parameters; and initiates the cross-process request to the request receiving and processing process based on the URI through the `call` method of the ContentProvider. Based on the Uniform Resource Identifier (URI) corresponding to the cross-process request, determine the corresponding request processing logic; The request processing logic parses the cross-process request and distributes it to the corresponding business interface based on the identifier, so that the business interface can process the request based on the request parameters. Obtain the processing result of the business interface, generate a result notification based on the processing result, and return the result notification to the request initiating process through the call method, so that the request initiating process: receives the result notification returned by the request receiving processing process.
[0010] As a third aspect of the present invention, a cross-process communication method is provided, characterized in that it includes: The request initiating process determines the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process based on the business logic to be executed. The request initiating process generates an identifier corresponding to the service to be executed and determines the request parameters corresponding to the service to be executed to form a cross-process request, the cross-process request including the identifier and the request parameters; The request initiating process initiates the cross-process request to the request receiving and processing process based on the URI through the call method of the ContentProvider; The request receiving and processing process receives the cross-process request through the call method of ContentProvider; The request receiving and processing process determines the corresponding request processing logic based on the Uniform Resource Identifier (URI) corresponding to the cross-process request, parses the cross-process request through the request processing logic, and distributes the cross-process request to the corresponding business interface according to the identifier, so that the business interface processes the request based on the request parameters. The request receiving and processing process obtains the processing result of the business interface, generates a result notification based on the processing result, and returns the result notification to the request initiating process through the call method; The request initiating process receives the result notification returned by the request receiving processing process.
[0011] As a fourth aspect of the present invention, an electronic device is provided, characterized in that it includes a storage module, the storage module including instructions loaded and executed by a processor, the instructions, when executed, causing the processor to perform an inter-process communication method as described in the first, second or third aspects above.
[0012] As a fifth aspect of the present invention, a computer-readable storage medium is provided that stores one or more programs, characterized in that, when the one or more programs are executed by a processor, they implement an inter-process communication method as described in the first, second, or third aspects above.
[0013] The beneficial effects of this invention are as follows: 1. This invention achieves cross-process communication through the call method of ContentProvider, eliminating the need to predefine complex interfaces using AIDL, avoiding the risk of communication failures caused by interface inconsistencies, saving repetitive work on interface adaptation and debugging, reducing development and adaptation costs, improving system expansion flexibility, and eliminating the need to define additional callback interfaces, thus greatly shortening the development cycle.
[0014] 2. Unlike the AIDL solution, this invention eliminates the need for the two core operations of binding the service (bindService) and obtaining the IBinder object, reducing intermediate steps in the communication establishment process, shortening the cross-process communication link, and helping to improve request response efficiency. The response speed is improved to the millisecond level, which is suitable for the low latency requirements of high-frequency interaction of multiple applications in the cockpit. Attached Figure Description
[0015] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments: Figure 1 A flowchart illustrating a cross-process communication method provided in an embodiment of the present invention; Figure 2 A schematic diagram of an electronic device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of an embodiment of the present invention. Detailed Implementation
[0016] The embodiments of the present invention will be described below with reference to the accompanying drawings. It should be noted that the embodiments described in this specification are not exhaustive and do not represent the only embodiments of the present invention. The corresponding embodiments below are only for clearly illustrating the inventive content of this patent and are not intended to limit its implementation. For those skilled in the art, different variations and modifications can be made based on the embodiments described. Any variations or modifications that fall within the technical concept and inventive content of this invention and are obvious are also within the protection scope of this invention.
[0017] This application provides a cross-process communication method, such as... Figure 3 As shown, it implements cross-process communication based on a client-server architecture. The client corresponds to the request initiating process, which contains the ContentProviderClient(call) module and the CommandControllerCallback(Client) module; the server corresponds to the request receiving and processing process, which contains the ContentProvider(call) module, the CommandControllerCallback(server) module, and the business interface. Figure 1 and Figure 3As shown, the specific flow of the method in this application embodiment is as follows: S101. The request initiating process determines the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process based on the business to be executed.
[0018] The CommandControllerCallback (Client) module provides remote call entry points. In this embodiment, these entry points include setter call entry points (callRemoteMethodSetVal), getter call entry points (callRemoteMethodGetVal), register call entry points (callRemoteMethodRegister), and unregister call entry points (callRemoteMethodUnregister), etc. The request initiating process responds to call requests initiated by upper-layer applications or business modules, determining the specific business to be executed based on the called remote call entry point and the business parameters carried in the call request.
[0019] The CommandControllerCallback (Client) module's subclasses predefine the URIs of the target ContentProviders corresponding to different business logic. After determining the business logic to be executed, the request-initiating process retrieves the URI from the corresponding subclass to determine the target ContentProvider for the request-receiving and processing process. It should be noted that ContentProvider is one of the four major components of Android.
[0020] S102. The request initiating process generates an identifier corresponding to the business to be executed and determines the request parameters corresponding to the business to be executed, so as to form a cross-process request.
[0021] Cross-process requests include an identifier and request parameters. In this embodiment, the CommandControllerCallback (Client) module encapsulates the identifier as part of the request parameters, along with other request parameters, within a Bundle. It should be noted that a Bundle is Android's data transfer container.
[0022] In a specific example, when the service to be executed is to turn on Wi-Fi, the request parameters in the Bundle are as follows: ACTION=ON_SET,String key_WIFI_OPT, int val = SWITCH_ON or SWITCH_OFF. Here, ON_SET is the identifier corresponding to the service to be executed, which is used to distinguish it by using the ACTION field as part of the request parameters. String key_WIFI_OPT is used to indicate that the current service of the request receiving and processing process is Wi-Fi. int val = SWITCH_ON or SWITCH_OFF is used to indicate the target state corresponding to the setting operation of the service object. SWITCH_ON means that Wi-Fi is turned on, and SWITCH_OFF means that Wi-Fi is turned off.
[0023] S103. The request initiating process initiates a cross-process request to the request receiving and processing process based on the URI through the call method of ContentProvider.
[0024] Specifically, the ContentProviderClient(call) module uses the call method to ensure that cross-process requests are directly routed to the ContentProvider(call) module of the corresponding receiving and processing process.
[0025] S104. The request receiving and processing process receives cross-process requests through the call method of ContentProvider.
[0026] Specifically, the ContentProvider(call) module receives cross-process requests.
[0027] S105. The request receiving and processing process determines the corresponding request processing logic based on the Uniform Resource Identifier (URI) corresponding to the cross-process request, parses the cross-process request through the request processing logic, and distributes the cross-process request to the corresponding business interface according to the identifier, so that the business interface can process it based on the request parameters.
[0028] Since cross-process requests are sent to the target ContentProvider(call) module based on the corresponding URI, the request receiving and processing side can obtain the URI corresponding to this cross-process request when routing the cross-process request to the ContentProvider(call) module corresponding to the request receiving and processing process. Furthermore, the ContentProvider(call) module can receive multiple URIs, each corresponding to different processing logic in different business scenarios. Further, the CommandControllerCallback(server) module first finds the corresponding implementation class (i.e., the corresponding processing logic) based on the URI and creates a singleton instance, then calls the instance's handCallMethod method to decompose the Bundle parameters.
[0029] like Figure 3 As shown, onSetVal, onGetVal, onRegister, and onUnRegister are examples of business interfaces, used to handle set-value, retrieve-value, register-value, and unregister-value business operations, respectively. When ACTION=ON_SET, the corresponding business interface is onSetVal.
[0030] S106. The request receiving and processing process obtains the processing result of the business interface, generates a result notification based on the processing result, and returns the result notification to the request initiating process through the call method.
[0031] In this embodiment, the result notification is returned in Bundle form. The `call` method of the `ContentProvider(call)` module supports returning Bundle results. Therefore, after the business interface is processed, the result notification is encapsulated into a Bundle and returned. For example, the result notification for opening the Wi-Fi service is: `ACTION=NOTIFY, ret=true`.
[0032] S107. The request initiating process receives the result notification returned by the request receiving and processing process.
[0033] After receiving the result notification, the request initiating process parses it and connects it to subsequent business logic. Specifically, the CommandControllerCallback (Client) module breaks down the Bundle parameters. Taking the above-mentioned notification of enabling Wi-Fi as an example, the request initiating process can know that it has received a notification by setting ACTION=NOTIFY, and know that Wi-Fi was successfully enabled by setting ret=true.
[0034] As can be seen from the above, the cross-process communication method provided in this application has the following beneficial effects: 1. This invention achieves cross-process communication through the call method of ContentProvider, eliminating the need to predefine complex interfaces using AIDL, avoiding the risk of communication failures caused by interface inconsistencies, saving repetitive work on interface adaptation and debugging, reducing development and adaptation costs, improving system expansion flexibility, and eliminating the need to define additional callback interfaces, thus greatly shortening the development cycle.
[0035] 2. Unlike the AIDL solution, this invention eliminates the need for the two core operations of binding the service (bindService) and obtaining the IBinder object, reducing intermediate steps in the communication establishment process, shortening the cross-process communication link, and helping to improve request response efficiency. The response speed is improved to the millisecond level, which is suitable for the low latency requirements of high-frequency interaction of multiple applications in the cockpit.
[0036] 3. This invention has lower maintenance complexity: It replaces fixed interfaces with a standardized format of Bundle + Action (Bundle passes parameters, Action distinguishes methods), which reduces the cost of debugging compatibility between modules. When iterating functions later, there is no need to modify the interface definition synchronously, reducing maintenance manpower costs by about 30%. At the same time, communication stability is improved to over 99.5% due to the simplification of the process.
[0037] Similar to the above concept, Figure 2 A schematic block diagram of the structure of an electronic device provided by an embodiment of the present invention is shown.
[0038] For example, the electronic device includes a storage module 21 and a processor 22. The storage module 21 includes instructions loaded and executed by the processor 22, which, when executed, cause the processor 22 to perform the steps described in the section on an inter-process communication method of the present specification according to various exemplary embodiments of the present invention.
[0039] It should be understood that processor 22 can be a Central Processing Unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, the general-purpose processor can be a microprocessor or any conventional processor.
[0040] This invention also provides a computer-readable storage medium that stores one or more programs, which, when executed by a processor, implement the steps described in the above section on an inter-process communication method according to various exemplary embodiments of the invention.
[0041] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer-readable storage media (or non-transitory media) and communication media (or transient media).
[0042] As is known to those skilled in the art, the term computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0043] For example, the computer-readable storage medium may be an internal storage unit of the electronic device described in the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., provided on the electronic device.
[0044] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A cross-process communication method, applied to a request-initiating process, characterized in that, include: Based on the business logic to be executed, determine the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process; An identifier corresponding to the service to be executed is generated, and the request parameters corresponding to the service to be executed are determined to form a cross-process request, wherein the cross-process request includes the identifier and the request parameters; The cross-process request is initiated to the request receiving and processing process based on the URI through the call method of the ContentProvider, so that the request receiving and processing process receives the cross-process request through the call method of the ContentProvider. Based on the Uniform Resource Identifier (URI) corresponding to the cross-process request, determine the corresponding request processing logic; The request processing logic parses the cross-process request and distributes it to the corresponding business interface according to the identifier, so that the business interface processes the request based on the request parameters; the processing result of the business interface is obtained, a result notification is generated based on the processing result, and the result notification is returned to the request initiating process through the call method; The request is received, and the result notification returned by the processing process is received.
2. The cross-process communication method according to claim 1, characterized in that, The identifier of the cross-process request is encapsulated in a Bundle along with other request parameters as part of the request parameters, and the result notification is returned in Bundle form.
3. A cross-process communication method, applied to a request receiving and processing process, characterized in that, include: The cross-process request sent by the request initiating process is received through the `call` method of the ContentProvider. The request initiating process: determines the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process based on the business logic to be executed; generates an identifier corresponding to the business logic to be executed and determines the request parameters corresponding to the business logic to be executed, thereby forming the cross-process request, which includes the identifier and request parameters; and initiates the cross-process request to the request receiving and processing process based on the URI through the `call` method of the ContentProvider. Based on the Uniform Resource Identifier (URI) corresponding to the cross-process request, determine the corresponding request processing logic; The request processing logic parses the cross-process request and distributes it to the corresponding business interface based on the identifier, so that the business interface can process the request based on the request parameters. Obtain the processing result of the business interface, generate a result notification based on the processing result, and return the result notification to the request initiating process through the call method, so that the request initiating process: receives the result notification returned by the request receiving processing process.
4. The cross-process communication method according to claim 3, characterized in that, The identifier of the cross-process request is encapsulated in a Bundle along with other request parameters as part of the request parameters, and the result notification is returned in Bundle form.
5. A cross-process communication method, characterized in that, include: The request initiating process determines the Uniform Resource Identifier (URI) of the ContentProvider corresponding to the request receiving and processing process based on the business logic to be executed. The request initiating process generates an identifier corresponding to the service to be executed and determines the request parameters corresponding to the service to be executed to form a cross-process request, the cross-process request including the identifier and the request parameters; The request initiating process initiates the cross-process request to the request receiving and processing process based on the URI through the call method of the ContentProvider; The request receiving and processing process receives the cross-process request through the call method of ContentProvider; The request receiving and processing process determines the corresponding request processing logic based on the Uniform Resource Identifier (URI) corresponding to the cross-process request, parses the cross-process request through the request processing logic, and distributes the cross-process request to the corresponding business interface according to the identifier, so that the business interface processes the request based on the request parameters. The request receiving and processing process obtains the processing result of the business interface, generates a result notification based on the processing result, and returns the result notification to the request initiating process through the call method; The request initiating process receives the result notification returned by the request receiving processing process.
6. The cross-process communication method according to claim 5, characterized in that, The identifier of the cross-process request is encapsulated in a Bundle along with other request parameters as part of the request parameters, and the result notification is returned in Bundle form.
7. An electronic device, characterized in that, The system includes a storage module comprising instructions loaded and executed by a processor, the instructions, when executed, causing the processor to perform an inter-process communication method according to any one of claims 1-6.
8. A computer-readable storage medium storing one or more programs, characterized in that, When the one or more programs are executed by the processor, they implement the cross-process communication method according to any one of claims 1-6.