CN112835615A

CN112835615A - Plug-in processing method and device for software development kit and electronic equipment

Info

Publication number: CN112835615A
Application number: CN202110170524.5A
Authority: CN
Inventors: 龚正
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2021-02-08
Filing date: 2021-02-08
Publication date: 2021-05-25
Anticipated expiration: 2041-02-08
Also published as: CN112835615B

Abstract

The application discloses a plug-in processing method, a calling method, a device, electronic equipment, a storage medium, a program product and terminal equipment of a plug-in software development kit, and relates to cloud computing and chips in computer technology. The specific implementation scheme is as follows: the method comprises the steps of determining an implementation class of the SDK to be processed according to a configuration file, generating an SDK plugin deployed at a cloud end according to the implementation class and the SDK to be processed, generating a static SDK according to calling information and the SDK to be processed, packaging the static SDK and a preset plugin framework, and obtaining a client assembly SDK deployed at a client end, wherein the SDK plugin and the client assembly SDK form the plugin SDK, so that the technical threshold and the research and development cost of the SDK plugin are reduced, the integration difficulty and the research and development cost of the App integrated plugin SDK are reduced, and the technical effect of improving the universality of the plugin of the SDK is realized.

Description

Plug-in processing method and device for software development kit and electronic equipment

Technical Field

The present application relates to cloud computing and chips in computer technologies, and in particular, to a plug-in processing method, a call method, an apparatus, an electronic device, a storage medium, a program product, and a terminal device for a software development kit.

Background

With the rapid Development of mobile Application technology, in order to promote products and services, Software Development Kit (SDK) is provided for developers of third parties, and the plug-in SDK can be called by Application programs (apps).

In the prior art, a plug-in method for an SDK includes: and realizing the pluging of part of functional modules in the SDK and dynamically loading.

However, the method for implementing partial function module plugins inside the SDK has high requirements on technical capabilities, and may have problems of low generality and high consumption cost.

Disclosure of Invention

The application provides a plug-in processing method, a calling device, electronic equipment, a storage medium, a program product and terminal equipment of a software development kit for improving SDK plug-in.

According to a first aspect of the present application, there is provided a plug-in processing method for a software development kit, including:

acquiring a Software Development Kit (SDK) to be processed, and acquiring a configuration file of the SDK to be processed and calling information of a calling interface externally provided by the SDK to be processed;

determining an implementation class of the SDK to be processed according to the configuration file, and generating an SDK plug-in deployed in a cloud according to the implementation class and the SDK to be processed, wherein the implementation class represents contents indicated by each calling interface in the configuration file;

generating a static SDK according to the calling information and the SDK to be processed, and packaging the static SDK and a preset plug-in framework to obtain a client side assembly SDK deployed at a client side; and the SDK plug-in and the client side assembly SDK form a plug-in SDK.

According to a second aspect of the present application, there is provided a calling method of a plug-in software development kit, including:

obtaining a call request, wherein the call request indicates to call a plugin Software Development Kit (SDK), the plugin SDK is generated based on the method of any one of claims 1-10, and the plugin SDK comprises an SDK plugin and a client assembly (SDK);

and if the SDK plug-in is determined not to be locally provided according to the calling request, running a static SDK in the client side assembly SDK.

According to a third aspect of the present application, there is provided a plug-in processing apparatus of a software development kit, comprising:

the system comprises a first acquisition unit, a second acquisition unit and a third acquisition unit, wherein the first acquisition unit is used for acquiring a Software Development Kit (SDK) to be processed and acquiring a configuration file of the SDK to be processed and calling information of a calling interface externally provided by the SDK to be processed;

a determining unit, configured to determine an implementation class of the SDK to be processed according to the configuration file;

the first generating unit is used for generating an SDK plug-in deployed in a cloud according to the implementation class and the SDK to be processed, wherein the implementation class represents the content indicated by each calling interface in the implementation configuration file;

the second generation unit is used for generating a static SDK according to the calling information and the SDK to be processed;

the packaging unit is used for packaging the static SDK and a preset plug-in framework to obtain a client side assembly SDK deployed at a client side; and the SDK plug-in and the client side assembly SDK form a plug-in SDK.

According to a fourth aspect of the present application, there is provided a calling apparatus of a plug-in software development kit, including:

a second obtaining unit, configured to obtain a call request, where the call request indicates to call a plugin software development kit SDK, where the plugin SDK is generated based on the method of any one of claims 1 to 10, and includes an SDK plugin and a client assembly SDK;

and the operation unit is used for operating the static SDK in the client side assembly SDK if the fact that the SDK plug-in is not locally provided is determined according to the calling request.

According to a fifth aspect of the present application, there is provided an electronic device comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the first aspect; alternatively, the first and second electrodes may be,

to enable the at least one processor to perform the method of the second aspect.

According to a sixth aspect of the present application, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of the first aspect; alternatively, the first and second electrodes may be,

the computer instructions are for causing the computer to perform the method of the second aspect.

According to a seventh aspect of the present application, there is provided a computer program product comprising: a computer program, stored in a readable storage medium, from which at least one processor of an electronic device can read the computer program, execution of the computer program by the at least one processor causing the electronic device to perform the method of the first aspect or the second aspect.

According to an eighth aspect of the present application, there is provided a terminal device comprising the electronic device according to the fifth aspect.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present application, nor do they limit the scope of the present application. Other features of the present application will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not intended to limit the present application. Wherein:

FIG. 1 is a schematic diagram according to a first embodiment of the present application;

FIG. 2 is a schematic diagram according to a second embodiment of the present application;

FIG. 3 is a schematic illustration according to a third embodiment of the present application;

FIG. 4 is a scenario diagram of a calling method of a plug-in software development kit that may implement an embodiment of the present application;

