Multi-host-oriented SDK calling method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of artificial intelligence, is suitable for finance, medical treatment and other scenes, and discloses a multi-host-oriented SDK calling method and device, computer equipment and a storage medium, the method comprises the following steps: identifying a current operation environment, and determining each host type based on the current operation environment; calling and initializing the original SDK of each host; packaging a standard protocol adaptation class for the SDK of each host, and establishing a standard protocol interface based on the standard protocol adaptation class; and establishing an intermediate layer based on the standard protocol interface, responding to a calling request of a service system through the intermediate layer, and then routing and calling to a corresponding host SDK in combination with an operation environment of the service system. According to the method and the system, the capabilities of various host SDKs are uniformly packaged and dynamically adapted, and bridging, dynamic loading and capability mapping are performed on the host SDKs and the service system in a middle layer form, so that the calling compatibility, stability and docking efficiency of the host SDKs can be improved.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to a multi-host SDK calling method, device, computer equipment and storage medium. Background Art

[0002] With the widespread use of digital services, account management services often need to run in multiple different ecosystems, such as WeChat mini-programs and H5 pages related to healthcare and finance. These ecosystems each encapsulate independent container capabilities, and there are differences in the implementation of functions such as login, redirection, resource download, and WebView control. At the same time, the SDKs provided by each ecosystem also show significant differences in input and output parameter calling methods, function granularity, and version compatibility. This makes account management services that need to run uniformly in multiple ecosystems face many technical challenges: (1) The problem of repeated development is prominent. Each business project needs to customize the code for different SDKs, and there is a lack of unified interface standards, resulting in high development costs; (2) The service is highly coupled with the SDK, and SDK upgrades can easily affect the stability of multiple business systems; (3) Frequent SDK docking and inconsistent interface adjustments make it difficult to reuse project adaptation logic and low maintenance efficiency; (4) When the SDK is unavailable or has compatibility issues, the system lacks a smooth degradation mechanism, which affects the user experience. In addition, due to the lack of a complete, standardized and extensible protocol mechanism and dynamic adaptation strategy, it is difficult to fundamentally solve the problem of high adaptation and maintenance costs caused by multiple ecosystems and multiple SDKs. Summary of the Invention

[0003] The embodiments of the present invention provide a multi-host SDK calling method, apparatus, computer equipment and storage medium, aiming to improve the compatibility, stability and docking efficiency of host SDK calling.

[0004] In a first aspect, an embodiment of the present invention provides a multi-host SDK calling method, comprising:

[0005] Identify the current operating environment and determine the host type based on the current operating environment;

[0006] Call the original SDK of each host and initialize it;

[0007] Encapsulate a standard protocol adapter class for each host's SDK and build a standard protocol interface based on the standard protocol adapter class;

[0008] An intermediate layer is built based on the standard protocol interface, and the intermediate layer responds to the call request of the business system through the intermediate layer, and then routes the call to the corresponding host SDK in combination with the operating environment of the business system.

[0009] In a second aspect, an embodiment of the present invention provides a multi-host SDK calling device, comprising:

[0010] An environment identification unit, configured to identify the current operating environment and determine the host type based on the current operating environment;

[0011] Initialization unit, used to call the original SDK of each host and initialize it;

[0012] The encapsulation and construction unit is used to encapsulate the standard protocol adaptation class for each host SDK and build a standard protocol interface based on the standard protocol adaptation class;

[0013] The routing calling unit is used to build an intermediate layer based on the standard protocol interface, respond to the calling request of the business system through the intermediate layer, and then route the call to the corresponding host SDK in combination with the operating environment of the business system.

[0014] In a third aspect, an embodiment of the present invention provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the multi-host SDK calling method as described in the first aspect is implemented.

[0015] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the multi-host oriented SDK calling method as described in the first aspect is implemented.

[0016] An embodiment of the present invention provides a multi-host SDK calling method, apparatus, computer equipment and storage medium, the method comprising: identifying the current operating environment, and determining each host type based on the current operating environment; calling and initializing the original SDK of each host; encapsulating a standard protocol adaptation class for the SDK of each host, and building a standard protocol interface based on the standard protocol adaptation class; building an intermediate layer based on the standard protocol interface, and responding to the calling request of the business system through the intermediate layer, and then routing the call to the corresponding host SDK in combination with the operating environment of the business system. The embodiment of the present invention uniformly encapsulates and dynamically adapts the capabilities of various host SDKs, and uses an intermediate layer to bridge, dynamically load and map the capabilities of the host SDK and the business system. The intermediate layer is used to bridge the upper-level business projects and the underlying multiple host SDKs. It identifies the current environment (APPA / B / C, WeChat, H5, etc.) at runtime and automatically routes the call to the corresponding SDK adaptation module. The business system only needs to call according to the standard protocol without worrying about which host or SDK provides the capability at the bottom. The business system can always use the same interface without frequent code changes. In this way, the strong dependency between the business system and the host SDK can be decoupled, the overall decoupling capability and maintainability can be improved, and the compatibility, stability and docking efficiency of the host SDK call can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1 A schematic diagram of a multi-host SDK calling method provided by an embodiment of the present invention;

