Application deployment method and system based on swan gap equipment and storage medium

Abstract

The invention relates to an application deployment method and system based on a swan gap device and a storage medium, and the method comprises the steps: responding to an application deployment task, and recognizing a target swan gap device cluster and a target application; obtaining an installation package, and extracting component composition information and a demand information set; creating a shared data object and acquiring running state data; constructing a dynamic deployment portrait, performing matching analysis on the dynamic deployment portrait and the deployment strategy knowledge base, and generating a deployment arrangement scheme; analyzing the deployment arrangement scheme into a plurality of atomization tasks, and distributing the atomization tasks to a plurality of target devices for cooperative execution; in conclusion, by dynamically acquiring the running state data of the equipment cluster, constructing the deployment portrait and generating the optimal deployment scheme, the method can effectively adapt to a multi-equipment linkage scene in the Yang Mongolia ecology, and by dynamically sensing the state of the equipment cluster and intelligently optimizing the deployment strategy, the deployment failure rate is remarkably reduced, the debugging time is shortened, and the debugging efficiency is improved. And the resource utilization efficiency and the communication performance are improved.

Description

Technical Field

[0001] This application relates to the technical field of computer technology, and in particular to an application deployment method, system and storage medium based on HarmonyOS devices. Background Technology

[0002] With the deepening of the era of the Internet of Everything, the trend of diversification and fragmentation of smart terminal devices is becoming increasingly prominent. Huawei's HarmonyOS, as a distributed operating platform for all scenarios, aims to provide a unified and collaborative operating experience for devices with different capabilities. However, this diversity of devices also brings severe challenges to the widespread deployment of applications.

[0003] Existing deployment methods mostly remain in isolated installation mode for single device types, making it difficult to adapt to the complex scenarios of multi-device collaboration within the HarmonyOS ecosystem. Specifically, the deployment process lacks a deep awareness mechanism for the real-time operating status of the target device cluster. For example, it cannot dynamically monitor network latency, bandwidth fluctuations, and resource load between devices, making it difficult to predict compatibility risks caused by inconsistent system interface versions, hardware performance bottlenecks, or missing dependent components before installation. This results in a high deployment failure rate and lengthy repeated debugging. At the same time, existing technologies fail to establish a global optimization perspective for device clusters. They neither treat distributed application components as an organic whole for unified planning nor have the ability to intelligently schedule the interaction needs between devices. For example, in cross-device collaboration scenarios such as video conferencing, it is impossible to dynamically adjust the deployment strategy of components between devices based on component communication timing, data transmission volume, and latency sensitivity requirements, leading to problems such as unbalanced resource allocation and low communication efficiency.

[0004] These limitations not only make the application deployment process cumbersome and redundant, but also severely restrict the release of the potential of the HarmonyOS distributed architecture, resulting in a fragmented user experience when switching between multiple devices and significantly hindering the promotion efficiency of the application ecosystem. Summary of the Invention

[0005] To address the aforementioned shortcomings, this application provides an application deployment method, system, and storage medium based on HarmonyOS devices.

[0006] The above-mentioned objective of this application is achieved through the following technical solution: A method for deploying applications based on HarmonyOS devices, comprising the following steps: In response to application deployment tasks, identify the target HarmonyOS device cluster and the target application corresponding to the application deployment task; Obtain the current version installation package of the target application, and extract component composition information and requirement information set, the requirement information set including resource requirement information and cross-device requirement information; Create a shared data object in the target HarmonyOS device cluster, determine key status indicators based on the requirement information set, and obtain the operating status data of the target HarmonyOS device cluster through the shared data object; A dynamic deployment profile is built based on component composition information, requirement information set, and operational status data; The dynamic deployment profile is matched and analyzed with a pre-built deployment strategy knowledge base, and a deployment orchestration scheme is generated based on the matching analysis results. The deployment orchestration scheme is parsed into several atomic tasks, and the atomic tasks are distributed to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling.

[0007] The second objective of this invention is achieved through the following technical solution: An application deployment system based on HarmonyOS devices includes: The target identification module is used to identify the target HarmonyOS device cluster and target application corresponding to the application deployment task in response to the application deployment task. The information extraction module is used to obtain the current version installation package of the target application and extract component composition information and requirement information set, wherein the requirement information set includes resource requirement information and cross-device requirement information. The data acquisition module is used to create shared data objects in the target HarmonyOS device cluster, determine key status indicators based on the demand information set, and acquire the operating status data of the target HarmonyOS device cluster through the shared data objects. The profile building module is used to build dynamic deployment profiles based on component composition information, requirement information sets, and runtime status data. The solution generation module is used to match and analyze the dynamic deployment profile with the pre-built deployment strategy knowledge base, and generate a deployment orchestration solution based on the matching analysis results. The task distribution module is used to parse the deployment orchestration scheme into several atomic tasks, and distribute the atomic tasks to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling.

[0008] This application also relates to a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described application deployment method based on HarmonyOS devices.

[0009] In summary, the application deployment method, system, and storage medium provided in this application, based on HarmonyOS devices, can effectively adapt to scenarios with multiple devices working together in the HarmonyOS ecosystem by dynamically acquiring device cluster operation status data, constructing deployment profiles, and intelligently matching strategies to generate optimized deployment schemes. By dynamically sensing the device cluster status and intelligently optimizing deployment strategies, it can significantly reduce deployment failure rate, shorten debugging time, and improve resource utilization efficiency and communication performance. Attached Figure Description

[0010] Figure 1 This is a flowchart of an embodiment of an application deployment method based on HarmonyOS devices according to this application; Figure 2 This is a flowchart of step S10 in an embodiment of an application deployment method based on HarmonyOS devices according to this application; Figure 3 This is a flowchart of step S30 in an embodiment of an application deployment method based on HarmonyOS devices according to this application. Detailed Implementation

[0011] The following is in conjunction with the appendix Figures 1-3 This application will be described in further detail.

[0012] In one embodiment, this application discloses an application deployment method based on HarmonyOS devices, such as... Figure 1 As shown, the specific steps include the following: S10: In response to an application deployment task, identify the target HarmonyOS device cluster and the target application corresponding to the application deployment task; In this embodiment, an application deployment task refers to a set of instructions initiated by the user or system to install, configure, and run a specific application on one or more HarmonyOS devices. The task typically includes the identifier of the target application and the desired deployment environment information. The target HarmonyOS device cluster refers to a logical or physical set of multiple HarmonyOS operating system devices corresponding to the application deployment task. These devices can work collaboratively and share resources through HarmonyOS distributed capabilities. Devices within the target HarmonyOS device cluster can have different hardware capabilities and network connection statuses. The target application refers to the specific application that needs to be deployed to the target HarmonyOS device cluster corresponding to the deployment task. The target application typically exists in the form of an installation package and contains various components and resources required for its operation.

[0013] S20: Obtain the current version installation package of the target application, and extract component composition information and requirement information set, wherein the requirement information set includes resource requirement information and cross-device requirement information; In this embodiment, component composition information refers to the structured description of the target application, including which functional modules, services, library files, and other components the application consists of, as well as the dependencies and interaction methods between these components; the requirement information set refers to the requirements of the target application for system resources and cross-device collaboration capabilities during operation; wherein, the requirement information set includes resource requirement information and cross-device requirement information. The resource requirement information describes the application's requirements for hardware resources such as CPU, memory, storage, and network bandwidth; the cross-device requirement information describes the application's requirements for inter-device communication, data synchronization, and task collaboration in a distributed scenario.

[0014] S30: Create a shared data object in the target HarmonyOS device cluster, determine key status indicators based on the demand information set, and obtain the operating status data of the target HarmonyOS device cluster through the shared data object; In this embodiment, a shared data object refers to a distributed data structure created in the HarmonyOS device cluster, allowing multiple devices to perform read and write operations on it, thereby achieving real-time sharing and synchronization of status information between devices. The shared data object can be configured to store specific types of data. Key status indicators refer to important parameters used to evaluate the operating status of the HarmonyOS device cluster or individual devices within it. Key status indicators include device load, performance, network quality, etc., and are important bases for deployment decisions. Operating status data refers to the current operating status information of each device in the HarmonyOS device cluster collected in real time through shared data objects or other mechanisms, including but not limited to CPU utilization, memory usage, network latency, bandwidth, battery level, etc.

[0015] S40: Build a dynamic deployment profile based on component composition information, requirement information set, and runtime status data; In this embodiment, the dynamic deployment profile refers to a multi-dimensional, real-time updated description of the deployment environment, which is comprehensively constructed based on the component composition information, requirement information set, and operating status data of the target application's HarmonyOS device cluster. The dynamic deployment profile is used to guide deployment decisions and ensure that the application runs in the best state.

[0016] S50: Match and analyze the dynamic deployment profile with the pre-built deployment strategy knowledge base, and generate a deployment orchestration scheme based on the matching analysis results; In this embodiment, the deployment strategy knowledge base refers to a collection of pre-built and stored deployment rules, optimization algorithms, and best practices. The deployment strategy knowledge base contains deployment strategies for different application types, device environments, and performance goals, which are used to match dynamic deployment profiles and generate specific deployment schemes. The deployment orchestration scheme refers to a specific plan generated based on the matching and analysis results of the dynamic deployment profile and the deployment strategy knowledge base. It describes in detail how application components are allocated to target devices, how resources are configured, and how tasks are scheduled, aiming to optimize the overall performance and user experience of the application.

[0017] S60: The deployment orchestration scheme is parsed into several atomic tasks, and the atomic tasks are distributed to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling.

[0018] In this embodiment, an atomic task refers to the smallest granularity executable task unit obtained after the deployment orchestration scheme is further refined and decomposed. Each atomic task usually corresponds to a specific deployment operation, such as installing a component, configuring a service, or starting a process. HarmonyOS distributed task scheduling refers to a distributed capability provided by the HarmonyOS operating system, which can intelligently distribute atomic tasks to different devices in the cluster and coordinate these devices to perform tasks together, so as to realize the distributed deployment and operation of applications.

[0019] Specifically, this embodiment provides an application deployment method based on HarmonyOS devices, which enables intelligent and efficient deployment of applications in multi-device environments.

