Cross-process communication method and related device
By using the target service binding interface integrated by SDK in Android system for cross-process communication, the process priority coupling problem caused by AMS mediation is solved, and the process priority decoupling and system performance improvement are achieved.
Patent Information
- Application Number
- CN202510184453.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-19
- Publication Date
- 2025-05-30
AI Technical Summary
In Android system, when cross-process communication is performed through AMS as an intermediary, the process binding causes the process priority to be consistent, which in turn causes the system to be unable to recycle low-priority process resources in time, resulting in resource redundancy and poor system performance.
By integrating the SDK on the first process and the second process side, cross-process communication is performed using the target service binding interface, the priority coupling of AMS is avoided and the process priority decoupling is achieved.
It realizes that service calls between processes do not require priority coupling, avoid resource redundancy, and improve system performance.
Smart Images
Figure CN120066822A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of application programs, and in particular, to a cross-process communication method and related devices. Background Art
[0002] In the Android system, multiple application programs providing service functions are deployed. A process is an instance for executing an application program. In the existing Android system, when performing cross-process communication through the Android system AMS (ActivityManagerService, activity management service) as an intermediary based on the Binder mechanism, after different processes establish a binding relationship, the process priority management service in AMS will synchronize the importance indicators of the processes, making the priorities of the two bound processes the same. After increasing the process priority, the system cannot recycle the process resources in time, resulting in resource redundancy. Therefore, using the bindService method for cross-process communication will cause redundant process resources to occupy the Android system memory, thereby reducing the system performance.
[0003] For example, process A for executing application program A is a high-priority resident process, and process B for executing application program B is a low-priority non-resident process. When process A binds to process B, due to the process priority management service under the AMS mechanism, process B will also remain resident, and the resources of process B cannot be recycled by the system in time, resulting in the process resources of process B becoming redundant process resources that occupy the Android system memory, thereby affecting the system performance. Summary of the Invention
[0004] In view of the above problems, this application provides a cross-process communication method and related devices. The specific solutions are as follows:
[0005] In a first aspect of this application, a cross-process communication method is provided, which is applied to a cross-process communication system. The cross-process communication system includes a first process running a first application program and at least one second process running a second application program. The first application program integrates a first type of SDK, and the second application program integrates a second type of SDK. The cross-process communication method includes:
[0006] The first process calls a target service binding interface through the first type of SDK to send a service call request. The target service binding interface is pre-encapsulated in the first type of SDK, and the interface parameters are the same as those of the native service binding interface of the Android system. The interface parameters include at least one set of package name and service name, and the service call request includes a target package name and a target service name;
[0007] The target second process receives the service call request through the second type of SDK, obtains a target IBinder service instance based on the target package name and the target service name, and sends the target IBinder service instance to the first process;
[0008] The first process receives the target IBinder service instance through the first type of SDK and establishes communication with the target second process based on the target IBinder service instance.
[0009] In a possible implementation manner, obtaining a target IBinder service instance based on the target package name and the target service name includes:
[0010] The target second process splices the target package name and the target service name according to a preset instance design rule through the second type of SDK to generate a target instance name;
[0011] The target second process searches through the second type of SDK whether there is an IBinder service instance in the IBinder service instance library with the target instance name as the instance name; if it exists, obtains the target IBinder service instance from the IBinder service instance library, and the instance name of the target IBinder service instance is the target instance name; if it does not exist, creates the target IBinder service instance.
[0012] In a possible implementation manner, after creating the target IBinder service instance, the cross-process communication method further includes:
[0013] The target second process caches the target IBinder service instance to the IBinder service instance library through the second type of SDK.
[0014] In a possible implementation manner, the communication system further includes a proxy module configured in the Android system. After the first process calls the target service binding interface through the first type of SDK to send a service call request, the cross-process communication method further includes:
[0015] The proxy module determines whether the target second process is in a running state based on the target package name; if not, starts the target second process.
[0016] In a possible implementation manner, the cross-process communication method further includes:
[0017] Each second process creates a content provider component through the second type of SDK, obtains the package name of the second process, and generates and registers a component identifier for the content provider component based on the package name of the second process;
[0018] The proxy module determines whether the target second process is in a running state based on the target package name, including: the proxy module generates a target component identifier based on the target package name, and after determining that the second process registering the target component identifier is the target second process, determines whether the target second process is in a running state.
[0019] In a possible implementation, the first process sends a service call request by calling a target service binding interface through a first type of SDK, including:
[0020] The first process sends the service call request to the second process by calling a content provider component interface function of the second process, and the content provider component interface function is pre-encapsulated in the second type of SDK;
[0021] The target second process receives the service call request through the second type of SDK, including:
[0022] The target second process receives the service call request by calling a content provider component interface function through the second type of SDK.
[0023] The second aspect of the present application provides a cross-process communication system, which includes a first process running a first application and at least one second process running a second application. The first application integrates a first type of SDK, and the second application integrates a second type of SDK:
[0024] The first process is used for: sending a service call request by calling a target service binding interface through the first type of SDK, receiving a target IBinder service instance, and establishing communication with a target second process based on the target IBinder service instance;
[0025] Wherein, the target service binding interface is pre-encapsulated in the first type of SDK, and the interface parameters are the same as those of the native service binding interface of the Android system. The interface parameters include at least one set of package name and service name, and the service call request includes a target package name and a target service name;
[0026] The target second process is used for: receiving the service call request through the second type of SDK, obtaining the target IBinder service instance based on the target package name and the target service name, and sending the target IBinder service instance to the first process.
[0027] In a third aspect of the present application, there is provided a computer program product, including computer-readable instructions, which, when running on an electronic device, enable the electronic device to implement the cross-process communication method in the above-mentioned first aspect or any implementation manner of the first aspect.
[0028] In a fourth aspect of the present application, there is provided an electronic device, including at least one processor and a memory connected to the processor, wherein:
[0029] The memory is used for storing a computer program;
[0030] The processor is used for executing the computer program, so that the electronic device can implement the cross-process communication method in the above-mentioned first aspect or any implementation manner of the first aspect.
[0031] In a fifth aspect of the present application, there is provided a computer storage medium, which carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the cross-process communication method in the above-mentioned first aspect or any implementation manner of the first aspect.
[0032] By means of the above technical solutions, a cross-process communication method and related devices provided by the present application. The cross-process communication system includes a first process running a first application program and at least one second process running a second application program. The first application program integrates a first type of SDK, and the second application program integrates a second type of SDK. The first process sends a service call request by calling a target service binding interface through the first type of SDK. The target service binding interface is pre-encapsulated in the first type of SDK, and the interface parameters are the same as those of the native service binding interface of the Android system. The interface parameters include at least one set of package name and service name, and the service call request includes a target package name and a target service name. The target second process receives the service call request through the second type of SDK, obtains a target IBinder service instance based on the target package name and the target service name, and sends the target IBinder service instance to the first process. It can be seen that the first process receives the target IBinder service instance through the first type of SDK and establishes communication with the target second process based on the target IBinder service instance. Compared with the cross-process communication mediated by AMS in the prior art, this solution can implement service calls between processes without priority coupling. After the processes are bound, the process priorities are not affected, achieving decoupling of process priorities and achieving the goal of improving system performance. Further, by integrating SDKs on the first process side and the second process side, and the first type of SDK integrated by the first application program encapsulates a target service binding interface for replacing the native service binding interface, there is no need to modify the native function codes on both sides, thus realizing seamless integration and reducing the complexity of cross-process communication. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] In combination with the accompanying drawings and with reference to the following specific embodiments, the above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic and the original and elements are not necessarily drawn to scale.
[0034] Figure 1 It is a schematic flowchart of a cross-process communication method provided by an embodiment of the present application;
[0035] Figure 2 It is a specific implementation flowchart of a cross-process communication method provided by an embodiment of the present application;
[0036] Figure 3 It is a signal interaction diagram of a cross-process communication method provided by an embodiment of the present application;
[0037] Figure 4 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Specific Embodiments
[0038] The following describes the embodiments of the present application in combination with the drawings in the embodiments of the present application. The terms used in the embodiments of the present application are only used to explain the specific embodiments of the present application, and are not intended to limit the present application.
[0039] The following describes the embodiments of the present application in combination with the drawings. Those skilled in the art know that with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.
[0040] The terms "first", "second", etc. in the specification, claims and above drawings of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is only a way of distinguishing objects with the same attributes when describing the embodiments of the present application. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device comprising a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.
[0041] The present application can be applied to the field of application program technology, and specifically can be applied to cross-process communication when different application programs are running in a cockpit system. It should be noted that the active binding end is called the binding end process, and the bound end is called the bound end process.
[0042] The Binder communication mechanism is an important inter - process communication method in the Android system. In the existing technology under the Binder communication mechanism, after the first process uses the native bindService in the Android system to establish a binding relationship with the second process to achieve cross - process communication, the first process uses the Android system AMS (ActivityManagerService, activity management service) as an intermediary. AMS starts the second process and calls to create the IBinder instance of the second process, and then calls back to the first - end process. Further, after the AMS internally updates the process priority and establishes the binding relationship between the binding - end process and the bound - end process using the preset bindService interface of the binding service, due to the process priority management function of AMS, the problem that it is difficult to recycle the resources of the bound - end process will occur when the priority of the bound - end process is increased.
[0043] To solve the above - mentioned technical problems, the embodiments of the present application provide a cross - process communication method, which realizes that when each application program in the cockpit system uses the Binder communication mechanism for cross - process communication, the binding relationship is not coupled, so that the priority of the bound - end process is not affected by the binding relationship. Therefore, the system can effectively recycle the resources of the bound - end process with low priority and solve the problem that the system memory is occupied by redundant process resources.
[0044] The embodiments of the present application provide a cross - process communication method applied to a cross - process communication system. The cross - process communication system includes a first process running a first application program and at least one second process running a second application program. The first application program integrates a first - type SDK, and the second application program integrates a second - type SDK.
[0045] Figure 1 The implementation process of a cross - process communication method provided by the embodiments of the present application is as Figure 1 shown. This method includes:
[0046] S101. The first process sends a service call request by calling the target service binding interface through the first - type SDK.
[0047] In this embodiment, the target service binding interface is pre - encapsulated in the first - type SDK, and the interface parameters are the same as those of the native service binding interface of the Android system. The interface parameters include at least one set of package names and service names, and the service call request includes a target package name and a target service name.
[0048] S102. The target second process receives the service call request through the second - type SDK, obtains the target IBinder service instance based on the target package name and the target service name, and sends the target IBinder service instance to the first process.
[0049] S103. The first process receives the target IBinder service instance through the first type of SDK, and establishes communication with the target second process based on the target IBinder service instance.
[0050] As can be seen from the above technical solution, in a cross-process communication method provided by an embodiment of the present application, the first process receives the target IBinder service instance through the first type of SDK, and establishes communication with the target second process based on the target IBinder service instance. Compared with the cross-process communication mediated by AMS in the prior art, this solution can implement service calls between processes without priority coupling. After the process is bound, it does not affect the process priority, realizing the decoupling of process priorities and achieving the goal of improving system performance. Further, by integrating the SDK on the first process side and the second process side, and the first type of SDK integrated in the first application encapsulates the target service binding interface for replacing the native service binding interface, there is no need to modify the native function codes on both sides, thus realizing seamless integration and reducing the complexity of cross-process communication.
[0051] See Figure 2 , Figure 2 which is a specific implementation flowchart of a cross-process communication method provided by an embodiment of the present application. This method is specifically applied to a communication system composed of a first application and a second application. The first process is the process running the first application, also known as the binding-end process, and the second process is the process running the second application, also known as the bound-end process.
[0052] The first application pre-integrates the first type of SDK (Software Development Kit), and the first type of SDK is used to provide the target binding service bindService interface (referred to as the target bindService) for replacing the native binding service interface (referred to as the native bindService) of the Android system. The configuration information of the target bindService includes the interface parameters corresponding to the second process. The interface parameters corresponding to a second process include the package name PackageName and the service name ServiceName. Among them, the interface parameters corresponding to the second process in the configuration information of the target bindService are exactly the same as the interface parameters corresponding to the second process in the configuration information of the native bindService. In addition, the first type of SDK also includes a listening interface to implement the listening of the process status of other processes and maintain compatibility with the native logic.
[0053] It should be noted that the target bindService that replaces the native bindService is encapsulated in the first type of SDK. By configuring the target bindService, the interface parameters corresponding to the second process in the configuration information of the target bindService are made exactly the same as the interface parameters corresponding to the second process in the configuration information of the native bindService. Therefore, only by calling the bindService interface encapsulated in the first type of SDK can the purpose of efficient integration and compatibility with the original code be achieved.
[0054] The second type of SDK is pre-integrated in the second application. During the compilation stage of the second application, the second type of SDK is used to register and create a content provider component ContentProvider in the second process, automatically obtain the package name PackageName of the second process, and automatically generate a unique identifier for the ContentProvider based on the PackageName, denoted as the ContentProvider identifier. Therefore, there is no need to manually write the code logic for creating the ContentProvider of the second process and configure the Manifest file. During the running stage of the second process, the second type of SDK is used to retrieve the preset IBinder service instance library according to the package name and service name in the received service call request. Since the package name of each process in Android is definitely unique and the service class name inside each process is also unique, the IBinder service instance indicated by the service call request is obtained, or the IBinder service instance indicated by the service call request is automatically created and cached in the IBinder service instance library for other processes to call. Among them, the IBinder service instance library includes the cached IBinder service instances and the instance names of the IBinder service instances. The instance name is a unique identifier generated by concatenating the package name and the service name based on the preset instance design rules.
[0055] Based on this, an embodiment of the present application provides a cross-process communication method, as Figure 2 shown. Specifically, this method includes:
[0056] S201. The first process calls the target bindService interface in the first type of SDK to send a service call request to the target second process.
[0057] In this embodiment, the service call request is used to call the IBinder service instance of the target second process, and the service call request includes: the target package name and the target service name.
[0058] In this embodiment, based on the ContentProvider mechanism of the Android system, the service call proxy module configured in the Android system generates a target ContentProvider identifier according to the target package name, and checks whether the second process that registers the target ContentProvider identifier exists according to the ContentProvider identifier. If not, the second process is launched.
[0059] If it exists, it means that the second process indicated by the service call request is running. The first process sends a service call request to the second process by calling the ContentProvider interface function (ContentProvider: call()) of the second process. This ContentProvider interface function is pre-encapsulated in the second type of SDK, that is, SMServerSDK.
[0060] S202. The target second process receives the service call request by calling the ContentProvider interface function through the second type of SDK, and splices the target package name and the target service name according to the preset instance design rules to generate a target instance name.
[0061] S203. The target second process checks whether there is a target IBinder service instance in the IBinder service instance library based on the target instance name through the second type of SDK.
[0062] In this embodiment, the target IBinder service instance is an IBinder service instance identified by the target instance name as an example.
[0063] In this embodiment, the IBinder service instance library, that is, the Service instance library, stores multiple IBinder service instances. For example, IBinder instances, and an IBinder instance is uniquely identified by an instance name. The instance name of the IBinder instance is obtained by splicing the package name and the service name according to the instance design rules to obtain the IBinder service instance.
[0064] In this embodiment, check whether the target instance name exists in the instance table of the IBinder service instance library. If it exists, it means that there is a target IBinder service instance corresponding to the target instance name, where the instance table is used to record the instance names of the existing IBinder service instances.
[0065] S204. If it exists, the target second process extracts the target IBinder service instance from the IBinder service instance library through the second type of SDK.
[0066] S205. If not, after the target second process creates an instance of the target IBinder service through the second type of SDK, it stores the target IBinder service instance in the IBinder service instance library with the target instance name as the identifier.
[0067] S206. The target second process sends the target IBinder service instance to the first process through the second type of SDK.
[0068] S207. After receiving the target IBinder service instance, the first type of SDK determines whether it is the first time to receive the target IBinder service instance.
[0069] S208. If so, the first type of SDK calls the onServiceConnected method to callback the target IBinder service instance to the first process.
[0070] S209. After receiving the target IBinder service instance through onServiceConnected, the first process performs cross-process communication with the target second process based on calling the preset AIDL interface.
[0071] In this embodiment, the AIDL (Android Interface Definition Language) interface is a unique interface definition language in Android development, which is mainly used to implement inter-process communication.
[0072] It can be seen from the above technical solutions that a cross-process communication method provided by an embodiment of the present application realizes cross-process communication between different processes in the Android system, binds the processes but does not synchronize the priorities, thereby realizing priority decoupling and achieving performance optimization.
[0073] Furthermore, both the first application and the second application only need to integrate the SDK. The first application integrates the first type of SDK and encapsulates the target bindService used to replace the native bindService without any code changes, with low integration cost, no impact on the original interface function, and low modification risk. In addition, this method does not involve special system permission configuration, can be integrated and used by third-party applications, does not change the system mechanism, and uses the system's native mechanism to implement, without affecting the Android CTS compatibility test.
[0074] In summary, based on the AIDL interface definition completed by the first process and the second process, this solution realizes communication decoupling by quickly integrating the SDK with minimal modification to the existing code and without changing the existing AIDL interface logic, making both communication parties unaware of the optimization of the connection process. Based on the ContentProvider mechanism, it replaces the AMS to transfer the IBinder instance of the bound process to achieve cross-process communication. At the same time, using the dynamic binding technology, the application is unaware of integrating this solution, which is compatible with the original AIDL communication interface and avoids updating the priority of the service process after establishing the binding relationship.
[0075] It should be noted that Figure 2 This is only the specific implementation process of a cross-process communication method provided by the embodiments of the present application. The present application can also be implemented through other various optional specific implementation processes. For example: this solution uses the Android native ContentProvider mechanism to obtain the IBinder instance of the second process to achieve cross-process communication and the function of pulling up the remote process. In other optional embodiments, other low-coupling communication mechanisms can also be used to replace the ContentProvider mechanism, such as a communication framework based on Socket communication to achieve cross-process communication, and the broadcast mechanism to achieve the function of pulling up the remote process, etc.
[0076] Figure 3 It is a signal interaction schematic diagram of the cross-process communication method provided by the embodiments of the present application. As Figure 3 shown, in order to overcome the priority binding caused by the AMS module, this solution uses the Android native ContentProvider decoupling communication mechanism to remove the AMS intermediary role. The ContentPrpovider mechanism can pull up the remote process according to the url address and can transmit the IBinder instance data through its interface capabilities to achieve pulling up the server process (i.e., the second process) and transmitting the IBinder instance of the server.
[0077] Furthermore, through the encapsulation of the SDK, reasonable parameter design and the encapsulation of the calling logic are configured, enabling the host module to be integrated without changing the original interface logic, thus achieving the purpose of solving problems. Specifically, the component identification rule of ContentProvider is defined as: ${packagename}.service.publisher, and the service class name design rule is preset as ${packagename} / .${servicename}. In these two rules, packagename can be dynamically obtained during the compilation process after integrating the SDK, and servicename is passed in by the client when calling bindService. The client needs to know the servicename of the other end when calling the server capabilities, which is known information on the client side.
[0078] Based on this, seamless integration on the server side (without caring about the specific attributes registered by ContentProvider) can be achieved. It can be automatically generated during server-side compilation. The client can use its own existing information to dynamically find the ContentProvider instance of the server for communication and interaction. Otherwise, each client needs to communicate with the server offline in advance to obtain its instance identifier and then implement it separately in the code. When encapsulating, the server-side information can be completely ignored. Therefore, relatively efficient integration can be achieved without changing the AIDL interfaces defined and implemented by both parties, which is suitable for system optimization scenarios in the later stage of the project.
[0079] Based on the above mechanism, the first type of SDK, namely ClientSDK, is configured in the application program on the client side (Client), and the second type of SDK, namely SMServerSDK, is configured in the second application program on the server side (Server).
[0080] Among them, the functions implemented by SMServerSDK include:
[0081] (1) Automatically register and create a content provider component ContentProvider in the current process. During the compilation phase, the PackageName integrated on the server side will be automatically obtained, and a unique identifier for the ContentProvider registered in each process will be automatically generated, eliminating the need for the server process to manually write the code logic for creating ContentProvider and configure the Manifest file.
[0082] (2) According to the "package name + service name" transmitted from the Client side, automatically search the internal Service instance library. Automatically create the existing Service instance IBinder in the server process and cache it, facilitating subsequent calls by other Client processes and providing quick access.
[0083] The functions implemented by the ClientSDK include:
[0084] (1) Encapsulate the target bindService interface to replace the native Android bindService. The interface parameter is ComponentName (ComponentName includes PackageName and ServiceName), which is exactly the same as the native interface. This solution is implemented to replace the bindService under the original Binder mechanism. To enable seamless switching during the integration of the client module, the client only needs to change the original call to the system's bindService to call the bindService interface in the ClientSDK. The parameters and behaviors are exactly the same for the client process, aiming to achieve efficient integration and compatibility with the original code.
[0085] (2) Implement the monitoring of the server process status, and synchronize in real time when the server process restarts, etc., to maintain compatibility with the native logic.
[0086] Such as Figure 3 shown, the signal interaction of cross-process communication includes:
[0087] (1) The client process calls the bindService interface in the ClientSDK (replacing the bindService interface method in the original Binder mechanism) to request service binding.
[0088] (2) Based on the ContentProvider mechanism, if the server process does not exist, the server process will be launched. After the process exists, the client will call the implemented interface call() of the ContentProvider, which is encapsulated and implemented in the SMServerSDK.
[0089] (3) The implementation of call() in the SMServerSDK creates a service instance according to the incoming package name + service name. If there is no corresponding service instance in the cache, a service instance will be created; otherwise, there is no need to create one.
[0090] (4) If a new service instance is created, cache the service instance object so that other clients can directly obtain it from the cache when making subsequent calls. Return the service instance object to the client through the result of the call() function.
[0091] (5) After the client SDK obtains the IBinder service instance, if it obtains this instance for the first time, it will, according to the native Binder mechanism, call back to the application host through onServiceConnected.
[0092] (5) After the application host obtains the service IBinder instance through onServiceConnected, it can reuse the code logic after the native Binder mechanism and call the AIDL interface to communicate with the server process. It should be noted that Figure 3 interface1 and interface2 in it are only for illustration.
[0093] As can be seen from the above technical solutions, the cross-process communication provided by the embodiments of the present application can achieve:
[0094] 1. Use the Binder mechanism for communication between Android system processes. After binding, it does not affect the process priority, realizes decoupling, and achieves the goal of performance optimization
[0095] 2. Without changing the original interface design, both the Client side and the Server side only need to configure and integrate the SDK package. The Client side changes the original bindService interface to the bindService interface in ClientSDK, and the Server side integrates the SDK, without any code changes.
[0096] 3. It does not involve special system permission configuration and can be integrated and used by third-party applications.
[0097] 4. It does not change the system mechanism, uses the system's native mechanism to implement, and does not affect the Android CTS compatibility test.
[0098] The embodiments of the present application also provide an electronic device. Refer to Figure 4 As shown, it shows a schematic structural diagram of an electronic device suitable for implementing the electronic device in the embodiments of the present application. The electronic device in the embodiments of the present application may include, but is not limited to, fixed terminals such as mobile phones, laptop computers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), desktop computers, and the like. Figure 4 The electronic device shown is only an example and should not bring any limitations to the functions and usage scope of the embodiments of the present application.
[0099] As Figure 4 shown, the electronic device may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 402 or the program loaded from the storage device 408 into the random access memory (RAM) 403. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 403. The processing device 401, the ROM 402, and the RAM 403 are connected to each other through a bus 404. The input / output (I / O) interface 405 is also connected to the bus 404.
[0100] Typically, the following devices can be connected to the I / O interface 405: input devices 406 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 407 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 408 including, for example, a memory card, a hard disk, etc.; and a communication device 409. The communication device 409 can allow the electronic device to communicate with other devices wirelessly or wiredly to exchange data. Although Figure 4 an electronic device with various devices is shown, it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices can be implemented or had.
[0101] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions run on an electronic device, the electronic device is enabled to implement any one of the cross-process communication methods provided by the embodiments of the present application.
[0102] An embodiment of the present application also provides a computer-readable storage medium. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can be enabled to implement any one of the cross-process communication methods provided by the embodiments of the present application. Wherein, the cross-process communication method is applied to a cross-process communication system. The cross-process communication system includes a first process running a first application program and at least one second process running a second application program. The first application program integrates a first type of SDK, and the second application program integrates a second type of SDK.
[0103] In this embodiment, the cross-process communication method includes:
[0104] The first process invokes a target service binding interface through the first type of SDK to send a service invocation request. The target service binding interface is pre-encapsulated in the first type of SDK, and the interface parameters are the same as those of the native service binding interface of the Android system. The interface parameters include at least one set of package name and service name. The service invocation request includes a target package name and a target service name;
[0105] The target second process receives the service invocation request through the second type of SDK, obtains a target IBinder service instance based on the target package name and the target service name, and sends the target IBinder service instance to the first process;
[0106] The first process receives the target IBinder service instance through the first type of SDK and establishes communication with the target second process based on the target IBinder service instance.
[0107] In a possible implementation, obtaining a target IBinder service instance based on the target package name and the target service name includes:
[0108] The target second process splices the target package name and the target service name according to a preset instance design rule through the second type of SDK to generate a target instance name;
[0109] The target second process checks whether there is an IBinder service instance with the target instance name in the IBinder service instance library through the second type of SDK; if so, obtains the target IBinder service instance from the IBinder service instance library, and the instance name of the target IBinder service instance is the target instance name; if not, creates the target IBinder service instance.
[0110] In a possible implementation, after creating the target IBinder service instance, the cross-process communication method further includes:
[0111] The target second process caches the target IBinder service instance to the IBinder service instance library through the second type of SDK.
[0112] In a possible implementation, the communication system further includes a proxy module configured in the Android system. After the first process sends a service call request by calling a target service binding interface through the first type of SDK, the cross-process communication method further includes:
[0113] The proxy module determines whether the target second process is in a running state based on the target package name; if not, starts the target second process.
[0114] In a possible implementation, the cross-process communication method further includes:
[0115] Each second process creates a content provider component through the second type of SDK, obtains the package name of the second process, and generates and registers a component identifier of the content provider component based on the package name of the second process;
[0116] The proxy module determines whether the target second process is in a running state based on the target package name, including: the proxy module generates a target component identifier based on the target package name, and after determining that the second process that registers the target component identifier is the target second process, determines whether the target second process is in a running state.
[0117] In a possible implementation, the first process sends a service call request by calling a target service binding interface through the first type of SDK, including:
[0118] The first process sends the service call request to the second process by invoking the content provider component interface function of the second process, and the content provider component interface function is pre-encapsulated in the second type of SDK.
[0119] The target second process receives the service call request through the second type of SDK, including:
[0120] The target second process invokes the content provider component interface function through the second type of SDK to receive the service call request.
[0121] In addition, it should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationships between the modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines.
[0122] Through the description of the above embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general hardware, and of course, it can also be implemented by means of dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. Generally, functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures used to implement the same function can also be various, such as analog circuits, digital circuits or dedicated circuits. However, for this application, in more cases, software program implementation is a better implementation method. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk or optical disc of a computer, and includes several instructions to enable a computer device (which can be a personal computer, training device, or network device, etc.) to execute the methods described in various embodiments of this application.
[0123] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product.
[0124] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are wholly or partially generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or a data center that includes one or more integrated available media. The available medium may be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)).
Claims
1. A cross-process communication method, characterized in that: Applied to a cross-process communication system, the cross-process communication system includes a first process running a first application and at least one second process running a second application, the first application integrates a first type of SDK, the second application integrates a second type of SDK, and the cross-process communication method includes: The first process calls the target service binding interface through the first type SDK to send a service call request, the target service binding interface is pre-encapsulated in the first type SDK, and the interface parameters are the same as the interface parameters of the native service binding interface of the Android system, the interface parameters include at least one set of package name and service name, and the service call request includes the target package name and the target service name; The target second process receives the service call request through the second type SDK, obtains a target IBinder service instance based on the target package name and the target service name, and sends the target IBinder service instance to the first process; The first process receives the target IBinder service instance through the first type SDK, and establishes communication with the target second process based on the target IBinder service instance.
2. The inter-process communication method according to claim 1, characterized in that: The acquiring the target IBinder service instance based on the target package name and the target service name includes: The target second process generates a target instance name by concatenating the target package name and the target service name according to a preset instance design rule through the second type SDK; The target second process searches the IBinder service instance library through the second type SDK to see whether there is an IBinder service instance with the target instance name as the instance name; if so, obtains the target IBinder service instance from the IBinder service instance library, and the instance name of the target IBinder service instance is the target instance name; if not, creates the target IBinder service instance.
3. The inter-process communication method according to claim 2, characterized in that: After creating the target IBinder service instance, the cross-process communication method further includes: The target second process caches the target IBinder service instance to the IBinder service instance library through the second type SDK.
4. The inter-process communication method according to claim 1, characterized in that: The cross-process communication system further includes a proxy module configured in the Android system. After the first process calls the target service binding interface through the first type SDK to send a service call request, the cross-process communication method further includes: The proxy module determines whether the target second process is in a running state based on the target package name; if not, the target second process is started.
5. The inter-process communication method according to claim 4, characterized in that: The cross-process communication method also includes: Each of the second processes creates a content provider component through the second type SDK, obtains a package name of the second process, and generates and registers a component identifier of the content provider component based on the package name of the second process; The proxy module determines whether the target second process is in a running state based on the target package name, including: The proxy module generates a target component identifier based on the target package name, determines whether the target second process is in a running state after determining that the second process that registers the target component identifier is the target second process.
6. The inter-process communication method according to claim 1, characterized in that: The first process calls the target service binding interface through the first type SDK to send a service call request, including: The first process sends the service call request to the second process by calling the content provider component interface function of the second process, and the content provider component interface function is pre-encapsulated in the second type SDK; The target second process receives the service call request through the second type SDK, including: The target second process receives the service call request by calling the content provider component interface function through the second type SDK.
7. An inter-process communication system, characterized in that: The cross-process communication system includes a first process running a first application and at least one second process running a second application, the first application integrating a first type of SDK, and the second application integrating a second type of SDK: The first process is used to: call the target service binding interface through the first type SDK to send a service call request, receive a target IBinder service instance, and establish communication with the target second process based on the target IBinder service instance; The target service binding interface is pre-packaged in the first type SDK, and the interface parameters are the same as those of the native service binding interface of the Android system, the interface parameters include at least one set of package name and service name, and the service call request includes the target package name and the target service name; The target second process is used to: receive the service call request through the second type SDK, obtain the target IBinder service instance based on the target package name and the target service name, and send the target IBinder service instance to the first process.
8. A computer program product, characterized in that It comprises computer-readable instructions, and when the computer-readable instructions are executed on an electronic device, the electronic device implements the cross-process communication method as claimed in any one of claims 1 to 6.
9. An electronic device, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the electronic device can implement the cross-process communication method as described in any one of claims 1 to 6.
10. A computer storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by an electronic device, the electronic device can implement the cross-process communication method as described in any one of claims 1 to 6.