A computer desktop collaborative optimization method and device based on open source honkong

Abstract

This invention discloses a computer desktop collaboration optimization method and device based on open-source HarmonyOS. The method includes: an application adaptation layer responding to collaboration task requests and forwarding parameters to the core service layer; the core service layer establishing an encrypted soft bus connection; collecting hardware status data and dynamically allocating the proportion of multiple resource pools based on collaboration function type, resource demand coefficient, and user attention weight; a functional module layer monitoring various collaboration events; serializing and compressing cross-device operation event data for transmission; adapting the projection interface based on the target terminal's physical resolution using pixel scaling and layout rearrangement algorithms; allocating classification transmission identifiers according to collaboration task priority; fragmenting and indexing standard-compliant collaboration data before transmission; and the application adaptation layer responding to collaboration end requests and the core service layer restoring the computer-side collaboration-related state after completing data integrity verification. This improves the security, efficiency, smoothness, and user experience of open-source HarmonyOS computer desktop collaboration.

Description

Technical Field

[0001] This invention relates to the fields of access conversion and terminal collaboration technology, and in particular to a computer desktop collaboration optimization method and device based on the open-source HarmonyOS. Background Technology

[0002] OpenHarmony, an open-source distributed operating system designed for all scenarios, has been widely used in various smart terminals. As the demand for distributed collaboration in personal computers (PCs) continues to increase, OpenHarmony has encountered development bottlenecks in communication, resource scheduling, and interaction adaptation during its expansion to PC desktops. Native soft bus protocols, general resource scheduling strategies, and traditional interaction adaptation methods are all unable to meet the usage requirements of PC desktops.

[0003] Currently, there are three main types of solutions for distributed collaboration on OpenHarmony PC desktops: one type is based on dedicated hardware and uses near-field communication or wireless connection to achieve collaborative functions such as file transfer, screen projection, and keyboard and mouse control; another type relies on Bluetooth or point-to-point wireless transmission technology to achieve file transfer and basic collaborative operations between similar desktop devices; and the third type is achieved by combining fast file transfer and cross-device control functions, which are responsible for data transmission and input device sharing, and interface collaboration, respectively, and only support terminals within the same ecosystem.

[0004] However, methods based on dedicated hardware only support terminals within the same brand's ecosystem, resulting in limited compatibility, slow transmission rates, and lack of support for resuming interrupted downloads. Resource scheduling is not adapted to the differences in computer hardware configurations, and the dedicated key system is incompatible with the open-source HarmonyOS. Methods relying on Bluetooth or point-to-point wireless transmission technologies are only applicable to similar desktop terminals, cannot interconnect with open-source HarmonyOS devices, do not support complex collaborative scenarios, have high transmission latency, lack interrupted download and encrypted transmission mechanisms, and have low data security. Methods combining file transfer and cross-device control functions belong to a closed ecosystem, independent of the open-source HarmonyOS ecosystem. They do not support cross-device multi-task linkage, resource scheduling relies on dedicated hardware, cannot adapt to computers with different configurations, and transmission encryption only supports proprietary ecosystem keys, resulting in poor compatibility. Summary of the Invention

[0005] This invention provides a computer desktop collaboration optimization method and device based on open-source HarmonyOS, in order to solve the problems of poor compatibility, poor security, low efficiency, poor smoothness and poor user experience of computer desktop collaboration based on open-source HarmonyOS.

[0006] According to one aspect of the present invention, a computer desktop collaborative optimization method based on open-source HarmonyOS is provided, executed by a computer based on open-source HarmonyOS, comprising: The application adaptation layer responds to user-initiated collaborative task requests, determines the matching target terminal, collaborative function type, and custom interaction parameters, and after forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, an encrypted soft bus connection is established between the computer and the target terminal through the core service layer. The core service layer collects hardware status data, determines the priority of collaborative tasks based on the type of collaborative function, and calculates the corresponding resource requirement coefficient and user attention weight. Based on the priority, resource requirement coefficient and user attention weight, the resource ratio of multiple resource pools is dynamically allocated to the collaborative task, and then the encrypted soft bus transmission is started. By listening to cross-device operation, screen mirroring startup, and collaborative data transmission events through the functional module layer, when cross-device operation event data is collected through the functional module layer, the cross-device operation event data is serialized and compressed, and transmitted to the target terminal through an encrypted soft bus to execute the computer's keyboard and mouse control of the target terminal; When the physical resolution of the target terminal is collected through the functional module layer and the screen casting start command is received, the screen casting interface is adaptively adapted based on the physical resolution of the target terminal through pixel scaling algorithm and layout rearrangement algorithm. When the functional module layer receives collaborative data forwarded by the application adaptation layer, and the core service layer has started encrypted soft bus transmission, the functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that meets the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index. The application adaptation layer responds to the user's collaboration termination request and forwards the collaboration termination request to the core service layer. After the core service layer passes the integrity verification of the collaboration data, the collaboration-related state on the computer is restored to the initial state before the collaboration task request was executed.

[0007] According to another aspect of the present invention, a computer desktop collaborative optimization device based on open-source HarmonyOS is provided, configured on a computer based on open-source HarmonyOS, comprising: The connection establishment module is used to respond to user-initiated collaborative task requests through the application adaptation layer, determine the matching target terminal, collaborative function type and custom interaction parameters, and after forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, establish an encrypted soft bus connection between the computer and the target terminal through the core service layer. The transmission module is started to collect hardware status data through the core service layer, determine the priority of the collaborative task based on the collaborative function type, and calculate the corresponding resource demand coefficient and user attention weight. After dynamically allocating the resource ratio of multiple resource pools for the collaborative task based on the priority, resource demand coefficient and user attention weight, the encrypted soft bus transmission is started. The sequence compression module is used to listen to cross-device operation, screen mirroring startup, and collaborative data transmission events through the functional module layer. When cross-device operation event data is collected through the functional module layer, the cross-device operation event data is serialized and compressed, and transmitted to the target terminal through an encrypted soft bus to execute the computer's keyboard and mouse control of the target terminal. The screen mirroring module is used to adaptively adapt the screen mirroring interface based on the physical resolution of the target terminal when the physical resolution of the target terminal is collected through the functional module layer and a screen mirroring start command is received. The collaborative transmission module is used when the functional module layer receives collaborative data forwarded by the application adaptation layer and the core service layer has started encrypted soft bus transmission. The functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that meets the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index. The collaboration termination module is used to respond to user-initiated collaboration termination requests through the application adaptation layer, forward the collaboration termination request to the core service layer, and restore the collaboration-related state on the computer to the initial state before the collaboration task request was executed after the integrity verification of the collaboration data is passed by the core service layer.

[0008] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the computer desktop collaborative optimization method based on open-source HarmonyOS as described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the computer desktop collaborative optimization method based on open-source HarmonyOS as described in any embodiment of the present invention.

[0010] According to another aspect of the present invention, a computer program product is also provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any embodiment of the present invention.

[0011] The technical solution of this invention, through the application adaptation layer responding to collaborative task requests and forwarding parameters to the core service layer, establishes an encrypted soft bus connection, enabling secure and stable interconnection between the computer and the target terminal, avoiding the risk of data leakage during the collaboration process. Simultaneously, standardized collaborative interface calls improve the efficiency of collaborative request forwarding and reduce redundancy between layers. The core service layer collects hardware status data and dynamically allocates the proportion of multiple resource pools based on collaborative function type, resource demand coefficient, and user attention weight, achieving precise resource scheduling, avoiding resource waste, ensuring the smooth operation of high-priority collaborative tasks, and adapting to different hardware states to achieve flexible resource allocation and improve the compatibility of the collaborative system. The functional module layer listens to various collaborative events and serializes and compresses cross-device operation event data for transmission, reducing data transmission bandwidth consumption, improving the response speed of keyboard and mouse operation, and achieving seamless cross-device operation. Through pixel scaling and layout... The rearrangement algorithm adapts to the projection interface based on the physical resolution of the target terminal, solving problems such as screen stretching, control overlap, and text truncation when projection across devices, thus improving the projection display effect and user viewing experience. The functional module layer assigns classification transmission identifiers according to the priority of collaborative tasks, and transmits standard-compliant collaborative data after fragmentation and indexing. This ensures orderly and efficient transmission of collaborative data, guaranteeing that high-priority data is transmitted first. Furthermore, fragmented transmission combined with index management allows for the retransmission of only missing or erroneous fragments after transmission interruption, improving data transmission integrity and efficiency while reducing resource consumption from repeated transmissions. The application adaptation layer responds to the collaboration end request, and the core service layer restores the computer-side collaboration-related state after data integrity verification. This ensures closed-loop operation of collaborative tasks, avoids resource occupation residue, improves system stability and reliability, and optimizes open-source HarmonyOS computer desktop collaboration, balancing collaboration security, efficiency, smoothness, and user experience.

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

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart of a computer desktop collaborative optimization method based on open-source HarmonyOS provided according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of another computer desktop collaborative optimization method based on open-source HarmonyOS provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart of another computer desktop collaborative optimization method based on open-source HarmonyOS provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of a computer desktop collaborative optimization system based on the open-source HarmonyOS, to which this invention is applicable; Figure 5 This is a schematic diagram illustrating a computer desktop collaboration optimization based on the open-source HarmonyOS, applicable to an embodiment of the present invention. Figure 6 This is a schematic diagram of a computer desktop collaborative optimization device based on the open-source HarmonyOS according to Embodiment 4 of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device that implements the computer desktop collaborative optimization method based on open-source HarmonyOS according to an embodiment of the present invention. Detailed Implementation

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

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] Example 1 Figure 1This is a flowchart of a computer desktop collaboration optimization method based on open-source HarmonyOS provided in Embodiment 1 of the present invention. This embodiment is applicable to optimizing collaborative operations on a computer desktop based on open-source HarmonyOS. This method can be executed by a computer desktop collaboration optimization device based on open-source HarmonyOS. This device can be implemented in hardware and / or software and is generally configured in a computer based on open-source HarmonyOS. Correspondingly, as... Figure 1 As shown, the method includes: S110. Responding to the user-initiated collaborative task request through the application adaptation layer, the matching target terminal, collaborative function type, and custom interaction parameters are determined. After forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, an encrypted soft bus connection between the computer and the target terminal is established through the core service layer.

[0018] In this embodiment of the invention, the application adaptation layer can be specifically understood as: a connection layer that receives user operations, connects upper-layer collaborative needs with lower-layer services, and provides standardized collaborative interfaces to realize the parsing, parameter encapsulation, and forwarding of user collaborative requests. A collaborative task request can be specifically understood as: an operation command initiated by a user on a computer based on open-source HarmonyOS, requesting distributed collaboration with other terminals, which may include requests such as target terminal selection, collaborative function selection, and customized interaction rules. A target terminal can be specifically understood as: a smart terminal matching the computer, such as an open-source HarmonyOS phone or tablet, which is the collaborative object on the computer. A collaborative function type can be specifically understood as: cross-device collaborative functions selected by the user, such as screen sharing and file transfer, which can be selected individually or in combination.

[0019] Custom interaction parameters can be understood as cross-device interaction rule parameters set by the user based on usage habits, such as mapped edges and trigger sensitivity. Mapped edges can be specifically understood as the screen edges (such as the left, right, or top edge) on the computer that trigger cross-device keyboard and mouse interaction, as set by the user; these are the trigger positions for cross-device interaction. Trigger sensitivity can be specifically understood as a distance threshold parameter that matches the mapped edge, determining how far the mouse needs to move to the mapped edge to trigger cross-device interaction; the sensitivity level corresponds to the specific distance threshold.

[0020] The standardized collaboration interface can be understood as a unified interface built into the application adaptation layer, used to encapsulate all parameters of the collaboration task request and forward them to the core service layer, realizing standardized data interaction between layers and improving compatibility and scalability. The core service layer can be understood as the control layer used to implement core operations such as cross-device connection establishment, hardware resource scheduling, and data transmission control; it is the main body for establishing encrypted soft bus connections. The encrypted soft bus connection can be understood as a secure communication link between the computer and the target terminal established based on an encryption mechanism; it is the basic channel for transmitting cross-device collaborative data and operation commands, ensuring transmission security and stability.

[0021] Specifically, this section is the initiation phase of the entire distributed collaboration process, which is completed collaboratively by the application adaptation layer and the core service layer.

[0022] On the computer-based HarmonyOS-based "Distributed Collaboration Center" and other visual operation interfaces, users can select the target terminal for collaboration (such as an open-source HarmonyOS phone) by checking or selecting options. They can choose one or a combination of screen sharing, file transfer, etc., as the collaboration function type. They can also customize interaction parameters according to their own usage habits, such as edge mapping and trigger sensitivity (e.g., different levels correspond to a distance threshold of 30-50px (pixels), with level 3 corresponding to 30px). After completing all settings, users can initiate a collaboration task request. This request can also be triggered through computer shortcut keys, voice commands, or other methods, without being limited to the visual interface operation.

[0023] The application adaptation layer receives and parses the collaborative task request initiated by the user, and extracts and determines the target terminal to be collaborated with, the collaborative function type selected by the user, and the user-defined custom interaction parameters from the request.

[0024] The application adaptation layer calls its own standardized collaboration interface, such as `InitCooperation(deviceId, mapEdge=right, sensitivity=3, taskType=[1,2])`, to encapsulate user-defined collaboration parameters and forward them to the core service layer. `InitCooperation` is the initialization function for collaboration; `deviceId` is the unique identifier of the target terminal, used to specify the object of this collaboration (such as an open-source HarmonyOS phone or tablet); `mapEdge=right` is a custom interaction parameter, where `mapEdge` represents the mapping edge for cross-device interaction. Assigning `right` indicates that the user sets the right edge of the computer screen as the trigger for cross-device interaction. The location of the device's keyboard and mouse interaction; sensitivity=3 is the trigger sensitivity parameter, with a value of 3 corresponding to the preset sensitivity level (e.g., level 3 corresponds to a distance threshold of 30px, meaning that cross-device interaction is triggered when the mouse moves within 30px of the right edge of the screen); taskType=[1,2] is the collaborative function type parameter, with the number in square brackets being the function type code, where 1 can represent screen sharing and 2 can represent file transfer. [1,2] indicates that this collaborative task includes both screen sharing and file transfer functions. The purpose of this code statement is to pass the instruction to the core service layer to "establish a collaborative connection with the target terminal corresponding to deviceId, use the right edge of the screen and level 3 sensitivity as the interaction rules, and execute screen sharing and file transfer collaborative tasks simultaneously".