FIG. 5 is a schematic illustration according to a fourth embodiment of the present application;

FIG. 6 is a schematic illustration according to a fifth embodiment of the present application;

FIG. 7 is a schematic illustration according to a sixth embodiment of the present application;

FIG. 8 is a schematic diagram of a plug-in SDK according to an embodiment of the present application;

fig. 9 is a block diagram of an electronic device for implementing a plug-in processing method of a software development kit or a calling method of a plug-in software development kit according to an embodiment of the present application.

Detailed Description

The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The software development kit SDK generally refers to a development tool used when application software is established for a specific software package, a software framework, a hardware platform, an operating system, and the like, and in order to facilitate the invocation of an application App, the SDK may be subjected to plug-in processing to obtain a plug-in SDK.

In the related art, two methods can be generally adopted for performing plug-in processing on the SDK.

One of the ways is: and realizing the pluging of part of functional modules in the SDK and dynamically loading.

However, when the method is used for performing plug-in processing on the SDK, relatively speaking, the internal implementation of the SDK needs to be analyzed based on functions, the development cost is relatively high, higher technical capability is required, and the universality is relatively low due to the plug-in processing aiming at part of the functional models.

The other mode is as follows: and performing plug-in processing on the whole SDK, and integrating by the App in a bridging mode.

However, the method for performing plug-in processing on the SDK is limited by an external integration mode, the App can only call the plug-in SDK by calling the bridge, and the plug-in SDK obtained by the method cannot provide other integration modes.

In order to solve at least one of the above problems, the inventors of the present application have made creative efforts to obtain the inventive concept of the present application: and generating an SDK plug-in deployed at the cloud end based on the implementation class, generating a static SDK based on the calling information, and obtaining a client end assembly SDK based on the static SDK and the plug-in framework, so that plug-in processing of the SDK is realized, wherein the plug-in SDK comprises an SDK plug-in and a client end assembly SDK.

Based on the inventive concept, the application provides a plug-in processing method of a software development kit, which is applied to cloud computing and chips in the technical field of computers to achieve the universality of SDK plug-in processing.

Fig. 1 is a schematic diagram according to a first embodiment of the present application, and as shown in fig. 1, a plug-in processing method of a software development kit according to the embodiment of the present application includes:

s101: the method comprises the steps of obtaining a Software Development Kit (SDK) to be processed, and obtaining a configuration file of the SDK to be processed and calling information of a calling interface provided by the SDK to be processed to the outside.

For example, the execution main body of this embodiment may be a plug-in processing device (hereinafter, referred to as a processing device) of a software development kit, and the processing device may be a server (may be a cloud server or a local server), or may be a terminal device, or may be a processor, or may be a chip, and the embodiment is not limited.

By way of example, a configuration file may be understood as a computer file, such as may configure parameters and initial setup information for some computer program.

That is, in the present embodiment, the configuration file may include: computer program configuration parameters of the SDK, initialization information of the SDK, information for implementing functions of the SDK, information of functions that the SDK can implement, and the like.

The calling information can be understood as information related to the calling interface when the App calls the plug-in SDK through the calling interface, for example, information how to call the plug-in SDK.

S102: and determining the implementation class of the SDK to be processed according to the configuration file, and generating the SDK plug-in deployed at the cloud end according to the implementation class and the SDK to be processed.

Wherein the implementation class represents the content indicated by each calling interface in the implementation configuration file.

By way of example, this step may be understood as: the processing device obtains all calling interfaces (interfaces) to be realized based on the configuration file, and generates a realization class corresponding to each calling Interface aiming at each calling Interface.

S103: and generating a static SDK according to the calling information and the SDK to be processed.

For example, the processing device may compile the SDK based on the call information, and so on, to obtain the static SDK.

S104: and packaging the static SDK and a preset plug-in framework to obtain a client side assembly SDK deployed at the client side.

The SDK plug-in and the client side assembly SDK form a plug-in SDK.

It should be noted that, regarding the execution sequence between S102 and S103, the present embodiment is not limited, that is, in one example, the processing device may preferentially generate the SDK plug-in; in another example, the processing device may preferentially generate the static SDK and the client assembly SDK; in yet another example, the processing device may perform generating the SDK plug-in and the static SDK concurrently.

The plug-in framework may adopt a plug-in framework in the related art, so as to implement initialization of the static SDK based on the plug-in framework, and the like.

Based on the above analysis, an embodiment of the present application provides a plug-in processing method for a software development kit, including: acquiring a Software Development Kit (SDK) to be processed, acquiring a configuration file of the SDK to be processed and call information of a call interface provided by the SDK to be processed to the outside, determining an implementation class of the SDK to be processed according to the configuration file, and generating an SDK plugin deployed at a cloud according to the implementation class and the SDK to be processed, wherein the implementation class represents contents indicated by each call interface in the implementation configuration file, generating a static SDK according to the call information and the SDK to be processed, and packaging the static SDK and a preset plugin framework to obtain a client assembly (SDK) deployed at a client, wherein the SDK plugin and the client assembly (SDK) form the plugin SDK, in the embodiment, the implementation class is determined according to the configuration file, the SDK plugin is generated according to the implementation class, the static SDK is generated based on the call information, and the client assembly (SDK) is generated according to the static SDK and the plugin framework, therefore, the plug-in SDK comprising the SDK plug-in and the client side assembly SDK is obtained, the technical threshold and the research and development cost of the plug-in SDK are reduced, the integration difficulty and the research and development cost of the App integrated plug-in SDK are reduced, and the technical effect of improving the plug-in universality of the SDK is realized.

Fig. 2 is a schematic diagram according to a second embodiment of the present application, and as shown in fig. 2, a plug-in processing method of a software development kit according to the embodiment of the present application includes:

s201: the method comprises the steps of obtaining a Software Development Kit (SDK) to be processed, and obtaining a configuration file of the SDK to be processed and calling information of a calling interface provided by the SDK to be processed to the outside.

For example, the description about S201 may refer to S101, and is not described herein again.

S202: and determining the implementation logic for implementing the content indicated by each calling interface in the configuration file according to the configuration file.

The configuration file is used for indicating various implementation classes required by the SDK to be processed, and the implementation classes represent the contents indicated by each calling interface in the configuration file.

For example, in this embodiment, since the configuration file is used to indicate the implementation classes required by the SDK to be processed, if the processing device acquires the configuration file, the implementation classes required by the SDK to be processed may be determined based on the configuration file, and the implementation classes may be understood as the contents indicated by each calling interface in the implementation configuration file, and the processing device may determine the contents indicated by each calling interface based on the configuration file.

Accordingly, if the processing device determines the content indicated by each calling interface based on the configuration file, the processing device may determine the implementation logic corresponding to the content indicated by each calling interface based on the content indicated by each calling interface.

S203: and inserting the SDK to be processed according to each implementation logic to generate the implementation classes corresponding to each implementation logic.

In this step, the processing device may perform insertion processing or the like on the SDK to be processed, thereby obtaining an implementation class corresponding to each implementation logic.

It should be noted that, in this embodiment, the processing device determines each implementation logic based on the configuration file, and performs processing such as insertion based on each implementation logic to obtain the implementation class corresponding to each implementation logic, so as to improve the accuracy and reliability of the generated implementation class.

In some embodiments, S203 may include: and aiming at the implementation logic of the content indicated by each calling interface, inserting the implementation logic of the content indicated by each calling interface into the SDK to be processed to obtain an implementation class corresponding to the implementation logic of the content indicated by each calling interface.

It should be noted that, in this embodiment, for the implementation logic of the content indicated by each invocation interface, the processing device performs insertion processing on the implementation logic of the content indicated by each invocation interface on the basis of the SDK to be processed, so as to obtain the implementation classes corresponding to each invocation interface, and can achieve the technical effect of improving the reliability and accuracy of generating the implementation classes of the SDK.

In some embodiments, on the basis of the insertion process in the above embodiments, S203 may specifically include the following steps

Step 1: determining the byte code corresponding to the implementation logic of the content indicated by each calling interface.

Illustratively, the processing device may determine, based on the implementation logic of the content indicated by any of the calling interfaces, the bytecode (e.g., a binary file containing the execution program) corresponding to the implementation logic of the content indicated by the any of the calling interfaces.

Step 2: and performing byte code instrumentation on the SDK to be processed based on the byte codes corresponding to the implementation logic of the content indicated by each calling interface, and generating an implementation class corresponding to the implementation logic of the content indicated by each calling interface.

It is worth to say that, in this embodiment, a feature that the processing device generates the corresponding implementation class based on the bytecode instrumentation technology is introduced, and the implementation class is generated based on the bytecode instrumentation technology, so that the problem of low intelligence caused by adopting a code writing mode in the related art can be avoided, automation and intelligence of insertion processing are realized, subsequent adjustment and modification are facilitated, and the technical effect of generating the implementation class is improved.

In some embodiments, step 2 may include the following sub-steps:

substep 1: and determining the inserting position of the byte code of the implementation logic of the content indicated by each calling interface in the SDK to be processed according to the configuration file.

Based on the above analysis, the configuration file is used to indicate the implementation classes required by the SDK to be processed, and the implementation classes represent the content indicated by each calling interface in the implementation configuration file, so that the processing device can determine the insertion position based on the configuration file, so as to obtain the implementation classes with higher accuracy and reliability.

Substep 2: inserting the byte codes of the implementation logic of the content indicated by each calling interface into the insertion positions of the byte codes of the implementation logic of the content indicated by each calling interface in the SDK to be processed by adopting a preset instrumentation interface, and generating the implementation classes corresponding to the implementation logic of the content indicated by each calling interface.

This step is understood to mean that the processing means may insert a bytecode based on the determined insertion position, resulting in an implementation class.

It should be noted that, in this embodiment, the processing device generates the implementation class by determining the insertion position and then performing the bytecode instrumentation processing based on the insertion position, and thus, the technical effect of improving the accuracy and reliability of the generated implementation class can be achieved.

S204: and generating the SDK plug-in deployed at the cloud end according to the implementation class and the SDK to be processed.

Wherein, the SDK to be processed includes jar packet, in some embodiments, S204 may include the following steps:

step 1: and inserting the implementation class into the jar packet to obtain a new jar packet.

Step 2: and generating the SDK plug-in according to the new jar packet and the SDK to be processed.

It should be noted that, in this embodiment, the SDK plug-in is obtained based on the implementation class and jar, so that the technical effects of reliability and integrity of the generated SDK plug-in are improved.

In some embodiments, the SDK to be processed includes a dynamic link library and a process file, the process file includes a resource file, and step 2 may include the following sub-steps:

substep 1: and packaging the new jar package and the resource file into an application package.

Substep 2: and packaging the application program package, the dynamic link library and the files except the resource files in the process files to obtain the SDK plug-in.

It should be noted that, in this embodiment, by packaging the new jar and the resource file into an application package, and generating the SDK plug-in by combining the dynamic link library and the file in the process file except the resource file on this basis, the SDK plug-in can have integrity and comprehensiveness, thereby achieving the technical effects of accuracy and reliability of the obtained plug-in SDK.

S205: and inserting calling information into a calling interface externally provided by the SDK to be processed to obtain the static SDK.

It should be noted that, in this embodiment, by inserting the call information into the call interface provided externally, the generated static SDK can have higher external call performance, and the technical effect of improving the reliability of the obtained static SDK is achieved.

In some embodiments, S205 may include the steps of:

