CN114860468A

CN114860468A - SDK calling method and device, computer equipment and storage medium

Info

Publication number: CN114860468A
Application number: CN202110154507.2A
Authority: CN
Inventors: 苟亚明; 骆寰宇
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-02-04
Filing date: 2021-02-04
Publication date: 2022-08-05

Abstract

The application provides an SDK calling method, an SDK calling device, computer equipment and a storage medium, which are applied to a first SDK in an application program, wherein the first SDK receives an SDK calling request sent by a target service party of the application program, the SDK calling request indicates to call a target SDK in at least one second SDK of the application program, and the target SDK is called depending on parameters, and the second SDK is different from the first SDK; inquiring a registration list pre-generated in the first SDK when the application program is started to obtain a target class name of the target SDK; and then the parameters are transmitted to the target SDK according to the target class name, so that the target SDK can be triggered to respond to the execution command indicated by the parameter execution parameters. According to the method and the system, the required service can be realized only by loading the SDK with the required function according to the requirement by different access parties, and customized development is not required for different access parties, so that the development workload is reduced, and the development efficiency is improved.

Description

SDK calling method and device, computer equipment and storage medium

Technical Field

The present invention relates to the field of computer technologies, and in particular, to an SDK invoking method, an SDK invoking device, a computer device, and a storage medium.

Background

Interdependencies between functions in the service module may cause the access party to import the dependent functions. For example, if the access side depends on the function B and needs to use the function a but does not need to use the function B, the access side needs to import not only the function a but also the function B. The interdependence between functions causes the size of the application package of the access party to increase, and also increases the compiling time, and in severe cases, also causes development blocking.

In order to solve the problems of increased size of an application package of an access party, increased compiling time, development blocking caused by serious conditions and the like caused by function interdependence, the prior art provides a customized development mode for different access parties. However, the customized development method for different access parties requires different functions to be deleted and redeveloped for different access parties, which results in large development workload and low efficiency. Especially, when the functions which are mutually dependent are more, the defects of large development workload and low efficiency are increasingly obvious.

Disclosure of Invention

In view of the above, to solve the above problems, the present invention provides an SDK invoking method, an apparatus, a computer device, and a storage medium, in which an access party only needs to load an SDK with a required function as needed to complete a required service based on invoking between SDKs, and customized development is not needed for different access parties, so that development workload is reduced, and development efficiency is improved, and the technical scheme is as follows:

an SDK calling method is applied to a first SDK in an application program, and comprises the following steps:

receiving an SDK calling request sent by a target service party of the application program, wherein the SDK calling request indicates to call a target SDK in at least one second SDK of the application program, and the target SDK is called depending on parameters; the second SDK is different from the first SDK;

inquiring a registration list pre-generated in the first SDK when the application program is started, and acquiring a target class name of the target SDK; the registration list comprises registration information of each second SDK in the at least one second SDK, and the registration information of the second SDK indicates the class name of the second SDK;

and transmitting the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the parameters to execute the execution command indicated by the parameters.

An SDK calling apparatus applied to a first SDK in an application, the apparatus comprising:

an SDK call request receiving unit, configured to receive an SDK call request sent by a target service party of the application, where the SDK call request indicates to call a target SDK in at least one second SDK of the application, and the target SDK is called depending on a parameter; the second SDK is different from the first SDK;

a target class name obtaining unit, configured to query a registration list pre-generated in the first SDK when the application is started, and obtain a target class name of the target SDK; the registration list comprises registration information of each second SDK in the at least one second SDK, and the registration information of the second SDK indicates the class name of the second SDK;

and the SDK calling unit is used for transmitting the parameters to the target SDK according to the target class name and triggering the target SDK to respond to the parameters to execute the execution command indicated by the parameters.

A computer device, comprising: the system comprises a processor and a memory, wherein the processor and the memory are connected through a communication bus; the processor is used for calling and executing the program stored in the memory; the memory is used for storing programs, and the programs are used for realizing the SDK calling method.

A computer readable storage medium having stored thereon a computer program which, when loaded and executed by a processor, carries out the steps of the SDK call method.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

Fig. 1 is a schematic diagram of a splitting result of a login SDK according to an embodiment of the present application;

fig. 2 is a flowchart of an SDK invoking method according to an embodiment of the present application;

fig. 3 is a flowchart of another SDK invoking method provided in the embodiment of the present application;

fig. 4 is a schematic diagram illustrating a first SDK system according to an embodiment of the present disclosure;

FIG. 5 is a diagram illustrating a data structure provided in an embodiment of the present application;

fig. 6 is a schematic diagram of an SDK invoking method according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an SDK invoking device according to an embodiment of the present application;

fig. 8 is a block diagram of a hardware structure of a computer device to which an SDK calling method according to an embodiment of the present invention is applied.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Cloud technology refers to a hosting technology for unifying serial resources such as hardware, software, network and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data.