[0025] The collaborative task request, which encapsulates the target terminal, collaborative function type, and custom interaction parameters, is forwarded to the core service layer. Upon receiving the request, the core service layer initiates a cross-device connection establishment process, ultimately establishing an encrypted soft bus connection between the computer and the target terminal, thus building a secure communication foundation for subsequent collaborative operations such as resource scheduling, cross-device interaction, and data transmission.

[0026] S120: Collect hardware status data through the core service layer, determine the priority of the collaborative task based on the collaborative function type, and calculate the corresponding resource demand coefficient and user attention weight. After dynamically allocating the resource ratio of multiple resource pools for the collaborative task based on the priority, resource demand coefficient and user attention weight, start encrypted soft bus transmission.

[0027] In this embodiment of the invention, hardware status data can be specifically understood as: real-time operating status parameters of the core hardware on the computer side, which may include CPU (Central Processing Unit) utilization, remaining memory, GPU (Graphics Processing Unit) utilization, network bandwidth (such as Wi-Fi (Wireless-Fidelity) 6 bandwidth), and storage IO (Input / Output) utilization, which are the basic data basis for resource allocation.

[0028] Collaborative task priority can be understood as a task level determined by factors such as the resource requirements of the collaborative function type and the importance of the usage scenario. This level determines the degree of resource allocation bias, with higher-priority tasks receiving more hardware resources. The resource requirement coefficient can be understood as a parameter calculated based on historical collaborative data, reflecting the actual hardware resource consumption requirements of different collaborative tasks. A higher coefficient corresponds to a task's dependence on resources. User attention weight can be understood as a weight parameter set based on the user's level of attention to collaborative tasks. This can be determined through window focus detection; focused tasks have higher weights, ensuring a better user experience for core operations.

[0029] A resource pool can be understood as a resource management unit categorized by computer hardware type. It can include CPU, memory, GPU, network bandwidth, and storage I / O resource pools, supporting dynamic allocation of resource proportions based on task requirements. Dynamic allocation can be understood as the core service layer flexibly adjusting the allocation ratio of each resource pool to different collaborative tasks based on the priority of collaborative tasks, resource demand coefficients, and user attention weights, combined with real-time hardware status, to avoid resource waste and uneven distribution.

[0030] Specifically, the core service layer uses standardized interfaces to collect real-time hardware status data from the computer. It can also collect data through hardware sensors, system-level application programming interfaces (APIs), or third-party hardware monitoring tools. The collected hardware status data consists of core operating parameters of the PC, such as CPU utilization, remaining memory, GPU utilization, Wi-Fi 6 bandwidth (typically, the collected value can be 800 megabits per second), and storage I / O utilization.

[0031] After data collection, the priority of each collaborative task is determined according to the user-selected collaborative function type (such as screen sharing and file transfer) and a custom priority determination rule (such as screen sharing, which has high hardware resource requirements and strong real-time requirements, being high priority, and file transfer being medium priority). At the same time, the resource requirement coefficient of each task is calculated based on statistical analysis of historical collaborative data or training of machine learning models. The user attention weight is determined through window focus detection or user manual marking, thus completing the calculation of multi-dimensional core parameters.

[0032] Based on the calculated priority, resource demand coefficient, and user attention weight, the system dynamically allocates resource proportions from multiple resource pools, such as CPU, memory, GPU, network bandwidth, and storage I / O, to each collaborative task using a multi-dimensional weighted round-robin algorithm, queue scheduling algorithm, or other intelligent scheduling algorithms. During the allocation process, the proportions can be flexibly adjusted according to the remaining hardware capacity, tilting resources towards high-priority, high-resource-demand, and high-user-attention tasks to ensure the rationality and efficiency of resource allocation. Finally, after the resource pool proportions for each collaborative task are allocated and it is verified that the allocated resources can meet the task's operational requirements, the core service layer officially initiates encrypted soft bus transmission between the computer and the target terminal.

[0033] S130: Listen to cross-device operation, screen mirroring startup, and collaborative data transmission events through the functional module layer. When cross-device operation event data is collected through the functional module layer, serialize and compress the cross-device operation event data, and transmit it to the target terminal through an encrypted soft bus to execute the computer's keyboard and mouse control of the target terminal.

[0034] In this embodiment of the invention, the functional module layer can be specifically understood as: the execution layer that implements specific collaborative functions in the open-source HarmonyOS computer desktop collaborative architecture. It receives scheduling instructions from the core service layer and is used for practical operations such as cross-device event listening, data processing, and function implementation. It is a key layer connecting the core service layer with terminal hardware or interaction scenarios. Cross-device operation event data can be specifically understood as: operation instruction data initiated by the user on the computer terminal via keyboard and mouse, pointing to the target terminal, such as mouse movement coordinates, click actions, and keyboard key commands. It is the data carrier for realizing cross-device keyboard and mouse control.

[0035] The screen casting start event can be understood as an operation signal that triggers the screen casting function, such as when a user clicks the "Screen Cast" button or uses a shortcut key. After listening to this event, the functional module layer will initiate the screen casting interface adaptation process. The collaborative data transmission event can be understood as a signal that starts, pauses, or terminates the transmission of collaborative data (such as file fragments or screen casting screen data). After listening to this event, the functional module layer will perform operations such as data fragmentation, verification, and transmission.

[0036] Serialization compression can be understood as the process of converting non-standardized operation event data into a unified format (serialization) and reducing data volume (compression). The aim is to reduce bandwidth consumption, improve transmission efficiency, and ensure data parsing compatibility. Encrypted soft bus transmission can be understood as data transmission based on an encrypted soft bus connection established by the core service layer. This ensures data transmission security and leverages the distributed nature of the soft bus to achieve efficient cross-terminal data exchange. Keyboard and mouse control of the target terminal can be understood as the process of mapping keyboard and mouse operation commands from the computer to the target terminal and executing them, achieving a distributed collaborative effect of one keyboard and mouse controlling multiple terminals.

[0037] Specifically, the functional module layer uses the device file monitoring and system event notification mechanisms (such as inode notification mechanism and message hook mechanism) of the operating system input subsystem to monitor cross-device operations, screen casting startup, and collaborative data transmission events at high frequency (such as 1000 Hz) around the clock to ensure that no user interaction commands are missed.

[0038] When cross-device operation event data is detected and collected, such as corresponding keyboard and mouse operation data (e.g., mouse coordinate changes, key press or release signals), these keyboard and mouse operation command data are first serialized and compressed to convert the heterogeneous operation data into a unified input format of the open-source HarmonyOS ecosystem, such as a custom JSON (JavaScript Object Notation) structure or Protobuf (Protocol). The system uses a buffer (protocol buffer) format to break down input protocol barriers between different terminals. Data compression algorithms are then used to reduce data size and bandwidth usage. After processing, the functional module layer calls the standardized transmission interface of the encrypted soft bus to transmit the compressed operation data to the target terminal via a pre-established encrypted soft bus connection in the core service layer. Data integrity is ensured during transmission through fragmented transmission or verification codes. Upon receiving the data, the target terminal decompresses and deserializes the operation commands. Then, based on the dynamic coordinate mapping between the computer and the target terminal (such as multi-screen coordinate transformation formulas), it maps the computer's keyboard and mouse commands to the target terminal's interface and executes them. For example, when the computer mouse moves to the right edge of the screen by 30px (matching a custom trigger sensitivity), the command is transmitted to the target terminal and a click operation is executed at the corresponding location. Simultaneously, a real-time feedback mechanism sends the target terminal's operation results back to the computer, forming an interactive closed loop.

[0039] Throughout the process, the functional module layer focuses on the data processing and transmission of cross-device operation events, while screen casting startup and collaborative data transmission events are processed according to their respective preset logic. The three types of event listening do not interfere with each other, ensuring low latency and high accuracy of cross-device keyboard and mouse control, while relying on the encrypted soft bus to achieve secure transmission of operation data. This solves the problems of high threshold, slow response, and fragmented experience in traditional cross-device interactive operation, while also adapting to the interactive scenarios of multi-screen PCs, achieving a distributed collaborative effect of controlling multiple terminals with a single keyboard and mouse.

[0040] Furthermore, based on the above embodiments, while establishing an encrypted soft bus connection between the computer and the target terminal through the core service layer, it may also include: The input device mapping unit and the interface adaptive unit are initialized through the functional module layer. During the initialization of the input device mapping unit through the functional module layer, the input device mapping unit identifies the multi-screen splicing mode and resolution of each screen on the computer through the display server and window system tools, and obtains screen topology data. During the initialization of the interface adaptive unit through the functional module layer, the interface adaptive unit collects the physical resolution of the target terminal through the terminal access layer. Accordingly, by listening to cross-device operation, screen mirroring initiation, and collaborative data transmission events through the functional module layer, it can include: The input device mapping unit of the functional module layer listens to the device files of the operating system input subsystem through a notification mechanism and captures cross-device operation, screen casting startup, and collaborative data transmission event data on the computer at a preset frequency.

[0041] In this embodiment of the invention, the input device mapping unit can be specifically understood as a sub-unit of the cross-device interaction module in the functional module layer. It is used to identify multi-screen hardware information on the computer, listen to keyboard and mouse operation events, and implement coordinate and format mapping of cross-terminal operation commands. It is the execution unit for PC keyboard and mouse control of the target terminal. The interface adaptive adaptation unit can be specifically understood as a sub-unit of the functional module layer. It is used to collect the physical resolution of the target terminal and achieve cross-device adaptation of the projection interface through pixel scaling and layout rearrangement algorithms, solving the problems of screen distortion and control overlap caused by resolution differences.

[0042] Screen topology data can be specifically understood as the basic hardware parameters for cross-device interactive mapping of multi-screen PCs. This can include comprehensive data such as the computer's multi-screen splicing mode (e.g., expansion and duplication), the resolution of each screen, and the splicing position relationship between screens. Display server and window system tools can be specifically understood as tools used to identify computer display hardware information. For example, the XRandR (X Resize and Rotate) tool can accurately obtain information such as the splicing mode and resolution of each screen in a multi-screen PC, providing technical support for screen topology data acquisition. Notification mechanisms can be specifically understood as file system event monitoring mechanisms, such as inotify (inode notify), which can monitor device file status changes in real time and capture keyboard and mouse operation events from the operating system input subsystem.

[0043] The device file of the operating system's input subsystem can be understood as the underlying file in the operating system that stores operation events of input devices such as keyboards and mice. For example, the " / dev / input / eventX" file in the Linux operating system is a device file used by the system to manage and store input device operation events. Here, "X" is a numerical sequence number, corresponding to different input devices on the computer (such as mice, keyboards, touchpads, etc. The system will assign an independent sequence number to each connected input device, forming different files such as event0 and event1). This file belongs to the Linux input subsystem and is a key data bridge between hardware input operations and system applications. All operation events such as keyboard and mouse clicks, drags, key inputs, and movements are written to the corresponding file in real time in a standardized event data format. At the same time, the application layer can listen to and read it through a specific mechanism. The input device mapping unit of the functional module layer listens to this file through the inotify notification mechanism, captures the operation event data in it at a preset frequency, and carries the screen ID (Identifier) ​​parameter to provide the original and accurate input data source for subsequent cross-device operation event processing, transmission, and mapping. The preset frequency can be understood as the frequency at which the functional module layer collects operation event data, such as 1000 Hz, which is the millisecond level of collection, to ensure the real-time capture of keyboard and mouse operation events and avoid delays and loss of operation commands.

[0044] Specifically, this section is the synchronous preparation stage for establishing the encrypted soft bus connection, and it is also the prerequisite for the functional module layer to realize subsequent cross-device interaction and screen projection adaptation.

[0045] While the core service layer performs the encrypted soft bus connection establishment operation between the computer and the target terminal, the functional module layer does not need to wait for the connection to complete. It directly and synchronously starts the initialization process of the input device mapping unit and the interface adaptive adaptation unit, ensuring the efficient advancement of the collaborative process without sequential waiting. The input device mapping unit identifies the multi-screen splicing mode and the resolution of each screen on the computer through the display server and window system tools, and obtains the screen topology data. This data is the basis for subsequent coordinate mapping between the multi-screen PC and the target terminal. The interface adaptive adaptation unit collects the physical resolution of the target terminal through the standardized communication interface of the terminal access layer. This parameter is the basis for subsequent pixel scaling and layout rearrangement of the projection interface. After the initialization of the two units is completed, they can send a "initialization complete" signal to the core service layer, triggering subsequent resource allocation and other collaborative processes, ensuring the orderly connection of processes at each level.

[0046] In line with the dual-unit initialization described above, the functional module layer clarifies the monitoring implementation methods for various collaborative events. The input device mapping unit acts as the monitoring entity, using a dedicated notification mechanism to monitor the device files of the operating system's input subsystem. It captures three types of event data from the computer: cross-device operations, screen mirroring startup, and collaborative data transmission, at a fixed preset frequency. This provides data sources for subsequent event processing and command transmission. Cross-device operation events can include keyboard and mouse clicks, input, and drag-and-drop commands. All collected event data carries a screen ID parameter, allowing for precise location of the specific screen on a multi-screen PC, preventing operation mapping errors in multi-screen scenarios.

[0047] It should be emphasized that the input device mapping unit is a core component of the cross-device interaction module in the functional module layer. Its core purpose is to break through the device barriers and multi-screen adaptation bottlenecks of cross-device input interaction, and realize seamless control of PC keyboard and mouse on multiple terminals. It is also the core unit for realizing the interactive convenience advantage of this invention.

