Flash control method, device, medium and program product

Abstract

Embodiments of the present application provide a flash control method, device, medium and program product, relating to the technical field of control or the technical field of electronic devices. The method is applied to an electronic device, and the method comprises: collecting multi-scene event data through a service layer; inputting structured feature information in the multi-scene event data into a priority determination model, performing priority determination on the scene event data through the attention mechanism of the priority determination model by weighted fusion of event types, time dimension features and user historical behavior features, and generating an event queue containing scene identifiers and priorities; dynamically allocating flash hardware resources through a hardware abstraction layer based on the scene identifiers and priorities in the event queue, generating a light effect task queue; and controlling the flash to execute corresponding light effects according to the light effect task queue. The method is used to achieve flexible priority scheduling through the priority determination model, improve the effect of flash resource scheduling and the accuracy of personalized scene matching.

Description

Technical Field

[0001] This application relates to the field of control technology or electronic equipment technology, and in particular to a flash lamp control method, device, medium and program product. Background Technology

[0002] As smartphones and other mobile electronic devices become increasingly feature-rich, flashlights are used as supplementary lighting tools for taking photos. Therefore, improving the user experience by controlling the flashlight is crucial.

[0003] Currently, existing flash control methods mainly achieve photo lighting through hardware logic driver interfaces. This method relies on a single control logic and hardware call, resulting in limited functionality, poor flash resource scheduling, difficulty in adjusting priorities, and poor accuracy in matching personalized scenes. Summary of the Invention

[0004] This application provides a flash control method, device, medium, and program product, which uses a priority determination model to achieve flexible priority scheduling, improve the accuracy of flash resource scheduling and personalized scene matching.

[0005] In a first aspect, embodiments of this application provide a flash control method applied to an electronic device. The electronic device has a layered architecture, including a hardware abstraction layer, a service layer, and an application layer. The hardware abstraction layer controls flash hardware resources, the service layer monitors multiple scene events and generates scene event data, and the application layer provides a user interaction interface. A pre-trained priority determination model is deployed in the service layer, and the priority determination model is used to determine the priority of scene event data. The method includes:

[0006] The service layer collects multi-scenario event data, which includes at least the following alert-triggered data: incoming call alerts, charging alerts, low battery alerts, and lock screen notification alerts. Each scenario event data contains structured feature information, including event type, time dimension features, and user historical behavior features. The structured feature information from the multi-scenario event data is input into the priority determination model. The attention mechanism of the priority determination model performs weighted fusion of the event type, the time dimension features, and the user historical behavior features to determine the priority of the scenario event data, generating an event queue containing scenario identifiers and priorities.

[0007] Based on the scene identifier and priority in the event queue, the flash hardware resources are dynamically allocated through the hardware abstraction layer to generate a lighting effect task queue.

[0008] The flashlight is controlled to perform the corresponding lighting effect according to the lighting effect task queue.

[0009] In one possible implementation, the priority determination model includes an embedding layer, a multi-head attention layer, a feature fusion layer, and a priority output layer;

[0010] Wherein: the embedding layer is used to convert the structured feature information of the scene event data into a low-dimensional dense feature vector; the multi-head attention layer is used to extract multi-dimensional related features of the event type, the time dimension feature, and the user historical behavior feature, and output the attention weight of each feature; the feature fusion layer is used to weightedly fuse the attention weight and the feature vector to generate a fused feature representation; the priority output layer is used to determine the priority of the fused feature representation in combination with basic priority rules;

[0011] The basic priority rules include: incoming call reminders have a higher priority than low battery reminders, low battery reminders have a higher priority than lock screen notifications, and lock screen notifications have a higher priority than charging reminders.

[0012] In one possible implementation, the dynamic allocation of the flash hardware resources through the hardware abstraction layer includes:

[0013] A task queue is maintained in the service layer, and the task queue is sorted according to the scenario priority in the event queue.

[0014] Based on the scene identifier in the task queue, the hardware abstraction layer calls the preset lighting effect parameters to generate a lighting effect task queue containing lighting effect configuration information.

[0015] The method further includes:

[0016] When the flash hardware resources are occupied, the unexecuted lighting effect tasks will be suspended, and the step of generating the lighting effect task queue will continue after the hardware resources are released.

[0017] In one possible implementation, generating the lighting effect task queue containing lighting effect configuration information includes:

[0018] Based on the scene identifier, preset lighting effect parameters are called through the hardware abstraction layer. The lighting effect parameters include brightness, flashing frequency and color corresponding to different scenes.

[0019] The lighting effect task queue is generated based on the preset lighting effect parameters;

[0020] The lighting effect parameters include at least one of the following:

[0021] The target breathing light corresponds to the incoming call scenario, the target red flashing light corresponds to the low battery scenario, and the multi-color flashing light corresponds to the lock screen notification scenario; the target breathing light is a breathing light with a brightness greater than a first preset brightness threshold, and the target red flashing light is a red flashing light with a flashing frequency greater than a first preset frequency threshold.

[0022] In one possible implementation, ambient light sensor data is invoked in the service layer to dynamically adjust the brightness and flicker frequency in the lighting effect parameters based on the ambient light intensity. Specifically, this dynamic adjustment of the brightness and flicker frequency in the lighting effect parameters based on ambient light intensity includes at least one of the following: increasing brightness and flicker frequency in strong light environments, and decreasing brightness and extending the flicker interval in weak light environments. The ambient light intensity value in the strong light environment is greater than that in the weak light environment, and the ambient light intensity ranges corresponding to the strong light environment and the weak light environment are preset.

[0023] In one possible implementation, the priority rules of each scenario in the generated event queue are dynamically adjusted based on the output of the user behavior analysis module; wherein, the service layer is provided with the user behavior analysis module, which is used to record the user's response behavior to scenario events through system logs.

[0024] In one possible implementation, when there is a currently executing lighting effect task in the lighting effect task queue, the flash is controlled to execute the lighting effect corresponding to the current lighting effect task;

[0025] If a new first lighting effect task is received during the execution of the current lighting effect task, and the priority of the new first lighting effect task is higher than the priority of the current lighting effect task, then the current lighting effect task is paused and its execution progress information is saved.

[0026] Add the new first lighting effect task to the lighting effect task queue and execute it with priority, and control the flash to execute the lighting effect corresponding to the new first lighting effect task;

[0027] Once the new high-priority lighting effect task is completed, the control of the flashlight to execute the lighting effect corresponding to the current lighting effect task that was paused is restored according to the saved execution progress information.

[0028] If a new second lighting effect task is received during the execution of the current lighting effect task, and the priority of the new second lighting effect task is lower than or equal to the priority of the current lighting effect task, then the new second lighting effect task is added to the tail of the lighting effect task queue.

[0029] Once the current lighting effect task is completed, control the flash to execute the lighting effect corresponding to the new second lighting effect task.

[0030] Secondly, embodiments of this application provide a flash control device. The electronic device has a layered architecture, including a hardware abstraction layer, a service layer, and an application layer. The hardware abstraction layer controls flash hardware resources, the service layer monitors multiple scene events and generates scene event data, the application layer provides a user interaction interface, and the service layer deploys a pre-trained priority determination model for prioritizing scene event data. The device includes:

[0031] The data collection module is used to collect multi-scenario event data through the service layer. The multi-scenario event data includes at least the following reminder-triggered data: incoming call reminder, charging reminder, low battery reminder, and lock screen notification reminder. Each scenario event data contains structured feature information, which includes event type, time dimension features, and user historical behavior features.

[0032] The first generation module is used to input the structured feature information in the multi-scene event data into the priority determination model, and use the attention mechanism of the priority determination model to perform weighted fusion of the event type, the time dimension feature and the user historical behavior feature to determine the priority of the scene event data, and generate an event queue containing scene identifiers and priorities.

[0033] The second generation module is used to dynamically allocate the flash hardware resources through the hardware abstraction layer based on the scene identifier and priority in the event queue, and generate a lighting effect task queue.

[0034] The control module is used to control the flashlight to execute the corresponding lighting effect according to the lighting effect task queue.

