Software application generation method and apparatus, electronic device, and storage medium

Abstract

The application provides a software application generation method and device, electronic equipment and storage medium. The method comprises the following steps: in response to a construction request for a target version, determining a set of differentiated elements associated with the target version; in a software construction stage, performing compile-time differentiated processing on a common code library based on the set of differentiated elements to generate an application package carrying static features of the target version; in a running stage of the application package, performing runtime differentiated processing on the application package based on the set of differentiated elements to provide dynamic functions of the target version; wherein, through the combination of the compile-time differentiated processing and the runtime differentiated processing, a software application with complete functions of the target version is generated from the common code library. Through the present scheme, all customized versions can generate complete function applications based on the same set of common code libraries, eliminating synchronization and merging conflicts in multi-branch development.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a software application generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the development of smart terminal software, especially in the fields of in-vehicle infotainment systems and enterprise-level customized applications, it is often necessary to launch multiple software versions with different functions and interfaces for different customers, vehicle models, or markets, based on the same core business logic. While this "multi-project co-development" model improves code reuse and unifies the technical architecture, it also brings the technical challenge of how to efficiently and clearly isolate the differences between versions.

[0003] In current software product development, especially when launching customized versions for different customers or different hardware platforms, a branch management strategy is typically adopted. The development team creates an independent code branch for each customized version, implementing differentiated features on each branch.

[0004] However, as the number of projects increases, the above method will lead to multiple independent branches, which will require repeated synchronization and merging of core function improvements and defect fixes between branches, causing a large number of conflicts, resulting in a sharp increase in codebase maintenance costs and chaotic version management. Summary of the Invention

[0005] This application provides a software application generation method, apparatus, electronic device, and storage medium to solve the problem in the prior art that as the number of projects increases, multiple independent branches lead to the need for repeated synchronization and merging of core function improvements and defect fixes between branches, causing a large number of conflicts, resulting in a sharp increase in code library maintenance costs and chaotic version management.

[0006] Firstly, this application provides a method for generating a software application, including: In response to a build request for a target version, determine a set of differentiated elements associated with the target version; During the software construction phase, based on the set of differentiated elements, the public code library is subjected to compile-time differentiation processing to generate an application package that carries the static characteristics of the target version; During the runtime phase of the application package, based on the set of differentiated elements, runtime differentiation processing is performed on the application package to provide the dynamic functions of the target version; Specifically, by combining compile-time differentiation processing with runtime differentiation processing, a software application with the full functionality of the target version is generated from the public code repository.

[0007] In one possible implementation, determining the set of differential elements associated with the target version includes: Extract the version identifier of the target version from the build request; Based on the version identifier, determine the corresponding exclusive source code directory; The resource files and code files in the dedicated source code directory are identified as the set of differentiated elements.

[0008] In one possible implementation, the static features include static interface features and static functional features of the target version. The process of performing compile-time differentiation processing on the public codebase based on the differentiated element set includes: The resource files in the differentiated element set are used to overwrite the resource files with the same name in the public code library, so as to integrate the resource files in the differentiated element set into the application package and form the static interface features of the target version; The code files in the differentiated element set are used to replace the original class files with the same class paths in the public code library, so that the code files in the differentiated element set are compiled into the application package to form the static functional features of the target version.

[0009] In one possible implementation, the runtime differentiation processing of the application package based on the differentiated element set includes: During the runtime phase, the service declaration file pre-installed in the application package is parsed to obtain description information, wherein the description information is obtained from the set of differentiated elements and registered to the service declaration file during the software construction phase; Based on the description information, the service implementation class corresponding to the target version is dynamically loaded and instantiated to provide the dynamic functionality.

[0010] In one possible implementation, the method further includes: During the software construction phase, the fully qualified name of the service implementation class to be registered is obtained from the set of differentiated elements as the description information; Create a service declaration file named with the fully qualified name of the unified interface, and write the description information into the service declaration file; The service declaration file containing the description information is placed in the metadata directory of the application package.

[0011] In one possible implementation, dynamically loading and instantiating the service implementation class corresponding to the target version based on the description information includes: Based on the description information, load and instantiate all service implementation classes declared and registered by the set of differentiated elements to obtain the corresponding instance set; Obtain the version identifier of the target version and the hardware configuration information of the current operating environment; Based on the version identifier and the hardware configuration information, target service instances that match the target version are selected from the instance set.

[0012] In one possible implementation, the method further includes: In the public code library, functional interfaces containing default methods and abstract methods are declared, wherein the default methods are used to implement general business logic, and the abstract methods are used to declare differentiated business logic; Within the set of differentiated elements, a concrete class is provided to implement the functional interface, and the differentiated business logic defined by the abstract method is implemented in the concrete class.

