A cross-platform application development method, system, device, and program product

Abstract

This application proposes a cross-platform application development method, system, device, and program product. The solution involves: extracting a fingerprint from a target application project to obtain a core engine fingerprint; matching this core engine fingerprint with a pre-defined cross-platform dependency database to obtain a set of cross-platform dependency versions; performing a multi-dimensional scan and deviation determination on the target application project based on the cross-platform dependency version set to obtain a version deviation result; and performing version synchronization and development processing on the target application project based on the version deviation result to obtain the target application. This solution can improve application development efficiency and can be widely applied in fields such as home entertainment product software, digital cultural product production software, and digital cultural creative software in the digital creative industry.

Description

Technical Field

[0001] This application relates to the field of application software development technology, and in particular to a cross-platform application development method, system, device, and program product. Background Technology

[0002] In cross-platform application development, project dependencies involve not only the underlying scripting languages ​​but also deep coupling with native components. When related technologies manage project dependencies through management tools, they typically only allow downloading dependencies from a single repository, making it difficult to manage different dependency versions used by different project teams. This results in a single management dimension, impacting the development efficiency of cross-platform applications. Summary of the Invention

[0003] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a cross-platform application development method, system, device, and program product, which can improve the development efficiency of cross-platform applications.

[0004] To achieve the above objectives, one aspect of this application proposes a cross-platform application development method, comprising: The fingerprint of the core engine is obtained by performing fingerprint extraction on the target application project. Based on the core engine fingerprint, a set of cross-platform dependency versions is obtained by matching from a preset cross-platform dependency database; Based on the cross-platform dependency version set, the target application project is subjected to multi-dimensional scanning and deviation determination processing to obtain version deviation results; Based on the version deviation results, the target application project is synchronized and developed to obtain the target application.

[0005] According to some embodiments of this application, the fingerprint extraction process for the target application project to obtain the core engine fingerprint includes: The development environment of the target application project is identified to obtain the development environment version number; The target application project is subjected to runtime environment and dependency environment identification processing to obtain a heterogeneous environment version; The core engine fingerprint is obtained by associating the development environment version number and the heterogeneous environment version.

[0006] According to some embodiments of this application, before matching the cross-platform dependency version set from a preset cross-platform dependency database based on the core engine fingerprint, the method further includes pre-constructing the cross-platform dependency database, including: Retrieve historical application projects and record the development environment version number of the historical application projects; Dependency recursive analysis is performed on the project description files of the historical application projects to obtain script layer dependencies; Dependency analysis is performed on the description files of the historical application projects on different mobile devices to obtain the native layer dependencies; The cross-platform dependency database is constructed by recording the script layer dependencies and the native layer dependencies using the development environment version number as an index.

[0007] According to some embodiments of this application, the step of performing multi-dimensional scanning and deviation determination processing on the target application project based on the cross-platform dependency version set to obtain version deviation results includes: During the continuous integration phase of the target application project, an execution hook is embedded to perform project dependency scanning and obtain the project dependency tree; Based on the cross-platform dependency version set, the version deviation of the project dependency tree is calculated to obtain the version deviation. Based on the version deviation, the dependent versions of the target application project are managed, and the version deviation results are generated.

[0008] According to some embodiments of this application, the step of managing the dependency versions of the target application project based on the version deviation and generating the version deviation result includes: Based on the version deviation, the dependent versions in the target application project are matched to obtain the version format; The dependent versions are marked or upgraded based on the version deviation and the version format to obtain the version deviation result.

[0009] According to some embodiments of this application, the step of performing version synchronization and development processing on the target application project based on the version deviation result to obtain the target application includes: Based on the version deviation results, dependency image data is obtained from the cross-platform dependency database and the dependency versions of the target application project are synchronized to obtain a synchronized application project. The synchronous application project is compiled to obtain the target application.

[0010] According to some embodiments of this application, dependency image data obtained from the cross-platform dependency database based on the version deviation result is used to synchronize the dependency versions of the target application project, resulting in a synchronized application project, including: In response to the vulnerability patching request, the vulnerability patching code is obtained based on the version deviation result; Based on the vulnerability fix code, the dependencies to be fixed in the cross-platform dependency database are updated to obtain dependency image data, and a version update beacon corresponding to the dependency image data is generated. When the target application project identifies the version update beacon during the continuous integration phase, the dependency image data obtained based on the version update beacon is used to align the dependency versions of the target application project to obtain the synchronized application project.

[0011] To achieve the above objectives, another aspect of this application proposes a cross-platform application development system, applied to the cross-platform application development method described above, comprising: The fingerprint extraction module is configured to perform fingerprint extraction processing on the target application project to obtain the core engine fingerprint; The dependency matching module is configured to match a set of cross-platform dependency versions from a preset cross-platform dependency database based on the core engine fingerprint; The deviation determination module is configured to perform multi-dimensional scanning and deviation determination processing on the target application project based on the cross-platform dependency version set to obtain version deviation results. The synchronous development module is configured to perform version synchronization and development processing on the target application project based on the version deviation results, thereby obtaining the target application.

[0012] To achieve the above objectives, another aspect of this application provides an electronic device including at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, which, when executed by the at least one control processor, enables the at least one control processor to perform the cross-platform application development method described above.

[0013] To achieve the above objectives, another aspect of this application provides a computer-readable storage medium storing computer-executable instructions for performing the cross-platform application development method as described above.

[0014] To achieve the above objectives, another aspect of this application provides a computer program product storing computer-executable instructions for executing the cross-platform application development method described above.

[0015] One of the above technical solutions has the following advantages or beneficial effects: This application provides a cross-platform application development method, system, device, and program product. This solution extracts the fingerprint of the target application project to obtain the core engine fingerprint, and can retrieve the corresponding dependency version based on the core engine fingerprint, thereby improving the consistency and stability of environment construction. Furthermore, this solution matches the cross-platform dependency version set from a preset cross-platform dependency database based on the core engine fingerprint, and performs multi-dimensional scanning and deviation judgment processing on the target application project based on the cross-platform dependency version set to obtain the version deviation result. This enables dependency version management of cross-platform projects based on past development experience, improving the efficiency of dependency version management. In addition, this solution performs version synchronization and development processing on the target application project based on the version deviation result to obtain the target application. It can automatically perform version synchronization, saving time and effort and improving the development efficiency of cross-platform applications. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a cross-platform application development method according to an embodiment of this application; Figure 2 yes Figure 1 Flowchart of step S101; Figure 3 This is a flowchart illustrating the construction of a cross-platform dependent database according to one embodiment of this application; Figure 4 yes Figure 1 Flowchart of step S103; Figure 5 yes Figure 4 Flowchart of step S403; Figure 6 yes Figure 1 Flowchart of step S104; Figure 7 yes Figure 6 Flowchart of step S601; Figure 8 This is a schematic diagram of the structure of a cross-platform dependent database provided in one embodiment of this application; Figure 9 This is a schematic diagram of the structure of a cross-platform application development system provided in one embodiment of this application; Figure 10 This is a structural diagram of an electronic device provided in another embodiment of this application. Detailed Implementation

