Unity cross-platform SDK (Software Development Kit) intelligent access method, system and equipment and medium

Abstract

The invention discloses a Unity cross-platform SDK (Software Development Kit) intelligent access method, system and device and a medium, and the method specifically comprises the following steps: when a plug-in is loaded, extracting project feature data by scanning Unity engineering assets and a code structure; based on the project feature data, triggering an intelligent decision engine to generate an SDK combination weight matrix and a platform differentiation configuration parameter set; based on the SDK combination weight matrix and the platform differentiation configuration parameter set, marking SDK dependency conflict points and code compatibility risks to form a conflict marking result; based on the conflict marking result, calling an adaptation strategy of a repair rule base, and executing conflict repair; after conflict repair is completed, hierarchical code injection operation is executed; after code injection is completed, pressure testing is executed through Monte Carlo simulation, and a testing result is fed back to the intelligent decision engine for SDK recommendation weight optimization. According to the invention, a scientific SDK access scheme is provided for developers, the SDK access efficiency and quality are improved, and the manual intervention cost and the error rate are reduced.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a method, system, device and medium for intelligent access to the Unity cross-platform SDK. Background Technology

[0002] In the current mobile application development field, Unity, as a widely used game engine, is favored by developers due to its powerful cross-platform capabilities and rich functionality. When developing mobile applications using Unity, developers typically need to integrate various third-party SDKs to enrich the application's functionality. These include advertising SDKs for implementing ad placement to generate revenue, analytics SDKs for collecting user behavior data to optimize the application experience, and payment SDKs for supporting in-app purchase functionality.

[0003] However, manually integrating third-party SDKs is a complex and tedious process. For each platform's SDK (such as Android and iOS), developers need to perform a series of operations, including importing the corresponding configuration files, writing initialization code, and connecting to various interfaces. However, many game developers may not possess comprehensive Android and iOS development skills, leading to a significant learning curve when integrating SDKs. They need to spend considerable time and effort learning the development specifications and interface calling methods of different platforms to complete the SDK integration. This high integration cost not only increases the manpower required for development but also extends the project development cycle.

[0004] Secondly, manually integrating SDKs is time-consuming, severely impacting development efficiency. From importing SDK files and configuring related parameters to writing the calling code, each step requires manual operation by the developer, which is prone to errors. Moreover, when integrating multiple SDKs, this tedious manual operation becomes even more time-consuming, easily leading to project delays. Furthermore, while existing tools offer SDK management functions to some extent, most are quite basic and lack automated integration and configuration capabilities. Developers still need to manually complete a significant amount of configuration and coding work, failing to meet the need for efficient and accurate SDK integration. Summary of the Invention

[0005] The purpose of this invention is to provide a method, system, device and medium for intelligent access to Unity cross-platform SDK, which provides developers with a scientific SDK access solution, improves SDK access efficiency and quality, and reduces manual intervention costs and error rates, thereby solving at least one of the aforementioned problems in the prior art.

[0006] In a first aspect, the present invention provides a method for intelligent access to the Unity cross-platform SDK, the method specifically including: When the plugin is loaded, it extracts project feature data by scanning the Unity project assets and code structure. The project feature data includes game type tags, target platform SDK compatibility matrix and user profile features. Based on project feature data, the intelligent decision engine is triggered to call the pre-trained multi-objective optimization model to generate the SDK combined weight matrix and the platform-differentiated configuration parameter set; Based on the SDK combined weight matrix and the platform-differentiated configuration parameter set, a dependency graph is constructed. The existing code of the project is compared with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, and to form conflict marking results. Based on the conflict marking results, the adaptation strategy of the repair rule base is invoked to perform conflict repair; After resolving the conflicts, perform layered code injection. After the code injection is completed, test vectors for abnormal scenarios are constructed based on the SDK type. Stress tests are then performed using Monte Carlo simulation, and the test results are fed back to the intelligent decision engine for SDK recommendation weight optimization.

[0007] Secondly, this invention provides a Unity cross-platform SDK intelligent access system, the system specifically comprising: The feature extraction module is used to extract project feature data by scanning Unity project assets and code structure when the plugin is loaded. The project feature data includes game type tags, target platform SDK compatibility matrix and user profile features. The target optimization module is used to trigger the intelligent decision engine to call the pre-trained multi-objective optimization model based on project feature data, and generate the SDK combined weight matrix and platform-differentiated configuration parameter set; The conflict marking module is used to construct a dependency graph based on the SDK combined weight matrix and the platform's differentiated configuration parameter set, and compare the existing code of the project with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, thus generating conflict marking results. The conflict resolution module is used to call the adaptation strategy of the resolution rule base based on the conflict marking results and perform conflict resolution. The code injection module is used to perform layered code injection operations after conflict resolution is completed; The weight optimization module is used to construct abnormal scenario test vectors based on the SDK type after code injection is completed, perform stress tests through Monte Carlo simulation, and feed the test results back to the intelligent decision engine for SDK recommendation weight optimization.

[0008] Thirdly, the present invention provides a computer device, including: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the Unity cross-platform SDK smart access method as described in any of the above methods.

[0009] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the Unity cross-platform SDK intelligent access method as described in any of the above methods.

[0010] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention provides developers with a scientific SDK integration solution, which improves the efficiency and quality of SDK integration and reduces the cost of manual intervention and error rate.

[0011] 2. This invention avoids configuration errors caused by developers' lack of experience, reducing learning costs and manpower investment.

[0012] 3. This invention can quickly and accurately inject SDK-related code into the project, significantly improving the SDK integration efficiency and shortening the project development cycle.

[0013] 4. This invention utilizes a pre-trained multi-objective optimization model, comprehensively considering performance, cost, and stability objectives, to scientifically generate an SDK combination weight matrix and a platform-differentiated configuration parameter set, ensuring the optimality of the SDK access solution.

[0014] 5. This invention constructs a dependency graph and accurately marks SDK dependency conflict points and code compatibility risks, generating a report with risk levels to help developers quickly locate and resolve potential problems, thus ensuring project stability.

[0015] 6. This invention dynamically selects adaptation strategies and performs repair operations based on conflict marking results, provides targeted solutions for different types of conflicts, and re-detects after repair, ensuring that conflicts are completely resolved and improving SDK compatibility.

[0016] 7. This invention uses AST syntax tree parsing and model-generated code to perform layered code injection. It combines local and cloud models and switches them according to confidence level to ensure the accuracy and applicability of the generated code. At the same time, it verifies the scope and exception chain integrity, thereby improving code quality.

[0017] 8. This invention constructs abnormal scenario test vectors based on SDK type and performs stress tests, feeding back the test results to optimize SDK recommendation weights, making the SDK access solution more reliable and stable in practical applications, and continuously optimizing the access effect. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a method for intelligent access to the Unity cross-platform SDK provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a Unity cross-platform SDK intelligent access system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

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

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a Unity cross-platform SDK smart access method according to an embodiment of the present invention is shown below: S101, when the plugin is loaded, the project feature data is extracted by scanning the Unity project assets and code structure. The project feature data includes game type tags, target platform SDK compatibility matrix and user profile features.

[0027] In this embodiment, when the Unity engine starts and loads the SDK smart access plugin, the plugin first performs initialization. During initialization, the plugin creates an internal data structure to store the project feature data extracted during the scanning process, and simultaneously starts an independent scanning thread to avoid blocking the Unity main thread, ensuring the normal operation of the engine.

[0028] The scanning thread starts from the Assets directory of the Unity project and recursively traverses all subdirectories. During the traversal, it identifies different types of resource files, such as scene files, prefab files, material files, texture files, audio files, and script files. Based on the type and distribution of resource files, a preliminary judgment is made on the game type. For example, if the project contains a large number of 3D models, skeletal animation files, and complex physical material files, and the scene files contain multiple complex 3D scene elements, the game is preliminarily judged to be a 3D role-playing game; if the project mainly contains 2D sprite images, simple animation frame files, and 2D scene layout files, it is more likely to be judged as a 2D casual game. At the same time, the quantity and proportion of each type of resource file are counted as auxiliary criteria for determining the game type.

[0029] We conduct in-depth analysis of resources that are indicative of specific game genres. For example, strategy games may contain a large number of map data files and unit attribute configuration files; competitive games may have dedicated skill effect resources and leaderboard data templates. By identifying the existence and characteristics of these specific resources, we can further refine the game genre tags.

[0030] The scanning thread parses all found C# script files. Using Unity's reflection mechanism or a custom code parsing tool, it reads information such as class definitions, method declarations, and property definitions from the scripts. During script parsing, it focuses on code snippets relevant to the target platform. For example, it looks for code blocks using conditional compilation directives such as `#if UNITY_ANDROID` and `#if UNITY_IOS`, which typically contain platform-specific logic. By analyzing the quantity and complexity of platform-related code, a preliminary framework for a target platform SDK compatibility matrix is ​​constructed.

[0031] Analyze the user interaction-related code in the script, such as button click event handling, touch input response, and keyboard input processing. Based on the function and implementation of this code, infer the main methods and frequency of user interaction with the game, providing a basis for extracting user profile features. For example, the presence of a large amount of complex touch gesture recognition code may indicate that the game's user base prefers touch operations and has high requirements for the accuracy and variety of operations.