step 1: and determining the calling logic corresponding to the calling information.

Step 2: and inserting calling logic into a calling interface externally provided by the SDK to be processed to obtain the static SDK.

It should be noted that, in this embodiment, the static SDK is obtained by determining the call logic and inserting the call logic, so that the static SDK is highly associated with the call information, thereby improving the accuracy and reliability of the static SDK.

In some embodiments, S205 may specifically include: and determining a proxy code corresponding to the calling logic, and performing byte code instrumentation on a calling interface externally provided by the SDK to be processed based on the proxy code to obtain the static SDK.

Similarly, in this embodiment, the static SDK is generated by the bytecode instrumentation technology, so that the intelligence and automation of generating the static SDK can be improved, the coding resources can be saved, and the technical effects of improving the efficiency and reliability of generating the static SDK can be achieved.

In some embodiments, a multi-dimensional calling logic may be included, for example, an eight-dimensional calling logic, that is, eight functions may be implemented by the calling interface provided outside the SDK to be processed.

Wherein, eight functions can be respectively: an SDK initialization function; classes for external static calls and their static functions; classes for external instantiation and the corresponding functions of those classes; classes that need to obtain their instances externally, functions that obtain such instances, and functions that these instances need to use; calling interface classes which need to be realized by a user and functions of transmitting the calling interfaces to other classes; enumerating classes, and functions that need to pass enumerated values; the function of external writing to the custom View (View) and View Group (View Group) in the Layout (Layout) is needed; the functions of the components registered in Manifest are required.

It should be noted that the above eight functions are only used for exemplarily illustrating the functions that the plug-in SDK may implement, and are not to be construed as limiting the functions.

The corresponding implementation of each function (i.e., invoking logic accordingly) is now exemplarily described with respect to the eight functions described above. Illustratively, the SDK initialization function is implemented as follows:

initializing a plug-in framework, calling a plug-in framework method to check whether an available SDK plug-in exists currently, if so, marking the plug-in to run as the SDK plug-in, and if not, marking the plug-in to run as the static SDK. If the SDK plug-in unit runs, calling the same method of the same implementation class name of the SDK plug-in unit through the plug-in framework, otherwise, ending the insertion calling logic, and starting to execute the static calling logic of the initialization method.

Illustratively, the implementation of classes for external static calls and their static functions is as follows:

and judging whether the operation is the SDK plug-in operation, if so, calling the same method of the same realization class name of the SDK plug-in through the plug-in framework, otherwise, finishing the insertion calling logic, and starting to execute the static calling logic of the initialization method.

Illustratively, implementation of implementation classes for external instantiation and the corresponding functionality of these implementation classes is as follows:

a base class (Object class) declared global variable (mInnerInstance) is inserted in the implementation class for holding an instance of the implementation class within the SDK plug-in. In the implementation class construction method, if the SDK plug-in runs at this time, construction methods of the same parameter type of the same implementation class name of the SDK plug-in are called through a plug-in framework, a base class is obtained, and the base class is stored in a global variable.

In some embodiments, if the SDK plug-in is running at this time, the same method of the global variable is called through the plug-in framework, and the obtained return value is returned. Otherwise, the inserting calling logic is finished and the static calling logic of the initialization method is started to execute.

In some embodiments, if the SDK plugin runs at this time, when the method for unifying the names of the same implementation class of the SDK plugin is called, the global variable of the implementation class needs to be taken out as a parameter, and an instance of the implementation class outside the SDK plugin cannot be directly used.

Illustratively, the class whose instances need to be obtained externally, the functionality to obtain such instances, and the functionality that these instances need to use are implemented as follows:

if the plug-in operation is carried out, firstly, the same method of the same implementation class name in the SDK plug-in is reflected and called, the instance of the implementation class in the SDK plug-in is obtained, at the moment, an externally defined instance of the implementation class can be instantiated, the instance obtained from the SDK plug-in is assigned to the global variable, and then the externally defined instance of the implementation class is returned.

Illustratively, the functions that require the user to implement the call interface classes and pass these call interfaces to other classes are implemented as follows:

the external App implementation calling interface can be implemented through external definition, the instance of the calling interface cannot be commonly used with the same-name calling interface definition in the SDK plug-in, and then an implementation class of the calling interface is automatically generated when the SDK plug-in is required to be inserted, and the implementation class and the external definition are implemented together.

The internal implementation class of the SDK plug-in can have a function global variable (mCallbackImpl) of a base class, and a construction method taking a parameter as the base class is provided at the same time, so that the introduced base class is assigned to the function global variable. When the callback method of the implementation class is called, the corresponding method of the global variable of the calling function is reflected, so that the callback is transmitted to the external implementation.

If the current plug-in operation is the plug-in operation, an instance of the implementation class in the SDK plug-in is created in a reflection mode and is transmitted into the external implementation class, and then the instance of the implementation class in the SDK plug-in is used for calling the method of the implementation class instance of the transfer call interface in the plug-in.

Illustratively, the enumeration class, and the function that needs to pass enumerated values, is implemented as follows:

the plug-in framework provides an enumeration value conversion method, and the enumeration value defined outside the plug-in framework can be converted into the enumeration value defined inside the plug-in framework. The enumerated value is converted into an object of the base class, and can not be assigned to an external plug-in framework.

In some embodiments, if the current plug-in operation is performed, the method calls a plug-in method internally, and when an enumeration value is used, a conversion method is called first to convert the external enumeration value into an internal enumeration value. When the reflection call needs the declaration type, the enumeration value after conversion can be directly used to obtain the definition of enumeration Class (Class), or the method for loading the realization Class in the plug-in of the plug-in framework is used to load the enumeration Class in the plug-in with the same name as the external enumeration.

Illustratively, the functionality that requires external writing to custom views and groups of views in a layout is implemented as follows:

