Load balancing method and electronic device

Abstract

The application discloses a load balancing method and an electronic device. It belongs to the technical field of communication. An embodiment of the method comprises: obtaining running state data of a first device and a second device in the case that the first device is connected with the second device for screen projection; determining load scores of the first device and the second device based on the running state data; sending at least one task of the first device to the second device for processing in the case that the load scores meet a first condition; and receiving and processing a task sent by the second device in the case that the load scores meet a second condition.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to load balancing methods and electronic devices. Background Technology

[0002] In screen mirroring scenarios, once two devices establish a mirroring connection, users typically expect a smooth user experience during the mirroring process. However, in actual use, due to differences in hardware configuration, operating status, and other factors, different devices often exhibit significant variations in their processing power and power consumption.

[0003] In existing technologies, problems such as excessive single-end load and unbalanced load between devices are prone to occur. Summary of the Invention

[0004] The purpose of this application is to provide a load balancing method and electronic device that can achieve load balancing between two devices in a screen projection scenario, thereby improving the overall utilization rate of computing resources of the two devices during the screen projection process.

[0005] In a first aspect, embodiments of this application provide a load balancing method applied to a first device. The method includes: when the first device and a second device are connected for screen projection, acquiring operating status data of the first device and the second device; determining load scores of the first device and the second device based on the operating status data; when the load scores meet a first condition, sending at least one task from the first device to the second device for processing; and when the load scores meet a second condition, receiving and processing the task sent by the second device.

[0006] Secondly, embodiments of this application provide a load balancing device applied to a first device. The device includes: an acquisition unit, configured to acquire operating status data of the first device and the second device when the first device and the second device are connected for screen projection; a determination unit, configured to determine the load score of the first device and the second device based on the operating status data; a sending unit, configured to send at least one task of the first device to the second device for processing when the load score meets a first condition; and a receiving unit, configured to receive and process the task sent by the second device when the load score meets a second condition.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a computer program is stored, and when executed by a processor, the computer program implements the steps of the method described in the first aspect above.

[0009] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method described in the first aspect.

[0010] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.

[0011] In this embodiment, the operating status data of the first and second devices are first acquired; then, the load scores of the first and second devices are determined based on the operating status data; if the load score meets a first condition, at least one task from the first device is sent to the second device for processing; if the load score meets a second condition, the task sent by the second device is received and processed. Through the above process, the first device can simultaneously grasp the load status of both devices during the screen projection process, and, based on the load status of both devices, either migrate tasks from the first device out or migrate tasks from the second device in. This avoids the unbalanced state where one end bears a high load while the other end's resources are idle, achieving load balancing between the two devices in the screen projection scenario, thereby improving the overall utilization rate of computing resources of both devices during the screen projection process. Attached Figure Description

[0012] Figure 1 This is a flowchart of the load balancing method provided in the embodiments of this application; Figure 2 This is a schematic diagram illustrating an application scenario of the load balancing method provided in the embodiments of this application; Figure 3 This is a schematic diagram of the load balancing device provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in this application's specification are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, in the specification, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects have an "or" relationship.

[0015] The load balancing method and apparatus provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0016] Please refer to Figure 1 The diagram illustrates a flowchart of a load balancing method provided in an embodiment of this application. The load balancing method provided in this application can be applied to a first device.

[0017] The load balancing method provided in this application includes the following steps: Step 101: When the first device and the second device are connected for screen mirroring, obtain the operating status data of the first device and the second device.

[0018] The first device is one of the electronic devices participating in the screen mirroring connection. The first device can be either the screen mirroring initiator or the screen mirroring receiver. The second device is the electronic device that establishes a screen mirroring connection with the first device. When the first device is the screen mirroring initiator, the second device is the screen mirroring receiver; when the first device is the screen mirroring receiver, the second device is the screen mirroring initiator.

[0019] In this context, the screen mirroring initiator is the device that initiates the screen mirroring connection, outputs the local screen, and performs encoding and streaming, such as a mobile phone. The screen mirroring receiver is the device that receives the screen mirroring data, performs decoding and rendering, and displays the screen mirrored image, such as a personal computer (PC) or a smart TV.

[0020] Screen mirroring refers to a communication connection established between a first device and a second device for transmitting screen-mirror images, operation commands, and related data. This connection can be implemented based on a local area network (LAN) or a wired connection. Screen mirroring provides a data transmission channel for the exchange of status data and task migration between the two devices. The first and second devices can transmit data to each other through this data transmission channel.

[0021] Operational status data refers to data reflecting the current operating status of a device, used to assess the device's current load level. After the first device establishes a projection connection with the second device, the first device can periodically collect its own operational status data. Simultaneously, the second device also collects its own operational status data at the same period and sends this data to the first device through the projection connection channel. The first device receives the operational status data sent by the second device, thus simultaneously monitoring the real-time operational status of both devices.

[0022] For example, the first device is a mobile phone, which is the screen mirroring initiator; the second device is a computer, which is the screen mirroring receiver. After the mobile phone and computer establish a screen mirroring connection, the mobile phone collects its own operating status data every minute. At the same time, the computer collects its own operating status data every minute and sends this data to the mobile phone through the screen mirroring connection. The mobile phone thus obtains the operating status data of both parties.

[0023] Optionally, the operating status data includes at least one of the following: Central Processing Unit (CPU) utilization, Graphics Processing Unit (GPU) utilization, power used or remaining power, device temperature, and screen refresh rate.

[0024] CPU utilization is the percentage of time the CPU is in operation per unit of time, expressed as a percentage, ranging from 0% to 100%. CPU utilization reflects the degree to which CPU computing resources are occupied; a higher value indicates a busier CPU and less available idle computing resources, while a lower value indicates a more idle CPU with surplus computing power available. In screen mirroring scenarios, high CPU utilization typically means the device is performing computationally intensive operations such as video decoding, document rendering, and data compression.

[0025] It should be noted that for the screen mirroring initiator, such as a mobile phone, its operating status data may also include the ratio of the current CPU frequency to its maximum frequency, that is, the ratio between the actual operating frequency of the CPU at the current running moment and its highest supported operating frequency. For the screen mirroring receiver, such as a PC, its CPU utilization can be the percentage of utilization of each CPU core during the sampling period, and then the arithmetic mean of the utilization of all cores is calculated.

[0026] Graphics processor utilization is the percentage of time the graphics processor is engaged in rendering or parallel computing per unit of time, expressed as a percentage, ranging from 0% to 100%. GPU utilization reflects the degree to which the GPU's graphics rendering and parallel computing resources are being used. Higher GPU utilization indicates that the device is performing more intensive graphics rendering or general GPU computing tasks, such as game rendering, video effects processing, and image filtering calculations. In screen mirroring scenarios, GPU utilization can be used to assess the device's display output load and graphics processing pressure.

[0027] Used battery power refers to the percentage of total battery capacity that has been consumed, while remaining battery power refers to the percentage of total battery capacity that has not been consumed. Both values ​​range from 0% to 100%. The relationship between used battery power and remaining battery power is: Used Battery Power = 100% - Remaining Battery Power. Both can be used to reflect the device's remaining energy status. The higher the used battery power, the lower the remaining battery power, indicating that the device consumes more power and has weaker battery life; conversely, the lower the used battery power, the higher the remaining battery power, indicating that the device has more power and stronger battery life. In screen mirroring scenarios, used battery power or remaining battery power can be used to assess the device's battery life under the current load.

[0028] Device temperature is the real-time operating temperature of the device's core computing components or critical locations on the device's chassis, measured in degrees Celsius (°C), and collected by the device's built-in temperature sensor. The device temperature reflects the device's heat dissipation status and thermal risk level. Higher temperatures indicate more severe heat generation, and the device may proactively reduce performance to prevent overheating damage. In screen mirroring scenarios, continuous high-load operations can cause the device temperature to rise, triggering frequency throttling protection and affecting the smoothness of screen mirroring. Device temperature values ​​can be used to assess the device's thermal status and frequency throttling risk.