[0032] Based on the combined results of resource and code scanning, a predefined rule engine is used to finalize the game type label. The rule engine calculates the game type label that best matches the current project based on the weighting of different resource types and code characteristics. For example, if the resource scan shows a high proportion of 3D models and the code scan reveals complex 3D physics simulation code, along with a small amount of resources specific to strategy games, but the overall game leans more towards characteristics of a 3D action game, then the final game type label is determined to be "3D Action-Strategy Hybrid Game".

[0033] Based on the target platform-related code identified during code scanning, a more refined SDK compatibility matrix for each platform is created. This matrix records the supported SDK functional modules for each platform, potential compatibility issues, and any special configurations required. For example, if the code for the Android platform uses certain versions of the advertising SDK interface, while the iOS platform code uses different versions of the same advertising SDK interface, these differences are clearly marked in the compatibility matrix to provide a reference for subsequent SDK integration.

[0034] By combining the user interaction-related code analyzed during code scanning with potential user data configuration files in the project (such as user level settings, initial item configurations, etc.), user profile features are extracted. These features include user operating habits (e.g., preference for touch or keyboard controls), game preferences (e.g., preference for strategy or action games), and willingness to pay (inferred from initial item configurations and potential payment-related code). For example, if the project offers abundant initial items and multiple paid item purchase options, and the user interaction code contains numerous payment prompts and guidance logic, it can be inferred that the game's user base has a certain willingness to pay.

[0035] In this embodiment, the Unity project assets and code structure can be effectively scanned during plugin loading, and project feature data can be accurately extracted, providing basic support for subsequent SDK intelligent integration.

[0036] S102, based on project feature data, triggers the intelligent decision engine to call the pre-trained multi-objective optimization model, generating the SDK combined weight matrix and platform-differentiated configuration parameter set.

[0037] In this embodiment, the intelligent decision engine first cleans the received project feature data, removing potentially noisy and erroneous data. For example, for game type tags, it checks for ambiguous or contradictory tags; if found, it corrects or re-determines them based on other relevant feature data. For the target platform SDK compatibility matrix, it checks whether the data format is correct, ensuring that the compatibility information for each platform is complete and accurate. For user profile features, it removes obviously unreasonable or abnormal data points, such as extreme user operation frequencies.

[0038] Since the dimensions and value ranges of feature data for different types of projects can vary greatly, they need to be standardized to enable the model to better process them. For example, game type tags can be converted into numerical vectors using one-hot encoding so that the model can understand and process them. Numerical data in the target platform SDK compatibility matrix is ​​normalized according to its value range, mapping it to a specific interval (such as [0,1]). Numerical data in user profile features is also normalized, while categorical data undergoes appropriate encoding conversion.

[0039] The cleaned and standardized game type tags, target platform SDK compatibility matrix, and user profile features are fused together. They can be combined into a comprehensive feature vector using a simple concatenation method, or a weighted fusion or other more complex fusion method can be used based on the importance and correlation between the features to generate a comprehensive feature representation that fully reflects the project's characteristics, which serves as input to the multi-objective optimization model.

[0040] The intelligent decision engine selects a suitable pre-trained multi-objective optimization model according to preset rules. In this embodiment, the multi-objective optimization model can be an evolutionary algorithm-based model, such as the Non-Dominated Sorting Genetic Algorithm (NSGA-II). This algorithm can simultaneously optimize multiple objectives and find a set of non-dominated solutions, providing diverse options for SDK combination and configuration parameter selection. The intelligent decision engine loads the selected multi-objective optimization model from a pre-stored model library and performs initialization settings, including setting model parameters (such as population size, number of iterations, etc.) and optimization objectives.

[0041] Based on the actual needs of Unity cross-platform SDK integration, multiple optimization goals were set, including SDK function adaptability, platform compatibility, performance impact, and development cost.

[0042] Preprocessed project feature data is input into a pre-trained multi-objective optimization model, which then runs and optimizes. In each iteration, the model evaluates and selects individuals in the current population (i.e., different SDK combinations and configuration parameter schemes) based on the set optimization objective. New individuals are generated through genetic operations (such as selection, crossover, and mutation), gradually approaching the optimal solution. During iteration, the model continuously updates the fitness values ​​of individuals, calculating the merit of each individual based on the optimization objective. After multiple iterations, the model converges, yielding a set of non-dominated solutions that achieve a good balance across different optimization objectives.

[0043] From the non-dominated solutions obtained from the multi-objective optimization model, the final SDK combination is determined according to a certain selection strategy. The selection strategy can comprehensively consider the importance of each optimization objective; for example, the Analytic Hierarchy Process (AHP) can be used to determine the weights of different optimization objectives. Then, the comprehensive score of each non-dominated solution on each optimization objective is calculated, and the solution with the highest comprehensive score is selected as the final SDK combination. For the selected SDK combination, an SDK combination weight matrix is ​​generated based on the importance and contribution of each SDK in the combination. The weights can be determined by analyzing factors such as the functional coverage and performance impact of the SDKs. For example, if an SDK provides the core functionality required by the project and has a small impact on performance, it can be assigned a higher weight.

[0044] Based on the target platform SDK compatibility matrix and the final SDK combination, differentiated configuration parameter sets are generated for different platforms. For each platform, the compatibility and special requirements of the selected SDK on that platform are analyzed. Combined with platform-related information from the project feature data, suitable configuration parameters for that platform are determined. For example, for the Android platform, specific permission settings and advertising ID acquisition methods may need to be configured; for the iOS platform, configurations may need to comply with Apple's App Store review rules. The configuration parameters for each platform are then compiled into a set, forming a platform-differentiated configuration parameter set.

[0045] In this embodiment, multiple factors such as game type, target platform compatibility, and user profile are fully considered. A multi-objective optimization model is used to balance multiple optimization objectives, which improves the adaptability and efficiency of SDK integration, reduces development costs and compatibility risks, and provides strong support for the intelligent integration of Unity cross-platform SDK.

[0046] S103 constructs a dependency graph based on the SDK combined weight matrix and platform-differentiated configuration parameter set, and compares the existing code of the project with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, forming conflict marking results.

[0047] In this embodiment, based on the generated SDK combination weight matrix, all SDKs are sorted in descending order of weight. A weight threshold is set, which can be determined based on the actual needs and experience of the project, such as taking the average weight of all SDKs or setting a fixed value according to the project's requirements for SDK importance. SDKs with weights higher than this threshold are selected as the main SDK set for constructing the dependency graph. Simultaneously, SDKs with weights close to the threshold and possessing a certain level of importance in the project's functionality can also be included in the set, ensuring that no key SDKs are overlooked.

[0048] By combining platform-specific configuration parameter sets, examine the configuration of SDKs across different platforms. Some SDKs may require additional dependency libraries or specific configuration options on one platform, but not on others. Adjust the selected SDK set based on this configuration information. For example, if an SDK on iOS requires linking to a specific system library, but not on Android, then when building dependencies, explicitly mark the SDK's special dependencies on iOS to ensure that the dependency graph accurately reflects the actual dependencies of SDKs on each platform.

[0049] For each selected SDK, dependency information provided in its official documentation is collected. This information includes other SDKs and library files that it directly depends on, as well as related components that it indirectly depends on. For example, an advertising SDK might directly depend on a network request library, which in turn might indirectly depend on some cryptographic algorithm libraries. By deeply analyzing these dependencies, a complete SDK dependency tree structure is constructed. Simultaneously, version compatibility between SDKs is considered, and the version range requirements of other components that each SDK depends on are recorded to ensure that version conflicts do not occur during integration.

[0050] The dependencies between SDKs are displayed graphically, forming a dependency graph. This can be done using nodes and edges, where each node represents an SDK or dependent component, and edges represent dependencies, pointing from the dependent component to the depended-on component. The graph differentiates dependencies across different platforms, using different colors or line styles to represent dependencies on Android and iOS. Nodes are also labeled with key information such as the SDK name, version, and weight, allowing developers to intuitively understand the entire SDK dependency system.

[0051] The bytecode static analysis engine first loads the bytecode files generated by compiling the Unity project. These bytecode files contain compiled information about all the code in the project. By analyzing the bytecode, key information such as code structure, class definitions, and method calls can be obtained without directly processing the source code, thus improving the efficiency and accuracy of the analysis.

[0052] The loaded bytecode is parsed to identify the libraries, SDKs, and their call relationships used in the project. For example, by analyzing method call instructions, it determines which third-party library methods are called, thus identifying the dependencies between the project's existing code and external components. Simultaneously, version information for each component used in the project is recorded for comparison with the dependency information of SDKs to be integrated later.

[0053] The existing code dependencies in the project, obtained from the bytecode static analysis engine, are compared with the constructed dependency graph. This checks for duplicate dependencies, where a library file is already included in the project, but the integrated SDK depends on a different version of the same library. For example, if the project already uses version 1.0 of a network request library, and the newly integrated advertising SDK depends on version 2.0 of the same network request library, this could cause a dependency conflict. Simultaneously, it checks for circular dependencies, where SDK dependencies form a closed loop, preventing proper loading and initialization. Detected dependency conflicts are marked in the dependency graph, recording specific information such as the conflicting component names and version differences.