[0048] This unit innovatively optimizes traditional cross-device interaction solutions by addressing their pain points: Firstly, it features intelligent edge mapping and user habit learning. Unlike traditional fixed edge triggering methods, it supports user-defined left, right, and top mapping edges and can dynamically adjust trigger sensitivity by learning user usage frequency. For example, during high-frequency use, the trigger distance can be reduced from 50px to 30px. Compared to similar fixed edge solutions, it can adapt to multi-screen PC scenarios such as 4-screen splicing and supports mapping at any screen edge. Secondly, it enables low-latency input event transmission, overcoming the latency issues of traditional transmission. It adopts a dual mechanism of interrupt-driven and event compression, directly reading the raw events from the device files of the operating system's input subsystem and then compressing the event data through algorithms (such as the protobuf algorithm) to reduce transmission latency. Thirdly, it features intelligent multi-screen coordinate mapping, breaking the limitations of single-screen adaptation. It can automatically identify splicing modes such as expansion and copying of PC multi-screens and establish a dynamic mapping relationship between the PC multi-screen coordinate system and the target terminal coordinate system. It supports seamless mouse movement between PC multi-screens and collaborative terminals, solving the problem that existing solutions only support single-screen PCs.

[0049] In a specific example, this unit completes cross-device input interaction through three stages. First, input event acquisition and processing: using the inotify mechanism to monitor device files, it captures keyboard and mouse clicks, drags, and input events in real-time at millisecond-level sampling frequencies. Simultaneously, it uses the XRandR tool to identify the screen ID (screenId) of multi-screen PCs, obtaining screen resolution and splicing relationships, allowing the acquired event data to carry the screenId parameter to locate the screen where the operation occurred. Second, event standardization and compression: It converts raw events such as keyboard scan codes and absolute mouse coordinates from the Linux input subsystem into the OpenHarmony input event format, and then uses protobuf to serialize and compress the event data, removing redundant fields such as duplicate coordinate information, reducing data volume and lowering cross-device transmission overhead. Finally, cross-terminal mapping logic: on the one hand, it achieves accurate coordinate conversion through a preset formula, such as target terminal coordinates = (PC screen coordinates - screen splicing offset) × target terminal resolution / corresponding PC screen resolution; on the other hand, it uses libinput (library) to... The input library monitors the distance between the mouse and the edge of the screen. Based on the user's usage frequency data over the past 7 days, it dynamically adjusts the trigger threshold within a range of 30-50px. After triggering, it automatically establishes a cross-terminal mapping without requiring any additional user operation.

[0050] To facilitate development and usage, this unit also defines standardized input and output interfaces. The input interface is `InputEvent(uint8_t type, int32_t x, int32_t y, uint16_t keyCode, uint8_t screenId, uint8_t mapEdge, uint8_t sensitivity)`. In the `InputEvent` interface, `uint8_t type` represents the event type of the keyboard and mouse operation, used to distinguish different operation behaviors such as click, drag, and key input; `int32_t x` and `int32_t y` are the horizontal and vertical coordinate values ​​on the PC screen when the operation occurs, which are the original basis for coordinate mapping; `uint16_t keyCode` is the scan code of the keyboard key or the function code of the mouse operation, identifying the specific key or mouse operation; `uint8_t`... `screenId` is a unique identifier for the screen to which the operation occurs in a multi-screen PC, used to locate the specific screen where the operation takes place; `uint8_tmapEdge` is the user-defined cross-device interaction mapping edge, identifying the edge of the PC screen that triggers cross-terminal control; `uint8_tsensitivity` is the trigger sensitivity for cross-device interaction, divided into 1-5 levels, corresponding to different distance trigger thresholds, with the value positively correlated with the trigger sensitivity. The output interface is `MapEventResult(uint8_t status, uint32_ttargetDeviceId, int32_t targetX, int32_t targetY)`. In the `MapEventResult` output interface, `uint8_t status` is the processing and mapping status of the cross-device operation event, used to provide feedback on whether the operation was successful, whether the mapping was established, etc.; `uint32_t targetDeviceId` is the unique device identifier of the target collaborative terminal, enabling accurate terminal positioning and command transmission; `int32_t targetX` and `int32_t targetY` are the corresponding horizontal and vertical coordinate values ​​on the target terminal after transformation by the coordinate mapping formula, determining the landing position of the operation on the target terminal. uint8_t is an unsigned 8-bit integer type, int32_t is a signed 32-bit integer type, uint16_t is an unsigned 16-bit integer type, and uint32_t is an unsigned 32-bit integer type.

[0051] Regarding development dependencies and performance data, the development of this unit requires foundational components such as the operating system input subsystem driver, OpenHarmony distributed event service API, protobuf, and multi-screen management tools. Understandably, among alternative input device mapping solutions, if Bluetooth Low Energy is used to transmit input events, this approach is more suitable for low-power scenarios such as PC-to-wear device collaboration, but it cannot support high real-time operations like real-time keyboard and mouse drag-and-drop, and is only suitable for simple button input scenarios.

[0052] By establishing an encrypted soft bus connection at the core service layer while simultaneously initializing the input device mapping unit and the interface adaptive adaptation unit at the functional module layer, and by having the input device mapping unit listen for various collaborative events according to specifications, the parallel advancement of core connection establishment, functional unit initialization, and event listening is achieved. This avoids the increased process time caused by serial operations and improves the startup efficiency of the entire collaborative task. Furthermore, by using specialized tools to identify the multi-screen splicing mode and resolution on the computer and acquire screen topology data, and by having the interface adaptive adaptation unit simultaneously collect the physical resolution of the target terminal, complete and matching hardware parameters are prepared in advance for subsequent cross-device keyboard and mouse coordinate mapping and screen projection interface adaptive adaptation. This solves the pain points of traditional solutions that do not support multi-screen PC adaptation and have poor cross-device display and operation adaptability, ensuring subsequent communication... The accuracy of cross-device collaboration and screen mirroring is enhanced. The input device mapping unit monitors the device files of the operating system's input subsystem through a notification mechanism and captures three types of event data—cross-device operation, screen mirroring startup, and collaborative data transmission—at a preset frequency. This enables real-time and comprehensive collection of user collaborative operation commands, resulting in more timely responses to cross-device operation commands. Furthermore, this design allows the functional module layer to complete hardware parameter collection and event monitoring preparation at the initial stage of the collaborative process. This allows core collaborative operations such as data transmission and operation mapping to be carried out directly after the encrypted soft bus connection is established. This not only optimizes the overall operation process of cross-device collaboration but also provides crucial pre-emptive guarantees for achieving seamless control of the target terminal by the PC keyboard and mouse and adaptive display of the screen mirroring interface. This improves the smoothness of cross-device collaboration and the consistency of user experience within the open-source HarmonyOS ecosystem.

[0053] S140. When the physical resolution of the target terminal is collected through the functional module layer and the screen casting start command is received, the screen casting interface is adaptively adapted based on the physical resolution of the target terminal through pixel scaling algorithm and layout rearrangement algorithm.

[0054] In this embodiment of the invention, physical resolution can be specifically understood as: the inherent pixel size of the target terminal screen, which is the hardware benchmark for screen mirroring interface adaptation and determines the final size of the screen scaling and layout adjustment. Screen mirroring start command can be specifically understood as: the operation signal that triggers the screen mirroring function (such as clicking the screen mirroring button, shortcut key, or voice command), which is the trigger condition for starting the adaptation algorithm. Pixel scaling algorithm can be specifically understood as: an algorithm that adjusts the screen mirroring screen size based on the principle of proportionality (such as bilinear interpolation), solving the problem of screen stretching and distortion caused by the inconsistency in resolution ratio between the PC and the target terminal. Layout rearrangement algorithm can be specifically understood as: an adaptation algorithm for screen mirroring interface controls, which solves display abnormalities such as control overlap and text truncation after screen scaling by adjusting the control size, position, or text style.

[0055] Specifically, during the initial initialization phase, the functional module layer has already collected and cached the physical resolution of the target terminal through the interface adaptive adaptation unit. When a screen casting start command is received from the user, the screen casting interface adaptive adaptation process is initiated. Based on the obtained PC screen topology data, the size of the available screen casting area is determined. Then, combined with the physical resolution of the target terminal, the overall size of the screen casting screen is first adjusted through a pixel scaling algorithm, and then the distribution of interface controls is optimized through a layout rearrangement algorithm. Finally, the screen casting interface is adaptively adapted on the target terminal, ensuring that the screen casting content is displayed completely and clearly.

[0056] Optionally, based on the above embodiments, the screen projection interface can be adaptively adapted according to the physical resolution of the target terminal using pixel scaling and layout rearrangement algorithms, which may include: Based on the computer screen topology data, the available area size for projection is determined. Combined with the physical resolution of the target terminal, the screen scaling factor is calculated according to the principle of proportionality. If the resolution ratio between the computer and the target terminal is inconsistent, the projection screen size is adjusted according to the first principle. After pixel scaling of the projection screen using bilinear interpolation, all controls on the projection interface are traversed, the overlap area between controls is calculated, and the display integrity of text controls is checked. When the overlap area of ​​controls exceeds the preset overlap ratio or the text controls are not fully displayed, the size and position of non-core controls are adjusted according to the preset control priority. The font size of incomplete text controls is adjusted or the number of lines is increased, and the control distribution on the projection interface is optimized.

[0057] In this embodiment of the invention, the screen scaling factor can be specifically understood as: a screen scaling ratio calculated according to the available area size for projection on the computer and the physical resolution of the target terminal, based on the principle of proportionality, which determines the scaling range of the projected screen. The first principle can be specifically understood as: rules for adjusting the size of the projected screen, such as filling the long side and leaving a black border on the short side, to avoid interface distortion caused by forced stretching. The preset overlap ratio can be specifically understood as: the control overlap threshold that triggers layout rearrangement; when the overlap area between controls exceeds this ratio, the control layout adjustment operation is automatically initiated. The control priority can be specifically understood as: a pre-set importance level of the projection interface controls; core controls can be those that ensure core interactive functions, while non-core controls can be auxiliary display controls.

[0058] Specifically, the available projection area size is determined based on the computer's screen topology data. A scaling factor is calculated proportionally to the target terminal's physical resolution. If the resolution ratios of the two terminals are inconsistent, the projection image size is adjusted according to the first principle. Alternatively, non-core screen areas can be cropped to adapt the image and avoid interface distortion. Bilinear interpolation is then used for pixel scaling of the projection image. Hardware-accelerated rendering can be achieved through a graphics hardware acceleration interface, ensuring a smooth, jagged-free projection image and improving rendering efficiency and display quality. Then, it iterates through all controls on the projection interface, calculates the overlap area between controls using a control coordinate detection program, and checks the display integrity of text controls. When the overlap area of ​​controls exceeds a preset overlap ratio (e.g., 10%) or the text controls are not fully displayed, the size and position of non-core controls are adjusted according to the preset control priority, while the size of core controls remains unchanged. At the same time, the font size of incomplete text controls is adjusted or the number of lines is increased. For example, the font size is adjusted to a standard of no less than 12sp (Scaled Pixels). If it is still not fully displayed, the number of lines is increased. Meanwhile, the control distribution of the projection interface is optimized through the open-source HarmonyOS constraint layout engine. Fluid layout, elastic layout, and other methods can also be used to assist in optimization. Finally, the projection interface is adaptively adapted based on the physical resolution of the target terminal. It can scale and adapt the projection screen of other terminals according to the available area of ​​the PC screen, and it can also reversely project the PC screen to other terminals and complete the adaptive adaptation.

[0059] In a specific example, the pixel scaling algorithm is used to solve the problem of interface stretching or blurring caused by resolution mismatch. It ensures the smoothness of the image after scaling through bilinear interpolation and achieves low-latency rendering by relying on the graphics hardware acceleration interface. The complete implementation process can be divided into four steps: (1) Parameter acquisition and ratio calculation: The target terminal resolution and the available area size of the computer screen projection are obtained through the multi-screen adaptation unit of the hardware adaptation layer. The image scaling coefficient is calculated according to the proportional formula. If the resolution ratios of the two ends are inconsistent, the image size is adjusted according to the principle of filling the long side and leaving the short side with a black border, so as to fundamentally avoid the deformation of the interface. (2) Coordinate mapping and neighboring pixel calculation: The scaled pixel is mapped back to the floating-point coordinates of the original interface, the four neighboring pixels around the pixel are determined, and the weight value of each neighboring pixel is calculated according to the distance to ensure that the edges of the scaled image are smooth and without jagged edges. (3) Bilinear interpolation operation: The red, green and blue channels of the image are interpolated separately through the weighted average formula to ensure the color consistency of the scaled image.Return the default value: uint32_tBilinearInterpolation(uint8_t* srcData, int srcWidth, int srcHeight, floatux, float vy) { int i = floor(ux); int j = floor(vy); float a = ux - i; float b = vy -; j ; i = clamp ( i , 0 , srcWidth - 2 ) ; j = clamp ( j , 0 , srcHeight - 2 ) ; 1];uint32_t p10 = ((uint32_t*)srcData)[(j + 1) *srcWidth + i];uint32_t p11 = ((uint32_t*)srcData)[(j + 1) * srcWidth + i +1];uint8_t r = (uint8_t)((1 - a) * (1 - b) *; ((p00 >> 16) & 0xFF) + a * (1 -b) * ((p01 >> 16) & 0xFF) + (1 - a) * b * ((p10 >> 16) & 0xFF) + a * b *((p11 >> 16) & 0xFF));uint8_t g = (uint8_t)((1 - a) * (1 - b); * ((p00 >> 8) &0xFF) + a * (1 - b) * ((p01 >> 8) & 0xFF) + (1 - a) * b * ((p10 >> 8) & 0xFF)+ a * b * ((p11 >> 8) & 0xFF));uint8_t b = (uint8_t)((1 - a) * (1 - b) *; (p00&0xFF) + a*(1-b)*(p01&0xFF)+(1-a)*b*(p10&0xFF) +a*b*(p11&0xFF));return(0xFF << 24) | (r << 16) | (g << 8) | b;}.The formula can be: f(x,y) = (1-a)(1-b)f(i,j) + a(1-b)f(i+1,j) + (1-a)bf(i,j+1) + abf(i+1,j+1).

