SDK (Software Development Kit) dynamic integration method, device and equipment and readable storage medium

Abstract

The invention discloses an SDK (Software Development Kit) dynamic integration method, device and equipment and a readable storage medium, and relates to the technical field of software development, and the method comprises the following steps: after receiving an SDK loading instruction, analyzing the SDK loading instruction to obtain a first analysis result, and determining a class file storage path corresponding to a target loading SDK according to the first analysis result; loading a target SDK class file corresponding to the class file storage path according to a preset loading process template; instantiating the loaded target SDK file through a JAVA reflection mechanism to obtain a first instance corresponding to the target SDK file; and obtaining an identification code corresponding to the target loading SDK, obtaining metadata information in the target SDK class file, and registering the identification code corresponding to the target loading SDK, the first instance and the metadata information in a preset registry. According to the method, the SDK integration efficiency can be improved, and integration errors are reduced.

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to an SDK dynamic integration method, device, equipment and readable storage medium. Background Art

[0002] In modern software development, a software development kit is a set of tools, libraries, and documentation that provides specific functionality or services. These toolkits are usually created by third-party providers and can simplify the implementation of certain complex tasks, such as payment processing, mapping services, social media integration, etc.

[0003] Each SDK (Software Development Kit) has its own unique API (Application Programming Interface) design and architecture. Even if they are adding similar functions, there may be significant differences between different SDKs. Therefore, during the integration process, the code usually needs to be adjusted according to specific needs to ensure that the new functions can be seamlessly integrated into the existing system. This customization work is not only time-consuming, but after completing all necessary development and testing, the application containing the new SDK needs to be deployed to the production environment. At this stage, a series of operations such as configuration updates and permission settings may be involved. The slightest carelessness may lead to service interruptions or other adverse consequences. Therefore, the current SDK integration process requires independent development, testing, and online steps for each SDK, which easily leads to low SDK integration efficiency and error-prone integration process.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a SDK dynamic integration method, device, equipment and readable storage medium, aiming to solve the technical problems of errors or low efficiency in the SDK integration process.

[0006] To achieve the above purpose, the present application proposes a SDK dynamic integration method, which includes: After receiving the SDK loading instruction, the SDK loading instruction is parsed to obtain a first parsing result, and a class file storage path corresponding to the target loading SDK is determined according to the first parsing result; Load the target SDK class file corresponding to the class file storage path according to the preset loading process template; Instantiate the loaded target SDK class file through a JAVA reflection mechanism to obtain a first instance corresponding to the target SDK class file; Obtaining an identification code corresponding to the target loading SDK, obtaining metadata information in the target SDK class file, and registering the identification code corresponding to the target loading SDK, the first instance, and the metadata information in a preset registration table; After the identification code corresponding to the target loading SDK, the first instance, and the metadata information are successfully registered, it is determined that the target loading SDK is successfully loaded.

[0007] In one embodiment, before the step after receiving the SDK loading instruction, the step further includes: Creating a preset class loader, and writing a loading process template into the preset class loader, wherein the loading process template includes a process template for loading an SDK class file from a specified location; The step of loading the target SDK class file corresponding to the class file storage path according to the preset loading process template includes: Instantiating the preset class loader to obtain a second instance corresponding to the preset class loader; Obtaining a preset loading process template corresponding to the second instance; The class file storage path is used as an input parameter of the loading process template, and the target SDK class file corresponding to the target loading SDK is loaded by controlling the second instance to execute the loading process template.

[0008] In one embodiment, before the step after receiving the SDK loading instruction, the step further includes: Constructing an SDK loading environment, wherein the SDK loading environment includes an SDK class file storage directory and a preset registry, the SDK class file storage directory stores all SDK class files that need to be loaded, the SDK class file storage directory contains the class file storage path of each SDK, and the preset registry is used to store the first instance corresponding to the loaded SDK and the corresponding metadata information; Determine at least one SDK class file that needs to be stored, create a subdirectory corresponding to each SDK class file under the SDK class file storage directory, define a class file storage path corresponding to each SDK class file according to each subdirectory, and store each SDK class file in the corresponding class file storage path.

[0009] In one embodiment, after the step of determining that the target SDK is loaded successfully, the method further includes: If an SDK calling instruction is received, the SDK calling instruction is parsed to obtain a second parsing result, wherein the second parsing result includes an identification code of a target calling SDK corresponding to the SDK calling instruction, a calling function name and calling parameters corresponding to the target calling SDK; Obtaining a first instance corresponding to the target calling SDK from the preset registration table according to the identification code of the target calling SDK; Using the calling parameter as an input parameter for executing the process template, calling the first instance based on the JAVA reflection mechanism to execute the process template corresponding to the calling function name, and obtaining an execution result; The execution result is outputted.

[0010] In one embodiment, after the step of determining that the target SDK is loaded successfully, the method further includes: If an SDK offline instruction is received, the SDK offline instruction is parsed to obtain a third parsing result, wherein the third parsing result includes an identification code of a target offline SDK corresponding to the SDK offline instruction; Remove the identification code, the first instance and the metadata information corresponding to the target offline SDK from the preset registration table according to the identification code corresponding to the target offline SDK; After the first instance and metadata information corresponding to the target offline SDK are successfully removed, it is determined that the target offline SDK is successfully offline.

