Cross-platform software construction method and device, electronic equipment and medium

Abstract

The present disclosure provides a cross-platform software construction method and device, electronic equipment and medium, relating to the technical field of computer. The implementation scheme is: in response to a construction request for one of a plurality of candidate platforms, determining a target platform corresponding to a to-be-constructed task; obtaining a platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of a plurality of candidate dependent libraries corresponding to the target platform; based on a preset priority weight model, determining an adaptation score of each candidate dependent library and the target platform; based on the adaptation score, determining a target version dependent library of the target platform; constructing a construction task execution graph containing a plurality of candidate tasks; identifying a to-be-pruned task inconsistent with the target version dependent library from the construction task execution graph, and performing pruning processing on the construction task execution graph; and based on the pruned construction task execution graph and the source code corresponding to the to-be-constructed task, performing software construction.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and specifically to a cross-platform software construction method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of mobile internet technology, cross-platform development has become an important trend in the field of software engineering. Developers typically hope to support multiple different target platforms such as Android, iOS, and HarmonyOS by writing code once and running it on multiple clients, using the same set of business logic code.

[0003] Therefore, there is a need for a software building method that can compile, link, and package shared code and platform-specific code, taking into account the characteristics of different target platforms.

[0004] The methods described in this section are not necessarily methods that had been previously conceived or adopted. Unless otherwise specified, no method described in this section should be assumed to be prior art simply because it is included in this section. Similarly, unless otherwise specified, the issues mentioned in this section should not be considered to be accepted in any prior art. Summary of the Invention

[0005] This disclosure provides a cross-platform software construction method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0006] According to one aspect of this disclosure, a cross-platform software construction method is provided, comprising: responding to a construction request for one of a plurality of candidate platforms, determining a target platform corresponding to a task to be constructed; obtaining a platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of a plurality of candidate dependency libraries corresponding to the target platform; determining an adaptation score between each of the plurality of candidate dependency libraries and the target platform based on a preset priority weight model, wherein the adaptation score is determined at least based on a platform compatibility index between each candidate dependency library and the target platform; determining a target version dependency library of the target platform from the plurality of candidate dependency libraries based on the adaptation score; constructing a construction task execution graph containing a plurality of candidate tasks; identifying, from the construction task execution graph, tasks to be pruned that are inconsistent with the target version dependency library among the plurality of candidate tasks, and pruning the construction task execution graph; and performing software construction based on the pruned construction task execution graph and the source code corresponding to the task to be constructed.

[0007] According to another aspect of this disclosure, a cross-platform software building apparatus is provided, comprising: a first determining module configured to determine a target platform corresponding to a build task in response to a build request for one of a plurality of candidate platforms; an obtaining module configured to obtain a platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of a plurality of candidate dependency libraries corresponding to the target platform; and a second determining module configured to determine an adaptation score between each of the plurality of candidate dependency libraries and the target platform based on a preset priority weight model, wherein the adaptation score is based at least on each candidate dependency library. The platform compatibility index between the dependency library and the target platform is used to determine the target version dependency library of the target platform from the multiple candidate dependency libraries based on the adaptation score; the build module is configured to build a build task execution graph containing multiple candidate tasks; the pruning module is configured to identify tasks in the build task execution graph that are inconsistent with the target version dependency library and prune the build task execution graph; and the execution module is configured to execute software build based on the pruned build task execution graph and the source code corresponding to the task to be built.

[0008] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the methods described above.

[0009] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the above-described method.

[0010] According to another aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the above-described method.

[0011] According to one or more embodiments of this disclosure, a cross-platform software construction method is provided. Through a dynamic decision-making mechanism based on platform compatibility weights, intelligent matching and differentiated management of dependency library versions and target platform characteristics are achieved, breaking the limitation of mandatory unified dependency versions in traditional multi-terminal development. At the same time, combined with the pruning strategy of the build task execution graph, compilation conflicts caused by version differences and interference from non-target platform tasks are effectively isolated, thereby significantly improving the stability and execution efficiency of cross-platform software construction while ensuring the purity of the build environment.

[0012] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0013] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0014] Figure 1 This is a schematic diagram illustrating an example system in which various methods described herein may be implemented according to exemplary embodiments;

[0015] Figure 2 A flowchart illustrating a cross-platform software construction method according to an embodiment of the present disclosure is shown; Figure 3 A flowchart illustrating a portion of the process of a cross-platform software building method according to an embodiment of the present disclosure is shown; Figure 4 A structural block diagram of a cross-platform software building apparatus according to an embodiment of the present disclosure is shown; Figure 5 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0016] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0018] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. Furthermore, the term "and / or" as used in this disclosure covers any one of the listed items and all possible combinations thereof.