[0013] Secondly, this application provides a software application generation apparatus, comprising: A determination module is configured to, in response to a build request for a target version, determine a set of differential elements associated with the target version; The first processing module is used to perform compile-time differentiation processing on the public code library based on the set of differentiated elements during the software construction phase, so as to generate an application package that carries the static characteristics of the target version. The second processing module is used to perform runtime differentiation processing on the application package based on the set of differentiation elements during the runtime phase of the application package, so as to provide the dynamic functions of the target version. Specifically, by combining compile-time differentiation processing with runtime differentiation processing, a software application with the full functionality of the target version is generated from the public code repository.

[0014] In one possible implementation, the determining module is specifically used for: Extract the version identifier of the target version from the build request; Based on the version identifier, determine the corresponding exclusive source code directory; The resource files and code files in the dedicated source code directory are identified as the set of differentiated elements.

[0015] In one possible implementation, the static features include static interface features and static functional features of the target version. The first processing module is specifically used for: The resource files in the differentiated element set are used to overwrite the resource files with the same name in the public code library, so as to integrate the resource files in the differentiated element set into the application package and form the static interface features of the target version; The code files in the differentiated element set are used to replace the original class files with the same class paths in the public code library, so that the code files in the differentiated element set are compiled into the application package to form the static functional features of the target version.

[0016] In one possible implementation, the second processing module is specifically used for: During the runtime phase, the service declaration file pre-installed in the application package is parsed to obtain description information, wherein the description information is obtained from the set of differentiated elements and registered to the service declaration file during the software construction phase; Based on the description information, the service implementation class corresponding to the target version is dynamically loaded and instantiated to provide the dynamic functionality.

[0017] In one possible implementation, the apparatus further includes a creation module for: During the software construction phase, the fully qualified name of the service implementation class to be registered is obtained from the set of differentiated elements as the description information; Create a service declaration file named with the fully qualified name of the unified interface, and write the description information into the service declaration file; The service declaration file containing the description information is placed in the metadata directory of the application package.

[0018] In one possible implementation, the second processing module is further configured to: Based on the description information, load and instantiate all service implementation classes declared and registered by the set of differentiated elements to obtain the corresponding instance set; Obtain the version identifier of the target version and the hardware configuration information of the current operating environment; Based on the version identifier and the hardware configuration information, target service instances that match the target version are selected from the instance set.

[0019] In one possible implementation, the apparatus further includes a declaration module for: In the public code library, functional interfaces containing default methods and abstract methods are declared, wherein the default methods are used to implement general business logic, and the abstract methods are used to declare differentiated business logic; Within the set of differentiated elements, a concrete class is provided to implement the functional interface, and the differentiated business logic defined by the abstract method is implemented in the concrete class.

[0020] Thirdly, this application provides an apparatus comprising: a processor and a memory, wherein the processor is configured to execute a software application generation program stored in the memory to implement the software application generation method described in any one of the first aspects.

[0021] Fourthly, this application provides a storage medium storing one or more programs that can be executed by one or more processors to implement the software application generation method described in any one aspect.

[0022] Compared with the prior art, the technical solution provided in this application has the following advantages: First, by responding to the build request and determining the set of differentiated elements, a precise input foundation is established for subsequent processing, avoiding the necessity of creating independent branches for each version from the outset. Then, during the software build phase, compile-time differentiation processing is performed, solidifying the differentiated content into the static characteristics of the application package, enabling the isolation and integration of basic functional differences between versions during compilation. Finally, during the application package runtime phase, runtime differentiation processing is performed, dynamically providing differentiated functions and achieving a unification of static foundation and dynamic extension. Through this solution, all customized versions can generate fully functional applications based on the same common codebase, completely eliminating synchronization and merging conflicts in multi-branch development and significantly improving version management efficiency. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0026] Figure 1 A flowchart illustrating an embodiment of a software application generation method provided in this application; Figure 2 A flowchart illustrating an embodiment of another software application generation method provided in this application; Figure 3 A flowchart illustrating another embodiment of a software application generation method provided in this application; Figure 4 A block diagram illustrating an embodiment of a software application generation apparatus provided in this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0029] To address the technical problem in existing technologies where, as the number of projects increases, multiple independent branches lead to repeated synchronization and merging of core functionalities and bug fixes across branches, causing numerous conflicts, drastically increasing codebase maintenance costs, and resulting in chaotic version management, this application provides a software application generation method that enables all customized versions to generate fully functional applications based on the same common codebase. This completely eliminates synchronization and merging conflicts in multi-branch development and significantly improves version management efficiency.

[0030] Figure 1 This is a flowchart illustrating an embodiment of a software application generation method provided in this application. Figure 1 As shown, the method includes the following steps: Step 101: In response to a build request for a target version, determine the set of differential elements associated with the target version.

[0031] Build request: refers to a software build trigger instruction that contains a target version identifier.

[0032] Target version: refers to a software variant with specific functional customization requirements, such as an in-vehicle system version for different car models.

