Event distribution method and electronic equipment

Abstract

The invention discloses an event distribution method and electronic equipment, relates to the technical field of computers, and aims at enabling an input equipment node of a second operating system to directly acquire an input event, and enabling a first operating system and the second operating system to respectively perform distribution processing on the input event directly acquired by the input equipment node based on window information. The conversion and transmission steps are reduced, the event distribution process is simplified, the input event distribution efficiency and response speed are improved, and the user interaction experience is improved. In the method, a first operating system maps an input device node to a second operating system. And the first operating system sends the window information of the application window on the electronic equipment to the second operating system. In response to an input operation, an input device node of a first operating system and an input device node of a second operating system acquire an input event. And the first operating system and the second operating system perform distribution processing on the obtained input event based on the window information.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to an event distribution method and an electronic device. Background Technology

[0002] Among numerous electronic devices, the following is adopted: as well as These operating systems are found on a large number of devices. With the diversification of intelligent devices, the emergence of numerous operating system platforms such as wearable systems, in-vehicle systems, and smart home systems has exacerbated the fragmentation of the operating system ecosystem. This fragmentation leads to inconsistencies in user experience and makes compatibility issues between heterogeneous systems increasingly prominent. As the most fundamental part of the operating system and the part where users directly interact, the performance and efficiency of the input subsystem have a significant impact on user experience.

[0003] In existing technologies, to achieve the integration of input subsystems between heterogeneous systems, when the guest operating system boots up, the host operating system creates a virtualized input node within the guest operating system via a heterogeneous system compatibility dock. After receiving input events, the host operating system distributes the input events to the application layer, performs coordinate transformation and protocol encapsulation, and then sends the processed input events to the guest operating system through the virtualized input node, where subsequent distribution is completed.

[0004] In other words, the entire process of input events being captured by the Host operating system, passed to the application layer, and then converted and injected into the Guest operating system for distribution requires multiple transmissions and conversions. This results in long response times for input event distribution, poor responsiveness, and other issues that negatively impact the user's interactive experience. Summary of the Invention

[0005] This invention proposes an event distribution method and an electronic device. A first operating system in the electronic device maps input device nodes to a second operating system in the electronic device and sends window information to the second operating system. This enables the input device nodes of the second operating system to directly obtain input events. Furthermore, the first and second operating systems can distribute and process the input events directly obtained by the input device nodes based on the window information. This reduces conversion and transmission steps, simplifies the event distribution process, improves the efficiency and response speed of input event distribution, and enhances the user interaction experience.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] Firstly, an event dispatch method is provided, applied to an electronic device including a first operating system and a second operating system. In this method, the first operating system maps input device nodes to the second operating system. Furthermore, the first operating system sends window information of application windows on the electronic device to the second operating system. In response to an input operation, the input device nodes of both the first and second operating systems acquire input events. Subsequently, the first and second operating systems, respectively, dispatch and process the acquired input events based on the window information.

[0008] In the aforementioned event distribution method, the first operating system maps input device nodes to the second operating system, allowing both systems to directly access input events. Furthermore, the first operating system sends window information of the application window on the electronic device to the second operating system. Based on this window information, both the first and second operating systems perform their respective event distribution processes. During event distribution in the second operating system, it is unnecessary to first pass the input event to the application layer through the first operating system for coordinate transformation, protocol encapsulation, and other processing before injecting it into the second operating system for event distribution. This eliminates multiple transformations and transmissions between the first and second operating systems, shortening the event distribution process, reducing response time, and improving the user experience.

[0009] Furthermore, since the first operating system does not need to perform coordinate transformation and protocol encapsulation on the input events before sending them to the second operating system during the event distribution process, the CPU does not need to perform these processes. Moreover, the first operating system discards the input event if it determines that the input event does not correspond to its own, and then becomes inactive. Therefore, CPU resource consumption is reduced, thereby lowering device power consumption and enhancing battery life.

[0010] In one possible implementation, in response to an input operation, the input device nodes of the first operating system and the second operating system acquire the input event through a hardware driver.

[0011] In this implementation, the second operating system can directly obtain input events through hardware drivers and input device nodes, eliminating the need for multiple conversions or transmissions within the first operating system and between the first and second operating systems. This shortens the event distribution process, reduces the response time of event distribution, improves event distribution efficiency, and enhances the user interaction experience.

[0012] In one possible implementation, the second operating system and the first operating system are heterogeneous systems. The second operating system dispatches and processes input events based on window information, and this process is performed in parallel with the first operating system's dispatching and processing of input events based on window information.

[0013] In this implementation, the first and second operating systems each distribute and process the acquired input events based on window information, ensuring that input events are correctly distributed to the target application. Simultaneously, the second operating system's distribution and processing of input events based on window information runs in parallel with the first operating system's distribution and processing. This simultaneous distribution eliminates the complex process of multiple conversions and transfers between the first and second operating systems before finally injecting the data into the second operating system for distribution, shortening the event distribution process, reducing response time, improving efficiency, and enhancing the user experience.

[0014] In one possible implementation, during the distribution and processing of acquired input events based on window information by the first operating system and the second operating system, the first operating system, based on the window information of the application window on the electronic device, determines that the input event corresponds to the first operating system and then distributes the input event to the target application in the first operating system. Similarly, the second operating system, based on the window information, determines that the input event corresponds to the second operating system and then distributes the input event to the target application in the second operating system. Furthermore, the electronic device performs a response operation on the input event through the target application.

[0015] In this implementation, window information describes the state information of each application window on the electronic device. Based on the window information, the corresponding operating system is determined to distribute input events, ensuring that input events are correctly distributed to the corresponding application window and the appropriate target application. This allows the electronic device to correctly respond to user input operations, enhancing the user experience.

[0016] In one possible implementation, during the distribution and processing of acquired input events based on window information by the first operating system and the second operating system, if the first operating system determines that the input event does not correspond to the first operating system based on the window information of the application window on the electronic device, it discards the input event. If the second operating system determines that the input event does not correspond to the second operating system based on the window information, it discards the input event.

[0017] In this implementation, after an input event is acquired, the first and second operating systems determine, based on the window information, whether the input event corresponds to their respective operating systems. If they do not correspond, the input event is discarded, and the electronic device does not respond. This prevents erroneous event distribution and ensures the accuracy of user interaction.

[0018] In one possible implementation, during the process of the first operating system sending the window information of the application window on the electronic device to the second operating system, the first operating system sends the full window information of the application window on the electronic device to the second operating system; when the application window on the electronic device changes, the first operating system sends the incremental window information corresponding to the changed window to the second operating system.

[0019] In this implementation, window synchronization ensures that the window states of two operating systems remain consistent. Incremental window information is synchronized only when the window state changes, and the amount of incremental window information is relatively small. This allows for real-time and rapid synchronization of application window states across electronic devices through the synchronization of a small amount of incremental window information at a time.

[0020] In one possible implementation, during the process of the first operating system sending the full window information of the application windows on the electronic device to the second operating system, the first operating system sends the full window information to the second operating system when the second operating system starts, restores, or unfreezes.

[0021] In this implementation, when the second operating system starts, it may not have previously obtained the application window information, or the second operating system may have not been running for a long time when it is restored or unfrozen. In such cases, the window states obtained by the first and second operating systems may differ significantly. In these situations, the first operating system sends all the application window information to the second operating system. Window synchronization ensures that the window states remain consistent between the two operating systems.

[0022] In one possible implementation, during the process of determining whether an input event corresponds to the second operating system based on window information, when the input event is a keyboard key event, the second operating system determines that the first application window corresponding to the focused window belongs to the second operating system, thus determining that the input event corresponds to the second operating system. Here, the application to which the first application window belongs is the target application. When the input event is an interactive position event, the second operating system determines, based on window information, that among multiple application windows stacked on the electronic device, the second application window belongs to the second operating system, and is the application window whose position range includes the trigger position of the input event and whose stacking z-order is the highest, thus determining that the input event corresponds to the second operating system. Here, the application to which the second application window belongs is the target application.

