Processing method, system, equipment and medium for docking and joint debugging of game SDK (Software Development Kit)

Abstract

The invention discloses a game SDK (Software Development Kit) butt joint and joint debugging processing method, system and device and a medium, and the method specifically comprises the following steps: establishing an SDK interface dependency graph, and carrying out butt joint on each SDK interface; the method comprises the following steps: acquiring interaction log data of an SDK client and an SDK server, analyzing the interaction log data through a K-Means algorithm, and determining an abnormal SDK interface when an exception occurs; collecting calling data of each SDK interface in real time, and determining a joint debugging state and a butt joint progress of all the SDK interfaces through the calling data; dynamically adjusting the calling opportunity and the calling frequency of each SDK interface according to the business scene and the user behavior of the game; various game scenes and user operations are simulated, and all SDK interfaces are subjected to comprehensive automatic testing. According to the method, the game SDK docking efficiency is remarkably improved, the game SDK docking period is shortened, the game SDK docking quality is ensured, the game SDK problem positioning difficulty is reduced, and powerful support is provided for quick online of games.

Description

Technical Field

[0001] The present invention relates to the field of game SDK technology, and in particular to a method, system, device and medium for processing game SDK docking and joint debugging. Background Art

[0002] In the process of mobile game development and release, SDK (Software Development Kit) docking between game developers and publishers plays a vital role. SDK is a bridge connecting games with external services such as app stores, advertising platforms, and payment systems. Its docking efficiency and stability directly affect the game development progress, user experience, and subsequent operational results. However, the traditional SDK docking method has many shortcomings, which are specifically manifested in the following aspects:

[0003] 1. It is difficult to preview the docking progress globally: In the traditional SDK docking process, the R&D side can only focus on a single or a small number of SDK interfaces that are currently being docked, and lacks a global perspective to preview the entire docking progress. This makes it easy to miss the docking of certain key functions during the docking process, thus affecting the integrity and functionality of the game.

[0004] 2. Difficulty in problem location: During the SDK docking process, once a problem occurs, it is often difficult for the R&D side and publisher to quickly locate the root cause of the problem. Due to the lack of effective analysis methods for SDK interface calls and interaction logs, problem location often requires a lot of time and manpower, further delaying the progress of game development.

[0005] 3. Low docking efficiency: The traditional SDK docking method lacks automated testing and optimization methods, resulting in low docking efficiency. The R&D side needs to manually call and test the SDK interface, which is not only time-consuming and labor-intensive, but also prone to human errors. Summary of the invention

[0006] The purpose of the present invention is to provide a processing method, system, device and medium for game SDK docking and joint debugging, which significantly improves the efficiency of game SDK docking, shortens the game SDK docking cycle, ensures the quality of game SDK docking, reduces the difficulty of locating game SDK problems, and provides strong support for the rapid launch of games, so as to solve at least one of the above-mentioned prior art problems.

[0007] In a first aspect, the present invention provides a method for processing game SDK docking and joint debugging, the method specifically comprising:

[0008] Connect various SDK interfaces by establishing an SDK interface dependency graph;

[0009] Obtain the interaction log data with the SDK client and SDK server, analyze the interaction log data using the K-Means algorithm, and determine the abnormal SDK interface when the exception occurs;

[0010] Collect the call data of each SDK interface in real time, and determine the joint debugging status and docking progress of all SDK interfaces through the call data;

[0011] Dynamically adjust the calling timing and frequency of each SDK interface based on the game's business scenarios and user behaviors;

[0012] By simulating various game scenarios and user operations, each SDK interface is fully automated and tested.

[0013] In a second aspect, the present invention provides a system for processing game SDK docking and joint debugging, the system specifically comprising:

[0014] The first processing module is used to connect various SDK interfaces by establishing an SDK interface dependency graph;

[0015] The second processing module is used to obtain the interaction log data with the SDK client and the SDK server, analyze the interaction log data by using the K-Means algorithm, and determine the abnormal SDK interface when the exception occurs;

[0016] The third processing module is used to collect the call data of each SDK interface in real time, and determine the joint debugging status and docking progress of all SDK interfaces through the call data;

[0017] The fourth processing module is used to dynamically adjust the calling timing and calling frequency of each SDK interface according to the business scenario and user behavior of the game;

[0018] The fifth processing module is used to perform comprehensive automated testing on each SDK interface by simulating various game scenarios and user operations.

[0019] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor and a computer program stored in the memory, and when the computer program is executed on the processor, a processing method for game SDK docking and debugging as described in any one of the above methods is implemented.

[0020] In a fourth aspect, 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 processing method for game SDK docking and debugging as described in any one of the above methods is implemented.

[0021] Compared with the prior art, the present invention has at least one of the following technical effects:

[0022] 1. Significantly improved the efficiency of game SDK docking, shortened the game SDK docking cycle, ensured the quality of game SDK docking, reduced the difficulty of locating game SDK problems, and provided strong support for the rapid launch of games.

[0023] 2. By establishing an SDK interface dependency diagram, the dependency relationships between the SDK interfaces can be clearly displayed, thus ensuring that no key interfaces are missed during the docking process.

[0024] 3. Real-time collection of call data and abnormal analysis help to promptly discover and locate problems and improve docking efficiency and stability.

[0025] 4. By dynamically adjusting the calling time and frequency of the SDK interface and performing comprehensive automated testing, the game performance can be optimized and the user experience can be improved.

[0026] 5. Dynamically adjust the calling parameters of the SDK interface according to the game's business scenarios and user behaviors to ensure that the interface calls are more in line with game requirements and improve game performance and user experience.

[0027] 6. Comprehensive automated testing by simulating various game scenarios and user operations can ensure that the SDK interface can work properly in various situations and improve the stability and reliability of the game.

[0028] 7. The cosine similarity algorithm is used to calculate the similarity between new SDK problems and historical cases in the knowledge base, which can quickly and accurately determine new problem types and solutions and improve problem-solving efficiency.

