Game SDK automatic packaging and efficiency improving method, system and equipment

Abstract

The invention discloses a game SDK automatic packaging and efficiency improving method, system and equipment, and the method specifically comprises the steps: sending a packaging task request to a packaging service platform constructed based on a Knative Serving framework, and carrying out the expansion and contraction of a packer container instance in a Kubernetes cluster according to the load condition of a current task queue; in the resource-ready packer container instance, executing packing commands of the Android platform and the iOS platform in parallel, and extracting a code change log and a construction parameter in a packing process to generate packing data; inputting the packaged data of this time and historical packaged data into a cause and effect analysis engine based on a DoWhy framework, and outputting an optimal configuration recommendation file; and taking the historical packaging data and the optimal configuration recommendation file as training data, training to generate a packaging parameter optimization model, and re-executing the packaging task in combination with the packaging data of this time. According to the method, the packaging efficiency and quality are improved, and a more efficient and intelligent solution is provided for mobile game development.

Description

Technical Field

[0001] This invention relates to the field of game SDK technology, and in particular to a method, system and device for automated packaging and efficiency improvement of game SDKs. Background Technology

[0002] In the field of mobile game development, the integration and packaging of SDKs (Software Development Kits) is a crucial step for the smooth launch and continuous operation of projects. However, the traditional SDK packaging process suffers from numerous efficiency bottlenecks that urgently need to be addressed, severely restricting the efficiency and quality of mobile game development.

[0003] First, in the traditional packaging process, if operations or product personnel need to initiate a packaging task, it must rely on the technical team to manually trigger it. This process involves communication and coordination between multiple departments, which is not only cumbersome but also prone to delays due to poor communication or the technical team's work schedule. For example, during an urgent version release, waiting for the technical team to manually package the product may cause the optimal release time to be missed, thereby affecting the product's market competitiveness.

[0004] Secondly, the traditional full-package method requires processing all the code and resources of the entire SDK, which is time-consuming. Especially in scenarios with multiple versions under parallel development or frequent updates, packaging tasks are frequently initiated, resulting in huge resource consumption. Waiting for the packaging to complete for a long time will seriously affect the iteration speed of the development team, reduce development efficiency, and increase development costs.

[0005] Furthermore, the SDK lacks an intuitive demonstration mechanism during its continuous updates and iterations. As non-technical personnel, the operations and product teams struggle to quickly understand the specific changes made in each update. This leads to chaotic version management, discrepancies in understanding version content between different teams, increased friction during collaboration, and hinders the overall progress of the project.

[0006] Finally, after the packaging task is completed, the notification of the packaging result relies on manual operation. This method is prone to omissions or delays, preventing relevant personnel from receiving the packaging results in a timely manner and hindering subsequent testing, deployment, and other tasks, further impacting the project's progress.

[0007] Furthermore, some existing technical solutions attempt to optimize packaging speed, such as by optimizing packaging algorithms and improving resource management to shorten packaging time. However, these solutions only focus on packaging speed and fail to fundamentally solve other key problems existing in the traditional packaging process. Summary of the Invention

[0008] The purpose of this invention is to provide a method, system, and device for automated packaging of game SDKs, which effectively solves many problems existing in the traditional SDK packaging process, significantly improves packaging efficiency and quality, and provides a more efficient and intelligent solution for mobile game development, thereby solving at least one of the aforementioned prior art problems.

[0009] In a first aspect, the present invention provides a method for improving the efficiency of automated packaging of game SDKs, the method specifically including: By listening to the version tag creation event through a webhook configured in the code repository, a packaging task request can be automatically triggered; Packaging task requests are sent to a packaging service platform built on the Knative Serving framework, and the packager container instance is scaled up or down in the Kubernetes cluster according to the current task queue load. In a resource-ready packager container instance, package commands for the Android and iOS platforms are executed in parallel, and code change logs and build parameters are extracted during the packaging process to generate package data; The current packaging data and historical packaging data are input into the causal analysis engine based on the DoWhy framework to analyze the causal relationship between key build parameters and SDK product performance indicators, and output the optimal configuration recommendation file. The historical packaging data and the optimal configuration recommendation file are used as training data to train and generate a packaging parameter optimization model, and the packaging task is re-executed based on the current packaging data. After the packaging task is completed, the risk level of the packaging task is determined based on the preset rule base and the task status, and the access and operation permissions of relevant users to the packaging output, logs and analysis reports are dynamically adjusted in combination with user role information.

[0010] Secondly, this invention provides a game SDK automated packaging efficiency improvement system, the system specifically comprising: The build request module is used to automatically trigger build task requests by listening to the version tag creation event through the Webhook configured in the code repository; The container scaling module is used to send packaging task requests to the packaging service platform built on the Knative Serving framework, and to scale up or down the packager container instance in the Kubernetes cluster according to the current task queue load. The packaging command module is used to execute packaging commands for both Android and iOS platforms in parallel within a resource-ready packaging container instance, and to extract code change logs and build parameters during the packaging process to generate packaging data. The causal analysis module is used to input the current packaging data and historical packaging data into the causal analysis engine based on the DoWhy framework, analyze the causal relationship between key build parameters and SDK product performance indicators, and output the optimal configuration recommendation file. The packaging optimization module is used to train a packaging parameter optimization model by using historical packaging data and the optimal configuration recommendation file as training data, and then re-execute the packaging task based on the current packaging data. The user identification module is used to determine the risk level of the packaging task based on a preset rule base and task status after the packaging task is completed, and dynamically adjust the access and operation permissions of relevant users to the packaging output, logs and analysis reports in combination with user role information.

[0011] 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 game SDK automated packaging efficiency improvement method as described in any of the above methods.

[0012] 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 game SDK automated packaging efficiency improvement method as described in any of the above methods.

[0013] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention effectively solves many problems existing in the traditional SDK packaging process, significantly improves packaging efficiency and quality, and provides a more efficient and intelligent solution for mobile game development.

[0014] 2. This invention eliminates the need for operations or product personnel to rely on the technical team for manual triggering, reducing communication costs, avoiding delays caused by human factors, and improving version release efficiency.

[0015] 3. This invention sends packaging task requests to a packaging service platform built on the Knative Serving framework. Based on the current task queue load, it dynamically scales up and down the packager container instances in the Kubernetes cluster, achieving reasonable resource allocation and efficient utilization. Simultaneously, packaging commands for both Android and iOS platforms are executed in parallel within resource-ready packager container instances, further shortening packaging time, improving packaging efficiency, and accelerating development iteration speed.

[0016] 4. This invention extracts code change logs and build parameters during the packaging process, generating packaged data including SDK artifacts, a dependency list, and Markdown documents for recording feature changes. This data provides operations and product teams with an intuitive display of change information, enabling them to quickly understand SDK feature updates and reducing confusion and collaboration friction in version management.

[0017] 5. After the packaging task is completed, the risk level of the packaging task is determined based on a preset rule base and task status. Furthermore, the access and operation permissions of relevant users to the packaged outputs, logs, and analysis reports are dynamically adjusted based on user role information. Simultaneously, the packaged data is used for causal analysis, model training, and intelligent recommendation, achieving an automated closed-loop packaging process. This avoids omissions and delays in manual notifications and improves the overall project progress efficiency.

[0018] 6. This invention pre-divides non-core and frequently updated functional modules in the packaged SDK into multiple independent serverless computing functions, and configures a combination interface to predefine different function combination modes and corresponding computing function call chains. When responding to customized packaging requests, it can quickly determine the target call chain according to functional requirements, call the corresponding serverless computing function for execution, and finally generate a customized SDK package, meeting the diverse needs of SDK in different scenarios. Attached Figure Description

[0019] 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.

[0020] Figure 1 This is a flowchart illustrating an embodiment of a method for improving the efficiency of automated packaging of a game SDK according to the present invention. Figure 2 This is a schematic diagram of the structure of a game SDK automated packaging efficiency improvement 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

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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]."

[0025] 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.

[0026] References to "one embodiment" or "some embodiments" as described 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.

[0027] 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 an embodiment of the game SDK automated packaging efficiency improvement method disclosed in this invention is shown below: S101 automatically triggers a packaging task request by listening to the version tag creation event through a Webhook configured in the code repository.

[0028] In this embodiment, log in to the code repository platform and access the management page of the target game SDK code repository. On the management page, locate the settings options related to Webhook. In the Webhook configuration interface, click the "Add webhook" button or a similar button to create a new Webhook. In the configuration window, select the "tag" sub-event under the "Create" event. This means that when a new version tag is created in the code repository, the Webhook will capture the event and send a notification.

[0029] By configuring a Webhook in the code repository to listen for version tag creation events and automatically trigger packaging task requests, the foundation for the automated packaging process of the game SDK is laid, effectively improving packaging efficiency and the degree of automation of the process.