[0023] In this implementation, the interaction location of keyboard key events can be determined based on the focused window, thereby ensuring that keyboard key input is accurately distributed to the correct operating system and enhancing the user experience. Furthermore, by determining the trigger location of the input event, the application window corresponding to the trigger location can be accurately identified, and the input event can be distributed to the correct operating system, further enhancing the user experience.

[0024] In one possible implementation, window information includes multiple types of window metadata. During the process of determining whether an input event corresponds to the second operating system based on the window information, the second operating system determines the target event type corresponding to the input event, and the target data type of the window metadata corresponding to the target event type. Then, the second operating system determines whether the input event corresponds to the second operating system based on the window metadata corresponding to the data type in the window information.

[0025] In this implementation, input events are categorized into types such as keyboard key events and interactive position events. Different event types are then distributed and processed differently to ensure that input events are accurately distributed to the corresponding operating system according to their type. This optimizes the event processing flow and improves event distribution efficiency and user experience.

[0026] In one possible implementation, if the target event type is a keyboard key event, the target data type of the corresponding window metadata includes focus metadata and type metadata. The focus metadata indicates whether the application window is the focused window, and the type metadata indicates the operating system to which the application window belongs. Alternatively, if the target event type is an interactive position event, the target data type of the corresponding window metadata includes position metadata and hierarchy metadata. The position metadata indicates the position range of the application window, and the hierarchy metadata indicates the stacking information of the application windows.

[0027] In one possible implementation, during the process of the second operating system determining whether an input event corresponds to the first operating system based on the window metadata corresponding to the data type in the window information, when the input event is a keyboard key event, the second operating system determines, based on the focus metadata and type metadata in the window information, that the application window corresponding to the focus window belongs to the second operating system, thus determining that the input event corresponds to the second operating system; and the application to which the first application window belongs is the target application. When the input event is an interactive position event, the second operating system determines, based on the position metadata and hierarchy metadata in the window information, that among the multiple application windows stacked on the electronic device, the second application window belongs to the second operating system, and the second application window is the application window whose position range includes the trigger position of the input event and whose stacking z-order is the highest, thus determining that the input event corresponds to the second operating system; and the application to which the second application window belongs is the target application.

[0028] In this implementation, based on focus metadata and type metadata, the second operating system can accurately distribute keyboard key events to the correct target application, enhancing the user experience. Furthermore, utilizing location metadata and hierarchy metadata, the second operating system accurately identifies and processes interactive location events, ensuring that input events are distributed to the correct target application, further enhancing the user experience.

[0029] In one possible implementation, the first operating system is the host operating system, and the second operating system is the guest operating system. The host operating system and the guest operating system are different types of operating systems.

[0030] In a second aspect, an electronic device is provided, comprising: a memory and one or more processors; the memory and the processors are coupled; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the event dispatch method described in any of the first aspects above.

[0031] Thirdly, a computer-readable storage medium is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform the event dispatch method described in any of the first aspects above.

[0032] Fourthly, a computer program product is provided that, when run on a computer, causes the computer to execute the event dispatching method described in any of the first aspects above.

[0033] The technical effects of any of the design methods in the second to fourth aspects can be found in the technical effects of different design methods in the first aspect, and will not be repeated here. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of a window arrangement method.

[0035] Figure 2 This is a schematic diagram of an event distribution method in related technologies;

[0036] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0037] Figure 4 A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0038] Figure 5 This is a schematic diagram illustrating an event distribution method provided in an embodiment of this application;

[0039] Figure 6 This application provides a schematic diagram of an event distribution process as an embodiment of the present application.

[0040] Figure 7 A schematic diagram illustrating a window information sending scenario provided in an embodiment of this application;

[0041] Figure 8 This is a schematic diagram of a window collaboration method provided in an embodiment of this application;

[0042] Figure 9 A schematic diagram illustrating an input event acquisition method provided in an embodiment of this application;

[0043] Figure 10 This is a schematic diagram illustrating a window arrangement method provided in an embodiment of this application;

[0044] Figure 11 This is a schematic diagram illustrating an event distribution method provided in an embodiment of this application;

[0045] Figure 12 This is a schematic diagram illustrating a two-level distribution method provided in an embodiment of this application;

[0046] Figure 13 This application provides a schematic diagram of an event distribution process.

[0047] Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0048] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0049] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0050] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0051] In the current technological ecosystem, as well as Operating systems have become the mainstream platform for smart devices. However, with the increasing variety of smart devices, such as wearable devices, in-vehicle systems, and smart home devices, the emergence of new operating system platforms often necessitates running multiple operating systems to meet diverse user needs, leading to fragmentation of the operating system ecosystem. This fragmentation reduces the consistency of user experience when switching between different operating systems, and compatibility issues between operating systems are becoming increasingly prominent. This is particularly true for the input subsystem, the core component for direct user interaction; its performance and efficiency directly impact the user experience. The input subsystem manages various input devices (such as keyboards, mice, and touchscreens). The device driver layer of the input subsystem is responsible for the driver implementation of specific devices, such as keyboards, mice, and touchscreens.

[0052] The stacking methods of application windows vary across different device types and operating systems, including cascading windows, stacked displays, and side-by-side displays. Cascading windows indicate that all open windows are arranged in a regular stacked manner. Stacked displays indicate that all open windows are displayed horizontally on the screen. Side-by-side displays indicate that all open windows are displayed vertically on the screen. See also... Figure 1 , Figure 1 (a) can be represented as a stacked window. Figure 1 (b) in the text can be represented as a stacked display. Figure 1 (c) in the diagram can be represented as side-by-side display. Therefore, the coexistence of multiple operating systems faces the problem of distributing input events from shared hardware input devices, requiring input events to be distributed to the corresponding applications in the respective operating systems.

[0053] To address the aforementioned issues, related technologies typically employ a heterogeneous system compatibility dock to virtualize input nodes (input device nodes) for event distribution. This compatibility dock provides an isolated runtime environment for the operating system, offering an underlying architecture that supports compatibility across different hardware or software environments, allowing multiple operating systems to coexist on the same hardware. For example, a second operating system runs on the compatibility dock, interacting with hardware resources through the application programming interface (API) provided by the first operating system to allocate and manage these resources. The compatibility dock can create virtualized input nodes within the second operating system using containers or virtual machines. For example, the first operating system (such as...) This virtualization input node manages hardware resources and runs a second operating system (such as Linux) on a compatible dock (such as a container). Through the dock, the second operating system can interact with the hardware resources. This virtualization input node acts as a bridge for the first operating system to send input events to the second operating system. The existence of a virtualization input node can be determined by checking if a socket file exists in the second operating system or by using specific command-line tools (such as virsh, vmstat, etc.). For example, in a Linux operating system, the socket file can be located in the / var / or / tmp / directory; if a socket file is found, the existence of a virtualization input node is confirmed.

[0054] Specifically, when the second operating system boots, a virtualized input node is created within it via a compatibility dock. After receiving input events, the first operating system distributes them to the application layer, which then processes them to convert the input events from the first operating system into events that the second operating system can understand and process. For example, the first operating system is... Operating system, the second operating system is The operating system, on the other hand, needs to transfer input events from... The events that the operating system can understand and process are converted into The operating system can understand and process events. For example, after the application layer receives an input event, it performs coordinate mapping and protocol encapsulation on the input event. Then, the processed input event is passed to the second operating system through a virtualized input node for further distribution. The input event transmission process includes: being captured in the first operating system, then passed to the application layer, undergoing mapping and encapsulation, and finally being sent to the second operating system through a virtualized input node for further distribution.

[0055] For example, see Figure 2 During event dispatch, the first operating system receives input events through input device nodes (such as / dev / input / eventX), then reports them to application layer 1 after event reading, dispatch, and lifecycle management. After window management, the input events undergo coordinate transformation, protocol encapsulation, and other processing. The first operating system then sends the processed input events to the second operating system through virtualized input nodes. The second operating system reads the events through virtualized input nodes and then dispatches them to the target application in application layer 2. Figure 2 As shown by the arrow, the entire event distribution process is shaped like an N. Input events need to be reported from the first operating system to application layer 1, then converted and sent to the second operating system, and then distributed to the target application in application layer 2.