[0029] 8. By building an SDK version management platform, it is possible to effectively manage and track each SDK version to ensure compatibility and stability between versions. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0031] Figure 1 It is a schematic diagram of the operating environment of a method for processing game SDK docking and joint debugging provided by an embodiment of the present invention;

[0032] Figure 2 It is a flowchart of a method for processing game SDK docking and joint debugging provided by the first embodiment of the present invention;

[0033] Figure 3It is a flowchart of a method for processing game SDK docking and joint debugging provided by the second embodiment of the present invention;

[0034] Figure 4 It is a flowchart of a method for processing game SDK docking and joint debugging provided by the third embodiment of the present invention;

[0035] Figure 5 It is a flowchart of a method for processing game SDK docking and joint debugging provided by the fourth embodiment of the present invention;

[0036] Figure 6 It is a flowchart of a method for processing game SDK docking and joint debugging provided by the fifth embodiment of the present invention;

[0037] Figure 7 It is a flowchart of a method for processing game SDK docking and joint debugging provided by the sixth embodiment of the present invention;

[0038] Figure 8 It is a flowchart of a method for processing game SDK docking and joint debugging provided by the seventh embodiment of the present invention;

[0039] Fig. 9 It is a structural diagram of a processing system for docking and joint debugging of a game SDK provided by an embodiment of the present invention;

[0040] Fig.10 It is a structural schematic diagram of a computer device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0041] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0042] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0043] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0044] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0045] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0046] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0047] Reference Figure 1 In the embodiment of the present application, the execution entities include the game development side S101, the SDK client S102 and the SDK server 103. In this embodiment, the joint debugging version number is configured on the SDK server, which is usually the online version number plus 1. For example, if the online version number is 1.0.0, then the joint debugging version number is 1.0.1; when there is no online version number, the joint debugging version number can be 0.

[0048] The game development side starts by calling the initialization interface of the SDK client. The SDK client will request the API of the SDK server to determine whether the current version is the joint debugging version (determination rule: current version number => joint debugging version number). If so, a joint debugging status floating window of the SDK interface will pop up. This floating window shows all the interfaces that need to be connected and the status of the connection. Click to view the details of the connection, which helps the connection personnel quickly locate the problem and have an overview of the current connection progress.

[0049] The game development side calls the corresponding interface of the SDK client (initialization, login registration, TOKEN verification, recharge, data reporting, etc.). The SDK client will check whether the relevant parameters are legal locally, and then call the API interface of the SDK server. The SDK server will also check whether the parameters are legal and valid one by one, and give a detailed inspection conclusion, and return the interface joint debugging status of all SDK clients to the SDK client. The SDK client will simultaneously update the status display of the floating window. The SDK client backend displays the interfaces that need to be connected and the status of the connection in the form of reports, and can also display the problems encountered in the current connection, which can help the connection personnel to assist the R&D side to quickly connect.

[0050] Taking an action game as an example, game developers and publishers can globally grasp the current docking progress and clearly know the problems encountered in the docking process by docking SDK through the embodiment of the present application. The floating window of the debugging status can have different designs, for example, the icon can be replaced with a switch.

[0051] Figure 2 A flowchart of a method for processing game SDK docking and joint debugging disclosed in the first embodiment of the present invention is shown, and the details are as follows:

[0052] S201, interconnecting various SDK interfaces by establishing an SDK interface dependency graph.

[0053] In this embodiment, all SDK interfaces required for the game are first determined, including account registration and login, payment, advertising display, data reporting, etc. According to the functions and calling relationships of these interfaces, a detailed SDK interface dependency diagram is drawn using professional drawing tools to clearly show the dependencies, calling sequence and data flow between each interface. According to the calling relationship and dependency sequence in the SDK interface dependency diagram, the SDK interfaces are connected one by one. For example, the account registration and login interface is connected first to ensure that players can successfully register an account and log in to the game. Secondly, the payment interface is connected to realize the in-game purchase and payment functions, and the advertising display and data reporting interface is connected to display advertisements and collect player data. During the connection process, continuous testing and verification are carried out to ensure that each interface can work properly and meet the game requirements. At the same time, automated testing tools are used to simulate various game scenarios and user operations, and comprehensive automated testing of the SDK interface is carried out.

[0054] In this embodiment, by establishing the SDK interface dependency graph, the dependency relationship and calling order between the various interfaces can be clearly seen, thereby avoiding blindness and repetitive work in the docking process. This greatly improves the efficiency and quality of docking. In the docking process, docking is carried out strictly in accordance with the calling relationship and dependency order in the SDK interface dependency graph, avoiding conflicts and dependency conflicts between interfaces. This ensures the stability and reliability of the game.

[0055] S202, obtaining interaction log data with the SDK client and the SDK server, analyzing the interaction log data by using a K-Means algorithm, and determining an abnormal SDK interface when an exception occurs.

[0056] In the present embodiment, a log collection module is integrated in the game client to capture all interactive log data between the SDK client and the SDK server, and a corresponding log collection system is deployed on the SDK server to ensure that all requests and responses received by the SDK server can be fully recorded. The collected log data contains a large amount of original information, such as timestamp, interface name, request parameters, response status code, response time, etc. First, these log data are cleaned and formatted, invalid and redundant information is removed, and key features are extracted, such as interface call frequency, response time distribution, error rate, etc. K-Means algorithm is selected as an analysis tool, and a suitable K value (number of clusters) is set to divide the pre-treated log data into different cluster clusters. Through multiple iterations and calculations, the K-Means algorithm divides the log data into multiple cluster clusters, and each cluster cluster represents a set of log data with similar characteristics. In the clustering results, if the log data of one or more clusters show obvious abnormal characteristics, such as high interface call failure rate, response time far exceeding the average, etc., the SDK interface corresponding to these abnormal characteristics can be determined by further analyzing the log data in these clusters, that is, the abnormal SDK interface. Finally, the root cause of the problem is located by analyzing the code, checking the logs, and performing simulation tests, and corresponding repairs and optimizations are carried out.