[0017] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0018] In the description of this application, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0019] In the description of this application, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0020] In the description of this application, unless otherwise expressly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0021] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0022] 1) Cross-platform application development is the ability to use a single codebase or unified architecture to simultaneously cover multiple terminals (Web, iOS, Android) while maintaining consistency in functionality, performance, user experience, and security. The value of cross-platform development lies in its ability to deliver applications quickly using a unified technology stack and workflow engine, reducing redundant development and branch drift, and enabling requirement iterations to be implemented synchronously across all platforms.

[0023] 2) Project dependencies refer to external resources, library files, or other projects required for a project to run or be built. When a project needs to call the functionality provided by another project or library, a dependency relationship is formed. This relationship can be a direct dependency (directly referencing a library) or an indirect dependency (other libraries introduced through a third-party framework).

[0024] 3) Continuous Integration (CI) refers to the process where developers frequently integrate code into a shared repository, and the system automatically performs builds and tests. Its main purpose is to identify and resolve integration problems as early as possible, avoid software quality issues, and reduce the risks associated with releasing new versions.

[0025] In the development of cross-platform applications, related technologies are primarily managed through package management tools to manage dependencies within a single project, such as downloading dependencies from a single repository. However, project dependencies involve not only the underlying scripting languages ​​but also deeply coupled native components. In large-scale cross-platform application development, different project teams often use different dependency versions. This decentralized management leads to poor environment consistency and stability risks. For example, when native layer configuration conflicts cause compilation failures, the experience of one project team using stable third-party libraries cannot be transferred to new projects, and vulnerable library versions are likely to appear in multiple projects. Furthermore, when one project fixes an underlying dependency vulnerability, other projects cannot detect and synchronize the fix, resulting in a lag in synchronization and a lack of a synchronization mechanism. In cross-platform projects, projects involve JS, native Android, and native iOS sides, but different project teams use third-party library versions without reference, often using the latest versions or relying on their own development experience, failing to document and record specific problems solved.

[0026] Therefore, this application provides a cross-platform application development method, system, device, and program product, which can be applied to the technical fields of application software development, animation and game production engine software and development systems, digital cultural product production software, and digital cultural creative software. This application uses automated scripts to detect the core engine fingerprint of a target application project. This core engine fingerprint includes the major version number of the development environment, as well as the version numbers of the corresponding runtime environment and dependent environments. By extracting the core engine fingerprint from the target application project, this application can ensure the basic consistency of the build environment based on the core engine fingerprint. Based on the core engine fingerprint, this application can match a set of cross-platform dependency versions from a preset cross-platform dependency database. This cross-platform dependency database is a dependency database obtained by recording stable dependency versions of the project based on past development experience. This set of cross-platform dependency versions can be a full-stack compatibility matrix, which can be used not only to manage dependency versions at the script layer but also to manage dependencies at the native layer. Furthermore, by using a cross-platform dependency version set as a reference standard for the development of the target application project, this application can determine the deviation between the target application project's dependency version and the reference standard, thereby enabling the replacement or upgrading of versions. This helps projects quickly build a verified and stable cross-platform third-party library version management tool, allowing the experience accumulated in previous projects to be applied to other projects, making application products more secure, stable, and reliable, and improving application development efficiency.

[0027] This application provides a cross-platform application development method, system, device, and program product, which will be described in detail in the following embodiments.

[0028] The cross-platform application development method provided in this application covers most application software or digital cultural product development scenarios, and is applicable to fields such as animation and game production engine software and development systems, and game and animation software. It enables the management of dependency versions in heterogeneous environments during cross-platform mobile development processes, improving dependency stability and reducing dependency conflicts. Simultaneously, this application automatically extracts the core engine version and distributes a standard version, reducing inefficient debugging time caused by environment drift and eliminating the need for manual reference to compatibility documentation, thus improving the user experience. Specifically, in scenarios involving the development of cross-platform applications or software, a pre-set automated script on the client side can extract the fingerprint of the current target application project. By extracting the major version number of the target application project in the development environment and using the version numbers of the corresponding runtime environment and dependent environments as auxiliary anchors, the core engine fingerprint can be extracted and transmitted to the server. Upon receiving the core engine fingerprint, the server performs dependency version matching processing on the core engine fingerprint based on a pre-built cross-platform dependency database, thereby matching a corresponding stable set of cross-platform dependency versions. It is important to note that this cross-platform dependency version set can manage not only script-level dependencies but also native-level dependencies across different application clients. It serves as a reference standard for project development, reducing the cost of manually consulting compatibility documentation. This application also analyzes the project dependencies of the target application project based on the cross-platform dependency version set, thereby generating a corresponding management scheme. Developers can use this scheme to replace or upgrade dependency versions of the target application project, and can also update the current project with patch code in response to vulnerability remediation requests, improving application development efficiency.

[0029] The cross-platform application development method provided in this application can be applied to the interaction between a client and a server, and can also be software or an application running on the server for developing a target application project. The terminal, as a client, can run the specified target application software or application, and the server performs application development, code compilation, and other processing on the target application. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the cross-platform application development method, but is not limited to the above forms.

[0030] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0031] Reference Figure 1 , Figure 1 A flowchart of a cross-platform application development method provided in this application embodiment, the cross-platform application development method including but not limited to steps S101 to S104: Step S101: Perform fingerprint extraction processing on the target application project to obtain the core engine fingerprint; Step S102: Based on the core engine fingerprint, a set of cross-platform dependency versions is obtained by matching from a preset cross-platform dependency database; Step S103: Perform multi-dimensional scanning and deviation determination processing on the target application project based on the cross-platform dependency version set to obtain version deviation results; Step S104: Based on the version deviation results, perform version synchronization and development processing on the target application project to obtain the target application.

[0032] This application embodiment can be applied to the interaction scenario between client 105 and server 106. The client can be a computer device such as a mobile terminal or personal computer. The server can develop and process the target application project to be developed in the client, obtain the target application, and return it to the client of different mobile devices for display to the target object. It can also perform vulnerability repair on the application, thereby improving the development capability of cross-platform applications.

[0033] Specifically, this application embodiment can extract or detect the core engine fingerprint of the target application project to be developed on the mobile device by deploying automated processes on the server or backend, or by pre-deploying automated scripts on the mobile device. This application embodiment obtains the core engine fingerprint by acquiring the major version number of the development environment in the target application project. Based on the core engine fingerprint, it can match a set of cross-platform dependency versions from a preset cross-platform dependency database, thereby obtaining project dependency data closely related to the development environment of the target application project. This application embodiment performs multi-dimensional scanning and deviation judgment processing on the target application project based on the cross-platform dependency version set. It can use the cross-platform dependency version set as a reference label to manage dependency versions such as dependency version replacement or upgrades for the target application project, thereby synchronizing the dependency versions of the target application project and processing application development to obtain the target application. This application embodiment can also combine a reflow mechanism, by accumulating vulnerability fixes for dependencies from other projects into the cross-platform dependency database, thereby updating the dependency versions in the current project, which can improve the efficiency of project management. This application embodiment constructs a cross-platform dependency database, which can manage dependency data on different application devices. By generating dependency reference standards under preset versions, it can manage the dependencies of application projects under development, and can consolidate the experience accumulated in other projects and apply it to other projects, thereby improving the development efficiency of cross-platform applications. It is applicable to application fields such as application development, animation and game production engine software and development systems, game and animation software, animation, and game digital content services.