[0035] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0036] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0037] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0038] The flash control method, device, medium, and program product provided in this application embodiment collect multi-scenario event data through a service layer. This multi-scenario event data includes at least the following alert-triggered data: incoming call alerts, charging alerts, low battery alerts, and lock screen notifications. Each scenario event data contains structured feature information, including event type, time dimension features, and user historical behavior features, laying the foundation for subsequent priority determination. The structured feature information from the multi-scenario event data is input into a priority determination model. The attention mechanism of the priority determination model performs weighted fusion of the event type, time dimension features, and user historical behavior features to determine the priority of the scenario event data, generating an event queue containing scene identifiers and priorities, laying the foundation for subsequent flash control. Based on the scene identifiers and priorities in the event queue, the flash hardware resources are dynamically allocated through the hardware abstraction layer, generating a lighting effect task queue. This allows for dynamic adjustment of the lighting effect execution order, avoiding resource contention caused by multi-scenario conflicts. The flash is controlled to execute corresponding lighting effects according to the lighting effect task queue, thereby improving flash resource scheduling through the priority determination model. By combining "dynamic priority determination model", "binding lighting effects with priority" and "queue technology" into a complete technical solution, we can achieve flexible priority adjustment and accurate matching of personalized scenarios. Attached Figure Description

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

[0040] Figure 1 A schematic diagram of a layered architecture of an electronic device provided in an embodiment of this application;

[0041] Figure 2 A flowchart illustrating a flash control method provided in an embodiment of this application;

[0042] Figure 3 This is a schematic diagram of the structure of a priority determination model provided in an embodiment of this application;

[0043] Figure 4 A schematic diagram of the architecture of a flash control system provided in an embodiment of this application;

[0044] Figure 5 A flowchart illustrating a flash control method for an incoming call scenario provided in an embodiment of this application;

[0045] Figure 6 A flowchart illustrating a flash control method in a charging scenario provided in an embodiment of this application;

[0046] Figure 7 A flowchart illustrating a flash control method in a low-battery scenario provided in an embodiment of this application;

[0047] Figure 8 A flowchart illustrating a flash control method for a lock screen notification scenario provided in this application embodiment;

[0048] Figure 9 This is a schematic diagram of the structure of a flash control device provided in an embodiment of this application;

[0049] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0050] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0051] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0052] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0053] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0054] In this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0055] In the embodiments of this application, the use of terms such as "first" and "second" is to distinguish between identical or similar items that have essentially the same function and effect. For example, "first electronic device" and "second electronic device" are merely used to distinguish different electronic devices and do not limit their order of execution. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0056] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0057] In the context of mobile devices such as smartphones, flash is a core tool for supplementing light in photography, which can enhance the user's interactive experience. Therefore, flash control is of paramount importance.

[0058] Currently, existing flash control methods mainly employ fixed lighting effects, implementing photo lighting through hardware logic driver interfaces. These methods achieve only the single function of photo lighting through a single control logic and hardware call. Therefore, existing flash control methods, due to their reliance on fixed configurations and single control logic, suffer from poor scene adaptability, unsatisfactory user experience, and inefficient flash resource scheduling.

[0059] In view of the aforementioned problems with existing flash control methods, this application proposes a dynamic priority scheduling flash control method based on a hierarchical architecture. By using a priority determination model, it achieves flexible priority scheduling, improves flash resource allocation, and enhances multi-scene adaptability and user interaction experience.

[0060] The technical solutions of this application will be described in detail below with reference to specific embodiments. The specific embodiments described below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0061] The entity executing this flash control method can be, for example, a flash control system. Optionally, the flash control system can be any existing electronic device with processing capabilities, such as a terminal or a server. In some embodiments, the flash control system can also be deployed in a server cluster or cloud environment. This application does not limit the deployment environment of the flash control system.

[0062] Figure 1 This is a schematic diagram of a layered architecture of an electronic device provided in an embodiment of this application, such as... Figure 1 As shown, the layered architecture includes a hardware abstraction layer, a service layer, and an application layer. The hardware abstraction layer is used to control the flash hardware resources, the service layer is used to monitor multiple scene events and generate scene event data, the application layer is used to provide user interaction interfaces, and the service layer deploys a pre-trained priority determination model, which is used to determine the priority of scene event data.

[0063] Figure 2 This is a flowchart illustrating a flash control method provided in an embodiment of this application, as shown below. Figure 2 As shown, the method includes:

[0064] S201, collect multi-scenario event data through this service layer. The multi-scenario event data includes at least the following reminders: incoming call reminders, charging reminders, low battery reminders, and lock screen notifications. Each event data in this scenario contains structured feature information, which includes event type, time dimension features, and user historical behavior features.

[0065] For example, scene event data can be structured data representing the flash operation scene, triggered by user behavior or system status. For instance, scene event data may include incoming call alerts, charging alerts, low battery alerts, and lock screen notifications.

[0066] For example, incoming call alert data could be data generated by the phone module when it detects an incoming call.

[0067] Charging reminder data: Data generated by the charging management module when it detects that the charger is connected or disconnected, or when the charging progress changes.

[0068] Low battery alert data: Data generated by the battery management module when it detects that the battery level is lower than a preset power threshold.

[0069] Lock screen notification alert data: Data generated by the notification management module when a new message is detected while the device is locked.

[0070] Optionally, the flash control system can receive scene event data from various functional modules through a preset data interface based on the service layer. It can also set a fixed polling cycle through the service layer to periodically query the data cache corresponding to the scene event data of each functional module.

[0071] For example, when the flash control system detects an incoming call alert triggered by the service layer, it collects the structured feature information of the event. For instance, the structured feature information of the event could be that the event type is an incoming call alert, the time dimension feature is 9 PM, and the user's historical behavior feature is that the user has an 80% probability of turning off the flash alert at 9 PM in the past 7 days.

[0072] S202, the structured feature information in the multi-scenario event data is input into the priority determination model. The attention mechanism of the priority determination model is used to perform weighted fusion of the event type, the time dimension feature, and the user's historical behavior feature to determine the priority of the scenario event data and generate an event queue containing scenario identifiers and priorities.

[0073] Figure 3 This is a schematic diagram of the structure of a priority determination model provided in an embodiment of this application, as shown below. Figure 3 As shown, the priority determination model includes an embedding layer, a multi-head attention layer, a feature fusion layer, and a priority output layer.

[0074] Optionally, the embedding layer is used to convert the structured feature information of the scene event data into a low-dimensional dense feature vector; the multi-head attention layer is used to extract multi-dimensional related features of the event type, the time dimension feature, and the user's historical behavior feature, and output the attention weights of each feature; the feature fusion layer is used to weightedly fuse the attention weights with the feature vector to generate a fused feature representation; and the priority output layer is used to determine the priority of the fused feature representation in combination with the basic priority rules.

[0075] Optionally, the basic priority rules include: incoming call reminders have a higher priority than low battery reminders, low battery reminders have a higher priority than lock screen notifications, and lock screen notifications have a higher priority than charging reminders.

[0076] For example, priority is used to characterize the order in which events in different scenarios are executed.

[0077] For example, a scene identifier can be a unique identifier for each type of scene event, used to distinguish different scene types. For instance, a scene identifier can be in the form of characters, numbers, or enumeration values.

[0078] For example, an event queue can be a list of scene event data containing scene identifiers and priorities, sorted from high to low priority. For example, a time queue can be a list of tasks such as incoming call reminders (priority 1) and charging reminders (priority 4).

[0079] For example, a low-dimensional dense feature vector can be a low-dimensional vector representation with continuous element values ​​and no large number of zero values.

[0080] For example, event types could be incoming call alerts, charging alerts, low battery alerts, and lock screen notifications. Time-related features could also include time periods, dates, and event trigger points. User historical behavior features could include the user's average response time to various types of alerts and their preferences.

[0081] Optionally, the flash control system can convert event types into binary vectors using one-hot encoding, classify and encode time periods and dates in the time dimension features, and normalize the statistical data of user historical behavior features. The flash control system can also map the event types, classified and encoded time dimension features, and normalized user historical behavior features from the aforementioned binary vectors into three feature vectors, each with 64 dimensions, through the embedding layer of a priority determination model. These three feature vectors, each with 64 dimensions, correspond to the event type, time dimension features, and user historical behavior features, respectively.

[0082] Optionally, the flash control system can map the feature vectors, each with three dimensions of 64, to query and key vectors respectively through linear transformations. Based on the eight attention heads of the multi-head attention layer, the system calculates the dot product of the query vector and key vector under each attention head to obtain the association score between each feature. The flash control system can also obtain the initial attention weight of each feature based on the association score through a normalization function. A weighted average of the initial attention weights of each feature output by the eight attention heads is then performed to obtain the attention weights for event type, time dimension features, and user historical behavior features. For example, the flash control system can output an event type attention weight of 0.7, a time dimension feature attention weight of 0.2, and a user historical behavior feature attention weight of 0.1 through the multi-head attention layer.

[0083] Optionally, the flash control system can obtain a fused feature representation of the attention weight and the original feature vector output by the embedding layer through the feature fusion layer based on the formula "event type feature vector × event type attention weight + time dimension feature vector × time dimension attention weight + user history behavior feature vector × user behavior feature attention weight".