[0019] Figure 2 A schematic diagram of a sub-process of a multi-host SDK calling method provided by an embodiment of the present invention;

[0020] Figure 3 Another flowchart of a multi-host SDK calling method provided by an embodiment of the present invention;

[0021] Figure 4 A schematic diagram illustrating a multi-host SDK calling method provided by an embodiment of the present invention;

[0022] Figure 5 An example diagram of a standard protocol for a multi-host SDK calling method provided by an embodiment of the present invention;

[0023] Figure 6 A schematic block diagram of a multi-host SDK calling device provided by an embodiment of the present invention;

[0024] Figure 7 A schematic block diagram of a multi-host SDK calling device provided by an embodiment of the present invention;

[0025] Figure 8 Another schematic block diagram of a multi-host SDK calling device provided by an embodiment of the present invention;

[0026] Figure 9 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0027] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0028] It will be understood that when used in this specification and the appended claims, the terms “comprises” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0029] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the present invention. As used in the specification and appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0030] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0031] The multi-host SDK calling method provided by the embodiment of the present invention can be applied in an application environment where the client and the server interact, wherein the client communicates with the server through a network. The server can identify the current operating environment and determine the type of each host based on the current operating environment; call the original SDK of each host and initialize it; encapsulate the standard protocol adaptation class for the SDK of each host, and build a standard protocol interface based on the standard protocol adaptation class; build an intermediate layer based on the standard protocol interface. The client's business system sends a call request, and the server responds to the call request of the business system through the intermediate layer, and then routes the call to the corresponding host SDK in combination with the operating environment of the business system. Among them, the client can be but is not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0032] See below Figure 1 , an embodiment of the present invention provides a multi-host oriented SDK calling method, which specifically includes: steps S101 to S104.

[0033] Step S101: Identify the current operating environment and determine the host type based on the current operating environment;

[0034] Step S102: calling the original SDK of each host and initializing it;

[0035] Step S103: Encapsulate a standard protocol adapter class for each host's SDK, and build a standard protocol interface based on the standard protocol adapter class;

[0036] Step S104: Building an intermediate layer based on the standard protocol interface, responding to the calling request of the business system through the intermediate layer, and then routing the call to the corresponding host SDK in combination with the operating environment of the business system.

[0037] In this embodiment, the operating environment is first determined and different host types are identified. Next, the host SDKs are called and their native SDKs are initialized. A standard protocol adapter class is then created for each host SDK, establishing a standard protocol interface. Finally, an intermediate layer is constructed to handle service system call requests and route them to the appropriate host SDK based on the service system's operating environment.

[0038] This embodiment uniformly encapsulates and dynamically adapts the capabilities of various host SDKs, and uses an intermediate layer to bridge, dynamically load, and map capabilities between the host SDK and the business system. The intermediate layer is used to bridge the upper-level business projects and the underlying multiple host SDKs. It identifies the current environment (APPA / B / C, WeChat, H5, etc.) at runtime and automatically routes calls to the corresponding SDK adaptation module. The business system only needs to call according to the standard protocol without worrying about which host or SDK provides the capability at the bottom. The business system can always use the same interface without frequent code changes. This can decouple the strong dependency between the business system and the host SDK, improve the overall decoupling capability and maintainability, and thereby improve the compatibility, stability, and docking efficiency of the host SDK call.

[0039] In particular, the multi-host SDK calling method provided in this embodiment is applicable to different business scenarios. For example, in a medical scenario, the medical business system can use the multi-host SDK calling method to achieve efficient and stable interaction with the SDKs of multiple medical ecosystems (such as hospital APPs, medical WeChat applets, etc.). When the medical business system needs to call a certain function, it only needs to send a request to the middle layer in accordance with a unified standard protocol. The middle layer will automatically identify and route to the corresponding host SDK according to the current operating environment to complete the function call. For example, in a financial scenario, the financial business system can use the multi-host SDK calling method to achieve seamless docking with the SDKs of multiple financial ecosystems (such as bank APPs, financial WeChat applets, H5 pages, etc.). When the financial business system needs to perform functions such as transfer, payment, and account balance inquiry, it can follow a unified standard protocol to send the request to the middle layer. The middle layer will intelligently identify the current operating environment and automatically select the most appropriate host SDK for routing calls to ensure efficient and accurate execution of functions.

[0040] In a specific embodiment, in the step of identifying the current operating environment and determining each host type based on the current operating environment, the host type of the current operating environment can be determined by detecting the host's operating environment information, including but not limited to the type, version, device type, browser type, etc. of the operating host. For example, if the operating environment is detected to be a WeChat applet, the host type is determined to be a WeChat applet; if the operating environment is detected to be an H5 page, the host type is determined to be H5, etc. In addition, the host type can be determined in conjunction with the configuration information of the business system, such as a preset host type list, to assist in determining the host type and ensure the accuracy of the identification.

