Methods for constructing software development models that adapt to multiple hardware platforms

Abstract

This invention relates to the field of computer software technology. Specifically, it relates to a method for constructing a software development model adapted to multiple hardware platforms. When the target hardware platform is first started, a hardware baseline detection daemon is run to collect multi-dimensional low-level physical feature parameters and uses a sparse coding algorithm to fuse and generate a hardware baseline capability fingerprint. During the software development phase, a compile-time annotation processor is used to scan key functional modules and extract non-functional feature contract tags pre-embedded by the developer using structured declarative annotations into a tag list index file. After the fingerprint generation is completed upon software startup, a multi-dimensional constraint solving rule engine is used to perform conflict detection and optimal fit scoring and sorting of the module contract tags and hardware fingerprints, and to select the uniquely matching target functional module entry class. Based on this entry class, a server-side dynamic orchestration and distribution mechanism is used to extract only the associated high-cohesion atomized payload packages and inject them into the main program runtime context to complete dynamic assembly.

Description

Technical Field

[0001] This invention relates to the field of technology, and more specifically, to a method for constructing a software development model that is compatible with multiple hardware platforms. Background Technology

[0002] With the popularization of the Internet of Things and edge computing, software needs to be adapted to a large number of heterogeneous hardware platforms such as servers, industrial control computers, and embedded terminals. The traditional multi-hardware platform adaptation method mainly adopts the pre-compiled multi-version static packaging method, that is, during the development stage, software packages containing all functional modules are compiled separately for each target platform, and the system selects and loads the corresponding version according to preset rules or configuration files during distribution. However, this method has significant drawbacks: First, the differentiated code for different hardware platforms is embedded into the same software package during compilation, leading to a rapid expansion of the software installation package size. A large amount of redundant code incompatible with the current hardware is distributed and stored along with the main program. Second, the hardware adaptation logic is tightly coupled with the functional code. When new hardware platform support is needed or hardware configuration parameters are updated, the entire software package must be recompiled and republished, making runtime on-demand adaptation impossible. Third, existing methods lack fine-grained quantification of hardware capabilities and precise measurement of inter-module compatibility. They can only perform coarse version matching based on simple hardware category labels, making it difficult to select the optimal function implementation based on hardware performance differences. In summary, existing technologies have significant shortcomings in terms of installation package size, dynamic adaptation flexibility, and adaptation accuracy. To address this technical problem, we provide a method for constructing a software development model that adapts to multiple hardware platforms. Summary of the Invention

[0003] The purpose of this invention is to provide a method for constructing a software development model that is compatible with multiple hardware platforms, so as to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, one objective of this invention is to provide a method for constructing a software development model adaptable to multiple hardware platforms, comprising the following steps: S1. When the software is first launched on the target hardware platform, the hardware baseline detection daemon runs. The hardware baseline detection daemon collects multi-dimensional low-level physical feature parameters of the target hardware platform and uses a sparse coding algorithm to fuse the multi-dimensional low-level physical feature parameters locally to generate a hardware baseline capability fingerprint. S2. During the software development phase, the compiler-time annotation processor is used to scan the key functional modules in the code and extract the non-functional feature contract tags that are pre-embedded by the developer in the form of structured declarative annotations into the tag list index file. The non-functional feature contract tags are used to declare the non-functional pre-dependencies of the corresponding module on the target hardware platform. S3. After the software starts and completes the generation of the hardware baseline capability fingerprint, it loads the tag list index file and uses a multi-dimensional constraint solving rule engine to perform conflict detection and optimal fit scoring and sorting of the non-functional characteristic contract tags declared by each key functional module and the hardware baseline capability fingerprint currently generated by the target hardware platform, so as to filter out the target functional module entry class that uniquely matches the target hardware platform. S4. Based on the target functional module entry class, the server uses a dynamic orchestration and distribution mechanism to extract only the highly cohesive atomized payload package associated with the target functional module entry class and inject it into the main program runtime context to complete dynamic assembly.

[0005] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention generates a concise and unique fingerprint representing hardware capabilities through a hardware baseline detection daemon and a sparse coding algorithm, enabling fine-grained quantitative identification of heterogeneous hardware performance. It utilizes a compile-time annotation processor to extract and solidify the non-functional characteristic contract tags of modules into independent index files, decoupling hardware adaptation logic from functional code and avoiding package bloat caused by redundant code distributed with the package. At runtime, a multi-dimensional constraint solving rule engine performs conflict detection and optimal adaptation scoring on the hardware capability fingerprint and module contract tags, accurately selecting the optimal functional module based on actual hardware performance rather than relying on simple category marking. Finally, with the help of a server-side dynamic orchestration and distribution mechanism, highly cohesive atomized payload packages are extracted on demand and injected into the runtime context, achieving runtime dynamic adaptation without recompilation or restart. Attached Figure Description

[0006] Figure 1 This is a flowchart illustrating the overall workflow of the present invention. Detailed Implementation

[0007] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0008] Please see Figure 1 As shown, this embodiment provides a method for constructing a software development model that adapts to multiple hardware platforms, including the following steps: S1. When the software is first launched on the target hardware platform, the hardware baseline detection daemon runs. The hardware baseline detection daemon collects multi-dimensional low-level physical feature parameters of the target hardware platform and uses a sparse coding algorithm to fuse the multi-dimensional low-level physical feature parameters locally to generate a hardware baseline capability fingerprint. S2. During the software development phase, the compiler annotation processor is used to scan the key functional modules in the code and extract the non-functional feature contract tags that the developer has pre-embedded in the structured declarative annotations into the tag list index file. The non-functional feature contract tags are used to declare the non-functional pre-dependencies of the corresponding module on the target hardware platform. S3. After the software starts up and completes the generation of the hardware baseline capability fingerprint, it loads the tag list index file and uses the multi-dimensional constraint solving rule engine to perform conflict detection and optimal fit scoring and sorting of the non-functional characteristic contract tags declared by each key functional module and the hardware baseline capability fingerprint currently generated by the target hardware platform, so as to select the target functional module entry class that uniquely matches the target hardware platform. S4. Based on the target functional module entry class, the server-side dynamic orchestration and distribution mechanism extracts only the highly cohesive atomized payload package associated with the target functional module entry class and injects it into the main program runtime context to complete dynamic assembly.

[0009] Further explanation is needed. After the software is first launched on the target hardware platform and the hardware baseline detection daemon runs, this daemon, as a lightweight background process automatically loaded when the software starts on the target hardware platform, is responsible for the non-intrusive collection, standardized encapsulation, and temporary storage of low-level hardware features. This provides complete raw hardware data support for the subsequent sparse coding algorithm fusion to generate the hardware baseline capability fingerprint. Here, the target hardware platform refers to various hardware carriers that the software needs to be adapted to, including servers, embedded terminals, industrial control computers, and other devices. The operating system kernel interface is the low-level call interface exposed by the operating system kernel, used to directly obtain the native configuration information of core hardware such as CPU and memory. The hardware abstraction layer interface is a standardized access interface that shields the differences between different hardware architectures, used to uniformly read the feature data of hardware modules such as GPU and peripherals. The CPU instruction set architecture refers to the type of instruction set supported by the CPU, and the number of cores refers to the total number of physical cores of the CPU. Cache hierarchy and capacity refer to the hierarchical division of CPU cache levels (L1, L2, L3) and their corresponding storage capacity. Total memory capacity and bandwidth refer to the total storage size of physical memory and the data transfer rate. Persistent storage media refer to long-term data storage devices such as hard drives, flash memory, and solid-state drives. Read and write rates refer to the data read and write speeds of persistent storage media. The number of GPU rendering pipelines refers to the total number of parallel rendering processing units of the GPU. The number of shader units refers to the number of programmable graphics processing cores of the GPU. Peripheral interface type and version refer to the type and corresponding version number of external interfaces such as USB, Ethernet, and serial ports. Multi-dimensional low-level physical characteristic parameters are a set of structured parameters used to quantify the comprehensive performance of the target hardware platform. Key-value pair data structure is a data organization form composed of unique key names and corresponding parameter values. Process memory buffer is a temporary storage area allocated within the independent memory space of the hardware baseline detection daemon process, used to temporarily store the collected raw hardware data.