the externally integrated view group may include: integrating and generating new object integration through the layout file.

The layout file integration may adopt a construction method in which a parameter is Context (Context) and an attribute group (AttributeSet).

The same construction method of the uniform view group in the SDK plug-in can be called through the plug-in framework by generating new object integration, after the view group in the SDK plug-in is constructed, all the child groups (Children) of the view group in the SDK plug-in are copied to the external view group, and the Parent group (Parent) of the child groups is replaced to the external view group.

When other common methods of the implementation class are called, all parameters need to be copied from the outside to the inside, the same method in the inside needs to be called by reflection, and then all parameters need to be copied from the inside to the outside. This manner of invocation is referred to as bi-directional synchronization.

The main purpose of the context support of the SDK plug-in is to enable the SDK plug-in to directly access own resource files of the plug-in SDK through the context and to be isolated from the resource files of the App.

The context support method comprises three methods, namely: base Context (Base Context), Application Context (Application Context), and real-time public Context (Context Wrapper).

Illustratively, the following is understood with respect to the underlying context:

the base context may be used to generate application contexts, may support a read system resource functions (get Resources/get Assets) approach, and may be used to generate application context objects that have not yet produced an SDK plug-in.

Illustratively, the application context is understood as follows:

the application context is the context actually used by the SDK plug-in and may be isolated from the host context. For example, a main Thread object (Activity Thread) can be obtained through the application context, then a member variable (Instrumentation) is obtained, a new application (new application) method is called, and an active application object is created through the base context. The application program object is the context actually used by the plug-in, the method for reading the system resource function of the application program can call the basic context, so that the resource of the SDK plug-in can be accessed, and the method for reading the system resource function can return to the method, so that the isolation from the host context is achieved.

Wherein, the byte code instrumentation technique can be performed with the context as a replacement object.

Exemplarily, the following is understood with respect to the real-time public context:

the real-time public context accesses the resources of the SDK plug-in. When the real-time public context is created, the application program can return in the method for reading the system resource function through the application program of the plug-in, so that the SDK plug-in is prevented from acquiring the context of the host.

Illustratively, the implementation of the functionality of the component that needs to be registered in Manifest is as follows:

the components in Manifest include: for example, the Activity component (Activity) for completing tasks based on interactions, the component (Service) for declaring services, the component (Receiver) for declaring broadcast receivers, and the component (Content Provider) for declaring Content providers, and specific registration principles may be referred to the above description and implementation principles in the related art, and are not described herein again. However, it should be noted that, in the present embodiment, the implementation is based on the bytecode instrumentation technology, rather than the implementation based on the encoding code as in the related art.

S206: and packaging the static SDK and a preset plug-in framework to obtain a client side assembly SDK deployed at the client side.

And the SDK plug-in and the client side assembly SDK form a plug-in SDK.

Fig. 3 is a schematic diagram according to a third embodiment of the present application, and as shown in fig. 3, the calling method of the plug-in software development kit according to the embodiment of the present application includes:

s301: and acquiring a calling request.

The calling request indicates to call a plugin Software Development Kit (SDK), the plugin SDK is generated based on the method described in the first embodiment or the second embodiment, and the plugin SDK comprises an SDK plugin and a client assembly (SDK).

For example, the execution subject of this embodiment may be a calling device (hereinafter, referred to as a calling device) of a plug-in software development kit, and the calling device may be the same device as the processing device or a device different from the processing device, which is not limited in this embodiment.

S302: and if the local SDK plug-in is determined not to be available according to the calling request, running the static SDK in the client assembly SDK.

Illustratively, this step may be understood as the calling device determining whether an SDK plug-in is stored locally, and if not, running a static SDK.

In other embodiments, the SDK plug-in is run if the calling device determines that the SDK plug-in is stored locally.

Based on the above analysis, it can be seen that the SDK plug-in is deployed in the cloud, and the static SDK is deployed in the client (i.e., locally), in some embodiments, the invoking device may perform initialization processing based on the client assembly SDK, when the plug-in SDK is used for the first time, the SDK plug-in may be downloaded from the cloud, but is not loaded for operation, when the invoking request is received, it is first determined whether the SDK plug-in is stored locally, if not (if not, it is not), the static SDK is executed, and if it is (if the SDK plug-in is loaded for operation for the first time or in other use processes), the SDK plug-in is executed.

That is to say, the calling device may execute the static SDK, and may also execute the SDK plug-in (if loaded), and the specific execution of the static SDK or the SDK plug-in may be set based on a requirement, a history, a test, and the like, which is not limited in this embodiment.

It should be noted that, if the calling device preferentially executes the static SDK, and the static SDK is abnormal, the calling device may execute the SDK plug-in, and if the SDK plug-in is already stored locally, the calling device directly calls and executes the locally stored SDK plug-in, and if the SDK plug-in is not stored locally, the calling device may obtain and execute the SDK plug-in from the cloud.

On the contrary, if the calling device preferentially executes the SDK plug-in and the SDK plug-in is abnormal, the calling device can execute the static SDK and download the SDK plug-in from the cloud again; alternatively, the calling device may download and execute the SDK plug-in again from the cloud.

It should be noted that, in some embodiments, the invoking device may preset the priority for invoking the static SDK and the SDK plugin, and if the priority of the static SDK is higher than the priority of the SDK plugin, the static SDK is invoked preferentially, whereas if the priority of the SDK plugin is higher than the static SDK, the static SDK is invoked preferentially.

Based on the foregoing embodiment, it can be seen that, if the SDK plug-in is deployed in the cloud, the invoking device may set a mechanism for initiating an update request for obtaining the latest version of the SDK plug-in to the cloud, for example, the update request is initiated at preset time intervals, or when receiving an updated SDK plug-in sent by the cloud, the update request is automatically triggered to be initiated to the cloud, and so on, which are not listed here one by one.