[0011] In one embodiment, after the step of obtaining the third analysis result, the method further includes: Obtain a third instance, wherein the third instance is a preset instance used for unified management of all SDKs; Obtaining a preset offline process template corresponding to the third instance, wherein the preset offline process template includes a resource release process template, an event monitoring cancellation process template, a service stop process template, and a log storage process template; The identification code corresponding to the target offline SDK is used as an input parameter of the preset offline process template, and the preset third instance is called based on the JAVA reflection mechanism to execute the preset offline process template.

[0012] In one embodiment, after the step of determining that the target SDK is loaded successfully, the method further includes: Periodically obtain metadata information of all stored SDKs from the preset registry, wherein the metadata information includes SDK version numbers and SDKs to be upgraded corresponding to each SDK; Sending a latest version query request to the remote server addresses corresponding to all stored SDKs in the registry, and receiving the latest version number corresponding to each stored SDK returned by each remote server; For each stored SDK, compare the corresponding SDK version number with the latest version number, and determine the SDK to be upgraded whose SDK version number is lower than the latest version number; Remove the identification code, the first instance and the metadata information corresponding to each SDK to be upgraded from the preset registration table, and delete the SDK class file corresponding to each SDK to be upgraded; Obtain the latest version of the SDK upgrade file corresponding to each SDK to be upgraded from the remote server address corresponding to each SDK to be upgraded, and replace the SDK class file corresponding to each SDK to be upgraded with the SDK upgrade file; Take each SDK to be upgraded as the target loading SDK, take each SDK upgrade file as the target SDK class file, and obtain the class file storage path of each SDK upgrade file, and return to the execution step: obtain the preset loading process template, and load the target SDK class file corresponding to the class file storage path by executing the loading process template.

[0013] In addition, to achieve the above purpose, the present application also proposes an SDK dynamic integration device, the SDK dynamic integration device comprising: The instruction module is used to parse the SDK loading instruction after receiving it, obtain a first parsing result, and determine the class file storage path corresponding to the target loading SDK according to the first parsing result; A loading module, used to load the target SDK class file corresponding to the class file storage path according to a preset loading process template; An instantiation module, used to instantiate the loaded target SDK class file through a JAVA reflection mechanism to obtain a first instance corresponding to the target SDK class file; A registration module, used to obtain an identification code corresponding to the target loading SDK, obtain metadata information in the target SDK class file, and register the identification code corresponding to the target loading SDK, the first instance, and the metadata information in a preset registration table; The end module is used to determine that the target loading SDK is loaded successfully after the identification code corresponding to the target loading SDK, the first instance and the metadata information are successfully registered.

[0014] In addition, to achieve the above objectives, the present application also proposes an SDK dynamic integration device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the SDK dynamic integration method described above.

[0015] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the SDK dynamic integration method described above are implemented.

[0016] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the SDK dynamic integration method described above are implemented.

[0017] This application parses the SDK loading instruction after receiving the SDK loading instruction to obtain the first parsing result, and determines the class file storage path corresponding to the target loading SDK according to the first parsing result; loads the target SDK class file corresponding to the class file storage path according to the preset loading process template; instantiates the loaded target SDK class file through the JAVA reflection mechanism to obtain the first instance corresponding to the target SDK class file; obtains the identification code corresponding to the target loading SDK, obtains the metadata information in the target SDK class file, and registers the identification code, the first instance and the metadata information corresponding to the target loading SDK in the preset registration table; after the identification code, the first instance and the metadata information corresponding to the target loading SDK are successfully registered, it is determined that the target loading SDK is loaded successfully. This embodiment uses dynamic loading and reflection technology to enable the system to flexibly respond to the needs of different SDKs, support on-demand loading and immediate effectiveness, and the SDK can be directly called after uploading. Due to the templated loading process and reflection mechanism, there is no need to perform repeated development work such as multiple customization, testing, and release and online when integrating the SDK, which simplifies the maintenance and upgrade process, thereby improving the efficiency of SDK integration and reducing the possibility of SDK integration errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 A flowchart of the first embodiment of the SDK dynamic integration method of this application is provided; Figure 2 A flowchart of the second embodiment of the SDK dynamic integration method of this application is provided; Figure 3 A flowchart of the third embodiment of the SDK dynamic integration method of this application is provided; Figure 4 A flowchart of the fourth embodiment of the SDK dynamic integration method of this application is provided; Figure 5This is a schematic diagram of the module structure of the SDK dynamic integration device according to the embodiment of the present application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the SDK dynamic integration method in the embodiment of the present application.

[0021] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0022] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0023] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0024] It should be noted that the execution subject of this embodiment may be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, an application program, etc. The following takes an application program as an example to illustrate this embodiment and the following embodiments.

[0025] Based on this, the present application embodiment provides a SDK dynamic integration method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the SDK dynamic integration method of the present application.