Cloud technology (Cloud technology) is based on a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied in a Cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing.

The application relates to a user management tool in cloud technology.

In order to facilitate understanding of an SDK calling method, an SDK calling apparatus, a computer device, and a storage medium provided in the embodiments of the present application, first, technical terms involved in the SDK calling method provided in the embodiments of the present application are described.

Reflection: when running, the code of the application program (App) can acquire all attributes and methods of any one class, and can call and modify all attributes and methods of any one class or instance.

An SDK access party: generally referred to as a stand-alone application (App).

The functional dependence may cause the size of the application package of the access party to increase, and may also increase the compiling time, and in severe cases, may also cause development blocking. To give an example of a product side application: in the SDK maintained by the central station, a set of login SDKs exist, and the login SDKs have a plurality of modes: QQ login, WeChat login, microblog login, Microsoft login, Google login, etc. The domestic version of the video application only supports QQ and WeChat login, and the international version of the video application (user objects are overseas) needs to support Microsoft and Google login, so that the functions of the Microsoft and Google login in the domestic version of the video application are not used, but binary packages are still imported in the project, and the package volume and the compiling time are increased.

In order to reduce the volume and the compiling time of the domestic version registration SDK, the prior art can carry out customized development of the registration SDK aiming at the domestic version, delete Microsoft and Google registration from the registration SDK, and carry out development again to obtain the domestic version customized registration SDK, and the customized development of the domestic version registration SDK has large workload and low efficiency. Moreover, if different foreign countries have different requirements for login functions in the login SDK, the corresponding login SDK also needs to be customized and developed for different foreign countries, so that the development workload of the login SDK is further increased, and the customized development efficiency of the login SDK is reduced.

The SDK calling method provided by the embodiment of the application is characterized in that the functions of modules in the SDK are refined as much as possible, in terms of logging in the SDK, all logging-in modes are split, any combination of logging-in functions can be selected when an access party uses the SDK, and all logging-in modes are independent. Referring to fig. 1, after splitting each login mode, the access party can select the SDK after corresponding splitting according to the own requirement, and then realize the calling between SDKs based on the SDK calling method provided by the present application, and complete the service function.

The SDK calling method provided by the embodiment of the application is applied to the middleware SDK loaded on the access party, the middleware SDK does not need to care about the service requirement of the access party, the access party can load the corresponding SDK according to the service requirement of the access party, the middleware SDK can assist in realizing information transmission loaded between any two SDKs of the access party, and then one or more SDKs can realize the service function required to be realized by the access party together.

In order to make the aforementioned objects, features and advantages of the present invention comprehensible, embodiments accompanied with figures are described in further detail below.

According to the embodiment of the application, the functions of the modules can be refined as much as possible, one module is split into a plurality of functions, and each function is developed into one SDK independently, so that the functions in the modules are independent. That is, the SDKs corresponding to different functions in the module are independent of each other.

When an access party needs to provide a certain service in a module, the access party can determine a plurality of mutually independent SDKs into which the module is split, then determine an SDK related to the service from the plurality of SDKs, load the SDK related to the service and load a middleware SDK, where the middleware SDK is used to provide an SDK calling method provided by the embodiment of the present application, so as to implement mutual calling among the SDKs related to the service, and achieve the purpose of providing the service to the outside based on the mutual calling among the SDKs related to the service.

The SDK calling method provided in the embodiment of the present application is described in detail below from the perspective of a middleware SDK, and based on the SDK calling method provided in the embodiment of the present application, mutual calling between any two SDKs loaded on an access side can be achieved.

As shown in fig. 2, the method includes:

s201, receiving an SDK calling request sent by a target service party of an application program, wherein the SDK calling request indicates to call a target SDK in at least one second SDK of the application program, and the target SDK is called depending on parameters; the second SDK is different from the first SDK;

the computer device is provided with an application program (also called as App, access party), the application program is loaded with a middleware SDK (software development kit) which can also be called as a first SDK, the application program is loaded with not only the first SDK but also at least one second SDK, the second SDK is used for realizing service function, and the second SDK is different from the middleware SDK.

In the embodiment of the application, a service party (i.e., an SDK caller) on the application may send an SDK call request to the first SDK in response to a user operation to call any one of the at least one second SDK. For the sake of distinction, the service party that sends the SDK invocation request to the first SDK may be referred to as a target service party, and the service party may be considered as one SDK.

Illustratively, the service party may be any one of the at least one second SDK. For example, any one of the second SDKs loaded on the access party may be used as a service party, and the service party may send an SDK invocation request to the first SDK in response to a user operation to invoke another second SDK.

In the embodiment of the application, the target service side in the application sends the SDK call request to the first SDK in the application to request to call a certain second SDK in the at least one second SDK, and for convenience of distinguishing, the second SDK that the target service side requests to be called by the first SDK may be referred to as the target SDK.