[0054] Analyze the code-level compatibility risks between the project's existing code and the SDK to be integrated. Consider whether the SDK's interface calling methods are compatible with the project's existing code; for example, whether the SDK's interface parameter types and return value types are consistent with the code in the project that calls the interface. Simultaneously, check the compatibility of the system APIs used by the SDK on the target platform. Some SDKs may use newer system APIs, while the target platform version supported by the project may be older and unable to provide these APIs, leading to code compatibility issues. Mark the assessed code compatibility risks at the corresponding locations in the dependency graph and describe the specific details and potential impact of the risks in detail.

[0055] The dependency conflict points and code compatibility risk information marked in the dependency graph are organized and summarized to form a conflict marking result document. This document presents all detected issues in a clear and easy-to-understand manner, including the type of issue (dependency conflict or code compatibility risk), the specific SDK or component involved, the platform where the issue occurred (Android or iOS), and a detailed description and potential impact of the issue. Each issue is assigned a unique identifier to facilitate subsequent conflict remediation and tracking management. The conflict marking results will provide crucial information for subsequent conflict remediation and SDK integration work.

[0056] In this embodiment, developers can identify potential problems in advance before integrating the SDK, take targeted measures to fix them, improve the success rate and efficiency of SDK integration, and reduce project delays and increased development costs caused by dependency conflicts and code compatibility issues.

[0057] S104: Based on the conflict marking results, call the adaptation strategy of the repair rule base to perform conflict repair.

[0058] In this embodiment, key information is extracted from the conflict flagging results document, including the type of conflict (dependency conflict or code compatibility risk), the specific SDK or component involved, the platform on which the problem occurred (Android or iOS), a detailed description of the conflict (such as version differences of dependencies, interface incompatibility, etc.), and the location of the problem in the project (such as a specific code file, class, or method). This information will serve as an important basis for subsequent matching and remediation strategies and the execution of remediation operations.

[0059] The extracted information is categorized based on the type and characteristics of the conflicts. Dependency conflicts are further subdivided into subtypes such as version conflicts, duplicate dependencies, and circular dependencies. For example, if the tagging results show that a library version dependent on by an SDK is incompatible with an existing version in the project, it is classified as a version conflict; if a library has already been introduced into the project, and a new SDK depends on a different version of the same library, it is classified as a duplicate dependency; if dependencies between SDKs form a closed loop, causing failure to load and initialize correctly, it is classified as a circular dependency. Code compatibility risks are categorized based on the aspects of incompatibility, such as incompatible API calls or system API incompatibility.

[0060] The rule base for fixing conflicts is pre-built and includes adaptation strategies for various potential conflicts. These strategies are based on extensive practical experience, the official SDK documentation, and industry best practices. Each strategy has clearly defined applicable conditions and operational steps. For example, for version conflicts, strategies might include upgrading existing library versions in the project, downgrading SDK dependency library versions, or finding compatible intermediate versions; for incompatible API calls, strategies might include modifying project code to adapt to the new API, or using the adapter pattern for API conversion.

[0061] Based on the conflict classification results, a matching adaptation strategy is searched in the remediation rule base. The matching process employs a rule-based reasoning method, comparing key conflict characteristics (such as conflict type and involved components) with policy conditions in the rule base. For example, if the conflict involves incompatibility of an SDK's interface calls on the Android platform, the rule base is searched for strategies applicable to the Android platform that address the SDK's interface incompatibility issue. If multiple matching strategies exist, they are ranked according to priority, with the highest-priority strategy being prioritized for remediation. Strategy priority can be set based on factors such as strategy reliability, implementation difficulty, and impact on the project.

[0062] Before performing the repair operation, back up the project to prevent damage caused by unexpected situations during the repair process. At the same time, prepare the necessary resources and tools according to the matched adaptation strategy, such as specific versions of library files and code modification templates. For example, if the strategy requires upgrading a certain library version, the new version of the library file must be downloaded and prepared in advance.

[0063] Perform conflict remediation operations according to the specific steps of the adaptation strategy. For dependency conflicts, adjust dependencies according to the strategy requirements, such as modifying project configuration files to specify the correct library versions, deleting duplicate dependent library files, and breaking circular dependency chains. For code compatibility risks, modify project code according to the strategy, such as modifying API call methods, adding compatibility code layers, and replacing incompatible system API calls. During the execution of these operations, record the details of each step and its results for subsequent review and verification.

[0064] During the remediation process, the project's status and operation are monitored in real time to ensure that the remediation does not negatively impact other parts of the project. For example, after modifying code, a compilation check is performed immediately to see if any new compilation errors exist; after adjusting dependencies, the relevant components are loaded to verify that the dependencies have been correctly resolved. If new problems are discovered or the remediation does not achieve the expected results, the remediation is stopped promptly, and the adaptation strategy is reassessed and adjusted.

[0065] After the repair operation is completed, all conflict points marked in the conflict tagging results are verified one by one to ensure that each conflict has been completely resolved. For example, for dependency conflicts, check whether version differences, duplicate dependencies, and circular dependencies have been eliminated in the dependency graph; for code compatibility risks, rerun the relevant functions of the project to verify whether the interface calls are normal and whether the system APIs are compatible.

[0066] A comprehensive testing process was conducted on the repaired project, including functional testing, performance testing, and compatibility testing. Functional testing ensured that all functions of the project operated normally and that no new functional issues were introduced due to the conflict fix. Performance testing checked whether the project's performance metrics (such as startup time, memory usage, frame rate, etc.) were within reasonable ranges and whether the performance degradation was caused by the fix. Compatibility testing verified the project's compatibility with different platforms (Android and iOS) and devices, ensuring that the repaired project could run stably in various environments.

[0067] The repair results are meticulously recorded, including the type of conflict repaired, the adaptation strategy employed, the repair steps, and the verification results. These records are then fed back to the intelligent decision engine and the repair rule base, providing valuable experience for subsequent SDK integration and conflict repair. Simultaneously, the repair rule base is updated and optimized based on the repair results, continuously refining the adaptation strategy and improving the efficiency and accuracy of conflict repair.

[0068] This embodiment improves the automation and accuracy of conflict resolution, reduces the workload and error probability of developers manually fixing conflicts, and shortens the project development cycle. Simultaneously, real-time monitoring and verification, along with comprehensive evaluation of the resolution results, ensure the quality and stability of the project after resolution, providing a reliable guarantee for the intelligent integration of the Unity cross-platform SDK.

[0069] S105, after the conflict is resolved, perform the layered code injection operation.

[0070] In this embodiment, a detailed scan and analysis of the Unity project code after conflict resolution is performed to identify the core architecture and main functional modules of the project. Key files and classes are identified, such as the game's main logic class, scene management class, and resource loading class. The call relationships and dependencies between these classes and files are understood, and a code call diagram of the project is drawn to determine the location and method of code injection later.

[0071] The SDK code is categorized by function; for example, an advertising SDK can be divided into an ad display module, an ad loading module, and an ad click statistics module. The entry and exit points of the SDK code are analyzed, i.e., the relevant code locations for SDK initialization, function calls, and result returns. Simultaneously, the external libraries and system resources that the SDK code depends on are recorded to ensure that these dependencies are handled correctly during the injection process.

[0072] Choose a suitable code injection tool or develop a custom injection script. The code injection tool should be able to parse, modify, and save the Unity project code, accurately identify the code structure and syntax, and ensure that the injection process does not disrupt the original code's logic. Custom injection scripts can be written according to specific layering strategies and injection rules to achieve precise injection at different levels of code.

[0073] The base layer is primarily responsible for handling operations related to the Unity engine's underlying structure and system environment, providing basic support for upper-layer functions. For SDK components that need to be initialized at the initial stage of game startup, such as the data collection initialization code of the analytics SDK and the security authentication code of the payment SDK that partially depends on underlying system functions, these are injected into the Unity project's base startup script. These scripts typically execute at the very beginning of game loading, ensuring that the SDK completes necessary initialization work before the game runs, providing a stable environment for subsequent function calls.

[0074] The functional layer is the core layer for implementing specific business functions. Based on the functional characteristics of different SDKs, relevant code is injected into the corresponding functional modules. For example, the ad display code from the advertising SDK is injected into the scripts related to the ad display area in the game scene; the user behavior data collection code from the analysis SDK is injected into the key interactive logic code of the game, such as when players click buttons or enter new scenes, to accurately collect user behavior data. For the payment SDK, its payment function call code is injected into the scripts related to the in-game purchase process, achieving seamless integration with the game's business.

[0075] The interface layer primarily provides a unified interface for other modules to call, achieving decoupling and interaction between different modules. A clear set of interface specifications is defined for each SDK, encapsulating the SDK's core functionality within these interfaces. This interface code is then injected into the interface management module of the Unity project. Other modules use the SDK's functionality by calling these interfaces without directly coupling with the SDK code. This not only improves code maintainability and scalability but also facilitates future SDK upgrades or replacements by only modifying the interface implementation, without altering the code that calls the interfaces.

[0076] During code injection, the execution of the injection tool or script is monitored in real time, recording information such as the location and line number of the injected code. Simultaneously, the compilation process of the Unity project is monitored to check for compilation errors caused by code injection. If compilation errors are found, the injection process is stopped immediately, the cause of the error is analyzed, and the injection strategy or injection code is adjusted to ensure the injection process proceeds smoothly.

