Service calling method and device, electronic equipment and storage medium
Through a unified service call method, the problem of different call methods under different service call needs is solved, and the consistency between cross-device, cross-process and same-process calls is achieved, reducing the learning cost and use complexity of APP developers.
Patent Information
- Application Number
- CN202311011449.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-08-11
- Publication Date
- 2025-02-18
AI Technical Summary
In the prior art, there are differences in the calling methods corresponding to various service calling needs, which leads to the need for application APP developers to frequently switch different calling methods, which is inconvenient to use and high learning costs.
Provides a service calling method, which generates a call request based on the service name and target interface by obtaining the proxy object and input parameters of the service to be called, and processes the input parameters by calling the service to be called. This method unifies cross-device, cross-process and co-process calls, providing a common service calling interface.
It realizes consistency between cross-device, cross-process and same-process calls, making it more convenient for APP developers to use, reduce learning costs, and blocks differences in the underlying cross-end link types.
Smart Images
Figure CN119473440A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the technical field of service invocation, and relate to but are not limited to a service invocation method and device, an electronic device, and a storage medium. Background Art
[0002] With the advent of the era of interconnectedness, more and more smart terminal devices are connected. Smart terminal devices need to frequently switch between cross-device calls, cross-process calls on the device, and same-process calls on the device. Currently commonly used distributed capability calling solutions include calls based on Hypertext Transfer Protocol (HTTP), calls based on sockets, calls based on Google Remote Procedure Call (GRPC), etc. Currently commonly used local service calling solutions include calling methods based on interface definition languages, etc.
[0003] There is a problem with the above solutions, that is, there are differences in the calling methods corresponding to various calling requirements. Different calling methods need to be switched to meet different calling requirements. It is very inconvenient for application APP developers to use and the learning cost is very high. Summary of the invention
[0004] In view of this, the service calling method and device, electronic device, and storage medium provided in the embodiments of the present application provide a service calling method that can be used across devices, across processes of the device, and within the same process of the device. It is very convenient for APP developers to use and has a low learning cost.
[0005] In a first aspect, a service calling method provided in an embodiment of the present application is applied to a first electronic device, including:
[0006] Acquire a proxy object of a service to be called and input parameters corresponding to the service to be called, wherein the proxy object is generated according to an interface definition code file of the service to be called stored in the first electronic device;
[0007] Generate a call request according to the service name of the service to be called, the input parameters and the target interface corresponding to the proxy object, wherein the target interface is defined by the interface definition code file;
[0008] The service to be called is called according to the calling request to process the input parameters.
[0009] In a second aspect, a service invocation device provided in an embodiment of the present application is applied to a first electronic device, including:
[0010] An object parameter acquisition module, used to acquire a proxy object of a service to be called and input parameters corresponding to the service to be called, wherein the proxy object is generated according to an interface definition code file of the service to be called stored in the first electronic device;
[0011] A call request acquisition module, used to generate a call request according to the service name of the service to be called, the input parameters and the target interface corresponding to the proxy object, wherein the target interface is defined by the interface definition code file;
[0012] The calling service processing module is used to call the to-be-called service according to the calling request and process the input parameters.
[0013] In a third aspect, an electronic device provided in an embodiment of the present application includes a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the steps of the service calling method provided in the first aspect of the embodiment of the present application are implemented.
[0014] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the service calling method provided in the first aspect of the embodiment of the present application are implemented.
[0015] The service calling method, device, electronic device and computer-readable storage medium provided in the embodiments of the present application provide a service calling method that can be used for cross-device calling, cross-process calling of the device and same-process calling of the device. It is very convenient for APP developers to use and has a low learning cost, thereby solving the technical problems raised in the background technology. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The drawings herein are incorporated into the specification and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and are used together with the specification to illustrate the technical solution of the present application.
[0017] Figure 1 A schematic diagram of an implementation flow of a service calling method provided in an embodiment of the present application;
[0018] Figure 2 A schematic diagram of a method for obtaining a service object provided in an embodiment of the present application;
[0019] Figure 3 A flowchart of another service calling method provided in an embodiment of the present application;
[0020] Figure 4 A schematic diagram of the structure of a preset interface definition language provided in an embodiment of the present application;
[0021] Figure 5 A schematic diagram of a development process of an interface definition code file provided in an embodiment of the present application;
[0022] Figure 6 The overall process of a calling system and a calling method provided in an embodiment of the present application;
[0023] Figure 7 A schematic diagram of the structure of a service calling device provided in an embodiment of the present application;
[0024] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0025] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the specific technical solution of the present application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application, but are not used to limit the scope of the present application.
[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.
[0027] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0028] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are used to distinguish similar or different objects, and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.
[0029] With the advent of the era of interconnectedness, more and more smart terminal devices are connected. Smart terminal devices need to frequently switch between cross-device calls, cross-process calls on the device, and same-process calls on the device. Currently commonly used distributed capability calling solutions include calls based on Hypertext Transfer Protocol (HTTP), calls based on sockets, calls based on Google Remote Procedure Call (GRPC), etc. Currently commonly used local service calling solutions include calling methods based on interface definition languages, etc.
[0030] There is a problem with the above solutions, that is, there are differences in the calling methods corresponding to various calling requirements. Different calling methods need to be switched to meet different calling requirements. It is very inconvenient for application APP developers to use and the learning cost is very high.
[0031] In view of this, an embodiment of the present application provides a service calling method, which obtains a proxy object of the service to be called and the input parameters corresponding to the service to be called; generates a calling request according to the service name of the service to be called, the input parameters and the target interface corresponding to the proxy object; and calls the service to be called according to the calling request to process the input parameters. A service calling method is provided that can be used across devices, across processes of the device, and within the same process of the device. It is very convenient for APP developers to use and has a low learning cost.
[0032] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.
[0033] Figure 1 The present invention provides a flow chart of a service calling method according to an embodiment of the present invention. The service calling method can be applied to electronic devices, which can be various types of devices with information processing capabilities during implementation. For example, the electronic device can include a personal computer, a laptop computer, a PDA or a server, etc.; the electronic device can also be a mobile terminal, for example, a mobile phone, a car computer, a tablet computer or a projector, etc. Figure 1 As shown, the method may include the following steps 101 to 103:
[0034] Step 101: Acquire a proxy object of a service to be called and input parameters corresponding to the service to be called, wherein the proxy object is generated according to an interface definition code file of the service to be called stored in the first electronic device.
[0035] It should be noted that when calling a service, it is necessary to obtain the proxy object of the service to be called and the input parameters corresponding to the service to be called. The proxy object can be used to obtain the interface corresponding to the service to be called, and the input parameters can be the input parameters corresponding to the service to be called. Among them, the proxy object is generated according to the interface definition code file of the service to be called stored in the first electronic device, and the interface definition code file is a file indicating information such as the interface corresponding to the service to be called.
[0036] Among them, there are many methods for obtaining the proxy object of the service to be called and the input parameters corresponding to the service to be called, for example, it can be to receive the generated proxy object and input parameters, or it can be to actively generate the proxy object and input parameters by oneself. The embodiment of the present application does not limit the method for obtaining the proxy object of the service to be called and the input parameters corresponding to the service to be called.
[0037] Step 102: Generate a call request according to the service name of the service to be called, the input parameters, and the target interface corresponding to the proxy object, where the target interface is defined by the interface definition code file.
[0038] It should be noted that after obtaining the proxy object, a call request can be generated according to the target interface corresponding to the proxy object, the service name of the service to be called, and the input parameters. There are many methods for generating a call request, such as information encoding, information encapsulation, etc. The embodiment of the present application does not limit the method for generating a call request according to the service name of the service to be called, the input parameters, and the target interface corresponding to the proxy object.
[0039] Step 103: Call the service to be called according to the call request to process the input parameters.
[0040] It should be noted that after the call request is generated, the service to be called can be called according to the call request to process the input parameters. There are many ways to process, for example, the call request can be sent to the service provider for processing, or it can be called locally according to the call request. The embodiment of the present application does not limit the way to process the input parameters by calling the service to be called according to the call request.
[0041] The service calling method provided in the embodiment of the present application unifies the methods of cross-end service calling and local service calling. The deployment location of the service is transparent to the developer, which is very convenient for APP developers to use and has a low learning cost.
[0042] In some embodiments, the proxy object of the service to be called is obtained according to the service name of the called service.
[0043] Figure 2 This is a flowchart of a method for obtaining a service object according to an embodiment of the present application. Figure 2 As shown, obtaining the proxy object of the service to be called in step 101 may include:
[0044] Step 1011: Obtain the service name of the service to be called.
[0045] It should be noted that the method for obtaining the service name of the service to be called may be user input or other device transmission methods, and the embodiment of the present application does not limit the method for obtaining the service name of the service to be called.
[0046] Exemplarily, the service caller APP can obtain the proxy object from the local module, and the parameters carried include the service name it expects to call, that is, the service name is obtained.
[0047] Step 1012: Determine a target location corresponding to the service name to be called, where the target location indicates an electronic device that provides the service to be called.
[0048] It should be noted that after determining the service name of the service to be called, the electronic device providing the service to be called can be determined according to the service name of the service to be called, that is, its corresponding target location can be determined. There are many ways to determine the target location, for example, it can be determined according to the correspondence between the preset service name and the location information, or according to the received location information. The embodiment of the present application does not limit the method for determining the target location corresponding to the service name to be called.
[0049] Furthermore, determining the target location corresponding to the service name to be called may include: obtaining service synchronization information, the service synchronization information including the service name of the service that can be called and the corresponding location information; determining the target location based on the service synchronization information and the service name to be called.
[0050] It should be noted that the service synchronization information is used to synchronize and share the service names of services that can be called and the corresponding location information. Electronic devices can obtain service synchronization information and determine the target location, that is, the location of the device providing the service to be called, based on the service synchronization information and the service name to be called.
[0051] Exemplarily, the local service synchronization information is queried for the corresponding service information (service location information). If the service information cannot be found, it is considered that the service does not exist, and an error code is returned to the service caller.
[0052] Step 1013: Determine the interface definition code file of the service to be called according to the target location and the service name.
[0053] It should be noted that the electronic device stores multiple interface definition code files, and after determining the target location, the interface definition code file corresponding to the service to be called can be determined according to the target location and the service name. The determination method can be based on the file name or location information. The embodiment of the present application does not limit the method of determining the interface definition code file of the service to be called according to the target location and the service name.
[0054] Step 1014: Generate the proxy object according to the interface definition code file of the service to be called.
[0055] It should be noted that after determining the interface definition code file of the service to be called, the proxy object can be generated by running the code or other methods. The embodiment of the present application does not limit the method of generating the proxy object based on the interface definition code file of the service to be called.
[0056] In some embodiments, before generating the proxy object, a target communication link with the target location may also be determined.
[0057] In an embodiment of the present application, before generating the proxy object according to the interface definition code file of the service to be called, the method may further include: determining, according to the target location, a target communication link corresponding to the electronic device providing the service to be called.
[0058] Furthermore, determining the target communication link corresponding to the electronic device providing the service to be called according to the target location may include: querying, according to the target location, whether the created communication links include the communication link corresponding to the target location; in a case where the created communication links include the communication link corresponding to the target location, determining the communication link corresponding to the target location as the target communication link; in a case where the created communication links do not include the communication link corresponding to the target location, establishing the target communication link according to the target location.
[0059] It should be noted that if the corresponding service information is found, the communication channel can be requested through the service location information. That is, the existing channel list is queried. If there is an available channel, the channel ID is directly returned. If there is no available channel, a new channel is triggered. There are many types of underlying cross-end channels, such as HTTP, Socket, etc.
[0060] It can be understood that the method shields the differences in the underlying cross-end link types and can support communication between different devices\systems by switching the link types.
[0061] In some embodiments, after the target communication link is acquired, the service to be called may be called according to the target communication link.
[0062] In an embodiment of the present application, calling the service to be called according to the call request to process the input parameters may include: sending the call request to the electronic device providing the service to be called through the target communication link, so that the input parameters are processed by the electronic device providing the service to be called.
[0063] It can be understood that the above method can be used to call the service to be called to process the input parameters.
[0064] In some embodiments, before obtaining the proxy object and the input parameters, the interface definition code file may be obtained first.
[0065] Figure 3 A flow chart of another service calling method provided in an embodiment of the present application, such as Figure 3 As shown, before obtaining the proxy object of the service to be called and the input parameters corresponding to the service to be called in step 101, the method may further include:
[0066] Step 201: Obtain the initial interface definition file of the service to be called.
[0067] It should be noted that the method for obtaining the initial file of the interface definition of the service to be called can be active acquisition or passive acquisition, and the embodiment of the present application does not limit the method for obtaining the initial file of the interface definition of the service to be called.
[0068] Step 202: compile the interface definition initial file of the service to be called through a preset plug-in to obtain the interface definition code file of the service to be called.
[0069] It should be noted that the electronic device may be pre-installed with a plug-in for compiling the initial interface definition file to obtain the interface definition code file of the service to be called. For different platforms or programming languages, the plug-in may be different, that is, different versions of the plug-in.
[0070] Furthermore, the interface definition initial file is generated according to a preset interface definition language, and the preset interface definition language includes first definition information and second definition information, the first definition information is used to indicate the supported data type, and the second definition information is used to indicate the data length corresponding to the supported data type.
[0071] It should be noted that IDL (Interface Define Language) is the interface definition language. AIDL is the interface definition language of Android. The following is an example of an Android service interface definition:
[0072] / / IBookService.idl
[0073] package com.oplus.service.book;
[0074] def interface IBookService{
[0075] int subscribe(string bookName,IBookNotify callback);
[0076] }
[0077] / / IBookNotify.idl
[0078] package com.oplus.service.book;
[0079] def interface IBookNotify{
[0080] void notify(string bookName,int32 status);
[0081] }
[0082] Figure 4 A schematic diagram of the structure of a preset interface definition language provided in an embodiment of the present application. Figure 4 As shown, the data types supported by the interface definition language provided by the present application include 64-bit floating point double, 32-bit floating point float, 32-bit signed integer int32, 64-bit signed integer int64, 32-bit unsigned integer uint32, 64-bit unsigned integer uint64, always 4 bytes fixed32, always 8 bytes fixed64, always 4 bytes sfixed32, always 8 bytes sfixed64, Boolean type bool, a string must be a text string encoded in UTF-8 or 7-bit ASCII and may contain byte data bytes in any order. Among them, the read and write types include 64 fixed length (I64), 32 fixed length (I32), variable integer (VARINT), and variable (LEN). There are certain differences between the interface definition language provided in the embodiment of the present application and AIDL. The reason is that AIDL does not support cross-device, so it does not need to consider issues such as byte order and CPU architecture differences. The solution provided in the embodiment of the present application needs to support cross-device, so the data types supported in the IDL of this solution need to clearly identify the length of the data. In addition, based on the consideration of encoding and decoding efficiency and cross-device considerations, this solution adopts the encoding and decoding method of Proto Buffer, a data serialization protocol provided by Google. Figure 4 The encoding methods of various basic data types are also described in.
[0083] Figure 5 A schematic diagram of the development process of an interface definition code file provided in an embodiment of the present application. Figure 4As shown, when both the service provider APP and the service call APP are in the Android system, the development environment is Android Studio, which is the official Android application development integrated development environment (IDE) based on IntelliJ IDEA. Developers are divided into two roles: developers of the service provider APP and developers of the service call APP. The development process is as follows:
[0084] Developers of service-providing APPs: 1.1) The developer writes the xxx.idl file, where xxx is the name of the service interface that the APP wants to provide to the outside world. The xxx.idl file is the initial file for defining the interface. 1.2) This solution provides an idl code automatic generation plug-in, which can be integrated into the android studio tool. The developer calls the plug-in. 1.3) The plug-in automatically obtains the idl file in the project directory, parses the file, and generates the corresponding java code file. On the service provider side, stub code is generated. 1.4) The developer implements the interface in the stub through coding.
[0085] Developers of service-calling APP: 2.1) The developer obtains the xxx.idl file. If the service caller wants to call the service, it must first obtain the corresponding xxx.idl file. The way to obtain it is not limited, and it may even be that the developer rewrites an identical one. 2.2) Similarly, the developer calls the plug-in. 2.3) The plug-in automatically obtains the idl file in the project directory, parses the file, and generates the corresponding java code file. On the service caller side, proxy code is generated. 2.4) The developer codes, obtains the proxy object, and calls the method defined in the xxx interface through the proxy object.
[0086] In the above example solution, the core of the development process is the automatic generation of code. Developers only need to define interfaces and plug-ins based on IDL to automatically generate the corresponding code framework. This is completely consistent with the AIDL style, which greatly reduces the learning cost of Android APP developers.
[0087] In some embodiments, the electronic device providing the service to be called is the first electronic device or the second electronic device, wherein, when the electronic device providing the service to be called is the second electronic device, the target interface is defined by the interface definition code file stored in the second electronic device.
[0088] It should be noted that, when the electronic device providing the service to be called is another electronic device, namely, a second electronic device, the target interface is defined by the second electronic device according to the interface definition code file.
[0089] In some embodiments, the electronic device providing the service to be called is the second electronic device, and the interface definition code file is obtained by the second electronic device compiling the interface definition initial file corresponding to the service to be called through a preset plug-in.
[0090] It should be noted that, when the electronic device providing the service to be called is another electronic device, namely, a second electronic device, the second electronic device is defined according to an interface definition code file stored in the second electronic device.
[0091] In some embodiments, the above service calling solution also supports local calling, that is, the service caller APP and the service provider APP are deployed on the same device.
[0092] In an embodiment of the present application, the electronic device that provides the service to be called is the first electronic device, and the process that calls the service to be called is different from the process of the service to be called, and the target communication link is an Android native channel.
[0093] It should be noted that if the device is cross-process on the Android system, the underlying channel will automatically switch to the Android native channel - Binder to improve the calling performance.
[0094] In an embodiment of the present application, the electronic device providing the service to be called is the first electronic device, and the process of calling the service to be called is the same as the process of the service to be called, and the proxy object is a local interface function of the first electronic device.
[0095] It should be noted that if the device is in the same process, the proxy object obtained actually points to the local stub object. In this way, the service call is converted into a local interface function call, which can greatly improve the call performance.
[0096] It is understandable that the present application optimizes the performance of services / input and output calls within the device through the above method.
[0097] In some embodiments, the electronic device providing the service to be called is the second electronic device, and the service synchronization information may be synchronized to the first electronic device after the second electronic device registers the service provided by itself to the service synchronization information.
[0098] It should be noted that an electronic device can register the services it provides to service synchronization information, and through synchronous sharing between service synchronization information, it can be called by other electronic devices.
[0099] The following describes an exemplary application of the embodiments of the present application in a practical application scenario.
[0100] Figure 6 The overall process of a calling system and a calling method provided in the embodiment of the present application is as follows. Figure 6 As shown, the calling system includes: Proxy - proxy code automatically generated by the plug-in during the development process; Stub - stub code automatically generated by the plug-in during the development process; Service synchronization - a service synchronization module will be deployed on each device, and the service provider will register the service information provided by itself to the module, and the module will automatically synchronize the service information between various devices. The caller can obtain service information from the module through the service name; Session management - the core processing logic of this solution, mainly responsible for the management of calling sessions. At the same time, the module also integrates the encoding and decoding functions; Channel management - provides unified channel content to the upper layer, and unifies all links to the lower layer. That is, manages the creation and deletion of the underlying communication links, which is used to shield the differences between the lower layer links from the upper layer.
[0101] The calling method includes the following steps 301 to 307:
[0102] Step 301, the service provider APP adds a service to the service synchronization module, carrying the service name and service information. The service information mainly includes the location information of the service, such as device ID, APP package name, process ID and other information.
[0103] Step 302: The service synchronization modules of each device automatically synchronize service information with each other. The synchronization process may be based on a common synchronization mechanism such as a distributed database.
[0104] Step 303: The service provider APP initializes the stub and registers the corresponding interface to the local session management module, waiting for the caller's call request.
[0105] Step 304: The service caller APP obtains a proxy object from the local session management module, and the parameters carried include the name of the service it expects to call.
[0106] Step 305: The session manager queries the local service synchronization module for the corresponding service information (service location information) through the service name. If the service information cannot be found, it is considered that the service does not exist and an error code is returned to the service caller.
[0107] Step 306: If the corresponding service information is found, the session management requests a channel from the channel management module through the service location information.
[0108] Step 307: The channel management queries the existing channel list. If there is an available channel, the channel ID is directly returned. If there is no available channel, a new channel is triggered. There are many types of underlying cross-end channels, such as HTTP, Socket, etc.
[0109] After the above process, the session management module will generate a proxy object and return it to the service caller APP. The caller can then use the proxy object to call the service interface.
[0110] Step 401: The caller calls the service interface through the proxy object, that is, passes a parameter list to the service interface. After receiving the parameter list, the session management performs encoding.
[0111] Step 402: The session management module first encodes the input parameters, and then passes the encoded data to the channel management.
[0112] Step 403: The channel management module encapsulates the call request message, and the message header includes the called service name, interface name, etc. The message is sent to the channel management module at the opposite end through the corresponding underlying link.
[0113] Step 404: The channel management module at the other end first parses the message to obtain the service name and interface name in the message header, and then sends the service name, interface name, and input parameter encoding data to the local session management module.
[0114] Step 405: The local session management module finds the previously registered stub object and method based on the service name and interface name. Then the codec module decodes the input parameter to obtain the input parameter list. Finally, the method of the stub object is called and the parameters are passed in.
[0115] At this point, the call request process ends. It should be noted that the return value after the call here will be returned by the original path. The whole process is the opposite of the call request process, so I will not repeat it here.
[0116] The above embodiment provides a method for cross-end service calls on an Android device. The advantage of this method is that it provides a calling style similar to Android native AIDL, which can support calls within the same device as well as cross-device calls. The learning cost for APP developers is low and it is more convenient to use. Secondly, this method shields the differences in the underlying cross-end link types, and the deployment location of the service is transparent to the developer. The underlying channel type can be extended to any type, such as HTTP, cloud channel, Socket, Bluetooth, etc. This solution not only supports Android devices, but can also be extended to devices of other systems, such as IOS, Windows, etc. Finally, the method optimizes the performance of calls within this device and improves efficiency.
[0117] It should be understood that, although the steps in the above-mentioned flowcharts are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the above-mentioned flowcharts may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.
[0118] Based on the foregoing embodiments, the embodiments of the present application provide a service calling device, and the modules included in the device and the units included in the modules can be implemented by a processor; of course, they can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.
[0119] Figure 7 A schematic diagram of a service invocation device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, the device 500 includes an object parameter acquisition module 501, a call request acquisition module 502 and a service call processing module 503, wherein:
[0120] The object parameter acquisition module 501 is used to acquire a proxy object of a service to be called and input parameters corresponding to the service to be called, wherein the proxy object is generated according to an interface definition code file of the service to be called stored in the first electronic device;
[0121] The call request acquisition module 502 is used to generate a call request according to the service name of the service to be called, the input parameters and the target interface corresponding to the proxy object, wherein the target interface is defined by the interface definition code file;
[0122] The service call processing module 503 is used to call the to-be-called service according to the call request and process the input parameters.
[0123] In some embodiments, the object parameter acquisition module 501 includes a service name acquisition unit, a target location determination unit, a code file determination unit and a proxy object generation unit, wherein:
[0124] A service name acquisition unit, used to acquire the service name of the service to be called;
[0125] A target location determining unit, configured to determine a target location corresponding to the name of the service to be called, wherein the target location indicates an electronic device that provides the service to be called;
[0126] A code file determining unit, used to determine the interface definition code file of the to-be-called service according to the target location and the service name;
[0127] The proxy object generation unit is used to generate the proxy object according to the interface definition code file of the service to be called.
[0128] In some embodiments, the target location determination unit is specifically used to obtain service synchronization information, where the service synchronization information includes the service name of the service that can be called and the corresponding location information; and determine the target location based on the service synchronization information and the service name to be called.
[0129] In some embodiments, the object parameter acquisition module 501 further includes: a communication link determination unit, the communication link determination unit being configured to determine, according to the target location, a target communication link corresponding to the electronic device providing the service to be called.
[0130] In some embodiments, the communication link determination unit is specifically used to: query whether the created communication links include the communication link corresponding to the target position according to the target position; in a case where the created communication links include the communication link corresponding to the target position, determine the communication link corresponding to the target position as the target communication link; in a case where the created communication links do not include the communication link corresponding to the target position, establish the target communication link according to the target position.
[0131] In some embodiments, the service call processing module 503 is specifically used to: send the call request to the electronic device providing the service to be called through the target communication link, so that the input parameters are processed by the electronic device providing the service to be called.
[0132] In some embodiments, the device also includes a code file generation module, which is used to: obtain the interface definition initial file of the service to be called; compile the interface definition initial file of the service to be called through a preset plug-in to obtain the interface definition code file of the service to be called.
[0133] In the embodiments of the present application, a service calling method that is universal for cross-device calling, cross-process calling of the device, and same-process calling of the device can be provided, which is very convenient for APP developers to use and has a low learning cost.
[0134] The description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.
[0135] It should be noted that in the embodiments of this application Figure 7 The division of modules in the service calling device shown is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processing unit, or may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of a software functional unit. It may also be implemented in the form of a combination of software and hardware.
[0136] It should be noted that in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application can be essentially or partly embodied in the form of a software product that contributes to the relevant technology. The computer software product is stored in a storage medium, including several instructions to enable an electronic device to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.
[0137] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 As shown, the electronic device 100 may include a processor 110, a memory 120, a wireless communication module 130, an audio module 140, a camera 150, a USB interface 160, a display screen 170, and the like.
[0138] The processor 110 may include one or more processing units. For example, the processor 110 is a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as one or more microprocessors (digital signal processors, DSPs), or one or more field programmable gate arrays (FPGAs). Different processing units may be independent devices or integrated into one or more processors.
[0139] The memory 120 can be used to store computer executable program codes, which include instructions. The internal memory 120 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, video data, etc.), etc. In addition, the memory 120 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device 100 by running instructions stored in the memory 120, and / or instructions stored in a memory provided in the processor.
[0140] The wireless communication module 130 can provide solutions for wireless communication including WLAN, such as Wi-Fi network, Bluetooth, NFC, IR, etc., applied to the electronic device 100. The wireless communication module 130 can be one or more devices integrating at least one communication processing module. In some embodiments of the present application, the electronic device 100 can establish a wireless communication connection with other electronic devices through the wireless communication module 130.
[0141] The electronic device 100 can implement audio functions such as music playing and recording through the audio module 140 , the speaker 140A, the receiver 140B, the microphone 140C, the headphone jack 140D, and the application processor.
[0142] The audio module 140 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 140 can also be used to encode and decode audio signals. In some embodiments, the audio module 140 can be arranged in the processor 110, or some functional modules of the audio module 140 can be arranged in the processor 110.
[0143] The camera 150 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the electronic device 100 may include 1 or N cameras 150, where N is a positive integer greater than 1.
[0144] The USB interface 160 is an interface that complies with the USB standard specification, and can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 160 can be used to connect other electronic devices. In some other embodiments, the electronic device 100 can also be connected to an external camera through the USB interface 160 to capture images.
[0145] The display screen 170 is used to display images, videos, etc. The display screen 170 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 170, where N is a positive integer greater than 1.
[0146] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.
[0147] An embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the service calling method provided in the above embodiment are implemented.
[0148] The above-mentioned computer-readable storage medium can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.
[0149] Computer-readable signal media may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.
[0150] The program code embodied on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.
[0151] Computer program code for performing the operations of the present specification may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0152] An embodiment of the present application provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the steps in the service calling method provided in the above method embodiment.
[0153] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website site, a computer, a server, or a data center to another website site, a computer, a server, or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive Solid State Disk (SSD)), etc.
[0154] It should be noted here that the description of the above storage medium, program product and device embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the storage medium, storage medium and device embodiments of this application, please refer to the description of the method embodiment of this application for understanding.
[0155] It should be understood that "one embodiment" or "an embodiment" or "some embodiments" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in one embodiment" or "in some embodiments" appearing throughout the specification may not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The above-mentioned sequence numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments. The above description of each embodiment tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. For the sake of brevity, this article will not repeat them.
[0156] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist at the same time, and object B exists alone.
[0157] It should be noted that, in this article, the terms "include", "comprises" or any other variations 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, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.
[0158] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as: multiple modules or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical, mechanical or other forms.
[0159] The modules described above as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules; they may be located in one place or distributed on multiple network units; some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.
[0160] In addition, all functional modules in the embodiments of the present application may be integrated into one processing unit, or each module may be a separate unit, or two or more modules may be integrated into one unit; the above-mentioned integrated modules may be implemented in the form of hardware or in the form of hardware plus software functional units.
[0161] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.
[0162] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling an electronic device to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.
[0163] The methods disclosed in several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.
[0164] The features disclosed in several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.
[0165] The features disclosed in several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.
[0166] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A service calling method, characterized in that: Applicable to a first electronic device, comprising: Acquire a proxy object of a service to be called and input parameters corresponding to the service to be called, wherein the proxy object is generated according to an interface definition code file of the service to be called stored in the first electronic device; Generate a call request according to the service name of the service to be called, the input parameters and the target interface corresponding to the proxy object, wherein the target interface is defined by the interface definition code file; The service to be called is called according to the calling request to process the input parameters.
2. The method according to claim 1, characterized in that The step of obtaining a proxy object for the service to be called includes: Obtain the service name of the service to be called; Determine a target location corresponding to the name of the service to be called, the target location indicating an electronic device that provides the service to be called; Determine the interface definition code file of the service to be called according to the target location and the service name; The proxy object is generated according to the interface definition code file of the service to be called.
3. The method according to claim 2, characterized in that The determining of the target location corresponding to the service name to be called includes: Acquire service synchronization information, where the service synchronization information includes the service name of the service that can be called and the corresponding location information; The target location is determined according to the service synchronization information and the name of the service to be called.
4. The method according to claim 2, characterized in that: Before generating the proxy object according to the interface definition code file of the service to be called, the method further includes: A target communication link corresponding to the electronic device providing the service to be called is determined according to the target location.
5. The method according to claim 4, characterized in that The step of determining, according to the target location, a target communication link corresponding to the electronic device providing the service to be called includes: According to the target location, query whether the created communication links include a communication link corresponding to the target location; In a case where the created communication links include a communication link corresponding to the target position, determining the communication link corresponding to the target position as the target communication link; In a case where the created communication links do not include a communication link corresponding to the target location, the target communication link is established according to the target location.
6. The method according to claim 4, characterized in that The calling the service to be called according to the calling request to process the input parameter includes: The calling request is sent to the electronic device providing the service to be called through the target communication link, so that the input parameter is processed by the electronic device providing the service to be called.
7. The method according to any one of claims 1 to 6, characterized in that Before obtaining the proxy object of the service to be called and the input parameters corresponding to the service to be called, the method further includes: Obtaining an initial file of the interface definition of the service to be called; The interface definition initial file of the service to be called is compiled by a preset plug-in to obtain the interface definition code file of the service to be called.
8. The method according to claim 7, characterized in that The interface definition initial file is generated according to a preset interface definition language, and the preset interface definition language includes first definition information and second definition information, wherein the first definition information is used to indicate the supported data type, and the second definition information is used to indicate the data length corresponding to the supported data type.
9. The method according to claim 4, characterized in that The electronic device providing the service to be called is the first electronic device or the second electronic device, wherein, when the electronic device providing the service to be called is the second electronic device, the target interface is defined by the interface definition code file stored in the second electronic device.
10. The method according to claim 9, characterized in that The electronic device providing the service to be called is the second electronic device, and the interface definition code file is obtained by the second electronic device compiling the interface definition initial file corresponding to the service to be called through a preset plug-in.
11. The method according to claim 9, characterized in that The electronic device that provides the service to be called is the first electronic device, and the process that calls the service to be called is different from the process of the service to be called, and the target communication link is an Android native channel.
12. The method according to claim 9, characterized in that The electronic device providing the service to be called is the first electronic device, and the process of calling the service to be called is the same as the process of the service to be called, and the proxy object is a local interface function of the first electronic device.
13. The method according to claim 3, characterized in that The electronic device providing the service to be called is the second electronic device, and the service synchronization information is synchronized to the first electronic device after the second electronic device registers the service provided by itself into the service synchronization information.
14. A service calling device, characterized in that: Applicable to a first electronic device, comprising: An object parameter acquisition module, used to acquire a proxy object of a service to be called and input parameters corresponding to the service to be called, wherein the proxy object is generated according to an interface definition code file of the service to be called stored in the first electronic device; A call request acquisition module, used to generate a call request according to the service name of the service to be called, the input parameters and the target interface corresponding to the proxy object, wherein the target interface is defined by the interface definition code file; The service call processing module is used to call the service to be called according to the call request and process the input parameters.
15. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps of the service calling method according to any one of claims 1 to 14 are implemented.
16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the service calling method according to any one of claims 1 to 14 are implemented.