[0029] Screen refresh rate refers to the number of times a device's display screen updates its image per second, measured in Hertz (Hz). A higher refresh rate results in smoother display, but also increases the GPU's rendering load and the screen driver's power consumption. Common screen refresh rates include 60Hz, 90Hz, 120Hz, and 144Hz. In screen mirroring scenarios, the screen refresh rate reflects the device's display output load and power consumption. A high refresh rate means higher GPU rendering pressure and display power consumption, while a low refresh rate helps reduce power consumption.

[0030] In practice, the first and second devices can exchange collected status data in real time through a power consumption coordination protocol. The protocol frame format is defined as: {device_id (device identifier), cpu_load (CPU utilization), gpu_load (GPU utilization), battery (remaining battery power), temperature (device temperature), fps (device screen refresh rate), timestamp (timestamp)}. Protocol transmission is based on the existing connection channel for screen mirroring. This channel can be a local area network connection such as Ethernet or Wi-Fi, or a USB (Universal Serial Bus) connection. The timestamp uses a millisecond-level timestamp synchronized by both parties to ensure the consistency of status data timing.

[0031] Step 102: Determine the load scores of the first and second devices based on the operating status data.

[0032] For each of the first and second devices, its load score is a quantitative assessment of the overall load level of that device, calculated based on its operating status data, and reflects its current overall load condition. A higher load score indicates a heavier current load on the device; a lower load score indicates a lighter current load.

[0033] Specifically, the first device invokes a preset load assessment rule, substitutes its operating status data into the rule for calculation, and obtains the load score corresponding to the first device. Using the same assessment rule, the operating status data of the second device is substituted into the calculation to obtain the load score corresponding to the second device.

[0034] For example, the load assessment rule can be a preset load score calculation formula. A weighted summation formula can be used, which assigns corresponding weights to each operating status data of each device and then performs a weighted summation to obtain the load score of the device.

[0035] For example, the load assessment rules can also be learned through a machine learning model. A model for predicting load scores can be pre-trained using supervised learning. The model is then fed with various operational status data for each device to obtain its load score. This model can employ a convolutional neural network or similar structure, and the training dataset can include a large number of labeled samples, each containing a set of operational status parameters and a corresponding load score label.

[0036] Step 103: If the load score meets the first condition, at least one task of the first device is sent to the second device for processing.

[0037] The first condition refers to the condition that triggers the first device to send local tasks to the second device. This condition is determined based on a comparison of the load scores of the first and second devices and the remaining battery power of the first device. Specifically, when the load score of the first device is significantly higher than that of the second device, and the remaining battery power of the first device is low, it indicates that the first device is in an unfavorable state of high load and low battery. In this case, the first condition is met, and the first device sends at least one local task to the second device for processing. At this time, the first device can act as the source device, i.e., the task originating device; the second device can act as the destination device, i.e., the task inbound device.

[0038] A task refers to a computational or processing task that needs to be executed during screen mirroring. These tasks are typically computational or processing tasks that can be executed independently and do not rely on local dedicated hardware. Specifically, tasks may include, but are not limited to, video decoding processing tasks, document rendering processing tasks, data computation processing tasks, notification message processing tasks, audio encoding / decoding tasks, and user interface rendering computation tasks.

[0039] At least one task of the first device refers to a task currently running or waiting to be processed on the first device. For example, if the first device is the screen mirroring initiator, then at least one task of the first device can be one or more of the following: video decoding processing task, document rendering processing task, data calculation processing task, etc. If the first device is the screen mirroring receiver, then at least one task of the first device can be one or more of the following: notification message processing task, audio encoding and decoding task, user interface rendering calculation task, etc.

[0040] In practice, after calculating the load scores of both devices, the first device compares the load scores of both devices and checks its own remaining battery power. When the ratio of the load score of the first device to the load score of the second device reaches a predetermined multiple, and the remaining battery power of the first device is lower than a predetermined threshold, the first condition is deemed met. At this time, the first device can filter at least one task that can be migrated across devices from the tasks running locally or waiting to be processed. It packages the execution logic and related data of each selected task and sends it to the second device through the screen projection connection channel. The second device then takes over the execution of the task, achieving load balancing between the two devices. The filtering rules can be specified by the user; they can also follow the default settings; or they can be determined based on information such as the difference in load scores between the first and second devices. For example, the greater the difference in load scores, the more tasks are sent to the second device or the greater the computational resource consumption, etc., but no specific limitations are made here.

[0041] Optionally, when the first device is the screen mirroring initiator, the at least one task may include at least one of the following: video decoding task, document rendering task, and data processing task. When the first device is the screen mirroring receiver, the at least one task may include at least one of the following: notification message processing task, audio encoding / decoding task, and user interface rendering calculation task.

[0042] Understandably, when the first device is the screen-sharing initiator, it primarily runs computationally intensive tasks related to the generation and transmission of screen-sharing content, such as video decoding, document rendering, and data processing. Migrating these tasks to the second device effectively reduces the high computational load on the screen-sharing initiator due to content processing. Similarly, when the first device is the screen-sharing receiver, it primarily runs tasks related to receiving and presenting screen-sharing content, such as notification message processing, audio encoding / decoding, and user interface rendering. Migrating these tasks to the second device also effectively reduces the computational load on the screen-sharing receiver due to content processing. This mechanism ensures targeted task migration, avoiding migration failures or inability to execute correctly after migration due to unclear task types, thus guaranteeing the feasibility and effectiveness of the load balancing strategy in real-world screen-sharing scenarios.

[0043] Step 104: If the load score meets the second condition, receive and process the task sent by the second device.

[0044] The second condition refers to the criteria that trigger the first device to receive and process the task sent by the second device. This condition is determined based on a comparison of the load scores of the first and second devices and the remaining battery power of the second device. Specifically, when the load score of the second device is significantly higher than that of the first device, and the remaining battery power of the second device is low, it indicates that the second device is in an unfavorable state of high load and low battery. In this case, the second condition is met, and the first device receives and processes the task sent by the second device, thereby relieving the computational burden on the second device. At this time, the second device can act as the source device, i.e., the task originating device; the first device can act as the destination device, i.e., the task inbound device.

[0045] In practice, after calculating the load scores of both devices, the first device compares the load scores of the two devices and determines the remaining power of the second device based on the operating status data of the second device. When the load score of the second device exceeds the load score of the first device by a predetermined multiple, and the remaining power of the second device is lower than a predetermined threshold, the second condition is deemed met. At this time, the first device receives and processes at least one task migrated from the second device through the projection connection channel, thereby relieving the computational burden on the second device and achieving load balancing between the two devices.

[0046] The method provided in the above embodiments of this application first obtains the operating status data of a first device and a second device; then, it determines the load score of the first device and the second device based on the operating status data; if the load score meets a first condition, it sends at least one task from the first device to the second device for processing; if the load score meets a second condition, it receives and processes the task sent by the second device. Through the above process, the first device can simultaneously grasp the load status of both devices during the screen projection process, and, based on the load status of both devices, either migrate tasks from the first device out or migrate tasks from the second device in. This avoids the unbalanced state where one end bears a high load while the other end's resources are idle, achieving load balancing between the two devices in the screen projection scenario, thereby improving the overall utilization rate of computing resources of both devices during the screen projection process.

[0047] In some optional embodiments, the operating status data includes at least one of the following: central processing unit (CPU) utilization, graphics processing unit (GPU) utilization, power consumption, device temperature, and screen refresh rate. Step 102 may further include: Step S11: Determine the weights of various operational status data based on the screen projection scenario.