[0020] First, as described in step S10, in response to the application deployment task, the target HarmonyOS device cluster and the target application corresponding to the application deployment task are identified. Specifically, when an application deployment task is received, the target of the task needs to be clearly defined. For example, a target application can be automatically recommended based on preset rules, such as application type or user preferences, and the user is required to manually confirm the target HarmonyOS device cluster. Alternatively, the application deployment task can directly contain the identifier of the target application and a list of target devices, which can be identified by directly reading this information.

[0021] Further, as described in step S20, the current version installation package of the target application is obtained, and component composition information and requirement information set are extracted. This requirement information set includes resource requirement information and cross-device requirement information. For example, the latest version installation package of the target application can be downloaded from local storage or a pre-set application store server. The component composition information and requirement information set of this installation package can be manually configured by the developer and embedded into the metadata of the installation package during application packaging. Alternatively, the installation package of the target application can be obtained from the application management platform via an API interface. The component composition information and requirement information set can be stored in a separate configuration file and downloaded separately after obtaining the installation package. Furthermore, the installation package can also be obtained from a specified file server via a file transfer protocol, and the component composition information and requirement information set can be manually entered into the deployment system after analyzing the contents of the installation package.

[0022] Further, as described in step S30, a shared data object is created in the target HarmonyOS device cluster. Key status indicators are determined based on the demand information set, and the operational status data of the target HarmonyOS device cluster is obtained through the shared data object. Specifically, an agent program can be deployed on each device in the target HarmonyOS device cluster. This agent program periodically reports the device's operational status data (such as CPU load and memory usage) to a centralized shared data object. Key status indicators can be predefined as a set of fixed parameters. Alternatively, a master device can be selected in the cluster to create and maintain the shared data object. Other devices send their respective operational status data to the master device through point-to-point communication, and the master device updates the shared data object. Key status indicators can be manually configured according to the application type. In addition, multiple independent shared data objects can be created in the cluster. Each object is responsible for collecting operational status data of specific types or specific regions of devices. Key status indicators can be selected based on rules of thumb.

[0023] Further, as described in step S40, a dynamic deployment profile is constructed based on component composition information, requirement information set, and operational status data. For example, component composition information, requirement information set, and operational status data can be aggregated into a single data structure to form a deployment profile. Alternatively, the above information can be input into a predefined template to generate a structured deployment profile, which may include fields such as device capabilities, application requirements, and component dependencies. In addition, the collected data can be preliminarily processed, such as averaging the operational status data, and then the processed data can be combined into a deployment profile.

[0024] Further, as described in step S50, the dynamic deployment profile is matched and analyzed with the pre-built deployment strategy knowledge base, and a deployment orchestration scheme is generated based on the matching analysis results. Specifically, a preset strategy that perfectly matches the device type and application requirements in the dynamic deployment profile can be found in the deployment strategy knowledge base, and this strategy can be directly adopted as the deployment orchestration scheme. Alternatively, the key features in the dynamic deployment profile can be compared one by one with the rules in the deployment strategy knowledge base. If the conditions of a certain rule are met, the deployment action corresponding to that rule is executed, and the deployment orchestration scheme is gradually built. In addition, the information in the dynamic deployment profile can be used as a query condition to retrieve all relevant deployment templates in the deployment strategy knowledge base, and then the most suitable template can be selected as the deployment orchestration scheme.

[0025] Finally, as described in step S60, the deployment orchestration scheme is parsed into several atomic tasks, and these atomic tasks are distributed to several target devices in the target HarmonyOS device cluster for collaborative execution via HarmonyOS distributed task scheduling. For example, the deployment orchestration scheme can be broken down into a series of atomic tasks such as installation, configuration, and startup. These atomic tasks are distributed to the target devices through a message queue and executed by the devices in the order they are received. Alternatively, the deployment orchestration scheme can be automatically decomposed into atomic tasks according to preset general task splitting rules. These atomic tasks are distributed through the HarmonyOS distributed task scheduling service, which performs simple load balancing based on the available resources of the devices. In addition, the deployment orchestration scheme can also be parsed into a script file containing a series of commands, each command corresponding to an atomic task. The script runs on the target devices through a remote execution mechanism and is interpreted and executed by the devices themselves.

[0026] For example, suppose user A wants to deploy an application called "Smart Home Control Center" in their smart home environment. This application aims to manage multiple smart devices through a main control interface and achieve collaborative control between devices. First, when receiving the "Smart Home Control Center" application deployment task initiated by user A, the system responds by identifying the target application as "Smart Home Control Center" and, based on user A's configuration or system auto-discovery, determines that the target HarmonyOS device cluster includes smart screen A, smart speaker B, and smartwatch C. It then obtains the current version installation package of the "Smart Home Control Center" application and extracts the application's component composition information from the installation package, such as "main control interface module," "voice recognition module," and "device linkage module." Simultaneously, it extracts a set of requirements information, where resource requirements may indicate that the "main control interface module" requires high screen resolution and computing power, and the "voice recognition module" requires high screen resolution and computing power. The "module" requires a microphone and a certain amount of processing power, while the "device linkage module" requires a stable network connection. Cross-device requirements may indicate high-frequency communication between the "main control interface module" and the "voice recognition module," which is sensitive to latency. Subsequently, in order to obtain the operating status data of the target HarmonyOS device cluster, a shared data object is created between smart screen A, smart speaker B, and smartwatch C. Based on the previously extracted requirement information set, key status indicators that need to be monitored are determined, such as the CPU load and memory usage of smart screen A, the network bandwidth and communication latency of smart speaker B, and the battery level and available storage space of smartwatch C. Through this shared data object, the data is acquired and synchronized in real time. The system uses operational status data from screen A, smart speaker B, and smartwatch C. For example, smart screen A's CPU load is currently 70%, smart speaker B's network latency is 50ms, and smartwatch C has 2GB of available storage. Based on this information, a dynamic deployment profile is constructed. This profile integrates the component composition information of the "Smart Home Control Center" application, its resource and cross-device collaboration requirements, and the real-time operational status data of smart screen A, smart speaker B, and smartwatch C. For example, the dynamic deployment profile might show that the "Main Control Interface Module" is suitable for deployment on smart screen A, but smart screen A's current load is high; the "Voice Recognition Module" can be deployed on smart speaker B. However, the communication latency between it and smart screen A needs to be optimized. Then, the constructed dynamic deployment profile is matched and analyzed with the pre-built deployment strategy knowledge base. The deployment strategy knowledge base may contain strategies such as "prioritizing the unloading of non-core components on high-load devices" and "deploying components with low-latency communication requirements on physically nearby devices". Through matching analysis, the deployment strategy most suitable for the current environment is identified, and a deployment orchestration scheme is generated based on this. This deployment orchestration scheme may suggest deploying the "main control interface module" on smart screen A, the "voice recognition module" on smart speaker B, and the "device linkage module" on smart screen A, while optimizing the communication path between smart screen A and smart speaker B.Finally, the deployment orchestration scheme is broken down into several atomic tasks, such as "installing the main control interface module on smart screen A," "installing the voice recognition module on smart speaker B," and "configuring the communication channel between smart screen A and smart speaker B." These atomic tasks are distributed to smart screen A and smart speaker B for collaborative execution through HarmonyOS distributed task scheduling service. Thus, user A's "smart home control center" application can be deployed efficiently and intelligently in a multi-device environment, achieving seamless collaboration between the devices.

[0027] To address the lack of refined real-time status perception and automated assessment of target devices in existing technologies, this embodiment creates a shared data object within the target HarmonyOS device cluster and determines key status indicators based on a set of requirement information, acquiring and synchronizing operational status data in real time. In the example, information such as the CPU load of smart screen A and the network latency of smart speaker N are acquired in real time and incorporated into the construction of a dynamic deployment profile. Compared to the isolated and static device status assessments in existing technologies, this embodiment can dynamically perceive the operational status of the device cluster, thereby providing real-time and accurate data for subsequent deployment decisions and effectively avoiding deployment failures or performance issues caused by mismatched device statuses.

[0028] Furthermore, addressing the lack of a holistic perspective and collaborative scheduling capabilities for device clusters in existing technologies, this embodiment acquires component composition information and cross-device requirement information for the target application, and constructs a dynamic deployment profile by combining real-time operational status data. This dynamic deployment profile comprehensively reflects the application's needs in a distributed environment and the actual capabilities of the device cluster. In this example, the dynamic deployment profile not only considers the resource requirements of individual devices but also analyzes the low-latency communication requirements between the "main control interface module" and the "speech recognition module." By matching and analyzing this dynamic deployment profile with a pre-built deployment strategy knowledge base, an optimized deployment orchestration scheme is generated, such as deploying specific components to the most suitable devices and optimizing communication paths between devices. Finally, the deployment orchestration scheme is parsed into atomic tasks and collaboratively executed through HarmonyOS distributed task scheduling. This holistic profile construction, strategy matching, and distributed scheduling mechanism enables applications to be deployed and resource-configured intelligently across multiple devices, fully releasing the distributed potential of the HarmonyOS system, achieving a seamless cross-device experience, and overcoming the shortcomings of cumbersome deployment processes and limitations on distributed capability release in existing technologies.

[0029] In some of the embodiments described above in this application, steps are proposed to identify the target HarmonyOS device cluster and the target application corresponding to the application deployment task. However, in the actual application deployment process, how to efficiently and accurately select the device cluster most suitable for the specific application deployment needs from a large number of available devices to ensure application performance and resource utilization is a problem that needs to be solved.