[0030] S102, the packaging task request is sent to the packaging service platform built on the Knative Serving framework, and the packaging container instance is scaled up or down in the Kubernetes cluster according to the current task queue load.

[0031] In this embodiment, a packaging service platform is built on an infrastructure with a Kubernetes cluster runtime environment. After the Kubernetes cluster is built, the Knative Serving framework is installed. Knative Serving is a framework for building and deploying modern, container-based applications, which simplifies the deployment, scaling, and management of applications. Following the installation guide provided in the official Knative Serving documentation, the corresponding installation commands are executed using the kubectl command-line tool to complete the deployment of Knative Serving in the Kubernetes cluster.

[0032] Next, build a packaging service platform based on the Knative Serving framework. Develop or configure a container image specifically for handling packaging tasks; this image should include the necessary tools, dependency libraries, and scripts for packaging. Upload the built container image to a container image repository, such as Docker Hub or a private container image repository, for subsequent pulling and use in the Kubernetes cluster.

[0033] In the packaging service platform, an access interface needs to be configured to receive packaging task requests. This interface can be a RESTful API, developed using common web frameworks (such as Spring Boot, Flask, etc.). During interface development, clearly defined request parameters and response formats should be used to interact with frontend webhooks or other components that trigger packaging tasks. For example, request parameters may include code repository information (such as repository address, branch name), version tag information, packaging type (Android or iOS), etc. The response format may include a unique identifier for the packaging task, task status (such as received, processing, completed, etc.), and possible error messages. The developed interface should be deployed to one or more Pods in a Kubernetes cluster and exposed to external access through Kubernetes Service resources. Appropriate network and load balancing strategies should be configured to ensure that packaging task requests are correctly routed to the appropriate Pods for processing.

[0034] When a version tag creation event is detected via a webhook configured in the code repository, the webhook automatically triggers and sends a packaging task request to the packaging service platform's access interface. Upon receiving the request, the packaging service platform first verifies its validity, checking the legitimacy of the request source and the completeness and compliance of the request parameters. If verification is successful, the platform parses the parameters in the request, extracting key information such as the code repository address, branch name, version tag, and packaging type. This information will be used for subsequent packaging task processing and resource allocation.

[0035] To achieve reasonable scaling of the packager container instances, it's necessary to obtain real-time load information for the current task queue. A task queue management module is designed within the packaging service platform to record and manage packaging tasks that are currently being processed and awaiting processing. This module can use a database (such as MySQL or Redis) to store task information, including task identifiers, task status, creation time, and estimated completion time. By querying the task information in the database, the number of currently processed tasks and the number of tasks awaiting processing can be counted, thereby calculating the task queue load. Furthermore, the load level of the task queue can be comprehensively assessed by combining it with the resource usage of the Kubernetes cluster (such as CPU utilization and memory utilization). Cluster resource usage data is collected using Kubernetes monitoring tools (such as Prometheus and Grafana), and this data is correlated with the task queue information for analysis, to more accurately determine whether scaling of the packager container instances is necessary.

[0036] Based on the obtained task queue load, formulate corresponding scaling strategies. If the current task queue load is high (e.g., the number of tasks waiting to be processed exceeds a certain threshold), the number of packager container instances needs to be increased to improve the processing capacity of packaging tasks. In a Kubernetes cluster, Deployment resources are used to manage packager container instances. Scaling up or down can be achieved by modifying the number of replicas (replicas) parameter of the Deployment. For example, if the current number of replicas is 2 and needs to be increased to 4, the corresponding update command can be executed using the kubectl command-line tool, and Kubernetes will automatically create new container instances and add them to the cluster. Conversely, if the current task queue load is low (e.g., the number of tasks waiting to be processed is below a certain threshold), the number of packager container instances can be appropriately reduced to save cluster resources. Similarly, by modifying the number of replicas parameter of the Deployment, Kubernetes will automatically delete redundant container instances. During scaling up or down, the start and stop times of container instances need to be considered to ensure that newly created container instances are ready to start processing packaging tasks in a timely manner, while avoiding interruptions to ongoing tasks due to sudden stops of container instances.

[0037] After scaling up and down the packager container instance, the received packaging tasks need to be assigned to appropriate container instances for processing. Task allocation can be based on the current load of the container instance (e.g., the number of tasks processed, resource utilization, etc.) and the task priority. For example, high-priority tasks can be prioritized for allocation to container instances with lower loads to ensure that important tasks are processed promptly. Simultaneously, algorithms such as round-robin or random can be used to evenly distribute low-priority tasks across container instances to achieve load balancing. During task allocation, task information (e.g., code repository address, branch name, version tag, packaging type, etc.) is passed to the selected container instance. After receiving the task information, the container instance begins executing the corresponding packaging operation.

[0038] In this embodiment, the function of sending packaging task requests to a packaging service platform built on the Knative Serving framework and scaling up or down the packaging container instance in the Kubernetes cluster according to the current task queue load effectively improves the processing efficiency and resource utilization of game SDK packaging tasks.

[0039] S103 executes packaging commands for both Android and iOS platforms in parallel within a resource-ready packager container instance, and extracts code change logs and build parameters during the packaging process to generate packaging data.

[0040] In this embodiment, after assigning the packaging task to the packaging container instance, it is necessary to determine the resource readiness of the container instance. This includes checking whether key resource indicators such as CPU utilization, memory utilization, and disk space of the container instance meet the requirements of the packaging task. This can be done by running a resource monitoring script in the container instance to obtain these resource indicator data in real time and compare them with preset resource thresholds. If all resource indicators of the container instance are below the corresponding thresholds, the container instance is considered resource-ready and the packaging task can begin. If any resource indicator exceeds the threshold, it is necessary to wait for resource release or take corresponding resource optimization measures, such as cleaning up temporary files and stopping unnecessary processes, until the resources meet the requirements. Simultaneously, it is ensured that packaging tools and related dependency libraries suitable for Android and iOS platforms are installed in the container instance. For the Android platform, tools such as the Android SDK and Gradle need to be installed; for the iOS platform, the Xcode development environment and related command-line tools need to be installed. These tools and dependency libraries can be pre-installed during the container image building stage or automatically installed and configured via scripts when the container instance starts.

[0041] Once the container instance resources are confirmed to be ready and the packaging tools are prepared, the packaging commands for both the Android and iOS platforms are executed in parallel. Parallel execution can be achieved using multi-threading or multi-processing. Within the container instance, two independent threads or processes are created: one thread or process executes the packaging commands for the Android platform, and the other executes the packaging commands for the iOS platform. For example, for the Android platform, Gradle commands can be used for building and packaging; for the iOS platform, Xcode's command-line tools can be used to build the project and generate the IPA package. When starting parallel execution, an independent working directory is allocated to each thread or process to avoid file conflicts arising during the packaging process across different platforms. Simultaneously, relevant parameters for the packaging task, such as the code repository address, branch name, and version tag, are passed to the corresponding thread or process to ensure they can correctly obtain the code and resources to be packaged.

[0042] During the packaging process, it's necessary to extract the code change log to understand the code changes involved in this packaging. This can be achieved by interacting with the code repository. For scenarios using Git as the code repository, a Git client tool needs to be installed in the container instance. In the Android and iOS packaging threads or processes, Git commands are used to retrieve code change information from the previous version tag to the current version tag.

[0043] In addition to code change logs, it's also necessary to extract build parameters during the packaging process. Build parameters include compiler options, dependency library versions, environment variables, etc., and these parameters have a significant impact on the performance and quality of SDK artifacts. During the packaging process on the Android platform, the Gradle build tool generates detailed build logs. Build parameters can be extracted by parsing the Gradle build logs. For example, look for lines related to compiler options in the logs to extract information such as compiler version and optimization level; look for lines related to dependencies to extract the dependency library names and version numbers. For the packaging process on the iOS platform, Xcode also generates corresponding build logs. Build parameters can also be extracted by parsing the Xcode build logs. Furthermore, some fixed build parameters can be obtained by reading project configuration files (such as the build settings in the Xcode project file).

[0044] The extracted code change logs and build parameters are integrated to generate complete package data.

[0045] In this embodiment, the packaging commands for the Android and iOS platforms are executed in parallel within a resource-ready packager container instance. During the packaging process, code change logs and build parameters are extracted to generate packaging data, providing strong data support for subsequent causal analysis, parameter optimization, and risk assessment.

[0046] S104 inputs the current packaging data along with historical packaging data into the causal analysis engine based on the DoWhy framework to analyze the causal relationship between key build parameters and SDK product performance indicators, and outputs the optimal configuration recommendation file.