[0048] Weight refers to the proportion of each operational status data point in the weighted sum when calculating the load score. Weights are represented numerically, and the sum of all weights is 1. The magnitude of the weight determines the degree to which the corresponding operational status data contributes to the final load score. The larger the weight, the more significant the impact of that data point on the load score.

[0049] The weights of various operational status data can be dynamically adjusted according to the screen casting scenario, so that the load score calculation can highlight the most important and representative load factors in different usage scenarios. For example, in video playback screen casting scenarios, GPU utilization has the highest weight, focusing on evaluating graphics decoding and rendering load; in document screen casting scenarios, CPU utilization has the highest weight, focusing on evaluating general computing load; in game screen casting scenarios, GPU utilization and CPU utilization have the same or similar weights to simultaneously evaluate the two types of computing load.

[0050] Step S12: Based on the weights, the various operating status data of the first device and the second device are weighted and summed to obtain the load scores of the first device and the second device.

[0051] Specifically, the load score of the first device can be obtained by weighted summation of the various operating status data of the first device; the load score of the second device can be obtained by weighted summation of the various operating status data of the second device.

[0052] As an example, the operational status data includes CPU utilization (cpu_load), GPU utilization (gpu_load), battery power used (1 - battery_pct), and device temperature. Here, battery_pct represents the remaining battery power. The weights of these four operational status data items are denoted as α, β, γ, and δ, respectively. The load score can then be calculated as: S = α·cpu_load + β·gpu_load + γ(1 - battery_pct) + δ·temperature.

[0053] By acquiring operational status data from both the first and second devices, the first device can simultaneously grasp multi-dimensional operational status data from both ends, providing a multi-dimensional data foundation for load assessment. Based on this, by determining the weights of various operational status data based on the projection scenario, targeted assessments of the core factors truly affecting device performance in projection scenarios are achieved, avoiding the inaccuracy of assessments using fixed weights in different scenarios. Furthermore, by weighted summation of the operational status data from both the first and second devices based on the aforementioned weights, the load scores for each end device are obtained, making the load levels of the two devices directly comparable. Through this process, accurate quantification of the overall load status of the two devices under different projection scenarios is achieved, improving the scenario adaptability and accuracy of load score calculation. This provides a reliable decision-making basis for on-demand migration of tasks between the two devices, ensuring the effectiveness of subsequent load balancing decisions.

[0054] In some optional embodiments, step 103, which involves sending at least one task from the first device to the second device for processing, further includes: Step S21: Display the first information and send the second information to the second device.

[0055] The first piece of information can be used to ask the user whether they agree to the task migration out. The second piece of information can be used to ask the user whether they agree to the task migration in. The first and second pieces of information may include task migration plans and provide task migration options, such as a summary of the current power consumption status, a list of tasks to be migrated, an estimated percentage of power savings, and interactive controls for user operation.

[0056] For example, the first information can be presented as a notification card in the notification center or a pop-up window in the center of the screen of the first device. The card content may include: a summary of the current power consumption status, a list of tasks to be migrated, an estimated percentage of power savings, and two operable buttons: "Confirm Migration" and "Reject". Simultaneously, the first device sends the first information to the second device via a screen mirroring connection channel. After receiving the first information, the second device synchronously displays the corresponding notification card on its user interface. The notification card content displayed on the second device may include: a list of tasks to be received, an estimated impact on the computing power of the second device after receipt, and two operable buttons: "Agree to Receive" and "Reject".

[0057] Step S22: Receive the user's first input.

[0058] The first input refers to the user's interactive operation indicating whether they agree to the task migration based on the first information; it is the user's response to the task migration suggestion. The first input can be touch input, voice command, a specific gesture input by the user, or other feasible inputs. The specific input can be determined according to actual usage needs, and this application embodiment does not limit it. The specific gesture in this application embodiment can be any one of the following: single-click gesture, swipe gesture, drag gesture, pressure recognition gesture, long-press gesture, area change gesture, double-press gesture, and double-tap gesture. The click input in this application embodiment can be a single-click input, double-tap input, or any number of clicks, and can also be a long-press input or a short-press input.

[0059] For example, the first input can be a gesture operation by the user clicking the "Confirm Migration" or "Reject Migration" button on the touch screen, or a voice command of "Confirm Migration" or "Reject Migration" issued by the voice assistant.

[0060] Step S23: If the first input indicates that the user agrees to the task transfer and a confirmation message for the second information is received from the second device, at least one task is sent to the second device for processing.

[0061] A confirmation message is a feedback message generated by the user on the second device after receiving the second information, indicating agreement to receive the task. The confirmation message is not automatically generated by the second device, but rather in response to input from its local user. The confirmation message can be sent from the second device back to the first device via the screen mirroring connection channel. The task migration operation will only be executed after confirmation from both the user on the first device and the user on the second device. If either user refuses, the task migration operation will not be executed.

[0062] Specifically, after receiving the first input from the local user, the first device enters a state of waiting for a response from the other end. When the first input indicates that the local user agrees to the task migration and the first device receives a confirmation message from the second device indicating acceptance, it is determined that both ends have confirmed the migration. The first device selects at least one task to be migrated from its locally running tasks, packages the task's execution logic and associated data, and sends it to the second device through the screen mirroring connection channel, completing the task migration operation. If no confirmation message is received from the second device, or a rejection message is received, the migration operation is not performed, and the load status of both ends can be reassessed after a preset time.

[0063] By displaying the first piece of information and sending it to the second device, users of both devices are simultaneously informed of the task migration requirement, ensuring transparency in the migration decision and informed participation from both ends. Furthermore, by receiving the user's first input, the first device can obtain the user's attitude towards the migration suggestion. Based on this, the task is only sent after the first input indicates the user's agreement to the task migration and a confirmation message is received from the second device, ensuring that the migration execution requires mutual confirmation from both ends. This mechanism avoids the privacy risks that might arise from automatically executing task migration without the user's knowledge or consent, ensuring user controllability of the migration operation.

[0064] In some optional embodiments, after performing step 103, the following steps may also be performed: Step S31: Enable low power mode.

[0065] Low-power mode is an operating mode that reduces the overall power consumption of a device. It can be achieved by adjusting the hardware operating parameters and software scheduling strategies of the primary device. In low-power mode, the primary device no longer undertakes high-intensity tasks, thereby reducing unnecessary energy consumption, extending battery life, and lowering device temperature.

[0066] Enabling low-power mode may include, but is not limited to, at least one of the following: reducing the CPU frequency, reducing the screen refresh rate, reducing the temperature control threshold, limiting background processes, reducing screen brightness, and disabling graphics processor hardware acceleration. Low-power mode is not permanent; it automatically exits when certain conditions are met, such as when battery power is restored or tasks are rolled back, and then returns to normal operation.

[0067] Reducing the CPU frequency refers to lowering the CPU's operating clock frequency or switching to a low-power computing core. For example, switching the CPU from a high-performance, large core to a low-power, small core. This operation reduces the CPU's power consumption and minimizes energy loss due to inefficient computing power output.

[0068] Lowering the screen refresh rate means reducing the number of times the screen refreshes its image per second. For example, reducing it from 120Hz to 60Hz. This reduces the rendering load and power consumption of the display driver, minimizing unnecessary energy consumption in the display process.

[0069] Lowering the temperature control threshold refers to reducing the trigger temperature value of the device's temperature control protection mechanism. For example, lowering the temperature control trigger threshold from 42℃ to 39℃. This operation can activate the heat dissipation strategy in advance, avoid heat buildup in the device, and simultaneously constrain computing performance to reduce power consumption.

[0070] Limiting background processes refers to restricting or suspending the operation of unnecessary background processes. For example, suspending high-power-consuming processes such as automatic updates, cloud synchronization, and data indexing. This operation eliminates unnecessary computing power consumption and power drain caused by background processes, reducing device power consumption in the background.