[0026] In this embodiment, the SDK dynamic integration method includes steps S10 to S50: Step S10, after receiving the SDK loading instruction, the SDK loading instruction is parsed to obtain a first parsing result, and a class file storage path corresponding to the target loading SDK is determined according to the first parsing result.

[0027] It should be noted that this embodiment is applied to an application, and the SDK loading instruction may come from a user interface, a configuration file, an API call or other triggering mechanism, and the SDK loading instruction may include information such as the name of the SDK (unique identifier), the version number of the SDK, and the storage path of the SDK class files. Depending on the design and usage scenario of the application, the SDK loading instruction may be received in a variety of situations. For example, the user manually selects and triggers the loading of the SDK through the graphical user interface or command line interface of the application, or the application reads the configuration file at startup and automatically loads the required SDK according to the information in the configuration file, or when certain events occur, the system automatically triggers the loading of the SDK, or the application periodically checks and loads or updates the SDK according to a preset schedule.

[0028] Specifically, the loading instruction is parsed to extract the necessary information. Based on the parsed information, especially the storage path, the specific location of the target loading SDK is determined, avoiding the errors that may be caused by manually configuring the path. Since it supports dynamic loading of different SDKs, there is no need to hard-code a specific SDK path. The required SDK can be loaded at any time according to actual needs, without the need to pre-load all possible SDKs, which improves the flexibility of the system.

[0029] It can be understood that by parsing the received SDK loading instructions and determining the class file storage path corresponding to the target loading SDK based on the parsing results, it is ensured that the SDK can be correctly located and loaded, laying the foundation for subsequent loading, instantiation and registration processes.

[0030] In a feasible implementation manner, before step S10, steps S01-S02 are also included: Step S01, construct an SDK loading environment, wherein the SDK loading environment includes an SDK class file storage directory and a preset registry, the SDK class file storage directory stores all SDK class files that need to be loaded, the SDK class file storage directory contains the class file storage path of each SDK, and the preset registry is used to store the first instance corresponding to the loaded SDK and the corresponding metadata information.

[0031] Specifically, determine the path and structure of the SDK class file storage directory, and determine the data structure of the preset registry. The preset registry is usually a Map structure, with the key being the SDK identification code and the value being an object containing instance and metadata information.

[0032] It can be understood that the necessary directory structure and data structure are created to provide a centralized location to store all SDK class files that need to be loaded, and the preset registry is used to manage the loaded SDK instances and their metadata information, providing a basis for subsequent SDK loading. By building this environment, it can be ensured that the subsequent loading, instantiation, and registration processes can proceed smoothly.

[0033] Step S02, determine at least one SDK class file that needs to be stored, create a subdirectory corresponding to each SDK class file under the SDK class file storage directory, define the class file storage path corresponding to each SDK class file according to each subdirectory, and store each SDK class file in the corresponding class file storage path.

[0034] Specifically, first, you need to clarify which SDKs and their related files will be integrated into the current project. According to the project requirements, determine which functions or services need to be integrated, and then select the corresponding SDK. You can download the required SDK package from official channels or other trusted sources, including .jar files, native libraries (such as .so files), resource files, etc. If the SDK is provided in a compressed format (such as .zip), you need to decompress it first.

[0035] In step S01, a general SDK class file storage directory has been determined, such as / path / to / project / sdk / . Create a separate subdirectory for each SDK to be integrated. The subdirectory name is usually named after the SDK name, and a version number can be appended to distinguish different versions. For example: subdirectories my-sdk-1.0.0 / and another-sdk-2.0.0 / .

[0036] Based on the created subdirectory structure, define the specific path to each SDK class file. These paths can be absolute or relative, depending on how the project is configured. For example: / path / to / project / sdk / my-sdk-1.0.0 / lib / classes.jar and / path / to / project / sdk / my-sdk-1.0.0 / native / libnative.so.

[0037] Copy the unzipped SDK files to the corresponding subdirectories, making sure the file names and paths are consistent with what your application expects. For example, copy the MySDK .jar file and native library files to / path / to / project / sdk / my-sdk-1.0.0 / lib / and / path / to / project / sdk / my-sdk-1.0.0 / native / respectively.

[0038] Step S20, loading the target SDK class file corresponding to the class file storage path according to the preset loading process template.

[0039] It should be noted that the loading process template is a predefined and standardized loading process. The template is usually a loading method in a custom class loader. The specific process is usually to create a custom class loader, and then use the class loader to load the class file under the specified path, check whether the class file is successfully loaded, handle possible exceptions, and finally record the log information of the loading process to facilitate subsequent debugging and auditing.

[0040] It can be understood that loading the target SDK class file corresponding to the class file storage path according to the preset loading process template ensures that the SDK class file can be loaded according to a unified standard and process, thereby improving the stability and consistency of the system.

[0041] In a feasible implementation manner, before step S10, step S03 is further included: Step S03, creating a preset class loader, and writing a loading process template into the preset class loader, wherein the loading process template includes a process template for loading an SDK class file from a specified location.

