An event processing method, electronic device, storage medium and program product

Abstract

An event processing method, an electronic device, a storage medium and a program product can avoid application lag as much as possible and improve user experience. For example, the electronic device includes a first application, an event queue of the first application includes a first queue and a second queue, the first queue and the second queue are respectively used to store events to be processed of the first application, and a priority of the first queue is higher than a priority of the second queue. The electronic device processes a first event in the second queue. In the process of processing the first event, the electronic device detects whether there is a second event that needs to be processed in time in the first queue; if there is a second event that needs to be processed in time in the first queue, the processing of the first event is interrupted, and the second event is processed.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to an event processing method, electronic device, storage medium, and program product. Background Technology

[0002] To meet consumers' growing functional needs, engineers have developed numerous different types of applications (APPs). Users can install a wide variety of applications on their electronic devices.

[0003] In real-world usage scenarios, applications may experience lag during operation. Generally, application lag occurs because the processing of the currently handling event takes too long, causing other pending events to accumulate / block, resulting in slow or unresponsive application behavior, i.e., lag. Therefore, managing pending events in an application is essential to avoid lag. Summary of the Invention

[0004] This application provides an event handling method, electronic device, storage medium, and program product that can minimize application lag and improve user experience.

[0005] Firstly, an event handling method is provided, applied to an electronic device. The electronic device includes a first application, and the first application's event queue includes a first queue and a second queue. The first queue and the second queue are respectively used to store pending events of the first application, and the first queue has a higher priority than the second queue. The method includes: the electronic device processing a first event in the second queue; during the processing of the first event, detecting whether there is a second event that needs to be processed promptly in the first queue; if a second event that needs to be processed promptly is detected in the first queue, then interrupting the processing of the first event and processing the second event.

[0006] Therefore, in this embodiment, the pending events of the application are divided into high-priority and low-priority events, and low-priority events can be interrupted by high-priority events, thereby ensuring that high-priority events can be processed in a timely manner. In this way, the probability of application lag can be reduced and the user experience improved.

[0007] In one possible design, processing a first event in the second queue includes: a first application processing the first event in the second queue; detecting whether there is a second event in the first queue that needs to be processed promptly includes: the first application detecting whether there is a second event in the first queue that needs to be processed promptly; and interrupting the processing of the first event includes: the first application interrupting the processing of the first event. Wherein, the first application processing the first event in the second queue may include: the first application processing the first event in the second queue according to the storage address of the second queue. The first application detecting whether there is a second event in the first queue that needs to be processed promptly may include: the first application detecting whether there is a second event in the first queue that needs to be processed promptly according to the storage address of the first queue. Wherein, the storage address of the first queue and / or the storage address of the second queue is obtained by the first application through a first interface. The first interface is an interface provided by the operating system of the electronic device.

[0008] In one possible design, the second event is an event that requires feedback to the user, and / or the second event has been waiting in the first queue for a longer than a first duration. Therefore, in this way, the electronic device can promptly process events requiring feedback to the user and / or events with longer waiting times, avoiding event backlog / blocking and improving application smoothness. Furthermore, because events requiring feedback are processed promptly, users do not experience slow application response or lag, thus enhancing the user experience.

[0009] In one possible design, before detecting whether there is a second event requiring timely processing in the first queue, the method further includes: determining that the total processing time of the first event exceeds a second duration, and / or that the processed duration of the first event exceeds a third duration. Therefore, in this embodiment, if the currently processed event is a long-duration event, the current processing event is interrupted, and other events (events requiring timely processing) are processed promptly. In this way, application lag can be avoided as much as possible, improving the user experience.

[0010] In one possible design, the method further includes: generating a third event based on the unprocessed portion of the first event, the third event being placed in either the first queue or the second queue to await processing. Therefore, in this way, the unprocessed portion of the first event can continue to be processed, ensuring that the first event can be completely processed.

[0011] In one possible design, when the third event enters the second queue, it is positioned at the head of the second queue. Therefore, this allows the unprocessed portion of the first event to be processed as quickly as possible, avoiding excessively long processing intervals between the processed and unprocessed portions of the first event.

[0012] In one possible design, the method further includes: after the second event is processed, processing the third event; during the processing of the third event, detecting whether there is a fourth event that needs to be processed in the first queue; if a fourth event that needs to be processed in the first queue is detected, then interrupting the processing of the third event and processing the fourth event. Therefore, in this embodiment of the application, an event (e.g., the first event) can be interrupted once or multiple times, thereby ensuring that other events (events that need to be processed in a timely manner) can be processed in a timely manner.

[0013] In one possible design, the first event includes N sub-events, where N is an integer greater than or equal to 2. During the processing of the first event, detecting whether there is a second event requiring timely processing in the first queue includes: performing a detection step once within the processing interval between every two adjacent sub-events. This detection step is used to detect whether there is a second event requiring timely processing in the first queue. The processing interval includes the time period from the end time of the previous sub-event to the start time of the next sub-event. Therefore, in this embodiment, the detection of whether there is an event requiring timely processing is performed within the processing interval between two adjacent sub-events. In this way, on the one hand, the processing of each sub-event is not affected; on the other hand, it is possible to detect whether there is an event requiring timely processing in a timely manner.

[0014] In one possible design, the N sub-events are N sub-events obtained by dividing the first event according to function or duration; wherein, each of the N sub-events obtained by functional division is used to implement a different function, and the processing time of each of the N sub-events obtained by duration division is T / N, where T is the total processing time of the first event. Therefore, in this embodiment, an event can be divided into multiple sub-events, and during the processing interval between two adjacent sub-events, it is detected whether there is an event that needs to be processed in a timely manner. In this way, on the one hand, the processing of each sub-event is not affected, and on the other hand, it is possible to detect whether there is an event that needs to be processed in a timely manner.

[0015] In one possible design, the event queue further includes a third queue, which has a higher priority than the first queue. The method further includes: during the processing of the second event, detecting whether a fifth event requiring immediate processing exists in the third queue; if a fifth event requiring immediate processing is detected in the third queue, then interrupting the processing of the second event and processing the fifth event. Therefore, in this embodiment, low-priority events can be interrupted by high-priority events, and high-priority events can be interrupted by even higher-priority events. In other words, the higher the priority of an event, the more promptly it can be processed. This approach reduces the probability of application lag and improves the user experience.

[0016] In one possible design, the event queue further includes a fourth queue with a higher priority than the first queue. During the processing of the first event, detecting whether a second event requiring immediate processing exists in the first queue includes: during the processing of the first event, detecting whether a sixth event requiring immediate processing exists in the fourth queue; if the fourth queue does not contain a sixth event requiring immediate processing, then detecting whether a second event requiring immediate processing exists in the first queue. Therefore, in this way, events requiring immediate processing can be checked sequentially in each queue according to their priority from high to low, with higher-priority events being processed more promptly. This reduces the probability of application lag and improves the user experience.

[0017] In one possible design, the method further includes: if a sixth event requiring immediate processing exists in the fourth queue, then the first event is interrupted and the sixth event is processed; after the sixth event is processed, it is checked whether a second event requiring immediate processing exists in the first queue; if a second event requiring immediate processing is detected in the first queue, then the second event is processed. Therefore, in this way, events requiring immediate processing can be checked sequentially in each queue according to their priority from high to low, with higher priority events being processed more promptly. This reduces the probability of application lag and improves the user experience.

[0018] In one possible design, processing the second event includes processing the second event based on the processed portion of the first event. Therefore, in this embodiment, low-priority events can be interrupted by high-priority events, and when processing high-priority events, the processed portion of the low-priority events can be used to process them. In this way, the processed portion of low-priority events can participate in the application's operation earlier, helping to improve the smoothness of application operation.

[0019] In one possible design, the first event is used to acquire display elements within the target interface of the first application. The processed portion of the first event includes the acquired first display elements. The second event is an interface refresh event. Processing the second event based on the processed portion of the first event includes: displaying the target interface based on the first display elements, wherein the target interface includes the first display elements. Therefore, in this way, the display elements within the target interface are acquired in batches. When the electronic device displays the target interface, the acquired display elements can be displayed simultaneously, without waiting for all display elements to be acquired before displaying the target interface, thus shortening user waiting time and improving user experience.

[0020] In one possible design, the method further includes: after the second event is processed, a seventh event is processed, the seventh event including the unprocessed portion of the first event, the seventh event being used to acquire a second display element within the target interface; during the processing of the seventh event, an eighth event requiring timely processing is detected in the first queue, the eighth event being an interface refresh event; if the processing time of the seventh event is less than a threshold, then after processing the seventh event, the eighth event is processed based on the processing result of the seventh event. Therefore, in this way, the display elements within the target interface are acquired in batches; each batch of display elements is acquired and then displayed, without waiting for all display elements to be acquired before displaying the target interface, thus shortening user waiting time and improving user experience.