[0010] After the hardware baseline detection daemon starts, it first calls the operating system kernel interface and hardware abstraction layer interface of the target hardware platform in sequence according to the preset hardware module priority order through system call instructions. It initiates hardware feature parameter reading requests one by one. For CPU-related parameters, it reads the CPU instruction set architecture identifier, number of physical cores, hierarchical division information of each cache level and corresponding capacity value through the operating system kernel interface, parses the binary data returned by the interface and converts it into decimal value format. For memory-related parameters, it reads the total physical memory capacity value and memory data bandwidth value through the operating system kernel interface and completes the value format standardization conversion. For persistent storage media-related parameters, it reads the storage media type identifier, sequential read rate value and sequential write rate value through the hardware abstraction layer interface, filters invalid data and retains valid parameter values. For GPU-related parameters, it reads the total number of GPU rendering pipelines and the total number of shader units through the hardware abstraction layer interface and extracts the core count value. For peripheral interface-related parameters, it reads the type code and version number code of each peripheral interface through the hardware abstraction layer interface and maps them into standard text format.

[0011] After completing the reading and standardized parsing of all parameters, the hardware baseline probing daemon integrates and encapsulates all the aforementioned hardware feature information into a unified format of multi-dimensional low-level physical feature parameter set. It then constructs a key-value pair data structure, assigning a unique and non-repeating key name to each type of parameter. The key name is a combination of the parameter type's English abbreviation, and the parameter value serves as the value of the corresponding key name. All key-value pairs together constitute a complete parameter key-value pair set, the mathematical expression of which is: In the formula This represents the set of key-value pairs corresponding to multi-dimensional underlying physical feature parameters. Indicates the first The unique key name of each parameter. Indicates the first The standardized values ​​corresponding to each parameter This indicates the total number of dimensions of the hardware feature parameters collected this time. After the key-value pair data structure is constructed, the hardware baseline detection daemon writes the key-value pair set into the buffer of the process memory for temporary storage. The buffer adopts the first-in-first-out storage rule, retaining only the valid parameter data collected this time, without persistent storage, to avoid occupying too much hardware storage space. After the parameter collection, encapsulation and temporary storage are completed, the hardware baseline detection daemon triggers the sparse coding algorithm call instruction to provide the temporarily stored key-value pair data for subsequent fusion to generate the hardware baseline capability fingerprint.

[0012] After completing the acquisition, encapsulation, and buffering of multi-dimensional underlying physical feature parameters, the sparse coding algorithm officially starts the data reading and feature fusion process. As the core computing module for generating hardware baseline capability fingerprints, this algorithm transforms scattered multi-dimensional hardware parameters into hardware baseline capability fingerprints, providing standardized hardware feature identifiers for subsequent cross-platform module adaptation. The key-value pair data structure is a structured data organization form for storing multi-dimensional underlying physical feature parameters. The buffer is an independent storage area in the daemon process memory space used to temporarily cache the original hardware data. The sparse coding algorithm is a feature dimensionality reduction and fusion algorithm based on sparse representation theory, which can transform high-dimensional redundant data into low-dimensional sparse features. The hardware baseline capability fingerprint is a fixed-length hash value used to uniquely characterize the comprehensive performance level of the target hardware platform.

[0013] The sparse coding algorithm first uses the inter-process memory access interface to read the key-value pair data structure temporarily stored in the memory buffer of the hardware baseline probing daemon. It then traverses each key-value pair element in the key-value pair set, extracting the original value of the corresponding dimension parameter one by one. All the original values ​​are stored into a temporary value array in the order of parameter collection. During the reading process, the integrity of the key-value pairs is verified. The verification rules are that the key name is not duplicated, the value is not null, and the data type matches. If the verification fails, the buffer data synchronization is re-triggered to ensure that the read original hardware parameters are complete and valid, providing a reliable data source for subsequent normalization processing.

[0014] After completing the key-value pair data reading, the algorithm enters the numerical normalization process. Normalization is a standardization operation that maps original parameters with different units and numerical ranges to the same common scale. The common scale refers to a unified numerical range. This process uses the range of 0 to 1 as the common scale to eliminate the calculation deviations caused by differences in physical units and numerical magnitudes of parameters such as the number of CPU cores, memory bandwidth, and storage read / write speed. The numerical normalization adopts the min-max normalization method. For the j-th dimension of the original parameter in the temporary numerical array, the historical training dataset is a pre-collected massive sample of parameters from heterogeneous hardware platforms, used to determine the numerical boundaries of parameters in each dimension. The algorithm traverses all dimensions of the temporary numerical array, substitutes them one by one into the formula to complete the normalization calculation, and generates a standardized array containing the normalized values ​​of all dimensions, ensuring that the parameters in each dimension have a unified numerical scale, which meets the calculation requirements of subsequent high-dimensional vector concatenation and sparse decomposition.

[0015] After numerical normalization, the algorithm concatenates all normalized values ​​in the standardized array in a predetermined order to generate a high-dimensional vector. This predetermined order is: CPU-related parameters, memory-related parameters, persistent storage media-related parameters, GPU-related parameters, and peripheral interface-related parameters. This order is consistent with the acquisition order during hardware detection to ensure consistency of feature dimensions. The mathematical expression for constructing the high-dimensional vector is: In the formula This represents the high-dimensional vector of hardware features generated by splicing. to These represent the normalized values ​​of the parameters from the 1st to the mth dimensions, respectively. The high-dimensional vector represents the total number of dimensions of the multi-dimensional underlying physical feature parameters. It integrates all the underlying physical feature information of the target hardware platform, and the number of dimensions corresponds one-to-one with the dimensions of the collected parameters. It fully preserves the multi-dimensional feature correlation of hardware performance and provides an input carrier for sparse coding.

[0016] After the high-dimensional vector is constructed, the algorithm calls a pre-trained overcomplete dictionary to perform linear decomposition. The overcomplete dictionary is the core training model of the sparse coding algorithm; it refers to a matrix where the number of atoms is greater than the dimension of the high-dimensional vector. The atoms are column vectors of the dictionary matrix, used to represent the basic patterns of hardware features. The mathematical expression for the overcomplete dictionary is: In the formula Represents an overcomplete dictionary matrix. Represents the dimension of a high-dimensional vector. Represents the number of atoms in the dictionary, and satisfies This dictionary is pre-trained using massive amounts of heterogeneous hardware feature samples, enabling it to cover various hardware performance feature patterns. The core objective of linear decomposition is to represent high-dimensional vectors as linear combinations of a small number of atoms in the overcomplete dictionary, highlighting the core information of hardware features and filtering redundant noise. The mathematical expression for the decomposition solution is: In the formula This represents the sparse coefficient vector to be solved. The L1 norm of the sparse coefficient vector is used to constrain the sparsity of the coefficient vector. This represents the sum of squared errors of a linear combination of a high-dimensional vector and a dictionary. The preset error threshold is represented by the algorithm, which solves the constrained optimization problem through iterative optimization to obtain a sparse coefficient vector. Most of the elements in this vector are 0, and only a few non-zero elements correspond to atoms in the overcomplete dictionary that match the target hardware features. This achieves sparse representation of high-dimensional hardware features, significantly reducing feature dimensionality while retaining core performance information.

[0017] After the sparse coefficient vector is solved, the algorithm sequentially performs serialization and hashing operations to generate a hardware baseline capability fingerprint. Serialization converts the sparse coefficient vector into a fixed-format byte sequence. The algorithm iterates through the sparse coefficient vector, recording the index position and corresponding value of all non-zero elements, and encodes the index and value into a binary byte stream. The length of the byte stream is adaptively adjusted according to the sparsity of the sparse coefficient vector to ensure compact data and no information loss. The hashing operation uses the SHA-256 cryptographic hash algorithm. The binary byte stream generated by serialization is used as input, and a 256-bit fixed-length hexadecimal hash value is generated through the non-linear compression operation of the hash algorithm. The mathematical expression for the hashing operation is: In the formula This indicates that the generated fixed-length hash value is the hardware baseline capability fingerprint. Representing the binary byte stream after sparse coefficient vector serialization, the SHA-256 algorithm possesses the characteristics of being irreversible, collision-free, and having a fixed output length. This ensures that the generated hardware baseline capability fingerprint uniquely corresponds to the comprehensive performance characteristics of the target hardware platform. Even slight differences in hardware parameters will generate completely different fingerprints. At the same time, the fingerprint has a fixed length and uniform format, facilitating subsequent cross-platform comparison and matching operations. After completing the above full-process operation, the sparse coding algorithm generates a unique hardware baseline capability fingerprint. This fingerprint accurately represents the comprehensive performance characteristics of the target hardware platform, has no redundant information, and has a fixed length. It can be directly used for subsequent conflict detection and adaptation calculation of non-functional characteristic contract tags of key functional modules. Thus, the hardware baseline detection daemon process and the sparse coding algorithm work together to complete all the work in step S1, laying the core hardware feature foundation for annotation extraction in the subsequent software development stage and module adaptation in the runtime stage.