[0042] It should be noted that in Java, the class loader is responsible for loading class files into the JVM. By inheriting the ClassLoader class and implementing the findClass method, you can create a custom class loader to load classes from a specified location. The preset class loader is the custom class loader, and the rewritten findClass method is equivalent to the loading process template. The findClass method is used to load classes from a specified location.

[0043] It is understandable that, through the loading process template written by the preset class loader, classes can be dynamically loaded from the specified location, supporting loading from the file system, network or other data sources, and classes can also be loaded as needed at runtime without recompiling and deploying the entire application. It also supports loading classes from non-standard paths, which is suitable for scenarios such as plug-in systems and modular applications, providing flexibility for SDK integration.

[0044] Step S20 may include steps S21 to S23: Step S21, instantiate the preset class loader to obtain a second instance corresponding to the preset class loader.

[0045] Specifically, the preset class loader class obtained in step S03 uses a reflection mechanism or other means to obtain an object of the preset class loader class, and uses the reflection mechanism to create an instance of the preset class loader class.

[0046] It is understandable that the reflection mechanism can dynamically create class loader instances at runtime, providing greater flexibility, and the class loader can be instantiated and used immediately after it is defined, without the need to recompile and deploy the entire application.

[0047] Step S22: obtaining a preset loading process template corresponding to the second instance.

[0048] It should be noted that since a method, namely, loading the process template, has been written in the preset class loader class for executing the loading process, after creating an instance corresponding to the preset class loader class, the loading process template can be obtained first through the instance.

[0049] Step S23, taking the class file storage path as an input parameter of the loading process template, and controlling the second instance to execute the loading process template to load the target SDK class file corresponding to the target loading SDK.

[0050] The storage path of the class file to be loaded is obtained from step S10, and the class file storage path is used as an input parameter for loading the process template. The loading process is executed by calling the method for loading the process template.

[0051] This embodiment adds step S02 before step S10 to create a preset class loader and writes the loading process template into it. Then, in step S20, the preset class loader is instantiated and the loading process template is used to load the target SDK class file, ensuring that all SDKs are loaded according to the same process, reducing errors caused by different loading methods, and improving the standardization and maintainability of the loading process.

[0052] Step S30, instantiating the loaded target SDK class file through the JAVA reflection mechanism to obtain a first instance corresponding to the target SDK class file.

[0053] It should be noted that the JAVA reflection mechanism is a powerful function provided by the Java language, which allows a running Java program to check itself and can "reflect" (i.e. dynamically) manipulate internal properties. Through reflection, you can obtain class information (such as class name, method, field, etc.) at runtime, and you can create objects, call methods, and access fields without knowing this information at compile time. Therefore, based on the JAVA reflection mechanism, the specific class and method to be used can be determined at runtime without being determined at compile time. Therefore, object instances can be created at runtime without knowing the specific class at compile time, allowing applications to flexibly load and use different SDKs, greatly enhancing the flexibility, maintainability, and extensibility of SDK dynamic integration.

[0054] It can be understood that in this embodiment, the application can directly load the corresponding SDK after receiving the SDK loading instruction while it is still running, and instantiate the loaded target SDK class file through the Java reflection mechanism to obtain the first instance corresponding to the target SDK class file, thereby ensuring that the SDK dynamically creates objects at runtime, thereby improving the flexibility and scalability of the system.

[0055] Step S40, obtaining an identification code corresponding to the target loading SDK, obtaining metadata information in the target SDK class file, and registering the identification code corresponding to the target loading SDK, the first instance and the metadata information in a preset registration table.

[0056] It should be noted that after receiving the SDK loading instruction, the identification code of the target SDK can be obtained according to the SDK loading instruction or the target SDK class file. The identification code is usually a string that uniquely identifies the SDK. At the same time, metadata information is read from the target SDK class file. The metadata information usually includes version number, author, description, dependencies, etc. The preset registry can be a Map structure, with the key being the identification code and the value being an object containing instance and metadata information. The identification code, the first instance, and the metadata information of the target loading SDK need to be registered in the registry. Key information of the registration process can also be recorded, including the registered identification code, metadata information, registration status, etc.

[0057] It is understandable that the identification code and metadata information of the target loaded SDK are obtained, and these information are registered together with the first instance of the SDK in a preset registration table to ensure that the SDK information can be centrally managed and queried.

[0058] Step S50, after the identification code, the first instance and the metadata information corresponding to the target loading SDK are successfully registered, it is determined that the target loading SDK is loaded successfully.

[0059] Specifically, it is necessary to confirm that the identification code, the first instance and the metadata information of the target SDK loading have been successfully registered in the preset registration table. In addition, it is also necessary to record the log information of the successful loading, including the SDK identification code, the loading time, etc.

[0060] It is understandable that after the identification code, the first instance, and the metadata information of the target SDK are successfully registered in the preset registry, it can be confirmed that the target SDK is loaded successfully, ensuring the integrity and correctness of the entire loading process, and providing clear status feedback of the SDK loading. If the application has a user interface, prompt the user through the UI that the SDK is loaded successfully. If any exceptions occur in the previous steps, catch and handle these exceptions. Implement a retry mechanism as needed to try to reload the SDK.