[0047] In this embodiment, current packaging data and historical packaging data are collected and integrated. Current packaging data is generated during the execution of the current packaging task and includes information such as code change logs, build parameters, and packaging time. Historical packaging data is relevant data stored from past packaging tasks, and this data is stored in a pre-designed database or file system.

[0048] Before inputting the integrated data into the causal analysis engine, it's necessary to filter out the key components from numerous build parameters and performance metrics. Key build parameters refer to those that significantly impact the performance of the SDK artifacts, such as compilation optimization level, dependency library versions, and memory allocation strategies. Changes in these parameters can directly lead to changes in the SDK's runtime performance, such as startup time, response speed, and resource consumption. Performance metrics are quantitative indicators used to measure the quality of the SDK artifacts, commonly including startup time, frame rate stability, peak memory usage, and CPU utilization. By analyzing historical data and combining it with business requirements, we can determine which performance metrics are most critical for the current game project. For example, for a competitive game with high real-time requirements, frame rate stability might be the most important performance metric; while for a mobile game with limited memory resources, peak memory usage is a key area of ​​focus.

[0049] The selection of key build parameters and performance metrics can be achieved by combining expert evaluation with data analysis. Data analysis tools are used to statistically analyze historical data to identify build parameters that are strongly correlated with performance metrics, thus finalizing the list of key parameters and metrics.

[0050] The filtered data is then input into a causal analysis engine based on the DoWhy framework. The DoWhy framework is an open-source framework for causal reasoning that provides a complete causal analysis process, including causal graph construction, causal effect estimation, and counterfactual reasoning.

[0051] During the cause-effect graph construction phase, a cause-effect graph is built based on business knowledge and data characteristics to represent the causal relationships between key build parameters and performance metrics. The cause-effect graph is a directed acyclic graph (DAG), where nodes represent variables (including build parameters and performance metrics), and edges represent causal relationships between variables. For example, if we believe that the build optimization level affects the SDK startup time, then there would be an edge in the cause-effect graph pointing from the build optimization level node to the startup time node.

[0052] In the causal effect estimation phase, the causal effects of key build parameters on performance metrics are estimated using a causal graph and the input data, employing appropriate causal inference methods. The DoWhy framework supports various causal inference methods, such as those based on the backdoor criterion and those based on instrumental variables. The appropriate method is selected for causal effect estimation based on the structure of the causal graph and the characteristics of the data. Through causal effect estimation, the degree and direction of the impact of each key build parameter on performance metrics can be determined; for example, how many milliseconds the SDK startup time will be reduced by improving a certain compiler optimization level.

[0053] In the counterfactual reasoning phase, counterfactual analysis is performed based on the results of causal effect estimation. Counterfactual analysis involves hypothesizing how performance metrics change when a certain build parameter takes different values. Through counterfactual reasoning, a deeper understanding of the causal relationship between build parameters and performance metrics can be achieved, providing a basis for outputting optimal configuration recommendations.

[0054] Based on the analysis results of the causal analysis engine, an optimal configuration recommendation file is generated. The optimal configuration recommendation file includes the optimal value or range of each key construction parameter, the basis and explanation of the configuration recommendation, and the priority and precautions of the configuration recommendation.

[0055] S105 uses historical packaging data and optimal configuration recommendation files as training data to train and generate a packaging parameter optimization model, and then re-executes the packaging task using the current packaging data.

[0056] In this embodiment, based on the specific requirements for packaging parameter optimization and the characteristics of the data, a suitable model type and a reasonable model architecture are selected. Considering that packaging parameter optimization is a complex multivariate optimization problem, requiring comprehensive consideration of the interrelationships between multiple construction parameters and their impact on the performance indicators of the SDK output, a regression model from machine learning or a neural network model from deep learning can be selected.

[0057] If the amount of historical data is relatively small and the data features are relatively simple, traditional regression models can be chosen, such as linear regression, decision tree regression, or support vector regression. These models have advantages such as simple structure, fast training speed, and strong interpretability, and can quickly establish the mapping relationship between construction parameters and performance indicators.

[0058] If the historical data package is large and its features are complex, containing numerous non-linear relationships, neural network models in deep learning may be more suitable. For example, a multilayer perceptron (MLP) can automatically learn complex patterns and feature relationships in the data through non-linear transformations of multiple hidden layers; convolutional neural networks (CNNs) are suitable for processing data with local correlations, and if there is a certain local correlation between the construction parameters, CNNs can better capture these features; recurrent neural networks (RNNs) and their variants (such as LSTM and GRU) are suitable for processing data with temporal dependencies, and if the historical data of the packaging task has certain temporal characteristics, RNNs can leverage their advantages.

[0059] The preprocessed historical packaged data and optimal configuration recommendation files are divided into training, validation, and test sets. The training set is used for model parameter learning, the validation set is used to monitor model performance and perform hyperparameter tuning during training, and the test set is used to finally evaluate the model's generalization ability.

[0060] The selected model is trained using a training set. The model's parameters are continuously adjusted to minimize its prediction error on the training set. During training, appropriate optimization algorithms, such as stochastic gradient descent (SGD) and Adam, are used to update the model's parameters. Simultaneously, based on performance on the validation set, hyperparameters such as the learning rate, regularization coefficient, and number of hidden layer nodes are adjusted to improve the model's generalization ability and avoid overfitting.

[0061] After multiple iterations of training and hyperparameter tuning, when the model's performance on the validation set reaches a stable and satisfactory state, the test set is used for final evaluation. Evaluation metrics can be chosen based on the specific optimization objective; for example, mean squared error (MSE) and mean absolute error (MAE) are used for regression problems, while accuracy and recall are used for classification problems (if the optimization problem is transformed into a classification problem). If the model performs well on the test set, it indicates good generalization ability and can be used for subsequent packing parameter optimization. If the performance is unsatisfactory, the model selection, architecture design, or data preprocessing need to be re-examined for further improvement and optimization.

[0062] After the model training is complete, the code change logs and build parameters extracted during this packaging process are used as input to the trained packaging parameter optimization model. Based on the input data, the model predicts the optimal build parameter configuration that will maximize the performance of the SDK artifacts under the current code changes and build parameters.

[0063] Based on the optimal configuration recommendation output by the model, the build parameters in this packaging task are adjusted and optimized. For example, if the model recommends adjusting the compilation optimization level from the current O1 to O2 to shorten the SDK startup time, then when re-executing the packaging task, the compilation option will be set to O2.

[0064] After adjusting the build parameters, the packaging commands for both Android and iOS platforms were re-executed using the optimized parameters. During the repackaging process, code change logs and build parameters were continuously extracted in real time to generate new packaging data for further model updates and optimizations. Simultaneously, the performance metrics of the repackaged SDK artifacts were recorded and compared with those before optimization to evaluate the actual effectiveness of the optimized packaging parameters. Significant optimization results indicate that the model effectively guides the optimization of packaging parameters; if the results are unsatisfactory, the reasons need to be analyzed, which may include insufficient adaptability of the model to the specific packaging scenario or issues with the accuracy of the input data. Corresponding improvements and adjustments should be made based on the specific causes.

[0065] In this embodiment, historical packaging data and optimal configuration recommendation files are used as training data to train and generate a packaging parameter optimization model. The packaging task is then re-executed using the current packaging data, which realizes dynamic optimization of packaging parameters and intelligent efficiency improvement of the packaging process, thus helping to improve the development efficiency and quality of mobile game SDKs.

[0066] S106 After the packaging task is completed, the risk level of the packaging task is determined based on the preset rule base and the task status, and the access and operation permissions of relevant users to the packaging products, logs and analysis reports are dynamically adjusted in combination with user role information.

[0067] In this embodiment, a comprehensive and detailed pre-defined rule base is constructed. This rule base serves as the basis for determining the risk level of packaging tasks and adjusting user permissions. The construction of the rule base requires comprehensive consideration of multiple factors, covering all stages of the packaging task and various possible scenarios, including basic information about the packaging task (initiation time, estimated completion time, and actual completion time), build parameters during the packaging process, code changes, and performance metrics of SDK artifacts. Based on these factors, different risk weights and thresholds are assigned to each factor.

[0068] After the packaging task is completed, the status information of the packaging task is obtained. Based on the preset rule base and the obtained packaging task status information, a risk level is determined. Risk levels are typically divided into three levels: low risk, medium risk, and high risk, each corresponding to different judgment criteria and handling measures. During the judgment process, each relevant factor is scored according to the factor weights set in the preset rule base. For example, if the code change involves a core functional module, a higher score is given based on the set weight; if the increase in startup time does not exceed a threshold, a lower score is given. The scores of all factors are summarized, and the risk level is determined based on the range of the total score. For example, if the total score is between 0 and 30, it is judged as a low risk level; between 30 and 70 points is a medium risk level; and above 70 points is a high risk level. During the judgment process, it is essential to ensure the accuracy of the scoring of each factor and the calculation of the total score to guarantee the accuracy and reliability of the risk level determination.