[0018] After completing the local generation and standardized output of the hardware baseline capability fingerprint, the software development phase immediately initiates the compile-time annotation processor for scanning and parsing. Leveraging compile-time static analysis technology, it performs a full traversal of key functional modules, deep parsing of the syntax tree, extraction of core identifiers, and binding of contract tags during source code compilation. This provides standardized module metadata and constraint information for module adaptation in the subsequent runtime phase. The compile-time annotation processor is a plug-in processing component automatically loaded by the compiler during the source code compilation phase. It parses custom annotations in the code and performs static semantic processing. Specific annotations are predefined marker annotations by the developer, used only to identify classes and methods related to key functional modules. Key functional modules are those that implement the same hardware-independent functional interface but are designed for different hardware platforms. For code modules undergoing specialized optimization, the functional interface is an abstract interface that uniformly defines the signature of core business methods and does not contain hardware operation logic. The syntax tree is a structured abstract syntax tree generated by the compiler after parsing the source code text, used to accurately represent the syntax hierarchy and logical structure of the code. The fully qualified class name is a globally unique class identifier that includes the complete package path and class name. The module dependency coordinates are standardized coordinate strings used to uniquely identify code modules. The non-functional feature contract tags are key-value pair constraint tags implanted by developers through structured declarative annotations. The temporary mapping relationship is the corresponding binding relationship between module identifiers and contract tags established in the memory of the compile-time annotation processor. The internal state is a memory storage area independently allocated by the compile-time annotation processor at runtime, used to temporarily store intermediate processing data during the compilation process.

[0019] After the source code compilation starts, the compiler first completes lexical and syntactic analysis of the source code, generating a basic syntax tree structure. Then, through the SPI service registration mechanism or compilation configuration file, it automatically loads the pre-registered compile-time annotation processor, ensuring that this processor executes during a specific compilation stage after syntax analysis and before bytecode generation. After the processor is loaded, it first initializes the internal state storage area. Initialization operations include creating an empty hash table structure, configuring key-value pair read / write rules, and setting a data consistency check mechanism, preparing for the storage of subsequent temporary mapping relationships. After initialization, the compile-time annotation processor starts a full traversal process, traversing all class nodes and all method nodes within the current compilation unit. The traversal uses a depth-first traversal algorithm, starting from the root node of the syntax tree and traversing package nodes, class nodes, member nodes, and method nodes layer by layer. During the traversal, annotation matching checks are performed on each node. The detection rule is to determine whether the node is marked with a specific annotation defined by the developer. Only classes and methods marked with this specific annotation are marked as nodes to be processed; other nodes are skipped. The quantitative statistical expression for the traversal process is as follows: In the formula This represents the total number of unprocessed nodes encountered during the traversal. This represents the set of all class nodes within the current compilation unit. This represents the collection of all method nodes belonging to a single class node. This indicates an indicator function that takes the value 1 when the condition within the parentheses is true. This indicates the logical condition for labeling a node with a specific annotation.

[0020] After the nodes to be processed are selected, the compiler-time annotation processor executes a precise definition of key functional modules. The definition rule is to select classes in the nodes to be processed that implement the same preset functional interface. The same functional interface defines a unified core business method and has no hardware-related implementation logic. Key functional modules of different hardware platform optimized versions complete hardware adaptation optimization of unified functional logic through interface implementation, such as optimization for CPU instruction set, GPU parallel computing, and memory access efficiency. The processor parses the interface implementation relationship through syntax tree, verifies whether the class to be processed implements the specified functional interface, and removes the class to be processed that does not implement the interface. Finally, a set of key functional modules that meet the definition is obtained. Each class in this set is a dedicated optimization module for the corresponding hardware platform.

[0021] After defining the set of key functional modules, the compile-time annotation processor performs a deep parsing operation on the class syntax tree corresponding to each key functional module within the set. The syntax tree contains a multi-layered structure including package declaration nodes, class definition nodes, parent class interface nodes, member variable nodes, method nodes, and annotation nodes. The processor traverses the syntax tree nodes layer by layer, first extracting the fully qualified class name. The extraction logic involves concatenating the complete package path string from the package declaration node and the class name string from the class definition node to form a globally unique class identifier. Next, it extracts module dependency coordinates. The extraction logic involves parsing three types of information—organization identifier, module identifier, and version number—from the compilation configuration file or module definition node, concatenating them to form a standardized coordinate string. The generation expressions for the fully qualified class name and module dependency coordinates are as follows: and In the formula Indicates a fully qualified class name. Represents the complete package path string. Represents the class name string; Indicates the coordinates of module dependencies. Represents the organization identifier string, This represents the module identifier string. Represents the version number string.

[0022] After the core identifier extraction is completed, the compile-time annotation processor performs parsing and mapping binding of non-functional feature contract tags. The processor traverses the annotation nodes in the syntax tree of the key functional modules, identifies and extracts the structured declarative annotation content corresponding to the non-functional feature contract tags. These annotations define hardware dependency constraints in key-value pair form, such as minimum CPU instruction set, minimum memory capacity, GPU availability, minimum storage read / write speed, and minimum network bandwidth. During extraction, the validity of the key-value pair format is verified, and invalid tags with incorrect formats are removed. Subsequently, a one-to-one temporary mapping relationship is established between the extracted fully qualified class name, module dependency coordinates, and the corresponding valid non-functional feature contract tag key-value pairs. This mapping relationship is a two-way binding structure; constraint tags can be queried through module identifiers, and module identifiers can be associated with constraint tags. The set expression for the temporary mapping relationship is as follows: In the formula Represents a set of temporary mapping relationships. This represents a set of key-value pairs representing non-functional feature contract tags. This represents the set of fully qualified class names for key functional modules.

[0023] After establishing temporary mapping relationships, the compile-time annotation processor writes this set of relationships into its initialized internal state storage area. The write operation adopts an atomic write mechanism to avoid data corruption during multi-threaded parallel compilation. The internal state stores the mapping relationships in the form of a hash table, supporting subsequent fast lookup and data retrieval. The internal state is only valid during compilation and is not written to the source code bytecode file. After the compilation process is completed, the memory is automatically released when the annotation processor is unloaded. After completing the temporary mapping relationship record, the compile-time annotation processor completes all the core operations of the S2 stage. The generated internal state data provides direct data support for the subsequent generation of the tag list index file, laying the foundation for multi-dimensional constraint solving, conflict detection, and optimal module selection during the software runtime stage. At this point, the compile-time static processing flow of the software development stage is completed, realizing static scanning of key functional modules, metadata extraction, and constraint tag binding, ensuring the traceability and accuracy of subsequent adaptation processes.

[0024] After establishing temporary mapping relationships for key functional modules and storing internal states, the compile-time annotation processor continues to rely on the mapping data in the internal state to perform a full-process closing operation, including structured declarative annotation parsing, data entry serialization encoding, and tag list index file generation and distribution binding. This operation, as the core closing step of the S2 phase of software development, solidifies the module metadata and hardware constraint information collected during compilation into a standardized index file that can be distributed across platforms. This achieves a complete transformation of compile-time static information into runtime adaptation data, providing a basis for conflict detection and adaptation calculation by the multi-dimensional constraint solving rule engine during software runtime. The system provides structured input, including structured declarative annotations which are predefined compile-time custom annotations by developers. These annotations define non-functional prerequisites for key functional modules in the form of key-value pairs of attribute names and values. These non-functional prerequisites are the minimum hardware configuration requirements for the normal operation of key functional modules. Serializable data entries are structured data units that can be converted into byte streams and support cross-environment parsing. The tag manifest index file is a standardized index file that stores the metadata and constraint tag set of all key functional modules. The software package is a distributable installation package containing the runtime program and supporting resources, generated after the source code is compiled.

[0025] The compile-time annotation processor first reads the complete set of temporary mapping relationships from its own initialized internal state storage area. The reading process adopts a read-only access mode to avoid modifying the internal state data. At the same time, it performs data integrity verification to check whether there are problems such as missing key-value pairs, duplicate module identifiers, and abnormal constraint label formats in the temporary mapping relationship set. After the verification passes, the processor traverses each mapping record in the temporary mapping relationship set. Each mapping record corresponds to a key functional module. The traversal process adopts an iterative loop mechanism to ensure that all defined key functional modules are covered without omission.