And the target service party in the application program responds to the SDK calling request sent to the first SDK by the user operation, and carries the SDK identification and the parameters of the target SDK so as to request the first SDK to call the target SDK depending on the parameters.

For example, the parameter may carry command information, so that after the target SDK receives the parameter, the target SDK may respond to the execution command indicated by the parameter execution command information.

Further, the parameter may also indicate a resource of the target SDK requested to be invoked, and for convenience of distinction, the resource of the target SDK requested to be invoked by the SDK invocation request sent by the target service party may be referred to as a target SDK resource.

Further, if the target service party needs the target SDK to return the execution result, the parameter may further include a function pointer, where the function pointer indicates a certain function of the target service party (for convenience of distinguishing, the function may be referred to as a target function), so that after the target SDK generates the execution result in response to the call request of the target service party, the execution result is returned to the target function of the target service party through the function pointer.

Furthermore, after receiving the execution result returned by the target SDK through the first SDK, the target service party may also execute the target function in response to the execution result.

S202, inquiring a registration list pre-generated in the first SDK when the application program is started, and acquiring a target class name of the target SDK; the registration list comprises registration information of each second SDK in at least one second SDK, and the registration information of the second SDK indicates the class name of the second SDK;

according to the embodiment of the application, when the application program is started, a registration list is generated in the first SDK in the application program in advance; the registration list includes registration information for each of the at least one second SDK. Taking the registration information of the second SDK as an example, the registration information of the second SDK includes the SDK identifier of the second SDK and the class name of the second SDK. Therefore, the class name of the second SDK carried by the registration information of the second SDK is the class name of the second SDK indicated by the registration information of the second SDK.

For example, after receiving the SDK invocation request sent by the target service party, the first SDK may query the registration list after acquiring the SDK identifier and the parameter carried in the SDK invocation request, acquire the registration information carrying the SDK identifier from the registration list, and use the class name in the acquired registration information as the target class name.

It should be noted that the SDKs of different SDKs in the application are different, and the SDK corresponding to the SDK identifier carried in the SDK invocation request may be regarded as the target SDK requested to be invoked by the target service party, and correspondingly, the target class name obtained by querying the registration list may be regarded as the class name of the target SDK.

For example, the registration list in the embodiment of the present application may also be referred to as a hash table.

S203, transmitting the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the execution command indicated by the parameter execution instruction.

In the embodiment of the application, the first SDK may transmit the parameter in the SDK call request to the target SDK according to the target class name of the target SDK, so as to trigger the target SDK to respond to the execution command indicated by the operation execution parameter.

Fig. 3 is a flowchart of another SDK invoking method according to an embodiment of the present application.

As shown in fig. 3, the method includes:

s301, receiving an SDK calling request sent by a target service party of the application program, wherein the SDK calling request indicates to call a target SDK in at least one second SDK of the application program, and the target SDK is called depending on parameters; the second SDK is different from the first SDK;

s302, inquiring a registration list pre-generated in the first SDK when the application program is started, and acquiring a target class name of the target SDK; the registration list comprises registration information of each second SDK in at least one second SDK, and the registration information of the second SDK indicates the class name of the second SDK;

in this embodiment, the process of pre-generating the registration list by the first SDK may be: responding to the starting of an application program, providing a registration method for the first SDK, wherein the registration method carries a first parameter and a second parameter, the first parameter indicates an SDK identifier of the SDK, and the second parameter indicates a class name of the SDK; receiving the SDK identification and the class name of the second SDK transmitted to the first SKD by the registration method when the second SDK responds to the starting of the application program for initialization; and generating registration information of a second SDK for storing the registration list according to the SDK identification and the class name.

For example, the first SDK may provide a registration method to the outside in response to the start of the application, and the registration method may be a register withname: the first parameter is id and the Class name of the second parameter Class; correspondingly, the second SDK can also respond to the starting of the application program to carry out initialization, and a register WithName method is called during initialization, and the id and the class name of the second SDK are transmitted; and the first SDK stores the id and the corresponding class name transmitted by each second SDK into a registration list according to a key-value mode, for example, the id of the login SDK is 100, the class name is LoginEngin, and the generated key-value is 100: LoginEngin.

The first parameter is id, and the id can be regarded as the SDK identification of the SDK; the second parameter is a Class name, which indicates the Class name of the SDK.

The above is only a preferred generation manner of the registration list provided in the embodiment of the present application, and regarding a specific generation manner of the registration list, a person skilled in the art may set the generation manner according to a need of the person skilled in the art, which is not limited herein.

The execution process of steps S301 to S302 provided in this embodiment is the same as the execution process of steps S201 to S202 provided in the above embodiment, and for the specific execution manner of steps S301 to S302, reference is made to the description of steps S201 to S202 in the above embodiment, which is not repeated herein.