[0069] Before dynamically adjusting user access and operation permissions for packaged artifacts, logs, and analysis reports, it is necessary to thoroughly review the user role information in the project. Different user roles have different responsibilities in the project, and their access and operation requirements for packaged information also differ.

[0070] Common user roles include operations personnel, product personnel, developers, testers, and project managers. Operations personnel are primarily responsible for product marketing and operational activities. They may need to understand the SDK's basic functionality and performance to formulate appropriate operational strategies, but have less need for detailed code-level access. Product personnel focus on product feature planning and implementation, requiring access to the SDK's feature change logs and analysis reports to evaluate the effectiveness of feature implementation. Developers are responsible for SDK code development and maintenance, needing access to complete packaged artifacts, logs, and detailed analysis reports for troubleshooting and code optimization. Testers primarily perform functional and performance testing on the SDK, requiring access to packaged artifacts and test-related logs and analysis reports to complete testing tasks. Project managers need to control the overall project progress and quality, requiring a comprehensive understanding of the packaging task's status and related information, but may not necessarily need in-depth code-level access.

[0071] Based on the responsibilities and needs of different user roles, the default access and operation permission scope for each role regarding packaged artifacts, logs, and analysis reports should be clearly defined. For example, developers have permissions to download, modify, and delete packaged artifacts, and permissions to view and export logs and analysis reports; while operations personnel may only have permissions to view basic information about packaged artifacts and read-only permissions for analysis reports.

[0072] Based on the determined risk level of the packaging task and the sorted user role information, dynamically adjust the access and operation permissions of relevant users to the packaging output, logs and analysis reports.

[0073] For low-risk packaging tasks, users are allowed to access and manipulate relevant information normally within their authorized scope, according to the default user role permission settings. For example, developers can download the packaged artifacts for subsequent development, and testers can obtain test logs for analysis.

[0074] When a medium-risk level is reached, appropriate restrictions will be placed on the permissions of certain users. For example, for operations personnel, their access to view detailed information about packaged artifacts will be restricted, and only a basic functional overview will be provided; for non-core developers, their permissions to modify and delete packaged artifacts will be suspended to prevent the problem from escalating due to accidental operation.

[0075] For high-risk packaging tasks, user permissions will be further strictly restricted. Apart from core developers and project managers, other users may only be allowed to view basic status information of the packaging task, such as completion status and risk level, and are prohibited from accessing detailed contents of packaging artifacts, logs, and analysis reports. Simultaneously, when core developers access information related to high-risk tasks, the system will record detailed operation logs for subsequent traceability and review.

[0076] During the dynamic adjustment of user permissions, it is crucial to ensure the timeliness and accuracy of these adjustments. Integration with the project's permission management system enables automatic permission adjustments and real-time effectiveness, guaranteeing secure management and efficient project progress after the packaging task is completed.

[0077] In this embodiment, after the packaging task is completed, the risk level is determined based on the preset rule base and task status, and the access and operation permissions of relevant users to the packaging products, logs and analysis reports are dynamically adjusted in combination with user role information, which effectively improves the standardization and security of project management.

[0078] In some embodiments, step S101 above, which involves automatically triggering a packaging task request by listening to the version tag creation event through a Webhook configured in the code repository, specifically includes: In response to the version tag creation event listened to by the Webhook configured in the code repository, automatically receive HTTP requests sent by the code repository; Perform security verification on HTTP requests, and after successful verification, parse version tag information and code repository information from the HTTP request payload data; Based on the parsed version tag information and code repository information, a corresponding packaging task request is automatically encapsulated and generated, and the packaging task request is published to the work queue of the message middleware.

[0079] In this embodiment, locate the Webhook configuration option in the project settings of the code repository management platform. In the configuration interface, you need to specify the callback address of the Webhook. This address is the network address for receiving event notifications from the code repository, typically provided by the packaging service platform and ensured to be accessible to the code repository management platform. Simultaneously, select the event type to listen for; here, it's crucial to select "Version Tag Creation Event" to ensure that the Webhook notification is triggered only when a new version tag is created in the code repository.

[0080] When a developer creates a new version tag in the code repository, the code repository management platform detects this event. Based on the previously configured webhook, the platform automatically sends an HTTP request to the specified callback address. The packaging service platform needs to deploy a corresponding network service to listen on a specified port to respond to this HTTP request. This network service can be implemented using common web server frameworks (such as Spring Boot, Flask, etc.). When the HTTP request arrives, the network service captures it and performs preliminary processing, such as recording basic information like the time the request arrived and the source IP address, for subsequent auditing and troubleshooting.

[0081] To ensure that received HTTP requests originate from a legitimate code repository management platform and prevent malicious requests from triggering packaging tasks, security verification of HTTP requests is necessary. A common verification method is signature verification. When sending an HTTP request, the code repository management platform uses a pre-shared key to sign the request content and includes the signature information in the request header. Upon receiving the request, the packaging service platform re-signs the request content using the same key and compares the regenerated signature with the signature in the request header. If the two signatures match, the request originates legitimately, and verification passes; otherwise, the request is considered potentially security-risking, the request is rejected, and relevant security event information is recorded for subsequent analysis and handling. In addition to signature verification, other security mechanisms can be combined, such as IP whitelist verification. The packaging service platform pre-configures a range of legitimate IP addresses for the code repository management platform. When an HTTP request is received, it checks whether the request's source IP is in the whitelist. If it is not in the whitelist, the request is also rejected, further enhancing security.

[0082] After the HTTP request passes security verification, key information, namely version tag information and code repository information, needs to be parsed from the request payload data. HTTP request payload data is typically transmitted in JSON format. The packaging service platform can use appropriate JSON parsing libraries (such as Jackson, Gson, etc.) to parse the payload data. By defining a data model corresponding to the payload data structure, the parsed data is mapped to the corresponding fields. Version tag information is extracted from the parsed data, which typically includes version number, version description, etc., to identify the specific version of the code. Simultaneously, code repository information, such as the repository name, address, and branch information, is extracted. This information helps determine the source and scope of the code targeted by the packaging task.

[0083] Based on the parsed version tag information and code repository information, a corresponding packaging task request is automatically encapsulated and generated.

[0084] To achieve asynchronous processing of packaging tasks and improve system scalability, packaged packaging task requests are published to the work queue of a message middleware. Message middleware (such as RabbitMQ and Kafka) is a software system used to pass messages between different systems or components. It provides a reliable message storage and delivery mechanism, ensuring that packaging task requests are not lost and can be processed in a specific order. The packaging service platform establishes a connection with the message middleware and sends packaging task requests as messages to the designated work queue. The work queue can dynamically expand or shrink according to the system load to accommodate different numbers of packaging task requests. Simultaneously, the message middleware can also provide message persistence and acknowledgment mechanisms to ensure that packaging task requests are reliably processed.

[0085] In some embodiments, step S102 above, which involves sending the packaging task request to a packaging service platform built on the KnativeServing framework and scaling up or down the packager container instance in the Kubernetes cluster according to the current task queue load, specifically includes: Packaging task requests are temporarily stored in the request buffer, and the workload metrics of the request buffer are continuously monitored. Based on the comparison results between workload metrics and preset scaling targets, the number of container instances required for the Kubernetes cluster is dynamically calculated. Send instructions to the packaging service platform built on the Knative Serving framework to automatically adjust the number of running packager container instances based on the required number of container instances.

[0086] In this embodiment, when a packaging task request is retrieved from the message middleware's work queue, it is not immediately sent to the packaging service platform for processing. Instead, it is temporarily stored in a request buffer. The request buffer can be implemented using a distributed caching system (such as Redis), leveraging its high performance and high availability to ensure the rapid storage and retrieval of a large number of packaging task requests.

[0087] When a packaging task request is stored in the request buffer, a unique identifier is assigned to each request for subsequent tracking and management. Simultaneously, metadata such as the request's arrival time and source information is recorded. This information helps analyze task processing status and system performance bottlenecks. The capacity of the request buffer can be dynamically adjusted according to the actual needs of the system and hardware resources to avoid task loss due to buffer overflow.

[0088] To accurately grasp the current state of the request buffer, its workload metrics need to be continuously monitored. Key monitored metrics include request queue length, average request processing time, and request wait time. Real-time collection of workload metrics can be achieved by integrating monitoring tools into the request buffer or using third-party monitoring services. For example, Redis's INFO command can be used to obtain various status information of the current caching system, including memory usage and connection count. Combined with custom logic, key metrics such as request queue length can be further calculated. Simultaneously, a scheduled task can be set up to periodically retrieve these metric data from the request buffer and store them in a dedicated monitoring database for subsequent analysis and decision-making.