[0033] Differentiated element set: refers to the collection of resource files and code files stored in a dedicated source code directory that correspond to the target version.

[0034] In this embodiment, the build system (such as an Android build system based on Gradle) parses the build request, extracts the version identifier (such as through the BuildConfig.FLAVOR field), maps the identifier to the corresponding dedicated source code directory (such as src / a001 / res) according to the preset mapping rules, and collects the resource files and code files in the directory into a set of differentiated elements to provide input for subsequent differentiated processing.

[0035] Step 102: In the software construction phase, based on the set of differentiated elements, perform compile-time differentiation processing on the public code library to generate an application package that carries the static characteristics of the target version.

[0036] Software build phase: refers to the entire process from source code compilation and resource processing to generating APK (Android Package, application installation package).

[0037] Public code repository: refers to the main code repository (corresponding to the main source code set) that contains the common business logic and default implementation for all versions.

[0038] Compile-time differentiation: refers to the differentiation operations implemented during the build phase through resource merging and code compilation priority rules.

[0039] Static features: refer to user interface elements and pre-compiled functional modules that are embedded in the application package.

[0040] In this embodiment, when the system performs resource merging, it overwrites the resource files with the same name in the public code library with the resource files in the differentiated element set (such as the home.xml layout) to form the static interface features of the target version. At the same time, when compiling Java / Kotlin classes, it prioritizes the compilation of code files (such as the DataSyncManager class) in the differentiated element set that have the same class path as the public code library, replaces the original implementation, forms the static functional features of the target version, and finally generates an application package that carries these static features.

[0041] Step 103: During the runtime phase of the application package, based on the set of differentiated elements, the application package is subjected to runtime differentiation processing to provide the dynamic functions of the target version; wherein, through the combination of compile-time differentiation processing and runtime differentiation processing, a software application with the complete functions of the target version is generated from the public code library.

[0042] Runtime phase: refers to the period during which the application package is installed and executed on the terminal device.

[0043] Runtime differentiation: refers to the operation of dynamically loading differentiated functional components through the service discovery mechanism.

[0044] Dynamic functions: refer to business logic that needs to be adapted according to runtime hardware configuration or user policies.

[0045] In this embodiment, when the application starts, it parses the service declaration file (named with the fully qualified name of the unified interface and containing the fully qualified name of the implementation class) pre-installed in the META-INF / services / directory of the application package through the Java service loader. The content of this file is obtained and registered from the set of differentiated elements during the construction phase. After loading and instantiating all registered service implementation classes according to the description information, it selects matching service instances (such as A001DataParser) from the instance set by combining the target version identifier and the current hardware configuration information (such as the resolution of the vehicle screen), and provides dynamic functions by calling the interface methods of the instance.

[0046] The technical solution provided in this application first establishes a precise input foundation for subsequent processing by responding to build requests and determining the set of differentiated elements, thus avoiding the necessity of creating independent branches for each version from the outset. Then, during the software build phase, compile-time differentiation processing is performed, solidifying the differentiated content into the static characteristics of the application package, enabling the isolation and integration of basic functional differences between versions during compilation. Finally, runtime differentiation processing is performed during the application package runtime phase, dynamically providing differentiated functions and achieving a unification of static foundation and dynamic extension. This solution allows all customized versions to generate fully functional applications based on the same common codebase, completely eliminating synchronization and merging conflicts in multi-branch development and significantly improving version management efficiency.

[0047] In one embodiment, step 101 may specifically include the following steps: extracting the version identifier of the target version from the build request; determining the corresponding dedicated source code directory based on the version identifier; and determining the resource files and code files under the dedicated source code directory as the set of differentiated elements.

[0048] Version identifier: A string or enumeration value used to uniquely distinguish different software customization versions, such as the vehicle model code "a001" or the product line name "mainline". Dedicated source code directory: A directory created independently for a specific version within the project's source code structure. Its path is associated with the version identifier and is used to store resource files (including layout files, image resources, and string configurations) and code files (including Java class files and Kotlin class files) unique to that version.

[0049] In this solution, the build system (such as an Android build system based on Gradle) first parses the build command or configuration file and extracts the version identifier specified therein; then, according to the preset mapping rules (such as the directory naming convention src / <version identifier> / ), it maps the version identifier to the corresponding dedicated source code directory (e.g., src / a001 / java and src / a001 / res); finally, it scans the directory and its subdirectories and collects the layout files, image resources, string configurations, and Java / Kotlin class files into a set of differentiated elements.

[0050] This scheme achieves centralized management of differentiated content through precise mapping between version identifiers and source code directories, providing a structured input foundation for subsequent compilation and runtime processing. It avoids the need to create independent branches for different versions from the source, significantly reducing the complexity of version management.

[0051] In another embodiment, the resource files in the dedicated source code directory are categorized and stored according to the screen display characteristics of the target version; wherein, during the build process, the system automatically selects matching resource files for integration based on the screen characteristics of the target device.