[0084] Optionally, the flash control system can input the aforementioned fused feature representation into a two-layer fully connected network based on the priority output layer to obtain an initial priority prediction value, and then calibrate the initial prediction value based on the basic priority rules. For example, if the predicted priority of the low battery alert is higher than that of the incoming call alert, the initial priority prediction value of the low battery alert is reduced. The calibrated priority prediction value is then converted into a priority level and associated with the corresponding scene identifier. For example, the flash control system can obtain an event queue containing scene identifiers and priorities through the priority output layer.

[0085] By employing the above method, the basic priority rules prioritize incoming call alerts over low battery alerts, low battery alerts over lock screen notifications, and lock screen notifications over charging alerts, thus avoiding flash control conflicts triggered in multiple scenarios. The embedding layer of the priority determination model lays the foundation for subsequent feature analysis; the multi-head attention layer of the priority determination model increases the contribution of core features; the feature fusion layer of the priority determination model improves the accuracy of priority determination; and the priority output layer of the priority determination model provides an event queue containing scene identifiers and priorities, thereby improving flash resource scheduling.

[0086] Optionally, the flash control system can invoke preset priority mapping rules through the service layer to perform priority matching on the acquired scene event data. For example, the flash control system can determine the priority of the scene time data based on the priority configuration file stored in the service layer.

[0087] Optionally, the flash system can also store the user-defined priority configuration results in the system database. When the service layer performs priority determination, it can read the user-defined priority configuration from the system database.

[0088] Optionally, the flash control system can use a doubly linked list as the queue data structure at the service layer. Each node in the list stores information such as scene identifier, priority, and trigger timestamp. The node insertion position is determined according to the descending priority of the scene's time data, generating an event queue. For example, the flash control system can insert high-priority events at the front of the list and low-priority events at the back.

[0089] Optionally, the flash control system can also use a preset priority queue as the data structure based on the service layer to automatically sort the event data according to the priority attributes of the scene.

[0090] S203, based on the scene identifier and priority in the event queue, dynamically allocates the flash hardware resources through the hardware abstraction layer to generate a lighting effect task queue.

[0091] For example, the hardware abstraction layer can be a module that directly interfaces with hardware resources in the electronic device. This module can translate instructions into specific operations that drive the hardware resources. For instance, the hardware abstraction layer can control the flash drive circuitry based on the scheduling requirements of a time queue.

[0092] For example, flash hardware resources can be physical components related to the flash in an electronic device, and driving units can include light-emitting devices, battery management modules, and general-purpose input / output interfaces, etc.

[0093] For example, the lighting effect task queue can be a list of tasks containing lighting effect parameters generated from an event queue. These parameters can include, for example, brightness value, flashing frequency, duration, and color. For instance, the lighting effect task queue could contain "a red breathing light with a flashing frequency of 1 Hz (priority 1)" and "a blue breathing light with a flashing frequency of 3 Hz (priority 3)".

[0094] Optionally, the flash control system can, based on this hardware abstraction layer, obtain an event queue through a preset interface, parse the scene identifier and priority of each element in the event queue, and adjust the allocation of flash hardware resources in real time based on the parsed priorities to generate the lighting effect task queue.

[0095] In some embodiments, the flash control system can maintain a task queue in the service layer, which is ordered according to the scene priority in the event queue. Then, based on the scene identifier in the task queue, the hardware abstraction layer calls preset lighting effect parameters to generate a lighting effect task queue containing lighting effect configuration information. When the flash hardware resources are occupied, unexecuted lighting effect tasks are suspended, and the step of generating the lighting effect task queue continues after the hardware resources are released.

[0096] For example, lighting effect configuration information can be structured data that includes lighting effect parameters and execution control commands. For instance, lighting effect configuration information could include scene identifier, priority, brightness value, color, flashing frequency, duration, and a start command.

[0097] For example, suspension can be a state where the lighting effect task is temporarily not executed due to the occupation of flash hardware resources.

[0098] Optionally, the flash control system can encapsulate each scene event into a task containing scene identifiers, priorities, and other information based on the service layer, and then build and maintain the task queue according to the priority sorting rules of the event queue.

[0099] Optionally, the flash control system can, based on the hardware abstraction layer, obtain a sorted task queue through an interface, extract the scene identifier for each task, and, based on a preset scene identifier-lighting effect parameter mapping table, query and retrieve the corresponding lighting effect parameters to generate a lighting effect task queue containing lighting effect configuration information. For example, the flash control system can preset a fixed lighting effect parameter table, using the scene identifier as the index of this parameter table to store the lighting effect parameters for the corresponding scene. The flash system can, based on the hardware abstraction layer, calculate the index address based on the scene identifier in the task queue and read the corresponding parameter from the parameter table.

[0100] Optionally, the flash control system combines the called lighting effect parameters with the priority and execution instructions of the corresponding tasks based on the hardware abstraction layer, encapsulates them into lighting effect configuration information, and then links the encapsulated lighting effect configuration information into a linked list in descending order of priority, forming an executable lighting effect task queue.

[0101] Optionally, the flash control system can detect the occupancy status of flash hardware resources in real time based on the hardware abstraction layer and set a resource occupancy flag. For example, when the flash hardware resource is occupied, the resource occupancy flag is set to 1; when the flash hardware resource is idle, the resource occupancy flag is set to 0. If the resource flag is detected to be 1, it indicates that the flash hardware resource is occupied by the current task. The system will then mark the unexecuted lighting effect task as a suspended task in the task queue and write the lighting effect configuration information, priority, and expected execution order of the unexecuted lighting effect task into the buffer. After the current task is completed, the flash control system can clear the resource occupancy flag, read the suspended unexecuted lighting effect tasks from the buffer, add them back to the lighting effect task queue according to priority, and resume execution.

[0102] By maintaining a task queue in the service layer using the above method, and sorting the task queue according to the scene priority in the event queue, it is ensured that lighting effect tasks for high-priority scenes are executed first. Based on the scene identifier in the task queue, the hardware abstraction layer calls preset lighting effect parameters to generate a lighting effect task queue containing lighting effect configuration information. When the flash hardware resource is occupied, unexecuted lighting effect tasks are suspended. Once the hardware resource is released, the step of generating the lighting effect task queue continues, which avoids anomalies caused by flash hardware resource contention, thereby improving the stability of flash control.

[0103] S204, control the flash to execute the corresponding lighting effect according to the lighting effect task queue.

[0104] For example, a lighting effect can be the flash output state that matches the configuration information of each lighting effect in the lighting effect task queue.

[0105] Optionally, the flash control system can traverse the lighting effect task queue using a pointer, read the lighting effect tasks in the queue sequentially, extract the lighting effect configuration information for each task, and parse it. The flash control system can also convert the parsed lighting effect configuration information into drive signals recognizable by the flash hardware, and output them to the flash drive circuit through a hardware interface to drive the flash to execute the corresponding lighting effect.

[0106] In this embodiment, multi-scenario event data is collected through the service layer. This multi-scenario event data includes at least the following alert-triggered data: incoming call alerts, charging alerts, low battery alerts, and lock screen notification alerts. Each scenario event data contains structured feature information, including event type, time dimension features, and user historical behavior features, laying the foundation for subsequent priority determination. The structured feature information from the multi-scenario event data is input into the priority determination model. The attention mechanism of the priority determination model performs weighted fusion of the event type, time dimension features, and user historical behavior features to determine the priority of the scenario event data, generating an event queue containing scene identifiers and priorities, laying the foundation for subsequent flash execution control. Based on the scene identifiers and priorities in the event queue, the flash hardware resources are dynamically allocated through the hardware abstraction layer, generating a lighting effect task queue to dynamically adjust the execution order of lighting effects and avoid resource contention caused by multi-scenario conflicts. The flash is controlled to execute the corresponding lighting effects according to the lighting effect task queue, thereby improving flash resource scheduling through the priority determination model. By combining "dynamic priority determination model", "binding lighting effects with priority" and "queue technology" into a complete technical solution, we can achieve flexible priority adjustment and accurate matching of personalized scenarios.

[0107] The following section provides a detailed explanation of how the flash control system generates a queue of lighting effect tasks containing lighting effect configuration information.