[0030] In this regard, this application further proposes that, in one embodiment, as Figure 2 As shown, step S10 includes: S11: Parse and extract the metadata of the application deployment task, the metadata including the target application identifier and the device tag set; In this embodiment, parsing and extracting the metadata of the application deployment task refers to obtaining information describing the task itself from the application deployment task. In this embodiment, metadata specifically refers to information describing the application deployment task itself, and its function is to provide a basis for identifying the target application and initially screening devices. For example, structured data containing the target application identifier (such as the application's unique ID and package name) and a set of device tags (such as device type, physical location, performance level, etc.) can be parsed out through API interfaces or configuration files; or, the target application identifier and the set of device tags can be extracted in a structured manner from the request message body by listening to deployment requests in a specific message queue.

[0031] S12: Based on the set of device tags, filter out a set of candidate devices from the currently available HarmonyOS device network; In this embodiment, selecting a candidate device set from the currently available HarmonyOS device network based on the device tag set refers to selecting a set of potentially available devices based on preliminary conditions. The candidate device set, selected based on preliminary conditions, serves to narrow down the range of device selections and improve subsequent screening efficiency. For example, a HarmonyOS device registration center can be maintained, recording the tag information of all online devices. A matching query is performed in the registration center based on the device tag set in the application deployment task metadata, adding all devices that meet the tag conditions to the candidate device set. Alternatively, a query request can be broadcast to the entire HarmonyOS device network through a distributed device management service, allowing all devices to compare their own tags with the device tag set in the request, with eligible devices responding and joining the candidate device set.

[0032] S13: Obtain the network topology and physical proximity relationships of all candidate devices in the candidate device set, and assign network quality weights and physical proximity weights based on cross-device requirement information; In this embodiment, obtaining the network topology and physical proximity relationships of all candidate devices within the candidate device set, and assigning network quality weights and physical proximity weights based on cross-device requirement information, refers to evaluating the communication performance and collaborative efficiency between devices, providing a basis for refined screening. Network topology relationships refer to the network connection quality between devices, including communication latency, bandwidth, and stability, describing the connection method and path between devices. Physical proximity relationships refer to the relative positions and distances of devices in real physical space, describing the geographical or spatial proximity between devices. Network quality weights and physical proximity weights are indicators that measure the importance of connection quality and physical distance between devices. For example, network topology relationships can be obtained through network probing between devices (such as ping, traceroute) or from the network management system. Physical proximity can be obtained through GPS positioning, Bluetooth ranging, or preset physical area division. Cross-device demand information (such as low-latency communication and high-bandwidth transmission) can be used to guide the allocation of network quality weights (such as latency, bandwidth, and packet loss rate) and physical proximity weights (such as distance and obstacles). For example, latency-sensitive applications will be given higher priority for network quality weights. Alternatively, devices periodically report their network connection status and location information to the central management platform. The central management platform constructs a network topology map and physical location map between devices based on this information. When there is cross-device demand information, the central management platform dynamically calculates and allocates corresponding weights according to preset rules. For example, if the demand is for high real-time interaction, the network quality weight is higher; if the demand is for local data sharing, the physical proximity weight is higher.

[0033] S14: Based on network quality weights and physical proximity weights, select several target devices from the candidate device set and form a target HarmonyOS device cluster.

[0034] In this embodiment, based on network quality weights and physical proximity weights, several target devices are selected from the candidate device set to form a target HarmonyOS device cluster. This refers to the final set of devices selected for application deployment. The target HarmonyOS device cluster is the final set of devices selected for application deployment, and its role is to ensure that the selected cluster optimally meets the application deployment requirements, improves application performance and user experience. For example, network quality weights and physical proximity weights can be comprehensively considered to score the devices in the candidate device set. Alternatively, a comprehensive scoring function can be designed, taking network quality weights and physical proximity weights as inputs and combining them with the application's sensitivity to these factors for weighted summation, selecting the devices with the highest scores to form the target HarmonyOS device cluster. Or, graph algorithms (such as minimum spanning tree, community detection algorithm) combined with weight information can be used to find a subgraph of devices in the candidate device set that are closely connected, physically adjacent, and meet the specific requirements of the application. The devices in this subgraph are used as the target HarmonyOS device cluster. For example, for applications that require high bandwidth and low latency collaboration, devices with high network quality weights are preferred, and physical proximity is further considered to reduce cross-regional communication overhead.

[0035] Specifically, by parsing the metadata of the application deployment task, the target application identifier and device tag set can be accurately obtained, providing clear initial conditions for subsequent device selection. Based on this, the solution can filter out a preliminary set of candidate devices that meet the conditions from the entire HarmonyOS device network based on the device tag set, thereby narrowing down the range of device selection. Furthermore, the solution obtains the network topology and physical proximity relationships of all devices within the candidate device set, and intelligently allocates network quality weights and physical proximity weights based on the application's cross-device requirements. This weight allocation mechanism can quantitatively evaluate the communication performance and physical distance between devices according to the specific needs of the application. Finally, based on the aforementioned allocated weights, several target devices are selected from the candidate device set, forming the target HarmonyOS device cluster most suitable for the application deployment. This entire process forms an intelligent cluster identification mechanism from static to dynamic, ensuring that the selected cluster can highly meet the application's distributed collaboration needs, thereby optimizing communication efficiency and resource utilization between devices and significantly improving the application's deployment success rate and operational performance.

[0036] For example, suppose a user wants to deploy a distributed smart home control application that needs to collaboratively control the smart TV in the living room, the smart speaker in the bedroom, and the smart refrigerator in the kitchen. When the user submits the application deployment task, its metadata is first parsed. This metadata may include "target application identifier: SmartHome_Control_V2.0" and "device tag set: ['smart TV', 'smart speaker', 'smart refrigerator', 'Wi-Fi connection']". Based on these tags, all eligible devices are filtered from the currently online HarmonyOS device network. These include, for example, the user's smart TV, smart speaker, smart refrigerator, and other HarmonyOS devices that support Wi-Fi connectivity. These devices collectively form a candidate device set. Next, the network topology relationships (e.g., these candidate devices are all connected to the same home Wi-Fi router, or there is a direct Bluetooth connection between some devices) and physical proximity relationships (e.g., smart TV) are obtained. (For example, a smart speaker might be in the living room, and a smart refrigerator in the kitchen.) Because smart home control applications have high requirements for real-time response and inter-device collaborative control, their "cross-device demand information" indicator places greater emphasis on "low-latency control command transmission" and "inter-device state synchronization." This assigns a higher network quality weight to network quality (such as low latency and high stability), while physical proximity is relatively less important, but still needs to be considered to reduce potential interference in cross-room communication. Finally, considering these weights comprehensively, the most suitable devices are selected from the candidate device set. For example, a smart TV and smart speaker in the living room, and a smart refrigerator in the kitchen, might be prioritized because these devices have high-quality network connections and are physically close, meeting the stringent requirements of smart home control applications for real-time interaction and data transmission, thus forming the target HarmonyOS device cluster.

[0037] Through the above technical solution, this application can achieve intelligent and refined identification of target HarmonyOS device clusters. By parsing the metadata of application deployment tasks, the basic requirements of the application can be accurately grasped; preliminary screening based on device tag sets can effectively narrow down the range of device selection; more importantly, by obtaining the network topology and physical proximity relationships between devices, and combining the cross-device requirement information of the application to assign corresponding network quality weights and physical proximity weights, the final selected target HarmonyOS device clusters can meet the distributed collaboration requirements of the application to the greatest extent, optimize the communication efficiency and resource utilization between devices, thereby significantly improving the application deployment success rate, operating performance and user experience, and avoiding performance bottlenecks or resource waste caused by improper cluster selection.

[0038] In some implementations, a shared data object is created in the target HarmonyOS device cluster to determine key status indicators based on the requirement information set, and the running status data of the target HarmonyOS device cluster is obtained through the shared data object. However, in actual distributed application deployment scenarios, simply obtaining the overall running status data of the cluster may not be sufficient to accurately reflect the complex interaction requirements between components within the application, especially when executing collaboratively across devices, where the communication quality between components is crucial to application performance. If the communication status between these components cannot be carefully perceived and evaluated, the deployment scheme may fail to fully meet the application's performance requirements, or even cause communication bottlenecks or latency issues.

[0039] In this regard, this application further proposes that, in one embodiment, as Figure 3 As shown, step 30 includes: S31: Based on cross-device requirement information and component composition information, determine the target application component pair and its interaction information set, the interaction information set including communication timing, data volume and latency sensitivity requirements; In this embodiment, determining the target application component pair and its interaction information set based on cross-device requirement information and component composition information refers to analyzing the internal component structure of the target application specified in the application deployment task and the specific requirements of these components in a cross-device scenario. For example, a distributed application may contain a data acquisition component and a data processing component. Cross-device requirement information may indicate that these two components need to perform high-frequency data transmission. In this regard, the data acquisition component and the data processing component are identified as a component pair, and the interaction details between these two components are further analyzed to form an interaction information set. This interaction information set can describe in detail the order of data transmission between components (i.e., communication timing), such as whether it is synchronous or asynchronous transmission; the amount of data transmitted, such as the number of data packets transmitted per second or the total number of bytes; and the tolerance for communication latency (i.e., latency sensitivity requirements), such as whether millisecond-level latency is required.

[0040] S32: Determine the communication requirement baseline based on the interactive information set, and select several candidate device groups in the target HarmonyOS device cluster; In this embodiment, determining the communication requirement benchmark based on the interaction information set means that after clarifying the detailed interaction requirements of the application component pair, specific communication performance indicators are quantified based on these requirements as benchmarks. For example, if the interaction information set indicates that a component pair needs to transmit a large amount of real-time data and is highly sensitive to latency, then the corresponding communication requirement benchmark is determined based on this information. For example, a minimum bandwidth of 100Mbps and a maximum communication latency of no more than 20 milliseconds are required. This communication requirement benchmark is a key standard for measuring whether the communication capabilities between devices meet the application requirements. Selecting several candidate device groups in the target HarmonyOS device cluster means identifying and selecting a set of devices that can meet these communication benchmarks in the entire target HarmonyOS device cluster based on the communication requirement benchmarks determined above. For example, if the communication requirement benchmark of a component pair requires high bandwidth and low latency, devices with close physical distances and high network connection quality may be selected, and the selected devices may be combined into one or more candidate device groups. Each candidate device group represents a potential set of devices that can well support the communication of a specific component pair.

[0041] S33: Create an independent shared data object for each candidate device group, and enable the shared data object to obtain the joint status indicators of each device in its corresponding candidate device group. The joint status indicators include intra-group communication latency, bandwidth and packet loss rate. In this embodiment, creating an independent shared data object for each candidate device group means allocating or creating an independent and dedicated shared data object for each selected candidate device group. This shared data object can be a distributed shared memory region, a dedicated publish / subscribe topic, or a lightweight distributed database instance. Its independence ensures that the status information of different device groups will not interfere with each other, and can be managed and accessed in a targeted manner. Enabling the shared data object to obtain the joint status indicators of each device within its corresponding candidate device group means that after creating the independent shared data object, the shared data object will be responsible for collecting and aggregating the communication-related status of all devices within its candidate device group, i.e., the joint status indicators. Among them, the joint status indicators include the actual communication latency between devices within the group, for example, obtained through periodic ping tests or packet round-trip time measurements; the available bandwidth between devices within the group, for example, obtained through network throughput tests or network interface statistics; and the packet loss rate during data transmission, for example, obtained by statistically analyzing the proportion of data packets that fail to transmit or are retransmitted. These indicators can reflect the communication health status of the candidate device group as a whole.

[0042] S34: Obtain the running status data of each candidate device group by listening to the shared data object corresponding to each candidate device group.

[0043] In this embodiment, by monitoring the shared data objects corresponding to each candidate device group to obtain the operating status data of each device group, it means continuously monitoring the shared data objects corresponding to each candidate device group. When the joint status indicators in the shared data objects change, these data can be detected and extracted in real time, thereby obtaining the latest operating status data of each candidate device group. This monitoring mechanism ensures that the communication performance of different device groups in the cluster can be dynamically obtained, providing a real-time and accurate basis for subsequent deployment decisions.

[0044] Specifically, this solution identifies the interaction patterns and communication performance requirements between components within the application by deeply analyzing the component composition and cross-device requirements of the target application. Based on this, independent shared data objects are created for the subset of devices (i.e., candidate device groups) that meet specific communication needs. These objects are used to collect and aggregate joint communication status indicators within the candidate device groups, such as communication latency, bandwidth, and packet loss rate. Through this fine-grained state awareness mechanism, key information directly related to the communication performance of the application's distributed components can be further extracted from the macro-level cluster operation status data. This allows for a more accurate assessment of the communication capabilities of different combinations of devices in the cluster, providing more precise and reliable input for subsequent dynamic deployment profile construction and deployment orchestration scheme generation, and effectively reducing performance degradation caused by communication bottlenecks.

[0045] For example, suppose there is a distributed smart home application that includes a smart camera component and a smart display component, which requires real-time video streaming. First, based on the application's component composition information and cross-device requirements, the smart camera component and the smart display component are identified and paired. The interaction information set of this pair includes: real-time streaming communication timing, data volume of 10MB per second, and latency sensitivity requirement of less than 100 milliseconds. Based on this, the communication requirement baseline is determined as: minimum bandwidth 100Mbps, maximum latency 80 milliseconds. Next, several candidate device groups are selected from the HarmonyOS device cluster in the home network. For example, one group might include a smart TV in the living room and a smart camera in the bedroom, while another group might include a smart speaker in the kitchen and a smart display at the door. For the living room... A candidate device group consisting of a smart TV and a smart camera in the bedroom is used to create a separate shared data object. This shared data object continuously acquires and aggregates joint status metrics between the two devices. For example, it measures communication latency, available bandwidth, and packet loss rate by periodically sending test data packets between them. For instance, the shared data object records that the current communication latency within the group is 50 milliseconds, the available bandwidth is 200 Mbps, and the packet loss rate is 0.1%. By listening to this shared data object, the operating status data of the device group can be obtained in real time, thereby understanding whether the group meets the real-time video streaming requirements of the smart camera and smart display components.

[0046] Through the above technical solution, this application can precisely perceive and evaluate the operating status of the target HarmonyOS device cluster, especially the communication needs between components within the application. This fine-grained status acquisition method based on component interaction enables accurate identification of which device combinations in the device cluster can meet the communication performance requirements of specific application components. Thus, when building a dynamic deployment profile, it can more accurately evaluate the performance of the deployment scheme, avoiding the deployment of components with high communication quality requirements to device combinations with poor communication performance. This significantly improves the efficiency and reliability of distributed application deployment, ensures the stable operation and good performance of applications in a distributed environment, and effectively solves the deployment blind spots and performance bottlenecks caused by a lack of in-depth understanding of the communication status between components.

[0047] In some embodiments described above, this application proposes creating shared data objects within a target HarmonyOS device cluster, determining key status indicators based on a demand information set, and obtaining operational status data of the target HarmonyOS device cluster through these shared data objects. Specifically, communication demand benchmarks are determined based on an interaction information set, and several candidate device groups are selected from the target HarmonyOS device cluster. An independent shared data object is created for each candidate device group to obtain joint status indicators such as communication latency, bandwidth, and packet loss rate within the group. However, focusing solely on the communication status between or within device groups may not fully reflect the actual operational status of all devices in the target HarmonyOS device cluster. In particular, individual resource bottlenecks (such as CPU overload, insufficient memory, or storage exhaustion) of independent devices not included in candidate device groups may be overlooked, thus affecting the stability and performance of the overall application deployment.

[0048] In this regard, this application further proposes that, in one embodiment, after step S32, the following steps are included: S321: Identify and record independent devices in the target HarmonyOS device cluster that are not included in the candidate device group; In this embodiment, identifying and recording independent devices in the target HarmonyOS device cluster that are not included in the candidate device groups means that after the candidate device groups are divided, all devices in the target HarmonyOS device cluster are traversed, and devices that are not assigned to any candidate device group are marked as independent devices. This can be achieved by comparing the complete device list of the device cluster with the member list of the assigned device groups, for example, by using set difference operations to find the uncovered devices. Another approach is to assign a unique identifier to each device during the device registration or discovery phase, and after the group division is completed, check which identifiers do not appear in the member list of any group.

[0049] S322: Create an independent state object for each independent device, and enable the independent state object to obtain the individual operating status indicators of its corresponding independent device. The individual operating status indicators include CPU load, available memory, and storage space. In this embodiment, creating an independent state object for each independent device means assigning a dedicated data structure or software entity to each identified independent device to store and manage its individual operational status information. This independent state object can be a database record maintained on a central management server, containing the independent device's unique identifier and its various operational status indicators. Alternatively, the independent state object can be a lightweight agent program deployed on each independent device, responsible for collecting local device operational status data and providing query interfaces. Enabling the independent state object to obtain its corresponding independent device's individual operational status indicators means using a specific mechanism to collect and update the actual operational status data of the independent device into its corresponding independent state object. For example, independent state objects can periodically call the API interfaces provided by the device's operating system to obtain metrics such as CPU load, available memory, and storage space. Alternatively, agents on independent devices can proactively report the obtained metric data to independent state objects on the central management server via message queues or RPC (Remote Procedure Call) mechanisms. Individual operational status metrics include CPU load, available memory, and storage space. CPU load reflects the workload of the device's processor; high load may indicate a shortage of computing resources. Available memory represents the amount of physical memory currently available for applications; insufficient memory can lead to performance degradation or even application crashes. Storage space refers to the remaining capacity of the device's hard drive or flash memory, which is crucial for applications that require large amounts of storage.

[0050] S323: Obtain the operating status data of each independent device by listening to the independent status object corresponding to each independent device.

[0051] In this embodiment, the operation status data of each independent device is obtained by listening to the independent status objects corresponding to each independent device. This means continuously listening to the changes of the independent status objects. This can be achieved by subscribing to the data update events of the independent status objects. When the status indicators of an independent device change, the independent status object will trigger a notification and then receive the latest operation status data of the independent device. Alternatively, each independent status object can be polled periodically to actively query its current individual operation status indicators.

[0052] Specifically, this solution, building upon the existing joint status monitoring mechanism based on device groups, further identifies and specifically monitors independent devices within the target HarmonyOS device cluster that are not included in any device group. By creating independent runtime status objects for the identified independent devices and acquiring their individual runtime status indicators such as CPU load, available memory, and storage space, more comprehensive and detailed cluster runtime status data can be obtained. This dual monitoring mechanism, which considers both the joint status of device groups and the individual status of independent devices, ensures that the resource status and performance bottlenecks of all devices in the cluster can be effectively captured. This individual runtime status data, together with the joint status data of device groups, constitutes the complete input for building a dynamic deployment profile, enabling the deployment profile to more accurately reflect the resource distribution and performance potential of the entire cluster, thereby providing a more solid data foundation for subsequent deployment strategy matching and orchestration scheme generation.

[0053] The above technical solution not only monitors the communication status between device groups, but also captures the specific resource bottlenecks of each individual device, avoiding deployment failures or application performance degradation caused by the exhaustion of resources of a single device. This significantly improves the accuracy and completeness of subsequent dynamic deployment profiles, enabling the generated deployment orchestration scheme to more accurately match the actual resource status of the cluster, thereby optimizing resource utilization and improving the operating efficiency and stability of applications.

[0054] In some of the embodiments described above in this application, a dynamic deployment profile is constructed based on component composition information, requirement information set, and operational status data. However, in practical applications, effectively integrating this multi-source heterogeneous information and quantitatively evaluating the potential performance and resource consumption of different deployment schemes to form a comprehensive dynamic deployment profile is key to achieving efficient and intelligent application deployment. If deployment decisions are made solely based on raw data, it may lead to suboptimal deployment schemes, making it difficult to fully utilize device resources or meet application performance requirements.

[0055] In this regard, this application further proposes that, in one embodiment, step S40 includes: S41: Construct a multi-objective optimization function based on the demand information set. The optimization objectives of the multi-objective optimization function include minimizing overall latency, balancing equipment load, and minimizing total energy consumption. In this embodiment, constructing a multi-objective optimization function based on the demand information set refers to transforming the application deployment requirements into quantifiable optimization objectives. The demand information set may include application requirements for response time, throughput, resource consumption, etc. The optimization objectives of the multi-objective optimization function include minimizing overall latency, balancing device load, and minimizing total energy consumption. Constructing a multi-objective optimization function means comprehensively considering multiple conflicting or mutually influential optimization objectives. For example, minimizing overall latency may require more computing resources, thus increasing energy consumption; balancing device load may sacrifice local performance to some extent to achieve overall stability. Furthermore, this multi-objective optimization function can be constructed using weighted summation, Pareto optimization, or other methods; or, a multi-objective evolutionary algorithm can be used to find a set of Pareto optimal solutions.

[0056] S42: Based on component composition information and operational status data, identify all feasible component-device deployment mapping relationships; In this embodiment, identifying all feasible component-device deployment mapping relationships based on component composition information and runtime status data means determining all possible deployment combinations between application components and devices in the target HarmonyOS device cluster. Component composition information describes the application's internal structure, such as included microservices, modules, or processes, and the dependencies between them. Runtime status data provides real-time resource status of each device in the target HarmonyOS device cluster, such as CPU utilization, memory usage, network bandwidth, and storage space. Identifying feasible mapping relationships means excluding combinations that cannot be deployed due to insufficient resources, architectural incompatibility, or specific device limitations. For example, a compute-intensive component cannot be deployed on a resource-constrained low-power device; or certain components may require specific hardware accelerators and can only be deployed on devices with the corresponding hardware. Furthermore, the identification process can employ methods such as constraint satisfaction problem solving, graph traversal algorithms, or rule-based filtering.

[0057] S43: Substitute the identified component-device deployment mapping relationship into the multi-objective optimization function to obtain the corresponding comprehensive performance score; In this embodiment, the identified component-device deployment mapping relationships are substituted into a multi-objective optimization function to obtain the corresponding comprehensive performance score. This refers to the quantitative evaluation of the merits of each feasible deployment mapping relationship. Once all feasible component-device deployment mapping relationships are identified, each mapping scheme needs to be used as input and substituted into a pre-built multi-objective optimization function for calculation. The multi-objective optimization function will output a comprehensive performance score based on the estimated values ​​of each optimization objective under the deployment mapping relationship. This score reflects the performance of the corresponding deployment scheme in meeting various requirements and optimization objectives. For example, for a specific mapping relationship, its operating effect on the target device cluster can be simulated or predicted to calculate the expected latency, load distribution, and energy consumption. These values ​​are then input into the optimization function to obtain a single comprehensive score or a multi-dimensional score vector.

[0058] S44: Construct a dynamic deployment profile based on the component-device deployment mapping relationship and its comprehensive performance score.

[0059] In this embodiment, constructing a dynamic deployment profile based on component-device deployment mapping relationships and their comprehensive performance scores refers to building a dynamic, structured dataset based on all feasible component-device deployment mapping relationships and their comprehensive performance scores. This dynamic deployment profile is not merely a single deployment scheme, but a collection containing all feasible deployment mapping relationships and their corresponding comprehensive performance scores. This dynamic deployment profile clearly displays all potential deployment options in the current deployment environment, as well as the advantages and disadvantages of each option. For example, a multi-dimensional matrix or graph structure can be constructed, where nodes represent devices or components, edges represent deployment relationships, and attributes such as performance scores and resource consumption are included. The "dynamic" nature of this dynamic deployment profile is manifested in the fact that its content can be updated when the real-time operating status of the device cluster changes. Essentially, the construction process of the dynamic deployment profile closely relies on real-time data, ensuring that the decision-making basis it provides for subsequent deployment strategy matching is always timely and accurate.

[0060] Specifically, this application constructs a dynamic deployment profile through the aforementioned steps. First, based on resource requirement information extracted from the target application's requirement information set and cross-device requirement information, a multi-objective optimization function is constructed. This multi-objective optimization function transforms key performance indicators of application deployment, such as minimizing overall latency, balancing device load, and minimizing total energy consumption, into quantifiable optimization objectives. This allows for a comprehensive consideration of deployment schemes from multiple dimensions, avoiding the limitations that may arise from optimizing a single indicator. Subsequently, by combining the component composition information of the target application and the real-time operating status data of the target HarmonyOS device cluster, all component-device deployment mapping relationships that meet basic resource and compatibility constraints are identified. This ensures that only practically feasible deployment schemes are included in the evaluation scope, avoiding invalid calculations for infeasible schemes, such as those requiring specific hardware acceleration. Components will not be mapped to devices lacking the necessary hardware, or a component with high memory requirements will not be assigned to a device with insufficient memory. Each identified feasible component-device deployment mapping is used as input and fed into a pre-built multi-objective optimization function for calculation. A comprehensive performance score is generated for each deployment mapping, quantifying how well the mapping scheme meets various optimization objectives. For example, a deployment scheme might excel in latency but perform poorly in energy consumption; its comprehensive score reflects this trade-off. Finally, all feasible component-device deployment mappings and their corresponding comprehensive performance scores are integrated to construct a dynamic deployment profile. This profile not only includes all potential deployment options but also quantifies the expected performance and resource consumption of each option. This solution constructs a dynamic deployment profile in this way, providing a data foundation and decision-making basis for subsequent deployment strategy matching and deployment orchestration scheme generation. This makes deployment decisions more intelligent and efficient, effectively solving the problem that raw data is difficult to directly use to evaluate the merits of deployment schemes and improving the operational performance of applications on HarmonyOS device clusters.

[0061] For example, suppose a target application contains three components: a front-end UI component, a business logic component, and a data storage component, and the target HarmonyOS device cluster contains a high-performance mobile phone, a smartwatch, and a smart TV; first, based on the requirement information set, such as the application's requirements for low-latency user interaction, high-concurrency business processing capabilities, and data storage reliability, a multi-objective optimization function is constructed. This multi-objective optimization function can be defined as: ,in, , , The weights are set based on application priority. This refers to the estimated delay, This refers to the estimated maximum equipment load, This refers to the estimated total energy consumption. For example, if user experience is the primary consideration, The weight of the component will be higher; secondly, based on the component composition information (front-end UI components need display capabilities, business logic components need computing capabilities, and data storage components need storage capabilities) and the running status data (mobile phone CPU load 10%, memory usage 20%, watch CPU load 5%, memory usage 15%, TV CPU load 30%, memory usage 40%), all feasible component-device deployment mapping relationships are identified. For example, the front-end UI component can be deployed on a mobile phone or TV, but not on a watch because the screen is too small or the interaction capabilities are insufficient; the business logic component can be deployed on a mobile phone or TV, but a watch may not be suitable because of the difference in computing power and compatibility; the data storage component can be deployed on a mobile phone or TV because of the larger storage space; by excluding incompatible or insufficient resource combinations, a series of feasible mapping schemes can be obtained, such as Scheme A: UI (mobile phone), business (mobile phone), data (mobile phone); Scheme B: UI (mobile phone), business (TV), data (mobile phone); Scheme C: U The system identifies three components: I (TV), business (mobile phone), and data (TV). Each identified component-device deployment mapping is substituted into a multi-objective optimization function to obtain a corresponding comprehensive performance score. For example, for solution A, the overall latency, device load, and energy consumption when running on a mobile phone can be estimated, and then the value of F for solution A can be calculated. For solution B, various indicators of UI on a mobile phone, business on a TV, and data on a mobile phone are estimated, and the value of F for solution B is calculated. This estimation process can be based on historical data, simulation models, or heuristic rules. Finally, by integrating all these component-device deployment mappings and their corresponding comprehensive performance scores, a dynamic deployment profile is constructed. This dynamic deployment profile can be a data structure, such as a list or database table, where each row records a feasible deployment solution, including its component-device mapping details and corresponding comprehensive performance score. The dynamic deployment profile clearly displays all possible deployment options and their quantitative evaluation results in the current environment, providing a multi-faceted view for subsequent deployment decisions.

[0062] Through the above technical solution, this application effectively integrates multi-source heterogeneous component composition information, requirement information sets, and operational status data, and transforms them into a structured and quantifiable dynamic deployment profile. This dynamic deployment profile constructs a multi-objective optimization function, comprehensively considering key performance indicators such as overall latency, device load balancing, and total energy consumption. This allows for an objective evaluation of the merits of different deployment schemes from multiple perspectives, identifying all feasible component-device deployment mapping relationships from a vast array of deployment possibilities, and assigning a precise comprehensive performance score to each relationship. Therefore, in the subsequent deployment strategy matching and deployment orchestration scheme generation stages, more intelligent and efficient decisions can be made based on the dynamic deployment profile, avoiding suboptimal deployments caused by incomplete information or inaccurate evaluations. This improves the quality and efficiency of application deployment, optimizes the operational status of applications on HarmonyOS device clusters, and enhances the collaborative capabilities of distributed devices.

[0063] In some of the embodiments described above, this application proposes to perform matching analysis between a dynamic deployment profile and a pre-built deployment strategy knowledge base, and generate a deployment orchestration scheme based on the matching analysis results. However, in actual deployment, if the complexity of the deployment environment is not fully considered, the generated deployment orchestration scheme may not be optimal, making it difficult to effectively balance performance and resource consumption.

[0064] In this regard, this application further proposes that, in one embodiment, step S50 includes: S51: Based on the dynamic deployment profile and application deployment tasks, match the corresponding matching cost calculation rules from the deployment strategy knowledge base. The cost calculation rules define the mapping relationship between performance indicators and deployment costs. In this embodiment, matching the corresponding cost calculation rules from the deployment strategy knowledge base based on the dynamic deployment profile and application deployment task means intelligently selecting or generating a set of cost calculation rules suitable for the current scenario from the pre-established deployment strategy knowledge base, according to the specific deployment requirements of the current application and the real-time status of the device cluster. These cost calculation rules form the basis for evaluating the merits of different deployment schemes, quantifying various performance indicators into comparable deployment costs. The matching process of the calculation rules can be implemented using a rule engine. Multiple cost calculation rules are pre-stored in the deployment strategy knowledge base, each associated with a specific application type, deployment scenario, or device cluster characteristic. When a dynamic deployment profile and application deployment task are received, the most suitable cost calculation rule is retrieved from the knowledge base based on the key features in the dynamic deployment profile (such as application type and resource requirements) and the specific requirements in the task (such as priority and SLA), using a preset rule matching algorithm. Alternatively, a machine learning model can be used, using historical deployment data as a training set to train a classification or regression model. This model can predict or recommend the most suitable cost calculation rule based on the input dynamic deployment profile and application deployment task.

[0065] Furthermore, historical deployment data includes dynamic deployment profiles, application deployment tasks, actual deployment effects, and corresponding cost data.

[0066] S52: Construct a deployment decision space based on dynamic deployment profiles and identify performance bottlenecks and resource contention points in the deployment decision space; In this embodiment, constructing a deployment decision space based on a dynamic deployment profile and identifying performance bottlenecks and resource contention points within that space means building a decision space encompassing all possible deployment schemes, considering application component composition, requirements, and device operating status. Within this decision space, further analysis is needed to identify potential performance bottlenecks and resource contention points, which is crucial for generating efficient deployment paths subsequently. Performance bottlenecks represent aspects that may lead to system performance degradation, while resource contention points represent locations where multiple components or tasks compete for limited resources. Performance bottlenecks can be identified by recognizing devices with excessively high resource utilization or high-latency nodes on communication paths, while resource contention points can be identified by analyzing multiple components simultaneously requesting resources. The process involves identifying situations where the same scarce resource is required. Furthermore, the deployment decision space can be modeled as a multi-dimensional matrix or graph structure, where dimensions represent different device, component, or resource types. By analyzing the component composition and resource requirement information in the dynamic deployment profile, combined with the operational status data of the target HarmonyOS device cluster, the deployment of different components on different devices can be simulated. Additionally, simulation technology can be used to construct the deployment decision space: a simulation environment can be built based on the dynamic deployment profile to simulate the operation of application components under different deployment configurations in the target HarmonyOS device cluster. By running a series of simulation experiments, various performance index data can be collected, and potential performance bottlenecks and resource contention points under specific deployment configurations can be identified.

[0067] S53: Based on the matching cost calculation rules and the identified performance bottlenecks and resource contention points, generate several potential deployment paths with estimated total costs. In this embodiment, based on the matching cost calculation rules and the identified performance bottlenecks and resource contention points, several potential deployment paths associated with estimated total costs are generated. This means that the aforementioned determined cost calculation rules are used, combined with the identified performance bottlenecks and resource contention points, to explore paths and generate a series of feasible potential deployment path schemes. Each deployment path scheme is associated with its corresponding estimated total cost. These potential deployment paths represent different component-to-device mapping methods and corresponding resource allocation strategies. Their generation process can be implemented using heuristic search algorithms or graph search algorithms. Specifically, the deployment decision space is considered as a state space. Each state represents a component-to-device mapping. During the search process, the algorithm evaluates the cost of each intermediate state or path according to the cost calculation rules, and performs pruning or optimization based on performance bottlenecks and resource contention points to generate a series of potential deployment paths with different costs. Alternatively, it can be generated using constraint satisfaction problems or mixed-integer linear programming methods. In this approach, the component deployment problem is modeled as a set of variables and constraints, where the variables represent the component-to-device mapping, and the constraints include resource limitations, dependencies, etc. The cost calculation rules serve as the optimization objective function. By solving these rules, potential deployment paths that satisfy the constraints and have different estimated total costs can be obtained.

[0068] S54: Select the deployment path with the lowest estimated total cost as the deployment orchestration scheme.

[0069] In this embodiment, selecting the deployment path with the lowest estimated total cost as the deployment orchestration scheme means selecting the scheme with the lowest estimated total cost under the current cost calculation rules from all generated potential deployment paths and determining it as the final deployment orchestration scheme. The deployment orchestration scheme is considered to be the current optimal deployment strategy. The most direct way to select it is to perform a simple comparison and sorting. That is, after generating all potential deployment paths and their estimated total costs, these paths are arranged in ascending order according to the estimated total cost, and then the first path after sorting is selected as the deployment orchestration scheme.

[0070] Specifically, this solution generates deployment orchestration schemes in the following ways: First, based on the constructed dynamic deployment profile and specific application deployment tasks, the most suitable cost calculation rules for the current scenario are intelligently matched from the pre-built deployment strategy knowledge base. These cost calculation rules clarify the quantitative relationship between performance indicators and deployment costs, laying the foundation for subsequent scheme evaluation. Simultaneously, the dynamic deployment profile comprehensively analyzes application components, requirements, and device status, constructing a deployment decision space containing all possible deployment configurations, and accurately identifying potential performance bottlenecks and resource contention points within this space. Subsequently, path exploration is performed using the matched cost calculation rules and the identified performance bottlenecks and resource contention points, generating several potential deployment paths associated with estimated total costs. These potential deployment paths represent different component-to-device mapping strategies and their corresponding resource consumption and performance. Finally, the path with the lowest estimated total cost is selected from these potential deployment paths as the final deployment orchestration scheme. This application ensures, through the aforementioned method, that the generated deployment orchestration scheme not only meets application requirements but also achieves an optimal balance in terms of performance, resource utilization, and energy consumption, effectively solving the optimization problem of application deployment in complex HarmonyOS device clusters.

[0071] For example, suppose we need to deploy an intelligent security application comprising three components—data acquisition, feature extraction, and model inference—on a HarmonyOS device cluster consisting of multiple smart cameras, edge computing gateways, and cloud servers. First, based on the dynamic deployment profile of the intelligent security application (e.g., the model inference component has high computing power requirements, and the data acquisition component has high real-time requirements) and the application deployment tasks (e.g., low latency and high accuracy requirements), a cost calculation rule suitable for the "real-time video analysis" scenario is matched from the deployment strategy knowledge base. This cost calculation rule may define how factors such as computing resource consumption, network bandwidth usage, data transmission latency, and device energy consumption are quantified as deployment costs. Simultaneously, based on the dynamic deployment profile, a deployment decision space containing all possible component-device mappings is constructed. For example, the model inference component can be deployed on an edge computing gateway or a cloud server, and the feature extraction component can be deployed on a smart camera or an edge computing gateway. Within this decision space, potential performance bottlenecks are identified; for example, if all model inference tasks are concentrated on a single edge computing gateway, its NPU may become a bottleneck. Resource contention points are also identified. For example, when multiple smart security applications are deployed simultaneously, they may compete for NPU resources on the edge computing gateway. Subsequently, using the matched cost calculation rules and identified performance bottlenecks and resource contention points, several potential deployment paths are generated. For instance, one path might deploy the data acquisition and feature extraction components on the smart camera and the model inference component on the edge computing gateway; another path might deploy the data acquisition component on the smart camera and both the feature extraction and model inference components on the cloud server. Each path calculates an estimated total cost based on the cost calculation rules. Finally, the estimated total costs of these potential deployment paths are compared, and the deployment path with the lowest estimated total cost is selected as the deployment orchestration scheme for the smart security application. For example, if the path that offloads some feature extraction tasks to the smart camera and uses multiple edge computing gateways for distributed model inference has the lowest estimated total cost, then that deployment path will be selected.

[0072] Through the above technical solution, this application can overcome the problem that simple matching of dynamic deployment profiles and knowledge bases may lead to suboptimal deployment schemes when deploying applications in complex HarmonyOS device clusters. By introducing matching cost calculation rules and constructing a deployment decision space based on dynamic deployment profiles to identify performance bottlenecks and resource contention points, a systematic evaluation of the advantages and disadvantages of different deployment strategies can be achieved. Finally, by selecting the deployment path with the lowest estimated total cost, the generated deployment orchestration scheme can be ensured to meet application requirements while maximizing resource utilization, reducing operating costs, and improving overall system performance, thereby achieving efficient, intelligent, and robust application deployment.

[0073] In some of the embodiments described above, this application proposes to parse the deployment orchestration scheme into several atomic tasks, and distribute these atomic tasks to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling. However, in actual implementation, how to effectively decompose the complex deployment orchestration scheme into executable atomic tasks, and ensure that these tasks can be efficiently scheduled according to the real-time status of the device cluster and the inherent relationships between tasks, is a key issue that may be encountered in actual implementation. If the task decomposition is unreasonable or the scheduling is improper, it may lead to resource waste, low execution efficiency, or even deployment failure.

[0074] In this regard, this application further proposes that, in one embodiment, step S60 includes: S61: Perform semantic analysis on the deployment orchestration scheme to identify its task relationships, which include data dependency relationships, execution timing constraints, and resource mutual exclusion relationships; In this embodiment, semantic analysis of the deployment orchestration scheme to identify its task relationships refers to a deep analysis and understanding of the structure and content of the deployment orchestration scheme to reveal its implicit logic and connections. Task relationships describe the attributes that interact and constrain different tasks, including data dependencies, execution timing constraints, and resource exclusivity. Data dependencies indicate that the execution of one task requires the output data of another task as input. Execution timing constraints specify the execution order of tasks; for example, a task must start only after another task has completed. Resource exclusivity means that multiple tasks cannot simultaneously occupy the same resource and require coordination. Furthermore, these task relationships can be identified by parsing the description language of the deployment orchestration scheme, specifically by using natural language processing techniques or graph theory algorithms to construct task dependency graphs or directed acyclic graphs. Another implementation method is that the deployment orchestration scheme embeds corresponding relation metadata during design; simply extracting and parsing these predefined relation identifiers is sufficient to identify task relationships.

[0075] S62: Real-time acquisition of the real-time network topology and device computing power distribution of the target HarmonyOS device cluster, calculation of estimated communication overhead and estimated computing overhead based on preset task splitting rules, and determination of the target task splitting granularity in combination with task relationships; In this embodiment, real-time acquisition of the target HarmonyOS device cluster's real-time network topology and device computing power distribution refers to continuously and dynamically collecting the latest status information of the target HarmonyOS device cluster. The real-time network topology describes network characteristics such as connection methods, link bandwidth, and latency between devices, reflecting the efficiency and reliability of data transmission. Device computing power distribution refers to the resource status of each device in the cluster, such as computing power, memory size, and storage space, reflecting the device's task processing capabilities. Real-time network topology and device computing power distribution can be collected and summarized through periodic reporting by device-side agent programs, network probing protocols, or distributed monitoring systems. In calculating the estimated communication overhead and estimated computing overhead based on preset task splitting rules, the task splitting rules guide how to decompose a large deployment task into smaller, more manageable atomic tasks. The estimated communication overhead refers to the network resource consumption and time cost required for data exchange between different atomic tasks after task splitting; the estimated computational overhead refers to the computational resource consumption and time cost required for each atomic task to execute on a specific device; the calculation of these overheads can be predicted based on historical data, task type characteristics, device performance models, and the current network topology and device computing power distribution; in determining the target task splitting granularity in conjunction with task relationships, the task splitting granularity refers to the fineness of decomposing the deployment orchestration scheme into atomic tasks. If the granularity is too coarse, it may lead to insufficient task parallelism and failure to fully utilize distributed resources; if the granularity is too fine, it may introduce excessive communication overhead and scheduling management complexity. Determining the splitting granularity in conjunction with task relationships means considering the impact of task relationships on task execution efficiency when splitting tasks.

[0076] S63: Based on the target task segmentation granularity, the deployment orchestration scheme is parsed into several atomic tasks. A task priority queue is constructed according to the task relationship, and the atomic tasks and the task priority queue are injected into the HarmonyOS distributed task scheduler so that the HarmonyOS distributed task scheduler can distribute them.

[0077] In this embodiment, an atomic task is the smallest indivisible execution unit and also the basic unit that the HarmonyOS distributed task scheduling system can directly identify and schedule. Parsing the deployment orchestration scheme into several atomic tasks based on the target task granularity means decomposing the complex deployment orchestration scheme into several independent, executable atomic tasks according to the target task granularity determined in the preceding steps. Constructing a task priority queue based on task relationships involves a data structure used to store atomic tasks to be executed and sorting them according to their priority. The priority can be determined based on factors such as the task's criticality, deadline, resource requirements, and data dependencies. Injecting the atomic tasks and the task priority queue into the HarmonyOS distributed task scheduler for distribution means submitting the parsed atomic tasks and their priority information to the HarmonyOS distributed task scheduling system. The HarmonyOS distributed task scheduler is a core component provided by the HarmonyOS operating system, responsible for efficiently allocating, executing, and managing tasks in a distributed device cluster.

[0078] Specifically, when distributing the deployment orchestration scheme to the target HarmonyOS device cluster for collaborative execution, the solution of this application first performs semantic analysis on the deployment orchestration scheme to identify the task relationships contained therein. These task relationships are the foundation for ensuring the correct execution and efficient scheduling of distributed tasks. Simultaneously, it acquires the latest network topology and device computing power distribution of the target HarmonyOS device cluster in real time, providing accurate runtime environment information for subsequent task partitioning and scheduling. Based on this, and using preset task partitioning rules, combined with the real-time acquired network topology and device computing power distribution, it calculates the estimated communication overhead and estimated computing overhead that may occur when decomposing the deployment orchestration scheme into atomic tasks. By comprehensively considering the estimated overhead and the previously identified task relationships, a target task partitioning granularity is determined. This target task partitioning granularity is both... To ensure task parallelism and fully utilize distributed resources while avoiding excessive communication overhead and scheduling complexity due to overly fine-grained partitioning, the deployment orchestration scheme is parsed into a series of atomic tasks based on the determined target task partitioning granularity. These atomic tasks are the smallest execution units that the HarmonyOS distributed task scheduling system can directly process. To ensure that these atomic tasks are executed in the correct order and with the correct priority, a task priority queue is constructed based on the previously identified task relationships. Finally, these atomic tasks and their priority queues are injected into the HarmonyOS distributed task scheduler. The HarmonyOS distributed task scheduler uses its built-in intelligent scheduling mechanism to distribute these atomic tasks to the corresponding target devices in the target HarmonyOS device cluster for collaborative execution, based on the device's real-time load, resource availability, and task priority.

[0079] For example, suppose there is a deployment orchestration scheme whose goal is to deploy a cross-device collaborative fitness application on a HarmonyOS device cluster consisting of smartphones, smartwatches, and smart TVs. This fitness application includes a "data acquisition module", a "data analysis module", and a "results display module". First, semantic analysis was performed on the deployment orchestration scheme to identify data dependencies and execution timing constraints between the "data acquisition module" and the "data analysis module," and a similar relationship between the "data analysis module" and the "results display module." Simultaneously, if both the "data analysis module" and the "results display module" require significant CPU resources, a resource mutual exclusion relationship may exist between them. Next, the real-time network topology and device computing power distribution of the HarmonyOS device cluster were acquired. Based on preset task segmentation rules, the estimated communication and computational overhead of subdividing "data acquisition" into atomic tasks such as "sensor data reading" and "data preprocessing" were calculated. Combining this information and task relationships, the target task segmentation granularity was determined. For example, it might be decided to segment the "data acquisition module" into "sensor data reading atomic tasks" and "data preprocessing atomic tasks," the "data analysis module" into "data receiving atomic tasks," "algorithm computation atomic tasks," and "results generation atomic tasks," and the "results display module" into "data receiving atomic tasks." The system first identifies the "sensor data reading atomic task" and the "UI rendering atomic task." Then, based on the granularity of this target task, the original deployment orchestration scheme is parsed into a series of atomic tasks. Simultaneously, based on the previously identified task relationships, a task priority queue is constructed. For example, the priority of the "sensor data reading atomic task" may be higher than that of the "data preprocessing atomic task," which in turn has a higher priority than the "data receiving atomic task." Finally, these atomic tasks and the constructed task priority queue are injected into the HarmonyOS distributed task scheduler. The HarmonyOS distributed task scheduler, based on the real-time load, network conditions, and task priorities of the smartwatch, smartphone, and smart TV, distributes the "sensor data reading atomic task" and the "data preprocessing atomic task" to the smartwatch for execution; distributes the "data receiving atomic task," the "algorithm calculation atomic task," and the "result generation atomic task" to the smartphone for execution; and distributes the "data receiving atomic task" and the "UI rendering atomic task" to the smart TV for execution, thereby achieving collaborative deployment and efficient operation of the entire fitness application.

[0080] Through the above technical solution, this application can perform refined semantic analysis on complex deployment orchestration schemes and accurately identify the inherent relationships between tasks. At the same time, by combining real-time acquired device cluster status information, it intelligently determines the optimal task splitting granularity, effectively balancing the contradiction between task parallelism and communication overhead. This allows the deployment orchestration scheme to be efficiently parsed into a series of manageable atomic tasks, and the orderly execution of atomic tasks is ensured through a priority queue. Finally, the HarmonyOS distributed task scheduler can distribute atomic tasks to target devices for collaborative execution based on the above information, thereby improving the efficiency, reliability, and resource utilization of distributed application deployment and avoiding performance bottlenecks and resource waste caused by improper task splitting or chaotic scheduling.

[0081] In one embodiment, step S62 includes: S621: Set multi-dimensional decision constraints, including maximum allowable execution time, device load rate threshold, and battery energy consumption limit; In this embodiment, multidimensional decision constraints are used to provide various restrictions and guidance for the selection of task segmentation granularity. Multidimensional decision constraints can ensure that the final deployment scheme meets performance requirements while also taking into account the actual operating conditions of the device and user experience. For example, the maximum allowable execution time can be set according to the application's service level agreement or the user's expectation of response speed to ensure that the task is completed within an acceptable time range. It can be pre-configured as a fixed value, such as 500 milliseconds, or dynamically adjusted according to the application type. The device load rate threshold is used to limit the upper limit of the device's CPU, memory and other resources during task execution to prevent the overload of a single device from affecting system stability. The device load rate threshold can be set to, for example, 80% CPU utilization, or adaptively adjusted according to the device's hardware configuration and current idle resources. The battery power consumption limit is applicable to battery-powered HarmonyOS devices and aims to control the power consumed by task execution to extend the device's battery life. The battery power consumption limit can be calculated based on the device's battery capacity and the user's current power level, or dynamically adjusted according to the power saving mode selected by the user.

[0082] S622: Input the multidimensional decision constraints, real-time network topology and device computing power distribution into the pre-trained quantitative evaluation model, so that the quantitative evaluation model generates a set of segmentation granularity schemes; In this embodiment, to effectively handle complex constraints and real-time data, a pre-trained quantitative evaluation model is introduced. This model is an intelligent decision-making model trained on a large amount of historical data, capable of comprehensively analyzing input information such as multi-dimensional decision constraints, real-time network topology, and device computing power distribution. The quantitative evaluation model can be built based on machine learning algorithms, such as deep neural networks or support vector machines, learning the performance of different task segmentation granularities under various operating conditions to predict the merits of solutions in new scenarios. Alternatively, the model can be built based on reinforcement learning methods, learning and optimizing task segmentation strategies through interaction with a simulated environment to maximize expected performance indicators. The core function of the quantitative evaluation model is to generate a set of task segmentation granularity options. Based on the current input conditions, it outputs a series of possible task segmentation granularity options and performs quantitative evaluation on each option, such as predicting its total execution time, resource consumption, and energy consumption. These task segmentation granularity options can be a set of discrete segmentation granularity levels or multiple optimization points explored by the quantitative evaluation model in a continuous space.

[0083] S623: Select the segmentation granularity scheme with the shortest total execution time from the set of segmentation granularity schemes, and set it as the target task segmentation granularity.

[0084] In this embodiment, after obtaining the set of segmentation granularity schemes, the final target task segmentation granularity is determined by selecting the segmentation granularity scheme with the shortest total execution time. That is, among all candidate schemes that meet the multidimensional decision constraints, the scheme that can make the overall task execution time the shortest will be selected first, thereby ensuring that the application can respond to and complete the task at the fastest speed under the premise of meeting all operational constraints. In some cases, if the total execution time of multiple schemes is very close, other secondary optimization objectives can be further considered for trade-offs, such as lower energy consumption or more balanced device load, in order to make a more comprehensive decision.

[0085] Specifically, this solution optimizes the determination process of the target task segmentation granularity by introducing multi-dimensional decision constraints and a pre-trained quantitative evaluation model. Before parsing the deployment orchestration scheme into atomic tasks and distributing them, key operational constraints such as the maximum allowable execution time, device load rate threshold, and battery power consumption limit are first set. These constraints define acceptable performance and resource boundaries for task segmentation and deployment. Subsequently, these constraints, along with the real-time network topology and device computing power distribution of the target HarmonyOS device cluster, are input into the pre-trained quantitative evaluation model. This model comprehensively analyzes the input data to generate a set of multiple candidate segmentation granularity schemes. Each scheme represents a possible task segmentation method and includes estimated performance indicators for the task under that scheme, such as estimated total execution time, resource consumption, and energy consumption. Finally, the segmentation granularity scheme with the shortest total execution time is selected from this set of schemes and set as the target task segmentation granularity. This ensures that the determined task segmentation granularity not only meets the basic functional requirements of application deployment but also achieves performance optimization under multiple constraints in a complex distributed environment.

[0086] For example, suppose in a smart home scenario, a user triggers a cross-device collaborative smart security application through voice commands. This smart security application needs to analyze video streams from multiple cameras A in real time, display abnormal areas on smart screen B, and issue an alarm through smart speaker C. When parsing the deployment orchestration scheme, it is necessary to determine the granularity of the video analysis task. First, multi-dimensional decision constraints are set. For example, the maximum allowable execution time is set to 150 milliseconds to ensure real-time response; the device load rate threshold for Smart Screen B is set to 85% to avoid affecting its normal display function; the battery power consumption limit for Smart Speaker C is set to 200 millijoules to extend its standby time. Simultaneously, the real-time network topology and device computing power distribution of the target HarmonyOS device cluster are acquired. For example, it is found that Camera A and Smart Screen B are connected via 5GHz Wi-Fi, which has higher bandwidth; Smart Speaker C is connected via 2.4GHz Wi-Fi, which has relatively lower bandwidth; Smart Screen B's CPU idle rate is 70%, and Smart Speaker C's CPU idle rate is 90%. These multi-dimensional decision constraints, real-time network topology, and device computing power distribution are input into a pre-trained quantitative evaluation model. Through simulating numerous deployment scenarios, the model learns how to segment and allocate video analysis tasks to Smart Screen B and Smart Speaker C under different network and device conditions to achieve optimal performance. Subsequently, the quantitative evaluation model generates... A set of segmentation granularity schemes is generated. For example, the following schemes may be generated: Scheme 1: Smart screen B is responsible for all video analysis tasks, and smart speaker C is only responsible for alarm playback. The estimated total execution time is 180 milliseconds, which exceeds the maximum allowed execution time. Scheme 2: Smart screen B is responsible for video decoding and object detection, and smart speaker C is responsible for behavior recognition. The estimated total execution time is 120 milliseconds, smart screen B has a load rate of 80%, and smart speaker C consumes 150 millijoules of energy. Scheme 3: Smart screen B is responsible for video decoding, and smart speaker C is responsible for object detection and behavior recognition. The estimated total execution time is 130 milliseconds, smart screen B has a load rate of 60%, and smart speaker C consumes 180 millijoules of energy. Finally, the segmentation granularity scheme with the shortest total execution time is selected from the set of segmentation granularity schemes. Specifically, Scheme 1 is excluded because it exceeds the maximum allowed execution time. Among Schemes 2 and 3, the total execution time of Scheme 2 is 120 milliseconds, which is shorter than the 130 milliseconds of Scheme 3, and both satisfy all constraints. Therefore, Scheme 2 is selected as the target task segmentation granularity.

[0087] Through the above technical solution, this application sets multi-dimensional decision constraints and combines a pre-trained quantitative evaluation model to intelligently analyze the real-time network topology and device computing power distribution, generating and selecting the optimal task partitioning granularity scheme that satisfies all constraints. This makes the scheduling of distributed tasks more refined and intelligent, which not only shortens the overall execution time of tasks and improves the response speed and user experience of applications, but also effectively reduces device overload and unnecessary energy consumption, thereby improving the resource utilization efficiency and system stability of the entire HarmonyOS device cluster.

[0088] In one embodiment, an application deployment system based on HarmonyOS devices is provided, which corresponds one-to-one with the application deployment method based on HarmonyOS devices described in the previous embodiment. The application deployment system based on HarmonyOS devices includes: The target identification module is used to identify the target HarmonyOS device cluster and target application corresponding to the application deployment task in response to the application deployment task. The information extraction module is used to obtain the current version installation package of the target application and extract component composition information and requirement information set, wherein the requirement information set includes resource requirement information and cross-device requirement information. The data acquisition module is used to create shared data objects in the target HarmonyOS device cluster, determine key status indicators based on the demand information set, and acquire the operating status data of the target HarmonyOS device cluster through the shared data objects. The profile building module is used to build dynamic deployment profiles based on component composition information, requirement information sets, and runtime status data. The solution generation module is used to match and analyze the dynamic deployment profile with the pre-built deployment strategy knowledge base, and generate a deployment orchestration solution based on the matching analysis results. The task distribution module is used to parse the deployment orchestration scheme into several atomic tasks, and distribute the atomic tasks to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling.

[0089] For specific limitations regarding an application deployment system based on HarmonyOS devices, please refer to the limitations of an application deployment method based on HarmonyOS devices mentioned above, which will not be repeated here. Each module in the aforementioned application deployment system based on HarmonyOS devices can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0090] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements an application deployment method based on a HarmonyOS device.