[0052] Screen display characteristics: refers to the physical parameters of the terminal device's screen, including resolution, pixel density, screen size, and aspect ratio. Categorized storage: refers to a management method that organizes resource files into different directory structures according to specific rules.

[0053] In this embodiment, a resource directory structure based on screen display characteristics is established within a dedicated source code directory. For example, directories such as layout-1920x1080 and layout-2560x1440 are created according to resolution, or drawable-hdpi and drawable-xhdpi are created according to pixel density. During the build process, the build system identifies the screen characteristic parameters of the target device and automatically selects the resource files that best match the current device from the set of differentiated elements and integrates them into the application package. For example, layout files under the layout-2560x1440 directory are selected for high-resolution devices, and layout files under the layout-1920x1080 directory are selected for medium-resolution devices. This mechanism of classifying and storing resources according to screen characteristics and automatically matching them ensures that the application interface can achieve the best display effect on different devices, significantly improving the adaptation quality of the user interface and development efficiency.

[0054] Figure 2 A flowchart illustrating an embodiment of another software application generation method provided in this application. Figure 2 The process shown is in Figure 1 Based on the illustrated process, the following steps are included: Step 201: Use the resource files in the differentiated element set to overwrite the resource files with the same name in the public code library, so as to integrate the resource files in the differentiated element set into the application package and form the static interface features of the target version.

[0055] Resource files: These are configuration files used to define the display effects of the software interface, including layout files, image resources, string resources, etc.

[0056] Resource files with the same name: These are resource files that have the same file path and file name in the public code repository and the set of differentiated elements.

[0057] Static interface features: refer to the interface display effect fixed in the application package. It is the visual part that constitutes static features, including layout structure, visual elements and text content.

[0058] In this embodiment, during the software build process, the build system performs a resource merging operation. When a resource file with the exact same path and name as one in the common code repository is found in the differentiated element set, the resource file in the differentiated element set is selected for packaging first. For example, in the development of an in-vehicle system, a home.xml layout file with data dashboard functionality can be placed in a dedicated directory for high-end models (such as src / mainline / res / layout / ). This file will automatically override the basic layout file in the common directory (src / main / res / layout / ) during the build process, thus forming a static interface feature unique to high-end models. This resource overriding mechanism is one of the key elements constituting the static features of a version, ensuring that different versions can have unique visual presentations.

[0059] Step 202: Replace the original class files with the same classpath in the public code library with the code files in the differentiated element set, so as to compile the code files in the differentiated element set into the application package and form the static functional features of the target version.

[0060] Code files: refer to source code files that implement specific business logic, including Java class files, Kotlin class files, etc.

[0061] Same classpath: refers to packages and classes with identical names in both the common codebase and the differentiated element set.

[0062] Original class files: refer to the source code files in public code repositories that provide basic functionalities.

[0063] Static functional features: These refer to the functional logic that is determined and solidified in the application package during compilation. They are the core components of static features and together with static interface features, they completely define the compile-time solidified attributes of the target version.

[0064] In this embodiment, during the code compilation phase, the build system identifies code files in the differentiated element set that have the same package name and class name as the public code library, and automatically selects these customized implementations to replace the original basic functional implementation during compilation. For example, in the data synchronization function, the basic version uses the DataSyncManager class in the public code library to implement full synchronization, while the advanced version provides a DataSyncManager class with the same classpath in its dedicated source code directory to implement incremental synchronization. During the build process, the implementation of the advanced version is automatically compiled into the final application package. This code file replacement mechanism forms version-specific static functional features, which work together with the static interface features formed by resource overriding to jointly construct a complete static feature system, ensuring that different versions have differentiated functional characteristics while maintaining a unified core architecture.

[0065] Figure 2 The process shown uses resource overriding and class replacement mechanisms to complete the differentiation customization of interface and function during compilation. The generated application package naturally has version-specific static characteristics, avoiding complex condition judgments at runtime, improving code cleanliness and execution efficiency, and greatly enhancing the maintainability and scalability of multi-version development.

[0066] Figure 3 A flowchart illustrating another embodiment of a software application generation method provided in this application. Figure 3 The process shown is in Figure 1 Based on the illustrated process, the following steps are included: Step 301: During the runtime phase, parse the service declaration file pre-installed in the application package to obtain description information, wherein the description information is obtained from the set of differentiated elements and registered to the service declaration file during the software construction phase.

[0067] Service Declaration File: This refers to a configuration file created according to the SPI (Service Provider Interface) specification, used to register the specific implementation classes of the service interface.

[0068] Description information: refers to the fully qualified class name of the service implementation class recorded in the service declaration file.