[0056] This shows that in related technologies, after an input event is received by the first operating system, it needs to go through multiple steps: transmission to the application layer, coordinate transformation, protocol encapsulation, inter-system transmission, and redistribution. This results in a prolonged response time for event distribution. Users may experience a noticeable delay and poor responsiveness in actual operation. This is particularly evident in sensitive scenarios such as games that require fast responses, or in applications that require precise operations, significantly impacting the user's interactive experience.

[0057] Meanwhile, in the aforementioned complex event distribution process, both the first and second operating systems need to be active. Even if the input event does not belong to the first operating system, it still needs to remain active to process, transform, encapsulate, or transmit the input event before sending it to the second operating system. Furthermore, this process consumes significant CPU resources for transmitting, transforming, and distributing input events, increasing device power consumption and significantly reducing battery life.

[0058] In view of this, embodiments of this application provide an event distribution method applied to an electronic device. A first operating system maps an input device node to a second operating system. Furthermore, the first operating system sends window information of an application window on the electronic device to the second operating system. In response to an input operation, the input device nodes of the first and second operating systems acquire the input event. Subsequently, the first and second operating systems respectively distribute the acquired input event based on the window information.

[0059] The aforementioned input events characterize signals generated when a user interacts with an electronic device. These signals are captured and transmitted to the operating system via hardware devices (such as touchscreens, keyboards, and mice). For example, input events can be touchscreen events, keyboard events, and mouse events. The aforementioned input device nodes enable the operating system to directly access hardware resources and receive input events. In this embodiment, in response to an input operation, both the first and second operating systems can directly obtain input events through the input device nodes.

[0060] For example, when an electronic device responds to a user inputting characters via a keyboard, the keyboard event is acquired by a first operating system and a second operating system through the input device node. The first and second operating systems then distribute and process the input event based on window information, respectively.

[0061] For example, an electronic device responds to a user's mouse click on the screen. This mouse click event is then received by both the first and second operating systems via the input device node. The first and second operating systems then distribute and process the input event based on window information.

[0062] For example, an electronic device responds to a user swiping their finger on a touchscreen to control the movement of a character in a game. Touchscreen swipe events are input events, which are acquired by a first operating system and a second operating system through input device nodes. The first and second operating systems then distribute and process the input events based on window information.

[0063] In this scheme, the first operating system maps input device nodes to the second operating system, allowing input device nodes in both systems to directly access input events. Furthermore, the first operating system sends window information of the application window on the electronic device to the second operating system. Based on this window information, the second and first operating systems each perform their own distribution processing of input events. During event distribution in the second operating system, it is unnecessary to first pass the input events to the application layer through the first operating system for coordinate transformation, protocol encapsulation, and other processing before injecting them into the second operating system for event distribution. This eliminates multiple transformations and transmissions between the first and second operating systems, shortening the event distribution process, reducing response time, and improving the user experience.

[0064] Meanwhile, since the first operating system does not need to perform coordinate transformation and protocol encapsulation on the input events before sending them to the second operating system during the event distribution process, the CPU does not need to perform these processes. Furthermore, if the first operating system determines that an input event does not correspond to a specific operating system, it discards the input event and then enters an inactive state, such as hibernation or sleep, a low-power state. Therefore, CPU resource consumption is reduced, thereby lowering device power consumption and enhancing device battery life.

[0065] The electronic devices in this application embodiment can be tablet computers, mobile phones, laptops, smart screens, televisions, in-vehicle devices, netbooks, personal digital assistants (PDAs), wearable devices, smart home devices, augmented reality (AR) / virtual reality (VR) devices, or personal computers, etc. This application embodiment does not impose any special limitations on the specific form of the electronic devices.

[0066] For example, the first operating system and the second operating system in the embodiments of this application may include, but are not limited to: Alternatively, other operating systems may be used. It should be noted that this application embodiment does not impose any special limitations on either the first or second operating system.

[0067] For example, the communication methods between the first and second operating systems in this embodiment include various inter-process communication (IPC) mechanisms to ensure efficient and reliable data transmission. For instance, IPC mechanisms may include: pipes (including unnamed pipes and named pipes), message queues (message-passing mechanisms such as message queues, MQ), shared memory, and socket communication (network programming interface). This embodiment does not impose special limitations on the communication methods between heterogeneous systems.

[0068] The following are Figure 3 The hardware structure of the electronic device 100 having a first operating system and a second operating system is illustrated by way of example. Figure 3 This paper illustrates a hardware structure diagram of an electronic device 100 provided in an embodiment of this application.

[0069] like Figure 3 As shown, the electronic device 100 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.

[0070] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0071] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0072] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0073] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0074] 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.

[0075] In this embodiment of the application, the processor 110 is used to receive input events and map input device nodes to the second operating system, thereby enabling the second operating system to directly receive input events through the input device nodes.

[0076] The wireless communication function of electronic device 100 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 electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0077] In this embodiment of the application, the electronic device 100 can realize functions such as data transmission through antenna 1, antenna 2, mobile communication module 150, and wireless communication module 160.

[0078] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0079] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0080] In this embodiment, the display screen 194 can display an application window on an electronic device.

[0081] The electronic device 100 can implement 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, and the camera 193 is used to capture still images or videos. In some embodiments, the electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0082] 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 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0083] 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 electronic device 100 by running the instructions stored in internal memory 121.

[0084] In this embodiment of the application, the processor 110 can determine the operating system corresponding to the input event by running instructions stored in the internal memory 121, such as determining that the first application window corresponding to the focus window belongs to the second operating system, or determining that the second application window belongs to the second operating system among multiple application windows stacked on the electronic device.

[0085] The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). Furthermore, the 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, universal flash storage (UFS), etc.

[0086] Electronic device 100 can implement audio functions, such as music playback and recording, through the speaker, receiver, microphone, headphone jack, and application processor in audio module 170.

[0087] 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 detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0088] In this embodiment, the electronic device can detect touch operations on the touch screen composed of touch sensor 180K and display screen 194, thereby receiving input events (corresponding to touch operations).

[0089] In some embodiments, in addition to a touchscreen, the electronic device 100 may also include other input devices such as a mouse, keyboard, or stylus. The keyboard or mouse may also exist as an external component, connected to the electronic device via a physical connection (such as a USB or PS / 2 interface). The processor 110 of the electronic device can be used to receive input events from consumer operations on the electronic device 100 via input devices such as a mouse or keyboard.

[0090] based on Figure 3When the electronic device 100 implements the event distribution method in this embodiment, the display screen 194 displays an application window. The processor 110 acquires the input event corresponding to the touch screen (or input device such as a mouse or buttons) and maps the input device node to the second operating system. The first operating system sends the window information of the application window on the electronic device to the second operating system through inter-process communication or other means. By running instructions stored in the internal memory 121, the processor 110 can determine that the first application window corresponding to the focus window belongs to the second operating system, or determine that the second application window where the input position is located belongs to the second operating system among multiple application windows stacked on the electronic device. Then, by running instructions stored in the internal memory 121, the processor 110 controls the first and second operating systems to distribute and process the acquired input events based on the window information.

[0091] The electronic device 100 provided in this application embodiment can run an operating system (OS). This operating system can be various operating systems used in the industry, such as an operating system based on OpenHarmony, such as HarmonyOS; or other operating systems such as Android. TM iOS TM A mobile operating system can also refer to various open-source operating systems or their derivatives, such as Linux OS and other embedded operating systems; it can also be a future type of operating system, such as an AI operating system based on artificial intelligence. An operating system is a set of interconnected system software programs that manage and control the operation of electronic devices, utilize and run hardware and software resources, and provide public services to organize user interaction. In electronic devices, the operating system connects downwards to the physical devices at the hardware layer and upwards to provide a runtime environment for application software.

[0092] An operating system typically includes a kernel layer, a middleware layer, and an application layer. The application layer includes applications, which can include system applications and third-party applications. The middleware layer includes a suite of software providing various services to application developers, or frameworks providing services such as databases, multimedia, and graphics, or capabilities such as distributed scheduling and system expansion. For example, the middleware layer may include a framework layer, a system service layer, or a hardware abstraction layer. The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The system service layer includes the core capabilities of the system, providing services to applications through the framework layer. The hardware abstraction layer is an abstraction layer between the hardware and upper layers, providing a unified interface to the upper layers. The kernel layer is the layer between hardware and software. The kernel layer may include hardware drivers and the operating system kernel. In addition to providing hardware drivers, the kernel layer also supports functions such as memory management and system process management.