[0060] Here, `uint32_t BilinearInterpolation` is the function definition, returning a calculated 32-bit pixel value; `uint8_t* srcData` is a pointer to the original image pixel data, storing pixel information in RGBA (Red Green Blue Alpha) format; `int srcWidth` and `int srcHeight` are the width and height (in pixels) of the original image, respectively; `float ux` and `float vy` are the floating-point coordinates of the scaled target pixel mapped back to the original image, used to locate the reference position for interpolation calculation; `int i` and `int j` are integer coordinates rounded down from `ux` and `vy`, serving as the basis for locating neighboring pixels; `float a` and `float b` are floating-point differences between `ux`, `vy`, and their corresponding integer coordinates, representing the weight ratio of the target pixel among neighboring pixels; the `clamp` function is used to perform boundary processing on `i` and `j`, ensuring their values ​​are between 0 and `srcWidth-2` and between 0 and `srcHeight-2`, avoiding out-of-bounds pixel access; `uint32_t` p00, p01, p10, and p11 are the values ​​of the four neighboring pixels (RGBA format) around the target pixel in the original image, which are the data source for interpolation calculation; uint8_t r, g, and b are the red, green, and blue channel values ​​of the calculated pixel, respectively, obtained by weighting the corresponding channel values ​​of the four neighboring pixels according to the weights (1-a)(1-b), a(1-b), (1-a)b, and ab; in the formula f(x,y)=(1-a)(1-b)f(i,j)+ a(1-b)f(i+1,j) + (1-a)bf(i,j+1) + abf(i+1,j+1), f(x,y) is the final value of the target pixel, and f(i,j), f(i+1,j), f(i,j+1), and f(i+1,j+1) correspond to the values ​​of the four neighboring pixels. Smooth interpolation is achieved by combining the weight coefficients.

[0061] (4) Graphics hardware accelerated rendering: The rendering environment is initialized through the rendering environment initialization interface, the graphics processor resources are bound, and the screen is output in a double buffer mode after being processed by the vertex shader and fragment shader, which can adapt to full resolution scenes.The core shader and initialization code are as follows: attribute vec4 aPosition; attribute vec2 aTexCoord; uniform mat4 uMvpMatrix; varying vec2 vTexCoord; void main() { gl_Position = uMvpMatrix * aPosition; vTexCoord = aTexCoord;} precision mediump float; uniform sampler2D uTexture; varying vec2 vTexCoord; void main() { gl_FragColor = texture2D(uTexture, vTexCoord);} bool InitGLESEnv(EGLDisplay& display, EGLSurface& surface, EGLContext& context, int width, int height) { display = eglGetDisplay(EGL_DEFAULT_DISPLAY); eglInitialize(display, NULL, NULL); EGLConfig config; EGLint configCount; const EGLint attribs[] = { EGL_RED_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_BLUE_SIZE, 8, EGL_ALPHA_SIZE, 8, EGL_NONE}; eglChooseConfig(display, attribs, &config, 1, &configCount); surface = eglCreateWindowSurface(display, config, NULL, NULL); EGLint ctxAttribs[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE}; context = eglCreateContext(display, config, EGL_NO_CONTEXT, ctxAttribs); eglMakeCurrent(display, surface, surface, context); glViewport(0, 0, width, height); return true;}。The vertex shader consists of the following components: `attribute vec4 aPosition` is an attribute variable representing vertex coordinates, storing the four-dimensional coordinate information of the vertices in the graphic to be rendered; `attribute vec2 aTexCoord` is a texture coordinate attribute variable corresponding to the vertex, recording the two-dimensional coordinates of each vertex mapped onto the texture image; `uniform mat4 uMvpMatrix` is a globally consistent four-dimensional model-view projection matrix used for spatial transformations of vertex coordinates (such as scaling, translation, and projection); `varying vec2 vTexCoord` is a variable used to interpolate the texture coordinates of the vertices and pass them to the fragment shader; and `gl_Position` is a built-in variable of the vertex shader used to output the final coordinates of the vertices after matrix transformation. In the fragment shader section: `precision mediumpfloat` sets the floating-point precision to medium, balancing rendering efficiency and accuracy; `uniform sampler2D uTexture` is a 2D texture sampler that associates with the texture data of the projected image to be rendered; `varying vec2 vTexCoord` receives the texture coordinates passed from the vertex shader; `gl_FragColor` is a built-in variable of the fragment shader used to output the final color value of the current pixel, and `texture2D(uTexture, vTexCoord)` obtains the color of the corresponding pixel from the texture sampler using the texture coordinates. In the function `bool InitGLESEnv` that initializes the graphics rendering environment: `EGLDisplay& display` is a rendering display connection object used to associate the graphics rendering library with the system display device; `EGLSurface& surface` is a rendering surface object that carries the actual rendering drawing area; `EGLContext& context` is a rendering context object used to manage rendering state and resources; `int width` and `int height` are integer width and height of the rendering viewport; `EGLConfig config` is a rendering configuration object used to store rendering parameters such as color channel bit depth; `EGLint configCount` records the number of rendering configurations that meet the configuration conditions; `const EGLint attribs[]` defines rendering configuration attributes (8 bits each for red, green, blue, and alpha channels); `EGLint ctxAttribs[]` sets the version attribute of the rendering context (here, version 2.0); `glViewport(0,0,width,height)` sets the position and size of the rendering viewport, limiting the drawing area to a rectangular range from coordinates (0,0) to (width,height).

[0062] The layout rearrangement algorithm, based on pixel scaling, is used to solve the problems of control overlap and text truncation. It is implemented based on the open-source HarmonyOS constraint layout engine. The overall process can be divided into three steps: (1) Predefining constraint rules: Pre-setting basic rules such as control spacing, upper limit of text lines, and priority of core controls, defining the relative positional relationship between controls through constraint attributes, replacing the traditional nested layout method, and reducing the layout hierarchy. The core configuration code is as follows: <constraintlayout xmlns:ohos="http: / / schemas.huawei.com / res / ohos" ohos:width="match_parent" ohos:height="match_parent"> <button ohos:id="$+id / confirm_btn" ohos:width="120vp" ohos:height="40vp" ohos:text="确认" ohos:text_size="16fp" ohos:layout_constraintLeft_toLeftOf="parent" ohos:layout_constraintRight_toRightOf="parent" ohos:layout_constraintTop_toTopOf="parent" ohos:layout_marginTop="20vp">< / button> <Text ohos:id="$+id / desc_text" ohos:width="wrap_content" ohos:height="wrap_content" ohos:text="Description of Cross-device Collaboration Status" ohos:text_size="14fp" ohos:max_lines="2" ohos:layout_constraintTop_toBottomOf="$id / confirm_btn" ohos:layout_constraintLeft_toLeftOf="parent" ohos:layout_constraintRight_toRightOf="parent" ohos:layout_marginTop="8vp" / >< / constraintlayout> Among them, the root node <constraintlayout>To constrain the layout container, `xmlns:ohos` defines the HarmonyOS namespace, and `ohos:width="match_parent"` and `ohos:height="match_parent"` indicate that the layout's width and height both fill the parent container; core buttons <button>In the control, `ohos:id="$+id / confirm_btn"` sets a unique identifier for the button; `ohos:width="120vp"` and `ohos:height="40vp"` define the button width as 120 virtual pixels and the height as 40 virtual pixels, respectively; `ohos:text="Confirm"` sets the button's text to "Confirm"; `ohos:text_size="16fp"` defines the text font size as 16 font pixels; `ohos:layout_constraintLeft_toLeftOf="parent"` and `ohos:layout_constraintRight_toRightOf="parent"` constrain the button's left and right sides to align with the parent container (i.e., horizontally centered); `ohos:layout_constraintTop_toTopOf="parent"` constrains the button's top to align with the parent container's top; and `ohos:layout_marginTop="20vp"` sets the top margin of the button to 20 virtual pixels from the parent container; auxiliary text... <text>In the control, ohos:id="$+id / desc_text" sets a unique identifier for the text control; ohos:width="wrap_content" and ohos:height="wrap_content" indicate that the width and height of the text control adapt to the content size; ohos:text="Cross-device collaborative status description" sets the displayed text content; ohos:text_size="14fp" defines the text font size as 14 font pixels; ohos:max_lines="2" limits the text to a maximum of 2 lines; ohos:layout_constraintTop_toBottomOf="$id / confirm_btn" constrains the top of the text control to align with the bottom of the confirmation button; ohos:layout_constraintLeft_toLeftOf="parent" and ohos:layout_constraintRight_toRightOf="parent" constrain the text control to be horizontally centered; and ohos:layout_marginTop="8vp" sets the outer margin of the top of the text control and the bottom of the confirmation button to 8 virtual pixels.

[0063] (2) Layout Anomaly Detection: Iterate through all controls on the projection interface, calculate the overlapping area between controls, and check the display integrity of text controls; when the overlapping area of ​​controls exceeds 10%, or when text controls are not fully displayed, automatically trigger the layout reflow process. The core detection code is as follows: bool CheckLayoutAbnormal(std::vector< ...<UIControl*> controls, Rect parentRect) {for (size_t i = 0; i < controls.size(); i++) {for (size_t j = i + 1; j < controls.size(); j++) {Rect rect1 =controls[i]->GetRect();Rect rect2 = controls[j]->GetRect();int overlapWidth= min(rect1.right, rect2.right) - max(rect1.left, rect2.left);intoverlapHeight = min(rect1.bottom, rect2.bottom) - max(rect1.top, rect2.top);float overlapArea = (overlapWidth > 0 && overlapHeight > 0) ? (overlapWidth *overlapHeight) : 0;float totalArea = min(rect1.Width() * rect1.Height(),rect2.Width() * rect2.Height());if (overlapArea / totalArea > 0.1f) {returntrue;}}TextControl* textCtrl = dynamic_cast<TextControl*> (controls[i]);if(textCtrl != nullptr && !textCtrl->IsTextFullyDisplayed()) {return true;}}return false;}.The function `bool CheckLayoutAbnormal` is used to detect whether the layout of the control in the projection interface is abnormal and returns a boolean value (true means reflow is required, false means no reflow is required). `std::vector`<UIControl*> `controls` is a vector container storing pointers to all UI controls, including both core and non-core controls to be detected. `RectparentRect` is the rectangular area object of the parent container, defining the overall scope of the control layout. In the nested loop, `size_t i` and `size_t j` are the index values ​​for iterating through controls, used for pairwise comparisons. `Rect rect1` and `Rect rect2` are the rectangular area objects corresponding to the controls at indices i and j, respectively, and their position and size information are obtained using the `GetRect()` method. `int overlapWidth` and `int overlapHeight` calculate the width and height of the overlapping area between two controls, obtained by subtracting the maximum value from the left or top coordinate of the control from the minimum right or bottom coordinate. `float overlapArea` is the overlapping area between controls, calculated only when both the overlap width and height are greater than 0 (otherwise it is 0). `float totalArea` takes the smaller of the two control areas as the basis for calculating the overlap ratio. `overlapArea / totalArea > 0.1f` is a layout anomaly detection condition; when the overlap area exceeds 10%, a reflow is triggered and `true` is returned. `TextControl*` `textCtrl` is an object that casts a generic control pointer to a text control pointer. `dynamic_cast` is used for safe type conversion. `textCtrl != nullptr` checks if the conversion was successful. `!textCtrl->IsTextFullyDisplayed()` checks if there are any incomplete text controls. If so, it returns `true` to trigger a reflow. The function ultimately returns `false` to indicate that there are no overlap errors among the controls and the text is displayed completely, so no layout reflow is needed.

[0064] (3) Adjust the size, position, and text style of controls according to the preset control priority. Core controls retain their size and position, while non-core controls are scaled and adapted. The overall distribution of controls is further optimized after adjustment. The core code is as follows: void AdjustLayout(std::vector<int><UIControl*> controls, Rect parentRect) {for (auto& ctrl : controls) {if (ctrl->GetTag() == 0) {Rect currRect = ctrl->GetRect(); currRect.width = currRect.width * 0.8f; currRect.height =currRect.height * 0.8f; currRect.left = (parentRect.width - currRect.width) / 2;currRect.top = ctrl->GetRect().top;ctrl->SetRect(currRect);}TextControl*textCtrl = dynamic_cast<TextControl*> (ctrl);if (textCtrl != nullptr && !textCtrl->IsTextFullyDisplayed()) {float currSize = textCtrl->GetTextSize();if (currSize > 12) {textCtrl->SetTextSize(currSize - 2);} else {textCtrl->SetMaxLines(3);}}}UpdateConstraintChain(controls);}.The function `voidAdjustLayout` is used to adjust the layout of abnormal controls in the projection interface and has no return value; `std::vector`<UIControl*> `controls` is a vector container that stores pointers to all controls to be adjusted, including core and non-core controls; `Rect parentRect` is the rectangular area object of the parent container where the control is located, providing the overall size reference for layout adjustment; `auto& ctrl` in the loop are individual control references when traversing the control container, `ctrl->GetTag() == 0` distinguishes non-core controls (label 0) from core controls (label 1) by the control's label value, and only adjusts the size of non-core controls; `RectcurrRect = ctrl->GetRect()` gets the original rectangular area (including position and size) of the current non-core control, `currRect.width * 0.8f` and `currRect.height * 0.8f` reduce the width and height of the non-core control by 20% respectively; `currRect.left = (parentRect.width - currRect.width) / 2` recalculates the left coordinate of the control, making the control horizontally centered in the parent container, `currRect.top = ...` `ctrl->GetRect().top` keeps the top coordinates of the control unchanged, and `ctrl->SetRect(currRect)` applies the adjusted rectangular area to the control; `TextControl*textCtrl = dynamic_cast`<TextControl*> (ctrl) safely converts the general control pointer to a text control pointer, textCtrl != nullptr to check if the conversion was successful, !textCtrl->IsTextFullyDisplayed() checks if the text control is not fully displayed; float currSize = textCtrl->GetTextSize() gets the current font size of the text, currSize > 12 to determine if the font size is greater than 12 scaling pixels, if it is satisfied, then textCtrl->SetTextSize(currSize - 2) reduces the font size by 2 units, if it is not satisfied, then textCtrl->SetMaxLines(3) increases the maximum number of lines of text to 3; finally, UpdateConstraintChain(controls) calls the chain layout adjustment function, based on the adjusted control size and position, optimizes the overall distribution of all controls, and ensures that the layout of the projection interface is neat.