[0069] In this embodiment, when the application starts, it scans the service declaration files under the META-INF / services / directory of the application package using the Java ServiceLoader. These files are named with the fully qualified name of a unified interface, and their contents are the fully qualified names of the concrete classes that implement that interface. This descriptive information is obtained and written from the set of differentiated elements during the software build phase. For example, when building the mainline version, it reads com.app.parser.MainlineDataParser from the corresponding file under the src / mainline / resources / directory and registers it to the service declaration file. When building version A001, it registers com.app.parser.A001DataParser, thereby ensuring that each version of the application package contains the correct service implementation class description information.

[0070] Step 302: Based on the description information, dynamically load and instantiate the service implementation class corresponding to the target version to provide the dynamic functionality.

[0071] Dynamic loading: refers to the process of loading class definitions as needed during program execution.

[0072] Instantiation: refers to the operation of creating an instance of a class.

[0073] Service implementation class: refers to the class that specifically implements the functional logic of the service interface.

[0074] In this embodiment of the application, the service loader dynamically loads the corresponding service implementation class and creates an instance object through the class loader based on the description information parsed from the service declaration file; for example, in the data parsing scenario, the system will load the MainlineDataParser or A001DataParser class based on the description information and create the corresponding instance for invocation.

[0075] Specifically, step 302 may include the following steps: loading and instantiating all service implementation classes declared and registered by the differentiated element set according to the description information to obtain the corresponding instance set; obtaining the version identifier of the target version and the hardware configuration information of the current running environment; and filtering out the target service instance that matches the target version from the instance set according to the version identifier and the hardware configuration information.

[0076] Instance Collection: Refers to the total number of service instance objects obtained after loading and instantiating the service implementation class. Hardware Configuration Information: Refers to the hardware parameters of the terminal device, including processor model, memory capacity, sensor type, and communication module version. Target Service Instance: Refers to the service instance object selected from the instance collection that best matches the current version and hardware environment.

[0077] In this solution, the service loader first loads and creates instances of all registered service implementation classes using reflection, based on the description information in the service declaration file, forming a candidate instance set. Then, it obtains the version identifier generated during compilation (e.g., through BuildConfig.FLAVOR) and the hardware configuration information detected at runtime. Finally, it selects the best matching instance from the instance set based on composite filtering conditions. For example, it first filters instances corresponding to the vehicle model based on the version identifier, and then further selects instances supporting specific display modes based on hardware configuration information (e.g., screen resolution). This hierarchical filtering mechanism ensures that the final service instances can simultaneously meet software version customization requirements and hardware environment adaptation requirements. Through preloading and composite filtering mechanisms, this solution achieves flexibility and scalability in service discovery while ensuring accurate functional adaptation. It satisfies the differentiated needs of multiple software versions while also considering dynamic hardware environment adaptation, significantly improving the system's robustness and adaptability in complex deployment environments.

[0078] Figure 3 The process shown achieves flexible runtime adaptation of business logic through the parsing of service declaration files and the dynamic loading mechanism of service implementation classes. This ensures that the core process remains consistent while supporting functional differences between different versions, significantly improving the system's scalability and maintainability, and ensuring precise matching of functional implementations.

[0079] In another embodiment, the method may further include the following steps: during the software construction phase, obtaining the fully qualified name of the service implementation class to be registered from the set of differentiated elements as the description information; creating a service declaration file named with the fully qualified name of the unified interface, and writing the description information into the service declaration file; placing the service declaration file containing the description information in the metadata directory of the application package.

[0080] Fully qualified name: refers to the class name that includes the complete package path and can uniquely identify a class, such as com.example.module.ClassName.

[0081] Unified interface: refers to the standard interface defined in a public codebase that is followed by all service implementation classes.

[0082] Metadata directory: This refers to a special directory used to store application configuration information, usually META-INF / services / .

[0083] In this embodiment, during the software build phase, the build system reads the service implementation class information to be registered from a specified location in the differentiated element set (e.g., src / mainline / resources / META-INF / services / ), obtaining its fully qualified name as description information. Then, it creates a service declaration file named with a unified fully qualified interface name (e.g., com.app.parser.DataParser) and writes the obtained fully qualified name of the implementation class into this file. Finally, it packages the generated service declaration file into the META-INF / services / directory of the application package, completing the service implementation registration process. For example, when building the mainline version, com.app.parser.MainlineDataParser is written to the com.app.parser.DataParser file, while when building version A001, com.app.parser.A001DataParser is written, ensuring that each version of the application package contains the correct service registration information.

[0084] This solution achieves decoupling between service implementation and interface definition through an automated service registration mechanism during the build phase. This allows different versions to flexibly configure their respective implementation classes and provides reliable metadata support for runtime service discovery, significantly improving the system's scalability and maintainability.

[0085] In another embodiment, the method may further include the following steps: in the public code library, declaring a functional interface containing default methods and abstract methods, wherein the default methods are used to implement general business logic, and the abstract methods are used to declare differentiated business logic; in the set of differentiated elements, providing a concrete class that implements the functional interface, and implementing the differentiated business logic defined by the abstract methods in the concrete class.