[0077] After injection, compatibility verification is performed between the injected code and the original project code. Unit tests and integration tests are used to check whether the injected code functionally cooperates with the original code and whether there are any logical conflicts or data inconsistencies. For example, for the code injected into the analysis SDK, it is verified whether the data it collects can be correctly transmitted to the data analysis server without affecting the accuracy and integrity of the original game data.

[0078] In this embodiment, SDK code can be precisely and systematically injected into appropriate locations based on the characteristics of the Unity project and SDK code, improving the accuracy and efficiency of code injection. The application of a layered strategy makes the code structure clearer, facilitating subsequent maintenance and expansion. Simultaneously, real-time monitoring and verification during the injection process, along with comprehensive testing after injection, ensure that the injected code is compatible with the original project code and conflict-free, that SDK functionality is implemented correctly, and that the overall performance of the project is not affected, providing a reliable guarantee for the intelligent integration of the Unity cross-platform SDK.

[0079] S106. After the code injection is completed, an abnormal scenario test vector is constructed according to the SDK type. Stress tests are performed through Monte Carlo simulation, and the test results are fed back to the intelligent decision engine for SDK recommendation weight optimization.

[0080] In this embodiment, scenarios such as unstable network connection, high network latency, and network interruption are simulated. For example, different network latency times (such as 100ms, 500ms, 1000ms, etc.) are set, and the network connection is disconnected at different times to test whether the advertising SDK's ad loading, display, and click feedback functions are normal when the network is abnormal.

[0081] Consider scenarios where ad resources fail to load, such as ad images failing to download or ad video formats being incompatible. Test the ad SDK's ability to handle abnormal resources by modifying the ad resource URL or simulating server-returned error data, and whether it can provide reasonable error messages or automatically retry.

[0082] Simulate abnormal user actions during ad display, such as rapidly clicking ads consecutively or switching applications while ads are loading. Observe whether the ad SDK can correctly handle these abnormal actions and avoid problems such as chaotic ad display or incorrect data statistics.

[0083] Simulate abnormal situations that may occur during data acquisition, such as the inability to acquire data from device sensors or incorrect format of user input data. For example, for an analysis SDK that collects user geolocation information, simulate a situation where the device's positioning function fails to test whether the SDK can properly handle missing geolocation data, and whether it will use default values ​​or perform data completion operations.

[0084] Consider potential problems during data transmission, such as slow data transmission due to network congestion and packet loss. By setting different network bandwidth limits and packet loss rates, test and analyze the reliability of the SDK's data transmission mechanism and whether it can guarantee data integrity and accuracy.

[0085] Simulate errors that may occur during data analysis, such as errors in the analysis algorithm or mismatches in the data model. By modifying the configuration parameters of the analysis SDK or injecting erroneous data, test the SDK's fault tolerance and error handling mechanisms when encountering abnormal data analysis situations.

[0086] Simulate various anomalies that may occur during the payment process, such as payment request timeouts and incorrect payment results. For example, set different timeout periods during the payment process to test how the payment SDK handles timeouts, whether it can automatically retry or prompt the user of payment failure. Consider potential problems with the payment account, such as insufficient account balance or account freezing. By simulating these abnormal account states, test the payment SDK's ability to handle abnormal accounts, whether it can provide accurate error messages and guide the user to take appropriate actions. Simulate security threats during the payment process, such as man-in-the-middle attacks and data tampering. By injecting malicious data or simulating attack behaviors, test the effectiveness of the payment SDK's security protection mechanisms and whether they can protect the security of the user's payment information.

[0087] Using the Monte Carlo simulation method, a large number of random test cases are generated based on the constructed abnormal scenario test vectors. According to the probability distribution of each abnormal scenario, different combinations of abnormal parameters and conditions are randomly selected to generate test cases with randomness and diversity. For example, for the network latency abnormal scenario of the advertising SDK, test cases with different latency times are randomly generated based on the actual distribution of network latency to simulate the real network environment.

[0088] The generated random test cases are applied to the Unity project after integrating the SDK to perform stress testing. During the test, multiple test threads are started simultaneously to simulate concurrent access by multiple users, increasing the pressure and intensity of the test. Various performance indicators of the project, such as response time, throughput, and resource utilization, as well as the functional operation of the SDK, such as ad display success rate, data analysis accuracy, and payment success rate, are monitored in real time.

[0089] During stress testing, detailed test data, including performance metrics and functional operation data, were recorded. The recorded data was analyzed to calculate statistical measures such as the average, standard deviation, maximum, and minimum values ​​of each metric, evaluating the SDK's performance and functional stability under various abnormal scenarios. Simultaneously, errors and anomalies encountered during testing were analyzed to identify the root causes and influencing factors.

[0090] The data and analysis results obtained from stress testing are organized and formatted into a data format that the intelligent decision engine can recognize. For example, performance index data and functional operation data are organized into tabular form, and the abnormal scenarios and parameters corresponding to each test case are marked.

[0091] An SDK recommendation weight optimization model is established within the intelligent decision engine. This model considers multiple factors, such as SDK performance, functional stability, and project compatibility. Based on stress test results, corresponding weights and scoring criteria are assigned to each factor; for example, SDKs with better performance and more stable functionality receive higher recommendation weights.

[0092] The compiled test results are input into the weight optimization model of the intelligent decision engine. The engine dynamically adjusts and optimizes the recommendation weights of the SDKs based on the model's algorithm. Based on the strengths and weaknesses of the SDKs revealed in the test results, the recommendation weights of high-performing SDKs are increased, while the recommendation weights of problematic SDKs are decreased. Simultaneously, considering the characteristics of different projects and user needs, the weight optimization results are further adjusted to ensure that the recommended SDKs better meet the actual needs of the projects.

[0093] In some embodiments, step S101 above, where the process of extracting project feature data by scanning Unity project assets and code structure when the plugin is loaded, specifically includes: When the plugin is loaded, it scans the resources in the Unity project's Assets directory and matches file path features based on a preset naming rule set to generate game type probability tags. Based on the probability tags of game type, the PlayerSettings configuration of the project is parsed to determine the target platform, and a platform-SDK compatibility matrix is ​​generated by associating it with the historical SDK database. If historical analysis SDK data exists, extract device performance and behavior characteristics; otherwise, call the device metadata simulator to generate a default profile vector. Aggregate game type tags, compatibility matrix, and user profile features to output project feature data.

[0094] This embodiment conducts an in-depth analysis and research on common Unity game types, summarizing the typical characteristics of various games in terms of resource file naming, directory structure, etc. For example, for role-playing games (RPGs), character model files may typically begin with "role_", and scene files may be stored in the "Scenes / RPG" directory; for casual puzzle games, image resources may often be named with "puzzle_", and script files are concentrated in the "Scripts / Puzzle" directory. Based on these characteristics, a detailed and comprehensive set of preset naming rules is formulated. The rule set clearly defines the file path characteristic patterns corresponding to different game types, including filename wildcards, directory hierarchy, and other information.

[0095] When the plugin loads, a scan of the Unity project's Assets directory begins. A depth-first or breadth-first traversal algorithm is used to sequentially visit all subdirectories and files within the Assets directory. During the scan, the complete path information for each file is recorded, including the filename, file extension, and the directory hierarchy. The scanned file path information is then matched against patterns in a preset naming rule set. For each file, its path is checked to see if it conforms to a characteristic pattern of a certain game genre.

[0096] The number of matching files for each game type is counted, and the probability of that game type is calculated based on the proportion of matching files to the total number of files. For example, if 100 files are found during the scan, and 30 of them match the feature pattern of the RPG game type, then the probability of the RPG game type is 30%. The calculated probabilities of each game type are then organized to generate game type probability labels, which contain multiple game types and their corresponding probability values.

[0097] Based on the generated game type probability labels, the PlayerSettings configuration of the Unity project is further analyzed. PlayerSettings is an important configuration module in Unity used to configure the project's running parameters on different platforms. By calling the API interfaces provided by Unity or directly reading the relevant PlayerSettings configuration files, information about the target platforms supported by the project, such as Android, iOS, and Windows, can be obtained.

[0098] Establish and maintain a historical SDK database that records compatibility information for various SDKs on different platforms, including SDK version, supported platforms, and compatibility with different game genres. Perform a correlation query between the parsed target platform information and the historical SDK database, filtering out a list of SDKs potentially relevant to the project based on game genre probability tags.

[0099] Based on the results of the related queries, a platform-SDK compatibility matrix is ​​constructed. The rows of the matrix represent the target platform, and the columns represent possible SDKs. Each element in the matrix represents the compatibility status of the SDK on the corresponding platform, such as "compatible," "incompatible," or "partially compatible." Furthermore, historical project data and expert experience can be combined to assign a weight value to each compatibility status to more accurately reflect the degree of compatibility between the SDK and the platform.

[0100] Check if historical analytics SDK data exists in the Unity project. Historical analytics SDK data is typically collected during the early stages of a project's operation by analyzing user device information and usage behavior. You can determine the existence of this data by querying specific data storage files or database tables within the project.