[0093] Because electronic devices vary in type and form, and are used in a wide range of scenarios, the operating systems used in these devices may differ depending on their form and function, application scenarios, and user needs. The basic functions implemented by the electronic device provided in this application can be implemented using a general-purpose operating system or a dedicated operating system. To more clearly illustrate the implementation of the embodiments of this application under a specific operating system, the software structure of the electronic device 100 is shown below.

[0094] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses the layered Harmony system as an example to exemplify the software structure of electronic device 100. Those skilled in the art can deduce implementations of this application embodiment under other specific operating systems, such as Android. TM Implementation under operating systems, etc.

[0095] Figure 4 This provides a schematic diagram of the software structure of the electronic device 100 in the embodiments of this application.

[0096] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Harmony system includes an application layer, a framework layer, a hardware abstraction layer (HAL), and a kernel layer. System functions can be tailored, added, or combined at the subsystem level in deployment scenarios with different device configurations, and each subsystem can also be tailored, added, or combined at the functional granularity level.

[0097] The application layer can include a series of application packages.

[0098] like Figure 4 As shown, applications can include system apps and extended / third-party apps. System apps can include the desktop, control bar, settings, contacts, phone, camera, etc., while extended / third-party apps can include social apps, travel apps, etc.

[0099] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. For example, the framework layer includes: the ArkUI framework (which provides a complete infrastructure for UI development of system applications, including UI functions such as components, layouts, animations, and interactive events, as well as a real-time interface preview tool), the user application framework, the Ability framework (an Ability is a lightweight application; the Ability framework schedules and manages the operation and lifecycle of Abilities), a distribution module, a window synchronization module, and an event arbitration module. Different devices may run different operating systems, and therefore support different APIs.

[0100] The HarmonyOS API is a series of open capabilities provided to support HarmonyOS application development. The HarmonyOS API can be set at the framework layer or independently of the framework layer. The HarmonyOS API includes the Audio API (audio service), Push API (push service), and Account API (account service), among others.

[0101] ArkUI provides a complete infrastructure for UI development of system applications, including UI functions (such as components, layouts, animations, and interactive events) and real-time interface preview tools. The ArkUI framework provides at least two development paradigms, including a declarative development paradigm based on ArkTS (referred to as "declarative development paradigm") and a JS-compatible web-like development paradigm (referred to as "web-like development paradigm").

[0102] An application framework is a programming framework that can be an implementation of an application model. Developers can use an application framework to implement the structure and behavior of an application based on the application model. An application model is a model of an application used to represent different aspects of the application, such as application components, process models, thread models, task management, and package management. The application model provides a unified language and architecture for describing various aspects of the application.

[0103] The Ability framework enables the scheduling and management of the operation and lifecycle of Abilities (meta-capabilities). An Ability is a fundamental component of an application, the smallest unit for system-scheduled applications, and a component capable of performing an independent function. An application can contain one or more Abilities.

[0104] Abilities are divided into two types: FA (Feature Ability) and PA (Particle Ability). An application can consist of one or more FAs or PAs. FAs have a user interface (UI) and provide the ability to interact with the user; while PAs do not have a UI and provide the ability to run background tasks and a unified data access abstraction.

[0105] The distribution module is used to enable the first and second operating systems to distribute the acquired input events to the target application based on window information.

[0106] The window synchronization module is used to synchronize the window information of application windows on the electronic device from the first operating system to the second operating system.

[0107] The event arbitration module is used to enable the first and second operating systems to determine the operating system corresponding to the input event and the target application to which the application window belongs.

[0108] For example, based on the framework layer, the electronic device 100 can implement the following: the first operating system sends the window information of the application window on the electronic device to the second operating system, determines that the first application window corresponding to the focus window belongs to the second operating system, or determines that among the multiple application windows stacked on the electronic device, the second application window belongs to the second operating system, and the operating system corresponding to the input event, thereby distributing the input event to the target application.

[0109] The application layer and framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0110] The hardware abstraction layer is an abstraction layer between the hardware and the upper layers. It provides a unified interface to the upper layers, so that upper-layer applications do not need to know how the lower-layer hardware works, thus shielding the underlying implementation details.

[0111] The Hardware Abstraction Layer (HAL) provides standard interfaces to expose device hardware functionality to higher-level framework layers. The HAL contains multiple library modules, each implementing an interface for a specific type of hardware component. These library modules may include acquisition modules, mapping modules, etc. When the framework layer requests access to the device hardware, the system loads the corresponding library module for that hardware component. Vendors can define interfaces within the HAL.

[0112] The acquisition module is used to receive input events from hardware devices.

[0113] The mapping module is used to map the input device nodes of the first operating system to the second operating system, so that the input device nodes of the first operating system and the input device nodes of the second operating system can directly obtain input events.

[0114] For example, electronic device 100 can map input device nodes to a second operating system based on a hardware abstraction layer, so that input device nodes of the first operating system and input device nodes of the second operating system can directly obtain input events.

[0115] The kernel layer is the layer between hardware and software. It contains the kernel subsystem and driver subsystem. Hardware includes input devices, such as touchscreens.

[0116] The kernel subsystem supports selecting a suitable OS kernel for different resource-constrained devices, including but not limited to Linux kernel, HarmonyOS kernel, LiteOS (Lite Operating System), etc.

[0117] The driver subsystem's driver framework forms the foundation for an open system hardware ecosystem, providing unified peripheral access capabilities and a framework for driver development and management. The driver framework includes display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, and more.

[0118] In some embodiments, the hardware abstraction layer can be integrated into the kernel layer.

[0119] In some embodiments, Figure 4 The software architecture of the operating system shown may also include the aforementioned system service layer.

[0120] based on Figure 4 The architecture shown in this application and the event distribution method provided in this embodiment are as follows: Figure 5 As shown. See also Figure 5 The first operating system maps the input device nodes in the hardware abstraction layer to the second operating system; this process is handled by... Figure 4 The mapping module in the hardware abstraction layer is executed. See also Figure 5 At the framework layer, the first operating system sends the window information of application windows on the electronic device to the second operating system; this process is handled by... Figure 4 The window synchronization module in the frame layer shown executes. See also Figure 5 At the framework layer, the input device nodes of the first operating system and the input device nodes of the second operating system obtain input events. This process is handled by... Figure 4 The acquisition module in the shown framework layer is executed. See also Figure 5 At the framework layer, the first and second operating systems respectively dispatch and process the acquired input events based on window information. This process is handled by... Figure 4 The distribution module in the shown framework layer executes. See also Figure 5 At the application layer, electronic devices perform response operations from input devices.

[0121] based on Figure 5 The electronic device shown, equipped with a first operating system and a second operating system, implements the event distribution method in this embodiment. In this application layer, the application displays an application window. Input device nodes of the first and second operating systems acquire input events based on the hardware abstraction layer. Furthermore, the first operating system sends the window information of the application window on the electronic device to the second operating system based on the framework layer. The first and second operating systems acquire input events based on the framework layer and perform distribution processing, thereby distributing the input events to the target application in the target operating system. The framework layer also includes an event arbitration module, used to arbitrate the input events based on the window information during the distribution process to determine the target operating system corresponding to the input event. The target application in the application layer executes the response operation for the input event.

[0122] The following will be illustrated with reference to the accompanying drawings. Figures 3-5 Taking an electronic device with the structure shown as an example, the event distribution method provided in this application embodiment will be described. The electronic device includes a heterogeneous first operating system and a second operating system. See [link to relevant documentation]. Figure 6 The method may include the following steps S601-S605:

[0123] S601, The first operating system maps the input device node to the second operating system.

[0124] The first operating system and the second operating system are different types of operating systems on the electronic device. In some embodiments, the electronic device may also include other operating systems. For example, the operating systems in the electronic device include, but are not limited to, those mentioned above. Or any combination of other operating systems. This application does not specifically limit the number and type of operating systems included in the electronic device.