[0034] Please see Figure 2 In step S101 of some embodiments, the fingerprint extraction process on the target application item to obtain the core engine fingerprint includes: Step S201: Perform development environment identification processing on the target application project to obtain the development environment version number; Step S202: Perform runtime environment and dependency environment identification processing on the target application project to obtain a heterogeneous environment version; Step S203: Based on the development environment version number and the heterogeneous environment version, the core engine fingerprint is constructed by association.

[0035] Specifically, a target application project refers to an application project that is to be developed or is under development. It can run game software or other applications on different mobile terminal devices. Terminal devices can include smartphones, laptops, desktop computers, and other devices capable of running game software. A development environment is a dedicated workspace set up by developers for writing, debugging, and running applications. It typically consists of core components such as a code editor, programming language runtime, dependency management tools, a local database, and a version control system. The development environment version number refers to the version number of the development environment or development tools. The runtime environment refers to the sum of hardware, operating system, library files, and resource management mechanisms that an application depends on during its execution phase. For example, a JavaScript runtime environment built on a development engine is used to run JavaScript code on the server side. The dependency environment refers to the collection of all libraries and tools required to ensure the normal operation of a software project. Dependency management tools can be used to associate dependency environments. Heterogeneous environments include runtime environments and dependency environments on different mobile application devices. The version number is an identifier used to identify different versions of the software or operating system. The core engine fingerprint can be constructed based on the development environment version number as the primary anchor point and the heterogeneous environment versions, namely the runtime environment and dependent environment versions, as secondary anchor points, and is used for subsequent matching of data in cross-platform dependent databases.

[0036] In practical applications, embodiments of this application can set up automated scripts on the client side. When developing or running a target application project on a terminal device, the automated scripts can obtain data such as the development environment version number and dependent environment version number corresponding to the current application project, thereby constructing a core engine fingerprint. Embodiments of this application can analyze the engine type or development tool type used by the target application to browse the installation directory of the application or development tool, locate folders and packaged files that may contain version numbers, and thus obtain the version number of the development environment or heterogeneous environment. For example, by opening the dependent project file in the project root directory, the specific version number of the development environment that the project depends on can be found. Embodiments of this application can also confirm the development environment or the development environment version number that the project depends on by performing operations in the command line, for example, by directly running commands in the terminal to view the version number of the installed command-line tools. By associating the obtained version numbers, a core engine fingerprint can be constructed, and the build environment of the target application project can be confirmed through this core engine fingerprint.

[0037] In step S201 of some embodiments, the target application project is subjected to development environment identification processing to obtain the development environment version number; The target application project is an application or software to be developed or under development, while the development environment refers to a set of software used to support the engineering development and maintenance of the software. React Native can be used as a development tool to develop the application project. For example, developers can build the application by using a cross-platform mobile application development framework, and the version number of the React Native project can be used as the development environment version number.

[0038] For example, embodiments of this application can detect the development environment version number by having developers pre-set automated scripts on the client side to identify the development environment of the target application project during development. For instance, identification instructions or custom environment identifiers can be injected into the startup command, and the development environment of the target application project can be determined by reading and judging the code; for example, identifying the current target application project as a React Native project. Embodiments of this application can also identify the specific development environment version number by recognizing environment identifiers injected into build configuration files or packaging command parameters.

[0039] In step S202 of some embodiments, the target application project is subjected to runtime environment and dependency environment identification processing to obtain a heterogeneous environment version; The runtime environment refers to the sum of hardware and software infrastructure that an application relies on to actually run, including physical servers or cloud hosts, operating systems, runtime engines, web servers, databases, caches, and network configurations. The dependency environment refers to the various external components required to support the compilation and execution of the application, including third-party libraries, frameworks, SDKs, system tools, and specific versions of the runtime. By identifying the runtime environment and dependency environment of the target application project, the version numbers of each component or dependency that builds that runtime environment and dependency environment can be obtained, thus enabling the construction of a heterogeneous environment version. In cross-platform application development, differences in development across different mobile application platforms necessitate recording the versions of various engines or dependent components to obtain a heterogeneous environment version.

[0040] For example, embodiments of this application can also use automated scripts to identify the runtime environment and dependent environments used by the target application project. For the runtime environment, the corresponding runtime environment version can be determined by identifying environment variables or framework built-in variables. For the dependent environments, package management can be used to check if dependencies are fully installed, and a version detection script can be used to confirm whether the runtime version meets the project requirements. A complete dependency tree and environment information are output using commands, thereby obtaining the heterogeneous environment version. This heterogeneous environment version includes the version numbers of the runtime environment and dependent environments under different mobile devices.

[0041] In step S203 of some embodiments, the core engine fingerprint is obtained by associating the development environment version number and the heterogeneous environment version. The core engine fingerprint refers to a set of characteristic information used to uniquely identify and recognize the core runtime engine that the application depends on. This may include engine type, precise version number, underlying dependency versions, compilation configuration parameters, and critical patch status. In this embodiment, it is specifically constructed by associating the development environment version number with the heterogeneous environment version.

[0042] For example, this embodiment of the application constructs a core engine fingerprint by associating the development environment version number and the heterogeneous environment version. This core engine fingerprint can be constructed using the development environment version number as a primary index and the heterogeneous environment version as a secondary index. This embodiment of the application can also use a hash algorithm to generate a unique fingerprint identifier from multiple key fields as the basis for aggregation and comparison. Furthermore, this embodiment of the application can decompose the version number into a semantic structure of major version, minor version, and patch version, supporting flexible range queries and compatibility checks, thus constructing a comprehensive and efficient core engine fingerprint system.

[0043] Specifically, in this embodiment, the core engine fingerprint can be obtained by viewing the official command for environment fingerprinting. Alternatively, a script can be written to automatically collect environment information during the development process and generate a unified fingerprint file. The development environment version number in the core engine fingerprint can be used to quickly locate the development environment of the application project. Furthermore, by using the runtime environment and dependent environment used by different mobile terminals in heterogeneous environment versions as auxiliary search conditions, the build environment of the target application project can be quickly identified.

[0044] One of the above technical solutions has the following advantages or beneficial effects: The embodiments of this application obtain the core engine fingerprint by structurally collecting and combining the development environment version number and heterogeneous environment version of the target application project, and constructing an index. Based on the core engine fingerprint, the specific construction environment of the target application project can be identified, which makes it easier for developers and operation and maintenance personnel to quickly locate the problems caused by "environment drift", or accurately reproduce the problem scene during fault diagnosis, or assist in decision-making for rollback or full release during version upgrade and canary release, thereby improving the efficiency of cross-platform application development.