Illustratively, the calling method of the plug-in software development kit of the present embodiment may be applied to the application scenario as shown in fig. 4.

As shown in fig. 4, the user device 401 may be deployed with a client assembly SDK generated based on the first embodiment or the second embodiment, where the client static SDK includes a static SDK and a plug-in framework.

The cloud 402 may be deployed with the SDK plug-in generated based on the first embodiment or the second embodiment.

The user 403 may run a plug-in SDK through the user device 401. For example, if the plug-in SDK is an SDK for a map, the user 403 may initiate a request to the user device 401 to invoke the SDK for the map.

The user 403 may initiate a request for invoking the SDK of the map to the user device 401 by voice or by a touch screen, which is not limited in this embodiment.

Accordingly, the user device 401 may receive a request initiated by the user 403 to invoke the SDK of the map.

The user equipment 401 judges whether the SDK plug-in of the map is stored locally or not, and if not, the static SDK of the map in the client assembly SDK stored locally is operated; if so, running the SDK plug-in of the map.

Fig. 5 is a schematic diagram according to a fourth embodiment of the present application, and as shown in fig. 5, a plug-in processing apparatus 500 of a software development kit according to the embodiment of the present application includes:

the first obtaining unit 501 is configured to obtain a software development kit SDK to be processed, and obtain a configuration file of the SDK to be processed and call information of a call interface provided by the SDK to be processed externally.

A determining unit 502, configured to determine the implementation class of the SDK to be processed according to the configuration file.

The first generating unit 503 is configured to generate an SDK plugin deployed in the cloud according to the implementation class and the SDK to be processed, where the implementation class represents content indicated by each calling interface in the implementation configuration file.

The second generating unit 504 is configured to generate a static SDK according to the invocation information and the SDK to be processed.

And a packing unit 505, configured to pack the static SDK and the preset plug-in framework to obtain a client assembly SDK deployed at the client.

The SDK plug-in and the client side assembly SDK form a plug-in SDK.

Fig. 6 is a schematic diagram according to a fifth embodiment of the present application, and as shown in fig. 6, a plug-in processing apparatus 600 of a software development kit according to the embodiment of the present application includes:

the first obtaining unit 601 is configured to obtain a software development kit SDK to be processed, and obtain a configuration file of the SDK to be processed and call information of a call interface provided by the SDK to be processed externally.

A determining unit 602, configured to determine the implementation class of the SDK to be processed according to the configuration file.

As can be seen in conjunction with fig. 6, in some embodiments, the determining unit 602 includes:

a first determining subunit 6021, configured to determine, according to the configuration file, implementation logic for implementing the content indicated by each calling interface in the configuration file.

A first generating subunit 6022, configured to perform insertion processing on the SDK to be processed according to each implementation logic, and generate an implementation class corresponding to each implementation logic.

In some embodiments, the first generation subunit 6022 is configured to, for the implementation logic of the content indicated by each calling interface, insert the implementation logic of the content indicated by each calling interface into the SDK to be processed, and obtain an implementation class corresponding to the implementation logic of the content indicated by each calling interface.

In some embodiments, the first generation subunit 6022 comprises:

and the determining module is used for determining the byte codes corresponding to the implementation logics of the contents indicated by each calling interface.

And the instrumentation module is used for performing byte code instrumentation on the SDK to be processed based on the byte code corresponding to the implementation logic of the content indicated by each calling interface and generating the implementation class corresponding to the implementation logic of the content indicated by each calling interface.

In some embodiments, the stake module includes:

and the determining submodule is used for determining the insertion position of the byte code of the implementation logic of the content indicated by each calling interface in the SDK to be processed according to the configuration file.

And the inserting submodule is used for inserting the byte codes of the implementation logic of the content indicated by each calling interface into the insertion positions of the byte codes of the implementation logic of the content indicated by each calling interface in the SDK to be processed by adopting the preset instrumentation interface, and generating the implementation classes corresponding to the implementation logic of the content indicated by each calling interface.

The first generating unit 603 is configured to generate an SDK plug-in deployed in the cloud according to the implementation class and the SDK to be processed, where the implementation class represents content indicated by each invocation interface in the implementation configuration file.

As can be seen in fig. 6, in some embodiments, jar packets are included in the SDK to be processed; the first generation unit 603 includes:

a first inserting subunit 6031, configured to insert the implementation class into the jar packet, to obtain a new jar packet.

And a second generating subunit 6032, configured to generate an SDK plug-in according to the new jar packet and the SDK to be processed.

In some embodiments, the SDK to be processed includes a dynamic link library and a process file, and the process file includes a resource file; a second generation subunit 6032, including:

and the first packaging module is used for packaging the new jar package and the resource file into an application package.

And the second packaging module is used for packaging the application program package, the dynamic link library and the files except the resource files in the process files to obtain the SDK plug-in.

In some embodiments, the second generating subunit 6032 is configured to insert the call information into a call interface externally provided by the SDK to be processed, so as to obtain the static SDK.

The second generating unit 604 is configured to generate a static SDK according to the invocation information and the SDK to be processed.

As can be seen in fig. 6, in some embodiments, the second generating unit 604 includes:

and a second determining subunit 6041, configured to determine the call logic corresponding to the call information.

A second inserting sub-unit 6042, configured to insert a calling logic in a calling interface provided externally by the SDK to be processed, so as to obtain a static SDK.

In some embodiments, the second generating unit 604 is configured to determine a proxy code corresponding to the call logic, and perform bytecode instrumentation on a call interface externally provided by the to-be-processed SDK based on the proxy code to obtain a static SDK.

And the packing unit 605 is configured to pack the static SDK and the preset plug-in framework to obtain a client assembly SDK deployed at the client.