[0057] In this embodiment, the interaction log data is analyzed by the K-Means algorithm, which can quickly locate the SDK interface where the abnormality occurs, thereby greatly shortening the time for troubleshooting. By timely discovering and handling abnormal SDK interfaces, the stability and smoothness of the game can be ensured, thereby improving the player's gaming experience.

[0058] S203, collecting the call data of each SDK interface in real time, and determining the joint debugging status and docking progress of all SDK interfaces through the call data.

[0059] In this embodiment, a real-time data collection system is first built, which can capture the call data of all SDK interfaces, including key information such as call time, interface name, request parameters, response results, etc. Through the data collection system, the call data of each SDK interface is obtained in real time, and these data are analyzed in real time using professional data analysis tools, including statistics and monitoring of key indicators such as call frequency, response time, and error rate. Based on the results of real-time analysis, the joint debugging status and docking progress of each SDK interface can be clearly understood. For example, by monitoring the call frequency and response time of the interface, it can be determined whether the interface has been stably docked; by statistically analyzing the error rate, potential interface problems can be found, and repaired and optimized in time. During the docking process, if an interface call exception or joint debugging problem occurs, the specific interface and call data can be immediately located through the data collection system.

[0060] In this embodiment, by collecting and analyzing the call data of the SDK interface in real time, the joint debugging status and docking progress of each interface can be grasped in real time to ensure that the docking work is carried out as planned. Once an interface call abnormality or joint debugging problem occurs, the specific interface and call data can be immediately located through the data collection system, so as to quickly troubleshoot and solve the problem and avoid affecting the development and launch progress of the game.

[0061] S204, dynamically adjusting the calling timing and calling frequency of each SDK interface according to the business scenario and user behavior of the game.

[0062] In this embodiment, the timing and frequency of calling the SDK interface will be different at different stages of the game, such as login, game process, payment, etc. For example, in the login stage, the calling frequency of the account and payment interfaces will be higher; while in the game process, the calling of the advertising and data reporting interfaces will be more frequent. By analyzing the user's game behavior, such as active time, game duration, payment habits, etc., the calling of the SDK interface can be further optimized. For example, for users with a longer active time, the calling frequency of the advertising interface can be appropriately increased to provide more in-game rewards; and for users with better payment habits, the calling process of the payment interface can be optimized to improve the payment success rate. Implement the call to the SDK interface in the code, and dynamically adjust the calling timing and frequency by configuring parameters.

[0063] In this embodiment, by dynamically adjusting the timing and frequency of SDK interface calls, unnecessary interface calls and resource waste are avoided, thereby improving the running efficiency and performance of the game. By adjusting the SDK interface calls according to user behavior and business scenarios, the game is more in line with user needs and habits, improving user satisfaction and loyalty.

[0064] S205, conduct comprehensive automated testing on each SDK interface by simulating various game scenarios and user operations.

[0065] In this embodiment, a test platform simulating a real game environment is built, including a server, a client and a test tool. According to the business scenario and user operation of the game, multiple test cases are designed to cover all functional points of the SDK interface. The test cases include normal operation, abnormal operation, boundary conditions, etc. to ensure the comprehensiveness and accuracy of the test. Professional automated testing tools such as Selenium, Appium, etc. are selected to simulate user operations and capture test results. By writing test scripts, the automated call and verification of the SDK interface are realized. Multiple game scenarios are simulated on the test platform, such as user registration, login, game process, payment, etc. In each scenario, multiple user operations are included to trigger different calls of the SDK interface. The SDK interface is fully tested through the automated testing tool. During the test process, the automated testing tool simulates the user's operation and captures the test results. The test results are analyzed and verified to ensure the functional correctness and stability of the SDK interface. Finally, the test results are summarized and analyzed, and a test report is generated. The test report includes the test environment, test cases, test results, problem list and repair suggestions.

[0066] In this embodiment, the automated testing tool can simulate multiple user operations and multiple game scenarios, and realize fast and comprehensive testing of the SDK interface. Compared with manual testing, automated testing greatly improves testing efficiency and shortens the testing cycle. Automated testing tools can be reused, reducing the number of testers and testing time. Through automated testing, the testing team can find and fix problems in a timely manner, avoiding the additional costs of later repairs. Comprehensive automated testing can cover all functional points of the SDK interface, ensuring the stability and compatibility of the game in different scenarios. Problems found through testing are promptly fixed and optimized, improving the quality of the game and user experience.

[0067] In some embodiments, Figure 3 As shown, in the above step S201, the SDK interface dependency graph is established to connect various SDK interfaces, which specifically includes:

[0068] S2011, build SDK interface dependency graph by analyzing the functions and calling relationships of each SDK interface;

[0069] S2012, determining the priority of each SDK interface connection by using a topological sorting algorithm according to the SDK interface dependency graph;

[0070] S2013: Connecting various SDK interfaces according to the priority.

[0071] In this embodiment, through static code analysis and dynamic call tracking, the functional attributes and call relationship data of the SDK interface are extracted to construct the original SDK interface relationship map. The SDK interface relationship map is analyzed, the dependency relationship between the interfaces is identified by algorithms such as depth-first search, and the edge weight of the map is updated according to the dependency relationship. The updated SDK interface relationship map is divided into communities using a community discovery algorithm to identify each interface community, and the interface priorities within the community are similar. For each interface community, a topological sorting algorithm is used to calculate the docking priority of each interface in the community to obtain the docking order of the interface in the community. Each interface community is sorted according to the dependency relationship to obtain the dependency relationship between the communities, and then the docking priority of the community is determined. According to the docking priority of the community and the docking order of the interface in the community, the interface docking scheme of the entire SDK is generated to determine the docking time point of each interface. The generated SDK interface docking scheme is verified by combining automated testing and manual inspection to ensure that the SDK interface function after docking is complete and operates normally.