[0045] In step S102 of some embodiments, a set of cross-platform dependency versions is obtained by matching the core engine fingerprint from a preset cross-platform dependency database; The cross-platform dependency database is used to uniformly manage and track the structured information set of third-party libraries, frameworks, SDKs, and other dependent components required by the application on different operating systems and architectures. It can include key fields such as dependency name, version number, applicable platform, source, and compatibility constraints. In this embodiment, the cross-platform dependency database uses the core engine fingerprint as an index and presets and records a set of stable dependency versions across multiple dimensions. Therefore, by extracting the core engine fingerprint from the target application project, the corresponding set of cross-platform dependency versions can be matched in the preset cross-platform dependency database. This set of cross-platform dependency versions contains a structured information set of the application's dependent components on different operating systems and architectures.

[0046] Please see Figure 3 In some embodiments, prior to step S102, the method further includes pre-building the cross-platform dependency database, including: Step S301: Obtain historical application projects and record the development environment version number of the historical application projects; Step S302: Perform dependency recursive analysis on the project description file of the historical application project to obtain script layer dependencies; Step S303: Perform dependency analysis on the description files of the historical application project on different mobile devices to obtain the native layer dependencies; Step S304: Record the script layer dependencies and the native layer dependencies using the development environment version number as an index to build the cross-platform dependency database.

[0047] Specifically, this application embodiment extracts project dependency data from historical application projects or completed applications, yielding stable dependency data. This project dependency data includes the development environment version number, script layer dependencies, and native layer dependencies. In mobile application development, the script layer and the native layer are the two core layers constituting the application. The script layer refers to the business logic and interface code written in high-level languages ​​such as JavaScript, running in the virtual machine or engine provided by the framework, responsible for handling dynamic logic such as UI rendering, state management, and business interaction. The native layer, on the other hand, refers to the code that runs directly at the operating system's underlying layer, accessing hardware devices and platform-specific functions through system APIs, responsible for providing high-performance computing, underlying system interaction, and capabilities that the script layer cannot directly accomplish. This application embodiment, by recording the development environment version number, script layer dependencies, and native layer dependencies in historical application projects, can build a comprehensive cross-platform dependency database. This cross-platform dependency database allows for centralized management of dependency version strategies, automated detection of version conflicts, and rapid tracking of the coverage of a dependency across multiple platforms, thereby improving the stability and maintenance efficiency of cross-platform project construction.

[0048] In step S301 of some embodiments, historical application projects are obtained and the development environment version number of the historical application projects is recorded; Specifically, historical application projects refer to application projects that have been validated or completed, containing detailed information about the application software development. This application embodiment uses a software engineering system that maintains predictability, reliability, and maintainability under continuous development iterations and real-world user environments as a historical application project. This historical application project possesses a clear layered architecture, unified dependency management, a robust error capture mechanism, and traceable core engine fingerprints, ensuring environmental consistency and rapid problem localization.

[0049] In this embodiment, the version number of a historical application project can be uniformly declared in the project description file in the project root directory, or it can be declared in the version field in the configuration file. Thus, by identifying the version number in the project description file or the version field, the development environment version number of the historical application project can be obtained, and the source of the running version and the build environment of the historical application project can be identified.

[0050] In step S302 of some embodiments, dependency recursive analysis is performed on the project description file of the historical application project to obtain script layer dependencies; Specifically, the project description file is the application's configuration manifest, used to centrally declare the project's metadata, dependency list, runtime scripts, and build toolchain configuration. Script layer dependencies refer to third-party libraries and toolkits written in scripting languages, declared through fields in the project description file. Script layer dependencies run in the framework's provided virtual machine or engine, responsible for handling business logic, UI components, state management, and build assistance functions. They are automatically downloaded and version-controlled through package management tools, forming the code foundation of the application's script layer.

[0051] In this embodiment, script-level dependencies are obtained by parsing the dependency declarations of each dependency package layer by layer, starting from the root dependencies in the project description files of historical application projects. This embodiment can obtain the specific versions and dependencies recorded in the lock file using package management tools, and then traverse the description files of each dependency package using tools or scripts to collect the names and version constraints of its sub-dependencies. Combined with the parsed dependency tree, version deduplication, conflict detection, and circular dependency judgment are performed to obtain the script-level dependencies. This embodiment also pays attention to distinguishing between direct and indirect dependencies during the analysis process, identifying the coexistence of multiple versions of the same dependency, and determining the final installed dependency version through semantic versioning rules.

[0052] In step S303 of some embodiments, dependency analysis is performed on the description files of the historical application project on different mobile terminals to obtain the native layer dependency. Specifically, native layer dependencies refer to third-party libraries or software development kits that need to directly interact with the underlying operating system and can only be integrated into the application through compilation and linking. Native layer dependencies include iOS native layer dependencies and Android native layer dependencies, which can be declared and imported using specific dependency management tools.

[0053] In this embodiment, the native dependency management tools for each platform can be used to parse their declaration files to obtain the native layer dependencies. For example, for the iOS native layer, the definitions in the documentation files, such as the Podfile, which describes the dependencies of one or more project targets, can be analyzed. The specific fingerprints in the Podfile.lock file, which records the precise version number of each dependent library in the current project, including direct and indirect dependencies, can also be analyzed. This embodiment can obtain all native libraries and their versions, sub-specifications, and dependency trees through commands or parsing the lock file, thus obtaining the native layer dependencies for the iOS side. For the Android side, the native layer dependencies for the Android side can be obtained by parsing the project's core configuration file, such as the build.gradle file, which defines the project's dependencies, plugins, and build rules, combined with the dependency tree output by commands, and by checking the library versions and global variables declared in the configuration.

[0054] In step S304 of some embodiments, the script layer dependencies and the native layer dependencies are recorded using the development environment version number as an index to construct the cross-platform dependency database; Specifically, an index is an optimization technique in database management systems designed to improve the speed of data retrieval. An index functions similarly to a table of contents in a book, allowing the system to quickly locate the storage location of data without traversing the entire database.

[0055] In this embodiment, the development environment version number of historical application projects is used as an index to record the corresponding script layer dependencies and native layer dependencies, thereby integrating them into a data set and storing it in a cross-platform dependency database. This embodiment unifies script layer dependencies and native layer dependencies to the same traceable development environment version number. This version number can be used as the primary key, and detailed information for both types of dependencies can be stored in a relational table in the database, linked to the same version record via foreign keys. This ensures that a complete snapshot of script layer and native layer dependencies can be queried under a single version number.

[0056] One of the above technical solutions has the following advantages or beneficial effects: By constructing a cross-platform dependency database, this application embodiment can compare the dependency differences between different versions and quickly locate the native dependency version corresponding to a certain script library under a specific version, thereby constructing a traceable, comparable, and cross-platform unified dependency database, providing a reliable data foundation for dependency upgrades, environment reproduction, and security auditing.