[0026] When traversing to the mapping record corresponding to a single key functional module, the compile-time annotation processor extracts the structured declarative annotation identifiers bound in the record, backtracks to the syntax tree annotation node of that key functional module, locates and reads the complete content of the structured declarative annotation. The structured declarative annotation adopts a key-value pair format, with each attribute name corresponding to a hardware dependency constraint, and the attribute value being the minimum required value or enumeration identifier corresponding to the constraint. The processor parses all key-value pairs in the annotation line by line, performing format validity checks during the parsing process. The validation rules include compliance of the attribute name character set, matching of attribute value data type, and reasonable constraint value range. Key-value pairs with incorrect format or invalid logic are removed, and only valid non-functional pre-dependency condition key-value pairs are retained. After parsing, a set of valid constraint tags corresponding to a single key functional module is formed.

[0027] After parsing the constraint tags for a single module, the compile-time annotation processor performs serializable data entry encoding, integrating three types of core information into a unified format data entry. These three types of core information are the fully qualified class name of the key functional module, module dependency coordinates, and a set of valid non-functional prerequisite dependency key-value pairs. Encoding uses a custom binary serialization protocol. First, the fully qualified class name string is converted to a UTF-8 encoded byte array. Then, the module dependency coordinate string is converted to a UTF-8 encoded byte array. Next, the constraint tag key-value pair set is encoded into a byte sequence according to a fixed format: "attribute name byte length - attribute name byte - attribute value byte length - attribute value byte". Finally, the three byte data parts are concatenated in a preset order, and a data header and checksum marker are added to generate a complete serializable data entry. The logical expression for the data entry encoding is as follows: In the formula This represents the generated serializable data entry byte stream. This refers to the encoding function that converts a string or collection to a UTF-8 byte array. This indicates a byte data concatenation operation. Indicates the data header identifier byte field, This indicates the checksum identifier byte field.

[0028] After encoding a single data entry, the compiler annotation processor continues to traverse the temporary mapping set, repeatedly executing the annotation parsing and data entry encoding process until all serializable data entries corresponding to the key functional modules are generated. The processor then creates a tag list index file, using a lightweight key-value pair index format. The file path is fixed to a specified path under the package resource directory. The processor writes all serializable data entries line by line into the tag list index file according to the data entry generation order, storing one complete data entry per line. The writing process uses a streaming mechanism to avoid memory overflow. After writing is complete, the processor performs an integrity check on the index file. The check includes verifying that the number of data entries matches the number of key functional modules, that the check tail identifier of each data entry is valid, and that the file size meets the preset range. After the check passes, the tag list index file is generated.

[0029] After the tag manifest index file is generated, the compile-time annotation processor marks the index file as a necessary resource for the software package through compilation and packaging configuration instructions. In the subsequent software compilation and packaging stage, the packaging tool automatically copies the tag manifest index file to the specified resource directory of the software package and integrates it with the executable program, configuration files, dependency libraries, etc., to form a complete software package. This achieves the binding and distribution of the index file and the software package. When the software package is distributed, the tag manifest index file is transmitted to the target hardware platform along with the software package, providing data support for runtime adaptation when the software is first launched. At this point, the compile-time annotation scanning, parsing, encoding, file generation, and distribution binding process of step S2 in the software development stage is completed. This achieves the static solidification and cross-platform distribution of hardware constraint information of key functional modules, laying the data foundation for hardware fingerprint matching, module selection, and dynamic assembly in the subsequent software runtime stage. The entire process relies on compile-time static processing technology, has no runtime performance loss, standardizes the data format, and adapts to the distribution and adaptation needs of various heterogeneous hardware platforms.

[0030] After the tag list index file is distributed and bound with the software package, the various non-functional pre-dependency constraints defined in the structured declarative annotations become the core basis for matching runtime hardware fingerprints with key functional modules. These constraints are solidified in the annotations using a standardized key-value pair format, precisely limiting the minimum hardware configuration threshold required for the normal operation of key functional modules. This ensures that the corresponding optimized modules are loaded only on platforms that meet the hardware requirements, avoiding module malfunctions due to hardware incompatibility. The structured declarative annotations are developer-defined markers used only to carry hardware dependency constraint information for key functional modules. After parsing and data extraction during compilation, the annotations themselves do not participate in the runtime logic execution. Non-functional pre-dependency constraints are non-business-related mandatory conditions for the normal operation of key functional modules, not involving the core business logic of the software, but only relating to hardware resource adaptability. The minimum CPU instruction set extension constraint is a key functional module... The minimum level instruction set extension requirements that the CPU must support for efficient parallel computing and vector computation are defined by several constraints. The minimum memory capacity constraint is the minimum physical memory capacity required for critical functional modules to load business data and cache intermediate results during runtime. The existence constraint of a specific type of GPU is the requirement for critical functional modules to be equipped with a specified type of GPU for graphics rendering and large-scale parallel computing. The minimum sequential write rate constraint of persistent storage is the minimum sequential write speed requirement that persistent storage media must meet for critical functional modules to read and write large-volume business files and persist batch data. The minimum bandwidth constraint of the network interface is the minimum data transmission bandwidth requirement that the network interface must meet for critical functional modules to perform large-volume network communication and real-time data transmission. The key-value pair format is a standardized data format composed of a unique attribute name and a corresponding attribute value. It is used to accurately define the name and specific threshold of a single constraint item and is the basic organizational form for annotations to carry constraint information.