[0108] In some embodiments, the flash control system can invoke preset lighting effect parameters through the hardware abstraction layer based on the scene identifier. These lighting effect parameters include brightness, flashing frequency, and color corresponding to different scenes. Then, a lighting effect task queue is generated based on the preset lighting effect parameters. The lighting effect parameters include at least one of the following: a target breathing light corresponding to an incoming call scene, a target red flashing light corresponding to a low battery scene, and a multi-color flashing light corresponding to a lock screen notification scene; the target breathing light is a breathing light with a brightness greater than a first preset brightness threshold, and the target red flashing light is a red flashing light with a flashing frequency greater than a first preset frequency threshold.

[0109] Optionally, the first preset brightness threshold and the first preset frequency threshold can be threshold values ​​preset based on historical experience. For example, the flash control system can determine the first preset brightness threshold based on historical data of the light effect recognition under different lighting environments in incoming call scenarios, as well as user feedback results. The flash control system can determine the first preset frequency threshold based on test experience of visual warning effects at different battery levels in low-battery scenarios, as well as user charging behavior response data.

[0110] Optionally, the flash control system can obtain scene identifiers based on this hardware abstraction layer. Based on these scene identifiers, it calls a preset mapping table of scene identifiers and lighting effect parameters to determine the corresponding lighting effect parameters. It then reads lighting effect parameters including brightness, flashing frequency, and color for different scenes. The lighting effect parameters, scene priorities, and execution instructions are encapsulated into structured tasks, arranged in descending order of priority to form an ordered lighting effect task queue. For example, the flash control system can generate a lighting effect task queue based on at least one equivalent parameter, such as a target breathing light for an incoming call scene, a target red flashing light for a low battery scene, or a multi-color flashing light for a lock screen notification scene.

[0111] Optionally, the flash control system can also obtain scene identifiers based on the hardware abstraction layer, construct prompt words based on the scene identifiers, and input the prompt words into a preset model to obtain the lighting effect parameters corresponding to the scene identifiers. These prompt words can be used to determine the corresponding preset lighting effect parameters based on different scene identifiers. It should be understood that this application does not limit the implementation method of training the preset model; any existing model training process that determines the preset lighting effect parameters based on scene identifiers can be referenced, and will not be elaborated further here.

[0112] Using the method described above, based on the scene identifier, preset lighting effect parameters can be invoked through the hardware abstraction layer. These parameters include brightness, flashing frequency, and color corresponding to different scenes. A lighting effect task queue can be generated based on these preset parameters. These parameters include at least one of the following: a high-brightness breathing light for incoming call scenes, a high-frequency red flashing light for low battery scenes, and a multi-color flashing light for lock screen notification scenes. This allows for dynamic adjustment of the flash's state by using different preset lighting effect parameters for different scenes, thereby improving the flash's utilization rate in various scenarios.

[0113] As one possible implementation, the flash control system can also call ambient light sensor data in the service layer to dynamically adjust the brightness and flash frequency in the lighting effect parameters according to the ambient light intensity. The dynamic adjustment of the brightness and flash frequency in the lighting effect parameters according to the ambient light intensity specifically includes at least one of the following: increasing the brightness and flash frequency in a strong light environment, and decreasing the brightness and extending the flash interval in a weak light environment. The ambient light intensity value of the strong light environment is greater than that of the weak light environment, and the ambient light intensity ranges corresponding to the strong light environment and the weak light environment are preset.

[0114] For example, ambient light sensor data can be data collected by an ambient light sensor installed inside the electronic device within the flash control system. For instance, ambient light sensor data may include ambient light intensity, acquisition timestamps, and other data.

[0115] For example, ambient light intensity can be a physical quantity used to characterize the intensity of light in the surrounding environment. For instance, a higher ambient light intensity value indicates a brighter environment, while a lower ambient light intensity value indicates a darker environment.

[0116] Optionally, the ambient light intensity value in a strong light environment is greater than that in a weak light environment. The ambient light intensity ranges corresponding to both strong and weak light environments are preset.

[0117] For example, a strong light environment can be a scene where the ambient light intensity is in a preset high ambient light intensity range, such as an outdoor scene at noon.

[0118] Optionally, the flash control system can also determine whether it is a strong light environment based on a preset strong light threshold. For example, the preset strong light threshold could be 500 lux; when the ambient light intensity is greater than 500 lux, it is determined to be a strong light environment.

[0119] For example, a low-light environment can be a scene where the ambient light intensity is in a preset low ambient light intensity range. For instance, a low-light environment can be an indoor scene at night, or a dimly lit corridor.

[0120] Optionally, the flash control system can also determine whether it is a low-light environment based on a preset low-light threshold. For example, the preset low-light threshold could be 100 lux; when the ambient light intensity is less than 100 lux, it is determined to be a low-light environment.

[0121] Optionally, the flash control system can generate a lighting effect task queue based on this service layer, or trigger the collection of data from the ambient light sensor when updating lighting effect parameters. For example, before each generation of the lighting effect task queue, the service layer can obtain ambient light sensor data in real time through an interface. The flash control system can also collect ambient light sensor data at fixed intervals based on the ambient light sensor and store it in a buffer.

[0122] Optionally, the flash control system can first preset a mapping rule table for ambient light range, brightness, and flash frequency. Based on the collected ambient light intensity, it queries the mapping rule table for the ambient light range, brightness, and flash frequency to determine the brightness and flash frequency in the lighting effect parameters corresponding to the ambient light intensity, and adjusts them according to the brightness and flash frequency.

[0123] Optionally, the flash control system can also obtain user-defined strong light threshold, weak light threshold, and brightness and flicker frequency in the lighting effect parameters corresponding to ambient light intensity based on the application layer.

[0124] Optionally, the flash control system can increase brightness and flash frequency in bright light environments, and can also reduce brightness and extend flash intervals in low light environments.

[0125] By using the above method, ambient light sensor data can be invoked in the service layer to dynamically adjust the brightness and flashing frequency of the lighting effect parameters based on the ambient light intensity. Specifically, this dynamic adjustment of brightness and flashing frequency based on ambient light intensity includes at least one of the following: increasing brightness and flashing frequency in strong light environments, and decreasing brightness and extending the flashing interval in weak light environments. The ambient light intensity value in the strong light environment is greater than that in the weak light environment, and the corresponding ambient light intensity ranges for both environments are preset. Using ambient light sensor data improves the reliability of flash control under different ambient light intensities.

[0126] As one possible implementation, the flash control system can also dynamically adjust the priority rules of each scene in the generated event queue based on the output of the user behavior analysis module; wherein, the service layer is equipped with the user behavior analysis module, which is used to record the user's response behavior to scene events through system logs.

[0127] For example, the user analysis module could be responsible for collecting, analyzing, and recording user response data to scene events through system logs.

[0128] For example, system logs can be structured data that records user actions and scene events. For instance, system logs may include scene identifiers, corresponding behaviors, and timestamps.

[0129] Optionally, the flash control system can record the scene identifier and timestamp through the user behavior analysis module after a scene event is triggered, and at the same time obtain user operations, and record the user's corresponding behavior type and response time for the scene event in the system log.

[0130] Optionally, the flash control system can periodically analyze the system logs based on the user analysis module. It can also preset thresholds for scene events. When the number of occurrences of a scene event reaches the threshold, the user behavior analysis module is triggered to analyze the system logs. For example, after the low battery scene is triggered 10 times, the user behavior analysis module analyzes and records the system logs of the user's response behavior.

[0131] Optionally, the flash control system can input historical system logs into the user behavior analysis module. This module identifies priority rules for each scenario and adjusts priorities accordingly. The user behavior analysis module can include a data preprocessing layer, a feature extraction layer, and a rule generation layer. For example, it can also be any pre-trained deep learning or machine learning model with priority recognition capabilities.

[0132] Optionally, the flash control system can remove outliers and missing values ​​from historical system logs through the data preprocessing layer of the user behavior analysis module, normalize them, and convert discrete event types into numerical labels to generate a log sample set.

[0133] Optionally, the flash control system can use the convolutional neural network in the feature extraction layer of the user behavior analysis module to extract local features from the time series features in the above log sample set and output a local feature vector; use the memory network to extract the temporal correlation of continuous user behavior features and output a temporal feature vector; and concatenate the local feature vector and the temporal feature vector to output a global feature representation.

[0134] Optionally, the flash control system can input the aforementioned global feature representation into the rule generation layer of the user behavior analysis module. Combined with basic priority rules, it can statistically analyze user response rates, average response times, and resource conflict rates for various scenario events in the log sample set. Based on the logic that higher user response rates, shorter average response times, and lower resource conflict rates correspond to higher priority, the priority rules are adjusted. The flash control system can also store the generated priority rules in the system rule base as key-value pairs.