S303, sending a resource calling request to the target SDK according to the target class name, wherein the resource calling request indicates a target resource;

in the embodiment of the application, after receiving the SDK call request sent by the target service party, the first SDK sends a resource call request to the target SDK according to the target resource of the target SDK requested to be called indicated by the SDK call request, where the resource call request indicates the target resource.

S304, receiving multithreading information returned by the target SDK responding to the resource calling request;

illustratively, at least one resource exists in the target SDK, the target SDK manages the at least one resource, and some of the at least one resource may or may not support multithreading.

After receiving a resource calling request sent by a first SDK, a target SDK determines a target resource called by a resource calling request indication, and further can judge whether the target resource is a resource supporting multithreading or not, if the target resource is the resource supporting multithreading, the target SDK returns multithreading information representing that the target resource supports multithreading to the first SDK; and if the target resource is a resource which does not support multithreading, the target SDK returns multithreading information which represents that the target resource does not support multithreading to the first SDK.

Illustratively, the multithreading information may be needSupDaturad, and if YES is returned by the needSupDaturad, the target resource is characterized to support multithreading; if the returned result of the needSupUltithread is NO, the characterization target resource does not support multithreading.

The above is only the preferred content of the multithreading information provided in the embodiment of the present application, and the specific content of the multithreading information may be set by a person skilled in the art according to his own needs, which is not limited herein.

S305, judging whether the multithreading information represents that the target resource supports multithreading or not; if the multithreading information represents that the target resource does not support multithreading, executing the step S306; if the multithreading information represents that the target resource supports multithreading, executing step S307;

s306, constructing a mutual exclusion lock;

in an embodiment of the application, the first SDK is integrated with a pthread (POSIX thread) framework, where pthread is the POSIX standard for threads, which defines a complete set of APIs for creating and manipulating threads. After the first SDK receives the multithreading information returned by the target SDK, if the multithreading information indicates that the target resource does not support multithreading, a mutual exclusion lock needs to be constructed.

The way for the first SDK to construct the mutual exclusion lock may be: importing a pthread.h header file; initializing the attribute of the mutual exclusion lock, creating a mutual exclusion lock object, and transmitting an attribute address and a mutual exclusion lock object address into an init method; calling the lock attempt function brings in the mutex object address.

Illustratively, the attempted lock function may be a pthread _ mutex _ trylock function. The above is merely a preferred content of the attempted locking function provided by the embodiments of the present application, and regarding the specific content of the attempted locking function, a person skilled in the art may set the function according to his own needs, and is not limited herein.

In this embodiment of the application, the parameters are transmitted to the target SDK according to the target class name, and the manner of triggering the target SDK to respond to the execution command indicated by the parameter execution parameter may be: and calling a getDataWithParam method to transmit the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the execution command indicated by the parameter execution command.

Correspondingly, after the getDataWithParam method is executed, an unlocking function can be called to unlock the mutual exclusion lock.

For example, the unlock function may be pthread _ mutex _ unlock (). The above is only the preferable content of the unlocking function provided in the embodiment of the present application, and regarding the specific content of the unlocking function, a person skilled in the art may set the unlocking function according to his own needs, which is not limited herein.

S307, transmitting the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the execution command indicated by the parameter execution instruction;

as an implementation manner of the embodiment of the present application, all parameters carried in the SDK invocation request may be directly transmitted to the target SDK when step S307 is executed.

As another implementation manner of the embodiment of the present application, when executed in step S303, the first SDK has transmitted information indicating the target resource in the parameter carried in the SDK invocation request to the target SDK; accordingly, when step S307 is executed, only other information except the information indicating the target resource in the parameters carried in the SDK invocation request may be transmitted to the target SDK, so as to reduce the information transmission bandwidth.

The above are two preferable implementation manners for transmitting the parameter to the target SDK according to the target class name provided in the embodiment of the present application, and those skilled in the art can set the implementation manner of the process according to their own requirements, which is not limited herein.

Exemplarily, an SDK invocation request received by the first SDK carries parameters, and the parameters include command information in addition to information indicating target resources; the first SDK after transmitting the parameter to the target SDK based on step S307, the target SDK may respond to the execution command indicated by the parameter execution command information. Wherein executing the command may involve operating on a target resource in the target SDK.

In the embodiment of the present application, the command information may be parameter _ 0-1, parameter _ 0-2, and parameter _ 0-3. When the command information is parameter _0 ═ 1, the execution command indicated by the command information may be an execution page return instruction; when the command information is parameter _0 ═ 2, the execution command indicated by the command information may be an execute page jump instruction; when the command information is parameter _0 ═ 3, the execution command indicated by the command information may be an execution pop-up login prompt.

The above is only the preferred content of the command information provided in the embodiment of the present application, and the specific content of the command information may be set by a person skilled in the art according to his own needs, which is not limited herein.