[0041] In the step of calling the original SDK of each host and initializing it, the original SDK of the corresponding host, such as parSdk, is called according to the host type, and initialization operations are performed. The initialization process can include loading the resources required by the SDK, configuring parameters, verifying the validity of the SDK, etc., to ensure that the SDK can work properly. Different initialization strategies can be adopted for different types of hosts. For example, for WeChat applets, initialization can be performed through the API interface provided by WeChat; for H5 pages, initialization can be performed through JavaScript code. During the initialization process, the functions of the SDK can also be tested to ensure that its functions are complete and meet expectations. If the initialization fails or the SDK function is abnormal, corresponding error handling can be performed, such as recording error information, attempting reinitialization or downgrade processing, etc. Through this step, it can be ensured that the original SDK of each host is correctly called and initialized, providing a basis for subsequent standard protocol adaptation and routing calls.

[0042] In the step of encapsulating a standard protocol adapter class for each host SDK and building a standard protocol interface based on the standard protocol adapter class, an adaptation layer is specifically designed for each host SDK. The adaptation layer contains a standard protocol adapter class corresponding to the host SDK function, such as ParSdkWrapper, which implements a unified standard protocol interface, such as openPlugin(), getAppInstallApp(), etc., and is stored in memory. These standard protocol adapter classes implement a unified standard protocol interface, allowing the business system to call the SDK functions of different hosts through the same interface. By encapsulating these standard protocol adapter classes, the differences of the host SDK can be shielded inside the adaptation layer, and the business system does not need to care about the specific implementation details of the underlying host SDK. In actual application, the standard protocol interface can be set according to the principles of simplicity and clarity to ensure that the business system can call the required functions conveniently and efficiently. In specific implementation, corresponding standard protocol interfaces, such as login interface, jump interface, resource download interface, etc., can be defined according to the functional characteristics of the host SDK and the needs of the business system, and a unified calling method and parameter specifications can be provided for each interface.

[0043] In addition, this embodiment sets a callback mechanism for initialization completion, so that the business party can accurately determine whether the initialization process has been successfully completed. Through this callback mechanism, the business party can decide whether to continue to enter the execution of the main process according to the actual situation, or give a corresponding error prompt in the case of initialization failure, thereby ensuring the stability and reliability of the entire system. At the same time, this embodiment also allows the user to pass in a series of customized configuration parameters during the initialization process. These parameters may include but are not limited to return to refresh mode, that is, how to refresh the display after the data is updated. The user can also specify the configuration of the current environment, such as distinguishing between the production environment and the test environment, to ensure that the application can adapt to the corresponding configuration requirements in different working stages. In this way, users can make personalized settings according to their specific needs and environmental characteristics, thereby improving the adaptability and flexibility of the overall calling process.

[0044] In addition, the internal structure of the middle layer described in this embodiment can adopt a modular adaptation plug-in design, that is, the capabilities of each host SDK are encapsulated into an independent plug-in, which can be loaded and called on demand at runtime, realizing a lightweight "multi-SDK pluggable" operation mode. In other words, this embodiment adopts the method of environment identification + dynamic loading + standard protocol mapping to realize the automatic adaptation of each host SDK plug-in.

[0045] In one embodiment, encapsulating a standard protocol adapter class for each host's SDK and building a standard protocol interface based on the standard protocol adapter class includes:

[0046] Based on the standard protocol adapter class, a business-unaware standard protocol interface is built, and the standard protocol interface covers the preset functional modules; wherein the preset functional modules include login, page jump, WebView control, image download, and buried point reporting.

[0047] This embodiment builds a set of business-unaware standard API interface protocols from the design level, such as Figure 5 As shown, this standard protocol structure covers capabilities such as login, page redirection, WebView (the core view class in the WebKit framework, used to manage interactions between the WebFrame and WebFrameView classes) control, image downloading, and tracking point reporting. For example, to open a WebView, the middle-layer standard protocol includes the openPlugin method (a tool for managing large model plug-ins), which supports standard input parameters such as URLs.

[0048] In one embodiment, if Figure 2 As shown, step S104 includes steps S201 to S202.

[0049] Step S201: Identify the operating environment of the business system;

[0050] Step S202: Select and call a target host SDK that matches the operating environment of the business system.

[0051] In this embodiment, when a business system needs to call a host SDK, it first sends a call request to the middle layer. Upon receiving the call request, the middle layer identifies the business system's operating environment. This identification process is similar to step S101, also detecting the business system's operating environment information, such as operation type, device type, browser type, etc., to determine the business system's current operating environment. Based on this, the middle layer selects a matching target host SDK from among the initialized host SDKs based on the business system's operating environment. This matching process ensures that the business system can call the host SDK that best suits its current operating environment, thereby improving the compatibility and stability of SDK calls. After selecting the target host SDK, the middle layer routes the business system's call request to the target host SDK, which then performs the corresponding functional operations. This routing call process decouples the business system from the host SDK, freeing the business system from having to worry about which underlying host or SDK provides the capability; it simply calls according to the standard protocol. At the same time, due to the use of an intermediate layer for bridging and routing, the business system can always use the same interface without frequent code changes, thereby improving the system's maintainability and docking efficiency.