[0021] In one possible design, the processing result of the seventh event includes the acquired second display element. Processing the eighth event based on the processing result of the seventh event includes: refreshing the target interface based on the second display element, the target interface including the second display element. Therefore, in this way, when the electronic device displays the target interface, the display elements within the target interface are displayed gradually in batches, shortening the user's waiting time and improving the user experience.

[0022] In one possible design, the method further includes: if the processing time of the seventh event is greater than or equal to the threshold, then interrupting the processing of the seventh event, and processing the eighth event based on the processed portion of the seventh event. Therefore, in this way, the display elements within the target interface are acquired in batches; each batch of display elements is displayed as soon as it is acquired, without waiting for all display elements to be acquired before displaying the target interface, thus shortening user waiting time and improving user experience.

[0023] In one possible design, the first event is used to retrieve display elements within the target interface from a local database or server. Therefore, in this embodiment, if the electronic device needs to display a target interface, and the display elements within the target interface need to be retrieved from a local database or server, it is not necessary to wait until all display elements are retrieved before displaying the target interface. Instead, the display elements within the target interface can be retrieved in batches, and each batch of display elements can be displayed, thus shortening the user's waiting time and improving the user experience.

[0024] Secondly, an electronic device is also provided for performing the method as described in the first aspect above.

[0025] Thirdly, a computer-readable storage medium is also provided for storing a computer program that, when run on a computer, causes the computer to perform the method provided in the first aspect above.

[0026] Fourthly, a computer program product is also provided, comprising a computer program that, when run on a computer, causes the computer to perform the method provided in the first aspect above.

[0027] Fifthly, a chip is also provided for performing the method as described in the first aspect above.

[0028] For the technical effects that can be achieved by the second to fifth aspects mentioned above, please refer to the description of the technical effects that can be achieved by the corresponding design scheme in the first aspect mentioned above. This application will not repeat them here. Attached Figure Description

[0029] Figure 1 A schematic diagram of an event queue for an application provided in an embodiment of this application;

[0030] Figures 2A to 2B This is an example diagram illustrating a scenario of application lag provided in an embodiment of this application;

[0031] Figures 3A to 3B Another example diagram illustrating application lag as provided in an embodiment of this application;

[0032] Figure 4 Another schematic diagram of an event queue for an application provided in an embodiment of this application;

[0033] Figures 5A to 5B A schematic diagram illustrating a first application scenario provided in an embodiment of this application;

[0034] Figures 6A to 6B A schematic diagram illustrating a second application scenario provided in an embodiment of this application;

[0035] Figure 7 A schematic diagram of an event queue for a first application provided in an embodiment of this application;

[0036] Figure 8 A flowchart illustrating an event handling method provided in an embodiment of this application;

[0037] Figure 9 Another schematic flowchart of an event handling method provided in an embodiment of this application;

[0038] Figure 10 Another schematic diagram of an event queue for a first application provided in an embodiment of this application;

[0039] Figure 11 Another schematic flowchart of an event handling method provided in an embodiment of this application;

[0040] Figure 12 A schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0041] Figure 13 This is a schematic diagram of another structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0043] The embodiments of this application involve at least one, including one or more; where "multiple" means two or more. Furthermore, it should be understood that in the description of this specification, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order. For example, "first queue" and "second queue" do not represent the degree of importance of the two or their order, but are merely for descriptive distinction. In the embodiments of this application, "and / or" merely describes an association relationship, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0044] The directional terms mentioned in the embodiments of this application, such as "up", "down", "left", "right", "inner", and "outer", are only for reference to the directions in the accompanying drawings. Therefore, the directional terms used are for better and clearer explanation and understanding of the embodiments of this application, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0045] References to "one embodiment," "in some examples," or "some embodiments" as described in this specification mean that one or more embodiments of this specification include a particular feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in some examples," "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0046] The technical solutions provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0047] Electronic devices contain a wide variety of applications. These applications can be launched and run based on user actions. It's important to understand that the operation of an application can be viewed as the process of continuously processing events and responding to them. The events that the application needs to process are called pending events. Since applications often have a large number of pending events, an event management mechanism can be used to manage them and avoid confusion.

[0048] One possible management approach is to introduce an event queue to manage pending events in the application. The event queue follows a first-in-first-out (FIFO) principle. For example, pending events are sequentially entered into the event queue according to their occurrence time, and then the application retrieves events from the queue and processes them according to the FIFO principle. The introduction of event queues ensures that the application's event processing proceeds in an orderly manner. However, as business needs increase, the number of pending events grows, and a single event queue can easily lead to event backlog / blocking, making it difficult to meet the demands. Therefore, this embodiment adopts a multi-event queue management mechanism, where one application corresponds to multiple event queues.

[0049] For ease of management, when an application has multiple event queues, these queues need to be differentiated. One possible approach is to assign different priorities to each event queue. For example, please refer to [link to relevant documentation]. Figure 1 The application's event queues consist of Queue 1 and Queue 2. Queue 1 has a higher priority than Queue 2. That is, Queue 1 stores higher-priority events, and Queue 2 stores lower-priority events. Both Queue 1 and Queue 2 follow the First-In-First-Out (FIFO) principle.

[0050] In real-world scenarios, events pending in a high-priority queue (e.g., queue 1) may be blocked by low-priority events and thus cannot be processed in a timely manner.

[0051] For example, Figure 1 In this application, assuming event 1 enters queue 2 first, the application processes event 1 first. While event 1 is being processed, event 2 enters queue 1. Therefore, the application processes event 2 after processing event 1. In other words, Figure 1 The event handling order used in this application is: process event 1 first, then process event 2. It should be noted that... Figure 1 The arrows used to indicate the order of event processing (the dashed arrows in the diagram) point from left to right, meaning that events on the right are executed before events on the left. Therefore, Figure 1 Above the dashed arrow, since event 1 is to the right of event 2, the event processing order is to process event 1 first, then event 2. The principle is the same for the subsequent attached diagrams. Continuing as... Figure 1 It is understandable that if the processing of event 1 takes a long time, then event 2 will have to wait a long time, and if there are other high-priority events after event 2... Figure 1 (Not shown in the image), these high-priority events will all be blocked because the processing time of event 1 is too long. Assuming that high-priority events are those that require feedback to the user (e.g., UI refresh events) or events that are perceptible to the user, the blocking of high-priority events means that feedback to the user cannot be provided in a timely manner, resulting in slow or unresponsive application behavior, i.e., application lag. Therefore, through... Figure 1 It can be seen that the reason for the application lag is that the processing of low-priority events takes too long and cannot be interrupted, which causes the high-priority queue to be blocked and unable to be processed in time.

[0052] To facilitate understanding, the following examples illustrate several scenarios where application lag is caused by the aforementioned reasons. As mentioned earlier, slow application response speed creates a sense of waiting for the user, which is perceived as application lag. One manifestation of slow application response speed is slow update of the application's display interface. For example, after a user clicks on a control within the current interface, they must wait a certain amount of time before the target interface (the interface opened by the control) appears, giving the user the feeling of application lag. The slow appearance of the target interface is caused by the excessively long and uninterrupted processing of the aforementioned low-priority events, which blocks the high-priority queue. The following two specific examples illustrate this, with different target interfaces in each example.

[0053] Example 1: Application interface switching scenario

[0054] For example, such as Figure 2A(a) The electronic device displays the main interface of the settings application, which includes options 200 for notifications and the status bar. Optionally, a description of option 200 may also be displayed, such as "Which app messages are allowed to be displayed in the status bar." Upon receiving an action on option 200, the electronic device displays as follows: Figure 2A (b) The interface displays a prompt message to remind the user to wait. Optionally, the prompt message may or may not be present; this is not limited. Afterwards, the electronic device displays as follows: Figure 2A (c) The interface includes information about each application in the electronic device (e.g., application icons and / or names) and a switch control for each application, used to turn the application's status bar notification function on or off (i.e., whether application messages are displayed in the status bar). If... Figure 2A The interface shown in (c) is called the target interface. Figure 2A As we know, after an electronic device receives an operation to open a target interface, it needs to wait a certain amount of time before the target interface is displayed. From the user's perspective, this waiting time is what we call application lag.

[0055] The following is passed Figure 2B ,illustrate Figure 2A The specific reasons why the target interface of the application in the settings is lagging.