[0019] In existing cross-platform development technologies (such as Kotlin Multiplatform), to maintain version consistency across multiple platforms, developers are often forced to use the lowest common dependency version across all platforms, resulting in the inability to enjoy the features and optimizations of newer libraries; or, when each platform's technology stack evolves independently, it becomes difficult to handle the contradiction between platform decoupling and code reuse. While some existing technical solutions support multi-target platform configuration, they typically only implement a simple two-dimensional static mapping from "platform type" to "dependency version," lacking intelligent evaluation of version suitability and failing to automatically make optimal decisions in complex dependency conflict scenarios.

[0020] To address the aforementioned issues, this disclosure provides a cross-platform software construction method. Through a dynamic decision-making mechanism based on platform compatibility weights, it achieves intelligent matching and differentiated management of dependency library versions and target platform characteristics, breaking the limitation of mandatory unified dependency versions in traditional multi-terminal development. At the same time, combined with the pruning strategy of the build task execution graph, it effectively isolates compilation conflicts caused by version differences and interference from non-target platform tasks, thereby significantly improving the stability and execution efficiency of cross-platform software construction while ensuring the purity of the build environment.

[0021] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0022] Figure 1 A schematic diagram of an exemplary system 100 in which the various methods and apparatus described herein can be implemented according to embodiments of this disclosure is shown. Reference Figure 1 The system 100 includes one or more client devices 101, 102, 103, 104, 105 and 106, a server 120, and one or more communication networks 110 coupling the one or more client devices to the server 120. The client devices 101, 102, 103, 104, 105 and 106 can be configured to execute one or more applications.

[0023] In embodiments of this disclosure, server 120 may run one or more services or software applications that enable the execution of cross-platform software building methods.

[0024] In some embodiments, server 120 may also provide other services or software applications that may include non-virtual and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services, such as to users of client devices 101, 102, 103, 104, 105 and / or 106 under a Software as a Service (SaaS) model.

[0025] exist Figure 1 In the configuration shown, server 120 may include one or more components that implement the functions performed by server 120. These components may include software components, hardware components, or combinations thereof that can be executed by one or more processors. Users operating client devices 101, 102, 103, 104, 105, and / or 106 can sequentially interact with server 120 using one or more client applications to utilize the services provided by these components. It should be understood that various different system configurations are possible and may differ from system 100. Therefore, Figure 1 This is an example of a system used to implement the methods described herein, and is not intended to be limiting.

[0026] Users can use client devices 101, 102, 103, 104, 105, and / or 106 to execute cross-platform software building methodologies. The client devices can provide interfaces that enable users to interact with them. The client devices can also output information to the user through these interfaces. Although... Figure 1 Only six client devices are described, but those skilled in the art will understand that this disclosure can support any number of client devices.

[0027] Client devices 101, 102, 103, 104, 105, and / or 106 may include various types of computer devices, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, wearable devices, smart screen devices, self-service terminal devices, service robots, gaming systems, thin clients, various messaging devices, sensors, or other sensing devices. These computer devices can run various types and versions of software applications and operating systems, such as Microsoft Windows, Apple iOS, UNIX-like operating systems, Linux or Linux-like operating systems (such as Google Chrome OS); or include various mobile operating systems, such as Microsoft Windows Mobile OS, iOS, Windows Phone, and Android. Portable handheld devices may include cellular phones, smartphones, tablets, personal digital assistants (PDAs), etc. Wearable devices may include head-mounted displays (such as smart glasses) and other devices. Gaming systems may include various handheld gaming devices, internet-enabled gaming devices, etc. Client devices are capable of executing various applications, such as various internet-related applications, communication applications (such as email applications), short message service (SMS) applications, and can use various communication protocols.

[0028] Network 110 can be any type of network well known to those skilled in the art, and can support data communication using any of a variety of available protocols (including but not limited to TCP / IP, SNA, IPX, etc.). By way of example only, one or more networks 110 can be a local area network (LAN), an Ethernet-based network, a token ring network, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., Bluetooth, WIFI), and / or any combination of these and / or other networks.