[0057] Please see Figure 4 In step S103 of some embodiments, the multi-dimensional scanning and deviation determination processing of the target application project based on the cross-platform dependency version set to obtain the version deviation result includes: Step S401: During the continuous integration phase of the target application project, an execution hook is embedded to perform project dependency scanning to obtain the project dependency tree; Step S402: Based on the cross-platform dependency version set, perform version deviation calculation on the project dependency tree to obtain the version deviation. Step S403: Manage the dependent versions of the target application project based on the version deviation and generate the version deviation result.

[0058] In this embodiment, the cross-platform dependency version set refers to the set of related dependency versions retrieved through a cross-platform dependency database, which may include structured information about the application's dependency components on different operating systems and architectures. The target application project is the currently developing application project, which can be an application project with a pre-built environment or one without. Multi-dimensional scanning refers to performing multi-level scanning analysis on the application project to confirm its build environment, dependencies, etc. Deviation determination refers to comparing the differences between the cross-platform dependency version set and the dependency versions in the target application project. The version deviation result is used to represent the management strategy for dependency versions in the target application project based on the version deviation, such as upgrading or recommending a version of a dependency component.

[0059] In step S401 of some embodiments, an execution hook is embedded in the continuous integration phase of the target application project to perform project dependency scanning processing and obtain a project dependency tree; Specifically, continuous integration (CI) is a core development practice in software engineering, a streamlined process where developers frequently merge code changes into a shared main branch, automatically executing builds, tests, and verifications before and after each merge. In mobile cross-platform projects, CI requires special handling of dual builds at the script and native levels: first, script layer dependencies are installed using package management tools, then the native layer code is compiled by calling the build commands for each platform, and automated tests for different platforms are run. Execution hooks are mechanisms in software engineering that automatically trigger predefined logic at specific lifecycle nodes, allowing developers to insert custom operations before or after critical processes, thereby enabling process expansion, verification, and automation. A project dependency tree is a tree-like structure diagram formed by recursively parsing the dependency declarations of each dependency package, starting from the application's root dependencies, and showing the hierarchical relationships between all direct and indirect dependencies in the project.

[0060] In some feasible embodiments, this application embeds execution hooks during the continuous integration phase of the target application project to perform project dependency scanning. By configuring scripts or callback functions as execution hooks, the dependency declarations of each dependency package in the target application project are recursively parsed to obtain the project dependency tree. This application can generate a tree structure containing package name, version number, dependency path, and whether it is a duplicate installation, using package management tools. Each root node in this tree structure represents the top-level dependency declared by the project, and child nodes represent the child dependencies introduced by that dependency. In the cross-platform project of this application, the project dependency tree also distinguishes between the script layer and the native layer, analyzing the dependencies of the script layer and the native layer separately, and comparing them using version number indexes.

[0061] In step S402 of some embodiments, the version deviation is calculated on the project dependency tree based on the cross-platform dependency version set to obtain the version deviation. Specifically, version deviation refers to a quantitative indicator that measures the degree of difference between the dependency version actually used in the target application project and the unified specification version or the latest stable version provided by the cross-platform dependency database.

[0062] In some feasible embodiments, the deviation is calculated by comparing the actual installed version of each package in the dependency tree with the cross-platform dependency version set; the larger the difference, the higher the deviation. This application embodiment can calculate the deviation from multiple dimensions. For example, the version deviation can be calculated using the time dimension, where the time dimension refers to the interval between the dependency version release time and the current date, used to measure the obsolescence of technical debt. This application embodiment can also calculate the version deviation using the version span dimension, where the version span dimension refers to comparing the differences between major versions, minor versions, and patch versions. In the cross-platform project of this application embodiment, the version deviation can also be calculated separately for the script layer and the native layer, and the collaborative deviation between the two can be comprehensively evaluated.

[0063] In step S403 of some embodiments, the dependent versions of the target application project are managed based on the version deviation, and the version deviation result is generated; In this embodiment, management can be implemented based on version deviation to upgrade or provide suggestions for dependent versions of the target application project, thereby generating corresponding version deviation results. This embodiment can also detect whether dependent versions in the target application project contain high-risk vulnerabilities based on version deviation, thereby generating corresponding management methods, such as performing hard blocking or forcibly upgrading the dependent version.

[0064] One of the above technical solutions has the following advantages or beneficial effects: The embodiments of this application perform multi-dimensional scanning and deviation judgment processing on the target application project based on the cross-platform dependent version set to obtain the version deviation result, which can monitor the version deviation degree of the current application project, quantify technical debt, prioritize upgrade plans, avoid security risks caused by version lag, and provide data support in version upgrade decisions.

[0065] Please see Figure 5 In step S403 of some embodiments, the dependent versions of the target application project are managed based on the version deviation, and the version deviation result is generated, including: Step S501: Based on the version deviation, perform format matching on the dependent versions in the target application project to obtain the version format; Step S502: Based on the version deviation and the version format, mark or upgrade the dependent version to obtain the version deviation result.

[0066] In this embodiment, dependency version management for the target application project is performed based on version deviation. The allowed version range can be defined using the version declaration syntax in the project description file based on the version deviation results, and the exact version actually installed is recorded using a lock file, ensuring consistency across environments. This embodiment can also periodically run version checking tools based on the version deviation results to identify upgradable dependencies, assess upgrade risks, and gradually advance version updates by combining automated testing and canary release strategies.

[0067] In step S501 of some embodiments, the dependent versions in the target application project are format matched based on the version deviation to obtain the version format; Specifically, dependency version format refers to the standardized syntax used in project description files to declare versions of third-party libraries. This application embodiment manages dependency versions for different projects by defining a version format, thereby enabling dependency management, version upgrades, and conflict resolution.

[0068] In some feasible embodiments, the dependency versions in the target application project typically use a semantic versioning format, which includes a major version, a minor version, and a patch version. A change in the major version number indicates a modification to an incompatible application programming interface, a change in the minor version number indicates the addition of backward-compatible features, and a change in the patch version number indicates the fixing of backward-compatible issues. In this embodiment, all dependency versions in the cross-platform dependency database adopt this semantic versioning format. When a large version deviation is detected, the dependency version format of the current target application project can be analyzed to determine if the format matches. If the dependency version format of the current target application project only includes the major version, it indicates that the dependency version may not be a stable dependency version, and there may be issues with maintainability and risk management. For example, the lack of fine-grained version control may lead to an inability to distinguish between new features and bug fixes. When dependencies are released and updated, it may be forced to accept minor version or patch changes that have not been adequately tested, or conversely, miss critical security fixes. Furthermore, when a security bulletin indicates a vulnerability in a certain minor version number range, the major version number alone cannot determine whether the currently used version is affected, nor can it accurately pinpoint which patch version needs to be upgraded to. Therefore, by matching the format of the dependency versions in the target application project, it is possible to determine whether the dependency contains the complete format, or to detect the minor version and patch version based on the matched major version number.

[0069] In step S502 of some embodiments, the dependent version is marked or upgraded based on the version deviation and the version format to obtain the version deviation result; Specifically, embodiments of this application can match dependent versions under the corresponding major version number based on the version format, and can also identify whether a dependent version exists in the dependency database based on the version format. Embodiments of this application can also compare version numbers based on version deviation, thereby marking or upgrading dependent versions.