[0065] By calculating scaling factors based on computer screen topology data and target terminal physical resolution, and adjusting screen size proportionally, combined with pixel-level processing using bilinear interpolation, the system avoids screen stretching and blurring issues caused by cross-device resolution mismatch, ensuring smooth and complete screen display. In the layout rearrangement stage, by distinguishing between core and non-core controls, scaling is applied only to non-core controls. This ensures the position and size of core interactive controls remain unaffected while resolving layout overlap issues by compressing the space of non-core controls. For incomplete text controls, dynamic adaptation is performed according to rules, balancing text readability and interface layout rationality. Optimizing the overall control distribution through layout adjustments fundamentally solves the problems of control overlap and text truncation in traditional screen projection. Furthermore, differentiated control priority adjustments ensure the interactive experience of core functions, improving the accuracy and visual consistency of cross-device screen projection interface adaptation. Precise calculations and targeted adjustments at the algorithm level also reduce ineffective layout reconstruction operations, lower system resource consumption, and further guarantee the smoothness of screen projection interaction.

[0066] S150. When the functional module layer receives collaborative data forwarded by the application adaptation layer, and the core service layer has started encrypted soft bus transmission, the functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that meets the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index.

[0067] In this embodiment of the invention, the classification transmission identifier can be specifically understood as: an identifier assigned to collaborative data according to the priority of collaborative tasks, used to distinguish collaborative data of different types or priorities, and to ensure transmission order. The fragmentation and indexing can be specifically understood as: for processing ultra-large file-type collaborative data that meets preset standards (such as greater than or equal to 1 gigabyte), the data is split into multiple small fragments and a unique index is generated for each fragment, facilitating fragmented transmission and subsequent complete assembly.

[0068] S160. Respond to the user-initiated collaboration termination request through the application adaptation layer, forward the collaboration termination request to the core service layer, and after the core service layer passes the integrity verification of the collaboration data, restore the collaboration-related state on the computer to the initial state before the collaboration task request was executed.

[0069] In this embodiment of the invention, the integrity verification of collaborative data can be specifically understood as: the core service layer performing a verification operation on the transmitted collaborative data at the end of the collaboration phase to ensure that the data is neither lost nor damaged. The restoration of collaboration-related states can be specifically understood as: restoring the hardware and software states (such as multi-screen mode and screen projection adaptation parameters) on the computer side that have changed due to the execution of the collaborative task to their initial state before the task execution.

[0070] Specifically, the functional module layer receives collaborative data forwarded by the application adaptation layer. Under the premise that the core service layer has started encrypted soft bus transmission, it assigns a classification transmission identifier to the data according to the priority of the collaborative task matched by the collaborative data (the priority can also be dynamically adjusted according to the data type or transmission timeliness requirements). Collaborative data that meets the preset standards (i.e., ultra-large file collaborative data) is split into multiple fragments and a unique index is generated for each fragment. Then, based on the classification transmission identifier and fragment index, the collaborative data transmission is completed through the encrypted soft bus, ensuring the stability and orderliness of large file transmission.

[0071] The application adaptation layer responds to the user's request to end collaboration and forwards it to the core service layer. The core service layer performs integrity verification on the completed collaboration data, such as through hash verification, fragment index comparison, or parity check. After the verification is successful, the collaboration-related states on the computer side, such as multi-screen mode, projection parameters, and control layout (some states can also be selectively retained according to user needs), are restored to the initial state before the collaboration task request was executed.

[0072] The technical solution of this invention, through the application adaptation layer responding to collaborative task requests and forwarding parameters to the core service layer, establishes an encrypted soft bus connection, enabling secure and stable interconnection between the computer and the target terminal, avoiding the risk of data leakage during the collaboration process. Simultaneously, standardized collaborative interface calls improve the efficiency of collaborative request forwarding and reduce redundancy between layers. The core service layer collects hardware status data and dynamically allocates the proportion of multiple resource pools based on collaborative function type, resource demand coefficient, and user attention weight, achieving precise resource scheduling, avoiding resource waste, ensuring the smooth operation of high-priority collaborative tasks, and adapting to different hardware states to achieve flexible resource allocation and improve the compatibility of the collaborative system. The functional module layer listens to various collaborative events and serializes and compresses cross-device operation event data for transmission, reducing data transmission bandwidth consumption, improving the response speed of keyboard and mouse operation, and achieving seamless cross-device operation. Through pixel scaling and layout... The rearrangement algorithm adapts to the projection interface based on the physical resolution of the target terminal, solving problems such as screen stretching, control overlap, and text truncation when projection across devices, thus improving the projection display effect and user viewing experience. The functional module layer assigns classification transmission identifiers according to the priority of collaborative tasks, and transmits standard-compliant collaborative data after fragmentation and indexing. This ensures orderly and efficient transmission of collaborative data, guaranteeing that high-priority data is transmitted first. Furthermore, fragmented transmission combined with index management allows for the retransmission of only missing or erroneous fragments after transmission interruption, improving data transmission integrity and efficiency while reducing resource consumption from repeated transmissions. The application adaptation layer responds to the collaboration end request, and the core service layer restores the computer-side collaboration-related state after data integrity verification. This ensures closed-loop operation of collaborative tasks, avoids resource occupation residue, improves system stability and reliability, and optimizes open-source HarmonyOS computer desktop collaboration, balancing collaboration security, efficiency, smoothness, and user experience.

[0073] Example 2 Figure 2 This is a flowchart of another computer desktop collaborative optimization method based on open-source HarmonyOS provided in Embodiment 2 of the present invention. This embodiment is a refinement of the "establishing an encrypted soft bus connection between the computer and the target terminal through the core service layer" in the above embodiment. Figure 2 As shown, the method includes: S210. The application adaptation layer responds to the user-initiated collaborative task request, determines the matching target terminal, collaborative function type, and custom interaction parameters, and forwards the request carrying the above parameters to the core service layer by calling the standardized collaborative interface. The core service layer checks the current connection status between the computer and the target terminal. If no connection is established, the target terminal is scanned by broadcast. After key negotiation is performed through the encryption algorithm and a temporary session key is generated, an encrypted soft bus connection is established based on the temporary session key.

[0074] In this embodiment of the invention, the temporary session key can be specifically understood as a one-time key generated after negotiation, used for subsequent encrypted data transmission.

[0075] S220. If a connection has already been established, enable the existing encrypted soft bus connection.

[0076] Specifically, the application adaptation layer responds to user-initiated collaborative task requests by determining the matching target terminal, collaborative function type, and custom interaction parameters. After forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, the core service layer checks the current connection status between the computer and the target terminal. If no connection has been established, it scans for the target terminal by broadcasting, such as sending UDP (User Datagram Protocol) broadcasts at 100-millisecond intervals on port 5555. The broadcast content carries the PC device identifier and the digest of the open-source HarmonyOS certificate.

[0077] The target terminal listens to the corresponding port through the terminal access layer. After receiving the broadcast, it pushes a collaboration invitation to the user. After the user confirms and agrees, both ends perform key negotiation through an encryption algorithm and generate a temporary session key. For example, if the RSA-2048-bit encryption algorithm is used to complete the key negotiation, an AES-256 (Advanced Encryption Standard 256-bit) temporary session key is generated. An encrypted soft bus connection is established based on this temporary session key, and the connection status monitoring unit marks the connection as successful. In addition, the entire encrypted transmission mechanism also supports automatic rotation and rapid revocation of the temporary session key every preset time interval (e.g., 30 minutes), has financial-grade security strength, and is compatible with all ecosystem terminals. If the two ends have already established a connection, the existing encrypted soft bus connection is directly activated.

[0078] S230: Collect hardware status data through the core service layer, determine the priority of the collaborative task based on the collaborative function type, and calculate the corresponding resource demand coefficient and user attention weight. After dynamically allocating the resource ratio of multiple resource pools for the collaborative task based on the priority, resource demand coefficient and user attention weight, start encrypted soft bus transmission.

[0079] Optionally, based on the above embodiments, the priority of the collaborative task is determined by combining the collaborative function type, and the corresponding resource requirement coefficient and user attention weight are calculated. After dynamically allocating the resource ratio of multiple resource pools to the collaborative task based on the priority, resource requirement coefficient, and user attention weight, the encrypted soft bus transmission is initiated, which may include: The priority of each collaborative task is determined based on hardware status data and collaborative function type; resource demand coefficients are calculated based on historical collaborative data, and user attention weights are determined through window focus detection; based on the priority, resource demand coefficients, and user attention weights of each collaborative task, a multi-dimensional weighted round-robin algorithm is used to dynamically allocate resource ratios from multiple resource pools to each collaborative task, and it is verified whether the allocated resources meet the task's running requirements. If resources are insufficient, a dynamic degradation strategy is triggered; if resources are sufficient, encrypted soft bus transmission is initiated. The resource pools include: a central processing unit resource pool, a memory resource pool, a graphics processing unit resource pool, a network bandwidth resource pool, and a storage input / output resource pool.

[0080] In this embodiment of the invention, the multi-dimensional weighted round-robin algorithm can be specifically understood as a scheduling algorithm that allocates system resources based on the final weight of each task. The final weight can be specifically understood as a parameter used for resource allocation, calculated jointly by priority, remaining hardware resources, resource demand coefficient, and user attention weight. The dynamic degradation strategy can be specifically understood as reducing non-critical parameters when resources are insufficient, without compromising core functionality, to ensure the stable operation of high-priority tasks.

[0081] Specifically, task priorities are determined based on hardware status data and collaborative function types. For example, real-time screen sharing is set as high priority, and large file transfer is set as medium priority. Then, the corresponding resource requirement coefficients are calculated based on historical collaborative data. Screen sharing has a higher resource requirement coefficient because it relies on the computing power of the graphics processor, while file transfer focuses on storage and bandwidth resources and has a relatively lower resource requirement coefficient. The user attention weight is determined by window focus detection, with foreground focus tasks having a higher weight than background tasks.

[0082] Then, the final weight is calculated based on the priority, resource demand coefficient, user attention weight, and the remaining proportion of hardware resources (resource pool). For example, the final weight = task priority × remaining proportion of hardware resources × resource demand coefficient × user attention weight, where the resource demand coefficient = historical average resource consumption of the task / average consumption of similar tasks.

[0083] A multi-dimensional weighted round-robin algorithm dynamically allocates resource proportions from multiple resource pools, including central processing unit, memory, graphics processing unit, network bandwidth, and storage input / output, to each collaborative task. The allocated resource proportion is calculated as: (final weight of the target task / sum of the final weights of all collaborative tasks) × total available resources.

[0084] After allocation, the core service layer checks whether the resources meet the task's running requirements. If the resources are insufficient, a dynamic degradation strategy is triggered, reducing non-core performance parameters such as resolution for high-priority tasks and switching low-priority tasks to run in the background at low speed. If the resources are sufficient, the improved encrypted soft bus transmission is started directly, using a redundant error correction protocol and configuring transmission parameters according to the allocated bandwidth to achieve efficient, stable, and secure transmission across devices.

[0085] It should be emphasized that the improved encrypted soft bus can be specifically understood as: an encrypted soft bus that is specifically optimized based on the native OpenHarmony soft bus and combined with the resource scheduling results of the embodiments of this invention. For example, it adopts differentiated transmission strategies for different priority tasks such as real-time screen sharing and file transfer, uses UDP and FEC (Forward Error Correction) methods to ensure low latency for high-priority real-time data, and uses TCP (Transmission Control Protocol) for file transfer. The protocol (transmission control protocol) is combined with breakpoint resumption to ensure integrity and the transmission rate is configured according to dynamically allocated bandwidth resources, thus improving the transmission protocol level. The resource occupation of bus transmission is dynamically adjusted according to the resource ratio calculated by multi-dimensional weighted polling to avoid competing with other tasks for bandwidth, GPU and other resources. At the same time, the transmission parameters (such as resolution and bit rate) are adjusted synchronously with dynamic degradation strategy to ensure stable transmission even when resources are scarce, thus improving the transmission scheduling level. RSA-2048 key negotiation and AES-256 encryption are adopted and automatic key rotation is supported. At the same time, data fragmentation, index verification and breakpoint resumption mechanism are combined to improve the efficiency of large file transmission and interruption recovery capability, thus improving security and efficiency, thereby achieving deep matching with the resource scheduling logic mentioned above.

[0086] Understandably, an alternative to the weighted round-robin algorithm could be a long short-term memory network model, which uses training data to predict task resource requirements, thereby achieving more accurate resource allocation.

[0087] In a specific example, the dynamic degradation strategy is implemented through dynamic threshold configuration, degradation triggering and execution, and an automatic recovery mechanism: Real-time monitoring of remaining resource ratios allows for differentiated thresholds to be set for different tasks, with adaptive fine-tuning based on computer performance; the system monitors resource status every 100 milliseconds, executing corresponding degradation operations based on task type when resources are insufficient; and automatically restores the original configuration when the resource ratio recovers above the threshold, ensuring a seamless switching process. Cross-resource pool collaborative scheduling is achieved by constructing a resource association matrix, employing a collaborative scheduling algorithm, and setting a local resource reservation mechanism: defining correlation coefficients between resource pools ensures allocation synergy; adjusting allocation values ​​based on matrix operations and a weighted round-robin model avoids single resource bottlenecks; reserving basic resources for critical system tasks and using isolation mechanisms to prevent excessive preemption by collaborative tasks from causing system lag.