[0052] In one embodiment, after the steps of encapsulating a standard protocol adapter class for each host's SDK and building a standard protocol interface based on the standard protocol adapter class, the process further includes:

[0053] Register the host SDK as a protocol adapter to build an adapter object;

[0054] Register the adapter object in a preset registration table.

[0055] After encapsulating the standard protocol adapter class for each host's SDK, this embodiment registers the standard protocol adapter class as a protocol adapter and generates corresponding adapter objects. These adapter objects are registered in a preset registry, which is used to manage and maintain all available adapter objects. When the business system initiates a call request, the middle layer will search and select the corresponding adapter object from the registry for routing call based on the operating environment of the business system. This makes it unnecessary for the business system to perceive which SDK or host is being called at the bottom layer, truly realizing the capability of "unified calling and environmental isolation", thereby making the adaptation process of the host SDK more flexible and efficient, and able to quickly adapt to different business needs and operating environments.

[0056] In one embodiment, if Figure 3As shown, the multi-host oriented SDK calling method further includes: steps S301 to S302.

[0057] Step S301: Monitor the status of the host SDK and determine whether to trigger the preset degradation logic based on the status monitoring result;

[0058] Step S302: When it is determined that the preset downgrade logic is triggered, the host SDK is called according to the preset downgrade strategy.

[0059] Taking into account the situation where the host SDK is unavailable due to version differences, permission restrictions, operational anomalies, etc., this embodiment monitors the host SDK to determine whether there is a problem, and then determines whether it is necessary to trigger the downgrade logic to ensure business continuity and user experience stability through the downgrade logic. When a host SDK is detected to have an abnormality or cannot meet business needs, the downgrade logic will be automatically triggered. At this time, according to the preset downgrade strategy, such as using the Web method instead of the native jump, or the local fallback interface instead of the service call, the basic operation of the business is ensured to be unaffected. In this way, the embodiment of the present invention not only improves the fault tolerance of the system, but also effectively reduces the risk of business interruption due to SDK problems.

[0060] In a specific embodiment, monitoring the status of the host SDK and determining whether to trigger a preset degradation logic based on the status monitoring result include:

[0061] When it is detected that the host SDK's capabilities do not meet the capability threshold or an abnormal status code is received from the host SDK, the degradation logic is triggered.

[0062] This embodiment determines that a problem with the host SDK exists if the host SDK's capabilities do not meet the capability threshold or if the host SDK returns an abnormal status code, thereby triggering the downgrade logic. It should be noted that in actual applications, all adapter plug-ins will include a try-catch package (an exception handling mechanism) and status code detection when executing the standard protocol interface. Therefore, when the host SDK detects a problem, it can directly throw an exception or return an error code.

[0063] In addition, during the degradation process, a unified pop-up component can be used to prompt users with the cause of the problem and alternative operation instructions, as well as example prompts, to improve user experience and provide users with clear operation instructions when facing service degradation, thereby reducing the trouble caused by service unavailability. In some optional embodiments, the configuration of the degradation strategy is not limited to automatic triggering at the technical level, but can also include manually configured degradation rules. For example, during business peaks or specific time periods, the degradation processing of certain non-core functions is pre-set to ensure the stable operation of the core business. This flexible configuration method enables the system to dynamically adjust service strategies according to different business scenarios and needs, thereby achieving optimal business continuity and user experience.

[0064] In another specific embodiment, when it is determined that the preset downgrade logic is triggered, calling the host SDK according to the preset downgrade strategy includes:

[0065] When the plug-in fails to be opened, the host SDK is called using the browser's native jump method.

[0066] When the application is called and identified as not installed, the corresponding application store is called and started to download and install the corresponding application.

[0067] The downgrade solutions for the standard protocol capability configuration in this embodiment are as follows:

[0068] When openPlugin fails to open, use the browser's native jump method.

[0069] When the openApp call identifies that the app is not installed, it opens the app store for the user to download it.

[0070] Furthermore, during the downgrade process, detailed log information is recorded, including the time of the downgrade, triggering conditions, the downgrade strategy implemented, and user feedback. This log information is invaluable for subsequent problem tracking, system optimization, and user experience improvement. By thoroughly analyzing these logs, technicians can promptly identify and resolve potential issues, further improving system stability and user experience.

[0071] It's worth noting that the multi-host SDK calling method provided in this embodiment also offers excellent scalability and flexibility. With business development and technological iteration, new host SDKs or new business capabilities may be continuously introduced. The method provided in this embodiment can easily cope with these changes. Simply by encapsulating and adapting the new host SDK according to standard protocols, it can be quickly integrated into the system without requiring large-scale modifications and adjustments to the existing business system. This scalability and flexibility ensures that the system can continue to evolve to meet ever-changing business needs and technical challenges.