[0031] Structured declarative annotations are defined using Java annotation syntax or the compile-time annotation syntax of the corresponding programming language. Annotations are marked as compile-time active during declaration using meta-annotations, ensuring they are only recognized and processed by the annotation processor during the source code compilation phase. Each annotation defines five independent attributes, each corresponding to a non-functional pre-dependency constraint. The data type of the attribute is set according to the constraint characteristics. Attribute names use all-lowercase camelCase naming conventions to ensure uniqueness and readability. Attribute values ​​are specific thresholds or identifiers for the corresponding constraints. During compile-time annotation parsing, the annotation processor reads all attribute key-value pairs within the annotation one by one, performing format validation, value conversion, and validity checks. Invalid constraint definitions will directly trigger compilation errors, ensuring that the constraint data written to the tag list index file is valid and legal. Regarding the minimum instruction set extension constraint supported by the CPU, a dedicated attribute named `cpuMinIsaExt` is defined in the annotation. This attribute is set to a string type, and its value is a standardized instruction set extension enumeration string. Valid enumeration values ​​include SSE4.2, AVX, AVX2, AVX512, NEON, and ASIMD, corresponding to the instruction set extension versions supported by different CPU architectures. When defining the constraint, developers directly assign the target minimum instruction set extension enumeration value to this attribute based on the computational optimization requirements of key functional modules. For example, if a module requires AVX2 instruction set support, then assign AVX2. If a module has no specific instruction set requirement, this attribute is omitted, and it is considered as having no instruction set constraint by default. The logical expression for this constraint is as follows: In the formula This indicates the highest instruction set extension actually supported by the CPU of the target hardware platform. This indicates the CPU minimum instruction set extension constraint value defined in the annotation. When the compiler parses this constraint, it only checks whether the attribute value belongs to the preset valid enumeration set, without performing hardware matching checks. The matching logic is deferred to runtime. For the minimum memory capacity constraint, the annotation defines a specific attribute named `memMinSize`. This attribute is set to a string type, and its value supports two formats: the first is a numeric string with storage units, including valid units such as B, KB, MB, GB, and TB (e.g., 4GB, 8192MB); the second is a plain numeric string, with the default unit being bytes. When defining the constraint, developers set the minimum physical memory capacity threshold based on the peak memory usage of critical functional modules during runtime. For example, if the module's peak memory usage is 3.2GB, then a value of 4GB is assigned. Omitting this attribute is considered as having no memory capacity constraint. When the compiler parses this constraint, it automatically converts the attribute value to a uniform byte value. The conversion expression is: In the formula This indicates the minimum memory capacity in bytes after conversion. This represents the purely numeric portion of the attribute value. This represents the byte conversion factor corresponding to the storage unit. The processor also verifies whether the converted value is a positive integer; non-positive integers are directly considered invalid constraints. For constraints requiring a specific type of GPU, the annotation defines a dedicated attribute named `gpuRequiredType`. This attribute is set to a string type and has two valid values: a boolean string `true` or `false`, where `true` indicates a GPU is required and `false` indicates no GPU support is needed; and a GPU type enumeration string, with valid values ​​including NVIDIA, AMD, ARM-Mali, Imagination, etc., used to specify the specific manufacturer or architecture type of the required GPU. When defining constraints, modules without GPU dependencies omit this attribute; if GPU support is only required and no type is specified, `true` is assigned; if a specific type of GPU is required, the corresponding enumeration string is assigned. During compilation, when the annotation processor parses the constraint, it verifies whether the attribute value belongs to the preset set of valid values ​​to ensure the constraint identifier is valid. To constrain the minimum sequential write rate of persistent storage, a dedicated attribute named `storageMinSeqWrite` is defined in the annotation. This attribute is set to a string type, and its value is a numeric string with a rate unit. Valid units include B / s, KB / s, MB / s, and GB / s, such as 500MB / s and 1GB / s. When defining the constraint, developers set the minimum sequential write rate threshold for persistent storage media based on the speed requirements of batch data writing for key functional modules. Omitting this attribute is considered as having no storage rate constraint by default. When the compiler parses this constraint, it automatically converts the attribute value into a uniform number of bytes per second. The conversion expression is: In the formula This indicates the minimum sequential write rate of the converted persistent storage. This represents the purely numeric portion of the attribute value. This represents the byte conversion factor corresponding to the rate unit. The processor verifies whether the converted value is a positive integer to ensure the rate threshold is valid. Regarding the minimum bandwidth constraint for the network interface, a dedicated attribute named `netMinBandwidth` is defined in the annotation. This attribute is set to a string type, and the attribute value is a numeric string with the bandwidth unit. Valid units include bps, Kbps, Mbps, and Gbps, such as 100Mbps and 1Gbps. When defining the constraint, developers set the minimum bandwidth threshold for the network interface based on the network data transmission speed requirements of key functional modules. Omitting this attribute is considered as having no network bandwidth constraint by default. When the compiler parses this constraint, it automatically converts the attribute value to a uniform bits per second value. The conversion expression is: In the formula This indicates the minimum bandwidth of the network interface after conversion. This represents the purely numeric portion of the attribute value. This represents the bit conversion factor corresponding to the bandwidth unit. The processor verifies whether the converted value is a positive integer to ensure the bandwidth threshold is valid. In structured declarative annotations, the five types of constraint attributes are independently optional configurations. Developers can selectively declare some or all constraint attributes according to the actual hardware dependency requirements of key functional modules, without mandatory full definition. All declared constraint attributes have parallel logical relationships. At runtime, all declared constraints must be satisfied simultaneously for the key functional module to be determined as compatible with the target hardware platform. After the compiler annotation processor completes the parsing, verification, and value conversion of all constraint key-value pairs, it will match the set of valid constraint key-value pairs with the fully qualified class name and module of the key functional module. Block-dependent coordinate integration is encoded into serializable data entries and written to a tag list index file. After the index file is distributed to the target hardware platform along with the software package, when the software starts for the first time, the multidimensional constraint solving rule engine reads the constraint key-value pairs in the index file and compares them one by one with the hardware parameters in the hardware baseline capability fingerprint. It completes conflict detection and adaptation scoring, and selects the uniquely matching target functional module entry class. Thus, the entire adaptation process from hardware detection, fingerprint generation, compile-time annotation parsing, constraint definition, index file distribution to runtime matching is closed, ensuring that the software can dynamically load the optimal adaptation module on any heterogeneous hardware platform and achieve seamless compatibility across multiple hardware platforms.

[0032] After the software is distributed to the target hardware platform and the hardware baseline capability fingerprint is generated, the core conflict detection process of the multi-dimensional constraint solving rule engine is immediately initiated during the software runtime phase. This process, as a key pre-step of the adaptation model construction S3 step, is responsible for loading the tag list index file, resolving hardware capability vectors, comparing constraint dimensions, and initially screening compatible modules. This provides a foundation for compliant candidate modules for subsequent optimal adaptation scoring and ranking. The multi-dimensional constraint solving rule engine is the core rule execution component loaded at runtime, used to achieve automated matching and determination of hardware capabilities and module constraints. The tag list index file is a structured index file generated during compilation and distributed with the software package, storing all relevant information. The metadata and constraint information of the key functional modules are as follows: the hardware baseline capability fingerprint is a fixed-length hash identifier of the target hardware platform, corresponding to a unique sparse coefficient vector. The sparse coefficient vector is a low-dimensional sparse feature vector generated by the sparse coding algorithm. The hardware capability vector is the restored hardware parameter quantization vector that corresponds one-to-one with the constraint dimension. The non-functional characteristic contract label is a set of hardware constraint key-value pairs bound to the module. The constraint key-value pair is a combination of key-value pairs of the minimum hardware requirements in a single dimension. Dimension comparison is the numerical matching operation between the dimension value of the hardware capability vector and the constraint threshold. The incompatibility flag is the status identifier when the module does not meet any constraint. The set of compatible candidate modules is the summary of modules verified by all constraints. After the multidimensional constraint solving rule engine starts, it first completes its own initialization and the loading of the tag list index file. The initialization process includes creating three core data structures: a module storage hash table, a constraint dimension mapping table, and an incompatible tag list. It also sets up a data reading cache and an exception handling mechanism to ensure the stability and reliability of the loading and parsing process. After initialization, the engine locates the tag list index file in the package resource directory through the file system interface and loads the file content line by line using a streaming reading method. During the loading process, it verifies the integrity of the file format, the validity of the tail identifier of the data entry, and the matching of the data header identifier, filtering out damaged or invalid data entries. Subsequently, the engine performs deserialization and parsing operations on each valid data entry according to a custom binary serialization protocol, splitting and extracting the fully qualified class name, module dependency coordinates, and non-functional characteristic contract tag key-value pair set of each key functional module. The parsed module metadata and constraint information are stored in the initialized module storage hash table, establishing a fast query mapping relationship between module identifiers and constraint tags, and completing the full loading and parsing of the index file.

[0033] After loading the index file, the multidimensional constraint solving rule engine initiates the hardware baseline capability fingerprint parsing process. This process reverse-engineers the fixed-length hash value form of the hardware baseline capability fingerprint into a hardware capability vector that can be directly used for constraint comparison. The engine first retrieves the corresponding sparse coefficient vector generated by the sparse coding algorithm from its local cache based on the fingerprint hash value. This vector is a low-dimensional numerical sequence, with most elements being 0 and only a few non-zero elements corresponding to core hardware features. Then, the engine calls the reverse reconstruction interface of the sparse coding algorithm, loads a pre-trained overcomplete dictionary, and performs a linear reconstruction operation on the sparse coefficient vector to reconstruct the initial high-dimensional hardware feature vector. The mathematical expression for the high-dimensional feature vector reconstruction is as follows: In the formula This represents the reconstructed high-dimensional hardware feature vector. This represents a pre-trained, overcomplete dictionary matrix. This represents the sparse coefficient vector corresponding to the hardware fingerprint. After reconstruction, the engine performs dimension mapping and numerical normalization on the high-dimensional feature vector according to five constraint dimensions: CPU instruction set, memory capacity, GPU type, storage write speed, and network bandwidth. This compresses the high-dimensional vector into a hardware capability vector that corresponds one-to-one with the constraint dimensions. The mathematical expression for the hardware capability vector is: In the formula Represents a hardware capability vector. To extend the quantization value for the CPU instruction set, Quantification of memory capacity Match values ​​for GPU type. Quantization value for sequential write rate of storage, For network interface bandwidth quantization, each dimension's value is a standardized quantization value, which can be directly compared with constraint thresholds. After the hardware capability vector is generated, the multi-dimensional constraint solving rule engine initiates a full-module constraint comparison and compatibility filtering process. The engine traverses all parsed key functional modules in the module storage hash table, using a sequential iteration mechanism to read the non-functional characteristic contract tags bound to each individual key functional module, extracting all valid constraint key-value pairs within the tags. Each constraint key-value pair corresponds to a fixed dimension of the hardware capability vector. The engine establishes a one-to-one mapping relationship between constraint keys and hardware capability vector dimension indices to ensure accurate matching of comparison dimensions. The mapping relationship set expression is as follows: In the formula Represents a set of dimensional mapping relationships. to These correspond to five types of constraint key names, with numbers 1 to 5 corresponding to the hardware capability vector dimension index.