[0072] For example, suppose a mobile application development kit (SDK) contains interfaces such as user authentication, data synchronization, payment processing, and message push. First, the functions and calling relationships between these interfaces need to be analyzed. The user authentication interface must be called before data synchronization and payment processing because these operations need to verify the identity of the user. Similarly, the data synchronization interface may need to be called before the message push to ensure that the pushed message contains the latest data. Building a dependency graph can be represented by representing the interface as a node and the dependency as a directed edge. In this example, the user authentication interface is a starting node, which points to the data synchronization and payment processing interfaces, which in turn point to the message push interface. Such a graphical representation helps developers clearly see the dependency order between the various interfaces. Next, using a topological sorting algorithm to determine the docking priority of the interface is an effective strategy. Topological sorting is an algorithm for sorting a directed acyclic graph (DAG), which outputs a linear sequence of vertices. According to this sequence, all dependent nodes of each node (in this scenario, the SDK interface) will be ranked in front of it. In practice, this means that developers can first dock the user authentication interface, then the data synchronization and payment processing interfaces, and finally the message push interface. Finally, based on the determined priorities, developers can systematically connect to various SDK interfaces. The advantage of this approach is that it can minimize dependency issues encountered during the development process and improve development efficiency. For example, ensuring that the user authentication interface is connected and tested first can ensure that the user's identity has been verified during data synchronization and payment processing, thereby avoiding repeated debugging of authentication errors in subsequent development. In this way, the development team can work more orderly and efficiently, reduce problems caused by improper interface dependencies, and accelerate product time to market. In addition, this approach also helps developers who are new to the project quickly understand the relationship between the project structure and interfaces, and improve the collaboration efficiency of the entire team.

[0073] In some embodiments, Figure 4 As shown, in the above step S202, the interaction log data is analyzed by the K-Means algorithm to determine the abnormal SDK interface when the abnormality occurs, specifically including:

[0074] S2021, determining a plurality of SDK interface indicator feature vectors according to the interaction log data;

[0075] S2022, when an exception occurs, clustering multiple SDK interfaces using a K-Means algorithm based on the SDK interface indicator feature vector to obtain a clustering result;

[0076] S2023: Determine an abnormal cluster based on the clustering result, and determine an abnormal SDK interface according to the abnormal cluster.

[0077] In this embodiment, according to the interaction log data, the feature engineering method is adopted to extract the various indicator parameters of the SDK interface call and construct the indicator feature vector. The system operation status is monitored in real time. If an abnormality is detected, the abnormal analysis process is triggered. The indicator feature vector of the SDK interface is input into the K-Means clustering model, and appropriate clustering parameters are set to perform cluster analysis. The abnormal cluster is identified from the clustering results, and the SDK interface corresponding to the data point in the abnormal cluster is the suspicious abnormal interface. The SDK interface call situation in the abnormal cluster is statistically analyzed, and whether the interface is abnormal is determined based on indicators such as call failure rate and response time. If the interface is judged to be abnormal, the abnormal interface information is recorded, and the alarm mechanism is triggered to notify the relevant responsible person to conduct investigation and processing. The analysis results of the abnormal interface are fed back to the business system, the abnormal interface is marked, and it is offline or limited in time to avoid further deterioration of the abnormality.

[0078] Exemplarily, the SDK interface indicator feature vector can be understood as a set of key indicators extracted from the interaction log data that can describe the operating status of the SDK interface. These indicators may include the number of interface calls, average response time, error rate, traffic size, etc. For example, for a payment SDK, indicators such as "average number of calls per day", "average response time", "payment success rate" and "average payment amount" can be extracted to form a feature vector to characterize the operating status of the SDK interface. Extracting these indicators can help understand the operation of the SDK interface from multiple dimensions and provide data support for subsequent anomaly detection and problem location. Suppose there are multiple SDK interfaces, namely user authentication SDK (Auth), data synchronization SDK (Sync), payment SDK (Pay) and message push SDK (Push). Their indicator feature vectors are extracted from the logs respectively.

[0079] The feature vector of Auth is (number of calls: 10000, average response time: 50ms, error rate: 1%);

[0080] The feature vector of Sync is (number of calls: 5000, average response time: 100ms, error rate: 5%);

[0081] The feature vector of Pay is (number of calls: 2000, average response time: 200ms, error rate: 2%).

[0082] The feature vector of Push is (number of calls: 8000, average response time: 80ms, error rate: 3%).

[0083] For example, when an SDK interface has an exception and the user reports that the payment function is unavailable, the SDK interfaces can be clustered using the K-Means algorithm based on the extracted SDK interface indicator feature vectors.

[0084] K-Means algorithm is a commonly used clustering algorithm, which divides data points into K clusters so that the sum of the distances between each data point and the center point of its cluster is minimized. In this example, the K value can be set to 2, and the SDK interface can be divided into two categories: normal and abnormal.

[0085] Assume that the clustering results of the K-Means algorithm are as follows: the first cluster contains Auth and Push, and the second cluster contains Sync and Pay. Observing the feature vectors of each cluster, the first cluster has a higher number of SDK interface calls, a shorter average response time, and a lower error rate. The second cluster has a relatively lower number of SDK interface calls, a longer average response time, and a relatively higher error rate. At this point, since users report that the payment function is unavailable, and Pay belongs to the second cluster, it can be preliminarily determined that the second cluster is an abnormal cluster. After determining the abnormal cluster, the abnormal SDK interface can be determined based on the members in the abnormal cluster. In this example, the abnormal cluster contains Sync and Pay. Since the user reported that the payment function is abnormal, it can be determined that Pay is an abnormal SDK interface.

[0086] Further analysis of the feature vector of Pay shows that its average response time reaches 200ms, which is significantly higher than other SDK interfaces. This may be the cause of the abnormal payment function. In this way, the SDK interface with the problem can be quickly located, thereby improving the efficiency of troubleshooting. The advantage of doing this is that related SDK interfaces can be effectively aggregated together to better identify and locate anomalies. For example, if Sync and Pay often have problems at the same time, clustering them into the same cluster can help discover the potential correlation between them and solve the problem more effectively.

[0087] In some embodiments, Figure 5 As shown, in the above step S204, dynamically adjusting the calling timing and calling frequency of each SDK interface according to the business scenario and user behavior of the game specifically includes:

[0088] S2041, acquiring SDK interface calling parameters according to the SDK configuration file, wherein the SDK interface calling parameters include a calling time and a calling frequency of the SDK interface;

[0089] S2042, obtaining business scenario characteristics and user behavior characteristics of the game, and performing correlation analysis on the business scenario characteristics, the user behavior characteristics and the SDK interface call parameters to form a first training data set;

[0090] S2043, using the first training data set as input, performing modeling training through a decision tree algorithm, and obtaining an SDK interface call parameter adjustment model, wherein the SDK interface call parameter adjustment model is used to dynamically adjust the call parameters of the SDK interface according to different game environments and user needs.

[0091] In this embodiment, the name, calling time and calling frequency and other parameters of the SDK interface are parsed from the SDK configuration file to construct an SDK interface calling parameter table; business scenario characteristics during the game operation are obtained, including the current game level, scenario type, scenario complexity, etc., and user operation behavior characteristics are obtained, including operation type, operation frequency, operation duration, etc.; the SDK interface calling parameter table is correlated with the business scenario characteristics and user behavior characteristics to find out the optimal configuration of the SDK interface calling parameters under different scenarios and behaviors, and a training data set is generated; a decision tree algorithm is used to model and train the training data set to obtain an SDK interface calling parameter adjustment decision tree model, which is based on the business scenario characteristics and user behavior characteristics. The scenario characteristics and user behavior characteristics are used as input, and the corresponding optimal SDK interface calling parameter configuration is output; during the game operation, the current business scenario characteristics and user behavior characteristics are obtained in real time, input into the decision tree model, and dynamically decide the optimal SDK interface calling time and frequency under the current environment; according to the output of the decision tree model, the calling parameters of the SDK interface are dynamically adjusted to achieve interface calling optimization based on game scenarios and user behaviors; the scenario characteristics, user behavior characteristics and corresponding SDK interface calling parameters in the game process are continuously collected, the training data set is updated, and the decision tree model is retrained regularly to adapt it to changes in the game environment and improve the timeliness and accuracy of SDK interface calls.

[0092] For example, the SDK configuration file is a necessary configuration description for integrating the SDK into a game development project. It defines various parameters of the SDK interface, including the calling time and calling frequency. The calling time refers to the stage in the game process at which the SDK interface is called, for example, when the game starts, when the level is loaded, when the user completes a specific task, and so on. The calling frequency refers to the number of times the SDK interface is called per unit time, for example, once per second, once per minute, only once each time the game starts, and so on. The purpose of obtaining these parameters is to understand the usage of the SDK interface in the game.

[0093] Take a game statistics SDK as an example. The SDK provides an interface for counting user level distribution. The SDK configuration file defines the calling time of the interface as "whenever the player's level is upgraded" and the calling frequency as "once for each level upgrade". Game business scenario features refer to various scenarios in the game, such as login scenarios, battle scenarios, transaction scenarios, etc. User behavior features refer to various behaviors of users in the game, such as login time, game time, payment amount, etc. These features are obtained to understand the user's behavior patterns in the game.

[0094] For example, for a role-playing game, business scenario features may include "main quest", "dungeon challenge", "equipment enhancement", etc. User behavior features may include "daily login times", "average online time", "in-game currency consumption", etc. The purpose of associating business scenario features, user behavior features and SDK interface call parameters is to understand the impact of different scenarios and user behaviors on SDK interface calls.

[0095] For example, in the "Dungeon Challenge" scenario, the frequency of user level upgrades may be higher, so the frequency of calling the statistical user level distribution interface will also be higher. In the user group with a higher user payment amount, they may perform "equipment enhancement" more frequently, so the frequency of calling the SDK interface related to equipment enhancement will also be higher. Through association analysis, this information can be integrated into the first training data set.

[0096] Assume that the following data is collected: User A, in the "Dungeon Challenge" scenario, plays for 1 hour, levels up 2 times, and calls the user level distribution statistics interface 2 times; User B, in the "Mainline Mission" scenario, plays for 2 hours, levels up 1 time, and calls the user level distribution statistics interface 1 time. These data constitute part of the first training data set.

[0097] The decision tree algorithm is a commonly used machine learning algorithm that can build a tree model based on training data to predict or classify new data. In this example, the first training data set is used as input, and the decision tree algorithm is used for modeling and training to obtain the SDK interface call parameter adjustment model. The decision tree model may learn that if the user's game time in the "Dungeon Challenge" scene exceeds 1 hour, the call frequency of the statistical user level distribution interface is increased to once every 30 minutes. The SDK interface call parameter adjustment model is used to dynamically adjust the call parameters of the SDK interface according to different game environments and user needs. During the game activity, in order to understand user behavior more accurately, the call frequency of certain SDK interfaces can be increased according to the prediction results of the model. When the game server is under high load, the call frequency of certain SDK interfaces can be reduced according to the prediction results of the model to reduce the pressure on the server. The advantage of this is that the call parameters of the SDK interface can be dynamically adjusted according to the actual situation, thereby improving the efficiency of data collection and avoiding excessive burden on the game server. If, after a period of game operation, it is found that the user's activity in the "transaction scenario" has decreased, the call frequency of the SDK interface related to the transaction can be reduced according to the model prediction results to reduce unnecessary computing resource consumption. At the same time, the call frequency of other SDK interfaces related to the "transaction scenario" can be increased to collect user data in more detail and analyze the reasons for changes in user behavior.

[0098] In some embodiments, Figure 6 As shown, in the above step S205, by simulating various game scenarios and user operations, a comprehensive automated test is performed on each SDK interface, specifically including:

[0099] S2051, obtaining different game scene data and user operation data, and building a game SDK interface test environment using an automated testing framework according to the game scene data and user operation data;

[0100] S2052, based on the game SDK interface test environment, executing automated test cases on each SDK interface to obtain test results;

[0101] S2053, determining a failed test case according to the test result;

[0102] S2054, based on a preset test feature vector, using a support vector machine algorithm to determine the failure cause and repair solution of the failed test case.