[0072] In the existing technology, each time a host SDK is connected, each business system needs to be repeatedly developed and tested separately. In comparison, this embodiment only needs to be connected once according to the standard protocol, and it can be reused for all business projects. All business projects call service capabilities through standard protocols and no longer perceive the differences in the underlying SDKs. This not only greatly reduces the workload of technical docking communication, interface modification, and testing and verification, but also improves the system's compatibility and user experience consistency in multiple ecosystems. In particular, when the SDK version changes, it only needs to adjust the adaptation logic within the GJSDK to take effect, achieving the true architectural goal of "external stability and internal evolution". It not only greatly reduces labor costs and project cycles, but also strongly supports the rapid expansion and continuous evolution of businesses in complex operating environments.

[0073] Figure 6 A schematic block diagram of a multi-host SDK calling device 600 provided in an embodiment of the present invention, the device 600 includes:

[0074] An environment identification unit 601 is used to identify the current operating environment and determine the host type based on the current operating environment;

[0075] Initialization unit 602, used to call the original SDK of each host and initialize;

[0076] The encapsulation and construction unit 603 is used to encapsulate the standard protocol adaptation class for each host SDK and build a standard protocol interface based on the standard protocol adaptation class;

[0077] The routing calling unit 604 is used to build an intermediate layer based on the standard protocol interface, respond to the calling request of the business system through the intermediate layer, and then route the call to the corresponding host SDK in combination with the operating environment of the business system.

[0078] In this embodiment, the operating environment is first determined and different host types are identified. Next, the host SDKs are called and their native SDKs are initialized. A standard protocol adapter class is then created for each host SDK, establishing a standard protocol interface. Finally, an intermediate layer is constructed to handle service system call requests and route them to the appropriate host SDK based on the service system's operating environment.

[0079] This embodiment uniformly encapsulates and dynamically adapts the capabilities of various host SDKs, and uses an intermediate layer to bridge, dynamically load, and map capabilities between the host SDK and the business system. The intermediate layer is used to bridge the upper-level business projects and the underlying multiple host SDKs. During runtime, it identifies the current environment (APP A / B / C, WeChat, H5, etc.) and automatically routes calls to the corresponding SDK adaptation module. The business system only needs to call according to the standard protocol without worrying about which host or SDK provides the capability at the bottom. The business system can always use the same interface without frequent code changes. This can decouple the strong dependency between the business system and the host SDK, improve the overall decoupling capability and maintainability, and thereby improve the compatibility, stability, and docking efficiency of the host SDK call.

[0080] In particular, the multi-host SDK calling method provided in this embodiment is applicable to different business scenarios. For example, in a medical scenario, the medical business system can use the multi-host SDK calling method to achieve efficient and stable interaction with the SDKs of multiple medical ecosystems (such as hospital APPs, medical WeChat applets, etc.). When the medical business system needs to call a certain function, it only needs to send a request to the middle layer in accordance with a unified standard protocol. The middle layer will automatically identify and route to the corresponding host SDK according to the current operating environment to complete the function call. For example, in a financial scenario, the financial business system can use the multi-host SDK calling method to achieve seamless docking with the SDKs of multiple financial ecosystems (such as bank APPs, financial WeChat applets, H5 pages, etc.). When the financial business system needs to perform functions such as transfer, payment, and account balance inquiry, it can follow a unified standard protocol to send the request to the middle layer. The middle layer will intelligently identify the current operating environment and automatically select the most appropriate host SDK for routing calls to ensure efficient and accurate execution of functions.

[0081] In a specific embodiment, in the step of identifying the current operating environment and determining each host type based on the current operating environment, the host type of the current operating environment can be determined by detecting the host's operating environment information, including but not limited to the type, version, device type, browser type, etc. of the operating host. For example, if the operating environment is detected to be a WeChat applet, the host type is determined to be a WeChat applet; if the operating environment is detected to be an H5 page, the host type is determined to be H5, etc. In addition, the host type can be determined in conjunction with the configuration information of the business system, such as a preset host type list, to assist in determining the host type and ensure the accuracy of the identification.

[0082] In the step of calling the original SDK of each host and initializing it, the original SDK of the corresponding host, such as parSdk, is called according to the host type, and initialization operations are performed. The initialization process can include loading the resources required by the SDK, configuring parameters, verifying the validity of the SDK, etc., to ensure that the SDK can work properly. Different initialization strategies can be adopted for different types of hosts. For example, for WeChat applets, initialization can be performed through the API interface provided by WeChat; for H5 pages, initialization can be performed through JavaScript code. During the initialization process, the functions of the SDK can also be tested to ensure that its functions are complete and meet expectations. If the initialization fails or the SDK function is abnormal, corresponding error handling can be performed, such as recording error information, attempting reinitialization or downgrade processing, etc. Through this step, it can be ensured that the original SDK of each host is correctly called and initialized, providing a basis for subsequent standard protocol adaptation and routing calls.