It should be noted that the agreement between the target service party and the target SDK for the command information is uniform, so that it can be ensured that the execution command executed by the target SDK based on the command information is the execution command that the target service party wants to execute after the target service party sends the command information to the target SDK.

In addition, when the target service party, the first SDK and the target SDK interact with each other, a standard and uniform data structure is required to be adopted to ensure accurate transmission of information.

And S308, if the parameters further comprise a function pointer for calling back the execution result, returning the execution result of the execution command returned by the target SDK based on the function pointer to the target service party.

Further, the SDK call request received by the first SDK carries parameters, and the parameters may include a function pointer in addition to information indicating a target resource and command information. It should be noted that, in a normal case, the parameter in the sent SDK call request carries the function pointer only when the target service party needs to return the execution result from the target SDK, otherwise, if the target service party does not need to return the execution result from the target SDK, the parameter in the SDK call request sent by the target service party may not carry the function pointer.

Correspondingly, if the parameter further includes a function pointer for performing execution result callback, after the target SDK executes the execution command indicated by the command information to obtain an execution result, the execution result may be returned to the target service party through the first SDK based on the function pointer. Specifically, the execution result may be returned to the target function of the target service party indicated by the function pointer.

If the parameter does not include the function pointer for performing the execution result callback, the target SDK does not perform the process of returning the execution result after the execution command indicated by the execution command information obtains the execution result.

It should be noted that, after receiving the SDK invocation request sent by the target service party, the first SDK may not directly respond to the SDK invocation request to execute a corresponding SDK invocation method, but store the received SDK invocation request in the cache queue, and further determine the SDK invocation request that needs to be responded currently (i.e., the SDK invocation request to be processed currently) from the cache queue.

Correspondingly, a registration list pre-generated in the first SDK when the application program is started is inquired, and a target class name of the target SDK is obtained; transmitting the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the execution command indicated by the parameter execution instruction, wherein the execution command comprises the following steps: determining the current SDK calling request to be processed in a cache queue based on the preset priority of a service party in an application program; inquiring a registration list pre-generated in a first SDK when an application program is started, and acquiring a target class name of a target SDK indicated by a current SDK calling request to be processed; and transmitting the parameters indicated by the SDK calling request to be processed to the target SDK according to the target class name, and triggering the target SDK to respond to the execution command indicated by the parameter execution command.

It should be noted that each of the at least one second SDK loaded in the application may also be regarded as a service party. Thus, the priority of the second SDK may also be referred to in the priority of the service in the application.

In the application, the target service party can be regarded as the SDK, the first SDK can be regarded as the middleware SDK, the target service party, the first SDK and the target SDK are independent of each other, and the target service party can call the target SDK depending on the first SDK. Therefore, the application can decouple the interdependent service functions, and the access party can complete the required service based on the calling between the SDKs only by loading the SDKs with the required functions as required without carrying out customized development on different access parties, thereby reducing the development workload and improving the development efficiency.

The SDK calling method provided in the embodiment of the present application is described in detail below from the perspective of system composition of the first SDK. Referring to fig. 4, the first SDK provided in the embodiment of the present application is composed of a calling module, an engine module, and a data parsing module.

The calling module is as follows:

initializing class objects or instance objects by class name, and calling methods in the class by reflection mechanism. The module needs to process the multithreading problem and the calling success/failure problem, the multithreading problem is that a piece of resource or memory (both the resource and the memory can be regarded as target resource) is read and written at the same time, a plurality of business parties simultaneously create a certain instance object in the calling module, the attribute or the memory in the certain instance is modified, the calling module is not responsible for management, and the business module maintaining the instance object is used for processing; before calling, a business party needs to abide by two protocols, namely, needSupUlthread and callComplete, of a calling module, wherein the needSupUlthread needs to return whether to support multithreading operation, if not, a mutual exclusion lock is added in the calling module for protection, and the construction of the mutual exclusion lock is realized in the following way:

1. and the implementation is realized by adopting a cross-platform frame pthread, and pthread.h header files need to be imported.

2. The attribute attr of the lock is initialized, then the mutex object is created, the init method is called to transfer the object address and the attribute address into the mutex object, and the mutex object can be used.

3. When the module is called up, before the getDataWithParam method starts to execute, a pthread _ mutex _ trylock function is called to transfer in a mutex object address, at the moment, locking is successful, and before the current method is executed, other business parties can sleep and wait when entering the getDataWithParam method.

4. The next service party cannot enter the getDataWithParam method until the pthread _ mutex _ unlock () function is called after the getDataWithParam of the previous service party is executed.

Therefore, thread safety can be guaranteed by using the mutual exclusion lock, and the problem that the SDK is crashed because the same attribute is modified at the same time in the needSupBatithread method is solved.