[0056] After the settings application receives an operation instructing the opening of the target interface (e.g., the user clicking option 200), it determines that the display elements within the target interface (e.g., information about each application and whether each application has enabled status bar notifications) require database access. Therefore, it generates event 1. Event 1 is a database access event used to retrieve information about each application and whether each application has enabled status bar notifications from the database. In other words, event 1 is used to retrieve the display elements within the target interface. Event 1 is then added to the settings application's event queue. Figure 2B (a) Since event 1 (i.e., the database access event) has a lower priority, event 1 enters queue 2. The application is configured to retrieve event 1 from queue 2 and process it, i.e., by accessing the database to obtain information about each application and whether each application has enabled status bar notifications, i.e., to obtain the displayed elements within the target interface. Optionally, the database can be a local database of the electronic device or a cloud database, containing information about each application on the electronic device and whether each application has enabled status bar notifications.

[0057] Before event 1 is processed, the settings application sends a UI update request to the operating system, indicating that the settings application needs a UI update. In response to the settings application's UI update request, the operating system posts a UI refresh event to the settings application's event queue, indicating that the interface should be refreshed. For example, the UI refresh event can be a display frame synchronization event, such as a vertical synchronization (Vsync) event. Figure 2B (b) Because the Vsync event is a high-priority event, it enters queue 1. It should be noted that although the Vsync event is a high-priority event, since event 1 (i.e., the database access event) has not yet been processed, the Vsync event must wait until event 1 is completed before it can be processed. As mentioned earlier, event 1 is used to access the database to obtain information about various applications and whether each application has enabled status bar notifications. Therefore, the processing time for event 1 is relatively long, and the Vsync event must wait for a longer period. As mentioned earlier, the Vsync event is a UI refresh event; if the Vsync event cannot be processed in a timely manner, the target UI cannot be updated promptly. Therefore, [the following occurs]. Figure 2A (b) shows the waiting scenario.

[0058] like Figure 2B (c) After event 1 is processed, the application retrieves the Vsync event from queue 1 and processes it, i.e., performs graphics rendering and display. Since event 1 has been processed, meaning all application information and whether each application has enabled status bar notifications have been obtained—in other words, all display elements of the target interface have been obtained—the application processes the Vsync event based on the obtained display elements, performing graphics rendering and display, which is why the event is displayed. Figure 2A The target interface is shown in (c).

[0059] Therefore, through Figure 2A and Figure 2B As can be seen, when the application switches from the current interface to the target interface, the processing of low-priority events (such as database access events) takes too long and cannot be interrupted, which causes high-priority events (such as Vsync events) to be blocked, resulting in the target interface not appearing in time. In other words, the interface switching speed is slow, giving users a laggy experience.

[0060] Example 2: Application startup scenario

[0061] For example, such as Figure 3A (a) The electronic device displays a desktop, which includes an icon for a browser application. Upon receiving an action on the browser application icon, the electronic device launches the browser application and displays the following: Figure 3A(b) The interface displays a prompt message to remind the user to wait. Optionally, the prompt message may or may not be present; this is not limited. Afterwards, the electronic device displays as follows: Figure 3A (c) is the interface of the browser application, which is the homepage of the browser application. The homepage includes display elements (e.g., one or more news articles) that the browser application retrieves from the server. If... Figure 3A The interface shown in (c) is called the target interface. Figure 3A It is known that after receiving an operation to open a target interface, an electronic device needs to wait a certain amount of time before the target interface is displayed. From the user's perspective, this waiting time is what we call application lag.

[0062] The following is passed Figure 3B ,illustrate Figure 3A The specific reasons why the target interface of a Chinese browser application may lag.

[0063] After receiving the launch command, the browser application determines that the display elements (e.g., various news items) within the target interface (i.e., the homepage) need to be retrieved from the server. It then generates event 1, which is a server access event used to retrieve information from the server. In other words, event 1 is used to retrieve display elements within the target interface. Event 1 is added to the browser application's event queue, such as... Figure 3B (a) Since event 1 (i.e., the server access event) has a lower priority, event 1 enters queue 2. The browser application retrieves event 1 from queue 2 and processes it, that is, it obtains information from the server, i.e., it obtains the display elements of the target interface. Optionally, the server may be the application server corresponding to the browser application.

[0064] Before event 1 is processed, the browser application sends a UI update request to the operating system, indicating that the browser application needs to update its interface. In response to the browser application's UI update request, the operating system throws a Vsync event into the browser application's event queue. For example... Figure 3B (b) Because the Vsync event has a high priority, it enters queue 1. It should be noted that although the Vsync event is a high-priority event, it must wait for event 1 (the server access event) to finish processing before it can be processed. This is understandable, as event 1 (the server access event) retrieves information from the server, which takes a relatively long time; therefore, the Vsync event must wait for a certain period. As mentioned earlier, the Vsync event is a UI refresh event; if the Vsync event cannot be processed in a timely manner, the target UI cannot be updated promptly. Therefore, [the following occurs]. Figure 3A (b) shows the waiting scenario.

[0065] like Figure 3B(c) After event 1 is processed, the browser application retrieves the Vsync event from queue 1 and processes it, i.e., performs graphics rendering and display. Since event 1 has been processed, meaning the required display elements for the target interface (e.g., various news items) have been obtained from the server, the browser application processes the Vsync event based on the obtained display elements, performing graphics rendering and display, which is why the content is displayed. Figure 3A (c) shows the target interface (i.e., the main interface of the browser application).

[0066] Therefore, through Figure 3A and Figure 3B It can be seen that when the application starts, the processing of low-priority events (such as server access events) takes too long and cannot be interrupted, which causes high-priority events (such as Vsync events) to be blocked, resulting in the main interface of the application not being displayed in time, causing the application to start slowly and lag.

[0067] The above are two examples of application lag scenarios. In summary, after an electronic device receives an operation to display the target interface, the processing of low-priority events takes too long and cannot be interrupted, causing high-priority events (such as Vsync events) to be blocked and unable to be processed in time, resulting in a slow appearance of the target interface and a laggy experience for the user.

[0068] To avoid application lag, this application provides an event handling method. In this method, while processing low-priority events, the application checks for the existence of high-priority events that require immediate processing. If such events exist, the currently processing low-priority events is interrupted, and the high-priority events are processed instead. This approach minimizes the chance of high-priority events being blocked and unable to be processed in a timely manner, reducing the probability of application lag.

[0069] For example, see Figure 4 The application's event queue includes queue 1 and queue 2. Queue 1 has a higher priority than queue 2. Assuming event 1 enters queue 2 first, the application processes event 1 first. While event 1 is being processed, event 2 enters queue 1. If the application detects the presence of event 2 that requires immediate processing, it interrupts the processing of event 1 and processes event 2. After event 2 is processed, the remaining parts of event 1 are processed. This ensures that the higher-priority event 2 is processed promptly.

[0070] The event handling method provided in this application can be applied to electronic devices. Electronic devices can be any device that needs to perform event handling, including but not limited to terminal devices, servers, and interaction devices between terminal devices and servers, such as routers and switches. Taking terminal devices as an example, this includes but is not limited to: mobile phones, portable Android devices (PADs), laptops, PDAs, and other portable terminal devices; or wearable devices such as watches, bracelets, headphones, and helmets; or home appliances such as smart TVs, set-top boxes, smart refrigerators, and smart robot vacuum cleaners; or in-vehicle devices such as in-vehicle displays and in-vehicle speakers; or virtual reality (VR) devices, augmented reality (AR) devices, and other devices. In short, this application does not limit the specific type of terminal device. Moreover, the operating system of the terminal device can be Android. System, HarmonyOS system, system, system, system, system, system, Any one of the systems, without limitation.

[0071] Next, two application scenarios of the embodiments of this application will be illustrated with examples. Application scenario one corresponds to example one in the previous text, and application scenario two corresponds to example two in the previous text.

[0072] Application Scenario 1: Application Interface Switching Scenarios

[0073] like Figure 5A (a) The electronic device displays the main interface of the settings application, which includes options 200 for notifications and the status bar. After receiving an action on option 200, the electronic device displays the following... Figure 5A (b) The interface includes information about some applications on the electronic device (e.g., application icons and / or names) and a toggle control for each application to enable or disable the application's status bar notification function. The electronic device then displays as shown below. Figure 5A (c) is the interface that displays more information about the application and the corresponding switch controls for each application. If... Figure 5A The interfaces shown in (b) and (c) are called the target interfaces. Figure 5A As can be seen, the display elements in the target interface are displayed gradually in batches, rather than all at once.

[0074] Please compare. Figure 5A And the previous text Figure 2A. Figure 2A After receiving an operation to display the target interface, the electronic device needs to wait for a certain period of time before the target interface can be displayed, and all display elements in the target interface are displayed at once. Figure 5A After receiving an operation to display a target interface, the electronic device can display the target interface without waiting, and the display elements within the target interface are displayed gradually in batches. Therefore, compared with... Figure 2A compared to, Figure 5A There is no noticeable user wait time, which improves the user experience.