[0125] The first operating system has input device nodes and can directly obtain input events through these nodes. The first operating system can map these input device nodes to a second operating system, allowing the second operating system to also directly obtain input events based on these nodes. In one possible implementation, the first operating system is the main operating system that boots up when the electronic device is powered on. For example, the first operating system is a host operating system, and the second operating system is a guest operating system.

[0126] Input device nodes represent device files in the file system. They serve as the interface between user-space programs and the input subsystem in the operating system kernel. Each input device corresponds to an input device node in the operating system, which can then obtain input events. For example, an input device can be a keyboard, mouse, or touchscreen.

[0127] For example, in a Linux system, input device nodes can be located in the ` / dev / input` directory. For instance, an input device node can be represented as ` / dev / input / eventX`, where `X` can be a number representing different input device nodes (input device files), such as `event0`, `event1`, etc. The input device node corresponding to a mouse can be located in the ` / dev / input / mouse0` directory. Electronic devices can receive input events triggered by input devices through the ` / dev / input / eventX` file. Each file in the ` / dev / input` directory corresponds to a specific input device. For example, by checking the local file ` / dev / input` directory of the second operating system and finding nodes corresponding to real physical devices, it can be shown that mapped input device nodes exist. In this embodiment, the input device nodes mapped from the first operating system to the second operating system are real device nodes, not virtualized input nodes as in related technologies.

[0128] For example, a dual-system electronic device has an input device (keyboard, with the corresponding input device node represented as / dev / input / event0), and the first operating system (such as Windows) controls the input device node. At startup, the first operating system can map the input device node ( / dev / input / event0) to the second operating system (such as Linux), so that the second operating system can also directly obtain input events through / dev / input / event0.

[0129] In one possible design, the first operating system can map the input device node to the second operating system when the second operating system boots up. Subsequently, in response to input operations, the second operating system can immediately obtain input events based on its own input device node.

[0130] In another possible design, the first operating system can map the input device node to the second operating system when it first receives an input event. This way, the input device node is mapped only when an input event is received, avoiding pre-mapping and saving resources. This application does not limit the specific timing at which the first operating system maps the input device node to the second operating system.

[0131] Moreover, there are multiple ways for the first operating system to map input device nodes to the second operating system.

[0132] In some embodiments, the first operating system can map input device nodes to the second operating system via a virtual machine. Specifically, the first operating system can use a virtual machine created by virtualization software (such as VMware Workstation or KVM) to map the input device nodes of the first operating system to the virtual machine (which has the second operating system installed). The virtual machine then receives input events through the input device nodes, thus achieving the mapping of the input device nodes to the second operating system.

[0133] In other embodiments, the first operating system can map the input device node to the second operating system via sockets. Specifically, the first operating system creates a socket service to listen for events from the input device node. The second operating system sets up a listening socket. When the first operating system receives an input event, the first and second operating systems communicate with each other and receive the input event from the first operating system based on the input stream carried by the socket, thus mapping the input device node to the second operating system.

[0134] In other embodiments, the first operating system may map the input device node to the second operating system using hardware passthrough. Hardware passthrough technology allows the input device to be directly accessed by one operating system, exposing the access permissions of that input device to another operating system.

[0135] In this way, the first operating system maps the input device node to the second operating system, enabling the second operating system to directly access and control the input device. This avoids the complex process of passing input events from the first operating system to the application layer, processing them (such as coordinate transformation and protocol encapsulation), and then forwarding them to the second operating system during the distribution process. As a result, the first and second operating systems can simultaneously distribute and process input events, improving the response speed and event distribution efficiency.

[0136] Meanwhile, during event distribution, the first operating system does not need to perform coordinate transformations or protocol encapsulation on the input events; that is, the electronic device's CPU does not need to perform these processes. Furthermore, if the first operating system determines that an input event does not correspond to its own, it discards the input event and then becomes inactive. Therefore, this saves CPU and electronic device processing resources, reduces energy consumption, and enhances the device's battery life.

[0137] S602, The first operating system sends the window information of the application window on the electronic device to the second operating system.

[0138] Among them, window information is used to indicate the status information of each application window on the electronic device, such as the window's position, size, attributes, or identifier.

[0139] In some embodiments, window information includes multiple types of window metadata, such as one or more of focus metadata, type metadata, position metadata, or hierarchy metadata. Focus metadata indicates whether the application window is the focus window. Type metadata indicates the operating system to which the application window belongs. For example, type metadata can be marked when the application window is created. Position metadata indicates the location range of the application window, i.e., the window area. For example, the window is a rectangular area, described by the coordinates of its top-left corner, width, and height. Hierarchy metadata indicates the hierarchy / stack information (z-aix order, z-order) of the application windows, determining the overlapping relationship between application windows. In addition, window metadata may also include window identification (ID) data (such as window number).

[0140] Window metadata can be stored on electronic devices in the form of structures, lists, etc. For example, it can be stored as a structure as follows:

[0141]

[0142] In this embodiment, the first operating system holds window information of each application window on the electronic device. The first operating system can send the window information of the application windows on the electronic device to the second operating system, so that the second operating system can distribute and process input events based on the window information.

[0143] In some embodiments, the first operating system can send application window information from the electronic device to the second operating system via IPC. For example, IPC methods may include pipes, message queues, semaphores, shared memory, socket communication, streams, etc. This application does not limit the specific method of transmitting window information.

[0144] The first operating system sends the window information of the application windows on the electronic device to the second operating system, which can ensure that the state, display and function of the application windows are consistent between the first operating system and the second operating system. This ensures the synchronization of the first operating system and the second operating system in processing input events based on the window information, so that the second operating system can accurately distribute and process input events based on the accurate window states of all application windows on the electronic device.

[0145] In some embodiments, the window information of application windows sent by the first operating system to the second operating system is full window information. Full window information represents the window information of all application windows on the electronic device, including windows of applications from both the first and second operating systems. In one possible implementation, the first operating system may periodically send full window information to the second operating system to ensure that the window information obtained by the second operating system is more accurate and that the state, display, and functionality of application windows remain consistent with those of the first operating system. This window information is used by the second operating system to understand which windows are present on the electronic device and to distribute input events based on this window information.

[0146] In another possible implementation, the window information sent from the first operating system to the second operating system includes full window information and incremental window information. Incremental window information is used to represent window state information that has changed based on the full window information, such as window creation, closing, moving, or resizing, and is used to update the window in the second operating system.

[0147] The timing of sending full window information and incremental window information to the second operating system differs. In some embodiments, the first operating system first sends full window information of application windows on the electronic device to the second operating system. When an application window on the electronic device changes, the first operating system then dynamically sends incremental window information corresponding to the changed window to the second operating system.

[0148] In one possible design, the first operating system can send full window information at preset times. These preset times could include the second operating system starting up, resuming, or unfreezing. Then, when the window state changes, the first operating system sends incremental window information to the second operating system. This method synchronizes incremental window information only when the window state changes, and the data volume of incremental window information is relatively small. By synchronizing a small amount of incremental window information at a time, it can achieve the goal of real-time and rapid synchronization of application window states across various applications on the electronic device.

[0149] For example, when the second operating system starts up, or when the application window is woken up from hibernation and restored, or when it is thawed from a frozen state and reactivated, the first operating system sends all window information of all windows to the second operating system.

[0150] For example, when the application window on an electronic device changes, see Figure 7 When a new window B is created (added), the first operating system sends the information about the newly created window B to the second operating system in the incremental window information. Alternatively, when window A is moved or resized, the first operating system sends the information about the movement or resizing of window A to the second operating system in the incremental window information.

[0151] When the second operating system boots up, it may not have previously acquired application window information, or it may have been inactive for a considerable period when the second operating system is restored or unfrozen. This can lead to significant differences in window states between the first and second operating systems. In such cases, the first operating system sends all application window information to the second operating system. Window synchronization ensures that the window states remain consistent between the two operating systems. During the normal operation of the second operating system, when an application window on the electronic device changes, the first operating system sends the incremental window information corresponding to the changed window to the second operating system. The first operating system only sends the incremental window information corresponding to the changed window to the second operating system, rather than synchronizing data for all windows, reducing unnecessary data transmission and improving event distribution efficiency and response speed.