[0083] In the step of encapsulating a standard protocol adapter class for each host SDK and building a standard protocol interface based on the standard protocol adapter class, an adaptation layer is specifically designed for each host SDK. The adaptation layer contains a standard protocol adapter class corresponding to the host SDK function, such as ParSdkWrapper, which implements a unified standard protocol interface, such as openPlugin(), getAppInstallApp(), etc., and is stored in memory. These standard protocol adapter classes implement a unified standard protocol interface, allowing the business system to call the SDK functions of different hosts through the same interface. By encapsulating these standard protocol adapter classes, the differences of the host SDK can be shielded inside the adaptation layer, and the business system does not need to care about the specific implementation details of the underlying host SDK. In actual application, the standard protocol interface can be set according to the principles of simplicity and clarity to ensure that the business system can call the required functions conveniently and efficiently. In specific implementation, corresponding standard protocol interfaces, such as login interface, jump interface, resource download interface, etc., can be defined according to the functional characteristics of the host SDK and the needs of the business system, and a unified calling method and parameter specifications can be provided for each interface.

[0084] In addition, this embodiment sets a callback mechanism for initialization completion, so that the business party can accurately determine whether the initialization process has been successfully completed. Through this callback mechanism, the business party can decide whether to continue to enter the execution of the main process according to the actual situation, or give a corresponding error prompt in the case of initialization failure, thereby ensuring the stability and reliability of the entire system. At the same time, this embodiment also allows the user to pass in a series of customized configuration parameters during the initialization process. These parameters may include but are not limited to return to refresh mode, that is, how to refresh the display after the data is updated. The user can also specify the configuration of the current environment, such as distinguishing between the production environment and the test environment, to ensure that the application can adapt to the corresponding configuration requirements in different working stages. In this way, users can make personalized settings according to their specific needs and environmental characteristics, thereby improving the adaptability and flexibility of the overall calling process.

[0085] In addition, the internal structure of the middle layer described in this embodiment can adopt a modular adaptation plug-in design, that is, the capabilities of each host SDK are encapsulated into an independent plug-in, which can be loaded and called on demand at runtime, realizing a lightweight "multi-SDK pluggable" operation mode. In other words, this embodiment adopts the method of environment identification + dynamic loading + standard protocol mapping to realize the automatic adaptation of each host SDK plug-in.

[0086] In one embodiment, the packaging construction unit 603 includes:

[0087] An interface building unit is used to build a business-unaware standard protocol interface based on the standard protocol adapter class, and to make the standard protocol interface cover the preset functional modules; wherein the preset functional modules include login, page jump, WebView control, image download, and buried point reporting.

[0088] This embodiment builds a set of business-unaware standard API interface protocols from the design level, such as Figure 5 As shown, this standard protocol structure covers capabilities such as login, page redirection, WebView (the core view class in the WebKit framework, used to manage interactions between the WebFrame and WebFrameView classes) control, image downloading, and tracking point reporting. For example, to open a WebView, the middle-layer standard protocol includes the openPlugin method (a tool for managing large model plug-ins), which supports standard input parameters such as URLs.

[0089] In one embodiment, if Figure 7 As shown, the routing calling unit 604 includes:

[0090] An operation identification unit 701 is used to identify the operation environment of the business system;

[0091] The target selection unit 702 is used to select and call a target host SDK that matches the operating environment of the business system.

[0092] In this embodiment, when a business system needs to call a host SDK, it first sends a call request to the middle layer. Upon receiving the call request, the middle layer identifies the business system's operating environment. This identification process is similar to step S101, also detecting the business system's operating environment information, such as operation type, device type, browser type, etc., to determine the business system's current operating environment. Based on this, the middle layer selects a matching target host SDK from among the initialized host SDKs based on the business system's operating environment. This matching process ensures that the business system can call the host SDK that best suits its current operating environment, thereby improving the compatibility and stability of SDK calls. After selecting the target host SDK, the middle layer routes the business system's call request to the target host SDK, which then performs the corresponding functional operations. This routing call process decouples the business system from the host SDK, freeing the business system from having to worry about which underlying host or SDK provides the capability; it simply calls according to the standard protocol. At the same time, due to the use of an intermediate layer for bridging and routing, the business system can always use the same interface without frequent code changes, thereby improving the system's maintainability and docking efficiency.

[0093] In one embodiment, the multi-host oriented SDK calling apparatus 700 further includes:

[0094] The first registration unit is used to register the host SDK as a protocol adapter to construct an adapter object;

[0095] The second registration unit is used to register the adaptation object into a preset registration table.

[0096] After encapsulating the standard protocol adapter class for each host's SDK, this embodiment registers the standard protocol adapter class as a protocol adapter and generates corresponding adapter objects. These adapter objects are registered in a preset registry, which is used to manage and maintain all available adapter objects. When the business system initiates a call request, the middle layer will search and select the corresponding adapter object from the registry for routing call based on the operating environment of the business system. This makes it unnecessary for the business system to perceive which SDK or host is being called at the bottom layer, truly realizing the capability of "unified calling and environmental isolation", thereby making the adaptation process of the host SDK more flexible and efficient, and able to quickly adapt to different business needs and operating environments.