[0070] In some feasible embodiments, this application manages dependencies in a target application project based on version deviation and version format. Specifically, when a large version deviation is identified, the version format of the dependency version in the reference standard is compared with that of the dependency version in the target application project. If they are inconsistent, the dependency version in the target application project can be replaced with the dependency version in the reference standard, which is the retrieved cross-platform dependency version set. When a small version deviation is identified, the version numbers of the dependency versions in the target application project can be compared. If the version number is higher than the dependency version number corresponding to the cross-platform dependency version set, the dependency version in the target application project can be marked. This application can determine whether a dependency version has been approved by comparing the dependency version numbers in the target application project. If it has not been approved, it can be marked as an "uncontrolled version". If this application determines that the version number of a dependency version in the target application project is lower than the dependency version number corresponding to the cross-platform dependency version set, a warning can be sent to the developers to inform them of the risk and provide upgrade suggestions. Furthermore, this application embodiment can also store dependency versions containing high-risk vulnerabilities in the cross-platform dependency database. By comparing these versions with the dependency versions of the target application project, if a high-risk vulnerability is found in the current dependency version of the target application project, a hard interception is immediately executed to force an upgrade of the dependency version. Hard interception refers to the hardware device sending an interrupt request to the central processing unit when encountering a specific event, requesting to pause the currently executing program and handle the interrupt event. When it is detected that the third-party library of the target application project is not stored in the cross-platform dependency database, a mark is added to that third-party library, and the reviewers are notified to add a version.

[0071] One of the above technical solutions has the following advantages or beneficial effects: The embodiments of this application manage the dependency version of the target application project based on the version deviation, and obtain the version deviation result, which can provide a dependency version management solution for the dependency difference between the target application project and the reference standard.

[0072] Please see Figure 6 In step S104 of some embodiments, the process of performing version synchronization and development processing on the target application project based on the version deviation result to obtain the target application includes: Step S601: Based on the version deviation result, obtain the dependency image data from the cross-platform dependency database and perform synchronization processing on the dependency version of the target application project to obtain the synchronized application project; Step S602: Compile the code of the synchronous application project to obtain the target application.

[0073] In this embodiment, the version deviation result is a scheme for managing dependent versions based on the version deviation degree. Through a specific dependency version management scheme, the target application project can be managed for its dependencies, leading to the development of the target application. Based on the version deviation result, this embodiment prioritizes dependencies with known security vulnerabilities for immediate upgrades. Dependencies with lagging major versions and involving destructive changes require separate upgrade windows. By analyzing change logs and conducting compatibility tests to assess the impact, lag in minor versions or patch versions can be handled in batches during regular iterations. Automated testing ensures backward compatibility. By managing and developing the dependency versions of the target application project, the final target application is obtained.

[0074] In step S601 of some embodiments, dependency image data is obtained from the cross-platform dependency database based on the version deviation result, and the dependency version of the target application project is synchronized to obtain a synchronized application project. Specifically, a cross-platform dependency database refers to a structured database that centrally stores and manages all dependency information of an application across different platforms. This application embodiment associates script-level dependencies and native-level dependencies within the development environment version, enabling the association of cross-platform dependency snapshots under the same build using version number indexes. Developers can quickly query which native libraries a specific application version uses on iOS and which script libraries are introduced on Android, compare whether the two versions are consistent or compatible, and assess the impact on the entire platform when upgrading dependencies. Simultaneously, the cross-platform dependency database also serves as the infrastructure for automated dependency auditing, security vulnerability scanning, license compliance checks, and environmental consistency assurance, supporting continuous integration pipelines to automatically synchronize dependency status with each build, ensuring that project dependencies are always in a healthy and controllable state. Dependency image data refers to a set of independently accessible, version-fixed dependency copies formed by synchronizing or caching the third-party dependency packages required by the application from public sources to the cross-platform dependency database.

[0075] In some feasible embodiments, this application embodiment can determine which dependencies in the current target application project need to be upgraded or replaced based on version deviation results. Then, based on the version deviation results, it retrieves the corresponding dependency image data from the cross-platform dependency database and synchronizes the dependency versions of the target application project to obtain a synchronized application project. This application embodiment configures the project's package management tool to point to the cross-platform dependency database, and then executes a dependency synchronization command before each build during the continuous integration phase, forcibly pulling dependencies from the image and based on the lock file. In cross-platform projects, version alignment also needs to be established. When script-level dependencies are updated, it synchronously checks whether the corresponding bridging library versions in the iOS and Android native layer images already exist, and ensures that the dependency versions on both ends match through the build script.

[0076] Step S602: Compile the code of the synchronous application project to obtain the target application.

[0077] In some feasible embodiments, after the dependency image data synchronization is completed, the build system needs to call the corresponding compilation toolchain according to the project type. For cross-platform application development projects, the script layer code and resource files need to be compiled into an executable file by the packager first, and then the build commands of each native platform are called respectively. During the compilation process, the build pipeline injects environment variables to trigger the optimization strategy of the script layer and ensures that the native layer dependencies are correctly linked, thereby building the target application.

[0078] One of the above technical solutions has the following advantages or beneficial effects: This application embodiment can effectively manage runtime crashes caused by version inconsistencies between the script layer and the native layer through a cross-platform dependency database. Furthermore, by synchronizing and processing the target application project based on version deviation results, it can promptly block potential attack entry points by prioritizing the synchronization of dependency versions that fix known security vulnerabilities, thus enhancing the security of application development. Moreover, this application embodiment addresses environment drift issues by synchronizing dependency versions in development, testing, and production environments to the same baseline, reducing the difficulty in reproducing vulnerabilities caused by version differences and improving environment consistency.

[0079] Please see Figure 7 In step S601 of some embodiments, dependency image data is obtained from the cross-platform dependency database based on the version deviation result, and the dependency versions of the target application project are synchronized to obtain a synchronized application project, including: Step S701: In response to the vulnerability patching request, obtain the vulnerability patching code based on the version deviation result; Step S702: Based on the vulnerability repair code, perform dependency update processing on the dependencies to be repaired in the cross-platform dependency database to obtain dependency image data, and generate a version update beacon corresponding to the dependency image data; Step S703: When the target application project identifies the version update beacon during the continuous integration phase, the dependency image data obtained based on the version update beacon is used to align the dependency versions of the target application project to obtain the synchronized application project.

[0080] In this embodiment, the dependency image data can be directly obtained from the cross-platform dependency database based on the version deviation result to synchronize the dependency version of the target application project. Alternatively, if the version deviation result indicates that a vulnerability has been detected in the current application project and a vulnerability repair request has been received, the version that has been repaired by the vulnerability obtained from the cross-platform dependency database can be synchronized.