[0101] If historical SDK analysis data exists, device performance and behavioral characteristics are extracted from this data. Device performance characteristics may include device model, processor performance, memory size, graphics card performance, etc.; user behavioral characteristics may include user usage duration, usage frequency, frequently used function modules, operating habits, etc. The extracted feature data is cleaned and preprocessed to remove invalid data and outliers, ensuring the accuracy and reliability of the data.

[0102] If historical analysis SDK data is unavailable, the device metadata simulator is invoked to generate a default profile vector. The device metadata simulator is a simulation tool developed based on the performance parameters and usage behavior patterns of mainstream devices in the market. The simulator can generate a series of representative device performance data and user behavior data, and organize this data into a default profile vector according to a predetermined format. The default profile vector should cover common device performance indicators and user behavior characteristics to simulate real user behavior as accurately as possible.

[0103] The generated game type tags, platform-SDK compatibility matrix, and user profile features are aggregated. A unified data structure is used to integrate these three parts of information; for example, JSON or XML format data files can be used to store project feature data. The identifiers and content of each part are clearly defined in the data file to ensure that the subsequent intelligent decision engine can accurately read and parse this data. The final output is a data file containing complete project feature data, providing foundational support for the subsequent SDK intelligent integration process.

[0104] In some embodiments, step S102 above, which involves triggering the intelligent decision engine to call a pre-trained multi-objective optimization model based on project feature data to generate an SDK combined weight matrix and a platform-differentiated configuration parameter set, specifically includes: Based on project feature data, the intelligent decision engine is triggered to call a pre-trained multi-objective optimization model to optimize performance, cost and stability objectives. The multi-objective optimization model includes a feature encoding layer, a cross-analysis layer and a decision output layer. The game type label is mapped to a 128-dimensional vector through the feature encoding layer, the target platform SDK compatibility matrix and user profile features are fused through the cross-analysis layer, and the SDK combined weight matrix is ​​generated through the decision output layer. Based on the SDK combined weight matrix, dynamically construct a set of platform-differentiated configuration parameters.

[0105] In this embodiment, a dedicated triggering module is set up in the intelligent decision engine. This module monitors the input of project feature data in real time. Once complete project feature data is detected as input, the triggering module immediately starts the pre-trained multi-objective optimization model and passes the prepared project feature data as input to the model.

[0106] Performance targets primarily focus on the impact of SDK integration on the runtime efficiency of Unity projects, including but not limited to metrics such as game frame rate, loading time, and response speed. Reasonable performance thresholds and optimization directions should be set based on the project type and expected operating environment. For example, for an action game, the requirement is to maintain a stable frame rate above 60 FPS and a loading time of no more than 3 seconds during gameplay.

[0107] The cost target covers the usage costs of the SDKs, such as licensing fees and traffic costs. Cost information for various SDKs on the market is collected, and a cost cap is set for each SDK based on the project budget. Simultaneously, the long-term usage and maintenance costs of the SDKs are considered to ensure that the most cost-effective SDK combination is selected while meeting project requirements.

[0108] The stability goals focus on the reliability and compatibility of the SDK, requiring it to run stably on different platforms and devices, reducing the occurrence of crashes, freezes, and other anomalies. Based on historical project data and industry experience, stability metrics for the SDK are set, such as a crash rate of less than 0.1% and a compatibility test pass rate of over 95%.

[0109] The pre-trained multi-objective optimization model employs advanced optimization algorithms, such as genetic algorithms and particle swarm optimization, to balance and optimize performance, cost, and stability objectives. The model continuously adjusts the SDK's combination methods and configuration parameters to find optimal or near-optimal solutions across multiple objectives. During the optimization process, the model considers the interactions and constraints between various objectives to ensure that the generated solution possesses comprehensive advantages.

[0110] The feature encoding layer receives game type labels as input and employs embedding techniques from deep learning to map discrete game type labels into 128-dimensional continuous vectors. This mapping method transforms the semantic information of game types into a numerical form that can be processed by a computer, while preserving the similarities and differences between game types. For example, role-playing games (RPGs) and strategy games (SLGs) may be relatively close in vector space, while casual games and competitive games are much farther apart. The resulting 128-dimensional vectors are then standardized, such as using Z-score standardization, to adjust the mean to 0 and the standard deviation to 1. Standardization eliminates differences in the numerical range of different game type labels, improving the training effect and stability of the model.

[0111] The cross-analysis layer receives the game type vector output from the feature encoding layer, along with the target platform SDK compatibility matrix and user profile features. The target platform SDK compatibility matrix is ​​preprocessed, transforming it into a numerical form suitable for model processing; for example, compatibility states (compatible, incompatible, partially compatible) are mapped to values ​​such as 1, 0, and 0.5, respectively. Feature selection and dimensionality reduction are performed on the user profile features to extract key features relevant to SDK selection and configuration. Deep learning models, such as attention mechanisms or multilayer perceptrons (MLPs), are used to cross-fuse and analyze the game type vector, target platform SDK compatibility matrix, and user profile features. Attention mechanisms automatically learn the importance weights between different features, highlighting features that have a significant impact on SDK selection and configuration. Through cross-fusion analysis, the model can comprehensively consider multiple factors such as game type, platform compatibility, and user features, providing more comprehensive and accurate information for subsequent decision outputs.

[0112] The decision output layer receives the fusion features from the cross-analysis layer and uses a fully connected layer and a Softmax activation function to generate an SDK combination weight matrix. Each row of the SDK combination weight matrix represents an SDK, and each column represents a possible combination scheme. The element values ​​in the matrix represent the weight of that SDK in the corresponding combination scheme. The larger the weight value, the higher the importance of that SDK in the combination. The generated SDK combination weight matrix is ​​normalized to ensure that the sum of the weight values ​​in each column is 1. Normalization makes the weight values ​​more intuitively reflect the relative importance of the SDK in the combination, facilitating the subsequent construction of platform-differentiated configuration parameter sets.

[0113] Based on the characteristics of the target platform and the functional requirements of the SDK, a framework for a platform-specific configuration parameter set was designed. The parameter set framework consists of two parts: general configuration parameters and platform-specific configuration parameters. General configuration parameters are applicable to all platforms, such as SDK initialization parameters and log level settings; platform-specific configuration parameters are customized for different platforms, such as permission request configurations for Android and push notification settings for iOS.

[0114] Based on the generated SDK combination weight matrix, and combined with the documentation and configuration instructions for each SDK, a platform-specific configuration parameter set is dynamically generated. For each SDK, the priority and value of its configuration parameters are adjusted according to its weight value in the combination. For example, SDKs with higher weights can be given more detailed configuration parameter settings to ensure their performance and functionality are fully utilized; SDKs with lower weights can use default configurations or simplified configurations to reduce costs and complexity.

[0115] After generating a platform-specific configuration parameter set, parameter verification and optimization are performed. By simulating different platform and device environments, the configuration parameters are tested and verified to ensure the SDK functions correctly under various conditions. Based on the test results, the configuration parameters are adjusted and optimized to resolve potential compatibility issues or performance bottlenecks.

[0116] In this embodiment, the SDK combination weight matrix comprehensively considers multiple objectives such as performance, cost, and stability, enabling the selection of the optimal SDK combination scheme for the project; the platform-differentiated configuration parameter set is customized for the characteristics of different platforms, ensuring that the SDK can run efficiently and stably on various platforms.

[0117] In some embodiments, step S103 above, which involves constructing a dependency graph based on the SDK combined weight matrix and the platform-differentiated configuration parameter set, and comparing the existing code of the project with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, thereby forming conflict marking results, specifically includes: Based on the SDK combined weight matrix, a dependency graph with SDK as nodes is created; Based on the platform's differentiated configuration parameter set, dependency edges between nodes are established by recursively traversing the SDK declaration file, and version constraint attributes are attached to each dependency edge. Once the graph is built, the SDK dependency library and project code are compiled into intermediate bytecode. By comparing the bytecode symbol table of the SDK dependency library with the project bytecode, the conflict type is marked. The conflict types include version conflict, symbol conflict and resource conflict. Generate a conflict labeling report with risk level tags based on the conflict type.

[0118] In this embodiment, all relevant SDK information is extracted from the SDK combination weight matrix generated by the intelligent decision engine. The SDK combination weight matrix contains the various SDKs selected for the project and their weights in the combination. By traversing the rows or columns of the matrix, key information such as SDK names and version numbers can be accurately obtained. For each SDK, a corresponding node is created in the dependency graph. Nodes are stored in a structured data format, containing not only the SDK name and version number but also its weight information for subsequent analysis and processing. For example, a dictionary or object containing fields such as "SDK name," "version number," and "weight" can be used to represent each node.

[0119] The configuration information relevant to the current analysis platform is extracted from the previously generated set of platform-differentiated configuration parameters. The set of platform-differentiated configuration parameters specifies the SDK configuration in detail for different platforms (such as Android, iOS, etc.), including SDK initialization parameters, dependencies, etc.

[0120] For each SDK, locate its corresponding declaration file (e.g., AndroidManifest.xml for Android, Info.plist for iOS). Use a recursive algorithm to traverse the contents of the declaration file, paying particular attention to the dependency definitions. For example, in the AndroidManifest.xml file, parse... <uses-library>and <uses-permission>The tag is used to obtain the dependency information of the SDK on other libraries and permissions.