[0088] Correspondingly, the method interface for this part can be set as the input interface: SetTaskPriority(uint32_ttaskId, uint8_t priority, uint8_t taskType, uint32_t historyConsume[]); and the output interface: ResourceAllocationResult(uint32_t taskId, CPUInfo cpu, MemInfo mem, GPUInfo gpu, BandwidthInfo bw, IOInfo io, bool isDegraded, uint8_tdegradeLevel). The input interface `SetTaskPriority` is used to set the task priority. `uint32_t taskId` is the unique identifier of the task, `uint8_t priority` represents the task priority level, `uint8_t taskType` is used to distinguish the task type, and `uint32_t historyConsume[]` is an array of historical CPU, memory, and GPU consumption data, used for calculating resource demand coefficients. The output interface `ResourceAllocationResult` is used to return the resource allocation result. `uint32_t taskId` corresponds to the task identifier, `CPUInfo cpu`, `MemInfo mem`, `GPUInfo gpu`, `BandwidthInfo bw`, and `IOInfo io` represent the allocation information of CPU, memory, GPU, network bandwidth, and storage IO, respectively. `bool isDegraded` marks whether resource degradation has been triggered, and `uint8_t degradeLevel` represents the degree of degradation (0 for no degradation, 1 for mild degradation, and 2 for moderate degradation).

[0089] By combining collaborative function types to determine the priority of collaborative tasks, and calculating resource demand coefficients and user attention weights based on historical collaborative data and window focus detection, the system can comprehensively quantify task characteristics from multiple dimensions, including task importance, resource consumption patterns, and user scenarios. Then, relying on a multi-dimensional weighted polling algorithm, it dynamically allocates resources across multiple resource pools, including the CPU, memory, GPU, network bandwidth, and storage input / output. This makes resource allocation more aligned with actual task requirements and user habits. Furthermore, by verifying whether resources meet operational needs, a dynamic degradation strategy is triggered when resources are insufficient, and encrypted soft bus transmission is directly initiated when resources are sufficient. This avoids resource contention and waste, improves the overall utilization of hardware resources, ensures the stable and smooth operation of high-priority, high-user-attention collaborative tasks, and also ensures the normal execution of low-priority tasks. This achieves intelligent, efficient, and stable resource scheduling improvements during cross-device collaboration.

[0090] S240: Listen to cross-device operation, screen mirroring startup, and collaborative data transmission events through the functional module layer. When cross-device operation event data is collected through the functional module layer, serialize and compress the cross-device operation event data, and transmit it to the target terminal through an encrypted soft bus to execute the computer's keyboard and mouse control of the target terminal.

[0091] S250: When the physical resolution of the target terminal is collected through the functional module layer and the screen projection start command is received, the screen projection interface is adaptively adapted based on the physical resolution of the target terminal through pixel scaling algorithm and layout rearrangement algorithm.

[0092] S260. When the functional module layer receives collaborative data forwarded by the application adaptation layer, and the core service layer has started encrypted soft bus transmission, the functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that conforms to the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index.

[0093] S270. Respond to the user-initiated collaboration termination request through the application adaptation layer, forward the collaboration termination request to the core service layer, and after the core service layer passes the integrity verification of the collaboration data, restore the collaboration-related state on the computer to the initial state before the collaboration task request was executed.

[0094] The technical solution of this invention responds to collaborative task requests and forwards parameters to the core service layer through an application adaptation layer. Pre-connection status checks avoid resource consumption from repeated connection establishment, improving the efficiency of collaborative connection establishment. Simultaneously, the broadcast scanning method eliminates dependence on specific hardware, adapting to multiple brands and types of terminals within the open-source HarmonyOS ecosystem, breaking down terminal compatibility barriers. By negotiating and generating temporary session keys through encryption algorithms and establishing a soft bus connection based on these keys, an encrypted transmission channel is built for cross-device data transmission, mitigating the risk of data leakage during transmission from the communication layer. This solves the problem of existing collaborative solutions lacking a unified encrypted transmission mechanism, improving the security of cross-device collaboration. Differentiated connection processing logic ensures the security and standardization of new connection establishment while enabling the rapid activation of existing connections, reducing user operation waiting time and simplifying the initial connection process for cross-device interaction. Furthermore, this encrypted soft bus connection, built on the open-source HarmonyOS ecosystem, is compatible with the ecosystem's key system, further strengthening the seamless interconnection capability of multiple terminals within the open-source HarmonyOS ecosystem. This lays a secure, stable, and efficient communication foundation for subsequent cross-device data transmission, keyboard and mouse control, screen projection, and other collaborative operations. The core service layer collects hardware status data and dynamically allocates the proportion of multiple resource pools based on the type of collaborative function, resource demand coefficient, and user attention weight. The functional module layer listens for various collaborative events, serializes and compresses cross-device operation event data for transmission, adapts the projection interface based on the physical resolution of the target terminal through pixel scaling and layout rearrangement algorithms, assigns classification transmission identifiers according to the priority of collaborative tasks, and transmits standard-compliant collaborative data after fragmentation and indexing. The application adaptation layer responds to the collaboration end request, and the core service layer restores the computer-side collaborative state after completing data integrity verification, thus optimizing the open-source HarmonyOS computer desktop collaboration.

[0095] Example 3 Figure 3 This is a flowchart of another computer desktop collaborative optimization method based on open-source HarmonyOS provided in Embodiment 3 of the present invention. This embodiment is a refinement of the "serialization and compression of cross-device operation event data and transmission to the target terminal via an encrypted soft bus" in the above embodiment. Figure 3 As shown, the method includes: S310. Responding to the user-initiated collaborative task request through the application adaptation layer, the target terminal, collaborative function type, and custom interaction parameters are determined. After forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, an encrypted soft bus connection between the computer and the target terminal is established through the core service layer.

[0096] S320: Collect hardware status data through the core service layer, determine the priority of the collaborative task based on the collaborative function type, and calculate the corresponding resource demand coefficient and user attention weight. After dynamically allocating the resource ratio of multiple resource pools for the collaborative task based on the priority, resource demand coefficient and user attention weight, start encrypted soft bus transmission.

[0097] S330 listens for cross-device operation, screen mirroring startup, and collaborative data transmission events through the functional module layer. When cross-device operation event data is collected through the functional module layer, it converts the cross-device operation event data into the open-source HarmonyOS unified input format, performs serialization compression through the protocol buffer algorithm, and transmits the compressed cross-device operation event data to the target terminal through an encrypted soft bus based on the dynamic mapping relationship between the computer's multi-screen coordinate system and the target terminal's coordinate system, so as to execute the computer's keyboard and mouse to control the target terminal.

[0098] In this embodiment of the invention, cross-device operation events can be specifically understood as: input operations such as keyboard and mouse movement, clicking, or swiping generated by the user on the computer. The open-source HarmonyOS unified input format can be specifically understood as: a standard input event format applicable across devices, used to ensure compatibility with input commands from different devices. The protocol buffering algorithm can be specifically understood as: a data serialization compression method, such as Protobuf, which can remove redundant fields. The dynamic mapping relationship can be specifically understood as: real-time conversion rules between computer screen coordinates and target terminal screen coordinates.

[0099] Specifically, the system monitors cross-device operation, screen mirroring, and collaborative data transmission events through the functional module layer. When cross-device operation event data is collected through the functional module layer, it is converted into the open-source HarmonyOS unified input format. The data is then serialized and compressed using a protocol buffer algorithm. Based on the dynamic mapping relationship between the computer's multi-screen coordinate system and the target terminal's coordinate system, the coordinate transformation is completed. The compressed event data is then transmitted to the target terminal via an encrypted soft bus. After receiving the data, the target terminal parses and simulates touch commands, enabling seamless, low-latency control of the target terminal by the computer's keyboard and mouse. The operation results can also be transmitted back in real time to ensure interactive continuity.

[0100] S340. When the physical resolution of the target terminal is collected through the functional module layer and the screen casting start command is received, the screen casting interface is adaptively adapted based on the physical resolution of the target terminal through pixel scaling algorithm and layout rearrangement algorithm.

[0101] S350. When the functional module layer receives collaborative data forwarded by the application adaptation layer, and the core service layer has started encrypted soft bus transmission, the functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that meets the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index.

[0102] Optionally, based on the above embodiments, after assigning classification transmission identifiers to the collaborative data according to the priority of the collaborative tasks matching the collaborative data, splitting the collaborative data that conforms to preset standards into multiple fragments, and generating an index for each fragment, the collaborative data is transmitted through an encrypted soft bus according to the classification transmission identifiers and indexes, including: Based on the priority of collaborative tasks, classification transmission identifiers are assigned to collaborative data; collaborative data conforming to preset standards is split into multiple blocks and fragments matching each block according to preset specifications; an index is assigned to each fragment and a fragment checksum is generated, and a block checksum is generated for each block; a fragment index table is constructed, containing the index, fragment checksum, block checksum, transmission status, and storage location; the fragment index table and transmitted fragment data are synchronously cached on the computer and the target terminal, with data synchronization completed according to storage location and index table identifiers updated according to transmission status; collaborative data is transmitted via an encrypted soft bus according to the priority order of classification transmission identifiers and the index order of the fragment index table, with fragment checksums updated during transmission. The verification code performs integrity checks on the fragmented data. Upon successful verification, the corresponding fragment's transmission status in the fragment index table is updated to "completed," and synchronized to the target terminal. Once all fragments under any given block have been transmitted and verified, the block's overall integrity is checked based on the block's verification code. Upon successful verification, the block's transmission status is updated to "block complete." If transmission is interrupted, after re-establishing the encrypted soft bus connection, the sender requests the receiver's fragment index table and, by comparing the indexes, transmission statuses, and verification codes of both tables, identifies missing or incorrectly verified fragments. All missing or incorrectly verified fragments are retransmitted via the encrypted soft bus. After retransmission, the fragment index table is updated, and the operation of transmitting collaborative data via the encrypted soft bus is returned.

[0103] In this embodiment of the invention, collaborative data can be specifically understood as: business data transmitted across devices, including screen sharing, files to be transmitted, and interactive data of cross-device linked applications. Preset standard can be specifically understood as: the criteria for determining whether a large file is fragmented, such as being greater than or equal to 1 gigabyte. Chunk and fragmentation can be specifically understood as: data units obtained by first splitting a large file according to preset specifications, such as first splitting a large file into large chunks of approximately 1 gigabyte, and then splitting each chunk into multiple smaller fragments of approximately 1 megabyte, facilitating stable transmission. Fragment checksum can be specifically understood as: a parameter used to verify whether a single fragment of data is complete and undamaged, such as CRC32 (Cyclic Redundancy Check 32-bit). Chunk checksum can be specifically understood as: a parameter used to verify whether the entire chunk is complete, such as MD5 (Message-Digest Algorithm 5). Fragment index table can be specifically understood as: a management table recording the index, checksum, transmission status, and storage location of all fragments.

[0104] Specifically, the functional module layer determines the priority of collaborative tasks based on different collaborative task types such as real-time audio and video, files, and status synchronization. It assigns classification transmission identifiers to collaborative data such as screen sharing, file transfer, and interactive commands. For example, high-priority data is marked as priority transmission, and medium-priority data is marked as normal transmission, ensuring that high-priority data occupies transmission resources first. At the same time, oversized files exceeding the preset standard are split into multiple large blocks according to preset specifications, and each block is further split into multiple small fragments. An index and fragment check code are generated for each fragment, such as an index in the format of fragment ID_fragment sequence number and a CRC32 check code. A corresponding fragment check code is generated for each fragment, and a fragment index table containing the index, fragment check code, block check code, transmission status, and storage location is constructed. The index table and the transmitted fragments are synchronously cached in the distributed cache of the computer and the target terminal. According to the priority of the classification transmission identifier and the order of the index table, the collaborative data is transmitted sequentially through the encrypted soft bus. After each fragment transmission is completed, the fragment check code is checked. After the check passes, the transmission status is updated and synchronized to the other end. When all fragments under a block are transmitted, the entire block is checked again through the block check code. After the check passes, the transmission status is updated and synchronized to the other end.

[0105] If a transmission interruption occurs, the fragment index tables at both ends will be compared after the encrypted soft bus connection is re-established. The missing or incorrect fragments will be automatically selected and the interruption will be resumed to avoid repeated transmission. At the same time, the transmission rate can be dynamically adapted by combining the adaptive bandwidth adjustment mechanism to ensure efficient and stable transmission.

[0106] Understandably, an alternative to the improved soft bus protocol can be an architecture that combines 5G (5th Generation) with edge computing, enabling long-distance collaboration between devices by forwarding data to edge nodes through the 5G network.

[0107] In a specific example, the encrypted soft bus based on the improved soft bus protocol, unlike the traditional fixed-rate strategy, adopts a dynamic bandwidth and data type linkage adjustment algorithm. It can optimize transmission parameters according to network bandwidth and data type (real-time audio / video, file, status synchronization) to meet the needs of real-time audio / video with low latency, file transmission with integrity, and status synchronization with real-time performance. It adopts a distributed fragmentation caching and verification mechanism to break through the single-device caching limitation. After large files are fragmented, index and verification information are cached synchronously on both ends, supporting breakpoint resume and seamless switching across networks, improving retransmission efficiency. It adopts a dual-key encrypted transmission system to balance security and compatibility. Based on the open-source HarmonyOS unified device certificate negotiation temporary session key, it supports automatic key rotation and fast revocation, and can be adapted to all ecosystem terminals.

[0108] The encrypted soft bus interface based on the improved soft bus protocol provides directly callable input and output interfaces. The input interface is: TransmitData(uint8_t* data, uint32_t len, uint8_t dataType, bool isLargeFile), and the output interface is: TransmitStatus(uint8_t status, uint32_t progress, uint32_t blockId, uint32_t missingShardId[]). The input interface `TransmitData` is used to initiate data transmission. `uint8_t* data` is a pointer to the data to be transmitted, `uint32_t len` represents the data length, `uint8_t dataType` is used to identify the data type (1 for real-time audio / video, 2 for file, 3 for status synchronization), and `boolisLargeFile` is used to mark whether it is a large file. The output interface `TransmitStatus` is used to return the transmission result. `uint8_t status` represents the current transmission status, `uint32_t progress` represents the transmission progress, `uint32_t blockId` is the block number of the current transmission, and `uint32_t missingShardId[]` is an array of missing shard IDs, which can be used to achieve accurate retransmission of shards.