[0103] In this embodiment, game scene data and user operation data are obtained, the data is preprocessed, and key features are extracted. According to the extracted features, a clustering algorithm is used to classify the game scenes to obtain different types of game scenes. For each game scene, a corresponding automated testing framework is constructed, and a game SDK interface testing environment is built. In the test environment, according to the preset test cases, the SDK interface test is automatically executed to obtain the test result data. The test result data is analyzed to determine whether the test case execution is successful and the failed test cases are determined. For the failed test cases, the relevant test feature vectors are extracted as the input of the support vector machine algorithm. The support vector machine algorithm is used, combined with the preset test feature vectors, to classify the failed test cases, determine the cause of the failure, and provide the corresponding repair plan.

[0104] For example, the game SDK is integrated into the game, and it is necessary to ensure that it can work properly in various scenarios. In order to achieve this goal, it is necessary to obtain different game scene data and user operation data, and use this to build a test environment, perform automated testing, and finally analyze the test results and provide repair solutions. It is crucial to obtain game scene data and user operation data. Game scene data refers to different scenes in the game, such as login scenes, combat scenes, transaction scenes, etc. User operation data refers to various behaviors of users in the game, such as clicking buttons, sliding screens, entering text, etc. These data can be obtained through embedding points, logging, etc. For example, you can embed points in the game to record the time the user stays in each scene, the number of operations performed, etc.

[0105] Taking a card game as an example, you can record how many times the user has drawn cards in the "card drawing" scene, what the result of each draw is, how many battles the user has fought in the "arena" scene, the win or loss of each battle, etc. These data can help understand the user's behavior patterns in the game, so as to conduct more targeted testing. With the game scene data and user operation data, you can use the automated testing framework to build a game SDK interface test environment. The automated testing framework can help automate the execution of test cases and improve test efficiency. Common automated testing frameworks include Selenium and Appium. For example, you can use Appium to simulate various user operations in the game, such as clicking the login button and entering the battle scene. At the same time, you can simulate different network environments, such as weak network environments and network interruptions, to test the stability of the SDK in various network environments. In the constructed test environment, you need to execute automated test cases for each SDK interface. Test cases should cover various scenarios and user operations. For example, when testing the user login interface, it should include correct usernames and passwords, incorrect usernames and passwords, and empty usernames and passwords. Taking a game statistics SDK as an example, it is necessary to test whether its data statistics function is normal in scenarios such as user level improvement, task completion, and item purchase. The design of test cases should be as comprehensive as possible to ensure the quality of the SDK. After executing the automated test cases, the test results will be obtained. The test results need to be analyzed to determine the failed test cases. Failed test cases refer to test cases whose execution results do not match the expected results. For example, when testing the user login interface, if the login fails with the correct username and password, the test case is a failed test case. For failed test cases, it is necessary to determine the cause of failure and provide a repair plan. In order to achieve automated diagnosis, the support vector machine algorithm can be used to analyze the cause of failure based on the preset test feature vector. The test feature vector can include the input parameters, execution environment, error information, etc. of the test case. For example, if a test case fails to execute in a weak network environment, its test feature vector should include the feature of "weak network environment". The support vector machine algorithm can classify failed test cases into different cause categories based on the test feature vector, such as network error, parameter error, logic error, etc. For different cause categories, corresponding repair solutions can be pre-set. For example, for network errors, it can be suggested to check the network connection or retry the operation. For parameter errors, it can be suggested to check whether the input parameters are correct. In this way, the cause of the failure can be automatically diagnosed and a repair solution can be provided, thereby improving test efficiency.

[0106] In some embodiments, Figure 7 As shown, the method also includes:

[0107] S301, obtaining historical SDK problem case data, and forming a second training data set by performing data preprocessing and feature extraction on the historical SDK problem case data;

[0108] S302, using the second training data set as input, performing modeling training through a machine learning algorithm, and obtaining an SDK problem classification model and a solution recommendation model respectively;

[0109] S303, constructing an SDK problem knowledge base according to the SDK problem classification model and the solution recommendation model;

[0110] S304, when a new SDK problem appears, the similarity between the new SDK problem and each SDK problem historical case in the SDK problem knowledge base is calculated by using a cosine similarity algorithm to determine the problem type and solution of the new SDK problem.

[0111] In this embodiment, the historical data of massive SDK problem cases is obtained, and pre-processing operations such as data cleaning, denoising, and format conversion are performed on the original data to obtain standardized problem case data. Natural language processing technology is used to perform word segmentation, part-of-speech tagging, named entity recognition, and other processing on the standardized SDK problem case data to extract features such as problem description, error information, and keywords. According to the extracted feature vector, a feature matrix of the SDK problem case is constructed and divided into a training set and a test set to form a training data set for machine learning. For the SDK problem classification task, the support vector machine algorithm is used to model the training data set, and the model hyperparameters are optimized through grid search to obtain the problem classification model with the best performance. For the solution recommendation task, the collaborative filtering algorithm is used to model the training data set, and the best similarity calculation method is determined through cross-validation to obtain a solution recommendation model.

[0112] Use the trained SDK problem classification model to determine the problem type of the new problem; retrieve historical cases of the same type as the new problem from the SDK problem knowledge base; use the cosine similarity algorithm to calculate the similarity between the new problem and the retrieved historical cases; select the Top N historical cases with the highest similarity based on the similarity sorting results; use the solutions to the Top N historical cases as candidates, score and sort them through the solution recommendation model, and obtain the final recommended solution.

[0113] For example, obtaining historical SDK problem case data is the first step in building an SDK problem knowledge base. This data can come from various sources, such as customer service records, developer forums, bug feedback platforms, etc. Taking the game SDK as an example, you can collect player feedback on game crashes, freezes, flashbacks, recharge failures, and other issues, as well as integration issues and interface call issues raised by developers. These problem case data should include information such as the description of the problem, the scenario in which it occurs, the number of users affected, and the corresponding SDK version number.