[0075] The following is passed Figure 5B ,illustrate Figure 5A The implementation principle.

[0076] After the settings application receives an operation instructing it to open the target interface (e.g., the user clicking option 200), it determines that the display elements within the target interface (e.g., information about each application and whether each application has status bar notifications enabled) require database access. It then generates event 1, a database access event used to retrieve information about each application and whether each application has status bar notifications enabled from the database. In other words, event 1 is used to retrieve the display elements within the target interface. Event 1 is added to the settings application's event queue. Figure 5B (a) Since event 1 (i.e., the database access event) has a lower priority, event 1 enters queue 2. The application is configured to retrieve event 1 from queue 2 and process event 1, that is, to access the database to obtain information about each application and whether each application has enabled the status bar notification function, i.e., to obtain the display elements in the target interface.

[0077] Before event 1 is processed, the settings app sends a UI update request to the operating system, indicating that the settings app needs a UI update. In response to the settings app's UI update request, the operating system throws a Vsync event into the settings app's event queue. For example... Figure 5B (b) Since the Vsync event is a high priority event, the Vsync event enters queue 1.

[0078] During the processing of Event 1, the application is configured to detect events in Queue 1 that require immediate processing. If an event requiring immediate processing is detected in Queue 1, the processing of Event 1 is interrupted, and the event requiring immediate processing is handled instead. Figure 5B(c) If the application detects a Vsync event in queue 1 that requires immediate processing, it interrupts the processing of event 1 and handles the Vsync event. It should be noted that since event 1 (i.e., the database access event) has already been partially processed—meaning it has already obtained some application information and whether the application has enabled status bar notifications—in other words, some display elements within the target interface have been acquired. Therefore, when the application handles the Vsync event, it can perform graphics drawing and display based on the acquired display elements. Thus, the Vsync event occurs... Figure 5A (b) shows the target interface, which displays some display elements.

[0079] like Figure 5B (d) After the Vsync event is processed, the settings application continues to process the remaining part of event 1 (referred to as event 3), that is, it continues to retrieve information about the remaining applications from the database and whether these applications have enabled the status bar notification function, i.e., it continues to retrieve other display elements within the target interface. Understandably, since there are still display elements that have not been displayed, the settings application will also send an interface update request to the operating system. The operating system again throws a Vsync event into the settings application's event queue. Because the Vsync event has high priority, it enters queue 1, such as... Figure 5B (e).

[0080] Figure 5B In (e), if the processing time for event 3 is short, then the Vsync event is processed after event 3 is completed. Since event 3 has already been processed, meaning the information about the remaining applications and whether status bar notifications are enabled has been obtained through database access—in other words, the other display elements within the target interface have been acquired—graphics drawing and display can be performed based on these display elements when setting the application to process the Vsync event. Therefore, the occurrence of... Figure 5A (c) shows the target interface, which displays all display elements. That is, event 1 (i.e., the database access event) is executed in two parts (interrupted once). Each of these two parts retrieves a portion of the display elements within the target interface, and through two Vsync events, all display elements within the target interface are displayed.

[0081] Figure 5BIn (e), if the processing of event 3 takes a long time, the processing of event 3 can be interrupted, and then the Vsync event can be processed. It should be noted that since event 3 has been partially processed, meaning some display elements have been acquired, graphics drawing and display can be performed based on these display elements when processing the Vsync event. Therefore, more display elements appear in the target interface. It should be understood that since event 3 has not been fully processed, not all display elements are yet displayed in the target interface. After processing the Vsync event, the remaining part of event 3 (referred to as event 4) is processed. The processing principle of event 4 is the same as that of event 3 and will not be repeated. In other words, event 1 (i.e., the database access event) is executed multiple times (interrupted multiple times), each time acquiring a portion of the display elements in the target interface, and through multiple Vsync events, the display elements in the target interface are refreshed in multiple batches.

[0082] Application Scenario 2: Application Launch Scenario

[0083] like Figure 6A (a) The electronic device displays a desktop, which includes an icon for a browser application. Upon receiving an action on the browser application icon, the electronic device launches the browser application and displays the following: Figure 6A (b) The interface is the browser application's homepage, which includes one or more news articles. Afterwards, the electronic device displays... Figure 6A (c) is the interface that displays more news items. If... Figure 6A The interfaces in (b) and (c) are called the target interfaces, through which... Figure 6A It can be seen that the display elements within the target interface (e.g., multiple news items) are displayed gradually in batches, rather than all at once.

[0084] Please compare. Figure 6A Related to the previous text Figure 3A . Figure 3A After receiving the launch command, the browser application needs to wait for a certain period of time before the target interface is displayed, and all display elements (i.e., multiple news articles) in the target interface are displayed at once. Figure 6A After receiving the launch command, the browser application can display the target interface without waiting, and the display elements within the target interface are shown gradually in batches. Therefore, compared to... Figure 3A compared to, Figure 6A There is no noticeable user wait time, which improves the user experience.

[0085] The following is passed Figure 6B ,illustrate Figure 6A The implementation principle.

[0086] After receiving the launch command, the browser application determines that the display elements within the target interface (e.g., news articles) need to be retrieved from the server. It then generates event 1, which is a server access event used to retrieve information from the server. In other words, event 1 is used to retrieve the display elements within the target interface. Event 1 is added to the browser application's event queue, such as... Figure 6B (a) Since event 1 (i.e., the server access event) has a lower priority, event 1 enters queue 2. The browser application retrieves event 1 from queue 2 and processes it, i.e., obtains the display elements within the target interface. Optionally, the server may be the application server corresponding to the browser application.

[0087] Before event 1 is processed, the browser application sends a UI update request to the operating system, indicating that the browser application needs to update its interface. In response to the browser application's UI update request, the operating system throws a Vsync event into the browser application's event queue. For example... Figure 6B (b) Since the Vsync event is a high priority event, the Vsync event enters queue 1.

[0088] During the processing of event 1, the browser application can detect events in queue 1 that require immediate processing. If an event requiring immediate processing is detected in queue 1, the processing of event 1 is interrupted, and the event requiring immediate processing is processed instead. Figure 6B (c) If the browser application detects a Vsync event in queue 1 that requires immediate processing, it interrupts the processing of event 1 and processes the Vsync event. It should be noted that since event 1 (i.e., the server access event) has already been partially processed—meaning some information (e.g., one or more news items) has been retrieved from the server—in other words, some display elements within the target interface have been obtained. Therefore, when processing the Vsync event, the browser application can perform graphics rendering and display based on these display elements. Thus, the Vsync event occurs... Figure 6A (b) shows the target interface, which includes some display elements, such as one or more news articles.

[0089] like Figure 6B (d) After the Vsync event is processed, the browser application continues to process the remaining part of event 1 (referred to as event 3), that is, to continue to retrieve other display elements within the target interface. Understandably, since there are still display elements to be displayed, the browser application will send another UI update request to the operating system. The operating system then throws another Vsync event into the browser application's event queue. Because the Vsync event has high priority, it enters queue 1, such as... Figure 6B (e).

[0090] Figure 6BIn (e), if the processing time for event 3 is short, then the Vsync event is processed after event 3 is completed. Since event 3 has already been processed, meaning other display elements within the target interface have been acquired, graphics drawing and display can be performed based on these display elements when processing the Vsync event. Therefore, [the following occurs]. Figure 6B (b) shows the target interface, which displays all display elements. That is, event 1 (i.e., the server access event) is executed in two parts (interrupted once). Each of these two parts retrieves a portion of the display elements in the target interface, and the display elements in the target interface are refreshed in two separate Vsync events.

[0091] Figure 6B In (e), if the processing of event 3 takes a long time, the processing of event 3 can be interrupted, and then the Vsync event can be processed. Similarly, since part of event 3 has been processed, i.e., some display elements have been acquired, graphics drawing and display can be performed based on these display elements when processing the Vsync event. Therefore, there are more display elements in the target interface. It should be understood that since event 3 has not been fully processed, not all display elements are displayed in the target interface. After processing the Vsync event, the remaining part of event 3 (called event 4) is processed. The processing principle of event 4 is the same as that of event 3, and will not be repeated. That is to say, event 1 (i.e., the server access event) is executed in multiple stages (interrupted multiple times), each time acquiring a portion of the display elements in the target interface, and refreshing the display elements in the target interface in multiple stages through multiple Vsync events.

[0092] The above are illustrative examples of application scenarios for the embodiments of this application. It should be understood that the above application scenarios are merely examples and do not constitute a limitation on this application. In addition to the above application scenarios, the technical solutions of the embodiments of this application can also be applied to other application scenarios.