[0029] Server 120 may include one or more general-purpose computers, special-purpose server computers (e.g., PC (personal computer) servers, UNIX servers, mid-range servers), blade servers, mainframe computers, server clusters, or any other suitable arrangement and / or combination. Server 120 may include one or more virtual machines running a virtual operating system, or other computing architectures involving virtualization (e.g., one or more flexible pools of logical storage devices that can be virtualized to maintain virtual storage devices for servers). In various embodiments, server 120 may run one or more services or software applications that provide the functionality described below.

[0030] The computing unit in server 120 can run one or more operating systems, including any of the aforementioned operating systems and any commercially available server operating system. Server 120 can also run any of a variety of additional server applications and / or middleware applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, etc.

[0031] In some implementations, server 120 may include one or more applications to analyze and merge data feeds and / or event updates received from users of client devices 101, 102, 103, 104, 105, and 106. Server 120 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client devices 101, 102, 103, 104, 105, and 106.

[0032] In some implementations, server 120 can be a server for a distributed system or a server integrated with blockchain. Server 120 can also be a cloud server, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology. A cloud server is a host product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0033] System 100 may also include one or more databases 130. In some embodiments, these databases may be used to store data and other information. For example, one or more of the databases 130 may be used to store information such as audio files and video files. Databases 130 may reside in various locations. For example, a database used by server 120 may be local to server 120, or it may be located away from server 120 and may communicate with server 120 via a network-based or dedicated connection. Databases 130 may be of different types. In some embodiments, the database used by server 120 may be, for example, a relational database. One or more of these databases may store, update, and retrieve data from and from the databases in response to commands.

[0034] In some embodiments, one or more of the databases 130 may also be used by an application to store application data. The databases used by the application may be of different types, such as key-value stores, object stores, or regular stores supported by a file system.

[0035] Figure 1 The system 100 can be configured and operated in various ways to enable the application of the various methods and apparatus described in this disclosure.

[0036] Figure 2 A flowchart of a cross-platform software construction method according to an embodiment of the present disclosure is shown.

[0037] like Figure 2 As shown, the cross-platform software construction method 200 includes: Step S201: In response to a build request for one of multiple candidate platforms, determine the target platform corresponding to the task to be built; Step S202: Obtain the platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of multiple candidate dependency libraries corresponding to the target platform; Step S203: Based on a preset priority weight model, determine the adaptation score between each candidate dependency library and the target platform, wherein the adaptation score is determined at least based on the platform compatibility index between each candidate dependency library and the target platform. Step S204: Based on the adaptation score, determine the target version dependency library for the target platform from the plurality of candidate dependency libraries; Step S205: Construct a construction task execution graph containing multiple candidate tasks; Step S206: Identify, from the build task execution graph, tasks that are inconsistent with the target version's dependency library among the multiple candidate tasks and perform pruning on the build task execution graph; and Step S207: Based on the pruned construction task execution graph and the source code corresponding to the task to be built, execute the software construction.

[0038] In step S201, the target platform corresponding to the task to be built can be determined by listening to build requests from users. For example, multiple candidate platforms may include Android, iOS, HarmonyOS, etc. By listening to and parsing build requests from users, this step can determine the target platform corresponding to the task to be built.

[0039] For example, by parsing keywords in the build request, such as "Android," "iOS," or "Harmony," or by reading specific environment variables in the continuous integration environment, such as TARGET_PLATFORM, the target platform the user intends to build on can be accurately identified from multiple supported candidate platforms. This achieves automatic awareness of build intent, eliminating the need for users to manually switch project-level global configurations and supporting concurrent execution of build tasks for different platforms within the same codebase.

[0040] After determining the target platform, step S202 dynamically loads a platform-specific configuration file (e.g., androidlibs.versions.toml or ioslibs.versions.toml) instead of loading the default general version directory. Understandably, the platform configuration file for the target platform comprehensively lists the set of dependency library versions applicable to that platform. This achieves physical isolation of dependency configurations, avoids configuration pollution caused by mixing dependency versions from multiple platforms, and provides a clean data source for subsequent precise version selection.

[0041] Step S203 then uses a preset priority weight model to quantitatively evaluate the candidate versions in the configuration file to obtain the adaptation score of each candidate dependency library.

[0042] Based on the score calculated in step S203, step S204 selects the version with the highest score as the target version dependency library for this build. For example, compose-multiplatform 1.7.1 is locked for the Android platform, while 1.8.1 is locked for the iOS platform. This ensures that each platform can use the optimal dependency version, leveraging the advantages of the new version while avoiding the compatibility risks of the old version, thus achieving differentiated dependency management in a multi-platform scenario with a single code.