[0061] After receiving the SDK loading instruction, this embodiment parses the SDK loading instruction to obtain the first parsing result, determines the class file storage path corresponding to the target loading SDK according to the first parsing result; loads the target SDK class file corresponding to the class file storage path according to the preset loading process template; instantiates the loaded target SDK class file through the JAVA reflection mechanism to obtain the first instance corresponding to the target SDK class file; obtains the identification code corresponding to the target loading SDK, obtains the metadata information in the target SDK class file, registers the identification code, the first instance and the metadata information corresponding to the target loading SDK in the preset registration table; after the identification code, the first instance and the metadata information corresponding to the target loading SDK are successfully registered, it is determined that the target loading SDK is loaded successfully. This embodiment uses dynamic loading and reflection technology to enable the system to flexibly respond to the needs of different SDKs, support on-demand loading and immediate effectiveness, and the SDK can be directly called after uploading. Due to the templated loading process and reflection mechanism, there is no need to perform repeated development work such as multiple customized card methods, testing, and release and launch when integrating the SDK, which simplifies the maintenance and upgrade process, thereby improving the efficiency of SDK integration and reducing the error of SDK integration.

[0062] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 2 After step S50, the SDK dynamic integration method further includes steps A10 to A40: Step A10, if an SDK calling instruction is received, the SDK calling instruction is parsed to obtain a second parsing result, wherein the second parsing result includes an identification code of the target calling SDK corresponding to the SDK calling instruction, a calling function name and calling parameters corresponding to the target calling SDK.

[0063] It should be noted that the SDK call instruction from the application or other components is monitored and received, for example, through a network request, a message queue, or a direct method call. The format of the SDK call instruction is determined. Usually the instruction is a string containing information such as an identification code, a function name, and parameters.

[0064] In addition, after obtaining the parsing results, the identification code, function name and parameters need to be verified to ensure that the extracted identification code is valid and exists in the preset registry, that the extracted function name exists in the target SDK, and that the extracted parameters conform to the expected input format of the target function.

[0065] Step A20, obtaining a first instance corresponding to the target calling SDK from a preset registration table according to the identification code of the target calling SDK.

[0066] Specifically, the identification code of the target calling SDK parsed in step A10 can be used to search for the corresponding SDK instance from the registry according to the SDK identification code, because the preset registry stores all loaded SDK instances.

[0067] Step A30, using the calling parameter as the input parameter of the execution process template, calling the first instance to execute the process template corresponding to the calling function name based on the JAVA reflection mechanism, and obtaining the execution result.

[0068] It should be noted that there are multiple calling methods in the SDK class corresponding to the first instance, corresponding to calling templates of multiple functions. The calling function name can be obtained in the SDK calling instruction. In each calling template, there is a process template with the same name as the calling function, which is used to execute various functions. Due to different functions, the required input parameters are different. Therefore, you can first obtain the process template from the class according to the calling function name, and then obtain the process template corresponding to the required calling function name, and control the first instance to execute the process template to obtain the corresponding execution result.

[0069] Step A40, outputting the execution result.

[0070] In this embodiment, when an SDK call instruction is received, the instruction will be parsed to obtain relevant parameters, and the corresponding SDK function will be called through the JAVA reflection mechanism based on these parameters, ensuring that the SDK function can be called on demand and return the execution result. Through the reflection mechanism, dynamic calling of different SDK functions is supported, and new SDK functions can be quickly added without modifying the existing code structure, thereby improving the flexibility of the system.

[0071] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 Before and after step S50, the SDK dynamic integration method further includes steps B10 to B30: Step B10: If an SDK offline instruction is received, the SDK offline instruction is parsed to obtain a third parsing result, wherein the third parsing result includes an identification code of a target offline SDK corresponding to the SDK offline instruction.

[0072] Specifically, the SDK offline instruction from the application or other components is monitored and received, and the identification code corresponding to the SDK to be uninstalled can be obtained by parsing the SDK offline instruction.

[0073] In a feasible implementation manner, after step B10, steps C10 to C30 are further included: Step C10, obtaining a third instance, wherein the third instance is a preset instance used for unified management of all SDKs.

[0074] It should be noted that before starting, you need to define a class or interface as the central controller for unified management by the SDK, and instantiate the class to obtain the third instance. The singleton pattern is usually used to ensure that there is only one instance globally, and a static method is provided to obtain the third instance.

[0075] Step C20, obtaining a preset offline process template corresponding to the third instance, wherein the preset offline process template includes a resource release process template, an event monitoring cancellation process template, a service stop process template, and a log storage process template.

[0076] It should be noted that a preset offline process template (i.e., method) is defined in the class or interface managed by the SDK, and sub-process templates are defined in the offline process template, including a resource release process template, an event listener cancellation process template, a service stop process template, and a log storage process template, which are responsible for releasing all resources related to the SDK, such as memory, file handles, etc., canceling all event listeners registered by the SDK, stopping all background services provided by the SDK, and recording information related to the SDK offline in the log.