[0081] In step S701 of some embodiments, in response to the vulnerability repair request, vulnerability repair code is obtained based on the version deviation result; Specifically, a vulnerability remediation request (VRP) refers to a remediation instruction issued by a security team, automated scanning tool, or external reporting party during software development when a security vulnerability is discovered in a third-party library, framework, system component, or the application's own code. In application project development, VRP requests are automatically generated by a security monitoring platform and linked to the project repository, or pushed to the development team as a work order, requiring completion of the remediation and verification of the closed loop within a specified time. At this point, the development team needs to perform dependency upgrades, patch applications, or code refactoring according to the remediation guidelines in the request, and conduct regression testing to ensure that the remediation does not introduce functional regressions. Finally, the remediated version is redeployed, completing the closed-loop management of the vulnerability. Vulnerability remediation code refers to the specific code written to eliminate security vulnerabilities in an application, which may include remediation methods such as dependency version upgrades, code logic modifications, configuration adjustments, or patch integration. In cross-platform projects, vulnerability remediation code may be distributed across multiple layers: the script layer needs to modify the dependency versions in the project description file and update the lock file; the native layer needs to adjust the dependency declarations; and the business code layer needs to rewrite the function logic containing the vulnerability.

[0082] In some feasible embodiments, when any application project discovers a vulnerability in its dependencies and fixes it, the developer can submit a vulnerability fix request containing the fix code to the cross-platform dependency database. Upon receiving the vulnerability fix request, this embodiment can analyze vulnerability information based on version deviation results, such as the affected dependency name, affected version range, and fixed version number. This information is then matched with the dependency versions of the current target application project to confirm whether the currently used dependency version is indeed within the affected range and to determine the version span required to upgrade to the fixed version, thereby extracting the corresponding vulnerability fix code.

[0083] In step S702 of some embodiments, the dependencies to be fixed in the cross-platform dependency database are updated based on the vulnerability repair code to obtain dependency image data, and a version update beacon corresponding to the dependency image data is generated. Specifically, dependency image data refers to a collection of independently accessible, version-fixed, and auditable dependency copies formed by synchronizing or caching third-party dependency packages required by an application from public sources to a cross-platform dependency database. Version update beacons are structured metadata identifiers used to mark the version status, update availability, and operation priority of a dependency package within the dependency image data. These beacons are typically generated by dependency image management tools or independent version monitoring services and can include dependency identifiers, current image versions, target updatable versions, update types, and priorities. In cross-platform projects, version update beacons also establish dependency associations. When a new version of a core dependency at the script layer is available, an associated beacon is automatically generated to remind the corresponding dependencies on both iOS and Android platforms to be updated synchronously. In continuous integration, pipelines, dependency upgrade tools, or developer notification systems consume these beacons to trigger automated dependency synchronization, version deviation fixing, or vulnerability patching, ensuring that project dependencies are always in a healthy and controllable update rhythm.

[0084] In this embodiment, key information, such as the name of the dependency to be fixed, the precise version number after fixing, and the affected platforms, is first extracted from the vulnerability patching code. Then, the record entry for the dependency is located in the cross-platform dependency database to confirm the difference between its current version and the patched version. This embodiment updates the dependency version declaration and, based on the version change in the patching code, synchronously modifies the project description file to ensure that version constraints point to the patched version. Simultaneously, this embodiment pulls the patched version from the cross-platform dependency database using a package management tool. If the version is not yet cached in the cross-platform dependency database, a mirror synchronization process is triggered to pull it from a public source proxy or manually push it, ensuring that subsequent builds all obtain the patched version from the cross-platform dependency database. This embodiment updates the dependency entry in the cross-platform dependency database to the patched version number and adds fields to record the update reason, update time, and operator. Simultaneously, the affected script layer and native layer dependency records are re-associated using version number indexes to ensure consistency of dependency snapshots under the same application version. Finally, a complete build and security scan are performed through the continuous integration pipeline to verify that vulnerabilities have been removed and no functional regressions have occurred. The updated dependency snapshot is then stored in the database as the new baseline for this application version, forming a traceable closed loop from vulnerability remediation requests to dependency database synchronization. This embodiment also defines a beacon structure for each dependency version in the dependency image management tool, which may include dependency representation, image version number, update status, etc.

[0085] In step S703 of some embodiments, when the target application project identifies the version update beacon during the continuous integration phase, the target application project is aligned with the dependency image data obtained based on the version update beacon to obtain the synchronized application project. In this embodiment, after a beacon is identified during the continuous integration phase of the target application project, version alignment is automatically performed, enabling one-click synchronization of vulnerability remediation solutions. Specifically, the beacon is identified by the continuous integration pipeline or dependency management service, and the dependency name, current version, target version, and update type are parsed. Then, the target version's dependency package is pulled from the dependency image data, and the verification hash of the pulled dependency package is verified to match the image record using the package management tool's configuration. Next, version constraints are updated in the project description file, and the dependency tree is re-parsed. A lock file is used to lock the exact version, ensuring that all environments obtain a completely consistent dependency set when pulling from the image. After confirming that the vulnerability has been cleared and there is no functional regression, a new dependency version snapshot is finally updated to the cross-platform dependency database, and the version beacon is marked as processed, thus forming a complete closed loop from beacon triggering to version alignment.

[0086] One of the above technical solutions has the following advantages or beneficial effects: This application embodiment uses beacons as standardized metadata signals, which can be automatically consumed by continuous integration pipelines and dependency management tools, triggering the entire process from image pulling and version declaration updates to dependency locking. No manual intervention is required to identify update opportunities. Simultaneously, each alignment operation is associated with a specific beacon and vulnerability number, forming a complete change traceability chain. Furthermore, it can prioritize marking versions containing security fixes, enabling teams to align to secure versions immediately, reducing the long-term exposure of vulnerabilities due to dependency delays, and improving the security of application development.

[0087] This application's embodiments can be applied to animation and game production engine software and development systems, digital cultural product production software, and digital cultural and creative software technology fields within the digital creative industry. It is applicable to debugging and development environments for applications on different mobile terminal devices and is widely used in mobile application development and other scenarios. In one feasible embodiment, this application pre-constructs a cross-platform dependency database. Unlike traditional tools that only manage script-level dependencies, this cross-platform dependency database maintains a full-stack compatibility matrix. The matrix uses the core engine version as an index and presets and records a stable version set across multiple dimensions, including script-level dependencies, native-level dependencies, and environment constraints. In the React Native development environment, this application's embodiments use the React Native major version number as the primary anchor point, marking it as the RN version, and using the corresponding Node.js runtime environment, Ruby version, and Android Gradle version as secondary anchor points to ensure basic consistency of the build environment. Please refer to [link to relevant documentation]. Figure 8 In this implementation, Node.js is the engine-based JavaScript runtime environment, tagged as the Node version; package.json is the project configuration file; build.gradle is the core configuration file of the Gradle build tool, used to define the project's build scripts; and Podfile is a file describing the project's dependencies, used to manage CocoaPods. This embodiment uses automated scripts to detect the core engine fingerprint of the target application project, and then retrieves a set of matching stable versions from a cross-platform dependency database based on the core engine fingerprint. This embodiment embeds execution hooks during the continuous integration phase of the project, automatically scanning not only the package.json file at the script layer, but also recursively parsing the lock file (Lock-file) and native layer configuration files, such as Podfile.lock and build.gradle, scanning various third-party libraries to obtain the target application project's dependency data. Finally, the dependency data is compared based on the stable version set to perform dependency management on the target application project, such as replacing or upgrading dependency versions.