If the needSupUltithread returns YES, multithreading is supported, and the calling module does not process. The callComplete is a callback performed when the call is completed, when a calls B, time-consuming operations such as network requests and the like may be performed inside B, so whether a synchronization callback is to be performed or not is transmitted in the callback of the callComplete protocol method, and the implementation effect is as follows: in the process that the call B is executed by the A, the function pointer is transmitted through the callComplete, so that the A can do other tasks at the moment after the call B is generated by the A, and the A returns a message to the A through the function pointer of the callComplete after the internal processing of the B is finished, thereby improving the performance of the business party A.

The engine module is as follows:

the engine module maintains a global hash table, and the SDK injects the id and the basic class name of the SDK into the hash table when starting, and the implementation process is as follows:

1. the engine module provides a register WithName to the outside, wherein the register WithName is as follows: the parameters are id and Class name of Class

2, when the SDK is initialized, calling a register WithName method of the engine module, and transmitting the id and class name of the SDK

3. The hash table stores the id and the corresponding class name of each SDK according to a key-value mode, for example, the id of the SDK is 100, the class name is LoginEngin, and the generated key-value is 100: LoginEngin

When the message is called and distributed, the data type is analyzed in the data analysis module, the class name of the calling service party is found from the hash table through the key, and the calling is completed through the calling module after the class name is obtained. After the SDK takes the parsed data, corresponding codes are executed according to an agreed parameter value (for example, a parameter _0 ═ 1 executes a page return instruction, a parameter _0 ═ 2 executes a page jump instruction, and a parameter _0 ═ 3 executes a pop-up login prompt), and the returned data is implemented in a callComplete method.

The engine module will order the frequently called service functions, and since the amount of the called data may be large, a priority policy needs to be established, for example, a network module needs to be called to report the data in a real-time reporting system, the priority is not high but the data needs to be cached, the engine module will cache the incoming data locally, and when a certain amount of data is reached, the data will be called next. The priority level is preset by a service module, the value is between 0 and 10, a default parameter is added in the getDataWithParam method during calling, and if the priority level is not set, the default parameter is 5.

The data analysis module is as follows:

for formatting the data transmitted by the engine module and the calling module, since the data structures adopted by the service modules are different, a uniform data structure needs to be specified when interaction is performed, and the data structure is shown in fig. 5.

When a service module starts to be called, a data analysis module is required to be checked before the service module is transmitted to an engine module, if the data is not standard, shielding operation is carried out, a data structure is specified to be a dictionary, bizId and bizSubId must be transmitted, which indicates which function of which service party the calling party wants to acquire data from, custom json data can be transmitted under a parameter node optionally, the custom json data is in a format agreed by the calling party and the service party, and the data analysis module does not carry out any check.

Illustratively, bizId may be considered an SDK identification and bizSubId may be considered an identification of a module in the SDK.

Based on the above description of the system composition of the first SDK provided in the embodiment of the present application, the SDK calling method provided in the embodiment of the present application is further described in detail with reference to the schematic diagram of the SDK calling method shown in fig. 6.

As shown in fig. 6, the preparation to start communication may be regarded as application startup, and the data injection may be regarded as a pre-generation process of a registration list in a first SDK of the application, that is, a process of injecting registration information into the registration list of the first SDK by each of at least one second SDK. Further, the data parsing module may also verify whether the registration information of each second SDK passes, and if the registration information of a certain second SDK does not pass, the subsequent target service party may return a call failure when calling the second SDK.

For example, the engine module may be entered to call the target SDK, specifically, the class name corresponding to the id of the target SDK may be obtained through a registration list, the target SDK is called through reflection after multithread processing, and an execution result of the target SDK is returned under the condition that the callComplete method is executed.

According to the SDK calling method provided by the embodiment of the application, when the SDK is dependent, the application can be used for decoupling. If the data are acquired independently, the dependence number of the SDK can be greatly reduced, for example: when a user submits opinion feedback in the App, the user can acquire corresponding logs according to feedback problems (such as playing problems, webpage loading problems, directional flow problems, screen projection problems and the like) selected by the user, and log information is sent to a server when clicking submission is carried out. The log system forms the SDK in the middle station application, the middle station application can acquire the log data of each service party only by integrating the log SDK, and whether the corresponding function needs to be imported or not does not need to be concerned.

Fig. 7 is a schematic structural diagram of an SDK invoking device according to an embodiment of the present application.

The SDK calling apparatus shown in fig. 7 is applied to the first SDK, and includes:

an SDK call request receiving unit 701, configured to receive an SDK call request sent by a target service party of an application, where the SDK call request indicates to call a target SDK in at least one second SDK of the application, where the target SDK is called depending on a parameter; the second SDK is different from the first SDK;

a target class name obtaining unit 702, configured to query a registration list pre-generated in the first SDK when the application is started, and obtain a target class name of the target SDK; the registration list comprises registration information of each second SDK in at least one second SDK, and the registration information of the second SDK indicates the class name of the second SDK;