[0093] Based on the above application scenarios, the technical solutions of the embodiments of this application will be described in detail below.

[0094] For ease of understanding, the following explanation uses a first application in an electronic device as an example. The first application can be the settings application in application scenario one above, or the browser application in application scenario two. In short, the type of the first application is not limited in the embodiments of this application. Moreover, the first application can be a system application or a third-party application, without limitation.

[0095] In this embodiment, after receiving a launch command from a first application, the electronic device launches the first application and creates an event queue for storing pending events. The creation of the event queue can be handled by the operating system of the electronic device. Optionally, the operating system can create the event queue for the first application actively or passively. For example, actively creating the event queue involves the electronic device's desktop displaying the application icon of the first application. After receiving an operation on the application icon, the operating system sends a launch command to the first application and actively creates an event queue. Passively creating the event queue involves the first application receiving a launch command and sending a request to the operating system to create an event queue. The operating system responds to the request and creates the event queue. The process of the operating system creating the event queue may include: creating the event queue in the memory resources allocated to the first application and sending the event queue information (e.g., storage address) to the first application. The first application then retrieves pending events from the event queue using the storage address and processes them. The process of the operating system sending the storage address of the event queue to the first application may include: the operating system sending the storage address of the event queue to the first application through a first interface. Optionally, the first interface may be an interface provided by the operating system of the electronic device. For example, the first interface may be an application programming interface (API). It is understood that after the first application exits, the operating system may cancel the event queue created for the first application to release the occupied memory resources.

[0096] Optionally, the number of event queues for the first application can be one or more. In some embodiments, the number of event queues is pre-configured for the first application. For example, the application package of the first application pre-configures the number of event queues. The operating system of the electronic device determines the number of event queues for the first application based on the application package of the first application, and then creates the same number of event queues for the first application. In other embodiments, the number of event queues is pre-configured by the operating system of the electronic device. Therefore, when the operating system creates event queues for the first application, it creates the same number of event queues for the first application based on the number of event queues pre-configured by the operating system. Optionally, the number of event queues pre-configured by the operating system can be the same or different for different applications, and is not limited thereto.

[0097] When the first application has multiple event queues, different event queues can correspond to different priorities. Taking an application with two event queues as an example, please refer to [link to example]. Figure 7The first application's event queue consists of queue 1 and queue 2, with queue 1 having a higher priority than queue 2. That is, queue 1 stores higher-priority events, and queue 2 stores lower-priority events. Events pending in the first application are placed into the corresponding queue according to their priority. For example, if event 1 has a lower priority, it goes into queue 2; if event 2 has a higher priority, it goes into queue 1.

[0098] After the event queue of the first application is successfully created, the event thrower (also known as the event producer) can throw pending events into the event queue of the first application. Optionally, the event thrower of the first application can be the main thread of the first application, a child thread of the first application, the main thread of another application, a child thread of another application, the operating system, etc., without limitation. (Referring to the application scenario one above...) Figure 5B For example, event 1 (i.e., the database access event) is thrown by the main thread of the application, while the Vsync event is thrown by the operating system. This is similar to the scenario in application scenario two mentioned earlier. Figure 6B For example, the initiator of event 1 (i.e., the server access event) is the main thread of the browser application, while the initiator of the Vsync event is the operating system.

[0099] Continue with Figure 7 Taking the two queues shown as examples, after the event thrower generates an event to be processed, it can determine the priority level of the event and then throw it into the event queue of the corresponding priority level. One possible way to determine the priority level of an event is to query a mapping relationship, whereby the mapping relationship describes the priority levels of various events to be processed in the first application. Optionally, the first mapping relationship can be pre-configured.

[0100] Continue with Figure 7 For example, please refer to the two queues shown below. Figure 8 This is a schematic flowchart of an event handling method provided in an embodiment of this application. The method can be applied to... Figure 7 The scene shown. (As shown) Figure 8 The process includes the following steps:

[0101] Step 801, Event 1 enters queue 2.

[0102] Taking the first application as the settings application as an example, event 1 could be from the application scenario one mentioned earlier. Figure 5B Event 1 in the context refers to the database access event. Taking a browser application as an example, Event 1 could be the event mentioned in application scenario two above. Figure 6B Event 1 in the data refers to the server access event.

[0103] Step 802, first application processes event 1.

[0104] Event 1 is the first application scenario mentioned above. Figure 5B Taking the database access event as an example, the first application processes event 1, which involves retrieving information from the database, such as information about each application and whether each application has enabled status bar notifications. Event 1 is the application scenario two mentioned earlier. Figure 6B Taking the server access event in the example, the first application handles event 1, which is to obtain information from the server, such as news.

[0105] As mentioned earlier, after the operating system of the electronic device creates an event queue (e.g., queue 1 and queue 2) for the first application, it sends the storage address of the event queue to the first application through a first interface. Thus, the first application can retrieve events to be processed from the event queue using the storage address and process them. For example, the first application retrieves event 1 from queue 2 based on the storage address of queue 2 and processes event 1.

[0106] Step 803, Event 2 enters queue 1.

[0107] For example, event 2 could be a Vsync event. It should be noted that the execution order of step 803 and subsequent steps 804 and 805 is not limited. For example, step 803 can occur after step 804, or after step 805.

[0108] Step 804: The first application determines whether the currently processed event is of the highest priority. If so, the currently processed event cannot be interrupted; otherwise, proceed to step 805.

[0109] For example, if the first application determines that the currently processed event comes from queue 1, i.e., from the highest priority queue, then the current processed event has the highest priority and will not be interrupted. If the first application determines that the current processed event comes from queue 2, i.e., from a low priority queue, then the current processed event does not have the highest priority and can be interrupted. In other words, events in high-priority queues cannot be interrupted, while events in low-priority queues can be interrupted. Optionally, step 804 can be executed or not, without limitation. Figure 8 Step 804 is represented by a dashed line.

[0110] Step 805: During the processing of event 1, the first application checks whether there is an event in queue 1 that needs to be processed in a timely manner. If there is, step 806 is executed; otherwise, step 805 can be executed again.

[0111] Optionally, before step 805, the first application may further determine whether event 1 satisfies the first condition. If it does, step 805 is executed; otherwise, step 805 is not required. Optionally, the first condition includes at least one of the following:

[0112] (1) The total processing time of event 1 exceeds the time threshold 1. The specific value of the time threshold 1 is not limited. That is, if event 1 is a long-running event, the first application checks whether there is an event 2 that needs to be processed in a timely manner in queue 1 during the processing of event 1. In this way, the first application needs to determine the total processing time of event 1. One possible way is that the total processing time of event 1 is preset. For example, the application package of the first application has a preset total processing time of event 1. The first application can determine the total processing time of event 1 based on the application package, and then determine whether event 1 is a long-running event. Another possible way is that the first application evaluates the total processing time of event 1 based on the event type of event 1. For example, if the event type of event 1 is a database access event or a server access event, then event 1 is determined to be a long-running event.

[0113] (2) The processing time of event 1 has reached the duration threshold 2. For example, when the first application starts processing event 1, it starts a timer. When the timer reaches the duration threshold 2, it is determined that the processing time of event 1 has reached the duration threshold 2. The specific value of the duration threshold 2 is not limited in this embodiment. That is, if the processing time of event 1 exceeds the duration threshold 2, the first application checks whether there is an event 2 in queue 1 that needs to be processed in a timely manner.

[0114] If the first application determines that event 1 satisfies the first condition described above, then step 805 is executed to check whether there is an event 2 in queue 1 that needs to be processed promptly. Event 2 that needs to be processed promptly satisfies a second condition, which optionally includes at least one of the following:

[0115] (1) Event 2 is an event that requires feedback to the user. For example, a UI refresh event (e.g., a Vsync event). Optionally, an event that requires feedback to the user can be generated spontaneously by the electronic device or triggered by the user. Taking user-triggered events as an example, in application scenario one above, the application is set to generate a Vsync event when triggered by the user; or, in application scenario two above, the browser application generates a Vsync event when triggered by the user. Taking spontaneous generation by the electronic device as an example, for instance, the first application displays an animated image, which includes multiple frames. Before displaying the next frame, the first application automatically sends a UI update request to the operating system. In response to the UI update request, the operating system throws a Vsync event into the event queue of the first application. The first application processes the Vsync event to display the next frame. Optionally, in addition to Vsync events, events that require feedback to the user can also be other events, such as sound playback events, vibration feedback events, etc., which will not be listed one by one.

[0116] (2) The waiting time for event 2 in queue 1 exceeds the time threshold 3. That is, if event 2 in queue 1 has been waiting for a long time, the first application will interrupt the currently processed event 1 and process event 2. For example, the time threshold 3 can be 4ms, 40ms, 400ms, etc., and the specific value is not limited.