[0097] In one embodiment, if Figure 8 As shown, the multi-host oriented SDK calling device 700 further includes:

[0098] The monitoring and judgment unit 801 is used to monitor the status of the host SDK and determine whether to trigger the preset degradation logic according to the status monitoring result;

[0099] The policy calling unit 802 is configured to call the host SDK according to the preset downgrade policy when it is determined that the preset downgrade logic is triggered.

[0100] Taking into account the situation where the host SDK is unavailable due to version differences, permission restrictions, operational anomalies, etc., this embodiment monitors the host SDK to determine whether there is a problem, and then determines whether it is necessary to trigger the downgrade logic to ensure business continuity and user experience stability through the downgrade logic. When a host SDK is detected to have an abnormality or cannot meet business needs, the downgrade logic will be automatically triggered. At this time, according to the preset downgrade strategy, such as using the Web method instead of the native jump, or the local fallback interface instead of the service call, the basic operation of the business is ensured to be unaffected. In this way, the embodiment of the present invention not only improves the fault tolerance of the system, but also effectively reduces the risk of business interruption due to SDK problems.

[0101] In one embodiment, the monitoring and judging unit 801 includes:

[0102] The downgrade trigger unit is used to determine whether to trigger the downgrade logic when it detects that the host SDK's capabilities do not meet the capability threshold or receives an abnormal status code fed back by the host SDK.

[0103] This embodiment determines that a problem with the host SDK exists if the host SDK's capabilities do not meet the capability threshold or if the host SDK returns an abnormal status code, thereby triggering the downgrade logic. It should be noted that in actual applications, all adapter plug-ins will include a try-catch package (an exception handling mechanism) and status code detection when executing the standard protocol interface. Therefore, when the host SDK detects a problem, it can directly throw an exception or return an error code.

[0104] In addition, during the degradation process, a unified pop-up component can be used to prompt users with the cause of the problem and alternative operation instructions, as well as example prompts, to improve user experience and provide users with clear operation instructions when facing service degradation, thereby reducing the trouble caused by service unavailability. In some optional embodiments, the configuration of the degradation strategy is not limited to automatic triggering at the technical level, but can also include manually configured degradation rules. For example, during business peaks or specific time periods, the degradation processing of certain non-core functions is pre-set to ensure the stable operation of the core business. This flexible configuration method enables the system to dynamically adjust service strategies according to different business scenarios and needs, thereby achieving optimal business continuity and user experience.

[0105] In one embodiment, the policy calling unit 802 includes:

[0106] The first calling unit is used to call the host SDK using the browser's native jump method when the calling plug-in fails to open.

[0107] The second calling unit is configured to call and start a corresponding application store to download and install the corresponding application when the application is called and identified as not installed.

[0108] The downgrade solutions for the standard protocol capability configuration in this embodiment are as follows:

[0109] When openPlugin fails to open, use the browser's native jump method.

[0110] When the openApp call identifies that the app is not installed, it opens the app store for the user to download it.

[0111] Furthermore, during the downgrade process, detailed log information is recorded, including the time of the downgrade, triggering conditions, the downgrade strategy implemented, and user feedback. This log information is invaluable for subsequent problem tracking, system optimization, and user experience improvement. By thoroughly analyzing these logs, technicians can promptly identify and resolve potential issues, further improving system stability and user experience.

[0112] It's worth noting that the multi-host SDK calling method provided in this embodiment also offers excellent scalability and flexibility. With business development and technological iteration, new host SDKs or new business capabilities may be continuously introduced. The method provided in this embodiment can easily cope with these changes. Simply by encapsulating and adapting the new host SDK according to standard protocols, it can be quickly integrated into the system without requiring large-scale modifications and adjustments to the existing business system. This scalability and flexibility ensures that the system can continue to evolve to meet ever-changing business needs and technical challenges.

[0113] In the existing technology, each time a host SDK is connected, each business system needs to be repeatedly developed and tested separately. In comparison, this embodiment only needs to be connected once according to the standard protocol, and it can be reused for all business projects. All business projects call service capabilities through standard protocols and no longer perceive the differences in the underlying SDKs. This not only greatly reduces the workload of technical docking communication, interface modification, and testing and verification, but also improves the system's compatibility and user experience consistency in multiple ecosystems. In particular, when the SDK version changes, it only needs to adjust the adaptation logic within the GJSDK to take effect, achieving the true architectural goal of "external stability and internal evolution". It not only greatly reduces labor costs and project cycles, but also strongly supports the rapid expansion and continuous evolution of businesses in complex operating environments.

[0114] See also Figure 9 , Figure 9 This is a schematic block diagram of a computer device provided by an embodiment of the present invention. The computer device is a device with wireless communication and wired communication.

[0115] The computer device includes a processor 902 , a memory, and a network interface 905 connected via a system bus 901 , wherein the memory may include a non-volatile storage medium 903 and an internal memory 904 .

[0116] The non-volatile storage medium 903 can store an operating system 9031 and a computer program 9032. When the computer program 9032 is executed, the processor 902 can execute a multi-host oriented SDK calling method.