the SDK invoking unit 703 is configured to transmit the parameter to the target SDK according to the target class name, and trigger the target SDK to respond to the execution command indicated by the parameter execution command.

Further, an SDK invoking apparatus provided in an embodiment of the present application further includes: and the execution result returning unit is used for returning the execution result of the execution command returned by the target SDK to the target service party based on the function pointer if the parameters also comprise the function pointer for calling back the execution result.

In this embodiment of the present application, preferably, the parameter further indicates a target resource in a target SDK requested to be called, and correspondingly, the SDK calling apparatus further includes a multithread management unit, where the multithread management unit includes:

the resource calling request sending unit is used for sending a resource calling request to the target SDK according to the target class name, and the resource calling request indicates a target resource;

the multithreading information receiving unit is used for receiving multithreading information returned by the target SDK responding to the resource calling request;

the mutual exclusion lock construction unit is used for constructing a mutual exclusion lock if the multithreading information represents that the target resource does not support multithreading;

correspondingly, the SDK invoking unit is specifically configured to, if the multithreading information indicates that the target resource supports multithreading, transmit the parameter to the target SDK according to the target class name, and trigger the target SDK to respond to the execution command indicated by the parameter execution instruction.

In this embodiment of the application, preferably, the first SDK integrates a pthread framework, and the mutual exclusion lock constructing unit includes:

a header file importing unit for importing a pthread.h header file;

the exclusive lock constructing subunit is used for initializing the attribute of the exclusive lock, creating an exclusive lock object and transmitting the attribute address and the exclusive lock object address into an init method;

and the locking unit is used for calling the trial locking function to transfer the exclusive lock object address into the locking unit.

In the embodiment of the present application, preferably, the SDK invoking unit is specifically configured to invoke a getDataWithParam method to transmit the parameter to the target SDK according to the target class name, and trigger the target SDK to respond to the execution command indicated by the parameter execution command.

Correspondingly, the SDK calling method provided in the embodiment of the present application further includes a mutual exclusion lock unlocking unit, configured to unlock the mutual exclusion lock after the getDataWithParam method is executed and an unlocking function is called.

Further, the SDK invoking device provided in the embodiment of the present application further includes a cache management unit, configured to store the SDK invoking request to a cache queue.

Correspondingly, the target class name acquisition unit comprises:

the SDK calling request determining unit is used for determining the SDK calling request to be processed currently in the cache queue based on the preset priority of the service party in the application program;

and the target class name acquisition subunit is used for inquiring a registration list pre-generated in the first SDK when the application program is started, and acquiring the target class name of the target SDK indicated by the current SDK calling request to be processed.

Further, an SDK invoking device provided in an embodiment of the present application further includes a registration list generating unit, where the registration list generating unit includes:

the registration method providing unit is used for responding to the starting of the application program and providing a registration method for the outside, wherein the registration method carries a first parameter and a second parameter, the first parameter indicates the SDK identification of the SDK, and the second parameter indicates the class name of the SDK;

the information receiving unit is used for receiving the SDK identification and the class name of the second SDK transmitted from the first SKD by the registration method when the second SDK responds to the starting of the application program for initialization;

and the registration unit is used for generating registration information of a second SDK used for storing the registration list according to the SDK identification and the class name.

As shown in fig. 8, a structure diagram of an implementation manner of a computer device provided in the embodiment of the present application is provided, where the computer device may be the electronic device described above, and the computer device includes:

a memory 801 for storing programs;

a processor 802 for executing a program, the program specifically for:

receiving an SDK calling request sent by a target service party of an application program, wherein the SDK calling request indicates to call a target SDK in at least one second SDK of the application program, and the target SDK is called depending on parameters; the second SDK is different from the first SDK;

inquiring a registration list pre-generated in the first SDK when the application program is started to obtain a target class name of the target SDK; the registration list comprises registration information of each second SDK in at least one second SDK, and the registration information of the second SDK indicates the class name of the second SDK;

and transmitting the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the execution command indicated by the parameter execution instruction.

The processor 802 may be a central processing unit CPU or an Application Specific Integrated Circuit (ASIC).

The control device may further comprise a communication interface 803 and a communication bus 804, wherein the memory 801, the processor 802 and the communication interface 803 communicate with each other via the communication bus 804.

The embodiment of the present application further provides a readable storage medium, where a computer program is stored, and the computer program is loaded and executed by a processor to implement the steps of the SDK calling method, where a specific implementation process may refer to descriptions of corresponding parts in the foregoing embodiment, and details are not described in this embodiment.

The present application also proposes a computer program product or a computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instruction from the computer-readable storage medium, and executes the computer instruction, so that the computer device executes the methods provided in the various optional implementation manners in the SDK invoking method aspect or the SDK invoking apparatus aspect.