[0034] For each constraint key-value pair of a single key functional module, the multidimensional constraint solving rule engine extracts the constraint threshold and performs a numerical comparison operation with the quantized value of the corresponding dimension of the hardware capability vector. The comparison logic distinguishes between quantized numerical constraints and existence enumeration constraints. Four types of quantized constraints are defined: CPU instruction set, memory capacity, storage write speed, and network bandwidth. A numerical judgment is performed to determine if the "hardware dimension value ≥ constraint threshold," and the judgment expression is as follows: In the formula This represents the quantized value of the d-th dimension of the hardware capability vector. This represents the threshold for the corresponding constraint key-value pair. The GPU type existence constraint performs an enumeration matching judgment of the "hardware GPU type matching constraint requirement". A successful match is recorded as satisfying the constraint. If the hardware capability vector does not meet the minimum requirement of the corresponding constraint key-value pair in any dimension, the engine immediately marks the key functional module as incompatible and adds it to the incompatible mark list, terminates the remaining constraint comparison of the current module, and directly enters the verification process of the next module. After completing all constraint comparisons of a single module, if the module is not marked as incompatible, the engine adds it to the temporary compatible list. After traversing all key functional modules, the engine removes duplicate modules from the temporary compatible list. The deduplication rule is uniquely identified by the fully qualified class name. Finally, a set of compatible candidate modules without duplicates and passing all constraint verifications is generated. This set contains all key functional modules that can run normally on the current target hardware platform, providing compliant input for subsequent adaptation scoring and ranking. Thus, the multi-dimensional constraint solving rule engine completes the entire process of conflict detection and candidate module screening, effectively filtering hardware incompatible modules and ensuring the effectiveness of subsequent optimal module selection.

[0035] After completing the screening and deduplication of the compatible candidate module set, the multidimensional constraint solving rule engine immediately initiates the core process of adaptation quantification calculation and ordered sorting. This process, as a key scoring and sorting step in the S3 step of adaptability model construction, relies on standardized logic such as dimensional matching quantification, weighted summation to calculate the total score, and descending sorting to generate a list. It accurately quantifies the compatibility degree of each module with the target hardware platform from the compliant candidate modules, providing a quantifiable sorting basis for subsequent selection of the unique optimal module. The entire process is based on numerical comparison logic, with no subjective judgment steps, ensuring the objective and uniqueness of the sorting results. The compatible candidate module set is a summary of key functional modules that have been screened for conflict detection and satisfy all hardware constraints. The multidimensional constraint solving rule engine executes... The core rule components for matching calculation and sorting operations include: non-functional feature contract tags, which are sets of hardware constraint key-value pairs bound to modules; constraint recommendation values, which are recommended hardware configuration values ​​set by developers in annotations for optimal module operation, distinct from minimum requirement thresholds; hardware capability vectors, which are the restored quantified sequences of hardware parameters corresponding one-to-one with constraint dimensions; dimension actual values, which are the specific quantified values ​​of the corresponding dimensions in the hardware capability vector; matching degree, which is the quantified ratio of the hardware actual value to the constraint recommendation value; weighted summation, which is the calculation method for summarizing the matching degree of each dimension according to its weight; adaptation score, which is a comprehensive quantified value measuring the overall adaptation degree between the module and the hardware platform; and the module list, which is an ordered list of candidate modules generated by sorting according to the adaptation score.

[0036] The multi-dimensional constraint solving rule engine first completes the pre-initialization operation for adaptation calculation, loading the preset weight parameters for each constraint dimension from the local configuration file. These weight parameters are pre-set by the developers based on the module's functional characteristics and correspond one-to-one with five dimensions: CPU instruction set, memory capacity, GPU type, storage write speed, and network bandwidth. The total weight is fixed at 1, representing the priority of each hardware dimension's impact on the module's running performance. The expression for the weight parameter set is as follows: In the formula Represents the set of dimension weights. For CPU instruction set dimension weights, As weights for memory capacity dimension, For GPU type dimension weights, As a weight for the storage write rate dimension, As the weight for the network bandwidth dimension, after initialization, the engine uses a sequential traversal mechanism to traverse each candidate module in the set of compatible candidate modules. During the traversal, a temporary computing space is allocated independently for each module to store the matching degree, adaptability score and module identifier of each dimension, so as to avoid mutual interference of the computing data between modules.

[0037] When traversing to a single candidate module, the multi-dimensional constraint solving rule engine first reads the non-functional characteristic contract tags bound to that module, extracts the constraint recommendation values ​​corresponding to each constraint dimension in the tags, and defines the optimal hardware configuration values ​​for the module's operation in the annotations. These values ​​are distinct from the minimum requirement threshold and are only used for adapting quantization calculations, not for compatibility determination. The engine establishes a one-to-one mapping relationship between constraint recommendation values ​​and hardware capability vector dimensions, ensuring that each recommendation value corresponds to a unique dimension of the hardware capability vector. After mapping, the engine initiates a dimension-by-dimensional matching degree calculation operation. The matching degree calculation uses a proportional algorithm of dividing the actual value by the constraint recommendation value, and is only performed on quantization-type constraint dimensions. The GPU type dimension uses an enumerated matching degree assignment method. The mathematical expression for the matching degree calculation is as follows: In the formula This represents the matching degree of the k-th quantization dimension. This represents the actual quantized value of the k-th dimension of the hardware capability vector. This represents the recommended constraint value for that dimension. Since the candidate module has passed compatibility testing, the actual hardware value must be greater than or equal to the minimum constraint threshold, and the matching degree value must be greater than or equal to 1. When the GPU type dimension matches successfully, the matching degree is fixed at 1; if the matching fails, it has already been removed during the compatibility screening stage and does not need to participate in this calculation. After calculating the matching degree for all dimensions of a single candidate module, the multidimensional constraint solving rule engine performs a weighted summation operation to calculate the total fitness score. The weighted summation process multiplies the matching degree of each dimension by its corresponding dimension weight and then sums them up. The overall fitness level of the module is obtained by combining the fitness levels of each dimension. The mathematical expression for calculating the fitness score is: In the formula This represents the total fit score of the candidate modules. This represents the weight value corresponding to the k-th dimension. The matching degree corresponding to the k-th dimension is represented. The larger the matching degree score, the higher the degree of matching between the module and the target hardware platform, and the closer the performance is to the optimal level. The engine binds the calculated matching degree score with the fully qualified class name of the module and the module dependency coordinates and stores it in the temporary computing space to complete the matching degree calculation of a single candidate module.

[0038] The process of traversal, matching degree calculation, and weighted summation is repeated until the fitness scores of all candidate modules in the compatible candidate module set are calculated. Then, the multi-dimensional constraint solving rule engine initiates a sorting operation. The sorting algorithm uses a stable fast sorting algorithm, based on the fitness score, and sorts from high to low to ensure that modules with higher fitness scores are placed earlier. If modules with identical fitness scores are found during sorting, the engine performs a secondary sort based on the lexicographical order of their dependency coordinates to avoid ambiguity in the sorting results. After sorting, the engine integrates the ordered candidate modules, their corresponding fitness scores, fully qualified class names, and module dependency coordinates to generate a standardized module list. This module list is structured ordered data, with each row corresponding to one candidate module. The module, containing module identifiers and compatibility information, facilitates rapid subsequent reading and filtering. The entire matching calculation and sorting process is completed in the software runtime memory and is not written to persistent storage. After the calculation is completed, only the module list is retained for subsequent filtering. Temporary calculation data is automatically released from memory to avoid consuming hardware resources. Thus, the multi-dimensional constraint solving rule engine completes the entire process of matching quantification, compatibility calculation, and ordered sorting of compatible candidate modules. The generated module list provides an orderly, quantitative, and objective candidate basis for the accurate determination of the unique target functional module entry class. It realizes a complete runtime matching logic closed loop from hardware fingerprint parsing, constraint comparison, compatibility filtering to compatibility sorting, laying a solid foundation for the software to dynamically load the optimal compatible module for sorting and filtering.