[0043] In step S205, the build tool (such as Gradle) generates a build task execution graph based on the project configuration, which includes possible task nodes such as compilation, linking, packaging, and verification. Since the project is configured to support multiple platforms, the initially generated graph may contain tasks involving multiple platforms, such as tasks related to both `compileAndroid` and `compileIos`. Therefore, in step S206, the task execution graph needs to be traversed to query the dependency library versions associated with each task. If a task (e.g., the iOS metadata compilation task) depends on a version that is inconsistent with the target version determined in step S204 (e.g., the selected Android version), or if the task itself belongs to a non-target platform, step S206 will identify it as a task to be pruned and disable or remove it from the execution graph. This precisely eliminates metadata compilation pollution and task conflicts caused by dependency version differences, prevents erroneous interference from non-target platforms, and significantly improves the success rate and speed of the build.

[0044] Finally, in step S207, the compiler is invoked to build the source code, converting the source code into a binary product for the target platform, ensuring the correctness and purity of the final build product, and achieving efficient and stable cross-platform software delivery.

[0045] As can be seen, Method 200 achieves intelligent matching and differentiated management of dependency library versions and target platform characteristics through a dynamic decision-making mechanism based on platform compatibility weights, breaking the limitation of mandatory unified dependency versions in traditional multi-terminal development. At the same time, combined with the pruning strategy of the build task execution graph, it effectively isolates compilation conflicts caused by version differences and interference from non-target platform tasks, thereby significantly improving the stability and execution efficiency of cross-platform software building while ensuring the purity of the build environment.

[0046] In practical applications, to ensure the accuracy of version decisions, relying solely on a single-dimensional evaluation (such as selecting only the latest version or only matching the SDK version) is often insufficient to handle complex cross-platform dependency environments. Therefore, this disclosure further refines the calculation logic of the priority weight model and introduces multi-dimensional data metrics to comprehensively quantify the adaptability of dependency libraries.

[0047] According to some embodiments, step S203 includes: obtaining platform compatibility metrics, functional requirement coverage metrics, performance optimization metrics, and dependency chain stability metrics for each candidate dependency library, wherein the platform compatibility metrics are calculated based on API compatibility matrix data captured by a component information acquisition tool, the functional requirement coverage metrics are calculated based on the matching results between the target functional interfaces extracted from the source code corresponding to the task to be built and the functional list supported by the candidate dependency library version, the performance optimization metrics are calculated based on the historical build data or benchmark test data of the candidate dependency library version, and the dependency chain stability metrics are calculated based on the transitive dependency conflict analysis results of the cross-platform dependency chain graph constructed for the candidate dependency library version; and determining the weights corresponding to the platform compatibility metrics, the functional requirement coverage metrics, the performance optimization metrics, and the dependency chain stability metrics respectively based on the preset priority weight model, so as to calculate the adaptation score of each candidate dependency library.

[0048] Specifically, this embodiment achieves a comprehensive evaluation of candidate dependency libraries by introducing component information acquisition tools (such as MCP tools) and static code analysis technology.

[0049] First, platform compatibility metrics are a basic threshold. By capturing the API compatibility matrix maintained by the official or community, it is determined whether the candidate version has known crashes or incompatibilities with the operating system version of the current target platform.

[0050] Secondly, the functional requirements coverage metric focuses on business relevance. For example, it can be used to parse the developer's source code through an Abstract Syntax Tree (AST) to extract the key APIs actually called in the code. If a candidate version is stable but does not support the new feature, its score will be significantly reduced.

[0051] Secondly, performance optimization metrics focus on operational efficiency. Based on historical build data or benchmark tests, the performance of candidate versions in terms of startup speed, memory usage, or package size is evaluated, and the version with better performance is selected first.

[0052] Finally, the dependency chain stability metric is used to prevent global risks. By constructing a cross-platform dependency chain graph, it can be predicted whether the transitive dependencies of this version will conflict with the shared dependencies of other platforms.

[0053] Finally, based on the preset weighting strategy, a corresponding weight value is assigned to each indicator to calculate the comprehensive score, thereby selecting the optimal solution to determine the target version dependency library of the target platform.

[0054] The multi-dimensional weighted evaluation system described above effectively avoids the risks associated with blindly upgrading dependencies in traditional development. By dynamically adapting the platform, scenario, and version in three dimensions, it ensures that the selected dependency versions are not only technically compatible but also meet business functional requirements and maintain performance. This refined decision-making mechanism makes cross-platform development not just about getting it to run, but about achieving optimal adaptation, greatly reducing the later maintenance costs caused by improper dependency version selection.