The SDK plug-in and the client side assembly SDK form a plug-in SDK.

Fig. 7 is a schematic diagram according to a sixth embodiment of the present application, and as shown in fig. 7, an invoking device 700 of a plug-in software development kit according to the embodiment of the present application includes:

a second obtaining unit 701, configured to obtain a call request, where the call request indicates to call a plugin software development kit SDK, the plugin SDK is generated based on the method described in the first embodiment or the second embodiment, and the plugin SDK includes an SDK plugin and a client assembly SDK.

The running unit 702 is configured to run a static SDK in the client assembly SDK if it is determined that the SDK plug-in is not locally available according to the invocation request.

In some embodiments, the execution unit 702 is configured to execute the SDK plugin if it is determined from the invocation request that the SDK plugin is locally available.

In some embodiments, a plug-in framework is also included in the client assembly SDK, and is used to complete initialization of the static SDK.

Exemplarily, fig. 8 is a schematic structural diagram of a plug-in SDK according to an embodiment of the present application.

As shown in fig. 8, the plug-in SDK includes:

the SDK system includes an SDK plug-in 801 deployed in a cloud and a client assembly SDK802 deployed in a client, where the client assembly SDK802 includes: a static SDK8021 and a plug-in framework 8022.

According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.

There is also provided, in accordance with an embodiment of the present application, a computer program product, including: a computer program, stored in a readable storage medium, from which at least one processor of the electronic device can read the computer program, the at least one processor executing the computer program causing the electronic device to perform the solution provided by any of the embodiments described above.

FIG. 9 illustrates a schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 9, the electronic apparatus 900 includes a computing unit 901, which can perform various appropriate actions and processes in accordance with a computer program stored in a Read Only Memory (ROM)902 or a computer program loaded from a storage unit 908 into a Random Access Memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the device 900 can also be stored. The calculation unit 901, ROM 902, and RAM 903 are connected to each other via a bus 904. An input/output (I/O) interface 905 is also connected to bus 904.

A number of components in the device 900 are connected to the I/O interface 905, including: an input unit 906 such as a keyboard, a mouse, and the like; an output unit 907 such as various types of displays, speakers, and the like; a storage unit 908 such as a magnetic disk, optical disk, or the like; and a communication unit 909 such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 909 allows the device 900 to exchange information/data with other devices through a computer network such as the internet and/or various telecommunication networks.

The computing unit 901 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The computing unit 901 executes the respective methods and processes described above, such as the plug-in processing method of the software development kit or the calling method of the plug-in software development kit. For example, in some embodiments, a plug-in processing method of a software development kit or a calling method of a plug-in software development kit may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program may be loaded and/or installed onto device 900 via ROM 902 and/or communications unit 909. When the computer program is loaded into the RAM 903 and executed by the computing unit 901, one or more steps of the plug-in processing method of the software development kit or the calling method of the plug-in software development kit described above may be performed. Alternatively, in other embodiments, the computing unit 901 may be configured by any other suitable means (e.g., by means of firmware) to execute a plug-in processing method of a software development kit or a calling method of a plug-in software development kit.

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The Server can be a cloud Server, also called a cloud computing Server or a cloud host, and is a host product in a cloud computing service system, so as to solve the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service ("Virtual Private Server", or simply "VPS"). The server may also be a server of a distributed system, or a server incorporating a blockchain.

According to another aspect of the embodiments of the present application, there is also provided a terminal device including the electronic device according to the above embodiments.

In one example, the terminal device may be a user device, for example, the terminal device may be a mobile phone as shown in fig. 4, and of course, the terminal device may also be other user devices, such as a desktop computer, a notebook computer, a palmtop computer, and the like.

In another example, the terminal device may also be a server, a local server, or a cloud server.

It should be noted that the above examples are only for exemplary illustration, and the possible types of the terminal device of the present embodiment are not to be construed as limiting the terminal device.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, and the present invention is not limited thereto as long as the desired results of the technical solutions disclosed in the present application can be achieved.

The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A plug-in processing method of a software development kit comprises the following steps:

2. The method of claim 1, wherein the configuration file is used to indicate the implementation classes required for the SDK to be processed; determining the implementation class of the SDK to be processed according to the configuration file, wherein the determination comprises the following steps:

determining implementation logic for implementing the content indicated by each calling interface in the configuration file according to the configuration file;

and performing insertion processing on the SDK to be processed according to each implementation logic to generate implementation classes corresponding to each implementation logic.

3. The method of claim 2, wherein the inserting the to-be-processed SDK according to each implementation logic to generate the implementation class corresponding to each implementation logic comprises:

and aiming at the implementation logic of the content indicated by each calling interface, inserting the implementation logic of the content indicated by each calling interface into the SDK to be processed to obtain an implementation class corresponding to the implementation logic of the content indicated by each calling interface.

4. The method of claim 3, wherein inserting the implementation logic of the content indicated by each calling interface into the SDK to be processed to obtain an implementation class corresponding to the implementation logic of the content indicated by each calling interface comprises:

determining byte codes corresponding to the implementation logic of the content indicated by each calling interface;

and performing byte code instrumentation on the SDK to be processed based on the byte code corresponding to the implementation logic of the content indicated by each calling interface, and generating an implementation class corresponding to the implementation logic of the content indicated by each calling interface.

5. The method of claim 4, wherein performing bytecode instrumentation on the to-be-processed SDK based on the bytecode of the implementation logic of the content indicated by each calling interface to generate an implementation class corresponding to the implementation logic of the content indicated by each calling interface, comprises:

determining the inserting position of the byte code of the implementation logic of the content indicated by each calling interface in the SDK to be processed according to the configuration file;