[0091] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for deploying applications based on HarmonyOS devices, characterized in that, Including the following steps: In response to application deployment tasks, identify the target HarmonyOS device cluster and the target application corresponding to the application deployment task; Obtain the current version installation package of the target application, and extract component composition information and requirement information set, the requirement information set including resource requirement information and cross-device requirement information; Create a shared data object in the target HarmonyOS device cluster, determine key status indicators based on the requirement information set, and obtain the operating status data of the target HarmonyOS device cluster through the shared data object; A dynamic deployment profile is built based on component composition information, requirement information set, and operational status data; The dynamic deployment profile is matched and analyzed with a pre-built deployment strategy knowledge base, and a deployment orchestration scheme is generated based on the matching analysis results. The deployment orchestration scheme is parsed into several atomic tasks, and the atomic tasks are distributed to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling.

2. The application deployment method based on HarmonyOS devices according to claim 1, characterized in that: The step of identifying the target HarmonyOS device cluster and target application corresponding to the application deployment task in response to the application deployment task includes the following steps: Parse and extract the metadata of the application deployment task, which includes the target application identifier and a set of device tags; Based on the set of device tags, a set of candidate devices is selected from the currently available HarmonyOS device network; Obtain the network topology and physical proximity relationships of all candidate devices in the candidate device set, and assign network quality weights and physical proximity weights based on cross-device requirement information; Based on network quality weights and physical proximity weights, several target devices are selected from the candidate device set and a target HarmonyOS device cluster is formed.