[0071] Reducing screen brightness refers to lowering the output brightness of the screen backlight. For example, reducing the screen backlight brightness to 70% of its current level. This operation can reduce display power consumption without affecting the basic display.

[0072] Disabling graphics processor hardware acceleration means disabling the graphics processor's hardware rendering acceleration and switching to the central processing unit's software rendering path. For example, disabling graphics processor hardware acceleration in browsers and office applications. This reduces the workload on the graphics processor and decreases the power consumption of the graphics hardware.

[0073] Optionally, if the first device is the screen mirroring initiator, such as a mobile phone, the specific operations for enabling low power mode may include, but are not limited to, at least one of the following: reducing the CPU frequency, reducing the screen refresh rate, reducing the temperature control threshold, and limiting background processes.

[0074] Optionally, if the first device is a screen mirroring receiver, such as a PC, the specific operations for enabling low power mode may include, but are not limited to, at least one of the following: reducing the screen refresh rate, reducing the screen brightness, disabling the graphics processor hardware acceleration function, and limiting background processes.

[0075] Step S32: If the operating status of the first device or the second device meets the third condition, display the third information and send the fourth information to the second device. The third information is used to ask the user whether they agree to the migration of at least one of the above tasks, and the fourth information is used to ask the user whether they agree to the migration of at least one of the above tasks.

[0076] After enabling low-power mode, the first device can continue to periodically acquire its own and the second device's operating status data to determine their respective operating states. When the operating status of either the first or second device meets a third condition, it can be determined that task migration is necessary. The third condition refers to the conditions that trigger task migration from the second device back to the first device. Setting this third condition ensures that the timing of task migration is reasonable, preventing premature migration that could overload the first device again, and preventing excessive burden on the second device that could result in premature migration.

[0077] For example, the third condition may include: the remaining power of the first device recovers to above a preset threshold, and the load score of the first device is lower than the load score of the second device. Meeting this condition indicates that the first device has recovered sufficient computing power.

[0078] For example, the third condition may include: the second device experiencing an abnormal state. For instance, the second device's remaining battery power drops below 20%, the device temperature exceeds a safe threshold, or the CPU or GPU utilization rate remains above 85% for more than 10 seconds. In this case, it is necessary to urgently transfer tasks back to alleviate the burden on the second device.

[0079] When the operating status of either the first or second device meets the third condition, the first device can display third information and send fourth information to the second device. The third information can be used to ask the user whether they agree to migrate at least one of the aforementioned tasks in, and the fourth information can be used to ask the user whether they agree to migrate at least one of the aforementioned tasks out. The content of the third and fourth information may include, but is not limited to, a summary of the current power consumption status, a list of tasks to be migrated back, an estimate of the impact on the performance of both devices after migration, and interactive controls for user operation, such as "Confirm Migration" and "Reject" buttons. By displaying the third information on the first device and the fourth information on the fourth device, it can be ensured that both end users are aware of the migration suggestion and can make their own decisions.

[0080] The migration in and migration out of at least one of the aforementioned tasks constitutes migration back, which refers to the process of transferring a task previously migrated from the first device to the second device back to the first device for execution. When the second device migrates at least one task back to the first device, it can transmit information such as the current task's execution progress, intermediate data, and context back to the first device. The first device then continues execution based on this information, ensuring the continuity and integrity of the task. After the migration is complete, the first device exits low-power mode and resumes normal operation.

[0081] Step S33: Receive the user's second input.

[0082] The second input refers to the user's interaction indicating whether they agree to the migration of at least one of the aforementioned items in response to the third information. In other words, it indicates whether the user agrees to the task migration interaction and is the user's response to the task migration suggestion. The second input can be touch input, voice command, a specific gesture input by the user, or other feasible input. The specific form can be determined according to actual usage needs, and this application embodiment does not impose any limitations. For example, the specific form of the second input is similar to the first input; it can be a gesture operation where the user clicks the "Confirm Migration" or "Reject" button on the touchscreen, or a voice command issued through a voice assistant, etc., and is not limited here.

[0083] Step S34: If the second input indicates that the user agrees to migrate at least one of the above tasks and a confirmation message for the fourth information is received from the second device, execute at least one of the above tasks and exit the low-power mode.

[0084] After receiving the second input from the user, and with the consent of both users on both devices, the second device will then transfer the task back to the first device. Upon receiving the task from the second device, the first device can continue executing it.

[0085] Upon receiving confirmation from the second device regarding the fourth information, after the second input indicates that the user agrees to migrate at least one task, the first device exits low-power mode and restores all operating parameters to their pre-migration values. This includes restoring the CPU frequency, screen refresh rate, temperature control threshold, and background process limits. The first device then returns to its normal, full-function operating state. Alternatively, it can exit low-power mode and restore all operating parameters to their pre-migration values ​​after successfully receiving and initiating the migration of the task.

[0086] By immediately enabling low-power mode after task migration, the source device avoids remaining in a high-power idling state after task migration out, achieving low-power adaptive operation of the source device. Furthermore, upon meeting the third condition, a third message is displayed and a fourth message is sent to the second device, allowing both end users to be promptly informed of the migration requirement and jointly confirm it, ensuring that the migration decision is executed with the user's knowledge and consent. By exiting low-power mode upon receiving confirmation from the second device regarding the fourth message after the second input instructs the user to agree to migrate at least one of the aforementioned tasks, automatic task return and automatic recovery of the source device's operating state are achieved once the source device regains sufficient capacity. Through this mechanism, a closed-loop power management system is formed from load migration to load return, ensuring that the source device operates at low power during task migration out and automatically recovers to full functionality after task return, thereby minimizing the overall power consumption of the source device and avoiding the potential overload risk of the target device due to prolonged migration tasks, achieving a dynamic balance between power consumption and performance of both end devices.

[0087] In some optional embodiments, the operating status data includes the remaining battery power. Based on this, the following steps may also be performed: Step S41: Determine the power consumption adjustment level based on the remaining power.

[0088] Power consumption adjustment levels can be pre-defined as needed. Different levels correspond to different remaining battery ranges. The remaining battery power of both devices can be determined based on their operating status data, and then the power consumption adjustment level can be determined based on the remaining battery power. The division of power consumption adjustment levels allows the device to dynamically balance screen projection quality and device power consumption. That is, when the battery is sufficient, priority is given to ensuring the screen projection experience, and when the battery is low, priority is given to ensuring battery life.

[0089] For example, the power consumption adjustment levels are specifically divided into a first level, a second level, and a third level, which can also be referred to as peak level, off-peak level, and minimalist level, respectively.

[0090] When the remaining battery levels of both the first and second devices are above a first threshold, such as above 50%, the power consumption adjustment level can be set to the first level. At this level, both devices have ample battery power, eliminating the need for significant power consumption limitations and prioritizing the optimal screen mirroring experience. For example, 60fps encoding and streaming can be maintained, with only encoding parameters optimized, such as using High Efficiency Video Coding (H.265 / HEVC) instead of Advanced Video Coding (H.264 / AVC). This power consumption adjustment level is suitable for screen mirroring scenarios such as video mirroring and game mirroring.

[0091] When the remaining battery power of either the first device or the second device is less than or equal to a first threshold and greater than or equal to a second threshold (e.g., less than or equal to 50% and greater than or equal to 30%), the power consumption adjustment level can be determined as the second level. At this level, at least one device's battery power has dropped to a moderate level, requiring a moderate reduction in power consumption to extend battery life, but extreme energy-saving measures are not yet necessary. For example, the rendering frame rate of the screen-sharing initiator in both the first and second devices can be reduced to 30fps, the CPU frequency limited to 80% of the baseline, and background synchronization disabled; simultaneously, the screen refresh rate of the screen-sharing receiver can be reduced to 60Hz. This power consumption adjustment level is suitable for screen-sharing scenarios such as PPT (PowerPoint presentation) and document projection.