[0135] Optionally, the flash control system can also analyze the user's response to scene events based on the user behavior analysis module, determine the priority rules for each scene, store the priority rules in a configuration file, and dynamically adjust the priority of each scene in the generated event queue by reading the configuration file.

[0136] Using the above method, the priority rules for each scenario in the generated event queue can be dynamically adjusted based on the output of the user behavior analysis module, improving the response efficiency of different scenario events and thus enhancing the resource scheduling of the flashlight. Specifically, the service layer includes this user behavior analysis module, which records user response behaviors to scenario events through system logs.

[0137] The following is a detailed explanation of how the flash control system controls the flash to execute the corresponding lighting effect based on the lighting effect task queue.

[0138] In some embodiments, when there is a currently executing lighting effect task in the lighting effect task queue, the flash is controlled to execute the lighting effect corresponding to the current lighting effect task. If a new first lighting effect task is received during the execution of the current lighting effect task, and the priority of the new first lighting effect task is higher than that of the current lighting effect task, the current lighting effect task is paused and its execution progress information is saved. Then, the new first lighting effect task is added to the lighting effect task queue and executed with priority, and the flash is controlled to execute the lighting effect corresponding to the new first lighting effect task.

[0139] Once the new high-priority lighting effect task is completed, the flash is controlled to resume the lighting effect corresponding to the currently paused task, based on the saved execution progress information. If a new second lighting effect task is received during the execution of the current task, and the priority of the new second task is lower than or equal to the priority of the current task, the new second task is added to the end of the lighting effect task queue. Then, once the current task is completed, the flash is controlled to execute the lighting effect corresponding to the new second task.

[0140] For example, the current lighting effect task can be a lighting effect task that occupies flash hardware resources in the lighting effect task queue.

[0141] For example, the first lighting effect task can be a task with a higher priority than the current lighting effect task.

[0142] For example, the second lighting effect task can be a task with a lower priority than the current lighting effect task.

[0143] For example, the execution progress information could be the recorded execution status data when the lighting effect task is paused. For instance, the execution progress information could include the execution duration, lighting effect parameters, and remaining execution time.

[0144] For example, taking the currently executing lighting effect task as a low battery reminder task, the first lighting effect task as an incoming call reminder task, and the second lighting effect task as a lock screen notification reminder task, the flash control system can set the priority of the low battery reminder task to level 2, with lighting effect parameters of "red 10Hz high-frequency flashing, brightness 100%, duration 20 seconds," the purpose of which is to remind the user to charge the phone in time. The flash control system can set the priority of the incoming call reminder task to level 1, with lighting effect parameters of "green 5Hz breathing light, brightness 90%, duration 30 seconds," the purpose of which is to remind the user to answer the incoming call. The flash control system can also set the priority of the lock screen notification reminder task to level 3, with lighting effect parameters of "yellow-blue alternating flashing at 1Hz, brightness 60%, duration 15 seconds," the purpose of which is to remind the user of a new lock screen notification.

[0145] Optionally, when the flash control system detects that the battery level is below 20%, it triggers a low battery reminder event, generates a low battery reminder task through the service layer, and drives the flash to perform a "red 10Hz high-frequency flashing, 100% brightness, lasting for 20 seconds" light effect through the hardware abstraction layer. At the same time, the flash control system records the execution progress of the low battery reminder task in real time.

[0146] Optionally, when the low battery reminder task reaches the 5th second, a user receives an incoming call. The flash control system triggers the incoming call reminder scene event, generating the first lighting effect task. The flash control system immediately performs a "pause current task" operation, stopping the high-frequency red flashing output of the flash, while saving the execution progress information of the low battery reminder task. For example, the execution progress information of the low battery reminder task could be: 5 seconds of execution time, 15 seconds remaining, current lighting effect parameters, and the hardware state at the time of pause.

[0147] Optionally, the flash control system inserts the incoming call reminder task at the head of the lighting effect task queue, and drives the flash to switch to a "green 5Hz breathing light" through the hardware abstraction layer, at which point the incoming call reminder task begins execution. While the incoming call reminder task is being executed, the flash operates as a breathing light until the user answers the call, or, if more than 30 seconds have passed, the incoming call reminder task is completed.

[0148] Optionally, when the incoming call reminder task ends, the flash control system reads the execution progress information of the low battery reminder task from the cache, and based on the execution progress information of the low battery reminder task, drives the flash to resume "red 10 Hz high frequency flashing" and continues execution from the pause point of the 5th second.

[0149] Optionally, if the user receives a lock screen notification when the low battery reminder task resumes execution for 10 seconds, the flash control system triggers the lock screen notification reminder scene event, generates a second lighting effect task, and continues to execute the current low battery reminder task, adding the lock screen notification reminder task to the end of the lighting effect task queue for execution.

[0150] Optionally, when the low battery reminder task is completed, the flash control system detects that there is a lock screen notification reminder task to be executed in the lighting effect task queue, takes it as the current task, and drives the flash to execute the "yellow-blue two-color 1Hz alternating flashing" lighting effect through the hardware abstraction layer until the lock screen notification reminder task is completed.

[0151] Using the above method, based on the priority of the current lighting effect task, the first equivalent task, and the second equivalent task, the flash control system prioritizes the execution of high-priority lighting effect tasks, resolves conflicts in multiple scenarios, ensures that high-priority lighting effect tasks are not interfered with, thereby improving the utilization rate of the flash and enhancing the user experience.

[0152] Figure 4 This is a schematic diagram of the architecture of a flash control system provided in an embodiment of this application, as shown below. Figure 4 As shown, the flash control system includes a kernel layer, a hardware abstraction layer (HAL), a lighting effect scheduling service layer, a component control lighting effect layer, and a core service layer. The core service layer includes telephone service, battery service, notification service, and settings.

[0153] For example, a four-layer architecture of "kernel layer - HAL layer - service layer - application layer" is adopted to achieve multi-module collaboration and precise control of lighting effects.

[0154] Optional, kernel layer: provides flash hardware driver interface, including flash "on / off" control node, brightness adjustment node and breathing light mode control node, supporting low-level control of light effect parameters (brightness, flash frequency, mode).

[0155] HAL layer: Encapsulates the hardware driver interface, provides a standardized application programming interface (API) for flash control, shields the differences in underlying hardware, provides a unified calling interface for upper-layer services, and ensures the compatibility and stability of lighting control commands.

[0156] Service layer:

[0157] Core services include call service (monitoring incoming call status), battery service (obtaining battery level and charging status), notification service (obtaining lock screen notification information), and camera service (determining whether the flash is being used by the camera), and real-time collection of events triggered in various scenarios.

[0158] Scheduling Service: A new "Ring Flash Lighting Effect Scheduling Service (ITranLedLight)" has been added, which is responsible for receiving event data from various core services, performing scene priority judgment, light effect task queue management, and conflict handling logic.

[0159] Application layer: Provides user interaction entry points (such as the "ring flash function switch" in the settings panel), supports users to turn the ring flash function on / off, and preview the lighting effect modes of different scenarios.

[0160] Optionally, priorities can be set based on the user's focus on different scenarios: incoming call reminders have priority 1, low battery reminders have priority 2, screen-off notifications have priority 3, charging has priority 4, and settings panel preview lighting effects have priority 5. When multiple scenarios are triggered simultaneously, high-priority scenarios will preempt flash resources, while low-priority scenarios will enter the task queue and be executed after the high-priority scenarios have finished.

[0161] Optionally, the lighting effect parameters for each scene can be designed, including:

[0162] Incoming call scenario: Invoke the flash "breathing light mode" with the following parameters: "brightness 255 (brightest) - decrease time 2000 milliseconds - brightness 0 (off) - off time 500 milliseconds - brightness increase time 500 milliseconds - brightness 255 - brightest time 1000 milliseconds", and execute in a loop; if the user rejects or answers the call, immediately send a "turn off flash" command.

[0163] Charging scenario: The green breathing light is activated, and the brightness is adjusted according to the charging progress (e.g., 0-30% charging: brightness 100; 31-70% charging: brightness 180; 71-100% charging: brightness 255). The flashing frequency is "on for 2 seconds / off for 1 second". If the camera is using the flash (the status is obtained through the camera service), the charging light effect is paused and will resume after the camera releases resources.

[0164] Low battery reminder scenario (battery ≤ 10%): Activate the red breathing light with a brightness of 255 and a flashing frequency of "on for 1 second / off for 0.5 seconds". At the same time, trigger the light effect task to cycle 3 times (to avoid continuous flashing and power consumption). After the cycle ends, the light effect will automatically turn off.