[0055] However, after implementing dynamic dependency version optimization, cross-platform development faces a new challenge: since different platforms may be compatible with different versions of dependency libraries, and shared business source code is usually written based on a specific base version, the API interfaces called in the source code may be incompatible with the currently selected target version dependency library when building for a specific target platform, such as changes in method signatures or parameter tuning issues. To solve this code-level compatibility problem and ensure that the source code can still compile and run correctly after dynamically switching dependency versions, this disclosure proposes an automated API difference detection and repair scheme.

[0056] Figure 3 A schematic diagram illustrating a portion of the flow of a cross-platform software construction method according to embodiments of the present disclosure is shown. Figure 3 As shown, the cross-platform software construction method 200 also includes: Step S301: Obtain the API difference data of the target version dependency library relative to the base version dependency library referenced by the source code corresponding to the task to be built, wherein the API difference data includes at least one of interface signature change data and parameter list change data. Step S302: Map the API difference data to the corresponding conflict type, and generate API adaptation rules based on the conflict type using a preset conflict repair template; Step S303: Scan the abstract syntax tree of the source code using the API adaptation rules to detect whether there are API call nodes that are incompatible with the target version's dependency library; Step S304: In response to detecting the incompatible API call node, select either the code conversion logic or the adaptation layer wrapper function to repair the source code according to the conflict type corresponding to the incompatible API call node.

[0057] Before or in the early stages of the build process, step S301 uses a component information acquisition tool, such as the MCP tool, to compare the base version on which the current source code was written with the target version actually selected in step S204. By extracting the differences between the two, specific discrepancies are identified, such as changes in interface signatures, parameter types, parameter order adjustments, or method obsolescence. This proactively identifies potential runtime crashes or compilation errors, making implicit version incompatibility issues explicit.

[0058] In step S302, for example, the acquired discrepancies can be categorized into conflict types such as "parameter incompatibility," "method name change," and "platform-specific implementation missing." For each type, a pre-set template is invoked to dynamically generate specific adaptation rules. For example, the pre-set templates may include parameter type conversion templates, method replacement templates, etc. This transforms complex API differences into standardized, computer-executable rules, providing a logical basis for subsequent automated remediation.

[0059] In step S303, the source code is parsed to generate an Abstract Syntax Tree (AST), and the nodes in the AST are traversed and scanned using the generated adaptation rules. All code locations that call the modified API are precisely located and marked as incompatible API call nodes. This achieves code-level problem localization, enabling comprehensive coverage of compatibility vulnerabilities caused by version upgrades or downgrades without relying on manual queries.

[0060] Finally, in step S304, different repair strategies can be adopted for different types of conflicts.

[0061] According to some embodiments, step S304 includes: in response to detecting the incompatible API call node, determining that the conflict type corresponding to the incompatible API call node is parameter incompatibility, and using the code conversion logic to perform parameter order reordering or type conversion operator insertion in the abstract syntax tree to repair the source code; or determining that the conflict type corresponding to the incompatible API call node is method name change or platform-specific implementation missing, generating an adaptation layer wrapper function, and replacing the original call in the source code with a call to the adaptation layer wrapper function to repair the source code.

[0062] Understandably, for minor parameter differences, code transformation logic is directly executed on the AST, such as rearranging parameter order or inserting type conversion operators. However, for method name changes or missing functionality, an intermediate adaptation layer wrapper function is generated, and the original call is replaced with a call to the adaptation layer wrapper function, thus shielding the underlying differences. This achieves automated code adaptation, eliminating the need for developers to manually write numerous macro definitions to handle multi-platform differences, significantly reducing maintenance costs, and ensuring the portability of shared code in heterogeneous version environments.

[0063] Through the automated adaptation process of steps S301 to S304 above, code-level awareness and automatic repair of cross-platform dependency version differences are achieved. Without changing the developer's original coding habits, the API interface differences between different dependency versions are automatically eliminated by using precise reconstruction of the AST syntax tree and adaptation layer encapsulation technology. This avoids the pollution of business code by a large number of intrusive conditional compilation instructions. While ensuring the purity and high reusability of core business logic, it greatly reduces the maintenance cost and technical threshold of multi-terminal adaptation.

[0064] While rule-based adaptation can efficiently handle common conflicts such as parameter changes or simple interface renaming, in real-world cross-platform development scenarios, deep incompatibility issues often arise due to differences in underlying architecture or complex asynchronous logic changes. To address these complex scenarios that are difficult to cover with pre-defined rules, this disclosure further introduces a deep repair mechanism based on an artificial intelligence model.