The application provides an SDK calling method, an SDK calling device, computer equipment and a storage medium, which are applied to a first SDK in an application program, wherein the first SDK receives an SDK calling request sent by a target service party of the application program, the SDK calling request indicates to call a target SDK in at least one second SDK of the application program, and the target SDK is called depending on parameters, and the second SDK is different from the first SDK; inquiring a registration list pre-generated in the first SDK when the application program is started to obtain a target class name of the target SDK; and then the parameters are transmitted to the target SDK according to the target class name, so that the target SDK can be triggered to respond to the execution command indicated by the parameter execution parameters. According to the method and the system, the required service can be realized only by loading the SDK with the required function according to the requirement by different access parties, and customized development is not required for different access parties, so that the development workload is reduced, and the development efficiency is improved. According to the method and the device, decoupling between the SDKs can be achieved, mutual dependence between the SDKs is removed by trying to acquire data and distribute messages through an engine module of the SDK, and based on the problem of removing the mutual dependence between the SDKs, access cost is reduced, and the effect of high cohesion and low coupling of software design is achieved.

The SDK calling method, the SDK calling device, the computer device, and the storage medium provided by the present invention are described in detail above, and a specific example is applied in the present disclosure to explain the principle and the implementation of the present invention, and the description of the above embodiment is only used to help understanding the method and the core idea of the present invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.

It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other. The device disclosed in the embodiment corresponds to the method disclosed in the embodiment, so that the description is simple, and the relevant points can be referred to the description of the method part.

It is further noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include or include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An SDK calling method, applied to a first SDK in an application, includes:

2. The method of claim 1, further comprising:

and if the parameters further comprise a function pointer for performing execution result callback, returning the execution result of the execution command returned by the target SDK based on the function pointer to the target service party.

3. The method of claim 1, wherein the parameter further indicates a target resource in the target SDK that requested invocation, the method further comprising:

sending a resource calling request to the target SDK according to the target class name, wherein the resource calling request indicates the target resource;

receiving multithreading information returned by the target SDK responding to the resource calling request;

if the multithreading information represents that the target resource does not support multithreading, constructing a mutual exclusion lock;

the transmitting the parameter to the target SDK according to the target class name, and triggering the target SDK to respond to the parameter to execute the execution command indicated by the parameter includes: and if the multithreading information represents that the target resource supports multithreading, transmitting the parameter to the target SDK according to the target class name, and triggering the target SDK to respond to the parameter to execute the execution command indicated by the parameter.

4. The method of claim 3, wherein the first SDK integrates a pthread framework, and wherein constructing the mutual exclusion lock comprises:

importing a pthread.h header file;

initializing the attribute of a mutual exclusion lock, creating a mutual exclusion lock object, and transmitting the attribute address and the address of the mutual exclusion lock object into an init method;

calling an attempt locking function to transfer the mutually exclusive lock object address into the lock system.

5. The method of claim 4, wherein the transmitting the parameter to the target SDK according to the target class name, and wherein triggering the target SDK to execute the execution command indicated by the parameter in response to the parameter comprises: calling a getDataWithParam method to transmit the parameters to the target SDK according to the target class name, and triggering the target SDK to respond to the parameters to execute the execution command indicated by the parameters; the method further comprises the following steps:

and after the getDataWithParam method is executed and an unlocking function is called, the mutual exclusion lock is unlocked.

6. The method of claim 1, further comprising:

storing the SDK calling request to a cache queue;

the querying a registration list pre-generated in the first SDK when the application program is started to obtain a target class name of the target SDK, and the method comprises the following steps:

determining the current SDK calling request to be processed in the cache queue based on the preset priority of the service party in the application program;

and querying a registration list pre-generated in the first SDK when the application program is started, and acquiring a target class name of a target SDK indicated by the current SDK calling request to be processed.

7. The method of claim 1, wherein the method for generating the registration list comprises:

responding to the starting of the application program, and providing a registration method for the outside, wherein the registration method carries a first parameter and a second parameter, the first parameter indicates an SDK (software development kit) identifier of the SDK, and the second parameter indicates a class name of the SDK;

when the second SDK responds to the start of the application program for initialization, the SDK identification and the class name of the second SDK, which are transmitted to the first SKD by the registration method, are called;

and generating the registration information of the second SDK for storing the registration list according to the SDK identification and the class name.

8. An SDK calling apparatus, applied to a first SDK in an application, the apparatus comprising:

9. A computer device, comprising: the system comprises a processor and a memory, wherein the processor and the memory are connected through a communication bus; the processor is used for calling and executing the program stored in the memory; the memory for storing a program for implementing the SDK call method of any one of claims 1-7.

10. A computer-readable storage medium, having stored thereon a computer program, which, when loaded and executed by a processor, carries out the steps of the SDK call method according to any one of claims 1 to 7.