[0121] When an SDK is found to depend on another SDK in the declaration file, a directed edge is established in the dependency graph from the dependent SDK node to the depended SDK node. At the same time, version constraint information is extracted from the declaration file and attached to the dependency edge. The version constraint information can be a specific version number range, such as "[1.0, 2.0)", indicating that the dependent SDK version must be between 1.0 (inclusive) and 2.0 (exclusive).

[0122] The SDK dependent libraries and project code are compiled into intermediate bytecode. For different platforms and programming languages, the corresponding compilation tools and processes are used. For example, on the Android platform, the javac and dx tools in the Android SDK are used to compile Java code into Dex bytecode; on the iOS platform, the clang compiler in Xcode is used to compile Objective-C or Swift code into Mach-O format bytecode.

[0123] Symbol table information is extracted from the compiled intermediate bytecode using bytecode analysis tools. The symbol table contains various symbols defined and referenced in the code, such as class names, method names, field names, etc. For Dex bytecode, the baksmali tool for Android can be used to disassemble it into smali code, and then the symbol information can be extracted from the smali code; for Mach-O bytecode, tools such as MachOView can be used for parsing and symbol extraction.

[0124] By comparing the version information in the SDK dependent library bytecode symbol table with the version constraints recorded in the dependency graph, it is checked whether there is a version incompatibility. If the actual version of the SDK dependent library is not within the version range specified by the dependency edge, it is marked as a version conflict. For example, if the dependency edge requires the version of SDK A to be between [1.0, 2.0), and the actual version of SDK A introduced is 2.1, it is determined to be a version conflict.

[0125] It is checked whether there are symbols with the same name in the project bytecode and the SDK dependent library bytecode. If there are symbols with the same name, and the definition or use of these symbols is incompatible, it is marked as a symbol conflict. For example, a class named "Utils" is defined in the project code, and a class with the same name is also defined in a certain SDK dependent library, and the functionality of the two classes is different, which may cause a symbol conflict.

[0126] For SDKs that involve resource files (such as images, layout files, etc.), check if there are naming conflicts between the project resource files and the SDK resource files. If there are resource files with the same name, and the resource content or purpose is different, it is marked as a resource conflict. For example, there is a picture resource named "icon.png" in the project, and a certain SDK also contains a picture resource with the same name, but the styles or purposes of the two pictures are different, which will cause a resource conflict.

[0127] According to the type and severity of the conflict, assign a corresponding risk level label to each conflict marker. For example, version conflicts may cause the project to malfunction, so the risk level can be set to "high"; symbol conflicts may affect the normal use of part of the function, so the risk level is set to "medium"; resource conflicts may only affect the display effect of the interface, so the risk level is set to "low".

[0128] Organize all marked conflict information into a report in a certain format. The report content includes the type of conflict, the name and version number of the involved SDK, the specific location of the conflict (such as code file name, line number, etc.), and the risk level label. For example, the report can be presented in the form of a table, with each row representing a conflict marker, and the columns recording the above related information.

[0129] Output the generated conflict marker result report to the specified file or interface for developers to view and handle. The report can be saved as a text file, an HTML file, or displayed through a graphical interface, so that developers can intuitively understand the dependency conflicts and compatibility risks in the project and take appropriate measures in a timely manner.

[0130] In some embodiments, in step S104, based on the conflict marker results, the adaptive strategy of the repair rule library is called to perform conflict repair, specifically including: Based on the conflict marker results, retrieve the repair rule library and dynamically select the adaptive strategy according to the conflict type and risk level; After the strategy is selected, perform the repair operation corresponding to the conflict type; For version conflicts, force the uniform SDK version number in the dependency declaration file; For symbol conflicts, add override annotations or rename method signatures; For resource conflicts, rewrite the resource ID generation rule and synchronize the update; After the repair is completed, re-trigger the conflict detection, and if the conflict is not eliminated, roll back the repair and select a suboptimal strategy.

[0131] In this embodiment, the conflict marking result report is parsed in detail to extract key information, including conflict type (version conflict, symbol conflict, resource conflict) and risk level (high, medium, low). For example, read the conflict type field and risk level field of each row record from the report table and store them in a data structure in memory for subsequent processing.

[0132] According to the parsed conflict type and risk level, a query condition for retrieving the repair rule library is constructed. The query condition can be combined logically, for example, "conflict type = version conflict AND risk level = high", so that the repair strategy that matches the current conflict situation can be accurately matched.

[0133] The repair rule library is a pre-constructed knowledge base that stores various conflict types and risk level adaptation strategies. Using the constructed query condition to search the repair rule library can use database queries or knowledge graph traversal, etc. For example, if the repair rule library uses a relational database for storage, SQL statements can be used for querying; if a knowledge graph is used for storage, a graph query language can be used for traversal.

[0134] According to the search results, the most suitable adaptation strategy is dynamically selected from the matched strategies. When selecting a strategy, multiple factors can be considered, such as the scope of the strategy, the repair effect, the impact on the project, etc. For example, for high-risk version conflicts, strategies that can completely solve version compatibility problems are preferred; for low-risk symbol conflicts, strategies that have less impact on the project can be selected.

[0135] According to the SDK information involved in the version conflict recorded in the conflict marking result, the dependency declaration file in the project is located, for example, in an Android project, the dependency declaration file is usually a build.gradle file; in an iOS project, it may be a Podfile or Cartfile file. In the dependency declaration file, find the version declaration part of the SDK involved in the conflict and force it to be uniform, for example, if the repair strategy requires that the version of SDK A be uniform to 2.0, modify the relevant version number in the build.gradle file to "2.0". After modifying the dependency declaration file, update the project's dependency cache to ensure that the project uses the updated SDK version in subsequent compilation and running, for example, in an Android project, the ". / gradlew clean BuildCache" command can be executed to clean and update the Gradle cache.

[0136] For symbol conflicts of methods or classes, if the repair strategy chooses to add override annotations, find the definition of the conflicting symbol in the project code, and add the corresponding override annotations, for example, in Java code, for method conflicts, use the "@Override" annotation to explicitly indicate that the method is an override of the parent class method. If the repair strategy chooses to rename the method signature, rename the conflicting method in the project code according to the new method name specified in the repair strategy. At the same time, update all places where the method is called to ensure the correctness of the code, for example, rename the original method name "calculateSum" to "newCalculateSum" and modify the method name in the code where the method is called.

[0137] According to the new resource ID generation rule defined in the repair strategy, modify the resource ID generation logic in the project, for example, if the original resource ID generation rule is a simple hash based on the resource name, the new rule can be a composite hash combining the resource name and the resource type. After modifying the resource ID generation rule, all places in the project that reference these resources need to be updated synchronously. By searching for resource IDs globally, all reference points can be found and updated to the new resource ID, for example, in the layout file and code of an Android project, update the ID of the conflicting resource to the new ID.

[0138] After completing the conflict repair operation, retrigger the conflict detection process. Use the same conflict detection method as before to comprehensively detect the SDK dependencies and code in the project, and check whether the conflicts have been eliminated. For example, run the bytecode static analysis engine again to compare the bytecode symbol table of the SDK dependency library with the project bytecode and mark new conflict situations.

[0139] According to the conflict marking results obtained by re-detection, determine whether the previous conflicts have been completely eliminated. If there are no previously repaired conflict types in the conflict marking results, it is considered that the conflicts have been eliminated; otherwise, it is considered that the conflicts have not been eliminated.

[0140] If the conflicts have not been eliminated, it means that the current selected repair strategy has not effectively solved the problem. At this time, it is necessary to roll back the previously executed repair operation to restore the project to the state before repair. For example, if the dependency declaration file has been modified, roll back the file to the version before modification; if the code has been modified, use a version control tool (such as Git) to perform a rollback operation. After rolling back, select the suboptimal adaptation strategy from the repair rule library and re-execute the repair operation until the conflicts are effectively solved.

[0141] In some embodiments, after the conflict repair is completed, the hierarchical code injection operation is performed, specifically including: After conflict resolution, the source code structure of the target insertion point is parsed using the AST syntax tree to locate the precise injection position and obtain the current code context. Based on the current code context and SDK interface definition, the local CodeBERT model is activated to generate business logic code. When the generation confidence of the local CodeBERT model is lower than the pre-set confidence threshold, switch to the cloud large model to perform enhanced code generation. Through the AST reconstruction engine, the code snippets output by the CodeBERT model or the cloud large model are converted into syntax tree nodes, and after verifying the scope and exception chain integrity, they are injected into the source file.

[0142] In this embodiment, according to the project requirements and design planning, the target insertion point where new code needs to be injected is determined. The target insertion point can be a specific class, method or code block, such as injecting new identity verification logic code in a class that handles user login. The target insertion point can be determined by analyzing the project's functional modules and business processes, combined with the developer's experience.

[0143] Use file reading tools to load the source code file where the target insertion point is located into memory. For different programming languages and development environments, use the corresponding file reading method. For example, in a Java project, you can use Java's file input stream (FileInputStream) to read.java files; in a C# project, you can use the File class in the System.IO namespace to read.cs files.

[0144] Use the AST syntax tree parser to parse the source code loaded into memory and build an abstract syntax tree (AST). AST is a data structure that represents the structure of source code in tree form, which can clearly show various syntax elements and their relationships in the code. Different programming languages have their own AST parsers, such as Python code, which can be parsed using the ast module; for JavaScript code, you can use Esprima and other parsers.