[0114] Data preprocessing and feature extraction are to convert the original problem case data into a data format that can be used for machine learning model training. First, the text data needs to be cleaned, such as removing special characters and stop words. Then feature extraction is required to convert the text into a numerical vector representation. Common feature extraction methods include TF-IDF, Word2Vec, etc. For example, a problem description about "game SDK login failure" can be processed by TF-IDF to obtain a weight vector containing keywords such as "login", "failure", "SDK", and "game". Among them, "login" and "failure" have higher weights, indicating that these two words are more important in describing this problem. The purpose of feature extraction is to convert text data into a format that can be understood and processed by the machine learning model. After the second training data set is formed, it can be used to train the machine learning model. The SDK problem classification model is used to predict the category of new problems, such as network problems, interface problems, compatibility problems, etc. The solution recommendation model is used to recommend solutions for specific problems. These two models can be trained using different machine learning algorithms, such as support vector machines, naive Bayes, random forests, etc. Suppose the SDK problem classification model is trained using the support vector machine algorithm to distinguish between "network problems" and "interface problems". The training dataset contains some SDK problem cases that have been marked as "network problem" or "interface problem". Through training, the model can learn the features that distinguish these two types of problems. For example, "network problem" usually contains keywords such as "connection timeout" and "unable to connect", while "interface problem" usually contains keywords such as "parameter error" and "interface return exception". The trained SDK problem classification model and solution recommendation model can be used to build an SDK problem knowledge base. The knowledge base stores the feature vectors, problem categories and corresponding solutions of historical SDK problems. For example, a problem about "SDK initialization failure" may have a feature vector containing keywords such as "initialization", "failure" and "SDK". The problem category is "interface problem" and the corresponding solution may be "check whether the initialization parameters are correct" or "check whether the SDK version is compatible". When a new SDK problem appears, such as "game SDK cannot connect to the server", it is first necessary to perform data preprocessing and feature extraction on the problem to obtain its feature vector. Then, the cosine similarity algorithm is used to calculate the similarity between the new SDK problem and each historical SDK problem in the SDK problem knowledge base.

[0115] Assume that the similarity with a historical SDK problem "Game SDK network connection interrupted" is the highest. The category of this historical problem is "network problem" and the solutions are "check network connection" and "restart the game". It can be inferred that the category of the new problem may also be "network problem" and the corresponding solution can be recommended. The advantage of this is that the type of new problem can be quickly located and effective solutions can be provided, thereby improving the efficiency of problem solving.

[0116] In some embodiments, Figure 8 As shown, the method also includes:

[0117] S401, building an SDK version management platform based on the code differences and dependencies of each SDK version;

[0118] S402, when a problem occurs in the current SDK version, a version rollback operation is performed according to the SDK version management platform, and the problem of the current SDK version is traced.

[0119] In this embodiment, the source code and compiled binary files of each SDK version are obtained, and the code differences between different versions are analyzed through a difference comparison algorithm, and a version difference database is constructed. For the dependency relationship of each SDK version, a dependency graph algorithm is used to generate a version dependency graph and store it in a version dependency database. According to the version difference database and the version dependency database, an SDK version management platform is constructed to realize functions such as version information query, version switching, and version comparison. When a problem occurs in the current SDK version, the problem version is quickly located through the version management platform, and according to the version dependency graph, it is determined which stable version is most suitable to roll back to. The version rollback operation is performed to switch the SDK to the selected stable version, and the rollback operation log is recorded for subsequent problem tracing. The problem version is traced and analyzed, and the code modification that introduces the problem is located through code difference comparison and data mining algorithms, and a problem report is generated. According to the problem report, the SDK version management process is optimized, such as introducing code review, automated testing and other links, to improve the quality and stability of the SDK version and avoid similar problems from happening again.

[0120] Exemplarily, the construction of the SDK version management platform is to efficiently manage different versions of SDK, including code, dependent libraries, documents, etc., and can also help developers quickly switch versions, trace problems and roll back versions. For example, a game SDK, the version number iterates from 0 to 0, and each version has a corresponding code library, dependent library and update log. The SDK version management platform is like a warehouse, recording the information of all versions, which is convenient for developers to view and manage. The version rollback operation refers to rolling back the current SDK version to a previous stable version. When serious problems occur in the latest version, such as causing game crashes, recharge failures, etc., which affect the user experience, a version rollback operation needs to be performed. For example, in version 0 of the game SDK, there is a bug in the newly added payment interface, which causes the player to recharge and fail. At this time, the SDK version needs to be rolled back to the relatively stable version 0 to restore the normal recharge function. The SDK version management platform can quickly switch versions, so as to restore services as soon as possible.

[0121] Reference Fig. 9 An embodiment of the present invention provides a processing system 9 for docking and joint debugging of a game SDK, and the system 9 specifically includes:

[0122] The first processing module 901 is used to connect various SDK interfaces by establishing an SDK interface dependency graph;

[0123] The second processing module 902 is used to obtain the interaction log data with the SDK client and the SDK server, analyze the interaction log data by using the K-Means algorithm, and determine the abnormal SDK interface when the abnormality occurs;

[0124] The third processing module 903 is used to collect the call data of each SDK interface in real time, and determine the joint debugging status and docking progress of all SDK interfaces through the call data;

[0125] The fourth processing module 904 is used to dynamically adjust the calling timing and calling frequency of each SDK interface according to the business scenario and user behavior of the game;

[0126] The fifth processing module 905 is used to perform comprehensive automated testing on various SDK interfaces by simulating various game scenarios and user operations.

[0127] It is understandable that if Figure 2 The contents of the game SDK docking and joint debugging processing method embodiment shown in the figure are applicable to the game SDK docking and joint debugging processing system embodiment. The functions specifically implemented by the game SDK docking and joint debugging processing system embodiment are similar to those in the example. Figure 2 The processing method embodiment of the game SDK docking and joint debugging shown in the figure is the same, and the beneficial effects achieved are the same as those of the example Figure 2The beneficial effects achieved by the embodiment of the processing method for game SDK docking and joint debugging shown are also the same.