[0165] Lock screen notification scenarios: Differentiate lighting effects based on notification type (e.g., social software notifications: blue breathing light, flashing frequency "on for 1.5 seconds / off for 1 second"; SMS notifications: yellow breathing light, flashing frequency "on for 1 second / off for 0.8 seconds"). If a notification lighting effect is already in effect, the current lighting effect will be terminated when a new notification is triggered, and the new notification lighting effect will be executed first (based on notification time, with the latest notification taking priority).

[0166] Preview lighting effects in the settings panel: When the user clicks the preview button, the lighting effect of the corresponding scene is triggered (e.g., if previewing the incoming call lighting effect, the incoming call scene parameters are executed). The preview duration is fixed at 5 seconds, and the lighting effect will automatically turn off after the timeout.

[0167] Optionally, based on hardware occupancy conflict handling, the camera service monitors the flash occupancy status in real time. If the flash is being used by the camera when a scene is triggered (e.g., the user is taking a picture and turning on the fill light), the scene lighting effect is added to the "waiting queue". The system broadcasts the event of the camera service releasing the flash, and the lighting effect task in the queue is executed immediately after the flash is released.

[0168] Optionally, the flash control system can be designed with the following power optimization strategy:

[0169] (1) Default function off: When the user turns on the device for the first time, the ring flash function is off by default. The user needs to manually turn it on in the settings to avoid unnecessary power consumption in the background.

[0170] (2) Lighting effect parameter restrictions: The flashing frequency of the lighting effect in all scenes shall not be less than “0.5 seconds on / 0.5 seconds off” (to avoid high-frequency flashing and power consumption), the duration of the lighting effect in a single scene shall not exceed 30 seconds (such as the low battery reminder will automatically stop after 3 cycles), and the maximum brightness shall not exceed 255 (to avoid excessive power consumption).

[0171] (3) Screen off power consumption control: In the screen off state, only the lighting effects of incoming call, low battery reminder and lock screen notification scenarios are triggered. The charging scenario lighting effect maintains low brightness (such as brightness 100) when the screen is off, and automatically turns off the charging lighting effect when the screen is on (to avoid redundant lighting effects when the screen is on).

[0172] For example, a flash control system can set up a lighting effect task data structure and manage tasks.

[0173] Optionally, the flash control system sets a unique scene identifier for different scenarios to identify the scene type corresponding to the current lighting effect task. This identifier is linked to specific scenarios through preset numerical codes (e.g., 1 = incoming call, 2 = charging, 3 = low battery, etc.). The flash control system can then match the preset lighting effect logic for the corresponding scene based on this value.

[0174] Optionally, the flash control system can identify individual tasks in the lighting effect task queue to ensure that tasks are not duplicated and can be distinguished in the queue.

[0175] Optionally, the flash control system can be configured to control the number of times the lighting effect task is repeated. For example, if the low battery reminder needs to flash 3 times in a loop, the task will repeat 3 times according to the rule and then end.

[0176] Optionally, the flash control system can record the timestamp (in milliseconds) at which the current task is added to the lighting effect task queue. The flash control system can use this value to determine whether a task has timed out (e.g., it has not been executed after a preset time) and automatically clean up timed-out tasks to avoid the accumulation of invalid tasks in the queue.

[0177] Optionally, the flash control system can mark whether a task is a cyclic type. For example, 1 indicates a cyclic task (such as a low battery alert flashing continuously), and 0 indicates a non-cyclic task (such as a single notification flash). The flash control system can determine the task execution logic (repeatedly or executed once and then terminated) based on this marking.

[0178] Optionally, the flash control system can define the interval time (in milliseconds) between "different stages" in a cyclic task, typically used to control the "on / off switching cycle" of the lighting effect.

[0179] Optionally, the flash control system can specify the flash hardware resources that need to be driven for the current lighting effect task. For example, specific flashes can be associated with digital codes (e.g., 1 = main flash, 2 = green LED, etc.), and multi-flash collaboration can also be supported (e.g., {1,3} indicates simultaneous control of the main flash and the red LED).

[0180] Optionally, the flash control system can store the core configuration parameters of the lighting effect, defining the dynamic change rules of "brightness-duration" in the form of a two-dimensional array. For example, {{80,1000},{0,500}} means "brightness 80% for 1000 milliseconds, off (brightness 0) for 500 milliseconds".

[0181] Optionally, the flash control system can also associate the task's identifier with the identifier of the previous notification task to terminate the previous task.

[0182] Optionally, the flash control system can manage the task queue. The ring flash effect scheduling service maintains a "flash effect task queue" that follows a "first-in, first-out" principle, while adjusting the queue order based on scene priority (high-priority tasks are inserted at the head of the queue). Before a task is executed, the flash status is checked; if the hardware is idle, it is executed immediately; otherwise, it waits. After a task is completed, it is automatically removed from the queue, and the next task is triggered.

[0183] For example, in cases where camera flash control has a higher priority than incoming call alerts, Figure 5This is a flowchart illustrating a flash control method for an incoming call scenario provided in an embodiment of this application, as shown below. Figure 5 As shown, the method includes:

[0184] (1) Registered caller ID monitoring and detected caller ID;

[0185] (2) Determine if the incoming call lighting effect is turned on:

[0186] If the incoming call lighting effect is not enabled, the lighting effect will be ignored and the process will end.

[0187] If the incoming call lighting effect setting is turned on, go to (3).

[0188] (3) Determine if the camera is in use:

[0189] If the camera is in use, the priority of the camera control flash is higher than the priority of the incoming call reminder. The incoming call reminder light effect task is added to the light effect task queue and enters (4).

[0190] If you are not using a camera, go to (5).

[0191] (4) Determine if the camera is off:

[0192] If the camera is not turned off, wait to execute the incoming call reminder light effect task and continuously monitor the camera's usage status;

[0193] If the camera is off, proceed to (5).

[0194] (5) Control the flashlight to perform the incoming call reminder lighting effect;

[0195] (6) Determine whether to reject or answer the call:

[0196] If the call is not rejected or answered, the flashlight will continue to display the call reminder effect.

[0197] If the call is rejected or answered, the flashlight will turn off the caller ID effect.

[0198] For example, in the case where the camera controls the flash with higher priority than the incoming call reminder and the charging reminder, and the incoming call reminder has higher priority than the charging reminder, Figure 6 This is a flowchart illustrating a flash control method in a charging scenario provided by an embodiment of this application, as shown below. Figure 6 As shown, the method includes:

[0199] (1) The charging indicator is detected through battery service update, triggering the process to start;

[0200] (2) Determine if the charging light effect setting is turned on:

[0201] If the charging lighting effect is not enabled, ignore the lighting effect execution and the process ends.

[0202] If the charging light effect setting is not turned on, go to (3).

[0203] (3) Determine if the camera is in use:

[0204] If the camera is in use, the charging reminder light effect task is added to the light effect task queue and enters (4) because the camera control flash has a higher priority than the charging reminder.

[0205] If you are not using a camera, go to (5).

[0206] (4) Determine if the camera is off:

[0207] If the camera is not turned off, wait to execute the charging reminder light effect task and continuously monitor the camera's usage status;

[0208] If the camera is off, proceed to (5).

[0209] (5) Determine if there is an incoming call:

[0210] If there is an incoming call, and the incoming call reminder light effect setting is turned on, the incoming call reminder light effect task in the light effect task queue is executed first because the priority of the light effect task queue is higher than the charging reminder priority, and then proceeds to (6).

[0211] If there is no incoming call, proceed to (7).

[0212] (6) Determine whether the incoming call reminder light effect task has been completed:

[0213] If the incoming call reminder light effect task has not been completed, continue to execute the incoming call reminder light effect task and continuously monitor the execution status of the incoming call reminder light effect task until the task is completed.

[0214] If the incoming call reminder light effect task has finished, proceed to (7).

[0215] (7) Control the flash to perform the charging reminder lighting effect.

[0216] For example, in the case where the camera controls the flash with higher priority than incoming call alerts, charging alerts, and low battery alerts, and the incoming call alert has higher priority than both charging alerts and low battery alerts, and the charging alert has higher priority than the low battery alert, Figure 7 This is a flowchart illustrating a flash control method for low-battery scenarios provided in an embodiment of this application, as shown below. Figure 7 As shown, the method includes:

[0217] (1) Battery service status update triggers process startup;

[0218] (2) Determine if the low battery lighting effect setting is turned on:

[0219] If the low battery lighting effect setting is not turned on, the lighting effect will be ignored and the process will end.

[0220] If the low battery lighting effect setting is turned on, go to (3).

[0221] (3) Determine if the battery level is below the warning threshold:

[0222] If the battery level is not below the warning threshold, ignore the lighting effect and the process ends.

[0223] If the battery level is below the warning threshold, the flash component is invoked, and (4) is entered.

[0224] (4) Determine if the camera is in use:

[0225] If the camera is in use, since the camera controls the flash with a higher priority than the low battery reminder, the low battery reminder lighting effect task is added to the lighting effect task queue and enters (5).

[0226] If you are not using a camera, go to (6).

[0227] (5) Determine if the camera is off:

[0228] If the camera is not turned off, wait to execute the low battery reminder light effect task and continuously monitor the camera's usage status;

[0229] If the camera is off, proceed to (6).

[0230] (6) Determine if there is an incoming call:

[0231] If there is an incoming call, and the incoming call reminder light effect setting is turned on, the incoming call reminder light effect task in the light effect task queue is executed first because the priority of the light effect task queue is higher than the priority of the low battery reminder. Then proceed to (7).

[0232] If there is no incoming call, proceed to (8).

[0233] (7) Determine whether the incoming call reminder light effect task has been completed:

[0234] If the incoming call reminder light effect task has not been completed, continue to execute the incoming call reminder light effect task and continuously monitor the execution status of the incoming call reminder light effect task until the task is completed.

[0235] If the incoming call reminder light effect task has finished, proceed to (8);

[0236] (8) Determine if it is charging:

[0237] If charging is in progress, and the charging reminder light effect is enabled, the charging reminder light effect task in the light effect task queue will be executed first, based on the fact that the charging reminder has a higher priority than the low battery reminder in the light effect task queue, and then proceed to (9).

[0238] If not charging, proceed to (11).

[0239] (9) Determine if the charging reminder light effect task has ended:

[0240] If the charging reminder light effect task has not been completed, continue to execute the charging reminder light effect task and continuously monitor the execution status of the charging reminder light effect task until the charging reminder light effect task is completed.

[0241] If the charging reminder light effect task is completed, proceed to (10).

[0242] (10) Determine if the battery level is still below the battery warning threshold:

[0243] If the battery level is not lower than the battery warning threshold, the low battery reminder light effect will not be executed.

[0244] If the battery level is still below the low battery warning threshold, proceed to (11).

[0245] (11) Control the flash to perform the low battery reminder lighting effect.

[0246] For example, in the case where the camera control flash has a higher priority than incoming call reminders, charging reminders, and notification reminders, and the incoming call reminder has a higher priority than both charging reminders and notification reminders, and the notification reminder has a higher priority than the charging reminder. Figure 8 This is a flowchart illustrating a flash control method for a lock screen notification scenario provided in an embodiment of this application, as shown below. Figure 8 As shown, the method includes:

[0247] (1) The notification service updates and detects the notification identifier, triggering the process to start;

[0248] (2) Determine if the notification lighting effect is enabled:

[0249] If the lighting effect settings are not enabled, ignore the lighting effect execution and the process ends.

[0250] If the notification lighting effect settings are turned on, call the flash component and enter (3).

[0251] (3) Determine if the camera is in use:

[0252] If the camera is in use, since the camera controls the flash higher than the notification reminder, the notification reminder lighting effect task is added to the lighting effect task queue and enters (4).

[0253] If you are not using a camera, go to (5).

[0254] (4) Determine if the camera is off:

[0255] If the camera is not turned off, wait to execute the notification reminder lighting effect task and continuously monitor the camera usage status;

[0256] If the camera is off, proceed to (5).

[0257] (5) Determine if there is an incoming call:

[0258] If there is an incoming call, and the incoming call reminder light effect setting is turned on, the incoming call reminder priority is higher than the notification reminder priority, so the incoming call reminder light effect task in the light effect task queue is executed first, and then (6) is entered.

[0259] If there is no incoming call, proceed to (7).

[0260] (6) Determine whether the incoming call reminder light effect task has been completed:

[0261] If the incoming call reminder light effect task has not been completed, continue to execute the incoming call reminder light effect task and continuously monitor the execution status of the incoming call reminder light effect task until the task is completed.

[0262] If the incoming call reminder light effect task has finished, proceed to (7).

[0263] (7) Determine if it is charging:

[0264] If charging is in progress, and the charging reminder light effect is enabled, proceed to (8).

[0265] If not charging, proceed to (9).

[0266] (8) If the priority of notification reminder in the lighting effect task queue is higher than that of charging reminder, pause the charging reminder lighting effect task and add the charging reminder lighting effect task to the lighting effect task queue.

[0267] (9) Perform notification and reminder lighting effect tasks;

[0268] (10) Determine whether the notification reminder light effect task has ended:

[0269] If the notification and reminder light effect task has not been completed, continue to execute the notification and reminder light effect task and continuously monitor the execution status of the notification and reminder light effect task until the notification and reminder light effect task is completed.

[0270] If the notification reminder light effect task has finished executing, continue executing the charging reminder light effect task in the light effect task queue.

[0271] Figure 9This is a schematic diagram of the structure of a flash control device provided in an embodiment of this application, as shown below. Figure 9 As shown, the flash control device 900 includes:

[0272] The data collection module 901 is used to collect multi-scenario event data through the service layer. The multi-scenario event data includes at least the following reminder-triggered data: incoming call reminder, charging reminder, low battery reminder, and lock screen notification reminder. Each event data in this scenario contains structured feature information, which includes event type, time dimension features, and user historical behavior features.

[0273] The first generation module 902 is used to input the structured feature information in the multi-scene event data into the priority determination model, and use the attention mechanism of the priority determination model to perform weighted fusion of the event type, the time dimension feature and the user's historical behavior feature to determine the priority of the scene event data, and generate an event queue containing scene identifiers and priorities.

[0274] The second generation module 903 is used to dynamically allocate the flash hardware resources through the hardware abstraction layer based on the scene identifier and priority in the event queue, and generate a lighting effect task queue.

[0275] The control module 904 is used to control the flash to execute the corresponding lighting effect according to the lighting effect task queue.

[0276] Optionally, the first generation module 902 is further configured to dynamically adjust the priority rules of each scenario in the generated event queue based on the output of the user behavior analysis module; wherein the service layer is equipped with the user behavior analysis module, which is used to record the user's response behavior to scenario events through system logs.

[0277] Optionally, the first generation module 902 is further configured to include an embedding layer, a multi-head attention layer, a feature fusion layer, and a priority output layer in the priority determination model; wherein: the embedding layer is used to convert the structured feature information of the scene event data into a low-dimensional dense feature vector; the multi-head attention layer is used to extract multi-dimensional related features of the event type, the time dimension feature, and the user's historical behavior feature, and output the attention weights of each feature; the feature fusion layer is used to weightedly fuse the attention weights with the feature vector to generate a fused feature representation; the priority output layer is used to determine the priority of the fused feature representation in combination with basic priority rules; wherein the basic priority rules include: incoming call reminders have a higher priority than low battery reminders, low battery reminders have a higher priority than lock screen notification reminders, and lock screen notification reminders have a higher priority than charging reminders.

[0278] Optionally, the second generation module 903 is also used to maintain a task queue in the service layer, the task queue being sorted according to the scene priority in the event queue; based on the scene identifier in the task queue, the hardware abstraction layer calls preset lighting effect parameters to generate a lighting effect task queue containing lighting effect configuration information; when the flash hardware resource is occupied, the unexecuted lighting effect task is suspended, and the step of generating the lighting effect task queue continues after the hardware resource is released.

[0279] Optionally, the second generation module 903 is further configured to call preset lighting effect parameters through the hardware abstraction layer according to the scene identifier. The lighting effect parameters include the brightness, flashing frequency and color corresponding to different scenes.

[0280] The lighting effect task queue is generated based on the preset lighting effect parameters;

[0281] The lighting effect parameters include at least one of the following:

[0282] The target breathing light corresponds to the incoming call scenario, the target red flashing light corresponds to the low battery scenario, and the multi-color flashing light corresponds to the lock screen notification scenario; the target breathing light is a breathing light with a brightness greater than a first preset brightness threshold, and the target red flashing light is a red flashing light with a flashing frequency greater than a first preset frequency threshold.

[0283] Optionally, the second generation module 903 is further configured to call ambient light sensor data in the service layer and dynamically adjust the brightness and flicker frequency in the lighting effect parameters according to the ambient light intensity; the dynamic adjustment of the brightness and flicker frequency in the lighting effect parameters according to the ambient light intensity specifically includes at least one of the following: increasing the brightness and flicker frequency in a strong light environment, and decreasing the brightness and extending the flicker interval in a weak light environment; wherein, the ambient light intensity value of the strong light environment is greater than the ambient light intensity value of the weak light environment, and the ambient light intensity ranges corresponding to the strong light environment and the weak light environment are preset.