[0117] (3) The total processing time for event 2 is less than the duration threshold 4. The specific value of the duration threshold 4 is not limited. Optionally, the duration threshold 4 is less than or equal to the duration threshold 1 mentioned above. That is, if event 2 in queue 1 is a short-duration event, the first application can interrupt the currently processing event 1 and process event 2. In this way, the first application needs to determine the total processing time for event 2, which is the same principle as determining the total processing time for event 1 mentioned above, and will not be repeated.

[0118] Optionally, the first application's detection of whether there is an event 2 that needs to be processed promptly in queue 1 may include: the first application detecting whether there is an event 2 that needs to be processed promptly in queue 1 based on the storage address of queue 1. The storage address of queue 1 may be sent to the first application by the operating system of the electronic device through the first interface. This part has been described above and will not be repeated.

[0119] Step 807, first application process event 2.

[0120] Taking event 2 as an example, the first application handles the Vsync event, that is, the first application executes the graphics drawing and display process to refresh the interface.

[0121] In some embodiments, the first application processing event 2 may include: the first application processing event 2 based on the processed portion of event 1. Taking a settings application as an example, event 1 may be the database access event in the application scenario 1 above, that is, event 1 is used to obtain display elements within the target interface of the settings application. The processed portion of event 1 includes the obtained display elements. It can be understood that since event 1 has not been fully processed, the obtained display elements are only a portion of the display elements within the target interface. Therefore, the first application processes event 2 based on the processed portion of event 1, that is, based on the obtained display elements, it processes event 2 to display the target interface, which includes the obtained display elements, i.e., a portion of the display elements are displayed within the target interface.

[0122] Optionally, if the event queue of the first application also includes queue 3, and the priority of queue 3 is higher than that of queue 1, then during the processing of event 2, the first application can also detect whether there are any events in queue 3 that need to be processed in a timely manner; if an event that needs to be processed in a timely manner is detected in queue 3, the processing of event 2 is interrupted and the events in queue 3 are processed. The principle is the same and will not be repeated.

[0123] Step 808, the first application processes the remainder of event 1.

[0124] Optionally, before step 808, the process may further include: the first application generating event 3 based on the remaining portion of event 1, and event 3 entering the event queue of the first application for processing. Event 3 may include the unprocessed portion of event 1, and optionally, may also include context information between the processed and unprocessed portions of event 1. The context information may include the application identifier of the first application, the event identifier of event 1, the processing progress of event 1, etc. As mentioned above, event 3 enters the event queue of the first application, which includes queue 1 and queue 2. Optionally, event 3 may enter either queue 1 or queue 2. Taking event 3 entering queue 1 as an example, that is, event 1 originally entered queue 2, and after event 1 was interrupted, the remaining portion of event 1 generates event 3, the priority of event 3 is increased, and it enters queue 1. Taking event 3 entering queue 2 as an example, that is, event 1 originally entered queue 2, and after event 1 was interrupted, the remaining portion of event 1 generates event 3, the priority of event 3 remains unchanged, and it enters queue 2. Optionally, when event 3 enters the event queue of the first application, it can be placed at the tail or the head of the queue. Taking event 3 entering queue 2 as an example, in order to ensure that event 3 can be processed as quickly as possible, event 3 can be placed at the head of queue 2.

[0125] After event 3 enters the event queue of the first application, the first application can retrieve event 3 from the event queue and process it. Optionally, during the processing of event 3, the first application can check whether there are any events in queue 1 that require immediate processing. If so, it can interrupt the processing of event 3 and process the events that require immediate processing. Optionally, before checking whether there are any events in queue 1 that require immediate processing, the first application can determine whether event 3 meets a first condition, such as whether the total processing time of event 3 exceeds a time threshold 5, and / or whether the processing time of event 3 exceeds a time threshold 6. If event 3 meets the first condition, then it checks whether there are any events in queue 1 that require immediate processing. The detailed explanation of the first condition has been described above and will not be repeated. Optionally, the events in queue 1 that require immediate processing also meet a second condition, such as events that require feedback to the user, events whose waiting time in queue 1 exceeds a preset threshold 7, etc. The detailed explanation of the second condition has been described above and will not be repeated.

[0126] Continuing with the example of the settings application, event 1 could be the database access event from application scenario one mentioned earlier, meaning event 1 is used to retrieve the display elements within the target interface of the settings application. The processed portion of event 1 includes the retrieved display elements. Therefore, the unprocessed portion of event 1, i.e., event 3, is used to retrieve other display elements within the target interface. During the processing of event 3, the first application detects an event in queue 1 that requires immediate processing, such as a Vsync event.

[0127] If the processing time for event 3 is short, after the first application processes event 3, it processes the Vsync events in queue 1 based on the processing result of event 3. As mentioned earlier, event 3 is used to obtain other display elements within the target interface. Therefore, the processing result of event 3 includes the obtained other display elements. Thus, the first application processes the Vsync events based on the processing result of event 3, that is, it displays the target interface based on the obtained other display elements, and the target interface includes these other display elements. Since event 1 has been processed, all display elements are displayed within the target interface. Therefore, in this scenario, event 1 is interrupted once, that is, event 1 is processed in two steps, each time obtaining a portion of the target interface's display elements, and displaying all display elements within the target interface through two Vsync events.

[0128] If processing event 3 takes a long time, the first application interrupts the processing of event 3 and processes the Vsync event. For example, the first application can process the Vsync event based on the processed portion of event 3. The processed portion of event 3 includes the acquired partial display elements. Therefore, the first application processes the Vsync event based on the processed portion of event 3, that is, it displays the target interface based on the acquired partial display elements, and the target interface includes the acquired partial display elements. It should be noted that since event 3 is not fully processed, not all display elements are displayed in the target interface. Since event 3 is interrupted, the first application can generate event 4 based on the remaining portion of event 3 and then process event 4. The processing process of event 4 is the same as that of event 3, and will not be elaborated here. Therefore, in this scenario, event 1 is interrupted multiple times, that is, event 1 is processed in three or more parts, each time acquiring partial display elements of the target interface, and displaying all display elements in the target interface through three or more Vsync events.

[0129] As mentioned earlier, during the processing of event 1, the first application checks whether event 2, which requires timely processing, exists in queue 1. As one possible implementation, event 1 includes multiple sub-events. The first application can perform a detection step once between each pair of adjacent sub-events. This detection step is used to check whether event 2, which requires timely processing, exists in queue 1. The processing interval between two adjacent sub-events can include the time period from the end of processing the previous sub-event to the start of processing the next sub-event.

[0130] For example, see Figure 9 In (a), queue 2 contains event 1, which includes sub-events 1a, 1b, 1c, and 1d. The first application retrieves event 1 from queue 2 and processes each sub-event of event 1 sequentially. After processing each sub-event, a detection step is performed. If no event requiring immediate processing is detected in queue 1, the next sub-event of event 1 is processed. If event 2 requiring immediate processing is detected in queue 1, the processing of event 1 is interrupted, and event 2 is processed. For example, as... Figure 9 In (b), after the first application finishes processing sub-event 1b (processed sub-events are indicated in black), it detects that queue 1 contains event 2 that needs to be processed promptly. Then, as follows... Figure 9 In step (c), the first application generates event 3 based on the unprocessed portion of event 1. Event 3 enters queue 2 to await processing, and the first application retrieves event 2 from queue 1 and processes it. For example... Figure 9In step (d), after event 2 is processed (represented in black), the first application retrieves event 3 from queue 2 and processes it. Event 3 includes multiple sub-events. During the processing interval between two adjacent sub-events, it is possible to check whether there are any events in queue 1 that need to be processed in a timely manner. The principle is the same and will not be repeated.

[0131] Optionally, the first application's detection steps may include: the first application calling a query interface to check whether there is an event 2 requiring immediate processing in queue 1. The query interface may be configured by the operating system. For example, the query interface may be an Application Programming Interface (API). One possible scenario is that after the operating system creates an event queue for the first application, it exposes the query interface to the first application, allowing the first application to query whether there are events requiring immediate processing in the queue. Optionally, different applications may use the same or different query interfaces. For example, the first application might use query interface 1, and the second application might use query interface 2, thus preventing information leakage from the applications.

[0132] As mentioned above, event 1 can include multiple sub-events. As one possible implementation, event 1 is split into multiple sub-events. Optionally, the splitting process of event 1 can occur before or after event 1 is enqueued. Taking the case of event 1 being enqueued before enqueuing as an example, after the event thrower generates event 1, it splits event 1 into multiple sub-events, and then throws the split event 1 into multiple sub-events into the event queue of the first application. Taking the case of event 1 being enqueued after enqueuing as an example, for instance, after the first application retrieves event 1 from the event queue, it splits event 1 into multiple sub-events, and then performs a detection step once between each pair of adjacent sub-events.