[0065] According to some embodiments, method 200 further includes: in response to detecting an API call conflict that cannot be repaired by the code conversion logic or the adaptation layer wrapper function based on the API adaptation rules, inputting the API difference data, the business logic code in the source code, and information representing the target platform into a pre-trained repair model; using the repair model to generate repair code that includes data structure conversion or adaptation layer encapsulation; and applying the repair code to the source code.

[0066] Specifically, when the rule engine in step S302 cannot match a valid repair template, the above-mentioned scheme will be implemented. At this time, method 200 will collect three types of key contextual information as input: a detailed description of API differences obtained from the MCP tool, such as deep changes in data structure fields; the business logic code snippet currently causing the conflict; and an explanation of the target platform's ecosystem limitations. This information is fed into a pre-trained model specifically tuned for cross-platform code repair. Through deep analysis, the model generates complex repair code that bridges the differences, which may involve a complete transformation of the data structure or the generation of an adaptation layer encapsulation containing specific business logic. After the generated code passes compilation and verification, it is automatically merged into the source code.

[0067] This overcomes the limitations of static rules, enabling it to handle non-obvious and logically complex cross-platform compatibility issues, greatly expanding the boundaries of automatic adaptation, and achieving comprehensive repair capabilities for cross-platform code problems.

[0068] After resolving source code-level compatibility issues, the next step is to focus on the execution level of the build system itself. Ensuring that build tasks are executed correctly and cleanly in a complex dependency environment with multiple versions coexisting is another line of defense for successful builds. This requires precise control and pruning of the build task execution graph.

[0069] According to some embodiments, step S206 includes: querying the dependency library version associated with each of the multiple candidate tasks in the build task execution graph based on a pre-established dependency library version and build task association mapping table; performing a consistency comparison between the dependency library version associated with the candidate task and the target version dependency library to determine the task to be pruned; and performing pruning processing on the build task execution graph.

[0070] Specifically, this embodiment abandons the traditional approach of coarse-grained filtering based solely on the target platform name, instead delving into version-level comparison and filtering. Step S206 parses the entire task graph during the build initialization phase and establishes a fine-grained mapping table of task ID -> associated version set -> target platform. For example, task a associated with the Android platform is recorded as dependent on Compose 1.7.1, while task b associated with iOS is recorded as dependent on Compose 1.8.1. When step S204 determines that the current build target is Android and the dependent version is locked at 1.7.1, the mapping table can be traversed to find that the iOS-related tasks require version 1.8.1, which is inconsistent with the current target. Based on this comparison result, these version-conflicting task nodes are marked as tasks to be pruned and removed before the build task execution graph is executed. This achieves precise pruning based on dependency version associations, ensuring that the build process strictly adheres to the version constraints of the current target platform, fundamentally preventing build environment chaos caused by the coexistence of multiple version dependencies.

[0071] To further clarify the targets of pruning, this disclosure specifically defines task types that are easily overlooked but are highly likely to cause compiler pollution.

[0072] According to some embodiments, the pruning task includes at least one of a non-target platform task and a metadata compilation task caused by differences in dependent library versions.

[0073] Specifically, the tasks to be pruned mainly fall into two categories: The first category is non-target platform tasks, which are explicit redundancies. For example, when building HarmonyOS applications, resource processing or code compilation tasks on the iOS platform should be completely shielded. The second category is metadata compilation tasks caused by differences in dependency library versions. In the Kotlin platform (Kotlin Multiplatform, KMP), some tasks generate metadata for sharing across multiple platforms. If metadata tasks with versions inconsistent with their dependencies are allowed to execute, the generated metadata may carry incorrect API signature information, thereby polluting subsequent compilation of common code. This embodiment identifies and prunes these specific metadata tasks, blocking the propagation of errors. It effectively solves the metadata pollution problem unique to KMP multiplatform builds, ensuring that shared code can be compiled based on the correct platform context in a multi-version dependency environment, significantly improving the success rate of cross-platform project builds.

[0074] In summary, the cross-platform software construction method disclosed herein, with dynamic version adaptation and precise task pruning at its core, provides an adaptive cross-platform development and construction approach. On the one hand, through a multi-dimensional weighted decision model and a dependency association pruning mechanism, it solves the systemic problem of inconsistent dependency versions and the potential for compilation pollution in multi-platform development. On the other hand, supplemented by a rule-based and AI model-based two-layer code repair strategy, it achieves automated elimination of API differences in heterogeneous dependency environments. This dual guarantee of isolated build environment and automated business code repair not only significantly reduces the maintenance threshold of cross-platform projects but also provides strong technical support for the large-scale deployment of a single-code, multi-platform architecture in complex business scenarios.