[0109] Correspondingly, after the user completes screen control and file transfer, they click the "End Collaboration" button on the computer. The application adaptation layer captures the instruction and sends a termination signal to the core service layer. Subsequently, the core service layer verifies the integrity of the file and screen-shared data transmission through the breakpoint resume unit. After confirming that there are no errors, it disconnects the encrypted soft bus connection, destroys the temporary session key, clears the shard index table in the distributed cache, releases various hardware resources, and resets the interaction and interface states of the functional module layer and the application adaptation layer respectively, so that the system returns to the initial state.

[0110] By assigning classification transmission identifiers to collaborative data according to the priority of collaborative tasks, priority can be given to the transmission resources of high-priority collaborative data, improving the real-time performance and stability of high-priority collaborative tasks. Collaborative data conforming to preset standards is processed into blocks and fragments, and a corresponding checksum is generated for each block and fragment. Simultaneously, a fragment index table containing key information is constructed and cached synchronously on both ends. This achieves both ordered transmission of large files and ensures the integrity of each block and fragment through dual verification using fragment checksums and block checksums, preventing data loss or corruption during transmission. Transmission is performed according to priority and index order, further optimizing the transmission order and ensuring the priority completion of core tasks. Successfully implemented: After a transmission interruption, missing or erroneous fragments are filtered by comparing the dual-end fragment index table, and only those fragments are retransmitted, eliminating the need to retransmit the entire data from scratch. This reduces the amount of data transmitted repeatedly, improves transmission efficiency and interruption recovery capabilities, and lowers network resource consumption. Dual-end synchronous caching of the index table and fragment data also enables seamless connection during cross-network switching. Combined with the secure transmission characteristics of the encrypted soft bus, it balances the security, integrity, and orderliness of collaborative data transmission while improving transmission efficiency, interruption recovery capabilities, and scenario adaptability. This solves problems such as chaotic data transmission, low efficiency in large file transmission, cumbersome retransmission after interruption, and easy data loss in traditional cross-device collaboration, thus improving the data transmission experience in cross-device collaboration.

[0111] S360 responds to the user-initiated collaboration termination request through the application adaptation layer, forwards the collaboration termination request to the core service layer, and after the core service layer passes the integrity verification of the collaboration data, restores the collaboration-related state on the computer to the initial state before the collaboration task request was executed.

[0112] Figure 4 This is a schematic diagram of a computer desktop collaborative optimization system based on the open-source HarmonyOS, applicable to an embodiment of the present invention. Figure 4 As shown, the system comprises an application adaptation layer, a functional module layer, a core service layer, a hardware adaptation layer, and a terminal access layer. The application adaptation layer includes collaborative application interfaces, audio / video collaborative applications, file collaborative applications, and multi-task management applications, serving as the entry point for user interaction with the system. The functional module layer addresses the needs of the application adaptation layer, deploying cross-device interaction modules, interface adaptive adaptation modules, input device mapping modules, data transmission control modules, and data priority classification modules for the specific implementation of collaborative tasks. The core service layer is the system's scheduling core, integrating intelligent resource scheduling services, improved soft bus services, collaborative link management services, weighted polling resource allocation services, distributed communication services, and unified key authentication services, coordinating resource allocation, connection management, data encryption, and transmission scheduling. The hardware adaptation layer provides PC hardware abstraction interfaces, CPU / GPU / memory acquisition services, multi-screen PC adaptation services, and OpenHarmony kernel adaptation services, achieving system-hardware compatibility. The terminal access layer serves as the access carrier for collaborative terminals, supporting OpenHarmony... PC terminals, tablet terminals, mobile terminals, and other OpenHarmony terminals can access the system, and through the collaboration of various levels, a full-process computer desktop collaborative optimization system covering application interaction, function execution, service scheduling, hardware adaptation, and terminal access can be built.

[0113] In a specific example, the application adaptation layer serves as the upper-layer entry point, providing standardized collaborative interfaces to connect with various collaborative applications. Cross-device functionality can be achieved simply by calling these interfaces. The functional module layer is used for the implementation of specific collaborative functions and may include core units such as input device mapping, interface adaptive adaptation, and data priority classification. It adopts a modular design, supports independent deployment and upgrades, and allows customization of parameters such as screen edge trigger distance, trigger sensitivity, and file chunk size. Its interface adaptive adaptation unit uses pixel scaling and layout rearrangement algorithms as its core to ensure consistent cross-screen display. The core service layer provides core capabilities, consisting of an improved soft bus protocol, task priority evaluation, and collaborative connectivity. The system comprises management services and corresponding sub-units. Its service-oriented design allows for independent module upgrades, dynamic resource allocation based on hardware status and task requirements, and encrypted connections with mobile terminals. It monitors operational status throughout the process, ensuring collaborative stability. The hardware adaptation layer shields PC hardware differences, adapting to various graphics cards and network cards through hardware abstraction interfaces, resource acquisition units, and monitoring units. It automatically identifies multi-screen splicing modes and resolutions, providing a complete hardware topology to the core service layer. The terminal access layer serves as a unified entry point for various OpenHarmony terminals, adhering to a unified communication interface specification. Adding a new terminal only requires adapting the communication interface, without modifying the upper-layer logic, demonstrating excellent scalability.

[0114] Understandably, an alternative to the hardware adaptation layer could be to use QEMU (Quick Emulator) to virtualize the hardware abstraction layer, thereby shielding the differences between different PC hardware through virtualization technology.

[0115] Figure 5 This is a schematic diagram illustrating a computer desktop collaboration optimization based on the open-source HarmonyOS, applicable to an embodiment of the present invention. Figure 5 As shown, the process includes: initialization and device connection, resource allocation and verification, interaction and file transfer, and termination of collaboration phases. In the initialization and device connection phase, the user first selects collaborative tasks such as screen sharing and 10GB (gigabyte) file transfer, and customizes parameters such as mapping edge and sensitivity. After the application adaptation layer calls the initialization interface, the core service layer checks the device connection status. If not connected, the terminal is discovered via UDP broadcast and RSA-256 key negotiation authentication is completed. If connected, the functional module layer initializes input mapping, interface adaptation and multi-screen recognition, and mobile phone resolution acquisition. In the resource allocation and verification phase, the core service layer first collects the hardware status of CPU, memory, GPU, etc., and determines the task priority (e.g., screen sharing P=9, file transfer P=7). The task priority parameter P ranges from 1 to 10, which is a standardized value set by this embodiment to quantify the importance of collaborative tasks and resource scheduling priority. The larger the value, the higher the task priority, and the more priority it occupies system resources in resource allocation and transmission scheduling. P=1-3 can be low priority, such as state synchronization tasks, and P=4-7 is medium priority. Priorities are assigned (e.g., file transfer task priority P=7, P=8-10 is high priority, real-time screen sharing task priority P=9, real-time audio / video call task priority P=10). Resource coefficients are calculated, and resources such as CPU 40%, memory 30%, GPU 50%, and bandwidth 800Mbps are allocated. Resource validity is verified, and if insufficient, a degradation strategy is triggered (e.g., screen resolution is reduced). If sufficient, encrypted soft bus transmission (UDP combined with FEC, 800Mbps) is initiated. During the interaction and file transfer phase, the user moves the mouse to the right edge 30px to trigger keyboard and mouse control of the phone, or drags a 10GB file to the projection interface. The functional module layer classifies the data (high / medium priority), divides the file into 10 1GB blocks and generates CRC32 checksums. During transmission, breakpoint resumption verification is performed, and the projection interface is adapted (pixel scaling combined with layout rearrangement). When the collaboration ends, the user clicks "End Collaboration," and the core service layer verifies the transmission completion (fragmented MD5 aggregation, overall verification), disconnects the connection, destroys the encrypted channel, releases hardware resources, and completes the closed loop of the entire collaboration process.

[0116] The technical solution of this invention involves the application adaptation layer responding to collaborative task requests and forwarding parameters to the core service layer. The core service layer establishes an encrypted soft bus connection, collects hardware status data, and dynamically allocates the proportion of multiple resource pools based on the collaborative function type, resource requirement coefficient, and user attention weight. The functional module layer monitors various collaborative events. Converting cross-device operation event data into the unified input format of open-source HarmonyOS breaks down the input protocol barriers between different terminals, enabling standardized parsing of multi-terminal input events within the open-source HarmonyOS ecosystem. This avoids operational response anomalies caused by format incompatibility and improves the compatibility of cross-device interaction. The standardized event data is serialized and compressed using a protocol buffering algorithm, reducing data volume, bandwidth consumption, and redundancy during transmission, thereby improving the transmission efficiency of operation commands and reducing interaction latency. A dynamic mapping relationship is established between the computer's multi-screen coordinate system and the target terminal's coordinate system, enabling coordinate matching between different screens of a multi-screen PC and the target terminal. This allows for more precise mouse and keyboard operations in cross-terminal, multi-screen scenarios, solving the problem of traditional solutions being unable to adapt to multi-screen PC interaction and achieving seamless operation. The processed event data is transmitted to the target terminal via an encrypted soft bus. While ensuring efficient and accurate transmission of cross-device operation commands, the secure transmission mechanism of the encrypted soft bus prevents the operation event data from being stolen or tampered with during transmission, balancing the smoothness and security of cross-device interaction. By using pixel scaling and layout rearrangement algorithms to adapt the projection interface based on the physical resolution of the target terminal, and assigning classification transmission identifiers according to the priority of collaborative tasks, the collaborative data that meets the standards is fragmented, indexed and transmitted. The application adaptation layer responds to the collaboration end request and the core service layer completes the data integrity verification and restores the relevant collaborative state on the computer side, thereby optimizing the open source HarmonyOS computer desktop collaboration.

[0117] Example 4 Figure 6 This is a schematic diagram of a computer desktop collaborative optimization device based on the open-source HarmonyOS, provided in Embodiment 4 of the present invention. Figure 6 As shown, the device includes: a connection establishment module 610, a transmission initiation module 620, a sequence compression module 630, a screen projection module 640, a collaborative transmission module 650, and a collaborative termination module 660, wherein: The connection module 610 is used to respond to the user-initiated collaborative task request through the application adaptation layer, determine the matching target terminal, collaborative function type and custom interaction parameters, and after forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, establish an encrypted soft bus connection between the computer and the target terminal through the core service layer. The transmission module 620 is started to collect hardware status data through the core service layer, determine the priority of the collaborative task in combination with the collaborative function type, and calculate the corresponding resource demand coefficient and user attention weight. After dynamically allocating the resource ratio of multiple resource pools for the collaborative task based on the priority, resource demand coefficient and user attention weight, the encrypted soft bus transmission is started. The sequence compression module 630 is used to listen to cross-device operation, screen projection startup, and collaborative data transmission events through the functional module layer. When cross-device operation event data is collected through the functional module layer, the cross-device operation event data is serialized and compressed, and transmitted to the target terminal through an encrypted soft bus to execute the computer's keyboard and mouse control of the target terminal. The screen projection module 640 is used to adaptively adapt the screen projection interface based on the physical resolution of the target terminal by using pixel scaling algorithm and layout rearrangement algorithm when the physical resolution of the target terminal is collected through the functional module layer and a screen projection start command is received. The collaborative transmission module 650 is used when the functional module layer receives collaborative data forwarded by the application adaptation layer and the core service layer has started encrypted soft bus transmission, the functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that conforms to the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index. The collaboration termination module 660 is used to respond to the collaboration termination request initiated by the user through the application adaptation layer, forward the collaboration termination request to the core service layer, and restore the collaboration-related state on the computer to the initial state before the collaboration task request was executed after the integrity verification of the collaboration data is passed by the core service layer.

[0118] The technical solution of this invention, through the application adaptation layer responding to collaborative task requests and forwarding parameters to the core service layer, establishes an encrypted soft bus connection, enabling secure and stable interconnection between the computer and the target terminal, avoiding the risk of data leakage during the collaboration process. Simultaneously, standardized collaborative interface calls improve the efficiency of collaborative request forwarding and reduce redundancy between layers. The core service layer collects hardware status data and dynamically allocates the proportion of multiple resource pools based on collaborative function type, resource demand coefficient, and user attention weight, achieving precise resource scheduling, avoiding resource waste, ensuring the smooth operation of high-priority collaborative tasks, and adapting to different hardware states to achieve flexible resource allocation and improve the compatibility of the collaborative system. The functional module layer listens to various collaborative events and serializes and compresses cross-device operation event data for transmission, reducing data transmission bandwidth consumption, improving the response speed of keyboard and mouse operation, and achieving seamless cross-device operation. Through pixel scaling and layout... The rearrangement algorithm adapts to the projection interface based on the physical resolution of the target terminal, solving problems such as screen stretching, control overlap, and text truncation when projection across devices, thus improving the projection display effect and user viewing experience. The functional module layer assigns classification transmission identifiers according to the priority of collaborative tasks, and transmits standard-compliant collaborative data after fragmentation and indexing. This ensures orderly and efficient transmission of collaborative data, guaranteeing that high-priority data is transmitted first. Furthermore, fragmented transmission combined with index management allows for the retransmission of only missing or erroneous fragments after transmission interruption, improving data transmission integrity and efficiency while reducing resource consumption from repeated transmissions. The application adaptation layer responds to the collaboration end request, and the core service layer restores the computer-side collaboration-related state after data integrity verification. This ensures closed-loop operation of collaborative tasks, avoids resource occupation residue, improves system stability and reliability, and optimizes open-source HarmonyOS computer desktop collaboration, balancing collaboration security, efficiency, smoothness, and user experience.

[0119] Based on the above embodiments, a connection module 610 is established, specifically for: The core service layer checks the current connection status between the computer and the target terminal. If no connection is established, it scans the target terminal via broadcast, performs key negotiation through an encryption algorithm, generates a temporary session key, and establishes an encrypted soft bus connection based on the temporary session key. If a connection has been established, it enables the existing encrypted soft bus connection.