[0077] It is understandable that the preset offline process template corresponding to the third instance (i.e., the unified management instance) is obtained in the SDK offline operation, and the template contains multiple sub-process templates for executing operations such as resource release, event monitoring cancellation, service stop, and log storage. This process can systematically execute a series of necessary cleanup and shutdown operations when the SDK is offline.

[0078] Step C30: using the identification code corresponding to the target offline SDK as an input parameter of the preset offline process template, and calling the preset third instance based on the JAVA reflection mechanism to execute the preset offline process template.

[0079] Get the identification code of the target offline SDK from the previous step, get the method object (preset offline process template) according to the method name and parameter type in the preset offline process template, call the obtained method object, and pass in the preset third instance and SDK identification code to execute the corresponding method object.

[0080] Step B20: removing the identification code, the first instance and metadata information corresponding to the target offline SDK from the preset registration table according to the identification code corresponding to the target offline SDK.

[0081] Get the identification code of the target SDK to be offline from the previous step. The preset registry is usually a data structure that stores SDK information, including the loaded SDK instance and its metadata information. Therefore, in the offline SDK step, it is necessary to remove the identification code of the target SDK and its corresponding instance and metadata information from the preset registry. By promptly removing unused SDK instances, system resources can be released and performance can be improved.

[0082] Step B30, after the first instance and metadata information corresponding to the target offline SDK are successfully removed, it is determined that the target offline SDK is successfully offline.

[0083] Specifically, to verify the removal result, you need to check the registry to confirm that the identification code, first instance, and metadata information of the target offline SDK have been removed from the preset registry. If all relevant information has been successfully removed, you can set a flag or update the status to indicate that the SDK has been successfully offline. At the same time, you can record a log to record the information of the successful SDK offline, including the SDK identification code, removal time, etc. If necessary, you can send a notification to other components of the system to inform them that the SDK has been successfully offline.

[0084] After determining that the target SDK has been loaded successfully, the system of this embodiment also needs to process the SDK offline operation. When receiving the SDK offline instruction, the method will parse the instruction to obtain relevant parameters and remove the corresponding SDK instance and its metadata information from the preset registry, which can ensure that the SDK that is no longer needed can be safely uninstalled and cleaned up. By dynamically loading and unloading the SDK, the flexibility of the system is improved. At the same time, by promptly removing the SDK instance that is no longer used, system resources are released and performance is improved.

[0085] Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above description, and will not be described in detail later. Figure 4 After step S50, the SDK dynamic integration method further includes steps D10 to D60: Step D10, periodically obtaining metadata information of all stored SDKs from a preset registration table, wherein the metadata information includes the SDK version number and the SDK to be upgraded corresponding to each SDK.

[0086] It should be noted that the execution frequency should be set according to actual needs, and regular inspection and upgrade should be performed. All metadata information of the stored SDKs is obtained by traversing the preset registry, and the current version number of the SDK is extracted from the metadata. If the metadata also includes other upgrade-related information (such as remote server address, last check time, etc.), it should also be extracted. By regularly checking and updating the SDK version, the system functions are kept up to date.

[0087] Step D20, sending a latest version query request to the remote server addresses corresponding to all stored SDKs in the registration table, and receiving the latest version number corresponding to each stored SDK returned by each remote server.

[0088] Specifically, a query request URL is constructed according to the remote server address, and a GET request is sent to the remote server to query the latest version. The remote server responds to the query request and returns the latest version number, and the application receives the latest version number returned by the remote server.

[0089] Step D30 , for each stored SDK, compare the corresponding SDK version number with the latest version number, and determine the SDK to be upgraded whose SDK version number is lower than the latest version number.

[0090] Specifically, traverse the metadata information of all SDKs stored in the preset registry, extract the current version number from the metadata of each SDK, and write a version comparison function to determine the relationship between the version number in the registry and the latest version number. If the current version is lower than the latest version, mark the SDK as to be upgraded, and store the SDK identification code that needs to be upgraded in a list or other appropriate data structure as the SDK to be upgraded.

[0091] Step D40: remove the identification code, the first instance and the metadata information corresponding to each SDK to be upgraded from the preset registration table, and delete the SDK class files corresponding to each SDK to be upgraded.

[0092] It should be noted that if you need to upgrade the SDK, you need to uninstall the SDK to be upgraded first, and then load the SDK for the SDK upgrade file (that is, the new version SDK class file) downloaded after the upgrade.

[0093] Step D50 , obtaining the latest version of the SDK upgrade file corresponding to each SDK to be upgraded from the remote server address corresponding to each SDK to be upgraded, and replacing the SDK class file corresponding to each SDK to be upgraded with the SDK upgrade file.

[0094] It should be noted that for each SDK to be upgraded, a URL for downloading the latest version of the SDK is constructed based on the SDK identification code and the remote server address, and a GET request is sent using a suitable HTTP client library to download the file. At the same time, the target file path is constructed based on the SDK identification code, and a file output stream is created. The downloaded SDK upgrade file is saved in the SDK class file storage directory, in the location where the SDK class file corresponding to the SDK to be upgraded was originally saved, the old SDK class file is deleted, and the newly downloaded file is renamed to the official SDK class file name.