[0152] Furthermore, operating systems include native applications and shell applications. Native applications are applications running on the host operating system. Shell applications are used to encapsulate, bridge, or enhance the functionality of other applications (such as enhancing applications running on the guest operating system). Shell applications can act as an intermediate layer, providing interfaces, conversion services, or integrating applications from different operating systems. For example, shell applications can provide data transfer interfaces for heterogeneous systems.

[0153] In some embodiments, during the startup, recovery, or unfreezing of the second operating system, the window states held by the first and second operating systems differ. The first operating system sends the window information of the native application and the shell application to the second operating system. During normal operation of the operating system, when the application window state on the electronic device changes, the first operating system sends the incremental window information of the native application and the shell application to the second operating system.

[0154] Both native and shell applications send full and incremental window information to the primary operating system. The window information of a native application can be understood as the window information of application windows on the primary operating system of the electronic device. The full window information sent by the shell application can be understood as the window information of application windows on other operating systems on the electronic device besides the primary operating system. The full window information sent by both native and shell applications includes the full window information of all application windows on the electronic device. The incremental window information sent by both native and shell applications includes the incremental window information of all application windows on the electronic device.

[0155] For example, window synchronization methods are as follows: Figure 8 As shown, Figure 8 (a) shows the window synchronization method for full window information. Figure 8 (b) shows the window synchronization method for incremental window information.

[0156] like Figure 8 As shown in (a), the native application and the shell application send all window information to the window synchronization module in the first operating system in a list manner (windowList.Append()). Furthermore, the first operating system can also return a message indicating successful synchronization of all window information to the native application and the shell application. The window synchronization module in the first operating system can send all window information to the second operating system (such as the window synchronization module in the second operating system) in batch mode (batchAppend). Furthermore, the second operating system returns a message indicating successful synchronization of all window information to the first operating system.

[0157] like Figure 8As shown in (b), the native application sends the modified window to the first operating system, the first operating system synchronizes the corresponding modified window, and appends the incremental window data corresponding to the modified window to the second operating system. Furthermore, the second operating system returns a message to the native application indicating that the incremental window information has been successfully saved.

[0158] S603. In response to the input operation, the input device node of the first operating system and the input device node of the second operating system obtain the input event.

[0159] Input operations are user actions performed when interacting with an electronic device. Examples include sliding a finger on a touchscreen, typing on a keyboard, moving a mouse, or clicking a mouse button. Signals generated during user interaction are captured by input devices (such as touchscreens, keyboards, and mice) and transmitted to the operating system, thus creating input events. In response to user input operations, the input device nodes of the first and second operating systems receive the input events.

[0160] See Figure 9 The input device nodes of the first operating system and the second operating system simultaneously acquire input events. The second operating system can directly acquire the input events and then distribute and process them, eliminating the need for multiple conversions and transfers between the first and second operating systems. This shortens the event distribution process, reduces the response time, improves event distribution efficiency, and enhances the user interaction experience.

[0161] In response to an input operation, the input device nodes of the first operating system and the second operating system can read the input data from the kernel through the hardware input device via the hardware driver, thereby obtaining the input event. Then, the two operating systems synchronously distribute and process the input event.

[0162] In this embodiment, the second operating system can directly obtain input events through hardware drivers and input device nodes based on hardware pass-through, eliminating multiple conversions or transmissions within the first operating system and between the first and second operating systems, shortening the event distribution process, reducing the response time of event distribution, improving event distribution efficiency, and enhancing the user interaction experience.

[0163] Furthermore, since the first operating system does not need to perform coordinate transformations or protocol encapsulation on input events during event distribution, the CPU does not need to perform these processes. Moreover, the first operating system discards the input event if it determines that it does not correspond to the first operating system, and then remains inactive. Therefore, CPU and electronic device processing resources can be saved, energy consumption reduced, and device battery life enhanced.

[0164] Input events can include different event types such as keyboard key events and interactive position events. Keyboard key events represent input events generated by the user pressing keyboard keys, such as key presses. Interactive position events (also known as point events) represent events corresponding to the user's position during interaction on the electronic device screen, such as mouse events, touch events, stylus events, or pointer events.

[0165] In addition, interaction location events contain information indicating the location where the interaction occurred (i.e., the trigger location of the input event), such as coordinate values. The operating system can determine the interactive element between the input event and the operating system based on the coordinate values ​​of the interaction location event. The interactive element can be a button, icon, a location in a window, etc. For example, the coordinate values ​​can be represented as (x, y). See also... Figure 10 , Figure 10 This illustrates a window stacking method where windows A, B, and C are located in the XOY plane and arranged in a stacked manner along the Z-axis.

[0166] For example, in response to a user's input operation of pressing or releasing a key on a keyboard, or pressing a combination of keys, an electronic device can capture events generated by the keyboard device, including the key encoding and state (press / release, combination key), etc. These key events are acquired through the input device nodes of the first operating system and the second operating system.

[0167] For example, in response to a user's touchscreen actions such as clicking or swiping, an electronic device can capture events generated by the touchscreen, including data such as the touch location coordinates, duration, and pressure. These touch events are acquired through the input device nodes of the first operating system and the second operating system.

[0168] For example, in response to a user's mouse movement or click, an electronic device can capture events generated by the mouse, including position coordinates and changes in position coordinates. This data is obtained as mouse events through the input device nodes of the first and second operating systems. See, for an example... Figure 11In (a), the electronic device includes a first operating system and a second operating system. Application windows A and C on the electronic device correspond to the first operating system, and window B corresponds to the second operating system. The first operating system maps input device nodes to the second operating system. Furthermore, the first operating system sends window information of the application windows on the electronic device to the second operating system. In response to a mouse click operation (corresponding to an input operation), the input device nodes of the first and second operating systems receive the mouse click event.

[0169] S604, the first operating system, and the second operating system respectively distribute and process the acquired input events based on window information.

[0170] In this embodiment of the application, after receiving an input event, the first operating system and the second operating system each distribute and process the acquired input event based on window information. It is understood that, see [link to relevant documentation]... Figure 9 The second operating system distributes and processes input events based on window information, which is executed in parallel with the first operating system's distribution and processing of input events based on window information. In other words, they are executed simultaneously or separately.

[0171] The first and second operating systems each distribute input events based on window information and the accurate window states of all application windows on the electronic device, ensuring that input events are correctly distributed to the target application. Simultaneously, the second operating system's distribution of input events based on window information runs in parallel with the first operating system's distribution, eliminating the complex process of multiple conversions and transfers between the first and second operating systems before finally injecting the event into the second operating system for distribution. This shortens the event distribution process, reduces response time, improves efficiency, and enhances the user experience.

[0172] In this process, each input event corresponds to either a first operating system or a second operating system, and is distributed to that corresponding operating system. During the distribution process, the first operating system, based on the window information of the application window on the electronic device, distributes the input event to the target application within that first operating system if it determines that the input event corresponds to that operating system. Similarly, the second operating system, also based on the window information of the application window on the electronic device, distributes the input event to the target application within that second operating system if it determines that the input event corresponds to that operating system.

[0173] Window information describes the state of each application window on an electronic device. Based on this window information, the corresponding operating system is determined to distribute input events, ensuring that input events are correctly distributed to the appropriate application window and target application. This allows the electronic device to respond correctly to user input, enhancing the user experience.

[0174] Furthermore, when an input event does not correspond to the operating system, the operating system will discard the input event. For example, a first operating system checks whether an input event corresponds to its own operating system based on window information of an application window on the electronic device. If the first operating system determines that the input event does not correspond to its own operating system, it discards the input event. Similarly, a second operating system checks whether an input event corresponds to its own operating system based on window information. If the first operating system determines that the input event does not correspond to its own operating system, it discards the input event. In other words, after an input event is acquired, both the first and second operating systems determine whether the input event corresponds to their respective operating systems based on window information. If they do not correspond, the input event is discarded, and the electronic device does not take any response, thus preventing erroneous event distribution and ensuring the accuracy of user interaction.

[0175] For example, the application windows managed by the first operating system include document applications and email applications, while the application windows managed by the second operating system include game applications. In response to a user pressing a key on the keyboard while operating in the game application, the input device nodes of both the first and second operating systems acquire the key event. Based on window information, the first operating system determines that the key event does not correspond to its own window and discards it without responding. Simultaneously, the second operating system, based on the window information, determines that the key event corresponds to the game application window, and therefore the key event is distributed to the game application, enabling it to respond to the key event.