inserting the byte codes of the implementation logic of the content indicated by each calling interface into the insertion positions of the byte codes of the implementation logic of the content indicated by each calling interface in the SDK to be processed by adopting a preset instrumentation interface, and generating the implementation classes corresponding to the implementation logic of the content indicated by each calling interface.

6. The method of claim 1, wherein the SDK to be processed comprises jar packets; generating an SDK plug-in deployed in a cloud according to the implementation class and the SDK to be processed, wherein the generation comprises the following steps:

inserting the implementation class into the jar packet to obtain a new jar packet;

and generating the SDK plug-in according to the new jar packet and the SDK to be processed.

7. The method of claim 6, wherein the SDK to be processed comprises a dynamic link library and a process file, and the process file comprises a resource file; generating the SDK plug-in according to the new jar packet and the SDK to be processed, wherein the step of generating the SDK plug-in comprises the following steps:

packaging the new jar package and the resource file into an application package;

and packaging the application program package, the dynamic link library and the files except the resource files in the process files to obtain the SDK plug-in.

8. The method of any of claims 1 to 7, wherein generating a static SDK from the invocation information comprises:

and inserting the calling information into a calling interface externally provided by the SDK to be processed to obtain the static SDK.

9. The method of claim 8, wherein inserting the call information into a call interface externally provided by the to-be-processed SDK to obtain the static SDK comprises:

determining a calling logic corresponding to the calling information;

and inserting the calling logic into a calling interface externally provided by the SDK to be processed to obtain the static SDK.

10. The method of claim 9, wherein determining a call logic corresponding to the call information, and inserting the call logic into a call interface externally provided by the to-be-processed SDK to obtain the static SDK comprises:

determining a proxy code corresponding to the calling logic, and performing byte code instrumentation on a calling interface externally provided by the SDK to be processed based on the proxy code to obtain the static SDK.

11. A method for calling a plug-in software development kit, comprising:

12. The method of claim 11, further comprising:

and if the SDK plug-in is locally provided according to the calling request, operating the SDK plug-in.

13. The method of claim 11 or 12, wherein the client assembly SDK further comprises a plug-in framework for completing initialization of the static SDK.

14. A plug-in processing device for a software development kit, comprising:

15. The apparatus of claim 14, wherein the configuration file is to indicate implementation classes required for the SDK to be processed; the determination unit includes:

the first determining subunit is used for determining, according to the configuration file, implementation logic for implementing the content indicated by each calling interface in the configuration file;

and the first generation subunit is used for performing insertion processing on the SDK to be processed according to each implementation logic and generating implementation classes corresponding to each implementation logic.

16. The apparatus of claim 14, wherein the first generating subunit is configured to, for the implementation logic of the content indicated by each call interface, insert the implementation logic of the content indicated by each call interface into the SDK to be processed, and obtain an implementation class corresponding to the implementation logic of the content indicated by each call interface.

17. The apparatus of claim 16, wherein the first generating subunit comprises:

the determining module is used for determining the byte codes corresponding to the implementation logics of the contents indicated by each calling interface;

and the instrumentation module is used for performing byte code instrumentation on the SDK to be processed based on the byte code corresponding to the implementation logic of the content indicated by each calling interface, and generating an implementation class corresponding to the implementation logic of the content indicated by each calling interface.

18. The apparatus of claim 17, wherein the stake module comprises:

the determining submodule is used for determining the insertion position of the byte code of the implementation logic of the content indicated by each calling interface in the SDK to be processed according to the configuration file;

and the inserting submodule is used for inserting the byte codes of the implementation logic of the content indicated by each calling interface into the insertion positions of the byte codes of the implementation logic of the content indicated by each calling interface in the SDK to be processed by adopting a preset instrumentation interface, and generating the implementation classes corresponding to the implementation logic of the content indicated by each calling interface.

19. The apparatus of claim 14, wherein the SDK to be processed comprises jar packets; the first generation unit includes:

the first inserting subunit is used for inserting the implementation class into the jar packet to obtain a new jar packet;

and the second generating subunit is used for generating the SDK plug-in according to the new jar packet and the SDK to be processed.

20. The apparatus of claim 19, wherein the SDK to be processed comprises a dynamic link library and a process file, and the process file comprises a resource file; the second generation subunit includes:

the first packaging module is used for packaging the new jar package and the resource file into an application package;

21. The apparatus according to any one of claims 14 to 20, wherein the second generating unit is configured to insert the call information into a call interface externally provided by the to-be-processed SDK, so as to obtain the static SDK.

22. The apparatus of claim 21, wherein the second generating unit comprises:

the second determining subunit is used for determining a calling logic corresponding to the calling information;

and the second inserting subunit is used for inserting the calling logic into a calling interface externally provided by the to-be-processed SDK to obtain the static SDK.

23. The apparatus of claim 22, wherein the second generating unit is configured to determine a proxy code corresponding to a call logic, and perform bytecode instrumentation on a call interface externally provided by the to-be-processed SDK based on the proxy code to obtain the static SDK.

24. A calling device for a plug-in software development kit, comprising:

25. The apparatus of claim 24, wherein the execution unit is configured to execute the SDK plugin if it is determined that the SDK plugin is locally available according to the invocation request.

26. The apparatus of claim 24 or 25, wherein the client assembly SDK further comprises a plug-in framework for completing initialization of the static SDK.

27. An electronic device, comprising:

at least one processor; and

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-10; alternatively, the first and second electrodes may be,

to enable the at least one processor to perform the method of any one of claims 11-13.

28. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-10; alternatively, the first and second electrodes may be,

the computer instructions are for causing the computer to perform the method of any one of claims 11-13.

29. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-10; alternatively, the first and second electrodes may be,

the computer program, when executed by a processor, implementing the method according to any one of claims 11-13.

30. A terminal device comprising the electronic device of claim 27.