[0095] Step D60, take each SDK to be upgraded as the target loading SDK, take each SDK upgrade file as the target SDK class file, and obtain the class file storage path of each SDK upgrade file, and return to the execution step: obtain the preset loading process template, and load the target SDK class file corresponding to the class file storage path by executing the loading process template.

[0096] It should be noted that after the SDK upgrade file has been successfully saved, the SDK to be upgraded is used as the target SDK to be loaded, and the process returns to the loading step of steps S10 to S50.

[0097] In this embodiment, after determining that the target SDK is loaded successfully, the system needs to regularly check and automatically upgrade the stored SDK. This process includes obtaining metadata information of all stored SDKs from a preset registry, querying a remote server to obtain the latest version number, comparing the current version with the latest version, determining the SDK that needs to be upgraded, removing the old version information, downloading the new version file, and reloading the new version of the SDK. By updating the SDK version in a timely manner, the system functions are kept up to date. At the same time, the upgrade process is also a dynamic upgrade, which can be directly upgraded when the application is running.

[0098] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the SDK dynamic integration method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0099] This application also provides a SDK dynamic integration device, please refer to Figure 5 , the SDK dynamic integration device includes: The instruction module 10 is used to parse the SDK loading instruction after receiving it, obtain a first parsing result, and determine the class file storage path corresponding to the target loading SDK according to the first parsing result; A loading module 20, used to load the target SDK class file corresponding to the class file storage path according to a preset loading process template; An instantiation module 30, configured to instantiate the loaded target SDK class file through a JAVA reflection mechanism to obtain a first instance corresponding to the target SDK class file; A registration module 40, configured to obtain an identification code corresponding to the target loading SDK, obtain metadata information in the target SDK class file, and register the identification code corresponding to the target loading SDK, the first instance, and the metadata information in a preset registration table; The ending module 50 is used to determine that the target loading SDK is loaded successfully after the identification code corresponding to the target loading SDK, the first instance and the metadata information are successfully registered.

[0100] The SDK dynamic integration device provided by the present application adopts the SDK dynamic integration method in the above embodiment, which can solve the technical problems of errors or low efficiency in the SDK integration process. Compared with the prior art, the beneficial effects of the SDK dynamic integration device provided by the present application are the same as the beneficial effects of the SDK dynamic integration method provided by the above embodiment, and the other technical features in the SDK dynamic integration device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0101] The present application provides an SDK dynamic integration device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the SDK dynamic integration method in the above-mentioned embodiment 1.

[0102] Reference below Figure 6 , which shows a schematic diagram of the structure of the SDK dynamic integration device suitable for implementing the embodiment of the present application. The SDK dynamic integration device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The SDK dynamic integration device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0103] like Figure 6As shown, the SDK dynamic integration device may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the SDK dynamic integration device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the SDK dynamic integration device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows the SDK dynamic integration device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0104] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0105] The SDK dynamic integration device provided by the present application adopts the SDK dynamic integration method in the above embodiment, which can solve the technical problems of errors or low efficiency in the SDK integration process. Compared with the prior art, the beneficial effects of the SDK dynamic integration device provided by the present application are the same as the beneficial effects of the SDK dynamic integration method provided by the above embodiment, and the other technical features in the SDK dynamic integration device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0107] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0108] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the SDK dynamic integration method in the above-mentioned embodiment.

[0109] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned SDK dynamic integration method, and can solve the technical problems of errors or low efficiency in the SDK integration process. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the SDK dynamic integration method provided in the above-mentioned embodiment, and will not be repeated here.

[0110] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned SDK dynamic integration method when executed by a processor.

[0111] The computer program product provided by this application can solve the technical problems of errors or low efficiency in the SDK integration process. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the SDK dynamic integration method provided by the above embodiment, which will not be repeated here.

[0112] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A SDK dynamic integration method, characterized in that: The SDK dynamic integration method includes: After receiving the SDK loading instruction, the SDK loading instruction is parsed to obtain a first parsing result, and a class file storage path corresponding to the target loading SDK is determined according to the first parsing result; Load the target SDK class file corresponding to the class file storage path according to the preset loading process template; Instantiate the loaded target SDK class file through a JAVA reflection mechanism to obtain a first instance corresponding to the target SDK class file; Obtaining an identification code corresponding to the target loading SDK, obtaining metadata information in the target SDK class file, and registering the identification code corresponding to the target loading SDK, the first instance, and the metadata information in a preset registration table; After the identification code corresponding to the target loading SDK, the first instance, and the metadata information are successfully registered, it is determined that the target loading SDK is successfully loaded.

2. The SDK dynamic integration method according to claim 1, characterized in that: Before the step after receiving the SDK loading instruction, the step further includes: Creating a preset class loader, and writing a loading process template into the preset class loader, wherein the loading process template includes a process template for loading an SDK class file from a specified location; The step of loading the target SDK class file corresponding to the class file storage path according to the preset loading process template includes: Instantiating the preset class loader to obtain a second instance corresponding to the preset class loader; Obtaining a preset loading process template corresponding to the second instance; The class file storage path is used as an input parameter of the loading process template, and the target SDK class file corresponding to the target loading SDK is loaded by controlling the second instance to execute the loading process template.