[0176] The first and second operating systems handle input events of different types differently. The following explanation uses the second operating system as an example to illustrate how it handles input event distribution.

[0177] When the input event is a keyboard key event, if the second operating system determines, based on window information, that the first application window corresponding to the focused window belongs to the second operating system, then the input event corresponds to the second operating system. The application to which the first application window belongs is the target application. The focused window represents the window containing the application or interface element that the user is currently interacting with. Based on the focused window, the interaction location of the keyboard key event can be determined, thereby ensuring that the keyboard key event is accurately distributed to the correct operating system corresponding to the focused window, enhancing the user experience.

[0178] For example, the window containing the SMS application and the SMS editing box is a window managed by the second operating system. When the electronic device responds to a user pressing a letter key on the input method keyboard of the SMS editing box (corresponding to the first application window), the second operating system receives the keyboard key event. Based on the window information, the second operating system determines that the focus window is the window containing the SMS editing box, and since the window containing the SMS editing box belongs to the second operating system, it determines that the input event corresponds to the second operating system. The SMS application to which the window containing the SMS editing box belongs is the target application, and the key event is distributed to the SMS application and the window containing the SMS editing box within the second operating system.

[0179] When the input event is an interactive location event, if the second operating system determines, based on window information, that the second application window belongs to the second operating system among multiple stacked application windows on the electronic device, then the input event corresponds to the second operating system. The second application window is the application window whose location range includes the trigger position of the input event and whose stacking order (z-order) is the one that is visually at the top layer and whose user interaction position falls within its range. The application to which the second application window belongs is the target application. By determining the trigger position of the interactive location event, the foremost application window at the trigger position can be accurately identified, thereby distributing the input event to the correct operating system corresponding to the foremost application window at the trigger position, enhancing the user interaction experience.

[0180] For example, when an electronic device responds to a user touching a button on the screen, the input device nodes of the first and second operating systems acquire the touch event, including information such as the coordinates of the touch point. The second operating system, upon acquiring the touch event and window information, determines that the window containing the touch event is the application window whose trigger position is within the window and whose stacking z-order is the highest. Furthermore, the second application window containing the button corresponds to the second operating system. The second operating system then determines that the second application window corresponding to the button belongs to the second operating system, and the touch event is distributed to the window containing the button within the second operating system.

[0181] For example, an electronic device displays two split-screen application windows. The device responds when the user moves the mouse on the game window in the left half of the screen. The second operating system receives the mouse click event and, based on the window information, determines that among the stacked application windows on the electronic device, the game window in the left half of the screen belongs to the second operating system. Furthermore, if this game window's position includes the trigger point of the mouse click event and it is the application window with the highest z-order in the stack, then the mouse click event corresponds to the second operating system, and the mouse click event is distributed to the game window in the left half of the screen of the second operating system.

[0182] For example, see Figure 12 Window A, Window B, and Window C are stacked along the z-order increasing direction, with Window C being the application window that appears first in the z-order. See also Figure 12 In (a) of the diagram, the electronic device responds to a user touching the play / pause button in window B on the touchscreen. The second operating system receives the touch event, including the coordinates of the touch point. Starting from the top-level window C, the second operating system checks windows C, B, and A sequentially, following the z-order stacking order (increasing z-order). Based on the window information and the coordinates of the touch point, the second operating system determines that window C does not correspond to the second operating system. Then, the second operating system detects that the coordinates of the touch point are located on the play / pause button in window B. Since window B is the application window of the second operating system, the touch event is determined to correspond to the second operating system, and the touch event is dispatched to window B.

[0183] In some embodiments, different types of input events can use different window metadata to determine the corresponding operating system. For example, the second operating system can determine the target event type corresponding to the input event, and the target data type of the window metadata corresponding to the target event type. Then, the second operating system determines the second operating system corresponding to the input event based on the window metadata corresponding to the data type in the window information. In this way, by classifying input events into types such as keyboard key events and interaction position events, and performing different distribution processing on different event types, it is ensured that input events are accurately distributed to the corresponding operating system according to type, optimizing the event processing flow, improving event distribution efficiency, and enhancing user experience.

[0184] For example, if the target event type is a keyboard key event, the target data type of the corresponding window metadata includes focus metadata and type metadata. If the target event type is an interactive position event, the target data type of the corresponding window metadata includes position metadata and hierarchy metadata.

[0185] Therefore, when the input event is a keyboard key event, the second operating system determines, based on the focus metadata and type metadata in the window information, that the application window corresponding to the focus window belongs to the second operating system, thus determining that the input event corresponds to the second operating system. Furthermore, the application to which the first application window belongs is the target application. Based on the focus metadata and type metadata, the second operating system can accurately distribute the keyboard key event to the correct target application, enhancing the user interaction experience.

[0186] For example, in response to a user pressing a key on the keyboard during an operation within a game application, the second operating system determines, based on focus metadata and type metadata, that the focus window is the game application window. Since the game application window belongs to the second operating system, the keyboard key event corresponds to the second operating system. Furthermore, the game application to which the game application window belongs is the target application. Therefore, the keyboard key event is dispatched to the game application window, enabling the game application to respond to the key press.

[0187] When the input event is an interactive location event, the second operating system determines the second application window among the stacked application windows on the electronic device based on the location metadata and hierarchy metadata in the window information. If the second application window belongs to the second operating system, and its location range includes the trigger position of the input event while it is the application window with the highest z-order stacking order, then the input event corresponds to the second operating system. Furthermore, the application to which the second application window belongs is the target application. By utilizing location metadata and hierarchy metadata, the second operating system accurately identifies and processes interactive location events, ensuring that input events are distributed to the correct target application and enhancing the user experience.

[0188] For example, the electronic device responds to an interactive position event corresponding to a user's swipe operation on a game application window. The input device nodes of the first operating system and the second operating system acquire the input event. Based on the position metadata and hierarchy metadata in the window information, the second operating system determines which of the multiple application windows stacked on the electronic device is the game application window whose position range includes the trigger position of the interactive position event and which is the first in the stacking z-order. The game application window belongs to the second operating system, and the game application to which the game application window belongs is the target application. Therefore, the interactive position event is distributed to the game application window, enabling the game application to perform a corresponding action based on the swipe event.

[0189] Similarly, the process by which the second operating system distributes and processes the acquired input events based on window information is also used by the first operating system, and will not be elaborated here.

[0190] In this embodiment, the input event distribution process may include two stages, also known as a two-level distribution process. See also Figure 13In the first-level distribution process, the first and second operating systems respectively obtain input events through the input device node and determine the target operating system corresponding to the input event based on window information. The target operating system is either the first or the second operating system. In the second-level distribution process, the target operating system further distributes the input event to the target application. This two-level distribution process improves the accuracy of input event distribution, ensuring that input operations receive accurate responses on the correct operating system and in the correct target application, thus enhancing the user experience.

[0191] S605, The electronic device performs a response operation to the input event.

[0192] After an input event is dispatched to a target application in the corresponding operating system (such as the aforementioned first or second operating system), the electronic device executes a response operation for the input event through the target application.

[0193] For example, if the input event is a touchscreen swipe (corresponding to an interaction position event) and is distributed to a game application, then in this touchscreen swipe event, the user can control the movement of the character in the game by swiping their finger. Alternatively, if the touchscreen swipe event is distributed to a video application, then in this touchscreen swipe event, the user can control the video playback by swiping their finger to fast forward.

[0194] For example, if the input event is a keyboard key event (corresponding to the keyboard key event), and it is dispatched to the target application, which is a text editing application, then in the keyboard key event, when the user presses a letter key in the text editing application, they can edit the text, and the text editing content will be displayed in the text editing box.

[0195] For example, see Figure 11 In (b) of the example, window B responds to a mouse click event, and the video fast-forwards to the clicked location to begin playback. See also... Figure 12 In (b), window B responds to the user's touch event, and the video is paused.