[0133] Optionally, events can be split by function or by duration.

[0134] Taking functional decomposition as an example, each of the resulting sub-events is used to perform a different function. Taking Event 1 (database access event) from Application Scenario 1 as an example, Event 1 is used to retrieve information from the database about various applications on the electronic device. Therefore, Event 1 can be decomposed into multiple sub-events, each used to retrieve information from one or more applications; for example, each sub-event might retrieve information from three applications. Similarly, taking Event 1 (server access event) from Application Scenario 2 as an example, Event 1 is used to retrieve information from the server, such as news. Therefore, Event 1 can be decomposed into multiple sub-events, each used to retrieve one or more news items; for example, each sub-event might retrieve three news items.

[0135] Taking the splitting by duration as an example, for instance, the processing time of each sub-event in the multiple sub-events obtained by splitting is the same, which is T / N, where T is the total processing time of event 1.

[0136] In the above embodiment, the example mainly illustrates that the event queue of the first application includes two queues. It is understood that the event queue of the first application may include more queues, such as three queues, five queues, etc. For an example, please refer to [link to example]. Figure 10 The first application's event queue consists of five queues, numbered 1 to 5. Each queue corresponds to a different priority, with the priority decreasing from queue 1 to queue 5. Table 1 below illustrates the priorities of the five queues and the types of events to be processed stored in each queue.

[0137] Table 1: Priority and event type of the event queue in the first application

[0138]

[0139] It should be noted that the event types in Table 1 above are merely examples and do not constitute a limitation on the embodiments of this application.

[0140] based on Figure 10 For the event queue of the first application shown, please refer to [link / reference]. Figure 11 This is another flowchart illustrating an event handling method provided in an embodiment of this application. This method can be applied to... Figure 10 The scene shown. (As shown) Figure 11 The method includes the following steps:

[0141] Step 1100: Determine the priority of the current event being processed, denoted as Prio.

[0142] Step 1101: Determine if the priority of the current event is VIP level. If it is, the current event cannot be interrupted; otherwise, proceed to step 1102.

[0143] Step 1102: Determine if the priority of the current event is immediate. If yes, proceed to step 1103; otherwise, proceed to step 1104.

[0144] Step 1103: Determine if there is an event in the VIP queue that exceeds 4ms. If so, the current event processing can be interrupted; otherwise, the current event processing cannot be interrupted.

[0145] Therefore, as can be seen from steps 1102 to 1103, if the current event being processed is at the immediate level, it means that it is not the highest priority. In this case, the first application needs to check whether there are any events that need to be processed in a higher priority queue (i.e., the VIP queue) (e.g., events with a waiting time of more than 4ms). If they exist, the current event processing is interrupted, and the events that need to be processed in a higher priority queue (i.e., the VIP queue) are processed in a timely manner. If they do not exist, the current event processing is not interrupted.

[0146] Step 1104: Determine if the priority of the current event is high. If yes, proceed to step 1105; otherwise, proceed to step 1107.

[0147] Step 1105: Determine if there is an event in the VIP queue that exceeds 4ms. If so, the current event processing can be interrupted; otherwise, proceed to step 1106.

[0148] Step 1106: Determine if there is an event in the immediate queue that exceeds 40ms. If so, the current event processing can be interrupted; otherwise, the current event processing cannot be interrupted.

[0149] Therefore, as can be seen from steps 1104 to 1106, if the current event being processed is at the high level, it means that it is not the highest priority. In this case, the first application needs to check whether there are any events that need to be processed in a higher priority queue (i.e., the VIP queue and the immediate level). If there are, the current event processing is interrupted, and the events that need to be processed in a higher priority queue (i.e., the VIP queue and the immediate level) are processed. If there are no such events, the current event processing is not interrupted.

[0150] It should be noted that when the current event being processed is at the "high" priority level, there are two queues with higher priority than "high": the VIP priority queue and the immediate priority queue. The application can first check if there are any events requiring immediate processing in the VIP priority queue (e.g., events with a wait time exceeding 4ms). If so, the current event processing is interrupted, and the event requiring immediate processing in the VIP queue is processed. If not, the application checks if there are any events requiring immediate processing in the immediate priority queue (e.g., events with a wait time exceeding 40ms). If so, the current event processing is interrupted, and the event requiring immediate processing in the immediate priority queue is processed. If not, the current event processing cannot be interrupted.

[0151] As mentioned earlier, if the first application detects an event (referred to as event a) in the VIP queue that requires immediate processing, it interrupts the current event processing and processes event a in the VIP queue. Optionally, after event a is processed, the first application can check if there is an event requiring immediate processing in the immediate-level queue. If not, it continues processing the unprocessed portion of the interrupted event. If it does exist, it processes the event requiring immediate processing in the immediate-level queue, and after that event is processed, it continues processing the unprocessed portion of the interrupted event.

[0152] Step 1107: Determine if the priority of the current event is low. If yes, proceed to step 1108; otherwise, proceed to step 1111.

[0153] Step 1108: Determine if there is an event in the VIP queue that exceeds 4ms. If so, the current event processing can be interrupted; otherwise, proceed to step 1109.

[0154] Step 1109: Determine if there is an event in the immediate queue that exceeds 40ms. If so, the current event processing can be interrupted; otherwise, proceed to step 1110.

[0155] Step 1110: Determine if there is an event in the high queue that exceeds 400ms. If so, the current event processing can be interrupted; otherwise, the current event processing cannot be interrupted.

[0156] Therefore, as can be seen from steps 1107 to 1110, if the current event being processed is at the low level, it means that it is not the highest priority. In this case, the first application needs to check whether there are any events that need to be processed in a higher priority queue (i.e., the VIP queue, the immediate level queue, and the high level queue). If there are such events, the current event processing is interrupted, and the events that need to be processed in a higher priority queue (i.e., the VIP queue, the immediate level queue, and the high level queue) are processed. If there are no such events, the current event processing is not interrupted.

[0157] Step 1111: Determine if the priority of the currently processed event is Idle. If yes, proceed to step 1112; otherwise, the currently processed event cannot be interrupted.

[0158] It should be noted that if the current event being processed is not one of the five levels mentioned above, then the current event processing should not be interrupted to avoid any exceptions in the first application.

[0159] Step 1112: Determine if there are events in other queues. If so, the current event processing can be interrupted; otherwise, the current event processing cannot be interrupted.

[0160] Therefore, if the currently processed event is an Idle-level event, then once an event is detected in another queue, the current processing of the event is interrupted, and the events in the other queues are processed. Optionally, when the currently processed event is an Idle-level event, the first application can check whether there is an event in the first four queues in descending order of priority. Once an event is detected in a queue, the current processing of the event is interrupted, and the detected event is processed.

[0161] Please see Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device can be one of the electronic devices mentioned above, such as a mobile phone. Figure 12 As shown, the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0162] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, memory, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). Different processing units may be independent devices or integrated into one or more processors. The controller may serve as the nerve center and command center of the electronic device. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Processor 110 may also include memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has just used or is recurring. If processor 110 needs to reuse an instruction or data, it can directly retrieve it from the memory. This avoids repeated access, reduces the waiting time of processor 110, and thus improves system efficiency.

[0163] In some embodiments, the processor 110 may execute the event handling method provided in the embodiments of this application. For example, when processing low-priority events, the processor 110 may detect whether there are high-priority events that need to be processed in a timely manner. If such events exist, the processor 110 may interrupt the currently processed low-priority events and process the high-priority events instead, thereby avoiding the high-priority events from being blocked and unable to be processed in a timely manner, and reducing the probability of application lag.

[0164] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0165] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0166] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0167] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0168] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0169] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to enable the electronic device 100 to capture images. The processor 110 and the display screen 194 communicate via the DSI interface to enable the electronic device 100 to display images.

[0170] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0171] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0172] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0173] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in conjunction with a tuning switch.

[0174] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in electronic devices. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0175] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0176] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the electronic device to communicate with networks and other devices via wireless communication technology.

[0177] The display screen 194 is used to display the application's interface, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device may include one or N display screens 194, where N is a positive integer greater than 1.

[0178] The electronic device 100 can perform shooting functions through an ISP, a camera 193, a video codec, a GPU, a display 194, and an application processor. The ISP is used to process the data fed back by the camera 193.

[0179] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 121. For example, processor 110 executes the event handling method provided in the embodiments of this application by running the instructions stored in internal memory 121. The program storage area can store the operating system and software code of at least one application. The data storage area can store data generated during the use of the electronic device (e.g., images, videos, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, general-purpose flash memory, etc.

[0180] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, images, videos, and other files can be saved on the external memory card.

[0181] Electronic devices can implement audio functions such as music playback and recording through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors.

[0182] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0183] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or listen to hands-free calls and other external playback scenarios through one or more speakers 170A.