[0092] When the remaining battery power of either the first or second device falls below the second threshold, for example, less than 30%, the power consumption control level can be set to the third level. At this level, at least one device's battery is already at a low level, requiring the most stringent energy-saving measures to extend the screen mirroring duration as much as possible, prioritizing the continuous operation of basic screen mirroring functions. For example, the CPU frequency of the screen mirroring initiator in both the first and second devices can be reduced to 40% of the baseline, its screen turned off, and all non-screen mirroring processes paused; simultaneously, the screen mirroring receiver can reduce its screen refresh rate to 60Hz and decrease its screen brightness.

[0093] It should be noted that the switching between the above-mentioned power levels is automatic and requires no manual intervention from the user. Each time a switch occurs, the first and second devices can simultaneously display a notification card, informing the user of the current power level and power consumption strategy. The user can also manually adjust the power level or lock the current power level in the notification.

[0094] Step S42: Adjust the operating parameters of the first device according to the power consumption control level, and send third information to the second device. The third information is used to instruct the second device to adjust the operating parameters according to the power consumption control level.

[0095] Different power consumption adjustment levels correspond to different operating parameters. Operating parameters are adjustable configuration parameters at both the device hardware and system levels, and their values ​​directly affect the device's performance output and power consumption level. Specifically, operating parameters include, but are not limited to, at least one of the following: encoding frame rate, rendering frame rate, screen refresh rate, CPU frequency, screen brightness, screen on / off status, and on / off status of non-projection processes.

[0096] The encoding frame rate is the number of frames per second (fps) at which the screen-sharing initiator encodes and outputs the screen-sharing image. It determines the computational load and output bitrate of the screen-sharing encoding. For example, an encoding frame rate of 60 fps provides a smooth screen-sharing image, but consumes more power; an encoding frame rate of 30 fps significantly reduces the power consumption of the screen-sharing initiator. The rendering frame rate is the number of frames per second at which the displayed image is rendered and output. It reflects the intensity of graphics rendering load, and adjusting the rendering frame rate directly affects the GPU's computational power consumption. The screen's on / off state can include whether the device screen is on or off. Non-screen-sharing processes are background processes unrelated to the screen-sharing service; their on / off state can include running or paused.

[0097] After determining the power consumption control level, the first device can adjust its operating parameters according to the power consumption strategy corresponding to that level, and send third information to the second device through the screen projection connection channel. This third information can be used to instruct the second device to adjust its operating parameters according to this power consumption control level.

[0098] By determining the power consumption adjustment level based on the remaining battery level, the system can match the corresponding energy-saving strategy to the actual battery life pressure of both devices. When the battery is sufficient, it prioritizes ensuring screen mirroring quality; when the battery is low, it increases energy saving efforts, achieving a dynamic balance between power consumption optimization and user experience. By adjusting the operating parameters of the first device according to the power consumption adjustment level and sending a third message to the second device to instruct it to adjust its operating parameters synchronously, the power consumption strategies of both devices can be kept consistent, jointly adapting to the current battery life pressure. This avoids the coordination mismatch and weakened energy-saving effect caused by one device entering energy-saving mode while the other continues to maintain high power consumption. In this way, the screen mirroring battery life can be extended to the maximum extent while ensuring the screen mirroring function, reducing the risk of unexpected screen mirroring interruption due to battery depletion.

[0099] In some optional embodiments, the first device is the screen mirroring initiator, and the second device is the screen mirroring receiver. Based on this, the following steps can also be performed: Step S51: If the change rate of the projected screen is less than the change rate threshold and the duration is greater than the first duration threshold, or if the duration of the user interruption operation is greater than the second duration threshold, enable the low power mode and send fourth information to the second device. The fourth information is used to instruct the second device to enable the low power mode.

[0100] The screen mirroring change rate is the proportion of the total screen area where pixels change between consecutive frames. It reflects the dynamism of the mirrored content. In video or game mirroring scenarios, the image is constantly changing, resulting in a high change rate. In document mirroring scenarios, where there are pauses or user pauses, the image content is essentially static, leading to a very low change rate. By detecting the screen mirroring change rate in real time, time periods when the user is not interacting and the image is static can be identified, allowing for proactive reduction of device power consumption during these periods.

[0101] The rate of change threshold is a preset critical value used to determine whether the screen has entered a static state. When the rate of change of the projected screen is lower than the rate of change threshold, it indicates that the content of the projected screen has not changed much, and it can be considered that the projected content has entered a static or intermittent state. For example, the rate of change threshold can be set to 2%. When the rate of change of the projected screen is consistently lower than 2%, it can be determined that the screen is in a static idle state. The setting of the rate of change threshold can balance energy saving effect and response sensitivity. If the rate of change threshold is too high, it may lead to frequent false alarms of entering an intermittent state. If the rate of change threshold is too low, it may miss the true static period. Its specific value can be set according to the projection scenario, and no specific limit is set here.

[0102] The first duration threshold is a preset minimum duration required for the screen's change rate to remain below the threshold. Only when the screen's change rate remains below the threshold for an extended period can an intermittent period be determined. Setting this first duration threshold prevents accidental triggering of the intermittent power-saving mode due to momentary screen freezes. The specific value of the first duration threshold can be set according to the actual application scenario; for example, it can be set to 5 seconds.

[0103] User interruption refers to a user ceasing all interactive input with the projection device, including touch, button, and voice input, and entering a state of inactivity. In other words, continuous touch input indicates interaction with the projection content; prolonged inactivity suggests the user has paused operation or temporarily left the device.

[0104] The second duration threshold is a preset minimum duration required for user interruption. When the duration of user inactivity reaches the second duration threshold, it can be determined that the user has entered an inactive state, and an intermittent power-saving mode can be triggered. For example, the specific value of the second duration threshold can be set to 1 minute, that is, when the user does not perform any touch operation for 1 minute, it is determined that an intermittent period has begun.

[0105] Specifically, the first device can analyze the changes in the content of the currently projected screen in real time. It compares the currently captured screen frame with the previous frame at the pixel level, calculates the percentage of pixels that have changed out of the total number of pixels, and obtains the current screen change rate. For example, if 1.5% of the pixels in the current frame have changed compared to the previous frame, then the current screen change rate is 1.5%. Simultaneously, the first device can monitor in real time whether the user is performing interactive operations such as touching, clicking, swiping, or pressing buttons, and records the duration from the end of the last user operation to the current moment. For example, if the user last touched the screen 45 seconds ago, then the duration of the user's interrupted operation is 45 seconds.

[0106] If the rate of change of the projected screen is less than the rate of change threshold, such as 2%, and the duration of this state is greater than the first duration threshold, such as 5 seconds, it indicates that the projected content itself has entered a static state. If the duration of the user's interrupted operation is greater than the second duration threshold, such as 1 minute, it indicates that the user has not interacted with the device for a long time. When either of the above two conditions is met, it can be determined that an interval period has begun. At this time, the first device can immediately enable low-power mode to perform power reduction operations on its own end. For example, it can pause video encoding and streaming, and continue to send the last cached frame of the projected screen data to maintain the active projected connection, while reducing the CPU frequency, such as to the lowest available power level. At the same time, a fourth message can be sent to the second device through the projected connection channel to instruct the second device to simultaneously enable low-power mode to perform power reduction operations, such as reducing the video decoding frequency and the graphics processor load. Thus, both devices can enter a low-power state simultaneously.

[0107] Step S52: In low power mode, if the rate of change of the projected screen is detected to be greater than the rate of change threshold or the user operation is restored, the low power mode is exited and a fifth message is sent to the second device. The fifth message is used to instruct the second device to exit the low power mode.

[0108] Even after enabling low-power mode, the first device does not stop monitoring the screen change rate and user operation status. It continues to monitor these two metrics in real time to determine when to exit low-power mode. In practice, exiting low-power mode is determined when the screen change rate exceeds a threshold (i.e., the screen begins to change again) or when user operation resumes (i.e., the user resumes touching or operating the device).