3. The application deployment method based on HarmonyOS devices according to claim 1, characterized in that: The steps of creating a shared data object in the target HarmonyOS device cluster, determining key status indicators based on the demand information set, and obtaining the operating status data of the target HarmonyOS device cluster through the shared data object include the following steps: Based on cross-device requirement information and component composition information, target application component pairs and their interaction information sets are determined. The interaction information sets include communication timing, data volume, and latency sensitivity requirements. Based on the interactive information set, the communication requirement benchmark is determined, and several candidate device groups are selected from the target HarmonyOS device cluster. Create an independent shared data object for each candidate device group, and enable the shared data object to obtain the joint status indicators of each device in its corresponding candidate device group. The joint status indicators include intra-group communication latency, bandwidth and packet loss rate. By monitoring the shared data objects corresponding to each candidate device group, the operating status data of each candidate device group can be obtained.

4. The application deployment method based on HarmonyOS devices according to claim 3, characterized in that: After the steps of determining the communication requirement benchmark based on the interactive information set and selecting several candidate device groups from the target HarmonyOS device cluster, the following steps are included: Identify and record independent devices in the target HarmonyOS device cluster that are not included in the candidate device group; Create an independent state object for each independent device, and enable the independent state object to obtain the individual operating status indicators of its corresponding independent device. The individual operating status indicators include CPU load, available memory, and storage space. By listening to the independent status objects corresponding to each independent device, the operating status data of each independent device can be obtained.