[0039] After completing the quantitative sorting of compatible candidate modules and generating an ordered module list, the multidimensional constraint solving rule engine immediately initiates a precise selection process for the final unique target functional module entry class. This process, as the final step in the S3 step of adaptability model construction, uses a three-level progressive selection logic to lock in the unique, optimally adapted core module entry from the ordered module list. This provides a precise module location basis for the dynamic assembly in the subsequent S4 step. The entire selection logic is clearly hierarchical, with explicit judgment criteria and no ambiguity, ensuring a unique result is output in any scenario with the same score. The module list is sorted in descending order of adaptability and contains all candidate modules. The system is an ordered, structured list of modules, including class names, module dependency coordinates, fit scores, and matching data for each dimension. The preferred module is the candidate module with the highest fit score in the list. The specified dimension is the single, highest-priority hardware constraint dimension pre-defined by the developer in the rule engine configuration file; typically, it's a CPU instruction set extension dimension. The lexicographical order is based on a standard string sorting rule using ASCII encoding values, comparing characters one by one, with smaller values ​​ranking first. The target functional module entry class is the final, unique, and optimally suited entry point for the target hardware platform, possessing global uniqueness and optimal hardware compatibility. The multi-dimensional constraint solving rule engine first reads the complete ordered module list. The first row stores the candidate module data with the highest fit score. The engine directly extracts the relevant information for this first-row module, initially marking it as the preferred module, completing the first-level filtering. Then, the engine performs a tie-breaking operation. The logic is to traverse all entries in the module list, extract the fit scores of all candidate modules, and filter out all modules with fit scores exactly equal to those of the first-row module, generating a tie-breaking candidate subset. The expression for generating the tie-breaking candidate subset is: In the formula Denotes the candidate subsets with the same score. This represents an ordered list of modules. This represents the fit score of the candidate module (Mod). This represents the highest fit score in the module list. If the candidate subset with the same score contains only one module (i.e., no ties), that module is directly identified as the entry class for the target function module, and the filtering process ends immediately without further level verification. If the candidate subset with the same score contains two or more modules (i.e., multiple modules have the same and highest fit score), the engine immediately initiates a secondary filtering process, performing a second-order selection based on the matching degree of a specified dimension. The engine first reads the preset specified dimension identifier in the rule engine configuration file. This dimension is a predefined highest-priority hardware dimension, defaulting to the CPU instruction set extension dimension. Then, it iterates through all modules within the candidate subset with the same score, extracting the matching degree value of each module on the specified dimension. The matching degree value is a quantized ratio value generated in the previous fit calculation stage. The engine compares the extracted matching degree values ​​on the specified dimension, selecting the module with the highest matching degree value and generating a new high-fit candidate subset. The expression for generating the new candidate subset is: In the formula This represents a high-match candidate subset based on a specified dimension. This indicates the degree of matching of the candidate module (Mod) in the specified dimension. This indicates the highest matching degree in a specified dimension within the candidate subset with the same score. If the candidate subset with the highest matching degree contains only one module, that module is directly identified as the entry class of the target functional module, and the filtering process ends.

[0040] If the high-match candidate subset still contains two or more modules after the second-level screening (i.e., the fit score and the match score of the specified dimension are exactly the same), the engine initiates the third-level screening process. It performs the final sorting selection based on the overcomplete lexicographical order of the module dependency coordinates. The module dependency coordinates are standardized strings that uniquely identify the module, in the format of organization identifier: module identifier: version number. The engine extracts the dependency coordinate strings of all modules within the high-match candidate subset and sorts them according to the overcomplete lexicographical order rule. During sorting, it compares the ASCII code values ​​one by one starting from the first character of the string. Characters with smaller ASCII codes appear first in the sorted string. After sorting, the engine selects the first module in the sorted results. This module is the final and uniquely determined target functional module entry class. The logical expression for lexicographical order selection is as follows: In the formula This represents the entry class for the final target functional module. This represents a lexicographically complete sorting function. This indicates the operation of selecting the first element of the sorting result. After the target functional module entry class is determined, the multidimensional constraint solving rule engine extracts the fully qualified class name and module dependency coordinates of the module, encapsulates the two core identification information into location data and caches it in runtime memory. This location data will directly serve as the core retrieval basis for the dynamic orchestration and distribution of the S4 step server, realizing a complete runtime matching closed loop from hardware fingerprint parsing to optimal module location.

[0041] Once the unique target functional module entry class is determined, the software runtime phase immediately enters the final execution flow of server-side dynamic orchestration and delivery and client-side dynamic assembly. This flow, as the core implementation link of the S4 steps in building a software development model for adapting to multiple hardware platforms, relies on client-server collaborative communication, precise component retrieval, lightweight payload delivery, custom class loading, and runtime bytecode injection technologies to achieve on-demand loading of the optimal adapted functional module and dynamic assembly of software functions. This completes the full-link adaptation closed loop from hardware detection, fingerprint generation, constraint matching to module loading. The client software is a local software instance running on the target hardware platform, responsible for initiating component requests, receiving payload packets, and performing custom loading and function assembly operations. The server is a remote server node that centrally stores component resources, responds to client requests, and orchestrates and delivers payload packets. The module dependency coordinates uniquely identify the target functional module entry class. The standardized strings, the atomic component repository is a centralized structured repository on the server that pre-stores all key functional modules and their dependent lightweight components, the highly cohesive atomic payload package is a lightweight bytecode compressed package that only contains the target functional module entry class and its direct dependent classes, eliminating all redundant code and irrelevant resources, the custom class loader is a dedicated loading component developed by the client software that breaks through the system's default class loading limitations and supports dynamic loading of external bytecode and context injection, the runtime context is the core execution environment in the main program's runtime memory used to manage class definitions, object instances, resource references and execution status, bytecode injection is the operation of loading bytecode from the external payload package into the main program's runtime context so that it can be recognized, instantiated and called by the main program, and dynamic assembly is the final functional integration action of the main program loading the optimal adapted functional modules, integrating core business logic, and adapting to the current target hardware platform. The client software first extracts the module dependency coordinates corresponding to the entry class of the target functional module from the runtime memory cache. These coordinates are globally unique standardized identifier strings. Then, the client software initializes the network communication module and establishes a secure and encrypted network connection with the server. The communication protocol adopts a lightweight secure transmission protocol to ensure that the data is not tampered with or stolen during the data transmission process. After the connection is established, the client software encapsulates the module dependency coordinates into a standardized request message. The message contains four types of fields: request header, module dependency coordinates, client hardware identifier, and checksum. The checksum is used by the server to verify the integrity of the message. After encapsulation, the client software sends the request message to the server through the network and waits for the server's response and payload packet delivery.

[0042] The server continuously listens for network requests from clients. Upon receiving a request message from a client, it first parses the message and verifies the checksum. If the verification passes, it extracts the module dependency coordinates from the message. The server then calls the atomic component repository retrieval interface. The atomic component repository uses a hash index structure to store all component resources, with the index key being the module dependency coordinate and the index value corresponding to the bytecode storage path of the target module and its dependent classes. The retrieval logic involves precisely matching the module dependency coordinates, recursively traversing the dependency tree of the target functional module's entry class, filtering out only direct dependencies, and removing indirect dependencies, irrelevant resource files, and redundant configurations. After the retrieval is complete, the server aggregates the bytecode of the target functional module's entry class and the bytecode of all directly dependent classes, and uses a lightweight compression algorithm to package them into a highly cohesive atomic payload package. The logical expression for generating the payload package is as follows: In the formula This indicates the generated highly cohesive atomized payload package. This represents the bytecode collection of the target functional module's entry point class. This indicates a direct dependency on the class bytecode set. This represents a lightweight compression and packaging function that minimizes the payload size and eliminates redundant data.

[0043] After the highly cohesive atomized payload package is generated, the server initiates the payload package distribution process, employing a fragmented transmission and breakpoint resumption mechanism. The payload package is fragmented into fixed-size segments and distributed piecewise to avoid transmission failures due to network fluctuations. During the distribution process, transmission status messages are simultaneously sent to the client. After receiving all segments, the client reassembles them into a complete payload package according to the segment sequence number. Subsequently, the client software verifies the integrity and validity of the payload package. Verification methods include decompression verification, bytecode format verification, and digital signature verification. After successful verification, the client software calls a self-developed custom class loader. The custom class loader inherits from the system default class loader, overrides the core class loading methods, breaks through the system loading path restrictions, and supports loading external bytecode from local files. The class loader first decompresses the highly cohesive atomized payload package, reads all bytecode files within the package, and then calls the underlying bytecode conversion interface to convert the bytecode files into class definition objects that the virtual machine can recognize, completing bytecode parsing and conversion.