[0089] Based on the workload metrics obtained from continuous monitoring, these metrics are compared and analyzed with preset scaling targets to dynamically calculate the number of packager container instances required for the Kubernetes cluster.

[0090] The preset scaling targets can be flexibly set according to the system's performance requirements and business needs. For example, it can be set that when the request queue length exceeds a certain threshold, the number of container instances needs to be increased to speed up task processing; when the request queue length is below another threshold, the number of container instances can be appropriately reduced to save system resources.

[0091] A dynamic adjustment algorithm is used to calculate the required number of container instances. This algorithm comprehensively considers factors such as current workload metrics, historical data, and system resource constraints. For example, if the current request queue is long and shows a continuous growth trend, while the system has sufficient resources available for allocation, the algorithm will calculate that a larger number of container instances need to be added; conversely, if the request queue is short and system resources are strained, the algorithm will calculate that a smaller number of container instances need to be reduced. This dynamic adjustment algorithm ensures that the number of container instances matches the actual workload, improving the overall system performance and resource utilization.

[0092] Based on the dynamically calculated number of container instances required for the Kubernetes cluster, instructions are sent to the packaging service platform built on the KnativeServing framework to automatically adjust the number of running packager container instances.

[0093] The Knative Serving framework provides automatic scaling capabilities. Through integration with Kubernetes, it can automatically adjust the number of Pods based on application load. Packaging service platforms can send scaling commands by calling the APIs provided by Knative Serving. For example, to increase the number of container instances, a scaling request is sent to Knative Serving, specifying the number of instances to be added; to decrease the number of container instances, a scaling request is sent, specifying the number of instances to be removed.

[0094] After a command is sent, Knative Serving automatically creates or deletes the corresponding packager container instance in the Kubernetes cluster. Simultaneously, the packaging service platform continuously monitors the container instance creation and deletion process to ensure successful operation. If any anomalies occur during the operation, such as container instance creation failure, the packaging service platform will promptly handle errors and retry to guarantee system stability and reliability.

[0095] In some embodiments, step S103 above, which involves executing packaging commands for both the Android and iOS platforms in parallel within a resource-ready packager container instance, and extracting code change logs and build parameters during the packaging process to generate packaging data, specifically includes: In response to the packaging task request, the first child process and the second child process are launched simultaneously in the compute instance to execute the packaging commands for the Android platform and the iOS platform, respectively. During the execution of the packaging command, metadata extraction is performed synchronously to obtain code change logs and build parameters; Based on the code change log and build parameters, package data is automatically generated. The package data includes SDK artifacts, a dependency list, and a Markdown document for recording feature changes.

[0096] In this embodiment, when the packager container instance receives a packaging task request, it immediately initiates the corresponding processing flow. Inside the computing instance, a first child process and a second child process are started simultaneously through system calls or a specific process management mechanism.

[0097] The first child process is specifically responsible for executing the packaging commands for the Android platform. Based on the Android-related configuration information specified in the packaging task request, such as the target Android version and build type (debug or release), it calls pre-configured Android packaging tools (such as Gradle) to perform the specific packaging operations. When the first child process starts, appropriate working directories and environment variables are set for it to ensure that the packaging tools can correctly access the required code files and dependency libraries.

[0098] The second subprocess focuses on executing packaging commands for the iOS platform. Similarly, based on the iOS configuration information in the packaging task request, such as the Xcode version and target device type (iPhone or iPad), it calls the Xcode command-line tool or other relevant iOS packaging tools to perform the packaging work. Likewise, the correct working directory and environment variables are set for the second subprocess to ensure the smooth progress of the packaging process. By starting these two subprocesses simultaneously, the packaging tasks for the Android and iOS platforms are executed in parallel, significantly reducing the overall packaging time.

[0099] During the execution of the packaging command in the first and second child processes, the metadata extraction operation is started synchronously. This metadata extraction operation is handled by a separate thread or process, running in parallel with the packaging child processes without interference. The metadata extraction operation primarily retrieves two types of information: code change logs and build parameters.

[0100] For code change logs, this is achieved through interaction with a code version control system (such as Git). The metadata extraction module calls the command-line tools or APIs provided by the code version control system to retrieve the code change records from the previous version to the current version based on the code version information specified in the packaging task request. These change records include information on added, modified, and deleted files, as well as specific code modifications, clearly reflecting the code changes involved in this packaging.

[0101] For build parameters, the metadata extraction module obtains them directly from the packaging task request, and also reads some default build parameters from the packaging environment's configuration file. These build parameters cover various settings used during the packaging process, such as compilation options, optimization levels, and dependency library versions, and are crucial for understanding the packaging process and troubleshooting.

[0102] Based on the synchronously extracted code change logs and build parameters, package data is automatically generated. The package data consists of three main parts: SDK artifacts, a dependency list, and a Markdown document for recording feature changes.

[0103] SDK artifacts are the core outputs of the packaging process, including AAR or JAR files generated for the Android platform and .framework or .a files generated for the iOS platform. These artifacts are the actual deliverables of the mobile game SDK and will be used in subsequent development and testing. During SDK artifact generation, the generated artifact files are stored and managed according to a predetermined directory structure based on the execution results of the packaging command, facilitating subsequent access and use.

[0104] The dependency manifest details the various libraries and components that this build depends on. It lists the name, version number, and source (e.g., Maven repository, CocoaPods repository) of each dependency. This manifest allows developers and operations personnel to clearly understand the SDK's dependencies, facilitating dependency management and version conflict troubleshooting. When generating the dependency manifest, relevant information is retrieved from dependency management tools used during the building process (such as Gradle's dependency reporting feature and CocoaPods' Podfile.lock file), and then organized and formatted.

[0105] The Markdown document used to record feature changes describes the functional changes involved in this package in a concise and clear manner. It extracts the relevant code modifications from the code change log and converts them into easily understandable text descriptions. It also incorporates relevant information from the build parameters to explain the potential impact of these feature changes on SDK usage and compatibility. The Markdown document can be generated using a template engine, which populates the extracted information into a predefined template to produce a well-formatted and complete document.

[0106] In some embodiments, step S104 above, which involves inputting the current packaging data and historical packaging data together into a causal analysis engine based on the DoWhy framework to analyze the causal relationship between key build parameters and SDK product performance indicators, and outputting an optimal configuration recommendation file, specifically includes: Obtain the set of build parameters and the set of performance metrics of SDK artifacts from the current packaging data, and combine them with historical packaging data to form an analysis dataset; The analysis dataset is input into the causal analysis engine based on the DoWhy framework. The causal analysis engine executes the causal analysis process to quantify the causal effect of the parameter set on the performance index set. Based on the quantified causal effect, several key construction parameters with significant positive causal effects on the target performance index are identified from the set of construction parameters, and the quantification results are obtained. Based on the quantification results, optimal values ​​that optimize the target performance indicators are assigned to key construction parameters, and an optimal configuration recommendation file is generated.

[0107] In this embodiment, the build parameter set and SDK artifact performance metrics set are accurately extracted from the packaged data. The build parameter set covers various parameters set during the packaging process, such as compilation optimization levels (e.g., different optimization options for Android such as -O0, -O1, -O2, -O3, etc., and similar compilation optimization settings for iOS), dependency library version numbers (including Android's Gradle dependencies and iOS's CocoaPods dependencies), and code obfuscation configurations (e.g., whether obfuscation is enabled, the strictness of obfuscation rules, etc.). These parameters directly or indirectly affect the SDK artifact generation process and final performance.

[0108] The performance metrics set of SDK artifacts includes data reflecting multiple aspects of SDK runtime efficiency and quality, such as startup time (the time from loading to initial interface display for Android APKs and iOS .framework artifacts), memory usage (the amount of memory used by the SDK in a specific test scenario), and CPU utilization (the CPU load during operation). These performance metrics are key indicators for measuring the quality of an SDK.

[0109] Simultaneously, the build parameter sets and performance indicator sets corresponding to previous packaging tasks are retrieved from the historical packaging data storage system. These sets are then integrated with the current build parameter set, performance indicator set, and historical data, and combined according to a unified data format and structure to form an analysis dataset.