5. The application deployment method based on HarmonyOS devices according to claim 1, characterized in that: The step of constructing a dynamic deployment profile based on component composition information, requirement information set, and operational status data includes the following steps: A multi-objective optimization function is constructed based on the demand information set. The optimization objectives of the multi-objective optimization function include minimizing overall latency, balancing equipment load, and minimizing total energy consumption. Based on component composition information and operational status data, all feasible component-device deployment mapping relationships are identified; The identified component-device deployment mapping relationship is substituted into the multi-objective optimization function to obtain the corresponding comprehensive performance score; A dynamic deployment profile is constructed based on the component-device deployment mapping relationship and its comprehensive performance score.

6. The application deployment method based on HarmonyOS devices according to claim 1, characterized in that: The step of matching and analyzing the dynamic deployment profile with a pre-built deployment strategy knowledge base, and generating a deployment orchestration scheme based on the matching analysis results, includes the following steps: Based on dynamic deployment profiles and application deployment tasks, corresponding matching cost calculation rules are matched from the deployment strategy knowledge base. The cost calculation rules define the mapping relationship between performance indicators and deployment costs. A deployment decision space is constructed based on dynamic deployment profiles, and performance bottlenecks and resource contention points in the deployment decision space are identified. Based on the matching cost calculation rules and the identified performance bottlenecks and resource contention points, several potential deployment paths with estimated total costs are generated. Choose the deployment path with the lowest estimated total cost as the deployment orchestration scheme.