[0184] The receiver 170B, also known as a "handpiece," can be one or more, and is used to convert audio electrical signals into sound signals. When the electronic device 100 answers a telephone call or voice message, the receiver 170B can be brought close to the ear to listen to the voice.

[0185] The microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0186] The 170D headphone jack is used to connect wired headphones.

[0187] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194.

[0188] The gyroscope sensor 180B can be used to determine the motion attitude of an electronic device. In some embodiments, the gyroscope sensor 180B can determine the angular velocity of the electronic device about three axes (i.e., the x, y, and z axes). The gyroscope sensor 180B can be used for image stabilization.

[0189] The barometric pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device calculates altitude using the air pressure value measured by the barometric pressure sensor 180C to assist in positioning and navigation.

[0190] The magnetic sensor 180D includes a Hall effect sensor. Electronic devices can use the magnetic sensor 180D to detect the opening and closing of a flip cover.

[0191] The 180E accelerometer can detect the magnitude of acceleration in various directions (typically three axes) of electronic devices. When the electronic device is stationary, it can detect the magnitude and direction of gravity.

[0192] The 180F distance sensor is used to measure distance. Electronic devices can measure distance using infrared or laser.

[0193] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. The electronic device emits infrared light outward through the LED. The electronic device uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that an object is near the electronic device. When insufficient reflected light is detected, the electronic device can determine that no object is near the electronic device.

[0194] An ambient light sensor 180L is used to detect ambient light levels. Electronic devices can adaptively adjust the brightness of the display screen 194 based on the detected ambient light levels.

[0195] The fingerprint sensor 180H is used to collect fingerprints.

[0196] The 180J temperature sensor is used to detect temperature.

[0197] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touch screen." Touch sensor 180K is used to detect touch operations applied to or near it. The touch sensor can then transmit the detected touch operation to the application processor to determine the type of touch event.

[0198] The bone conduction sensor 180M can acquire vibration signals. In some embodiments, the bone conduction sensor 180M can acquire vibration signals from the vibrating bone segments of the human vocal cords.

[0199] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch buttons. The electronic device can receive button inputs and generate key signal inputs related to user settings and function control. Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to achieve contact and separation with the electronic device.

[0200] Understandable Figure 12 The components shown do not constitute a specific limitation on the electronic device. The electronic device in the embodiments of the present invention may include, but is not limited to, components that are more advanced than those shown. Figure 12 More or fewer parts. Furthermore, Figure 12 The combination / connection relationships between the components can also be adjusted and modified.

[0201] Figure 13 This is a schematic diagram of the structure of the electronic device 1300 provided in an embodiment of this application. The electronic device 1300 can be one of the electronic devices described above, such as a mobile phone. Figure 13As shown, electronic device 1300 may include: one or more processors 1301; one or more memories 1302; a communication interface 1303; and one or more computer programs 1304. These components can be connected via one or more communication buses 1305. The one or more computer programs 1304 are stored in the memory 1302 and configured to be executed by the one or more processors 1301. The one or more computer programs 1304 include instructions. For example, when electronic device 1300 is the electronic device described above, these instructions can be used to perform relevant steps of the electronic device as described in the corresponding embodiments above. The communication interface 1303 is used to enable communication between electronic device 1300 and other devices; for example, the communication interface may be a transceiver.

[0202] Based on the above, this application also provides a computer-readable storage medium storing instructions that, when executed, cause the method provided in any of the above-described method embodiments to be implemented. The computer-readable storage medium may include various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0203] Based on the above, this application also provides a computer program product, which includes: a computer program (also referred to as code or instructions), which, when run on a computer, causes the computer to perform the method provided in any of the above method embodiments. Optionally, the computer can be a terminal device, such as a mobile phone.

[0204] In the embodiments provided above, the methods provided by the embodiments of this application are described from the perspective of an electronic device (e.g., a mobile phone) as the executing entity. To implement the functions of the methods provided in the embodiments of this application, the electronic device may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is implemented in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.

[0205] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)). Where there is no conflict, the solutions in the above embodiments can be combined.

[0206] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0207] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0208] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0209] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0210] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope and intent of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. An event handling method, characterized in that, The method is applied to an electronic device, the electronic device including a first application, the first application having an event queue including a first queue and a second queue, the first queue and the second queue being used to store pending events of the first application, and the first queue having a higher priority than the second queue. Process the first event in the second queue, the first event being used to retrieve the display elements within the target interface of the first application; During the processing of the first event, it is checked whether there is a second event in the first queue that needs to be processed in a timely manner. The second event is a UI refresh event. If a second event requiring immediate processing is detected in the first queue, the processing of the first event is interrupted, and the second event is processed based on the processed portion of the first event; wherein, the processed portion of the first event includes the first display element that has been acquired, and the processing of the second event based on the processed portion of the first event includes: displaying a first interface based on the first display element, wherein the first interface includes the first display element, and the first display element is a portion of the display elements within the target interface; After the second event is processed, a third event is processed. The third event includes the unprocessed part of the first event. The third event is used to obtain a second display element in the target interface. The second display element is other display elements in the target interface besides the first display element. During the processing of the third event, a fourth event that needs to be processed in a timely manner is detected in the first queue. The fourth event is a UI refresh event. If the processing time of the third event is less than a threshold, then after processing the third event, the fourth event is processed according to the processing result of the third event; wherein, the processing result of the third event includes the acquired second display element, and processing the fourth event according to the processing result of the third event includes: refreshing the second interface according to the second display element, wherein the second interface includes the first display element and the second display element, and the first display element and the second display element are all or part of the display elements in the target interface.

2. The method according to claim 1, characterized in that, Before interrupting the processing of the first event, the method further includes: It is determined that the total processing time of the first event exceeds the second duration, and / or, the processing time of the first event exceeds the third duration.

3. The method according to claim 1, characterized in that, Before processing the third event, the method further includes: A third event is generated based on the unprocessed portion of the first event, and the third event enters the first queue or the second queue to await processing.

4. The method according to claim 3, characterized in that, When the third event enters the second queue, the third event is located at the head of the second queue.

5. The method according to claim 1, characterized in that, The first event includes N sub-events, where N is an integer greater than or equal to 2. During the processing of the first event, detecting whether there is a second event in the first queue that needs to be processed promptly includes: In the N sub-events, a detection step is performed once during the processing interval between every two adjacent sub-events. The detection step is used to detect whether there is a second event in the first queue that needs to be processed in a timely manner. The processing interval includes the time period from the end time of the processing of the previous sub-event to the start time of the processing of the next sub-event.

6. The method according to claim 5, characterized in that, The N sub-events are the N sub-events obtained by dividing the first event according to function or duration; wherein, each of the N sub-events obtained by dividing according to function is used to implement different functions, and the processing time of each of the N sub-events obtained by dividing according to duration is T / N, where T is the total processing time of the first event.

7. The method according to any one of claims 1-6, characterized in that, The event queue further includes a third queue, the third queue having a higher priority than the first queue, and the method further includes: During the processing of the second event, it is checked whether there is a fifth event in the third queue that needs to be processed in a timely manner; If a fifth event requiring immediate processing is detected in the third queue, the processing of the second event is interrupted, and the fifth event is processed.

8. The method according to any one of claims 1-6, characterized in that, The event queue also includes a fourth queue, which has a higher priority than the first queue. During the processing of the first event, it checks whether there is a second event in the first queue that needs to be processed promptly, including: During the processing of the first event, it is checked whether there is a sixth event that needs to be processed in a timely manner in the fourth queue; If there is no sixth event that needs to be processed in a timely manner in the fourth queue, then check if there is a second event that needs to be processed in a timely manner in the first queue.

9. The method according to claim 8, characterized in that, The method further includes: If there is a sixth event in the fourth queue that needs to be processed in a timely manner, then the first event is interrupted and the sixth event is processed. After the sixth event is processed, check if there is a second event in the first queue that needs to be processed in a timely manner; If a second event that requires immediate processing is detected in the first queue, then the second event is processed.

10. The method according to claim 1, characterized in that, The method further includes: If the processing time of the third event is greater than or equal to the threshold, the processing of the third event is interrupted, and the fourth event is processed according to the processed portion of the third event.

11. The method according to claim 1, characterized in that, The first event is used to retrieve the display elements within the target interface from a local database or server.

12. An electronic device, characterized in that, Used to perform the method as described in any one of claims 1-11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 11.

14. A computer program product, characterized in that, Includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 11.

Images