[0110] The assembled analysis dataset is input into the causal analysis engine based on the DoWhy framework. The DoWhy framework is an open-source library specifically designed for causal inference, providing a complete causal analysis workflow. The causal analysis engine first preprocesses the analysis dataset, including data cleaning (removing outliers, handling duplicate data, etc.) and data transformation (encoding categorical variables, etc.) to adapt it to the needs of causal analysis. Next, the causal analysis engine identifies the causal relationship structure between variables based on a pre-defined causal graph model (which can be initially constructed based on domain knowledge and experience and continuously optimized during subsequent analysis). For example, it determines which construction parameters are causal variables that may affect performance indicators, and which performance indicators are outcome variables. Then, using various causal inference methods provided by the DoWhy framework, such as methods based on the backdoor criterion and methods based on instrumental variables, it quantitatively analyzes the causal effect of the construction parameter set on the performance indicator set. During the analysis, confounding factors in the data are fully considered. By adjusting and controlling these confounding factors, the true causal relationship between the construction parameters and performance indicators is accurately estimated, and the causal effect value of each construction parameter on each performance indicator is obtained. These values ​​reflect the degree and direction of the influence of changes in construction parameters on changes in performance indicators.

[0111] Based on the quantified causal effect results, several key construction parameters with significant positive causal effects on the target performance index were selected from the set of construction parameters. During the selection process, a reasonable significance threshold was set, which could be determined based on actual business needs, the accuracy requirements of data analysis, and historical experience.

[0112] For each target performance metric, the causal effect values ​​of all construction parameters are iterated. Construction parameters with causal effect values ​​greater than the significance threshold and a positive direction (i.e., increasing the construction parameter leads to an improvement in the performance metric) are identified as key construction parameters. Simultaneously, the causal effect quantification results corresponding to these key construction parameters are recorded. These results include not only the magnitude of the causal effect but also information such as its confidence interval, in order to gain a more comprehensive understanding of the degree and reliability of the key construction parameters' influence on the performance metric.

[0113] Based on the identified key build parameters and their quantification results, an optimal value is assigned to each key build parameter to optimize the target performance metric. Several strategies can be employed to determine the optimal value. One strategy is to perform linear extrapolation based on the magnitude of the causal effect, assuming a linear relationship between the build parameter and the performance metric within a certain range, and calculating the optimal build parameter value based on the quantification results. Another strategy combines best practices from historical data, referencing build parameter settings that have yielded excellent performance in similar scenarios in previous packaging tasks, and comprehensively considering the current analysis results to determine the optimal value.

[0114] The optimal values ​​for each key build parameter are compiled and summarized, and an optimal configuration recommendation file is generated according to a specific file format (such as JSON, XML, or a custom text format). This file clearly lists the name of the key build parameter, its optimal value, and the corresponding optimization target performance metrics. This allows developers to easily refer to and apply these optimal configurations in subsequent packaging tasks, thereby improving the performance and quality of the SDK deliverables.

[0115] In some embodiments, step S105 above, which involves using historical packaging data and the optimal configuration recommendation file as training data to train a packaging parameter optimization model and then re-executing the packaging task using the current packaging data, specifically includes: The training dataset is constructed based on the construction parameters and their corresponding optimal configuration recommendation files from the historical packaged data. A machine learning model is trained using a training dataset to generate a packaged parameter optimization model, which is used to predict the optimal parameter configuration based on the input build parameters. The first construction parameter is extracted from the packaged data, and the first construction parameter is input into the packaged parameter optimization model to output the predicted optimal parameter configuration. Update the first build parameter in the current packaging data according to the predicted optimal parameter configuration, and re-execute the packaging task based on the updated first build parameter.

[0116] In this embodiment, optimal configuration recommendation files corresponding to historical packaging data are obtained. These files are sets of optimal build parameter values ​​that optimize SDK performance metrics, generated for each packaging task based on causal analysis and other methods.

[0117] The build parameters in the historical packaged data are correlated and matched with the optimal configuration recommendation file. Specifically, for each set of historical build parameters, the corresponding recommended parameter value in the optimal configuration recommendation file is found. Following a unified data format, the historical build parameters are used as input features, and the corresponding optimal parameter values ​​are used as the target output to construct the training dataset.