[0075] According to another aspect of this disclosure, a cross-platform software building apparatus is also provided.

[0076] like Figure 4 As shown, the cross-platform software building apparatus 400 includes: a first determining module 401, configured to determine the target platform corresponding to the task to be built in response to a build request for one of a plurality of candidate platforms; an obtaining module 402, configured to obtain a platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of a plurality of candidate dependency libraries corresponding to the target platform; and a second determining module 403, which determines the compatibility score between each of the plurality of candidate dependency libraries and the target platform based on a preset priority weight model, wherein the compatibility score is based at least on the compatibility score between each candidate dependency library and the target platform. The platform compatibility index between platforms is used to determine the target version dependency library of the target platform from the multiple candidate dependency libraries based on the adaptation score; the construction module 405 is configured to construct a construction task execution graph containing multiple candidate tasks; the pruning module 406 is configured to identify tasks in the construction task execution graph that are inconsistent with the target version dependency library and prune the construction task execution graph; and the execution module 407 is configured to execute software construction based on the pruned construction task execution graph and the source code corresponding to the task to be built.

[0077] The cross-platform software build device 400 achieves intelligent matching and differentiated management of dependency library versions and target platform characteristics through a dynamic decision-making mechanism based on platform compatibility weights, breaking the limitation of mandatory unified dependency versions in traditional multi-terminal development. At the same time, combined with the pruning strategy of the build task execution graph, it effectively isolates compilation conflicts caused by version differences and interference from non-target platform tasks, thereby significantly improving the stability and execution efficiency of cross-platform software build while ensuring the purity of the build environment.

[0078] It is understood that the various components of the cross-platform software building apparatus 400 can be configured to execute the various method steps defined in method 200 to achieve efficient task scheduling, which the applicant will not elaborate on here.

[0079] According to another aspect of this disclosure, an electronic device is also provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a cross-platform software building method.

[0080] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is also provided, wherein the computer instructions are used to cause the computer to perform a cross-platform software building method.

[0081] According to another aspect of this disclosure, a computer program product is also provided, including a computer program, wherein the computer program implements a cross-platform software construction method when executed by a processor.

[0082] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0083] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, output unit 507, storage unit 508, and communication unit 509. Input unit 506 can be any type of device capable of inputting information to electronic device 500. Input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device, and may include, but is not limited to, a mouse, keyboard, touchscreen, trackpad, trackball, joystick, microphone, and / or remote control. Output unit 507 can be any type of device capable of presenting information, and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 508 may include, but is not limited to, disk and optical disk. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth. TM Devices, 802.11 devices, WiFi devices, WiMax devices, cellular communication devices and / or the like.

[0084] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as cross-platform software construction methods. For example, in some embodiments, the cross-platform software construction method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the cross-platform software construction method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform cross-platform software construction methods by any other suitable means (e.g., by means of firmware).

[0085] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0086] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0087] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0088] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0089] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0090] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0091] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0092] While embodiments or examples of this disclosure have been described with reference to the accompanying drawings, it should be understood that the methods, systems, and devices described above are merely exemplary embodiments or examples, and the scope of the invention is not limited by these embodiments or examples, but only by the granted claims and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. Furthermore, the steps may be performed in a different order than that described in this disclosure. Further, various elements in the embodiments or examples may be combined in various ways. Importantly, as the technology evolves, many elements described herein can be replaced by equivalents that appear after this disclosure.

Claims

1. A method for building cross-platform software, the method comprising: In response to a build request for one of multiple candidate platforms, determine the target platform corresponding to the task to be built; Obtain the platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of multiple candidate dependency libraries corresponding to the target platform; Based on a preset priority weight model, the adaptation score of each candidate dependency library among the plurality of candidate dependency libraries and the target platform is determined, wherein the adaptation score is determined at least based on the platform compatibility index between each candidate dependency library and the target platform. Based on the adaptation score, the target version dependency library for the target platform is determined from the plurality of candidate dependency libraries; Construct a build task execution graph that includes multiple candidate tasks; From the build task execution graph, identify the candidate tasks that are inconsistent with the target version's dependency library and perform pruning on the build task execution graph; and Based on the pruned task execution graph and the source code corresponding to the task to be built, the software is built.