[0128] It should be noted that the information interaction, execution process and other contents between the above-mentioned systems are based on the same concept as the embodiment of the method of the present invention. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0129] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0130] Reference Fig.10 The embodiment of the present invention further provides a computer device 10, comprising: a memory 1002 and a processor 1001 and a computer program 1003 stored in the memory 1002. When the computer program 1003 is executed on the processor 1001, a processing method for game SDK docking and joint debugging as described in any one of the above methods is implemented.

[0131] The computer device 10 may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The computer device 10 may include, but is not limited to, a processor 1001 and a memory 1002. Those skilled in the art will appreciate that Fig.10 This is only an example of the computer device 10 and does not constitute a limitation on the computer device 10 . The computer device 10 may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, it may also include input and output devices, network access devices, etc.

[0132] The processor 1001 may be a central processing unit (CPU), or 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. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0133] In some embodiments, the memory 1002 may be an internal storage unit of the computer device 10, such as a hard disk or memory of the computer device 10. In other embodiments, the memory 1002 may also be an external storage device of the computer device 10, such as a plug-in hard disk, a smart memory card (SmartMedia Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 10. Further, the memory 1002 may also include both an internal storage unit of the computer device 10 and an external storage device. The memory 1002 is used to store an operating system, an application program, a boot loader (Boot Loader), data, and other programs, such as the program code of the computer program, etc. The memory 1002 may also be used to temporarily store data that has been output or is to be output.

[0134] An embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the processing method for game SDK docking and joint debugging as described in any one of the above methods is implemented.

[0135] In this embodiment, if the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0136] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0137] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0138] In the embodiments disclosed in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0139] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Claims

1. A method for processing game SDK docking and joint debugging, characterized in that: The method specifically comprises: Connect various SDK interfaces by establishing an SDK interface dependency graph; Obtain the interaction log data with the SDK client and SDK server, analyze the interaction log data using the K-Means algorithm, and determine the abnormal SDK interface when the exception occurs; Collect the call data of each SDK interface in real time, and determine the joint debugging status and docking progress of all SDK interfaces through the call data; Dynamically adjust the calling timing and frequency of each SDK interface based on the game's business scenarios and user behaviors; By simulating various game scenarios and user operations, each SDK interface is fully automated and tested.

2. The method according to claim 1, characterized in that The SDK interface dependency graph is established to connect various SDK interfaces, specifically including: By analyzing the functions and calling relationships of each SDK interface, an SDK interface dependency graph is constructed; According to the SDK interface dependency graph, a topological sorting algorithm is used to determine the priority of each SDK interface connection; According to the priority, each SDK interface is connected.

3. The method according to claim 1, characterized in that The analyzing the interaction log data by the K-Means algorithm to determine the abnormal SDK interface when the abnormality occurs specifically includes: Determine multiple SDK interface indicator feature vectors according to the interaction log data; When an exception occurs, based on the SDK interface indicator feature vector, a K-Means algorithm is used to cluster multiple SDK interfaces to obtain a clustering result; Based on the clustering result, an abnormal cluster is determined, and an abnormal SDK interface is determined according to the abnormal cluster.

4. The method according to claim 1, characterized in that: The dynamically adjusting the calling timing and calling frequency of each SDK interface according to the business scenario and user behavior of the game specifically includes: Acquire SDK interface calling parameters according to the SDK configuration file, wherein the SDK interface calling parameters include the calling time and calling frequency of the SDK interface; Acquire business scenario features and user behavior features of the game, and perform correlation analysis on the business scenario features, the user behavior features, and the SDK interface call parameters to form a first training data set; The first training data set is used as input, and modeling training is performed through a decision tree algorithm to obtain an SDK interface call parameter adjustment model, where the SDK interface call parameter adjustment model is used to dynamically adjust the call parameters of the SDK interface according to different game environments and user needs.

5. The method according to claim 1, characterized in that By simulating various game scenarios and user operations, comprehensive automated testing of each SDK interface is performed, including: Acquire different game scene data and user operation data, and build a game SDK interface test environment using an automated testing framework based on the game scene data and user operation data; Based on the game SDK interface test environment, execute automated test cases on each SDK interface to obtain test results; Determine the failed test cases according to the test results; Based on the preset test feature vector, a support vector machine algorithm is used to determine the failure cause and repair solution of the failed test case.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Acquire historical SDK problem case data, and form a second training data set by performing data preprocessing and feature extraction on the historical SDK problem case data; Using the second training data set as input, performing modeling training through a machine learning algorithm, and obtaining an SDK problem classification model and a solution recommendation model respectively; Building an SDK problem knowledge base according to the SDK problem classification model and the solution recommendation model; When a new SDK problem appears, the cosine similarity algorithm is used to calculate the similarity between the new SDK problem and each SDK problem historical case in the SDK problem knowledge base to determine the problem type and solution of the new SDK problem.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Build an SDK version management platform based on the code differences and dependencies of each SDK version; When a problem occurs with the current SDK version, a version rollback operation is performed according to the SDK version management platform, and the problem is traced back to the current SDK version.

8. A processing system for game SDK docking and joint debugging, characterized in that: The system specifically comprises: The first processing module is used to connect various SDK interfaces by establishing an SDK interface dependency graph; The second processing module is used to obtain the interaction log data with the SDK client and the SDK server, analyze the interaction log data by using the K-Means algorithm, and determine the abnormal SDK interface when the abnormality occurs; The third processing module is used to collect the call data of each SDK interface in real time, and determine the joint debugging status and docking progress of all SDK interfaces through the call data; The fourth processing module is used to dynamically adjust the calling timing and calling frequency of each SDK interface according to the business scenario and user behavior of the game; The fifth processing module is used to perform comprehensive automated testing on each SDK interface by simulating various game scenarios and user operations.

9. A computer device, characterized in that: include: A memory, a processor, and a computer program stored in the memory. When the computer program is executed on the processor, the processing method for docking and debugging the game SDK as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by the processor, the processing method for game SDK docking and joint debugging as described in any one of claims 1 to 7 is implemented.

Images