[0109] Upon determining that it must exit low-power mode, the first device immediately exits low-power mode and performs local recovery operations. For example, it resumes video encoding and streaming, restarting screen capture, encoding, and transmission, and restores the CPU frequency to its normal operating frequency. Simultaneously, the first device sends a fifth message to the second device via the screen mirroring connection channel, instructing the second device to exit low-power mode. Upon receiving the fifth message, the second device can exit low-power mode and perform its own recovery operations. For example, it restores the video decoding frequency to the normal decoding frame rate and the graphics processor load to the normal rendering load.

[0110] Furthermore, the first device can cumulatively record the duration of each intermittent period and the corresponding power consumption reduction; when the screen projection connection is disconnected, it generates and outputs a power saving statistics report for this screen projection process, showing the user the total energy-saving duration of this screen projection, the estimated power saving, and other information.

[0111] By detecting whether the rate of change of the projected screen is less than a rate of change threshold and the duration of the change is greater than a first duration threshold, and whether the duration of the user's interrupted operation is greater than a second duration threshold, the first device can accurately identify when the projected content enters a static state or when the user enters an inactive state. Based on this, when any of the above conditions are met, a low-power mode is activated and a fourth message is sent to the second device to instruct the second device to simultaneously activate the low-power mode. This allows both devices to collaboratively reduce their respective projected loads during periods when the projected content is static or the user is inactive, avoiding the weakened energy-saving effect caused by only one end reducing power consumption while the other end maintains high power consumption. Furthermore, when the rate of change of the projected screen is detected to be greater than the rate of change threshold or the user operation is resumed in low-power mode, the device exits the low-power mode and sends a fifth message to the second device to instruct the second device to simultaneously exit the low-power mode. This allows both devices to quickly resume normal operation the moment the user resumes operation or the screen begins to change, avoiding user-perceptible response stuttering caused by exit delay. Through the above mechanism, the screen projection load of both devices is actively reduced and quickly restored during the intermittent screen projection period. This reduces the ineffective power consumption during the intermittent period without affecting the user's normal screen projection experience, extends the screen projection battery life of the device, and avoids the continuous rise in device temperature caused by long-term high-load operation.

[0112] In some optional embodiments, the first condition includes a first sub-condition and a second sub-condition. The first sub-condition includes: the ratio of the load score of the first device to the load score of the second device is greater than a first ratio threshold, and the remaining battery power of the first device is less than a first battery power threshold. The second sub-condition includes: the ratio of the load score of the first device to the load score of the second device is greater than a second ratio threshold, and the remaining battery power of the first device is less than a second battery power threshold. Wherein, the first ratio threshold is greater than the second ratio threshold, and the first battery power threshold is less than the second battery power threshold.

[0113] For example, the first ratio threshold is 1.5, the first power threshold is 30%, and the first sub-condition is met when the load score of the first device is more than 1.5 times that of the second device and the remaining power of the first device is less than 30%. The second ratio threshold is 1.2, the second power threshold is 50%, and the first sub-condition is met when the load score of the first device is more than 1.2 times that of the second device and the remaining power of the first device is less than 50%.

[0114] The first sub-condition reflects an emergency state where the first device is under high load and low power, requiring the immediate migration of tasks with high resource utilization to the second device. The second sub-condition reflects a state where the first device is under moderate load and with moderate power, requiring the migration of tasks with low resource utilization to the second device to alleviate the load. The trigger threshold for the second sub-condition is lower than that for the first sub-condition. The first and second sub-conditions together constitute the first condition, with the urgency of migration corresponding to the first sub-condition being higher than that of the second sub-condition.

[0115] Based on this, step 103 may further include: Step S61: If the load score satisfies the first sub-condition, at least one first task of the first device is sent to the second device for processing.

[0116] The primary task is the one with the highest resource consumption, also known as the heavy task. Primary tasks typically have a high resource consumption rate, meaning they consume significant computing resources such as CPU, GPU, and memory. Examples include, but are not limited to, video decoding, document rendering, and data processing tasks. Migrating these tasks to the secondary device can minimize the load on the primary device.

[0117] Resource utilization refers to the degree to which a task consumes the device's computing resources during execution. Computing resources may include, but are not limited to, the central processing unit (CPU), graphics processing unit (GPU), memory, and bandwidth. Tasks with higher resource utilization require greater computing power and higher power consumption from the device. Resource utilization can be estimated based on historical statistical data of the task type, or it can be dynamically evaluated based on real-time resource monitoring data during task execution; no specific limitation is made here.

[0118] Step S62: If the load score does not meet the first sub-condition but meets the second sub-condition, at least one second task of the first device is sent to the second device for processing.

[0119] The second task is a task with lower resource consumption, also known as a light task. The resource consumption of the first task is greater than that of the second task. The second task typically has a lower resource consumption than the first task. For example, it may include, but is not limited to, notification message processing tasks, audio encoding and decoding tasks, and user interface rendering calculation tasks. In light-load migration scenarios, migrating it to the second device can appropriately reduce the load on the first device without placing an excessive burden on the second device.

[0120] By dividing the first condition into a first sub-condition and a second sub-condition, when the first sub-condition is met, the first task with higher resource utilization is migrated to the second device for processing; when the first sub-condition is not met but the second sub-condition is met, the second task with lower resource utilization is migrated to the second device for processing. This allows the migration operation to match the corresponding task according to the actual load and power urgency of the source device. Through this mechanism, refined and hierarchical control of load migration decisions is achieved, thereby ensuring effective load reduction for the source device while taking into account the receiving capacity of the target device, improving the flexibility and scenario adaptability of the load balancing strategy.

[0121] In summary, based on one or more of the above embodiments, Figure 2 A schematic diagram illustrating an application scenario for load balancing methods is provided. In this scenario, after a screen mirroring connection is established between the mobile phone and the computer, both devices collect their respective operational status data in real time at preset intervals, such as 1 minute, and send this data to each other through the screen mirroring connection channel, enabling both devices to obtain each other's operational status data. For the mobile phone, it can calculate the load score for both the mobile phone and the computer based on the acquired operational status data. The mobile phone compares the load scores of both devices and makes a conditional judgment based on the remaining battery power of both devices: if the first condition is met, i.e., the mobile phone's load score exceeds the computer's load score by a predetermined multiple, and the mobile phone's remaining battery power is below a predetermined threshold, then the process of migrating tasks from the mobile phone to the computer for processing is initiated; if the second condition is met, i.e., the computer's load score exceeds the mobile phone's load score by a predetermined multiple, and the computer's remaining battery power is below a predetermined threshold, then the process of migrating tasks from the computer to the mobile phone for processing is initiated; if neither condition is met, the process returns to the real-time operational status collection step for both the mobile phone and the computer and continues monitoring.

[0122] When the first condition is met, the phone sends a load migration notification to the user, requesting manual confirmation whether to migrate local tasks to the computer. Simultaneously, the phone sends a notification to the computer, and the computer also sends a corresponding notification to the user on the computer, requesting confirmation of acceptance of the migration task. After both devices confirm, the phone migrates at least one local task to the computer. If either device refuses confirmation, the migration is not executed, and the status of both devices is reassessed after 30 minutes. After the task migration is complete, the phone automatically switches to low-power mode to reduce power consumption.

[0123] After the phone enters low-power mode, it continues to acquire and monitor the operating status data of both devices at preset intervals. When the monitored operating status data meets a third condition, such as the phone's battery level recovering to above 60% and the phone's load score being lower than the computer's load score, or the computer's battery level being too low / temperature being too high / load being consistently too high, the phone sends a load rollback notification to the user, requesting manual confirmation whether to roll back the task from the computer to the phone. Simultaneously, the phone sends a notification to the computer, and the computer also sends a corresponding notification to the user on the computer, requesting confirmation of agreement to the rollback. After both devices confirm, the task is rolled back from the computer to the phone, and the phone exits low-power mode and resumes normal operation. If either device refuses confirmation, the rollback is not executed.