[0086] Functional interface: refers to the contract specification declared through the interface definition language, which includes default methods and abstract methods.

[0087] Default method: refers to a non-abstract method in the interface that provides a default implementation, used to encapsulate common processing logic shared across versions.

[0088] Abstract methods: These are methods declared in an interface but without providing an implementation. They are used to define differentiated business logic that needs to be implemented by each version.

[0089] Concrete class: refers to the class provided in the set of differentiated elements that implements the functional interface and specifically implements all abstract methods.

[0090] In this embodiment, the functional interfaces defined in the public codebase implement common business processes through default methods. For example, the voice command parsing interface implements common logic such as command reception, word segmentation, and basic verification through default methods. Simultaneously, abstract methods declare business points requiring differentiated processing, such as the `handleClimateCommand()` method for handling air conditioning commands. Within the differentiated element set of each project, specific classes implementing these functional interfaces are provided. For example, high-end vehicle projects implement zoned air conditioning control logic, while basic vehicle projects implement overall air conditioning control logic. This design ensures the uniformity of core business processes while providing ample customization space for different versions.

[0091] This solution separates the default and abstract methods of the functional interfaces, achieving an organic combination of unified maintenance of general logic and flexible customization of differentiated logic. This avoids code duplication and ensures personalized implementation of business for each version, significantly improving the maintainability and scalability of the system.

[0092] Furthermore, during the software construction phase, the method may also include the following steps: defining the version identifier of the target version as a compile-time constant and generating it in the configuration class of the application package; in the runtime differentiation process, obtaining the version identifier of the target version by reading the compile-time constant in the configuration class.

[0093] Compile-time constants: These are constant fields whose values ​​are determined and directly embedded into the code during the software compilation phase.

[0094] Configuration class: refers to a dedicated class that is automatically generated in the application package and is used to store build configuration information.

[0095] In this embodiment, during the software build phase, the version identifier of the target version is defined as a compile-time constant through the build script (such as the `buildConfigField` method in Gradle configuration). This constant is automatically generated in a specific configuration class of the application package (such as the `BuildConfig` class in an Android project). In the subsequent runtime differentiation processing phase, the target version information of the current application is accurately obtained by directly reading the version identifier constant (such as `BuildConfig.FLAVOR`) in this configuration class. For example, during the filtering of service implementation classes, reading this constant can accurately identify whether the currently running version is the mainline version or the A001 project version, thereby ensuring that the correct service instance is loaded.

[0096] This solution solidifies the version identifier into a compile-time constant, providing a reliable and efficient version identification mechanism at runtime. This avoids the maintenance problems caused by hard coding and ensures the accuracy and consistency of version information transmission, laying a solid foundation for the accurate adaptation of multiple software versions.

[0097] To make the solution in this application clearer and easier to understand, the software application generation method described in this application will be fully explained below in conjunction with a specific vehicle system development scenario.

[0098] 1. Project Structure and Build Configuration In this embodiment, taking the development of an in-vehicle infotainment system as an example, two projects, the high-end model (Mainline) and the basic model (A001), are developed on the same line.

[0099] Project hierarchy configuration: Define two product flavors in the project build configuration file: mainline and a001, corresponding to the high-end model and the basic model, respectively. Each flavor specifies a corresponding source code directory, with the mainline flavor pointing to the src / mainline directory and the a001 flavor pointing to the src / a001 directory. Also, configure a default source code set, main, to store common code and resources.

[0100] 2. Specific Implementation of Three-Level Difference Handling 2.1 UI (User Interface) Adaptation Difference Handling (Resource Layering and Overriding) The resource directory in the main source code set contains basic layout files, general sizes, and color definitions. In the mainline-style resource directory, create a dedicated layout directory at 1920x1080 resolution to house the complex homepage layout including data dashboards and a dark color scheme. In the a001-style resource directory, create a layout directory at 1280x720 resolution to house a simplified homepage layout and a light color scheme.

[0101] During the build process, the system automatically selects the resource files in the corresponding directory based on the target flavor, overwriting the files with the same name in the main directory. At runtime, layout and color resources are accessed through the standard resource loading interface, and the system automatically provides the resource instance corresponding to the current flavor.

[0102] 2.2 Class-level difference handling (dual-mode isolation) Path matching and replacement mode implementation: Define a data synchronization manager class in the main source code set to implement full data synchronization logic. In the mainline flavor's source code set, create a data synchronization manager class with the exact same package path and class name to implement the incremental synchronization algorithm. During the build system compilation, it will automatically select the class files in the flavor's specific directory to achieve seamless replacement of functional logic.