7. The application deployment method based on HarmonyOS devices according to claim 1, characterized in that: The step of parsing the deployment orchestration scheme into several atomic tasks and distributing the atomic tasks to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling includes the following steps: Semantic analysis is performed on the deployment orchestration scheme to identify its task relationships, which include data dependencies, execution timing constraints, and resource mutual exclusion relationships. The system acquires the real-time network topology and computing power distribution of the target HarmonyOS device cluster, calculates the estimated communication overhead and estimated computing overhead based on the preset task splitting rules, and determines the target task splitting granularity by combining task relationships. Based on the granularity of the target task, the deployment orchestration scheme is parsed into several atomic tasks. A task priority queue is constructed according to the task relationship, and the atomic tasks and the task priority queue are injected into the HarmonyOS distributed task scheduler so that the HarmonyOS distributed task scheduler can distribute them.

8. The application deployment method based on HarmonyOS devices according to claim 7, characterized in that: The steps of acquiring the real-time network topology and device computing power distribution of the target HarmonyOS device cluster, calculating the estimated communication overhead and estimated computing overhead based on preset task partitioning rules, and determining the target task partitioning granularity in combination with task relationships include the following steps: Set multi-dimensional decision constraints, including maximum allowable execution time, device load rate threshold, and battery energy consumption limit; The multidimensional decision constraints, real-time network topology and device computing power distribution are input into the pre-trained quantitative evaluation model, which then generates a set of segmentation granularity schemes. Select the segmentation granularity scheme with the shortest total execution time from the set of segmentation granularity schemes, and set it as the target task segmentation granularity.

9. An application deployment system based on HarmonyOS devices, characterized in that, include: The target identification module is used to identify the target HarmonyOS device cluster and target application corresponding to the application deployment task in response to the application deployment task. The information extraction module is used to obtain the current version installation package of the target application and extract component composition information and requirement information set, wherein the requirement information set includes resource requirement information and cross-device requirement information. The data acquisition module is used to create shared data objects in the target HarmonyOS device cluster, determine key status indicators based on the demand information set, and acquire the operating status data of the target HarmonyOS device cluster through the shared data objects. The profile building module is used to build dynamic deployment profiles based on component composition information, requirement information sets, and runtime status data. The solution generation module is used to match and analyze the dynamic deployment profile with the pre-built deployment strategy knowledge base, and generate a deployment orchestration solution based on the matching analysis results. The task distribution module is used to parse the deployment orchestration scheme into several atomic tasks, and distribute the atomic tasks to several target devices in the target HarmonyOS device cluster for collaborative execution through HarmonyOS distributed task scheduling.

10. A computer-readable storage medium, characterized in that, The device stores a computer program capable of being loaded by a processor and executing the application deployment method based on HarmonyOS as described in any one of claims 1 to 8.

Images