[0124] When the second condition is met, the computer's processing flow is similar to that of the mobile phone when the first condition is met. To avoid repetition, it will not be described again here.

[0125] The above process is executed cyclically, forming a complete closed loop of monitoring, evaluation, migration, low power consumption at the source, continuous monitoring, and relocation.

[0126] It should be noted that the load balancing method provided in this application embodiment can be executed by a load balancing device. This application embodiment uses the execution of the load balancing method by a load balancing device as an example to illustrate the load balancing device provided in this application embodiment.

[0127] like Figure 3 As shown, the load balancing device 300 in this embodiment includes: an acquisition unit 301, configured to acquire operating status data of the first device and the second device when the first device and the second device are connected for screen projection; a determination unit 302, configured to determine the load score of the first device and the second device based on the operating status data; a sending unit 303, configured to send at least one task of the first device to the second device for processing when the load score meets a first condition; and a receiving unit 304, configured to receive and process the task sent by the second device when the load score meets a second condition.

[0128] In some optional implementations of this embodiment, the operating status data includes at least one of the following: CPU utilization, GPU utilization, power consumption, device temperature, and screen refresh rate; the determining unit is specifically used to: determine the weight of each operating status data based on the screen projection scenario; and, based on the weight, perform a weighted summation of each operating status data of the first device and the second device to obtain the load scores of the first device and the second device.

[0129] In some optional implementations of this embodiment, the device further includes: a display unit for displaying first information; a sending unit for sending the first information to the second device, wherein the first information is used to ask the user whether to agree to the task migration out, and the second information is used to ask the user whether to agree to the task migration in; a receiving unit for receiving first input from the user; and a sending unit for sending the at least one task to the second device for processing when the first input indicates that the user agrees to the task migration out and a confirmation message for the second information is received from the second device.

[0130] In some optional implementations of this embodiment, the device further includes: an enable unit for enabling a low-power mode; a display unit for displaying third information when the operating state of the first device or the second device meets a third condition, the third information being used to ask the user whether they agree to migrate the at least one task; a sending unit for sending fourth information to the second device when the operating state of the first device or the second device meets the third condition, the fourth information being used to ask the user whether they agree to migrate the at least one task out; a receiving unit for receiving a second input from the user; and an exit unit for executing the at least one task and exiting the low-power mode when the second input indicates that the user agrees to migrate the at least one task and a confirmation message for the fourth information is received from the second device.

[0131] In some optional implementations of this embodiment, the operating status data includes the remaining battery power; the determining unit is further configured to determine a power consumption adjustment level based on the remaining battery power; the sending unit is further configured to adjust the operating parameters of the first device according to the power consumption adjustment level, and send third information to the second device, the third information being used to instruct the second device to adjust the operating parameters according to the power consumption adjustment level; wherein, the operating parameters include at least one of the following: encoding frame rate, rendering frame rate, screen refresh rate, central processing unit frequency, screen brightness, screen on / off state, and on / off state of non-screen projection processes.

[0132] In some optional implementations of this embodiment, the first device is the screen projection initiator and the second device is the screen projection receiver; the device further includes: a startup unit, further configured to enable a low-power mode and send fourth information to the second device when the screen projection change rate is less than a change rate threshold and the duration is greater than a first duration threshold, or when the duration of user interruption is greater than a second duration threshold; the fourth information is used to instruct the second device to enable the low-power mode; and an exit unit, further configured to exit the low-power mode and send fifth information to the second device if the screen projection change rate is detected to be greater than the change rate threshold or the user operation is resumed in the low-power mode, the fifth information is used to instruct the second device to exit the low-power mode.

[0133] In some optional implementations of this embodiment, the first condition includes a first sub-condition and a second sub-condition; the first sub-condition includes: the ratio of the load score of the first device to the load score of the second device is greater than a first ratio threshold, and the remaining power of the first device is less than a first power threshold; the second sub-condition includes: the ratio of the load score of the first device to the load score of the second device is greater than a second ratio threshold, and the remaining power of the first device is less than a second power threshold; the first ratio threshold is greater than the second ratio threshold, and the first power threshold is less than the second power threshold; the sending unit is further configured to: when the load score satisfies the first sub-condition, send at least one first task of the first device to the second device for processing; when the load score does not satisfy the first sub-condition but satisfies the second sub-condition, send at least one second task of the first device to the second device for processing; wherein, the resource utilization rate of the first task is greater than the resource utilization rate of the second task.

[0134] In some optional implementations of this embodiment, when the first device is the screen casting initiator, the at least one task includes at least one of the following: video decoding task, document rendering task, and data processing task; when the first device is the screen casting receiver, the at least one task includes at least one of the following: notification message processing task, audio encoding / decoding task, and user interface rendering calculation task.

[0135] The apparatus provided in the above embodiments of this application allows the first device to simultaneously monitor the load status of both devices during the screen projection process. Based on the load status of both devices, the first device can offload tasks or the second device can be offloaded. This avoids an unbalanced state where one end bears a high load while the other end's resources are idle, achieving load balancing between the two devices in the screen projection scenario, thereby improving the overall utilization rate of computing resources of both devices during the screen projection process.

[0136] The load balancing device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0137] The load balancing device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0138] The load balancing device provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0139] Optionally, such as Figure 4 As shown, this application embodiment also provides an electronic device 400, including a processor 401 and a memory 402. The memory 402 stores a program or instructions that can run on the processor 401. When the program or instructions are executed by the processor 401, they implement the various steps of the above-described load balancing method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0140] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0141] Figure 5 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application. The electronic device 500 includes, but is not limited to, components such as: radio frequency unit 501, network module 502, audio output unit 503, input unit 504, sensor 505, display unit 506, user input unit 507, interface unit 508, memory 509, and processor 510.

[0142] Those skilled in the art will understand that the electronic device 500 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 510 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here. The processor 510 is configured to, when the first device and the second device are connected for screen projection, acquire operating status data of the first device and the second device; determine the load score of the first device and the second device based on the operating status data; if the load score meets a first condition, send at least one task of the first device to the second device for processing; and if the load score meets a second condition, receive and process the task sent by the second device.

[0143] Through the above process, the first device can simultaneously monitor the load status of both devices during screen projection. Based on the load status of both devices, it can either move tasks off the first device or move tasks onto the second device. This avoids the unbalanced state where one end bears a high load while the other end is idle, achieving load balancing between the two devices in the screen projection scenario, thereby improving the overall utilization rate of computing resources of both devices during screen projection.

[0144] In some optional implementations of this embodiment, the operating status data includes at least one of the following: CPU utilization, GPU utilization, power consumption, device temperature, and screen refresh rate; the processor 510 is further configured to determine the weight of each operating status data based on the screen projection scenario; based on the weight, the operating status data of the first device and the second device are weighted and summed respectively to obtain the load scores of the first device and the second device.

[0145] In some optional implementations of this embodiment, the processor 510 is further configured to display first information through the display unit 506 and send the first information to the second device, wherein the first information is used to ask the user whether to agree to the task migration out and the second information is used to ask the user whether to agree to the task migration in; receive the user's first input through the user input unit 507; and, if the first input indicates that the user agrees to the task migration out and a confirmation message for the second information is received from the second device, send the at least one task to the second device for processing.

[0146] In some optional implementations of this embodiment, after sending at least one task from the first device to the second device for processing, the processor 510 is further configured to enable a low-power mode; if the operating state of the first device or the second device meets a third condition, display third information through the display unit 506 and send fourth information to the second device, the fourth information being used to ask the user whether they agree to move the at least one task in, and the fourth information being used to ask the user whether they agree to move the at least one task out; receive a second input from the user; if the second input indicates that the user agrees to move the at least one task in, and a confirmation message for the fourth information is received from the second device, execute the at least one task and exit the low-power mode.