[0120] Furthermore, based on the above embodiments, the computer desktop collaborative optimization device based on open-source HarmonyOS may further include: an initialization module, a topology acquisition module, and a resolution acquisition module, wherein: The initialization module is used to initialize the input device mapping unit and the interface adaptive unit through the functional module layer while establishing an encrypted soft bus connection between the computer and the target terminal through the core service layer. The topology acquisition module is used to obtain screen topology data during the initialization of the input device mapping unit through the functional module layer. The input device mapping unit identifies the multi-screen splicing mode and resolution of each screen on the computer through the display server and window system tools. The resolution acquisition module is used to acquire the physical resolution of the target terminal through the terminal access layer during the initialization of the interface adaptive adaptation unit through the functional module layer. Accordingly, based on the above embodiments, the sequence compression module 630 is specifically used for: The input device mapping unit of the functional module layer listens to the device files of the operating system input subsystem through a notification mechanism and captures cross-device operation, screen casting startup, and collaborative data transmission event data on the computer at a preset frequency.

[0121] Based on the above embodiments, the transmission module 620 is activated, specifically for: The priority of each collaborative task is determined based on hardware status data and collaborative function type; resource demand coefficients are calculated based on historical collaborative data, and user attention weights are determined through window focus detection; based on the priority, resource demand coefficients, and user attention weights of each collaborative task, a multi-dimensional weighted round-robin algorithm is used to dynamically allocate resource ratios from multiple resource pools to each collaborative task, and it is verified whether the allocated resources meet the task's running requirements. If resources are insufficient, a dynamic degradation strategy is triggered; if resources are sufficient, encrypted soft bus transmission is initiated. The resource pools include: a central processing unit resource pool, a memory resource pool, a graphics processing unit resource pool, a network bandwidth resource pool, and a storage input / output resource pool.

[0122] Based on the above embodiments, the sequence compression module 630 is further configured to: Cross-device operation event data is converted into the open-source HarmonyOS unified input format, serialized and compressed using a protocol buffering algorithm, and transmitted to the target terminal via an encrypted soft bus based on the dynamic mapping relationship between the computer's multi-screen coordinate system and the target terminal's coordinate system.

[0123] Based on the above embodiments, the projection module 640 is specifically used for: Based on the computer screen topology data, the available area size for projection is determined. Combined with the physical resolution of the target terminal, the screen scaling factor is calculated according to the principle of proportionality. If the resolution ratio between the computer and the target terminal is inconsistent, the projection screen size is adjusted according to the first principle. After pixel scaling of the projection screen using bilinear interpolation, all controls on the projection interface are traversed, the overlap area between controls is calculated, and the display integrity of text controls is checked. When the overlap area of ​​controls exceeds the preset overlap ratio or the text controls are not fully displayed, the size and position of non-core controls are adjusted according to the preset control priority. The font size of incomplete text controls is adjusted or the number of lines is increased, and the control distribution on the projection interface is optimized.

[0124] Based on the above embodiments, the cooperative transmission module 650 is specifically used for: Based on the priority of collaborative tasks, classification transmission identifiers are assigned to collaborative data; collaborative data conforming to preset standards is split into multiple blocks and fragments matching each block according to preset specifications; an index is assigned to each fragment and a fragment checksum is generated, and a block checksum is generated for each block; a fragment index table is constructed, containing the index, fragment checksum, block checksum, transmission status, and storage location; the fragment index table and transmitted fragment data are synchronously cached on the computer and the target terminal, with data synchronization completed according to storage location and index table identifiers updated according to transmission status; collaborative data is transmitted via an encrypted soft bus according to the priority order of classification transmission identifiers and the index order of the fragment index table, with fragment checksums updated during transmission. The verification code performs integrity checks on the fragmented data. Upon successful verification, the corresponding fragment's transmission status in the fragment index table is updated to "completed," and synchronized to the target terminal. Once all fragments under any given block have been transmitted and verified, the block's overall integrity is checked based on the block's verification code. Upon successful verification, the block's transmission status is updated to "block complete." If transmission is interrupted, after re-establishing the encrypted soft bus connection, the sender requests the receiver's fragment index table and, by comparing the indexes, transmission statuses, and verification codes of both tables, identifies missing or incorrectly verified fragments. All missing or incorrectly verified fragments are retransmitted via the encrypted soft bus. After retransmission, the fragment index table is updated, and the operation of transmitting collaborative data via the encrypted soft bus is returned.

[0125] The computer desktop collaborative optimization device based on open source HarmonyOS provided in the embodiments of the present invention can execute the computer desktop collaborative optimization method based on open source HarmonyOS provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0126] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0127] Example 5 Figure 7 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0128] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0129] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0130] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the computer desktop collaborative optimization method based on the open-source HarmonyOS, namely: The application adaptation layer responds to user-initiated collaborative task requests, determines the matching target terminal, collaborative function type, and custom interaction parameters, and forwards the request carrying these parameters to the core service layer after calling the standardized collaborative interface. The core service layer then establishes an encrypted soft bus connection between the computer and the target terminal. The core service layer collects hardware status data, determines the priority of the collaborative task based on the collaborative function type, and calculates the corresponding resource requirement coefficient and user attention weight. Based on the priority, resource requirement coefficient, and user attention weight, it dynamically allocates resource proportions from multiple resource pools for the collaborative task and initiates encrypted soft bus transmission. The functional module layer listens for cross-device operation, screen mirroring initiation, and collaborative data transmission events. When cross-device operation event data is collected by the functional module layer, it is serialized and compressed, and then transmitted to the target terminal via the encrypted soft bus for computation. The device controls the target terminal using a keyboard and mouse. When the physical resolution of the target terminal is acquired through the functional module layer and a screen projection start command is received, the screen projection interface is adaptively adapted based on the physical resolution of the target terminal using pixel scaling and layout rearrangement algorithms. When the functional module layer receives collaborative data forwarded by the application adaptation layer and the core service layer has started encrypted soft bus transmission, the functional module layer assigns classification transmission identifiers to the collaborative data according to the priority of the collaborative tasks matching the collaborative data. The collaborative data that meets the preset standards is split into multiple fragments, and an index is generated for each fragment. The collaborative data is then transmitted through the encrypted soft bus according to the classification transmission identifiers and indexes. The application adaptation layer responds to the user-initiated collaboration end request by forwarding the collaboration end request to the core service layer. After the core service layer verifies the integrity of the collaborative data, the collaboration-related state on the computer is restored to the initial state before the collaborative task request was executed.

[0131] In some embodiments, the computer desktop collaborative optimization method based on open-source HarmonyOS can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the computer desktop collaborative optimization method based on open-source HarmonyOS described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the computer desktop collaborative optimization method based on open-source HarmonyOS by any other suitable means (e.g., by means of firmware).

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

[0133] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

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

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

[0136] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0137] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0138] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0139] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.< / text> < / button> < / constraintlayout>

Claims

1. A computer desktop collaborative optimization method based on open-source Hongmeng, characterized in that, Executed by a computer based on the open-source HarmonyOS, including: The application adaptation layer responds to user-initiated collaborative task requests, determines the matching target terminal, collaborative function type, and custom interaction parameters, and after forwarding the request carrying the above parameters to the core service layer by calling the standardized collaborative interface, an encrypted soft bus connection is established between the computer and the target terminal through the core service layer. The core service layer collects hardware status data, determines the priority of collaborative tasks based on the type of collaborative function, and calculates the corresponding resource requirement coefficient and user attention weight. Based on the priority, resource requirement coefficient and user attention weight, the resource ratio of multiple resource pools is dynamically allocated to the collaborative task, and then the encrypted soft bus transmission is started. By listening to cross-device operation, screen mirroring startup, and collaborative data transmission events through the functional module layer, when cross-device operation event data is collected through the functional module layer, the cross-device operation event data is serialized and compressed, and transmitted to the target terminal through an encrypted soft bus to execute the computer's keyboard and mouse control of the target terminal; When the physical resolution of the target terminal is collected through the functional module layer and the screen casting start command is received, the screen casting interface is adaptively adapted based on the physical resolution of the target terminal through pixel scaling algorithm and layout rearrangement algorithm. When the functional module layer receives collaborative data forwarded by the application adaptation layer, and the core service layer has started encrypted soft bus transmission, the functional module layer assigns a classification transmission identifier to the collaborative data according to the priority of the collaborative task matching the collaborative data, splits the collaborative data that meets the preset standard into multiple fragments, generates an index for each fragment, and then transmits the collaborative data through the encrypted soft bus according to the classification transmission identifier and the index. The application adaptation layer responds to the user's collaboration termination request and forwards the collaboration termination request to the core service layer. After the core service layer passes the integrity verification of the collaboration data, the collaboration-related state on the computer is restored to the initial state before the collaboration task request was executed.

2. The method of claim 1, wherein, An encrypted soft bus connection is established between the computer and the target terminal through the core service layer, including: The core service layer checks the current connection status between the computer and the target terminal. If no connection is established, it scans the target terminal via broadcast and performs key negotiation through encryption algorithm to generate a temporary session key. Then, it establishes an encrypted soft bus connection based on the temporary session key. If a connection has already been established, then enable the existing encrypted soft bus connection.

3. The method of claim 1, wherein, In addition to establishing an encrypted soft bus connection between the computer and the target terminal through the core service layer, it also includes: The input device mapping unit and the interface adaptive unit are initialized through the functional module layer; During the process of initializing the input device mapping unit through the functional module layer, the input device mapping unit identifies the multi-screen splicing mode and resolution of each screen on the computer through the display server and window system tools, and obtains screen topology data. During the initialization of the interface adaptive unit through the functional module layer, the interface adaptive unit collects the physical resolution of the target terminal through the terminal access layer. Accordingly, the functional module layer listens for cross-device operation, screen mirroring startup, and collaborative data transmission events, including: The input device mapping unit of the functional module layer listens to the device files of the operating system input subsystem through a notification mechanism and captures cross-device operation, screen casting startup, and collaborative data transmission event data on the computer at a preset frequency.

4. The method of claim 1, wherein, Based on the collaborative function type, the priority of the collaborative task is determined, and the corresponding resource requirement coefficient and user attention weight are calculated. Then, based on the priority, resource requirement coefficient, and user attention weight, the resource ratios of multiple resource pools are dynamically allocated to the collaborative task. Finally, encrypted soft bus transmission is initiated, including: The priority of each collaborative task is determined based on hardware status data and collaborative function type; The resource demand coefficient is calculated based on historical collaborative data, and the user attention weight is determined by window focus detection. Based on the priority, resource demand coefficient, and user attention weight of each collaborative task, a multi-dimensional weighted round-robin algorithm is used to dynamically allocate the resource ratio of multiple resource pools to each collaborative task, and to verify whether the allocated resources meet the task's running requirements. If the resources are insufficient, a dynamic degradation strategy is triggered. If resources are sufficient, encrypted soft bus transmission will be initiated; the resource pool includes: CPU resource pool, memory resource pool, graphics processor resource pool, network bandwidth resource pool, and storage input / output resource pool.

5. The method of claim 1, wherein, The cross-device operation event data is serialized and compressed, and then transmitted to the target terminal via an encrypted soft bus, including: Cross-device operation event data is converted into the open-source HarmonyOS unified input format, serialized and compressed using a protocol buffering algorithm, and transmitted to the target terminal via an encrypted soft bus based on the dynamic mapping relationship between the computer's multi-screen coordinate system and the target terminal's coordinate system.

6. The method of claim 3, wherein, The projection interface is adaptively adapted based on the physical resolution of the target terminal using pixel scaling and layout rearrangement algorithms, including: Based on the computer screen topology data, determine the size of the available projection area on the computer, and calculate the screen scaling factor according to the principle of proportionality, taking into account the physical resolution of the target terminal. If the resolution ratio of the computer and the target terminal is inconsistent, adjust the screen projection size according to the first principle. After scaling the projected screen using bilinear interpolation, all controls on the projected screen are traversed, the overlapping area between controls is calculated, and the display integrity of text controls is checked. When the overlapping area of ​​controls exceeds the preset overlap ratio or the text controls are not fully displayed, the size and position of non-core controls are adjusted according to the preset control priority. The font size of incomplete text controls is adjusted or the number of lines is increased, and the distribution of controls on the projected screen is optimized.

7. The method of claim 1, wherein, After assigning classification transmission identifiers to the collaborative data according to the priority of the collaborative tasks matching the collaborative data, splitting the collaborative data that meets the preset standards into multiple fragments, and generating an index for each fragment, the collaborative data is transmitted through an encrypted soft bus according to the classification transmission identifiers and indexes, including: Assign category transmission identifiers to collaborative data based on the priority of collaborative tasks; Collaborative data that meets preset standards is split into multiple blocks and multiple fragments that match each block according to preset specifications; Assign an index to each fragment and generate a fragment checksum, generate a block checksum for each block, construct a fragment index table containing the index, fragment checksum, block checksum, transmission status, and storage location, and synchronously cache the fragment index table and the transmitted fragment data on the computer and the target terminal. During the synchronization process, data synchronization is completed according to the storage location, and the index table identifier is updated according to the transmission status. According to the priority order of the classification transmission identifier and the index order of the fragment index table, the collaborative data is transmitted through the encrypted soft bus. During the transmission, the integrity of the fragment data is checked according to the fragment check code. After the check is passed, the transmission status of the corresponding fragment in the fragment index table is updated to "completed" and synchronized to the target terminal. After all fragments under any block have been transmitted and verified, the block is checked for overall integrity based on the block checksum. If the verification is successful, the transmission status of the block is updated to block complete. If the transmission is interrupted, after the encrypted soft bus connection is re-established, the sender requests the receiver's fragment index table and filters out missing or incorrect fragments by comparing the indexes, transmission status and check codes of both parties' index tables. Retransmit all missing or incorrectly checked fragments via the encrypted soft bus, update the fragment index table after retransmission, and return to the operation of transmitting collaborative data via the encrypted soft bus.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the computer desktop collaborative optimization method based on open-source HarmonyOS as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause the processor to execute the computer desktop collaborative optimization method based on open-source HarmonyOS as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the computer desktop collaborative optimization method based on open-source HarmonyOS as described in any one of claims 1-7.

Images