[0196] The event distribution method of the above embodiments of this application maps input device nodes to a second operating system. The second operating system directly obtains input events through the input device nodes, and both the second and first operating systems simultaneously distribute the input events. This eliminates the need for the first operating system to pass the input events to the application layer for coordinate transformation, protocol encapsulation, and other processing before injecting them into the second operating system for distribution. The second operating system can directly obtain input events from the hardware driver through the input device nodes and distribute them to the target application, shortening the event distribution process, reducing the response time, and improving the user interaction experience.

[0197] Furthermore, since the first operating system does not need to perform coordinate transformation and protocol encapsulation on the input event before sending it to the second operating system during the event distribution process, the CPU does not need to perform these processes. Moreover, the first operating system discards the input event if it determines that the input event does not correspond to its own, and then becomes inactive. Therefore, CPU and electronic device processing resources can be saved, energy consumption reduced, and device battery life enhanced.

[0198] It should be noted that the above embodiments can be combined in any way as long as the solutions themselves are not contradictory.

[0199] In some solutions, multiple embodiments of this application can be combined, and the combined solution can be implemented. Optionally, some operations in the processes of each method embodiment may be combined, and / or the order of some operations may be changed. Furthermore, the execution order between the steps of each process is merely exemplary and does not constitute a limitation on the execution order between steps; other execution orders are also possible. It is not intended to indicate that the execution order is the only possible order in which these operations can be performed. Those skilled in the art will conceive of various ways to reorder the operations described herein. In addition, it should be noted that the process details involved in one embodiment of this document are similarly applicable to other embodiments, or different embodiments may be combined.

[0200] Furthermore, some steps in the method embodiments can be equivalently replaced with other possible steps. Alternatively, some steps in the method embodiments may be optional and can be deleted in certain use cases. Or, other possible steps may be added to the method embodiments.

[0201] Furthermore, the various method embodiments can be implemented individually or in combination.

[0202] It is understood that, in order to achieve the above functions, the electronic device includes hardware and / or software modules that perform the respective functions. Based on the algorithmic steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is implemented in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0203] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0204] For example, when functional modules are divided according to their respective functions, the electronic device involved in the above embodiments may include: an establishment unit, a receiving unit, a presentation unit, an activation unit, and an adjustment unit, etc. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0205] This application also provides an electronic device, such as... Figure 14 As shown, the electronic device may include one or more processors 1401, memory 1402 and communication interface 1403.

[0206] The memory 1402, communication interface 1403, and processor 1401 are coupled together. For example, the memory 1402, communication interface 1403, and processor 1401 can be coupled together via bus 1404.

[0207] The communication interface 1403 is used for data transmission with other devices. The memory 1402 stores computer program code. The computer program code includes computer instructions, which, when executed by the processor 1401, cause the electronic device to perform the display method described in this embodiment.

[0208] The processor 1401 may be a processor or controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in connection with this disclosure. The processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0209] The bus 1404 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 1404 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 14 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0210] This application also provides a computer-readable storage medium storing computer program code. When the processor executes the computer program code, the electronic device executes the relevant method steps in the above method embodiments.

[0211] This application also provides a computer program product that, when run on a computer, causes the computer to execute the relevant method steps described in the above method embodiments.

[0212] The electronic devices, computer storage media, or computer program products provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0213] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0214] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0215] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0216] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0217] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, in essence, or the part that contributes, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0218] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An event dispatching method, characterized in that, Applied to an electronic device, the electronic device including a first operating system and a second operating system, the method includes: The first operating system maps the input device node to the second operating system; The first operating system sends the window information of the application window on the electronic device to the second operating system; In response to an input operation, the input device node of the first operating system and the input device node of the second operating system acquire the input event; The first operating system and the second operating system respectively distribute and process the acquired input events based on the window information.

2. The method according to claim 1, characterized in that, In response to an input operation, the input device node of the first operating system and the input device node of the second operating system acquire an input event, including: In response to an input operation, the input device nodes of the first operating system and the second operating system acquire the input event through hardware drivers.

3. The method according to claim 1 or 2, characterized in that, The second operating system and the first operating system are heterogeneous systems; the second operating system distributes and processes the input events based on the window information, and the first operating system distributes and processes the input events based on the window information in parallel.

4. The method according to any one of claims 1-3, characterized in that, The first operating system and the second operating system respectively distribute and process the acquired input events based on the window information, including: If the first operating system determines that the input event corresponds to the first operating system based on the window information of the application window on the electronic device, it will distribute the input event to the target application in the first operating system. Based on the window information, if the second operating system determines that the input event corresponds to the second operating system, it will distribute the input event to the target application in the second operating system. The method further includes: The electronic device performs a response operation to the input event through the target application.

5. The method according to claim 4, characterized in that, The first operating system and the second operating system respectively distribute and process the acquired input events based on the window information, and the process further includes: If the first operating system determines, based on the window information of the application window on the electronic device, that the input event does not correspond to the first operating system, it discards the input event. If the second operating system determines, based on the window information, that the input event does not correspond to the second operating system, it discards the input event.

6. The method according to any one of claims 1-5, characterized in that, The first operating system sends window information of application windows on the electronic device to the second operating system, including: The first operating system sends all window information of the application windows on the electronic device to the second operating system; When the application window on the electronic device changes, the first operating system sends the incremental window information corresponding to the changed window to the second operating system.

7. The method according to claim 6, characterized in that, The first operating system sends all window information of the application windows on the electronic device to the second operating system, including: When the second operating system starts, restores, or unfreezes, the first operating system sends the full window information to the second operating system.

8. The method according to claim 4, characterized in that, The second operating system determines, based on the window information, that the input event corresponds to the second operating system, including: When the input event is a keyboard key event, the second operating system determines, based on the window information, that the first application window corresponding to the focused window belongs to the second operating system, and then determines that the input event corresponds to the second operating system, and the application to which the first application window belongs is the target application; When the input event is an interactive location event, the second operating system determines, based on the window information, the second application window in the stacked application windows of the electronic device, and the second application window belongs to the second operating system. The second application window is the application window whose location range includes the trigger position of the input event and whose stacking order z-order is the first. Then, the input event is determined to correspond to the second operating system, and the application to which the second application window belongs is the target application.

9. The method according to claim 4, characterized in that, The window information includes multiple types of window metadata. Based on the window information, the second operating system determines that the input event corresponds to the second operating system, including: The second operating system determines the target event type corresponding to the input event, and the target data type of the window metadata corresponding to the target event type; The second operating system determines that the input event corresponds to the second operating system based on the window metadata corresponding to the data type in the window information.

10. The method according to claim 9, characterized in that, If the target event type is a keyboard key event, then the target data type of the corresponding window metadata includes focus metadata and type metadata; wherein, the focus metadata is used to indicate whether the application window is the focus window, and the type metadata is used to indicate the operating system to which the application window belongs; or, If the target event type is an interactive location event, the target data type of the corresponding window metadata includes location metadata and hierarchy metadata; wherein, the location metadata is used to indicate the location range of the application window, and the hierarchy metadata is used to indicate the stacking information of the application windows.

11. The method according to claim 9 or 10, characterized in that, The second operating system determines that the input event corresponds to the second operating system based on the window metadata corresponding to the data type in the window information, including: When the input event is a keyboard key event, the second operating system determines, based on the focus metadata and type metadata in the window information, that the application window corresponding to the focus window belongs to the second operating system, and thus determines that the input event corresponds to the second operating system; and the application to which the first application window belongs is the target application; When the input event is an interactive location event, the second operating system determines, based on the location metadata and hierarchy metadata in the window information, the second application window belonging to the second operating system, and the second application window being the application window whose location range includes the triggering position of the input event and whose stacking order z-order is the first, then the input event is determined to correspond to the second operating system; and the application to which the second application window belongs is the target application.

12. The method according to any one of claims 1-11, characterized in that, The first operating system is the host operating system, and the second operating system is the guest operating system. The host operating system and the guest operating system are different types of operating systems.

13. An electronic device, characterized in that, include: A memory, one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the event dispatch method as described in any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the event dispatch method as described in any one of claims 1-12.

15. A computer program product, characterized in that, When the computer program product is run on a computer, the computer performs the event dispatching method as described in any one of claims 1-12.

Images