[0147] In some optional implementations of this embodiment, the operating status data includes the remaining battery power; the processor 510 is further configured to determine a power consumption adjustment level based on the remaining battery power; adjust the operating parameters of the first device according to the power consumption adjustment level, and send third information to the second device, the third information being used to instruct the second device to adjust the operating parameters according to the power consumption adjustment level; wherein, the operating parameters include at least one of the following: encoding frame rate, rendering frame rate, screen refresh rate, central processing unit frequency, screen brightness, screen on / off state, and on / off state of non-screen projection processes.

[0148] In some optional implementations of this embodiment, the first device is the screen projection initiator, and the second device is the screen projection receiver. The processor 510 is further configured to enable a low-power mode and send a fourth message to the second device when the screen projection change rate is less than a change rate threshold and the duration is greater than a first duration threshold, or when the duration of user interruption is greater than a second duration threshold. The fourth message is used to instruct the second device to enable the low-power mode. In the low-power mode, if the screen projection change rate is detected to be greater than the change rate threshold or the user operation is resumed, the processor exits the low-power mode and sends a fifth message to the second device, the fifth message being used to instruct the second device to exit the low-power mode.

[0149] In some optional implementations of this embodiment, the first condition includes a first sub-condition and a second sub-condition; the first sub-condition includes: the ratio of the load score of the first device to the load score of the second device is greater than a first ratio threshold, and the remaining power of the first device is less than a first power threshold; the second sub-condition includes: the ratio of the load score of the first device to the load score of the second device is greater than a second ratio threshold, and the remaining power of the first device is less than a second power threshold; the first ratio threshold is greater than the second ratio threshold, and the first power threshold is less than the second power threshold; the processor 510 is further configured to, when the load score satisfies the first sub-condition, send at least one first task of the first device to the second device for processing; when the load score does not satisfy the first sub-condition but satisfies the second sub-condition, send at least one second task of the first device to the second device for processing; wherein, the resource utilization rate of the first task is greater than the resource utilization rate of the second task.

[0150] In some optional implementations of this embodiment, when the first device is the screen casting initiator, the at least one task includes at least one of the following: video decoding task, document rendering task, and data processing task; when the first device is the screen casting receiver, the at least one task includes at least one of the following: notification message processing task, audio encoding / decoding task, and user interface rendering calculation task.

[0151] It should be understood that, in this embodiment, the input unit 504 may include a graphics processing unit (GPU) 5041 and a microphone 5042. The GPU 5041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 506 may include a display panel 5061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 507 includes at least one of a touch panel 5071 and other input devices 5072. The touch panel 5071 is also called a touch screen. The touch panel 5071 may include a touch detection device and a touch controller. Other input devices 5072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0152] The memory 509 can be used to store software programs and various data. The memory 509 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 509 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 509 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0153] Processor 510 may include one or more processing units; optionally, processor 510 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 510.

[0154] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described load balancing method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0155] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0156] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described load balancing method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0157] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0158] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the load balancing method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0159] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0160] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0161] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A load balancing method, characterized in that, Applied to a first device, the method includes: When the first device and the second device are connected for screen projection, obtain the operating status data of the first device and the second device; The load scores of the first device and the second device are determined based on the operational status data. If the load score meets the first condition, at least one task from the first device will be sent to the second device for processing. If the load score meets the second condition, the task sent by the second device is received and processed.

2. The method according to claim 1, characterized in that, The operational status data includes at least one of the following: CPU utilization, GPU utilization, power consumption, device temperature, and screen refresh rate; determining the load score of the first device and the second device based on the operational status data includes: The weights of various operational status data are determined based on the screen projection scenario. Based on the weights, the various operating status data of the first device and the second device are weighted and summed to obtain the load scores of the first device and the second device.

3. The method according to claim 1, characterized in that, Sending at least one task from the first device to the second device for processing includes: Display first information and send second information to the second device. The first information is used to ask the user whether they agree to the task migration out and the second information is used to ask the user whether they agree to the task migration in. Receive the user's first input; If the first input indicates that the user agrees to the task migration and a confirmation message for the second information is received from the second device, the at least one task is sent to the second device for processing.

4. The method according to claim 1, characterized in that, After sending at least one task from the first device to the second device for processing, the method further includes: Enable low power mode; If the operating status of the first device or the second device meets the third condition, the third information is displayed and the fourth information is sent to the second device. The third information is used to ask the user whether they agree to move the at least one task in, and the fourth information is used to ask the user whether they agree to move the at least one task out. Receive the user's second input; If the second input indicates that the user agrees to migrate the at least one task and the second device returns a confirmation message for the fourth information, the at least one task is executed and the low-power mode is exited.

5. The method according to claim 1, characterized in that, The operating status data includes the remaining battery power; the method further includes: Based on the remaining battery power, determine the power consumption adjustment level; The operating parameters of the first device are adjusted according to the power consumption control level, and a third message is sent to the second device, the third message being used to instruct the second device to adjust the operating parameters according to the power consumption control level; The operating parameters include at least one of the following: encoding frame rate, rendering frame rate, screen refresh rate, central processing unit frequency, screen brightness, screen on / off status, and on / off status of non-screen projection processes.

6. A load balancing device, characterized in that, Applied to a first device, the device includes: The acquisition unit is used to acquire the operating status data of the first device and the second device when the first device and the second device are connected for screen projection. The determining unit is used to determine the load scores of the first device and the second device based on the operating status data; The sending unit is configured to send at least one task of the first device to the second device for processing when the load score meets the first condition. The receiving unit is configured to receive and process the task sent by the second device when the load score meets the second condition.

7. The apparatus according to claim 6, characterized in that, The operating status data includes at least one of the following: CPU utilization, GPU utilization, power consumption, device temperature, and screen refresh rate; the determining unit is specifically used for: The weights of various operational status data are determined based on the screen projection scenario. Based on the weights, the various operating status data of the first device and the second device are weighted and summed to obtain the load scores of the first device and the second device.

8. The apparatus according to claim 6, characterized in that, The device further includes: The display unit is used to display the first information; The sending unit is further configured to send second information to the second device, wherein the first information is used to ask the user whether they agree to the task migration out, and the second information is used to ask the user whether they agree to the task migration in; The receiving unit is also used to receive the user's first input; The sending unit is further configured to send the at least one task to the second device for processing when the first input indicates that the user agrees to the task migration and the second device returns a confirmation message for the second information.

9. The apparatus according to claim 6, characterized in that, The device further includes: Enable unit, used to enable low-power mode; The display unit is configured to display third information when the operating status of the first device or the second device meets the third condition, wherein the third information is used to ask the user whether they agree to migrate the at least one task. The sending unit is further configured to send a fourth message to the second device when the operating state of the first device or the second device meets the third condition, the fourth message being used to ask the user whether they agree to move the at least one task out. The receiving unit is also used to receive a second input from the user; The exit unit is further configured to execute the at least one task and exit the low-power mode when the second input indicates that the user agrees to migrate the at least one task and the second device returns a confirmation message for the fourth information.

10. The apparatus according to claim 6, characterized in that, The operating status data includes the remaining battery power; The determining unit is further configured to determine the power consumption adjustment level based on the remaining power. The sending unit is further configured to adjust the operating parameters of the first device according to the power consumption control level, and send third information to the second device, the third information being used to instruct the second device to adjust the operating parameters according to the power consumption control level; The operating parameters include at least one of the following: encoding frame rate, rendering frame rate, screen refresh rate, central processing unit frequency, screen brightness, screen on / off status, and on / off status of non-screen projection processes.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the load balancing method as described in any one of claims 1-5.

Images