[0088] Corresponding to the above method embodiments, this application also provides embodiments of a cross-platform application development system. Figure 9 A schematic diagram of the structure of a cross-platform application development system according to an embodiment of this application is shown. Figure 9 As shown, the cross-platform application development system includes: The fingerprint extraction module 901 is configured to perform fingerprint extraction processing on the target application item to obtain the core engine fingerprint; The dependency matching module 902 is configured to match a set of cross-platform dependency versions from a preset cross-platform dependency database based on the core engine fingerprint; The deviation determination module 903 is configured to perform multi-dimensional scanning and deviation determination processing on the target application project based on the cross-platform dependency version set to obtain the version deviation result. The synchronous development module 904 is configured to perform version synchronization and development processing on the target application project based on the version deviation results, so as to obtain the target application.

[0089] The above is an illustrative scheme of a cross-platform application development system according to this embodiment. It should be noted that the technical solution of this cross-platform application development system and the technical solution of the cross-platform application development method applied to the cross-platform application development system described above belong to the same concept. For details not described in detail in the technical solution of the cross-platform application development system, please refer to the description of the technical solution of the cross-platform application development method described above.

[0090] like Figure 10 As shown, Figure 10 A structural block diagram of an electronic device 1000 according to an embodiment of this application is shown. The components of the electronic device 1000 include, but are not limited to, a memory 1010 and a processor 1020. The processor 1020 is connected to the memory 1010 via a bus 1030, and a database 1050 is used to store data.

[0091] Electronic device 1000 also includes access device 1040, which enables electronic device 1000 to communicate via one or more networks 1060. Examples of such networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. Access device 1040 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 1002.11 Wireless Local Area Network (WLAN) wireless interface, a Global System for Microwave Access (GSM) interface, or a Wi-Fi interface. MAX interface, Ethernet interface, Universal Serial Bus (USB) interface, Cellular network interface, Bluetooth interface, Near Field Communication (NFC) interface, etc.

[0092] In one embodiment of this application, the above-mentioned components of the electronic device 1000 and Figure 10 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 10 The illustrated electronic device block diagram is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0093] Electronic device 1000 can be any type of stationary or mobile electronic device, including mobile computers or mobile electronic devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable electronic devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary electronic devices such as desktop computers or PCs. Electronic device 1000 can also be a mobile or stationary server.

[0094] The processor 1020 is used to execute computer-executable instructions of the cross-platform application development method.

[0095] The above is an illustrative embodiment of an electronic device according to this invention. It should be noted that the technical solution of this electronic device and the technical solution of the aforementioned cross-platform application development method belong to the same concept. Details not described in detail in the technical solution of the electronic device can be found in the description of the technical solution of the aforementioned cross-platform application development method.

[0096] This application also provides a storage medium, which is a computer-readable storage medium, storing a computer program that, when executed by a processor, implements the above-described cross-platform application development method.

[0097] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate, and may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0098] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0099] The above is a detailed description of the preferred embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for developing cross-platform applications, characterized in that, include: The fingerprint of the core engine is obtained by performing fingerprint extraction on the target application project. Based on the core engine fingerprint, a set of cross-platform dependency versions is obtained by matching from a preset cross-platform dependency database; Based on the cross-platform dependency version set, the target application project is subjected to multi-dimensional scanning and deviation determination processing to obtain version deviation results; Based on the version deviation results, the target application project is synchronized and developed to obtain the target application.

2. The method according to claim 1, characterized in that, The fingerprint extraction process for the target application project, resulting in the core engine fingerprint, includes: The development environment of the target application project is identified to obtain the development environment version number; The target application project is subjected to runtime environment and dependency environment identification processing to obtain a heterogeneous environment version; The core engine fingerprint is obtained by associating the development environment version number and the heterogeneous environment version.

3. The method according to claim 1, characterized in that, Before matching the cross-platform dependency version set from the preset cross-platform dependency database based on the core engine fingerprint, the method further includes pre-building the cross-platform dependency database, including: Retrieve historical application projects and record the development environment version number of the historical application projects; Dependency recursive analysis is performed on the project description files of the historical application projects to obtain script layer dependencies; Dependency analysis is performed on the description files of the historical application projects on different mobile devices to obtain the native layer dependencies; The cross-platform dependency database is constructed by recording the script layer dependencies and the native layer dependencies using the development environment version number as an index.

4. The method according to claim 1, characterized in that, The multi-dimensional scanning and deviation determination process performed on the target application project based on the cross-platform dependency version set yields version deviation results, including: During the continuous integration phase of the target application project, an execution hook is embedded to perform project dependency scanning and obtain the project dependency tree; Based on the cross-platform dependency version set, the version deviation of the project dependency tree is calculated to obtain the version deviation. Based on the version deviation, the dependent versions of the target application project are managed, and the version deviation results are generated.

5. The method according to claim 4, characterized in that, The process of managing the dependency versions of the target application project based on the version deviation, and generating the version deviation result, includes: Based on the version deviation, the dependent versions in the target application project are matched to obtain the version format; The dependent versions are marked or upgraded based on the version deviation and the version format to obtain the version deviation result.

6. The method according to claim 1, characterized in that, The process of performing version synchronization and development processing on the target application project based on the version deviation results to obtain the target application includes: Based on the version deviation results, dependency image data is obtained from the cross-platform dependency database and the dependency versions of the target application project are synchronized to obtain a synchronized application project. The synchronous application project is compiled to obtain the target application.

7. The method according to claim 6, characterized in that, The dependency image data obtained from the cross-platform dependency database based on the version deviation result is used to synchronize the dependency versions of the target application project, resulting in a synchronized application project, including: In response to the vulnerability patching request, the vulnerability patching code is obtained based on the version deviation result; Based on the vulnerability fix code, the dependencies to be fixed in the cross-platform dependency database are updated to obtain dependency image data, and a version update beacon corresponding to the dependency image data is generated. When the target application project identifies the version update beacon during the continuous integration phase, the dependency image data obtained based on the version update beacon is used to align the dependency versions of the target application project to obtain the synchronized application project.

8. A cross-platform application development system, characterized in that, include: The fingerprint extraction module is configured to perform fingerprint extraction processing on the target application project to obtain the core engine fingerprint; The dependency matching module is configured to match a set of cross-platform dependency versions from a preset cross-platform dependency database based on the core engine fingerprint; The deviation determination module is configured to perform multi-dimensional scanning and deviation determination processing on the target application project based on the cross-platform dependency version set to obtain version deviation results. The synchronous development module is configured to perform version synchronization and development processing on the target application project based on the version deviation results, thereby obtaining the target application.

9. An electronic device, characterized in that, It includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor to enable the at least one control processor to perform the cross-platform application development method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product stores computer-executable instructions for causing a computer to perform the cross-platform application development method as described in any one of claims 1 to 7.

Images