[0044] After bytecode conversion, the custom class loader performs bytecode injection, injecting the converted target functional module entry class and its directly dependent class definition objects into the runtime context of the current main program. The injection process is achieved by modifying the class definition registry of the runtime context, allowing the main program to directly recognize and reference the injected class definitions. After injection, the main program locates the target functional module entry class in the runtime context through a preset functional interface or reflection mechanism, performs class instantiation, and generates a functional module instance. Subsequently, the main program calls the core business method of this instance, initiating the execution of the corresponding functional logic, thus completing the dynamic assembly of the software's core functionality with the current target hardware platform. The assembly process does not require restarting the client main program and is completed entirely in runtime memory without persistent data writing, resulting in high loading efficiency and low resource consumption. At the same time, because the payload package only contains core modules and direct dependencies, the transmission size is small and the distribution speed is fast, adapting to various network environments and heterogeneous hardware platforms. At this point, the entire process of building a software development model that adapts to multiple hardware platforms is completed, realizing a complete technical closed loop from hardware low-level feature detection, capability fingerprint generation, compile-time constraint annotation parsing, runtime constraint matching, optimal module selection to dynamic loading and assembly. This ensures that the software can load the optimal adapted functional modules on any heterogeneous hardware platform, achieving the goal of seamless compatibility and optimal performance adaptation across multiple hardware platforms.

[0045] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A construction method of a software development model adapted to a multi-hardware platform, characterized by: Includes the following steps: S1. When the software is first launched on the target hardware platform, the hardware baseline detection daemon runs. The hardware baseline detection daemon collects multi-dimensional low-level physical feature parameters of the target hardware platform and uses a sparse coding algorithm to fuse the multi-dimensional low-level physical feature parameters locally to generate a hardware baseline capability fingerprint. S2. During the software development phase, the compiler-time annotation processor is used to scan the key functional modules in the code and extract the non-functional feature contract tags that are pre-embedded by the developer in the form of structured declarative annotations into the tag list index file. The non-functional feature contract tags are used to declare the non-functional pre-dependencies of the corresponding module on the target hardware platform. S3. After the software starts and completes the generation of the hardware baseline capability fingerprint, it loads the tag list index file and uses a multi-dimensional constraint solving rule engine to perform conflict detection and optimal fit scoring and sorting of the non-functional characteristic contract tags declared by each key functional module and the hardware baseline capability fingerprint currently generated by the target hardware platform, so as to filter out the target functional module entry class that uniquely matches the target hardware platform. S4. Based on the target functional module entry class, the server uses a dynamic orchestration and distribution mechanism to extract only the highly cohesive atomized payload package associated with the target functional module entry class and inject it into the main program runtime context to complete dynamic assembly.

2. The method of claim 1, wherein the software development model is adapted to a plurality of hardware platforms. The hardware baseline detection daemon calls the operating system kernel interface and hardware abstraction layer interface of the target hardware platform to sequentially collect and encapsulate CPU instruction set architecture, number of cores, cache level and capacity, total memory capacity and bandwidth, type and read / write speed of persistent storage medium, number of GPU rendering pipelines and number of shader units, and type and version of peripheral interfaces as multi-dimensional low-level physical feature parameters, and temporarily stores the multi-dimensional low-level physical feature parameters in the process memory buffer as a key-value pair data structure.

3. The method of claim 2, wherein the software development model is adapted to a plurality of hardware platforms. The hardware baseline capability fingerprint is generated locally by fusing the multi-dimensional low-level physical feature parameters using a sparse coding algorithm, specifically as follows: The key-value pair data structure is read from the buffer, and the value of each dimension parameter is normalized to a common scale. All normalized values ​​are concatenated into a high-dimensional vector in a predetermined order. The sparse coding algorithm performs linear decomposition on the high-dimensional vector through a pre-trained overcomplete dictionary, and the high-dimensional vector is represented as a linear combination of atoms in the overcomplete dictionary to obtain a sparse coefficient vector. Finally, the sparse coefficient vector is serialized and hashed to obtain a fixed-length hash value. The fixed-length hash value is the hardware baseline capability fingerprint that characterizes the comprehensive capabilities of the target hardware platform.

4. The method of claim 1, wherein the software development model is adapted to a plurality of hardware platforms. The compiler uses a compile-time annotation processor to scan key functional modules in the code, specifically: During source code compilation, the compile-time annotation processor traverses all classes and methods annotated with specific annotations. The key functional modules are defined as different hardware platform optimized versions that implement the same functional interface. The compile-time annotation processor parses the syntax tree of each key functional module, identifies its fully qualified class name and the module dependency coordinates, and establishes a temporary mapping relationship with the non-functional feature contract tags in the module code, which is recorded in the internal state of the compile-time annotation processor.

5. The method for constructing a software development model adaptable to multiple hardware platforms according to claim 4, characterized in that: The non-functional feature contract tags pre-embedded by developers using structured declarative annotations are extracted into the tag manifest index file, specifically: The compile-time annotation processor parses the content of all structured declarative annotations declared by each key functional module based on the temporary mapping relationship recorded in the internal state. The structured declarative annotations define non-functional pre-dependencies in the form of key-value pairs of attribute names and attribute values. The compile-time annotation processor encodes the key-value pair content together with the fully qualified class name of the key functional module and the module dependency coordinates into a serializable data entry, and writes the set of data entries corresponding to all key functional modules into the tag manifest index file. The tag manifest index file is distributed with the software package after compilation.

6. The method for constructing a software development model adaptable to multiple hardware platforms according to claim 5, characterized in that: The non-functional feature contract tag is used to declare the non-functional pre-dependencies of the corresponding module to the target hardware platform, and the non-functional pre-dependencies include: The constraints on the minimum instruction set extensions supported by the CPU, the minimum memory capacity, whether a specific type of GPU is required, the minimum sequential write rate of persistent storage, and the minimum bandwidth of the network interface are all defined in the structured declarative annotation as key-value pairs of attribute names and attribute values.

7. The method for constructing a software development model adaptable to multiple hardware platforms according to claim 6, characterized in that: The multi-dimensional constraint solving rule engine performs conflict detection between the non-functional characteristic contract tags declared by each key functional module and the hardware baseline capability fingerprint currently generated by the target hardware platform. Specifically: The multidimensional constraint solving rule engine loads the tag list index file and parses the hardware capability vector implied by the sparse coefficient vector corresponding to the hardware baseline capability fingerprint. For each key functional module, the multidimensional constraint solving rule engine reads the constraint key-value pairs defined in its non-functional characteristic contract tag and compares each constraint key-value pair with the corresponding dimension in the hardware capability vector. If the quantization value of the hardware capability vector in any dimension does not meet the minimum requirement declared by the constraint key-value pair, the key functional module is marked as incompatible. This process traverses all key functional modules and filters out all compatible candidate module sets.

8. The method for constructing a software development model adaptable to multiple hardware platforms according to claim 7, characterized in that: In the set of compatible candidate modules, for each candidate module, the multidimensional constraint solving rule engine calculates the matching degree between the recommended constraint values ​​declared in its non-functional characteristic contract tag and the actual values ​​of the corresponding dimensions in the hardware capability vector. The matching degree is calculated as the ratio of the actual value to the recommended constraint value. The ratios of all dimensions are weighted and summed to obtain the total fit score. The multidimensional constraint solving rule engine sorts all candidate modules from high to low according to the fit score and generates a module list.

9. The method for constructing a software development model adaptable to multiple hardware platforms according to claim 8, characterized in that: The entry class of the target functional module that uniquely matches the target hardware platform is selected, specifically as follows: The module with the highest fit score is selected from the module list as the preferred module. If multiple modules have the same and highest fit score, the matching degree of the multiple modules on a specified dimension of the hardware capability vector is further compared, and the module with the highest matching degree on the specified dimension is selected. If they are still the same, the final selection is made according to the lexicographical order of the module dependency coordinates to determine the unique target function module entry class.

10. The method for constructing a software development model adaptable to multiple hardware platforms according to claim 9, characterized in that: The server-side dynamic orchestration and distribution mechanism extracts only the highly cohesive atomized payload packages associated with the target functional module's entry class and injects them into the main program's runtime context to complete dynamic assembly. Specifically: The client software sends the module dependency coordinates of the target functional module entry class to the server. The server retrieves a high-cohesion atomic payload package containing only the target functional module entry class and its direct dependent classes from the pre-stored atomic component repository based on the module dependency coordinates. The server then sends the high-cohesion atomic payload package to the client via the network. During runtime, the client receives and loads the high-cohesion atomic payload package through a custom class loader and injects the bytecode into the runtime context of the current main program. This bytecode is used to instantiate and call the target functional module entry class by the main program, thereby realizing the dynamic assembly of software functions with the current hardware platform.

Images