[0118] Using the constructed training dataset, select an appropriate machine learning algorithm to train the model. Available algorithms include, but are not limited to, decision tree algorithms (which can classify and regress data through a tree structure, intuitively showing the relationships between parameters), random forest algorithms (composed of multiple decision trees, improving the model's accuracy and stability through ensemble learning), gradient boosting tree algorithms (such as XGBoost and LightGBM, which improve model performance by progressively optimizing the loss function), and neural network algorithms (which have strong fitting capabilities for complex data relationships, especially deep neural networks, which perform exceptionally well when processing large-scale data).

[0119] During training, the training dataset is divided into a training set and a validation set (usually in a certain ratio, such as 7:3 or 8:2). The model is trained using the training set, and its hyperparameters (such as the maximum depth of the decision tree, the number of trees in the random forest, the number of layers and neurons in the neural network) are continuously adjusted to gradually reduce the model's loss function (such as mean squared error, mean absolute error, etc.) on the training set. Simultaneously, the trained model is evaluated using the validation set to observe its performance on unseen data, preventing overfitting (models that perform well on the training set but poorly on the validation set). Through multiple iterations of training and evaluation, the model with the best performance on the validation set is selected as the model for optimizing the packaging parameters. This model has the ability to predict the optimal parameter configuration based on the input building parameters, providing intelligent parameter optimization suggestions for subsequent packaging tasks.

[0120] The first build parameters are precisely extracted from the current packaging data. These parameters are the actual build parameters used in the current packaging task and have the same type and meaning as the build parameters in historical packaging data, such as the same compilation optimization level and dependency library version. The extracted first build parameters are then organized and transformed according to the input format required by the packaging parameter optimization model. This ensures that the dimensions, type, and range of the data are consistent with the data used during model training. The organized first build parameters are then input into the trained packaging parameter optimization model. Based on the parameter relationships and patterns learned internally, the model processes and calculates the input first build parameters and outputs the predicted optimal parameter configuration. These predicted optimal parameter configurations are the parameter values ​​that the model believes can further optimize SDK performance metrics based on the current build parameters.

[0121] Based on the predicted optimal parameter configuration output by the packaging parameter optimization model, the first construction parameter in the current packaged data is updated. The original construction parameter is replaced with the predicted optimal parameter value to ensure that the updated construction parameter accurately reflects the optimization scheme recommended by the model.

[0122] After updating the build parameters, the packaging task is restarted based on the updated initial build parameters. During the re-execution of the packaging task, the normal packaging process is followed, including code compilation, resource integration, and dependency library import. Due to the use of optimized build parameters, this re-execution of the packaging task is expected to generate a higher-performing SDK artifact, such as shorter startup time, lower memory usage, and more reasonable CPU utilization. Simultaneously, relevant packaging information and performance metrics are recorded during the re-execution of the packaging task to facilitate subsequent evaluation and analysis of the optimization effect, providing a basis for further model optimization and parameter adjustment.

[0123] In this embodiment, historical packaging data and optimal configuration recommendation files are used as training data to train and generate a packaging parameter optimization model. The packaging task is then re-executed based on the current packaging data, which effectively improves the intelligence level and product quality of mobile game SDK packaging.

[0124] In some embodiments, in step S106 above, after the packaging task is completed, the risk level of the packaging task is determined according to a preset rule base and the task status, and the access and operation permissions of relevant users to the packaging output, logs and analysis reports are dynamically adjusted in conjunction with user role information, specifically including: After the packaging task is completed, the status and context information of the packaging task are obtained, and the risk level of the packaging task is determined by combining the preset rule base. Obtain user role information associated with the packaging task, and determine the access and operation permissions of the corresponding users to the build artifacts under the current risk level based on the mapping relationship between risk level and user role information query permissions. Based on the determined access and operation permissions, dynamically update the access control policies for relevant users on the build artifacts and log data produced by the packaging task.

[0125] In this embodiment, the status and context information of the packaging task are obtained. The packaging task status covers different situations such as success, partial success, and failure, and this status information intuitively reflects the execution result of the packaging task. The context information is more comprehensive, including the number and severity of error logs that occur during the packaging process (e.g., whether it is a common compilation warning or a critical error that causes the packaging to be interrupted), the deviation between the packaging time and the preset standard time (if it exceeds the preset threshold by a large margin, it may indicate a potential risk), and whether the build parameters used comply with security specifications (e.g., whether specific compilation options that may introduce security vulnerabilities are enabled), etc.

[0126] The acquired packaging task status and context information are input into a pre-defined rule base for matching and analysis. This rule base, meticulously constructed by business experts based on years of practical experience and a deep understanding of potential risks, contains various risk assessment rules. For example, if a packaging task fails and the error log contains specific types of critical error information, and the packaging time significantly exceeds the standard time, the rule base may classify the task as high-risk. If the packaging task succeeds but contains a few common compilation warnings, and the packaging time is within the normal range, it may be classified as low-risk. Through a step-by-step comparison and comprehensive evaluation with the rules in the rule base, the system ultimately determines the risk level of the packaging task, generally categorized into high, medium, and low levels, providing crucial evidence for subsequent permission adjustments.

[0127] After determining the risk level of the packaging task, the system then retrieves the user role information associated with that task. In mobile game SDK development teams, there are typically various user roles, such as developers, testers, project managers, and operations personnel. Each role has different responsibilities within the project, and their access to and manipulation requirements of the packaged artifacts also differ.

[0128] Based on the determined risk level and the obtained user role information, the system queries a predefined permission mapping table. This permission mapping table is meticulously planned and designed, clearly defining the access and operation permissions of each user role for build artifacts (such as generated APK files, .framework files, etc.), log data (including detailed logs during the packaging process, error logs, etc.), and analysis reports (such as performance analysis reports, code quality analysis reports, etc.) under different risk levels. For example, at a high risk level, developers may only have permission to view build artifacts and log data, but not to modify or delete them; testers may only be able to access some key logs for troubleshooting, but not the complete analysis report; project managers have higher permissions, able to view all relevant information, but their operation permissions are also limited, such as not being able to arbitrarily delete important logs. By querying the permission mapping table, the system can accurately determine the access and operation permissions of the corresponding users for build artifacts under the current risk level.

[0129] Based on the determined access and operation permissions, the system immediately initiates a dynamic update process for the access control policy. Access control policy is a core mechanism for ensuring data security; it determines which users can perform what operations on which data under what conditions.

[0130] The system first interacts with the existing access control system to obtain the original access control policies for the build artifacts and log data produced by the packaging task for the relevant users. Then, based on the newly determined access and operation permissions, the original policies are modified and adjusted. For example, if a developer originally had full operation permissions for the build artifacts, but according to the new risk level and permission mapping relationship, their permissions should be adjusted to view-only, the system will modify the developer's permission settings in the access control system, canceling their modification and deletion permissions.

[0131] During the access control policy update process, the system performs rigorous permission verification and data consistency checks to ensure that the updated policy does not pose a risk of permission conflicts or data leaks. Simultaneously, the system records all permission update operation logs, including update time, update content, and operator information, for subsequent auditing and traceability. After the update is complete, when relevant users access the build artifacts and log data produced by the packaging task again, permission verification will be performed according to the new access control policy. Only users with the required permissions will be able to perform the corresponding access and operations, thus achieving fine-grained permission management of data related to the packaging task.

[0132] In this embodiment, after the packaging task is completed, the risk level of the packaging task is determined according to the preset rule base and the task status. The access and operation permissions of relevant users to the packaging products, logs and analysis reports are dynamically adjusted in combination with user role information, which effectively improves the security and standardization of mobile game SDK development and packaging management.

[0133] In some embodiments, the method further includes, in steps S101 to S106 above: Non-core functional modules that require frequent updates in the packaged SDK are pre-split into and deployed as multiple independent serverless computing functions. Configure a combination interface, which is used to predefine different function combination modes and corresponding computation function call chains; In response to a customized packaging request, based on the functional requirements in the customized packaging request, the corresponding target call chain is determined from the predefined functional combination patterns according to the combined interface; Invoke several corresponding serverless computing functions, execute the target call chain, and obtain the execution results; Obtain the pre-compiled software development kit (SDK) core library, combine the execution results with the SSD core library, and generate a customized SDK package.

[0134] In this embodiment, a comprehensive functional analysis is performed on the packaged SDK to identify non-core functional modules that require frequent updates. For example, in a game social SDK, non-core functions might include displaying specific types of emoticons and setting personalized chat backgrounds; in an advertising SDK, these might include the display logic for certain new ad formats and the dynamic adjustment of ad placement strategies. These functional modules are suitable for splitting because they are frequently updated and have a relatively small impact on the core stability of the SDK.

[0135] The identified non-core functional modules were meticulously broken down according to the principle of functional independence, ensuring that each module had a clear functional boundary and a single responsibility. For example, the emoji display function was split into two independent modules: emoji data acquisition and emoji rendering and display; the dynamic adjustment of advertising strategies was split into modules such as strategy data parsing and strategy execution evaluation.

[0136] For each independently decomposed functional module, it is developed and deployed as multiple independent serverless computing functions. Serverless computing functions have advantages such as no need to manage server infrastructure, on-demand scaling, and automatic scaling, making them ideal for handling frequently updated and changing functionalities. During deployment, based on the function's characteristics and expected call frequency, a suitable serverless computing platform (such as Alibaba Cloud Function Compute, Tencent Cloud Functions, etc.) is selected. The function code is uploaded according to the platform's requirements, triggers are configured (such as HTTP triggers, timed triggers, etc.; the appropriate triggering method can be selected based on the actual business scenario to achieve flexible function invocation), and resource parameters (such as memory size, execution timeout, etc.) are set to ensure that each serverless computing function can run stably and efficiently.

[0137] Develop and configure a composition interface that serves as a crucial bridge connecting customized packaged requests with serverless computation function call chains. The composition interface uses a predefined approach to map and store different functional combination modes with their corresponding computation function call chains.

[0138] When predefining functional combination patterns, various possible customized needs and scenarios are fully considered. For example, for a game social SDK, multiple functional combination patterns may be predefined, such as "basic social interaction + unique emoticons" and "advanced social interaction + personalized chat background + dynamic emoticon interaction". For each functional combination pattern, its corresponding calculation function call chain is planned in detail. Taking the "basic social interaction + unique emoticons" pattern as an example, its call chain may be as follows: first, the emoticon data acquisition function is called to obtain the unique emoticon data, and then the obtained data is passed to the emoticon rendering and display function for display. At the same time, functions related to basic social functions (such as friend list retrieval, message sending and receiving, etc.) are also called in the corresponding stages.

[0139] Predefined functional combination patterns and their corresponding computational function call chains are stored in a structured data format in the configuration file or database of the combination interface for quick subsequent querying and invocation. Simultaneously, a clear input / output specification is designed for the combination interface; input parameters should accurately express the functional requirements in the customized package request, while the output should be the defined target call chain information.

[0140] When a customization request is received, the system first parses the request and extracts the functional requirements information contained therein. The functional requirements information can be presented in various forms, such as explicitly indicating the functions that need to be included in the customized SDK through specific parameter identifiers (such as functional module ID, function name, etc.), or describing the required social function types, advertising display formats, etc. through descriptive text.

[0141] The parsed functional requirements information is passed as input parameters to the composition interface. The composition interface searches for a match within its predefined functional composition patterns based on the input functional requirements. By traversing all predefined functional composition patterns and comparing their included functions with the functional requirements in the request, the most suitable functional composition pattern is found. Once the functional composition pattern is determined, the composition interface retrieves the corresponding target call chain from the stored configuration information and returns it to the request initiator or subsequent processing module.

[0142] Based on the target call chain returned by the composite interface, the system sequentially calls several corresponding serverless computing functions in a predetermined order. During the call process, it ensures smooth data transfer and interaction between each function; for example, the output of the previous function is used as the input parameter of the next function.

[0143] For each serverless computation function called, its execution status and return results are monitored in real time. If an error or exception occurs during the execution of a function, the system should promptly capture and record the relevant information, and handle it according to the preset error handling strategy, such as retrying the call, skipping the function and continuing to execute subsequent functions (without affecting the overall functionality). After all target functions have been executed, the execution results of each function are collected, integrated, and preliminarily processed (such as standardizing data formats and summarizing error messages) to form a complete execution result.

[0144] Obtain the pre-compiled software development kit (SDK) core library. This core library contains the core functions and basic architecture of the SDK, has high stability and compatibility, and generally does not change frequently.

[0145] The execution results are then combined with the core library of the software development kit (SDK). This combination process can employ different methods depending on the specific needs. For example, the functional module code from the execution results can be linked to the core library as a dynamic link library, or the functional modules from the execution results can be loaded into the core library via a plugin mechanism. During the combination process, it is crucial to ensure interface compatibility between the various parts and that the functions can work together effectively.

[0146] After the integration is complete, the generated customized SDK package undergoes comprehensive testing and verification to check whether its functional completeness, performance, and compatibility meet the expected requirements. If the tests pass, the customized SDK package is packaged and encapsulated to generate the final product that game developers can use, and delivered to the client or team that requested the customized packaging in accordance with the agreed method.

[0147] In this embodiment, non-core and frequently updated functional modules in the packaged SDK are pre-split into and deployed as multiple independent serverless computing functions, configured with combined interfaces, responding to customized packaging requests and generating customized SDK packages. This effectively meets the diverse SDK customization needs in mobile game development, improving development efficiency and SDK flexibility.

[0148] Reference Figure 2 An embodiment of the present invention provides a game SDK automated packaging efficiency improvement system 2, the system 2 specifically including: The packaging request module 201 is used to automatically trigger packaging task requests by listening to the version tag creation event through the Webhook configured in the code repository; The container scaling module 202 is used to send packaging task requests to the packaging service platform built on the Knative Serving framework, and to scale up or down the packager container instance in the Kubernetes cluster according to the current task queue load. The packaging command module 203 is used to execute packaging commands for the Android platform and the iOS platform in parallel in a resource-ready packaging container instance, and extract code change logs and build parameters during the packaging process to generate packaging data; The causal analysis module 204 is used to input the current packaging data and historical packaging data into the causal analysis engine based on the DoWhy framework, analyze the causal relationship between key build parameters and SDK product performance indicators, and output the optimal configuration recommendation file. The packaging optimization module 205 is used to train a packaging parameter optimization model by using historical packaging data and the optimal configuration recommendation file as training data, and then re-execute the packaging task based on the current packaging data. The user identification module 206 is used to determine the risk level of the packaging task based on the preset rule base and task status after the packaging task is completed, and dynamically adjust the access and operation permissions of relevant users to the packaging products, logs and analysis reports in combination with user role information.

[0149] It is understandable that, such as Figure 1 The content of the game SDK automated packaging efficiency improvement method embodiment shown is applicable to the game SDK automated packaging efficiency improvement system embodiment. The specific functions implemented by the game SDK automated packaging efficiency improvement system embodiment are the same as those shown below. Figure 1 The illustrated method for improving the efficiency of automated packaging of game SDKs is the same as the one shown, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the illustrated method for improving the efficiency of automated packaging of game SDKs are the same.

[0150] 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.

[0151] 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.

[0152] 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 game SDK automated packaging efficiency improvement method as described in any of the above methods.

[0153] 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.

[0154] 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.

[0155] 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.

[0156] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the game SDK automated packaging efficiency improvement method as described in any of the above methods.

[0157] 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.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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 game SDK automatic packaging efficiency method, characterized in that, The method specifically includes: By listening to the version tag creation event through a webhook configured in the code repository, a packaging task request can be automatically triggered; Packaging task requests are sent to a packaging service platform built on the Knative Serving framework, and the packager container instance is scaled up or down in the Kubernetes cluster according to the current task queue load. In a resource-ready packager container instance, package commands for the Android and iOS platforms are executed in parallel, and code change logs and build parameters are extracted during the packaging process to generate package data; The current packaging data and historical packaging data are input into the causal analysis engine based on the DoWhy framework to analyze the causal relationship between key build parameters and SDK product performance indicators, and output the optimal configuration recommendation file. The historical packaging data and the optimal configuration recommendation file are used as training data to train and generate a packaging parameter optimization model, and the packaging task is re-executed based on the current packaging data. After the packaging task is completed, the risk level of the packaging task is determined based on the preset rule base and the task status, and the access and operation permissions of relevant users to the packaging output, logs and analysis reports are dynamically adjusted in combination with user role information.

2. The method of claim 1, wherein, The process of automatically triggering a build task request by listening to the version tag creation event through a Webhook configured in the code repository specifically includes: In response to the version tag creation event listened to by the Webhook configured in the code repository, automatically receive HTTP requests sent by the code repository; Perform security verification on HTTP requests, and after successful verification, parse version tag information and code repository information from the HTTP request payload data; Based on the parsed version tag information and code repository information, a corresponding packaging task request is automatically encapsulated and generated, and the packaging task request is published to the work queue of the message middleware.

3. The method of claim 1, wherein, The step of sending the packaging task request to the packaging service platform built on the KnativeServing framework, and scaling up or down the packaging container instance in the Kubernetes cluster according to the current task queue load, specifically includes: Packaging task requests are temporarily stored in the request buffer, and the workload metrics of the request buffer are continuously monitored. Based on the comparison results between workload metrics and preset scaling targets, the number of container instances required for the Kubernetes cluster is dynamically calculated. Send instructions to the packaging service platform built on the Knative Serving framework to automatically adjust the number of running packager container instances based on the required number of container instances.

4. The method of claim 1, wherein, The process of executing packaging commands for both Android and iOS platforms in parallel within a resource-ready packager container instance, and extracting code change logs and build parameters during the packaging process to generate packaging data, specifically includes: In response to the packaging task request, the first child process and the second child process are launched simultaneously in the compute instance to execute the packaging commands for the Android platform and the iOS platform, respectively. In the process of executing the packaging command, a metadata extraction operation is synchronously performed to obtain a code change log and a build parameter; Based on the code change log and the build parameter, packaging data is automatically generated, which includes an SDK product, a dependency list, and a Markdown document for recording functional changes.

5. The method of claim 1, wherein, The packaging data of this time is input into a causal analysis engine based on a DoWhy framework together with historical packaging data, the causal relationship between key build parameters and performance indicators of the SDK product is analyzed, and an optimal configuration recommendation file is output, specifically including: The set of build parameters in the packaging data of this time and the set of performance indicators of the SDK product are obtained, and are combined with historical packaging data to form an analysis data set; The analysis data set is input into a causal analysis engine based on a DoWhy framework, and a causal analysis process is performed by the causal analysis engine to quantify the causal effect of the set of build parameters on the set of performance indicators; Based on the quantified causal effect, a number of key build parameters that have a significant positive causal effect on the target performance indicator are identified from the set of build parameters, and a quantification result is obtained; According to the quantification result, the key build parameters are assigned optimal values that can optimize the target performance indicator, and an optimal configuration recommendation file is generated.

6. The method of claim 1, wherein, The historical packaging data and the optimal configuration recommendation file are used as training data to train a packaging parameter optimization model, and the packaging task is re-executed combined with the packaging data of this time, specifically including: A training data set is constructed according to the build parameters in the historical packaging data and the corresponding optimal configuration recommendation file; A machine learning model is trained using the training data set to generate a packaging parameter optimization model, which is used to predict optimal parameter configurations according to input build parameters; The first build parameter is extracted from the packaging data of this time and input into the packaging parameter optimization model to output the predicted optimal parameter configuration; The first build parameter in the packaging data of this time is updated according to the predicted optimal parameter configuration, and the packaging task is re-executed based on the updated first build parameter.

7. The method of claim 1, wherein, After the packaging task is completed, the risk level of the packaging task is determined according to a preset rule base and the task state, and the access and operation permissions of related users to the packaging product, logs and analysis reports are dynamically adjusted combined with user role information, specifically including: After the packaging task is completed, the state and context information of the packaging task are obtained, and the risk level of the packaging task is determined combined with a preset rule base; User role information associated with the packaging task is obtained, and the access and operation permissions of corresponding related users to the build product under the current risk level are determined based on the risk level and the user role information; According to the determined access and operation permissions, the access control strategy of related users to the build product and log data output by the packaging task is dynamically updated.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: The non-core and frequently updated functional modules in the packaged SDK are pre-split and deployed as multiple independent serverless computing functions; A combination interface is configured, which is used to predefine different functional combination modes and corresponding computing function call links; In response to the customized packaging request, a corresponding target call link is determined from the pre-defined function combination mode according to the function requirement in the customized packaging request and the combination interface; A number of corresponding serverless computing functions are called to execute the target call link and obtain an execution result; A pre-compiled software development kit core library is obtained, the execution result is combined with the software development kit core library, and a customized SDK package is generated.

9. A game SDK automatic packaging efficiency system, characterized in that, The system specifically comprises: The packaging request module is configured to listen to version tag creation events through Webhook configured in the code repository to automatically trigger packaging task requests; The container expansion module is configured to send the packaging task request to a packaging service platform built based on a Knative Serving framework and to expand or shrink the container instance of the packager in the Kubernetes cluster according to the current task queue load; The packaging command module is configured to execute the packaging commands of the Android platform and the iOS platform in the resource-ready packager container instance in parallel, extract the code change log and the build parameter during the packaging process, and generate packaging data; The causal analysis module is configured to input the packaging data of this time and historical packaging data into a causal analysis engine based on a DoWhy framework to analyze the causal relationship between the key build parameter and the performance index of the SDK product and to output an optimal configuration recommendation file; The packaging optimization module is configured to use the historical packaging data and the optimal configuration recommendation file as training data to train a packaging parameter optimization model and to re-execute the packaging task in combination with the packaging data of this time; The user identification module is configured to determine the risk level of the packaging task according to a preset rule library and a task state after the packaging task is completed and to dynamically adjust the access and operation permissions of the packaging product, the log and the analysis report of the related users in combination with the user role information.

10. A computer device, comprising: The system specifically comprises: A memory and a processor and a computer program stored in the memory, when the computer program is executed on the processor, the game SDK automatic packaging efficiency improvement method is realized as claimed in any one of claims 1 to 8.

Images