[0117] The processor 902 is used to provide computing and control capabilities to support the operation of the entire computer device.

[0118] The internal memory 904 provides an environment for the operation of the computer program 9032 in the non-volatile storage medium 903. When the computer program 9032 is executed by the processor 902, the processor 902 can execute a multi-host oriented SDK calling method.

[0119] The network interface 905 is used to communicate with other devices over the network. Figure 9 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention and does not constitute a limitation on the computer device to which the solution of the present invention is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0120] The processor 902 is configured to run a computer program 9032 stored in the memory to implement any embodiment of the multi-host oriented SDK calling method.

[0121] It should be understood that in the embodiment of the present invention, the processor 902 may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0122] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0123] Identify the current operating environment and determine the host type based on the current operating environment;

[0124] Call the original SDK of each host and initialize it;

[0125] Encapsulate a standard protocol adapter class for each host's SDK, and build a standard protocol interface based on the standard protocol adapter class;

[0126] An intermediate layer is built based on the standard protocol interface, and the call request of the business system is responded to through the intermediate layer. Then, the call is routed to the corresponding host SDK in combination with the operating environment of the business system.

[0127] The present invention also provides a computer-readable storage medium having a computer program stored thereon. When executed, the computer program can implement the steps provided in the above embodiments. The storage medium can include a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, among other media capable of storing program code.

[0128] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0129] Identify the current operating environment and determine the host type based on the current operating environment;

[0130] Call the original SDK of each host and initialize it;

[0131] Encapsulate a standard protocol adapter class for each host's SDK, and build a standard protocol interface based on the standard protocol adapter class;

[0132] An intermediate layer is built based on the standard protocol interface, and the call request of the business system is responded to through the intermediate layer. Then, the call is routed to the corresponding host SDK in combination with the operating environment of the business system.

[0133] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant description in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0134] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0135] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0136] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A multi-host SDK calling method, characterized in that: include: Identify the current operating environment and determine the host type based on the current operating environment; Call the original SDK of each host and initialize it; Encapsulate a standard protocol adapter class for each host's SDK and build a standard protocol interface based on the standard protocol adapter class; An intermediate layer is built based on the standard protocol interface, and the call request of the business system is responded to through the intermediate layer. Then, the call is routed to the corresponding host SDK in combination with the operating environment of the business system.

2. The multi-host SDK calling method according to claim 1, characterized in that: The SDK for each host encapsulates a standard protocol adapter class and builds a standard protocol interface based on the standard protocol adapter class, including: Based on the standard protocol adapter class, a business-unaware standard protocol interface is built, and the standard protocol interface covers the preset functional modules; wherein the preset functional modules include login, page jump, WebView control, image download, and buried point reporting.

3. The multi-host SDK calling method according to claim 1, wherein: The intermediate layer is built based on the standard protocol interface, and the intermediate layer responds to the call request of the business system, and then routes the call to the corresponding host SDK in combination with the operating environment of the business system, including: Identifying the operating environment of the business system; Select and call the target host SDK that matches the operating environment of the business system.

4. The multi-host SDK calling method according to claim 1, wherein: After the steps of encapsulating a standard protocol adapter class for each host's SDK and building a standard protocol interface based on the standard protocol adapter class, the following steps are also included: Register the host SDK as a protocol adapter to build an adapter object; Register the adapter object in a preset registration table.

5. The multi-host SDK calling method according to claim 1, wherein: Also includes: Monitor the status of the host SDK and determine whether to trigger the preset degradation logic based on the status monitoring results; When it is determined that the preset downgrade logic is triggered, the host SDK is called according to the preset downgrade strategy.

6. The multi-host oriented SDK calling method according to claim 5, characterized in that: The host SDK status monitoring and determining whether to trigger the preset degradation logic according to the status monitoring result include: When it is detected that the host SDK's capabilities do not meet the capability threshold or an abnormal status code is received from the host SDK, the degradation logic is triggered.

7. The multi-host oriented SDK calling method according to claim 5, characterized in that: When it is determined that the preset downgrade logic is triggered, the host SDK is called according to the preset downgrade strategy, including: When the plugin fails to be opened, the host SDK is called using the browser's native redirect method; When the application is called and identified as not installed, the corresponding application store is called and started to download and install the corresponding application.

8. A multi-host SDK calling device, characterized in that: include: An environment identification unit, configured to identify the current operating environment and determine the host type based on the current operating environment; Initialization unit, used to call the original SDK of each host and initialize it; The encapsulation and construction unit is used to encapsulate the standard protocol adaptation class for each host SDK and build a standard protocol interface based on the standard protocol adaptation class; The routing calling unit is used to build an intermediate layer based on the standard protocol interface, respond to the calling request of the business system through the intermediate layer, and then route the call to the corresponding host SDK in combination with the operating environment of the business system.

9. A computer device, characterized in that: The method comprises a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for calling a multi-host SDK according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the multi-host oriented SDK calling method according to any one of claims 1 to 7 is implemented.

Images