[0145] In the built AST syntax tree, according to the characteristics of the target insertion point, traverse and search to locate the precise injection position. For example, if you want to inject code in a specific method, you can traverse the method nodes in the AST to find the node of the target method. You can use algorithms such as depth-first search (DFS) or breadth-first search (BFS) to traverse.

[0146] After locating the injection position, extract the code information around the injection position as the current code context. The code context can include variable declarations, method calls, class definitions, and other related information, which are very important for generating code that conforms to the context logic. For example, if the injection position is in a loop, the code context should include information such as loop variables and loop conditions.

[0147] Organize and format the current code context and SDK interface definition as input data for the local CodeBERT model. The SDK interface definition can be extracted from the official documentation or header file of the SDK, which contains information such as interface name, parameters, return value, etc. Convert the input data into a text format that the model can handle, such as concatenating the code context and interface definition into a string.

[0148] Load the pre-trained local CodeBERT model. CodeBERT is a pre-trained model based on the Transformer architecture, specifically designed for code-related tasks such as code completion, code understanding, etc. When loading the model, ensure that the model's parameters and configurations are consistent with those during training.

[0149] Input the prepared input data into the local CodeBERT model, and the model generates the corresponding business logic code based on the input context and interface information. The generated code can be in the form of a fragment, such as a method body or a conditional statement.

[0150] Calculate the confidence of the generated code using the model's internal methods or additional evaluation indicators. The confidence reflects the model's self-confidence in the accuracy and reasonableness of the generated code. For example, you can evaluate the confidence by calculating the semantic similarity between the generated code and the input context, the grammatical correctness, etc.

[0151] Compare the calculated local CodeBERT model generation confidence with the pre-set confidence threshold. The pre-set confidence threshold can be set according to the actual needs of the project and experience, for example, set to 0.8. If the generation confidence is lower than the threshold, it means that the code generated by the local CodeBERT model may not be accurate or reasonable enough, and needs to be further enhanced.

[0152] When the confidence score of the local CodeBERT model falls below a preset confidence threshold, the input data is sent to a large cloud-based model. This large cloud-based model typically has greater computational power and a larger amount of training data, enabling it to generate more accurate and complex code. Input data can be uploaded to the cloud server via a network request, where the large model receives and processes the data. The large cloud-based model generates enhanced business logic code based on the received input data. Similar to the local CodeBERT model, the large cloud-based model also generates code based on the input context and interface information; however, due to its greater capabilities, the generated code may have advantages in quality, complexity, and accuracy. The code generated by the large cloud-based model is received via a network request. Upon receiving the results, the data needs to be validated and parsed to ensure that the received code is complete and correct. For example, checking whether the data format meets expectations and whether the code contains the necessary syntactic structure.

[0153] The AST refactoring engine converts code snippets output by CodeBERT models or large cloud-based models into AST syntax tree nodes. Based on the syntactic structure of the code snippet, the AST refactoring engine can break it down into corresponding syntax tree nodes, such as variable declaration nodes and method call nodes. For example, a simple assignment statement "int a = 10;" can be converted into a node structure containing variable type declarations, variable names, and assignment expressions.

[0154] Before injecting syntax tree nodes into the source file's AST, the scope and exception chain of the generated code are validated. Scope validation ensures that variables and methods used in the generated code are defined and accessed within the correct scope; exception chain validation ensures that the generated code can correctly handle possible exceptions, guaranteeing program stability. For example, it checks whether variables are declared within the current scope, whether method calls are within the accessible scope, and whether exception handling blocks are complete.

[0155] If verification passes, the converted syntax tree nodes are injected into the source file's AST, corresponding to the previously located precise injection positions. After injection, the modified AST syntax tree is regenerated into the source code file. An AST syntax tree generator can be used to convert the AST back to source code text format and write the generated text into the original source code file, completing the code injection operation.

[0156] In this embodiment, the AST syntax tree parsing and reconstruction technology is used to ensure the accuracy and syntactic correctness of code injection; the combination of the local CodeBERT model and the cloud-based large model improves the quality and adaptability of code generation, and can meet the code generation scenarios with different complexity and accuracy requirements.

[0157] In some embodiments, step S106 above, which involves constructing an abnormal scenario test vector based on the SDK type, performing stress testing via Monte Carlo simulation, and feeding the test results back to the intelligent decision engine for SDK recommendation weight optimization, specifically includes: Construct test vectors for abnormal scenarios based on SDK type; Based on abnormal scenario test vectors, a Monte Carlo simulation engine is used to randomly generate test path sequences and execute stress tests. During the stress test, the SDK crash rate and performance degradation index are recorded to obtain the test results, which are then converted into weight correction coefficients. The weight correction coefficient is fed back to the intelligent decision engine to optimize the SDK recommendation weight.

[0158] In this embodiment, a detailed analysis is conducted on the various SDKs involved in the project to understand their functional characteristics, application scenarios, and common problems. For example, for the graphics rendering SDK, the focus is on its performance and stability when processing complex graphics; for the network communication SDK, the emphasis is on its connection stability and data transmission efficiency under different network environments.

[0159] Based on the SDK's functions and usage scenarios, identify potential abnormal scenarios, including input anomalies (providing the SDK with input data that does not conform to the expected format or range, such as passing in strings or out-of-range values ​​for interfaces that require integer input), resource anomalies (simulating insufficient resources, such as memory exhaustion, insufficient disk space, limited network bandwidth, etc., and observing the SDK's performance under resource constraints), concurrency anomalies (concurrently calling the SDK in a multi-threaded or multi-process environment to test its stability and data consistency under high concurrency), and time anomalies (changing the system time or setting a timeout period, and observing the SDK's response and processing capabilities to time changes).

[0160] For each identified anomaly scenario, construct a specific test vector. The test vector should include detailed test parameters and expected results. For example, for input anomaly scenarios, the test vector could include information such as the type, value, and range of the input data; for resource anomaly scenarios, the test vector could specify the type of resource to simulate and the degree of resource limitation. Compile all test vectors for anomaly scenarios into a test vector library for later use.

[0161] Configure the relevant parameters of the Monte Carlo simulation engine, such as the number of simulations and the random number generation algorithm. The number of simulations should be set reasonably according to the complexity of the project and the requirements for the accuracy of the test results. It is generally recommended to perform a sufficient number of simulations to ensure the reliability of the results. The random number generation algorithm should have good randomness and uniformity to ensure that the generated test path sequence can cover all possible situations.

[0162] Using a Monte Carlo simulation engine, test path sequences are randomly generated based on abnormal scenario test vectors from the test vector library. A test path sequence refers to an abnormal scenario test vector combined in a certain order to simulate a series of abnormal situations that the SDK may encounter in actual use. For example, input anomalies can be simulated first, followed by resource anomalies, and then concurrency anomalies. The generated test path sequences should have randomness and diversity to fully test the SDK's performance under different conditions.

[0163] Perform stress testing on the SDK according to the generated test path sequence. During the test, simulate the actual operating environment, send corresponding test inputs to the SDK, and record the SDK's running status and output results. Automated testing tools can be used to execute stress tests, improving testing efficiency and accuracy. For example, for Android platform SDKs, the testing framework included with Android Studio or third-party testing tools can be used for testing.

[0164] During stress testing, the SDK's crash rate and performance degradation metrics are recorded in real time. The crash rate is the ratio of the number of times the SDK crashes during testing to the total number of tests, reflecting the SDK's stability. Performance degradation refers to the degree of difference between the SDK's performance metrics under abnormal scenarios (such as response time and throughput) and those under normal conditions, reflecting the SDK's performance adaptability. These metrics can be collected using logging tools or performance monitoring tools.

[0165] The recorded crash rate and performance degradation metrics data undergo preprocessing, including data cleaning and normalization. Data cleaning removes outliers and noise to ensure accuracy and reliability; normalization converts metrics with different dimensions into a unified dimension for easier subsequent analysis and processing. For example, crash rate data can be normalized to the range [0,1].

[0166] Based on the preprocessed test metric data, a weight adjustment coefficient is calculated. The calculation method for the weight adjustment coefficient can be designed according to the specific needs and evaluation criteria of the project. For example, a weighted average method can be used, assigning corresponding weights to the crash rate and performance degradation based on their impact on the SDK's recommended weight, and then calculating the weighted average as the weight adjustment coefficient. The value range of the weight adjustment coefficient can be adjusted according to the actual situation, and it can generally be set between [0, 2]. A value greater than 1 indicates that the SDK's recommended weight needs to be increased, and a value less than 1 indicates that the SDK's recommended weight needs to be decreased.

[0167] The calculated weight adjustment coefficients are fed back to the intelligent decision engine. The intelligent decision engine is a system based on machine learning or rule engines, used to dynamically adjust the SDK's recommendation weights according to various factors. The weight adjustment coefficients can be transmitted to the intelligent decision engine via data interfaces or message queues.

[0168] After receiving the weight correction coefficients, the intelligent decision engine optimizes and adjusts the recommended weights of the SDK according to a preset optimization algorithm. This optimization algorithm can consider various factors such as historical test data, project requirements, and user feedback to achieve more accurate and reasonable SDK recommendations. For example, it can use gradient descent or genetic algorithms to iteratively adjust the SDK's recommended weights until the optimal solution is reached.

[0169] Update the SDK recommendation list based on the optimized SDK recommendation weights. The recommendation list should be arranged in descending order of recommendation weight to provide a reference for developers. Additionally, the recommendation list can be integrated with the project's knowledge base or document management system for easy access and use by developers.

[0170] In this embodiment, comprehensive abnormal scenario test vectors can be constructed based on SDK type, and stress tests can be performed using Monte Carlo simulation to accurately evaluate the stability and performance adaptability of the SDK. The test results are converted into weight correction coefficients and fed back to the intelligent decision engine, realizing dynamic optimization of SDK recommendation weights, improving the accuracy of SDK selection and the efficiency of project development.

[0171] Reference Figure 2 An embodiment of the present invention provides a Unity cross-platform SDK intelligent access system 2, wherein the system 2 specifically includes: The feature extraction module 201 is used to extract project feature data by scanning Unity project assets and code structure when the plugin is loaded. The project feature data includes game type tags, target platform SDK compatibility matrix and user profile features. The target optimization module 202 is used to trigger the intelligent decision engine to call the pre-trained multi-objective optimization model based on project feature data, and generate the SDK combined weight matrix and platform-differentiated configuration parameter set; The conflict marking module 203 is used to construct a dependency graph based on the SDK combined weight matrix and the platform differential configuration parameter set, and to compare the existing code of the project with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, thereby generating conflict marking results. The conflict resolution module 204 is used to call the adaptation strategy of the resolution rule base based on the conflict marking result and perform conflict resolution. Code injection module 205 is used to perform layered code injection operations after conflict resolution is completed; The weight optimization module 206 is used to construct abnormal scenario test vectors based on the SDK type after the code injection is completed, perform stress tests through Monte Carlo simulation, and feed the test results back to the intelligent decision engine for SDK recommendation weight optimization.

[0172] It is understandable that, such as Figure 1 The content shown in the Unity cross-platform SDK smart access method embodiment is applicable to this Unity cross-platform SDK smart access system embodiment. The specific functions implemented in this Unity cross-platform SDK smart access system embodiment are the same as those shown below. Figure 1 The Unity cross-platform SDK smart access method shown in the example is the same, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the Unity cross-platform SDK smart access method embodiment shown are also the same.

[0173] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0174] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to 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 embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0175] Reference Figure 3 The present invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the Unity cross-platform SDK smart access method as described in any of the above methods.