[0284] Optionally, the control module 904 is also used to control the flash to execute the lighting effect corresponding to the current lighting effect task when there is a currently executing lighting effect task in the lighting effect task queue;

[0285] If a new first lighting effect task is received during the execution of the current lighting effect task, and the priority of the new first lighting effect task is higher than that of the current lighting effect task, then the current lighting effect task is paused and its execution progress information is saved.

[0286] Add the new first lighting effect task to the lighting effect task queue and execute it with priority, and control the flash to execute the lighting effect corresponding to the new first lighting effect task;

[0287] Once the new high-priority lighting effect task is completed, the lighting effect corresponding to the currently paused lighting effect task will be restored based on the saved execution progress information.

[0288] If a new second lighting effect task is received during the execution of the current lighting effect task, and the priority of the new second lighting effect task is lower than or equal to the priority of the current lighting effect task, then the new second lighting effect task is added to the tail of the lighting effect task queue.

[0289] Once the current lighting effect task is completed, control the flash to execute the lighting effect corresponding to the new second lighting effect task.

[0290] The flash control device provided in this application can be used to execute the technical solutions of any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be described again here.

[0291] Figure 10 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 10 As shown, the electronic device 1000 provided in this embodiment includes at least one processor 1001 and a memory 1002. Optionally, the device 1000 further includes a communication component 1003. The processor 1001, memory 1002, and communication component 1003 are connected via a bus 1004.

[0292] In a specific implementation, at least one processor 1001 executes computer execution instructions stored in memory 1002, causing at least one processor 1001 to perform the above-described method.

[0293] Optionally, the memory 1002 can be either standalone or integrated with the processor 1001.

[0294] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0295] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method of any of the foregoing embodiments.

[0296] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method of any of the foregoing embodiments.

[0297] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0298] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0299] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU) or other general-purpose processors. The processor can also be a Digital Signal Processor (DSP) or an Application Specific Integrated Circuit (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0300] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be various media that can store program code, such as USB flash drives, portable hard drives, read-only memory (ROM), disks or optical discs.

[0301] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof. Examples of storage media include Static Random-Access Memory (SRAM) or Electrically Erasable Programmable Read Only Memory (EEPROM).

[0302] Storage media can be, for example, erasable programmable read-only memory (EPROM) or programmable read-only memory (PROM). Storage media can also be read-only memory (ROM), magnetic storage, flash memory, magnetic disks, or optical disks. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0303] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside within an application-specific integrated circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components within an electronic device or host device.

[0304] 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. Unless otherwise specified, 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.

[0305] The sequence numbers of the embodiments in this application are merely for description and do not represent the superiority or inferiority of the embodiments. 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.

[0306] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a 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 device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0307] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0308] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0309] It should be further noted that although the steps in the flowchart are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order requirement for the execution of these steps, and they can be executed in other orders.

[0310] Furthermore, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0311] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0312] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0313] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A flash control method, characterized in that, The method is applied to an electronic device, which has a layered architecture including a hardware abstraction layer, a service layer, and an application layer. The hardware abstraction layer controls flash hardware resources, the service layer monitors multiple scene events and generates scene event data, and the application layer provides a user interaction interface. A pre-trained priority determination model is deployed in the service layer to determine the priority of scene event data. The method includes: The service layer collects multi-scenario event data, which includes at least the following alerts: incoming call alerts, charging alerts, low battery alerts, and lock screen notifications. Each scenario event data item contains structured feature information, including event type, time dimension features, and user historical behavior features. The time dimension features include time period, date, and event trigger point. The user historical behavior features include the user's average response time to various alerts and their preference settings. The structured feature information from the multi-scenario event data is input into the priority determination model. The attention mechanism of the priority determination model is used to perform weighted fusion of the event type, the time dimension feature, and the user's historical behavior feature to determine the priority of the scenario event data, generating an event queue containing scenario identifiers and priorities. The event queue adopts a doubly linked list data structure, in which each node stores the scenario identifier, the priority, and the trigger timestamp, and the insertion position of the node is determined according to the descending priority. Based on the scene identifier and priority in the event queue, the flash hardware resources are dynamically allocated through the hardware abstraction layer. The called lighting effect parameters are combined with the priority and execution instructions of the corresponding tasks and encapsulated into lighting effect configuration information. The lighting effect configuration information is then linked into a linked list in descending order of priority to generate a lighting effect task queue. The flashlight is controlled to perform the corresponding lighting effect according to the lighting effect task queue.

2. The method according to claim 1, characterized in that, The priority determination model includes an embedding layer, a multi-head attention layer, a feature fusion layer, and a priority output layer; Wherein: the embedding layer is used to convert the structured feature information of the scene event data into a low-dimensional dense feature vector; the multi-head attention layer is used to extract multi-dimensional related features of the event type, the time dimension feature, and the user historical behavior feature, and output the attention weight of each feature; the feature fusion layer is used to weightedly fuse the attention weight and the feature vector to generate a fused feature representation; the priority output layer is used to determine the priority of the fused feature representation in combination with basic priority rules; The basic priority rules include: incoming call reminders have a higher priority than low battery reminders, low battery reminders have a higher priority than lock screen notifications, and lock screen notifications have a higher priority than charging reminders.

3. The method according to claim 1 or 2, characterized in that, The dynamic allocation of flash hardware resources through the hardware abstraction layer includes: A task queue is maintained in the service layer, and the task queue is sorted according to the scenario priority in the event queue. Based on the scene identifier in the task queue, the hardware abstraction layer calls the preset lighting effect parameters to generate a lighting effect task queue containing lighting effect configuration information. The method further includes: When the flash hardware resources are occupied, the unexecuted lighting effect tasks will be suspended, and the step of generating the lighting effect task queue will continue after the hardware resources are released.

4. The method according to claim 3, characterized in that, The generation of the lighting effect task queue containing lighting effect configuration information includes: Based on the scene identifier, preset lighting effect parameters are called through the hardware abstraction layer. The lighting effect parameters include brightness, flashing frequency and color corresponding to different scenes. The lighting effect task queue is generated based on the preset lighting effect parameters; The lighting effect parameters include at least one of the following: The target breathing light corresponds to the incoming call scenario, the target red flashing light corresponds to the low battery scenario, and the multi-color flashing light corresponds to the lock screen notification scenario; the target breathing light is a breathing light with a brightness greater than a first preset brightness threshold, and the target red flashing light is a red flashing light with a flashing frequency greater than a first preset frequency threshold.

5. The method according to claim 4, characterized in that, The method further includes: In the service layer, ambient light sensor data is invoked to dynamically adjust the brightness and flicker frequency of the lighting effect parameters based on the ambient light intensity. Specifically, the dynamic adjustment of the brightness and flicker frequency of the lighting effect parameters based on the ambient light intensity includes at least one of the following: increasing the brightness and flicker frequency in a strong light environment, and decreasing the brightness and extending the flicker interval in a weak light environment. The ambient light intensity value of the strong light environment is greater than that of the weak light environment, and the ambient light intensity ranges corresponding to the strong light environment and the weak light environment are preset.

6. The method according to claim 4, characterized in that, The method further includes: Based on the output of the user behavior analysis module, the priority rules of each scenario in the event queue are dynamically adjusted; wherein, the service layer is equipped with the user behavior analysis module, which is used to record the user's response behavior to scenario events through system logs.

7. The method according to claim 1 or 2, characterized in that, The step of controlling the flash to execute the corresponding lighting effect according to the lighting effect task queue includes: When there is a currently executing lighting effect task in the lighting effect task queue, control the flash to execute the lighting effect corresponding to the current lighting effect task; If a new first lighting effect task is received during the execution of the current lighting effect task, and the priority of the new first lighting effect task is higher than the priority of the current lighting effect task, then the current lighting effect task is paused and its execution progress information is saved. Add the new first lighting effect task to the lighting effect task queue and execute it with priority, and control the flash to execute the lighting effect corresponding to the new first lighting effect task; Once a new high-priority lighting effect task is completed, the control of the flashlight to execute the lighting effect corresponding to the currently paused lighting effect task is restored based on the saved execution progress information. If a new second lighting effect task is received during the execution of the current lighting effect task, and the priority of the new second lighting effect task is lower than or equal to the priority of the current lighting effect task, then the new second lighting effect task is added to the tail of the lighting effect task queue. Once the current lighting effect task is completed, control the flash to execute the lighting effect corresponding to the new second lighting effect task.

8. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images