[0103] SPI dynamic loading mode implementation: A unified interface for the ECU (Electronic Control Unit) communicator is defined in the main source code set, declaring general methods for vehicle bus communication. A deluxe version of the ECU communicator, supporting the CAN-FD (Controller Area Network Flexible Data-Rate) high-speed bus protocol, is implemented in the mainline flavor; a standard version of the ECU communicator, supporting the standard CAN (Controller Area Network) bus protocol, is implemented in the a001 flavor. Service declaration files are created in the resource directories of each flavor, registering the corresponding implementation classes.

[0104] At runtime, the ServiceLoader scans the service declaration file and, in conjunction with the current vehicle model identifier and hardware configuration information, dynamically loads the matching ECU communicator implementation instance.

[0105] 2.3 Handling method-level differences (functional interface) The voice command processor interface is defined in the main source code set. Common logic such as command parsing and verification is implemented through default methods, while differentiated logic, such as air conditioning command processing, is declared as abstract methods. A concrete implementation is provided in the mainline flavor, supporting zoned air conditioning control and fine-tuning of multi-zone temperature control; a concrete implementation is provided in the a001 flavor, supporting only overall air conditioning control.

[0106] The ServiceLoader obtains the voice command processor instance for the current vehicle model, and automatically executes the corresponding vehicle model's implementation logic when the processing method is called.

[0107] 3. Build and Run Process Build Phase: Based on the flavor parameters specified in the build command, determine the target vehicle model version. Collect the set of differentiated elements under the corresponding flavor directory, including layout resources, replacement classes, and SPI implementation classes. Perform resource merging, overriding common resources with flavor-specific resources. Compile the replacement class files under the flavor-specific directory. Generate an application package containing configuration classes with flavor identifiers and SPI service declaration files.

[0108] Runtime Phase: Upon application startup, the current vehicle model version is determined based on the flavor identifier in the configuration class. Flavor-specific UI layouts and visual resources are loaded. Matching service implementation instances are dynamically loaded via ServiceLoader, combining the flavor identifier and hardware configuration information. Throughout the runtime, vehicle-specific business logic is executed through a unified interface call.

[0109] This example demonstrates how to maintain software for multiple vehicle models simultaneously within a single codebase using a "Flavor + SPI" combined strategy. UI differences are fixed at compile time through resource overriding, core functionalities are implemented through class replacement, and business logic differences are dynamically loaded via SPI. This approach ensures maximum reusability of core code while providing ample customization capabilities, significantly improving the efficiency and quality of in-vehicle software development.

[0110] This implementation plan effectively resolves the conflict between code reuse and difference isolation in the development of multiple projects along the same line, and provides a feasible technical path for the large-scale customized development of intelligent cockpit software.

[0111] Figure 4 This is a block diagram illustrating an embodiment of a software application generation apparatus provided in this application. Figure 4 As shown, the device includes: Determining module 41 is configured to determine, in response to a build request for a target version, a set of differential elements associated with the target version; The first processing module 42 is used to perform compile-time differentiation processing on the public code library based on the set of differentiated elements during the software construction phase, so as to generate an application package that carries the static characteristics of the target version. The second processing module 43 is used to perform runtime differentiation processing on the application package based on the set of differentiated elements during the runtime phase of the application package, so as to provide the dynamic functions of the target version. Specifically, by combining compile-time differentiation processing with runtime differentiation processing, a software application with the full functionality of the target version is generated from the public code repository.

[0112] In one possible implementation, the determining module is specifically used for: Extract the version identifier of the target version from the build request; Based on the version identifier, determine the corresponding exclusive source code directory; The resource files and code files in the dedicated source code directory are identified as the set of differentiated elements.

[0113] In one possible implementation, the static features include static interface features and static functional features of the target version. The first processing module is specifically used for: The resource files in the differentiated element set are used to overwrite the resource files with the same name in the public code library, so as to integrate the resource files in the differentiated element set into the application package and form the static interface features of the target version; The code files in the differentiated element set are used to replace the original class files with the same class paths in the public code library, so that the code files in the differentiated element set are compiled into the application package to form the static functional features of the target version.

[0114] In one possible implementation, the second processing module is specifically used for: During the runtime phase, the service declaration file pre-installed in the application package is parsed to obtain description information, wherein the description information is obtained from the set of differentiated elements and registered to the service declaration file during the software construction phase; Based on the description information, the service implementation class corresponding to the target version is dynamically loaded and instantiated to provide the dynamic functionality.

[0115] In one possible implementation, the apparatus further includes a creation module for: During the software construction phase, the fully qualified name of the service implementation class to be registered is obtained from the set of differentiated elements as the description information; Create a service declaration file named with the fully qualified name of the unified interface, and write the description information into the service declaration file; The service declaration file containing the description information is placed in the metadata directory of the application package.

[0116] In one possible implementation, the second processing module is further configured to: Based on the description information, load and instantiate all service implementation classes declared and registered by the set of differentiated elements to obtain the corresponding instance set; Obtain the version identifier of the target version and the hardware configuration information of the current operating environment; Based on the version identifier and the hardware configuration information, target service instances that match the target version are selected from the instance set.