3. The SDK dynamic integration method according to claim 2, characterized in that: Before the step after receiving the SDK loading instruction, the step further includes: Constructing an SDK loading environment, wherein the SDK loading environment includes an SDK class file storage directory and a preset registry, the SDK class file storage directory stores all SDK class files that need to be loaded, the SDK class file storage directory contains the class file storage path of each SDK, and the preset registry is used to store the first instance corresponding to the loaded SDK and the corresponding metadata information; Determine at least one SDK class file that needs to be stored, create a subdirectory corresponding to each SDK class file under the SDK class file storage directory, define a class file storage path corresponding to each SDK class file according to each subdirectory, and store each SDK class file in the corresponding class file storage path.

4. The SDK dynamic integration method according to claim 3, characterized in that: After the step of determining that the target SDK is loaded successfully, the method further includes: If an SDK calling instruction is received, the SDK calling instruction is parsed to obtain a second parsing result, wherein the second parsing result includes an identification code of a target calling SDK corresponding to the SDK calling instruction, a calling function name and calling parameters corresponding to the target calling SDK; Obtaining a first instance corresponding to the target calling SDK from the preset registration table according to the identification code of the target calling SDK; Using the calling parameter as an input parameter for executing the process template, calling the first instance based on the JAVA reflection mechanism to execute the process template corresponding to the calling function name, and obtaining an execution result; The execution result is outputted.

5. The SDK dynamic integration method according to claim 4, characterized in that: After the step of determining that the target SDK is loaded successfully, the method further includes: If an SDK offline instruction is received, the SDK offline instruction is parsed to obtain a third parsing result, wherein the third parsing result includes an identification code of a target offline SDK corresponding to the SDK offline instruction; Remove the identification code, the first instance and the metadata information corresponding to the target offline SDK from the preset registration table according to the identification code corresponding to the target offline SDK; After the first instance and metadata information corresponding to the target offline SDK are successfully removed, it is determined that the target offline SDK is successfully offline.

6. The SDK dynamic integration method according to claim 5, characterized in that: After the step of obtaining the third analysis result, the method further includes: Obtain a third instance, wherein the third instance is a preset instance used for unified management of all SDKs; Obtaining a preset offline process template corresponding to the third instance, wherein the preset offline process template includes a resource release process template, an event monitoring cancellation process template, a service stop process template, and a log storage process template; The identification code corresponding to the target offline SDK is used as an input parameter of the preset offline process template, and the preset third instance is called based on the JAVA reflection mechanism to execute the preset offline process template.

7. The SDK dynamic integration method according to claim 6, characterized in that: After the step of determining that the target SDK is loaded successfully, the method further includes: Periodically obtain metadata information of all stored SDKs from the preset registry, wherein the metadata information includes SDK version numbers and SDKs to be upgraded corresponding to each SDK; Sending a latest version query request to the remote server addresses corresponding to all stored SDKs in the registry, and receiving the latest version number corresponding to each stored SDK returned by each remote server; For each stored SDK, compare the corresponding SDK version number with the latest version number, and determine the SDK to be upgraded whose SDK version number is lower than the latest version number; Remove the identification code, the first instance and the metadata information corresponding to each SDK to be upgraded from the preset registration table, and delete the SDK class file corresponding to each SDK to be upgraded; Obtain the latest version of the SDK upgrade file corresponding to each SDK to be upgraded from the remote server address corresponding to each SDK to be upgraded, and replace the SDK class file corresponding to each SDK to be upgraded with the SDK upgrade file; Take each SDK to be upgraded as the target loading SDK, take each SDK upgrade file as the target SDK class file, and obtain the class file storage path of each SDK upgrade file, and return to the execution step: obtain the preset loading process template, and load the target SDK class file corresponding to the class file storage path by executing the loading process template.

8. A SDK dynamic integration device, characterized in that: The SDK dynamic integration device comprises: The instruction module is used to parse the SDK loading instruction after receiving it, obtain a first parsing result, and determine the class file storage path corresponding to the target loading SDK according to the first parsing result; A loading module, used to load the target SDK class file corresponding to the class file storage path according to a preset loading process template; An instantiation module, used to instantiate the loaded target SDK class file through a JAVA reflection mechanism to obtain a first instance corresponding to the target SDK class file; A registration module, used to obtain an identification code corresponding to the target loading SDK, obtain metadata information in the target SDK class file, and register the identification code corresponding to the target loading SDK, the first instance, and the metadata information in a preset registration table; The end module is used to determine that the target loading SDK is loaded successfully after the identification code corresponding to the target loading SDK, the first instance and the metadata information are successfully registered.

9. A SDK dynamic integration device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the SDK dynamic integration method according to any one of claims 1 to 7.

10. A possible storage medium, characterized in that: The possible storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the SDK dynamic integration method according to any one of claims 1 to 7 are implemented.

Images