[0176] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0177] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), 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.

[0178] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0179] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the Unity cross-platform SDK smart access method as described in any of the above methods.

[0180] In this embodiment, if the integrated unit is implemented as 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, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0181] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0182] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0183] In the embodiments disclosed in this 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 merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

Claims

1. A method for intelligent integration of Unity cross-platform SDK, characterized in that, The method specifically includes: When the plugin is loaded, it extracts project feature data by scanning the Unity project assets and code structure. The project feature data includes game type tags, target platform SDK compatibility matrix and user profile features. Based on project feature data, the intelligent decision engine is triggered to call the pre-trained multi-objective optimization model to generate the SDK combined weight matrix and the platform-differentiated configuration parameter set; Based on the SDK combined weight matrix and the platform-differentiated configuration parameter set, a dependency graph is constructed. The existing code of the project is compared with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, and to form conflict marking results. Based on the conflict marking results, the adaptation strategy of the repair rule base is invoked to perform conflict repair; After resolving the conflicts, perform layered code injection. After the code injection is completed, test vectors for abnormal scenarios are constructed based on the SDK type. Stress tests are then performed using Monte Carlo simulation, and the test results are fed back to the intelligent decision engine for SDK recommendation weight optimization.

2. The method according to claim 1, characterized in that, When the plugin loads, it extracts project feature data by scanning the Unity project assets and code structure, specifically including: When the plugin is loaded, it scans the resources in the Unity project's Assets directory and matches file path features based on a preset naming rule set to generate game type probability tags. Based on the probability tags of game type, the PlayerSettings configuration of the project is parsed to determine the target platform, and a platform-SDK compatibility matrix is ​​generated by associating it with the historical SDK database. If historical analysis SDK data exists, extract device performance and behavior characteristics; otherwise, call the device metadata simulator to generate a default profile vector. Aggregate game type tags, compatibility matrix, and user profile features to output project feature data.

3. The method according to claim 1, characterized in that, The process, based on project feature data, triggers the intelligent decision engine to invoke a pre-trained multi-objective optimization model, generating an SDK combined weight matrix and a platform-differentiated configuration parameter set, specifically including: Based on project feature data, the intelligent decision engine is triggered to call a pre-trained multi-objective optimization model to optimize performance, cost and stability objectives. The multi-objective optimization model includes a feature encoding layer, a cross-analysis layer and a decision output layer. The game type label is mapped to a 128-dimensional vector through the feature encoding layer, the target platform SDK compatibility matrix and user profile features are fused through the cross-analysis layer, and the SDK combined weight matrix is ​​generated through the decision output layer. Based on the SDK combined weight matrix, dynamically construct a set of platform-differentiated configuration parameters.

4. The method according to claim 1, characterized in that, The dependency graph is constructed based on the SDK combined weight matrix and the platform-differentiated configuration parameter set. Then, by comparing the existing project code with the bytecode static analysis engine, SDK dependency conflict points and code compatibility risks are marked, generating conflict marking results, specifically including: Based on the SDK combined weight matrix, a dependency graph with SDK as nodes is created; Based on the platform's differentiated configuration parameter set, dependency edges between nodes are established by recursively traversing the SDK declaration file, and version constraint attributes are attached to each dependency edge. Once the graph is built, the SDK dependency library and project code are compiled into intermediate bytecode. By comparing the bytecode symbol table of the SDK dependency library with the project bytecode, the conflict type is marked. The conflict types include version conflict, symbol conflict and resource conflict. Generate a conflict labeling report with risk level tags based on the conflict type.

5. The method according to claim 4, characterized in that, The process of invoking the adaptation strategy of the repair rule base based on the conflict marking results and performing conflict repair specifically includes: Based on the conflict marking results, the repair rule base is retrieved, and the appropriate strategy is dynamically selected according to the conflict type and risk level. Once a strategy is selected, the corresponding repair operation will be executed. To address version conflicts, the SDK version number in the dependency declaration file must be uniform. To resolve symbol conflicts, add a rewrite annotation or rename the method signature; To address resource conflicts, rewrite the resource ID generation rules and update references synchronously. After the repair is completed, the conflict detection is triggered again. If the conflict is not eliminated, the repair is rolled back and a suboptimal strategy is selected.

6. The method according to claim 1, characterized in that, After conflict resolution is completed, the layered code injection operation is performed, which specifically includes: After the conflict is resolved, the source code structure of the target insertion point is parsed using an AST syntax tree to pinpoint the precise injection location and obtain the current code context. Based on the current code context and SDK interface definition, activate the local CodeBERT model to generate business logic code; When the confidence level of the local CodeBERT model is lower than the preset confidence threshold, switch to the cloud-based large model to perform enhanced code generation; The AST reconstruction engine converts code snippets output by the CodeBERT model or large cloud models into syntax tree nodes, verifies the scope and exception chain integrity, and then injects them into the source file.

7. The method according to any one of claims 1 to 6, characterized in that, The process of constructing abnormal scenario test vectors based on SDK type, performing stress tests through Monte Carlo simulation, and feeding the test results back to the intelligent decision engine for SDK recommendation weight optimization specifically includes: Construct test vectors for abnormal scenarios based on SDK type; Based on abnormal scenario test vectors, a Monte Carlo simulation engine is used to randomly generate test path sequences and execute stress tests. During the stress test, the SDK crash rate and performance degradation index are recorded to obtain the test results, which are then converted into weight correction coefficients. The weight correction coefficient is fed back to the intelligent decision engine to optimize the SDK recommendation weight.

8. A Unity cross-platform SDK intelligent access system, characterized in that, The system specifically includes: The feature extraction module is used to extract project feature data by scanning Unity project assets and code structure when the plugin is loaded. The project feature data includes game type tags, target platform SDK compatibility matrix and user profile features. The target optimization module is used to trigger the intelligent decision engine to call the pre-trained multi-objective optimization model based on project feature data, and generate the SDK combined weight matrix and platform-differentiated configuration parameter set; The conflict marking module is used to construct a dependency graph based on the SDK combined weight matrix and the platform's differentiated configuration parameter set, and compare the existing code of the project with the bytecode static analysis engine to mark SDK dependency conflict points and code compatibility risks, thus generating conflict marking results. The conflict resolution module is used to call the adaptation strategy of the resolution rule base based on the conflict marking results and perform conflict resolution. The code injection module is used to perform layered code injection operations after conflict resolution is completed; The weight optimization module is used to construct abnormal scenario test vectors based on the SDK type after code injection is completed, perform stress tests through Monte Carlo simulation, and feed the test results back to the intelligent decision engine for SDK recommendation weight optimization.

9. A computer device, characterized in that, include: A memory and a processor, and a computer program stored in the memory, which, when executed on the processor, implements the Unity cross-platform SDK smart access method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the Unity cross-platform SDK smart access method as described in any one of claims 1 to 7.

Images