[0117] In one possible implementation, the apparatus further includes a declaration module for: In the public code library, functional interfaces containing default methods and abstract methods are declared, wherein the default methods are used to implement general business logic, and the abstract methods are used to declare differentiated business logic; Within the set of differentiated elements, a concrete class is provided to implement the functional interface, and the differentiated business logic defined by the abstract method is implemented in the concrete class.

[0118] like Figure 5 As shown in the figure, this application provides a device including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes a program stored in the memory 113, it implements the software application generation method provided in any of the foregoing method embodiments, including: In response to a build request for a target version, determine a set of differentiated elements associated with the target version; During the software construction phase, based on the set of differentiated elements, the public code library is subjected to compile-time differentiation processing to generate an application package that carries the static characteristics of the target version; During the runtime phase of the application package, based on the set of differentiated elements, runtime differentiation processing is performed on the application package to provide the dynamic functions of the target version; Specifically, by combining compile-time differentiation processing with runtime differentiation processing, a software application with the full functionality of the target version is generated from the public code repository.

[0119] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the software application generation method provided in any of the foregoing method embodiments.

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

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0122] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0123] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for generating software applications, characterized in that, The method includes: In response to a build request for a target version, determine a set of differentiated elements associated with the target version; During the software construction phase, based on the set of differentiated elements, the public code library is subjected to compile-time differentiation processing to generate an application package that carries the static characteristics of the target version; During the runtime phase of the application package, based on the set of differentiated elements, runtime differentiation processing is performed on the application package to provide the dynamic functions of the target version; Specifically, by combining compile-time differentiation processing with runtime differentiation processing, a software application with the full functionality of the target version is generated from the public code repository.

2. The method according to claim 1, characterized in that, The determination of the set of differentiated elements associated with the target version includes: Extract the version identifier of the target version from the build request; Based on the version identifier, determine the corresponding exclusive source code directory; The resource files and code files in the dedicated source code directory are identified as the set of differentiated elements.

3. The method according to claim 1, characterized in that, The static features include the static interface features and static functional features of the target version. The process of performing compile-time differentiation processing on the public codebase based on the differentiated element set includes: The resource files in the differentiated element set are used to overwrite the resource files with the same name in the public code library, so as to integrate the resource files in the differentiated element set into the application package and form the static interface features of the target version; The code files in the differentiated element set are used to replace the original class files with the same class paths in the public code library, so that the code files in the differentiated element set are compiled into the application package to form the static functional features of the target version.

4. The method according to claim 1, characterized in that, The runtime differentiation processing of the application package based on the differentiated element set includes: During the runtime phase, the service declaration file pre-installed in the application package is parsed to obtain description information, wherein the description information is obtained from the set of differentiated elements and registered to the service declaration file during the software construction phase; Based on the description information, the service implementation class corresponding to the target version is dynamically loaded and instantiated to provide the dynamic functionality.

5. The method according to claim 4, characterized in that, The method further includes: During the software construction phase, the fully qualified name of the service implementation class to be registered is obtained from the set of differentiated elements as the description information; Create a service declaration file named with the fully qualified name of the unified interface, and write the description information into the service declaration file; The service declaration file containing the description information is placed in the metadata directory of the application package.

6. The method according to claim 4, characterized in that, The step of dynamically loading and instantiating the service implementation class corresponding to the target version based on the description information includes: Based on the description information, load and instantiate all service implementation classes declared and registered by the set of differentiated elements to obtain the corresponding instance set; Obtain the version identifier of the target version and the hardware configuration information of the current operating environment; Based on the version identifier and the hardware configuration information, target service instances that match the target version are selected from the instance set.

7. The method according to claim 1, characterized in that, The method further includes: In the public code library, functional interfaces containing default methods and abstract methods are declared, wherein the default methods are used to implement general business logic, and the abstract methods are used to declare differentiated business logic; Within the set of differentiated elements, a concrete class is provided to implement the functional interface, and the differentiated business logic defined by the abstract method is implemented in the concrete class.

8. A software application generation device, characterized in that, The device includes: A determination module is configured to, in response to a build request for a target version, determine a set of differential elements associated with the target version; The first processing module is used to perform compile-time differentiation processing on the public code library based on the set of differentiated elements during the software construction phase, so as to generate an application package that carries the static characteristics of the target version. The second processing module is used to perform runtime differentiation processing on the application package based on the set of differentiation elements during the runtime phase of the application package, so as to provide the dynamic functions of the target version. Specifically, by combining compile-time differentiation processing with runtime differentiation processing, a software application with the full functionality of the target version is generated from the public code repository.

9. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a software application generation program stored in the memory to implement the software application generation method according to any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the software application generation method according to any one of claims 1-7.

Images