2. The method according to claim 1, further comprising: Obtain API difference data of the target version dependency library relative to the base version dependency library referenced by the source code corresponding to the task to be built, wherein the API difference data includes at least one of interface signature change data and parameter list change data; The API difference data is mapped to the corresponding conflict type, and API adaptation rules are generated based on the conflict type using a preset conflict repair template. The abstract syntax tree of the source code is scanned using the API adaptation rules to detect any API call nodes that are incompatible with the target version's dependency libraries; and In response to the detection of the incompatible API call node, the source code is repaired by selecting either the code conversion logic or the adaptation layer wrapper function, based on the conflict type corresponding to the incompatible API call node.

3. The method according to claim 2, wherein, In response to the detection of the incompatible API call node, and based on the conflict type corresponding to the incompatible API call node, one of the code conversion logic and the adaptation layer wrapper function is selected to repair the source code, including: In response to the detection of the incompatible API call node, and based on the determination that the conflict type corresponding to the incompatible API call node is parameter incompatibility, the code conversion logic is used to perform parameter order reordering or type conversion operator insertion in the abstract syntax tree to repair the source code; or Based on the determination that the conflict type corresponding to the incompatible API call node is a method name change or a platform-specific implementation missing, an adaptation layer wrapper function is generated, and the original call in the source code is replaced with a call to the adaptation layer wrapper function to repair the source code.

4. The method according to any one of claims 1-3, wherein, The method of determining the compatibility score between each candidate dependency library and the target platform based on a preset priority weight model includes: For each candidate dependency library, obtain its platform compatibility metrics, functional requirement coverage metrics, performance optimization metrics, and dependency chain stability metrics. The platform compatibility metrics are calculated based on API compatibility matrix data captured by a component information acquisition tool. The functional requirement coverage metrics are calculated based on the matching results between the target functional interfaces extracted from the source code corresponding to the task to be built and the list of functions supported by the candidate dependency library version. The performance optimization metrics are calculated based on historical build data or benchmark test data of the candidate dependency library version. The dependency chain stability metrics are calculated based on the transitive dependency conflict analysis results of the cross-platform dependency chain graph constructed for the candidate dependency library versions. Based on the preset priority weight model, the weights corresponding to the platform compatibility index, the functional requirement coverage index, the performance optimization index, and the dependency chain stability index are determined respectively, so as to calculate the adaptation score of each candidate dependency library.

5. The method according to any one of claims 1-4, wherein, The step of identifying tasks that are inconsistent with the target version's dependency library from the build task execution graph and pruning the build task execution graph includes: Based on the pre-established mapping table between dependency library versions and build tasks, query the dependency library version associated with each of the multiple candidate tasks in the build task execution graph; The dependency library versions associated with candidate tasks are compared with the target version dependency library to determine the tasks to be pruned; and The execution graph of the construction task is pruned.

6. The method according to claim 5, wherein, The tasks to be pruned include at least one of non-target platform tasks and metadata compilation tasks caused by differences in dependent library versions.

7. The method according to claim 2, further comprising: In response to the detection of API call conflicts that cannot be repaired by the code conversion logic or the adaptation layer wrapper function based on the API adaptation rules, the API difference data, the business logic code in the source code, and the information representing the target platform are input into the pre-trained repair model. The repair model is used to generate repair code that includes data structure transformation or adaptation layer encapsulation; as well as The fix is ​​applied to the source code.

8. A cross-platform software building apparatus, the apparatus comprising: The first determination module is configured to determine the target platform corresponding to the task to be built in response to a build request for one of a plurality of candidate platforms. The acquisition module is configured to acquire the platform configuration file corresponding to the target platform, wherein the platform configuration file includes version information of multiple candidate dependency libraries corresponding to the target platform; The second determining module is configured to determine the compatibility score between each candidate dependency library and the target platform based on a preset priority weight model, wherein the compatibility score is determined at least based on the platform compatibility index between each candidate dependency library and the target platform. The third determining module is configured to determine the target version dependency library of the target platform from the plurality of candidate dependency libraries based on the adaptation score; The build module is configured to build a build task execution graph that contains multiple candidate tasks; A pruning module is configured to identify, from the plurality of candidate tasks in the build task execution graph, tasks that are inconsistent with the target version's dependency library and require pruning, and to perform pruning processing on the build task execution graph; and The execution module is configured to perform software construction based on the pruned construction task execution graph and the source code corresponding to the task to be built.

9. An electronic device, comprising: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

11. A computer program product comprising a computer program, wherein, The computer program, when executed by a processor, implements the method of any one of claims 1-7.

Images