Touch event processing method and device, electronic equipment, vehicle and program product

Abstract

The invention relates to the technical field of computers, in particular to a touch event processing method and device, electronic equipment, a vehicle and a program product, and aims to improve the accuracy of touch event detection. The method comprises the steps that a groove queue used for recording state attributes of touch points is obtained, the groove queue comprises at least one groove, each groove corresponds to one touch point, and the touch points are points generated when an object executes pressing operation on a touch screen; when the first lifting event is identified, searching a target slot corresponding to the touch point in the abnormal state in the slot queue; the first lifting event is an event generated when the object performs lifting operation on the touch screen; and simulating a second lifting event for the target slot, and updating the state value stored in the target slot according to the second lifting event so as to relieve the abnormal state of the corresponding touch point. The accuracy is improved by simulating the lifting event.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, vehicle and program product for processing a touch event. Background Art

[0002] A touch screen is an inductive liquid crystal display device that can receive input signals from fingers or other objects. Touch screen technology makes human-computer interaction more direct and is widely used in many fields. Its basic principle is: when you touch the touch screen installed on the front of the display with your finger or other object, the touched position (in the form of coordinates) is detected by the touch screen controller and sent to the central processing unit (CPU) through an interface {such as an integrated circuit bus (Inter-Integrated Circuit, I2C), a serial port, etc.}, thereby determining the input information.

[0003] Taking the scenario where finger touch is used as the input signal as an example, after the Android system records a single-finger press event, if no single-finger lift event is received, the next time the single-finger press event is triggered again, since there are more than one point records in the slot queue, it will be reported as a multi-finger press event, which will cause confusion between single-finger and multi-finger operations.

[0004] In summary, how to improve the accuracy of touch event detection is an urgent problem to be solved. Summary of the invention

[0005] Embodiments of the present application provide a touch event processing method, device, electronic device, vehicle, and program product to improve the accuracy of touch event detection.

[0006] On the one hand, an embodiment of the present application provides a method for processing a touch event, the method comprising:

[0007] Acquire a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen;

[0008] When a first lift event is identified, searching for a target slot corresponding to the touch point in the slot queue whose state is abnormal; the first lift event is an event generated when the object performs a lift operation on the touch screen;

[0009] A corresponding second lift event is simulated for the target slot, and a state value stored in the target slot is updated according to the second lift event to release the abnormal state of the corresponding touch point.

[0010] The embodiments of the present application provide a method, device, electronic device, vehicle and program product for processing touch events. Specifically, touch events mainly include two categories: press events and lift events. In the related art, if a single-finger press event is detected but no single-finger lift event is received, different press events will be reported at the same time when the single-finger press event is triggered again next time, that is, confusion between single-finger operation and multi-finger operation will occur; and in the embodiments of the present application, each time a lift event is identified, the target slots corresponding to the touch points with abnormal status in the slot queue will be searched; for these target slots, the corresponding lift events are simulated to release the abnormal status of the corresponding touch points. Based on this method, when encountering the above situation, the lift event of the corresponding abnormal state touch point is simulated, and then the slot state value of the corresponding normal state touch point is updated, thereby releasing the abnormal state of the touch point, and improving the accuracy of touch event detection.

[0011] On the one hand, an embodiment of the present application provides a device for handling touch events, including:

[0012] A determination unit, configured to obtain a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen;

[0013] an identification unit, configured to search for a target slot corresponding to a touch point in an abnormal state in the slot queue when a first lift event is identified; the first lift event is an event generated when the object performs a lift operation on the touch screen;

[0014] The simulation unit is used to simulate a corresponding second lifting event for the target slot, and update the state value stored in the target slot according to the second lifting event to release the abnormal state of the corresponding touch point.

[0015] Optionally, the identification unit is specifically used for:

[0016] For each touch point, if after the object triggers a press event for the touch point, a first lift event triggered by the object for the touch point is not identified, then determining that the touch point is in an abnormal state;

[0017] The slot corresponding to the touch point with abnormal status in the slot queue is used as the target slot.

[0018] Optionally, before searching the slot queue for a target slot corresponding to the touch point with an abnormal state, the identification unit is further configured to:

[0019] Acquire first identification information corresponding to the first lifting event;

[0020] The state value of the slot corresponding to the first identification information is updated from the in-use state to the out-of-use state, wherein the slot corresponding to the first identification information is created and recorded as being in-use state when a press event for the touch point corresponding to the first identification information is recognized before the first lift event.

[0021] Optionally, the identification unit is specifically used for:

[0022] Traversing the slot queue, and analyzing the state value stored in each slot when traversing to the slot;

[0023] If the state value indicates that the state is being used, it is determined that the touch point corresponding to the one slot is in an abnormal state, and the one slot is used as a target slot.

[0024] Optionally, the simulation unit is specifically used for:

[0025] Obtaining second identification information corresponding to the target slot;

[0026] Simulating a second lifting event corresponding to the target slot through a local service layer;

[0027] Sending the second identification information and the second lift event to the kernel layer to release the abnormal state of the touch point corresponding to the second identification information, and sending the second identification information and the second lift event to the local service layer;

[0028] After the local service layer receives the second identification information and the second lift event sent by the kernel layer, the status value stored in the target slot is updated to a non-use status according to the second identification information and the second lift event to resolve the abnormal status of the touch point corresponding to the second identification information.

[0029] Optionally, the simulation unit is specifically used for:

[0030] The second lift event is simulated by the input trigger subsystem in the local server.

[0031] In one aspect, an embodiment of the present application provides an electronic device for processing a touch event, the device comprising a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following steps:

[0032] Acquire a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen;

[0033] When a first lift event is identified, searching for a target slot corresponding to the touch point in the slot queue whose state is abnormal; the first lift event is an event generated when the object performs a lift operation on the touch screen;

[0034] A corresponding second lift event is simulated for the target slot, and a state value stored in the target slot is updated according to the second lift event to release the abnormal state of the corresponding touch point.

[0035] On the one hand, an embodiment of the present application provides a vehicle, which includes any of the above-mentioned devices for processing touch events or any of the above-mentioned electronic devices for processing touch events, or a method for executing any of the above-mentioned touch event processing.

[0036] On the one hand, an embodiment of the present application provides a computer program product, including a computer program, which implements any of the above-mentioned methods for processing touch events when the computer program is executed by a processor.

[0037] Optionally, the computer-readable storage medium can be implemented as a computer program product, that is, an embodiment of the present application also provides a computer-readable storage medium, which includes a computer program, and when the computer program is executed by a processor, it implements any of the above-mentioned methods for processing touch events.

[0038] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] Figure 1 A schematic diagram of an application scenario of touch event processing provided by an embodiment of the present application;

[0041] Figure 2 A flowchart of a method for processing a touch event provided in an embodiment of the present application;

[0042] Figure 3A A schematic diagram of a touch point state provided in an embodiment of the present application;

[0043] Figure 3B A schematic diagram of another touch point state provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of the operation of a vehicle system provided in an embodiment of the present application;

[0045] Figure 5 A schematic diagram of an abnormal state of a touch point provided in an embodiment of the present application;

[0046] Figure 6 A schematic diagram of an Android input system provided in an embodiment of the present application;

[0047] Figure 7 An overall flow chart of a method for processing a touch event provided in an embodiment of the present application;

[0048] Figure 8 A schematic diagram of a hardware structure of an electronic device to which an embodiment of the present application is applied;

[0049] Fig. 9 A schematic diagram of the structure of an electronic device for processing touch events in an embodiment of the present application;

[0050] Fig.10 A schematic diagram of the hardware composition structure of a computing device using an embodiment of the present application. DETAILED DESCRIPTION

[0051] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the technical solution of the present application, rather than all of the embodiments. Based on the embodiments recorded in the application documents, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the technical solution of the present application.

[0052] The following is an introduction to some concepts involved in the embodiments of the present application.

[0053] Touch event: refers to an event triggered when a user moves a finger, stylus or other object on the touch screen in front of the display, which is used to indicate the event corresponding to one or more touch points in the touch screen. Touch operations can generally be broken down into two operations: press and lift. The press operation indicates that a finger, stylus or other object is detected pressing and clicking on the touch screen, and the lift operation indicates that a finger, stylus or other object is detected leaving the touch screen. Accordingly, the touch events in the embodiments of the present application include but are not limited to: press (down) events and lift (up) events.

[0054] Press event: indicates an event in which a pressed operation is triggered by an object during a touch process. During a touch process, a press operation is followed by a corresponding lift operation. In other words, press events and lift events are usually generated together in a touch scenario.

[0055] Lift event: indicates an event that characterizes an object triggering a lift operation during a touch process. In an embodiment of the present application, lift events are divided into two categories: a first lift event and a second lift event. Among them, the first lift event indicates an event corresponding to a lift operation performed by an object when the object is performing a touch operation, which refers to a real lift event in the present application. For a touch point, the touch point will generate a set of press events and lift events, but the lift event may not be detected normally. Based on this, the present application proposes the feature of a second lift event. The second lift event indicates a simulated lift event for a touch point with an abnormal state when no lift event is received after a press event is detected.

[0056] Identification information: The creation, replacement, and elimination of touch points can be achieved by modifying the corresponding identification information. For example, a non-negative identification information represents a touch point, and -1 represents an unused identification information. A new identification information represents a new touch point, and an identification information that does not appear represents that the touch point has been removed. In an embodiment of the present application, the identification information is divided into first identification information and second identification information, wherein the first identification information represents the identification information of the touch point corresponding to the first lift event; the second identification information represents the identification information of the touch point corresponding to the second lift event.

[0057] Slot and state value: A slot stores the state attributes of a touch point, which include but are not limited to some or all of the following: the coordinates of the touch point, the "in-use" state or the "no-use" state. The state value of the slot represents the state of the corresponding touch point, including the two state values ​​of "in-use" and "no-use".

[0058] "in-use" status value: indicates that after a down event is recognized, the touch point is recorded as the corresponding slot point in the slot queue, and the slot point status is updated to the "in-use" status;

[0059] "no-use" status value: indicates that after an up event is recognized, the status of the corresponding slot point in the slot queue is updated to the "no-use" status.

[0060] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application may be combined with each other if there is no conflict.

[0061] like Figure 1 As shown, it is a schematic diagram of an application scenario of touch event processing provided by an embodiment of the present application. The application scenario diagram includes a touch screen 110 and an electronic device 120. Among them, the touch screen 110 can be located on a vehicle terminal, and the vehicle terminal is a terminal device equipped with a touch screen listed in the embodiment of the present application. Specifically, the vehicle terminal is installed on a vehicle 10.

[0062] In the embodiment of the present application, the electronic device 120 may be deployed on the vehicle 10, for example, the electronic device 120 may be a vehicle-mounted terminal. The electronic device 120 may also be a device independent of the vehicle 10; for example, the electronic device 120 may also be an independent server, which is not specifically limited herein.

[0063] It should be noted that the processing of touch events in each embodiment of the present application is performed by the electronic device 120. The electronic device 120 obtains a slot queue for recording the state attributes of the touch point, the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when the object performs a press operation on the touch screen; when a lift event is identified, the target slot corresponding to the touch point with an abnormal state in the slot queue is searched; the lift event is an event generated when the object performs a lift operation on the touch screen; the corresponding lift event is simulated for the target slot, and the state value stored in the target slot is updated according to the lift event to release the abnormal state of the corresponding touch point.

[0064] After the abnormal state is resolved, the electronic device 120 can directly feed back the current state to the vehicle terminal, and the vehicle terminal performs processing related to the current touch and presents the corresponding processing results. For example, clicking on the touch screen of the vehicle terminal to start an APP, or sliding between two systems on the touch screen, etc., are not specifically limited in this article.

[0065] In an optional implementation, the vehicle-mounted terminal and the electronic device 120 may communicate via a communication network.

[0066] In an optional implementation, the communication network is a wired network or a wireless network.

[0067] It should be noted that Figure 1The examples shown are only for illustration. In fact, the types of terminal devices are not limited. In addition to the vehicle-mounted terminals listed above, they can also be mobile phones, tablet computers, laptop computers, desktop computers, e-book readers, intelligent voice interaction devices, etc., which are not specifically limited in the embodiments of the present application.

[0068] The following describes a method for processing touch events provided by an exemplary embodiment of the present application in combination with the application scenarios described above and with reference to the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this regard.

[0069] like Figure 2 As shown, it is an implementation flow chart of a touch event processing method provided by an embodiment of the present application. When the computer program is executed by the processor, the processor executes the following steps S21 to S23:

[0070] S21: Obtain a slot queue for recording touch point state attributes, where the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen.

[0071] Specifically, when an object touches the touch screen installed on the front of the display with a finger, stylus or other object, the touched position (in the form of coordinates) is detected by the touch screen controller and sent to the CPU through an interface (such as I2C, serial port, etc.), thereby determining the input information.

[0072] The specific location on the touch screen touched by the object through a finger, a stylus or other objects can be recorded as a touch point. Taking a single-finger touch as an example, one touch operation can generate one touch point; taking a multi-finger touch as an example, one touch operation can generate multiple touch points.

[0073] For example, in a Linux system, multi-point capacitive touch protocols are divided into Type A and Type B protocols, wherein the Type A protocol is mainly for single-finger touch events, and does not distinguish between touch points.

[0074] The Type B protocol is mainly for multi-finger touch events. When using the Type B protocol, each distinguishable touch point is associated with a corresponding slot, and the slot is used to transmit the changes of the touch point. The creation, replacement and elimination of touch points can be achieved by modifying the identification information (TRACKING_ID) of the corresponding slot. A non-negative TRACKING_ID represents a touch point, and -1 represents an unused channel. A new TRACKING_ID represents a new touch point, and a non-appearing TRACKING_ID means that the touch point has been removed.

[0075] In the embodiment of the present application, the operation of the object on the touch point can be specifically divided into: a press operation and a lift operation.

[0076] The pressing operation means that the finger, stylus or other object of the object presses and clicks the touch screen, and the lifting operation means that the finger, stylus or other object of the object leaves the touch screen.

[0077] When an object performs a touch operation based on a touch point, the state attribute corresponding to each touch point can be recorded through a slot queue, and each touch point corresponds to a slot point in the slot queue.

[0078] Specifically, taking the scene of finger touch of an object as an input signal as an example, it can be divided into single-finger touch and multi-finger touch. Single-finger touch refers to one finger touching a point on the screen to implement the operation. In this mode, when a single-finger press event is triggered, the point is recorded in the corresponding slot queue, and when a single-finger lift event is triggered, the point is removed from the corresponding slot queue; multi-finger operation refers to multiple single-finger operations. In this mode, when a multi-finger press event is triggered, multiple points will be recorded in the slot queue. Correspondingly, when a multi-finger lift event is triggered, the slots corresponding to the multiple points will be deleted from the slot queue.

[0079] like Figure 3A , which is a schematic diagram of a touch point state provided in an embodiment of the present application, Figure 3A The slot queue shown (i.e. Figure 3A The slot queue in the table contains at least one slot, and the slot queue contains the identification information and status value of the slot. Figure 3A "Slot 0", "Slot 1", etc. are identification information, and "in-use" and "no-use" are status values.

[0080] Taking a specific case as an example, assuming that the user presses the touch point with one finger, a corresponding slot will be recorded in the slot queue. For example, the identification information of the slot is slot 2, and the status is recorded as "in-use". When the user lifts the finger, the status of slot 2 should be updated to "no-use".

[0081] Correspondingly, if Figure 3B As shown, it is a schematic diagram of another touch point state provided by an embodiment of the present application. When a user performs a multi-finger operation, multiple slots will be recorded in the slot queue when the multi-finger is pressed, for example, slot 2, slot 3, slot 4, and the state is recorded as "in-use". When the user performs a multi-finger lift operation, the states of slot 2, slot 3, and slot 4 are all updated to "no-use".

[0082] However, when a user operates on a multi-system touch screen, after the user triggers a press operation on the previous system, the slot point status corresponding to the touch point is "in-use". The user slides to the next system to trigger a lift operation. At this time, the previous system cannot detect the lift event normally, which will cause the slot point status corresponding to the touch point in the previous system to fail to update normally. This type of touch point is a touch point with an abnormal status.

[0083] For these touch points with abnormal states, if the system cannot update the state of such touch points, the slot points corresponding to such touch points will remain in the "in-use" state. When the user performs a single-finger operation next time, a new slot point corresponding to a touch point will be in the "in-use" state. The system will report the lift event of the abnormal touch point and the new touch point at the same time, causing the user's single-finger operation to be recognized as a multi-finger operation.

[0084] In order to solve the above problems, the present application proposes a method for processing a simulated lift event of a touch point in an abnormal state. The specific implementation method is as follows S22-S23:

[0085] S22: When a first lift event is identified, searching for a target slot corresponding to the touch point with an abnormal state in the slot queue. The first lift event is an event generated when an object performs a lift operation on the touch screen.

[0086] In the embodiment of the present application, since the touch events corresponding to each touch point generally appear in pairs of a press event and a lift event, for a certain touch point, when a press event is detected for the touch point, but no lift event is detected for the touch point, the touch point is a touch point with an abnormal state.

[0087] In this case, an optional implementation is to implement S22 through the following steps, including S221 to S222 ( Figure 2 Not shown):

[0088] S221: For each touch point, if a first lift-off event triggered by the object with respect to the touch point is not identified after the object triggers a press event with respect to the touch point, it is determined that the touch point is in an abnormal state.

[0089] S222: The slot corresponding to the touch point with abnormal status in the slot queue is used as the target slot.

[0090] like Figure 4As shown, it is a schematic diagram of the operation of a vehicle system provided by an embodiment of the present application. In the vehicle system, the host system is a real-time operating system (Quantum Software Systems, QNX), and the virtual system is an Android system (Android). When the windows of the two systems are displayed on one display at the same time, the user triggers a single-finger press operation in the Android system window for the first time, and the Android system detects a press event. At this time, the status of the slot 0 point corresponding to the trigger point in the slot queue is recorded as "in-use". Then, when the user's finger slides from the Android system window to the QNX system window, a single-finger lift operation is triggered in the QNX system. At this time, the lift event is passed to QNX. The Android system cannot detect the lift event corresponding to the single-finger lift operation, and the corresponding slot point status cannot be updated normally.

[0091] When the user triggers a single-finger press operation in the Android system window for the second time, the Android system detects a press event, and the status of the slot 1 point corresponding to the new touch point in the slot queue is recorded as "in-use". After the user triggers a lift operation corresponding to the new touch point, the Android system recognizes the corresponding lift event.

[0092] Obviously, in the above case, the Android system does not detect the corresponding lift event when the user performs the first touch operation. Therefore, the slot point corresponding to the first touch operation can be recorded as the target slot, that is, slot 0 is the target slot.

[0093] In the above embodiment, by detecting lift events and press events, touch points with abnormal states can be accurately identified to reduce the confusion between single-finger operation and multi-finger operation caused by the lift event not being detected normally (or the lift event not being generated normally, etc.).

[0094] It should be noted that, in addition to the above-mentioned anomalies caused by the dual systems, any other anomaly caused by the inability to detect the lifting event normally can be solved based on the methods listed in this application and will not be described one by one here.

[0095] In addition, in the embodiment of the present application, since the state attribute of each touch point is recorded through the corresponding slot in the slot queue, the target slot can also be determined by the state value stored in the slot.

[0096] like Figure 5As shown in the figure, after the user performs a three-finger press operation, the corresponding slot points in the slot queue: slot 2, slot 3, slot 4, the status of these slots is "in-use". When the user lifts up the three fingers, only the lift event of the touch point corresponding to slot 2 is detected, and the status of slot 2 is updated to "no-use", while the status of slot 3 and slot 4 is still "in-use", it can be considered that the touch points corresponding to slot 3 and slot 4 are touch points with abnormal status.

[0097] In this case, an optional implementation is to implement S22 through the following steps, including S221'~S222'( Figure 2 Not shown):

[0098] S221': Acquire first identification information corresponding to the first lifting event;

[0099] S222': Update the state value of the slot corresponding to the first identification information from the in-use state to the out-of-use state, traverse the slot queue, and analyze the state value stored in each slot when traversing to a slot; if the state value represents the in-use state, determine that the touch point corresponding to a slot is in an abnormal state, and use the slot as a target slot.

[0100] In the present application, each time a lifting event corresponding to a lifting operation of the user is identified, that is, the first lifting event, the state value of the slot point corresponding to the lifting event will be updated, and the slot point will be updated from the "in-use" state to the "no-use" state.

[0101] In the embodiment of the present application, the abnormal state of the touch point in the slot queue refers to the touch point where only the press event is detected but no lift event is detected. Generally, after the user presses the button, the slot queue records the down event in the corresponding slot point and updates the slot point state to the "in-use" state. If the user's lift operation is not recognized and the slot point state is not updated to the "no-use" state, then this touch point is an abnormal touch point and the slot point corresponding to this touch point is the target slot.

[0102] When the user performs the next press operation, different press events will be reported at the same time, that is, confusion between single-finger operation and multi-finger operation will occur.

[0103] Using the car system in S222, after the user touches and slides to the QNX system, when the Android system traverses the slot queue, it will recognize that slot 0 is still in the "in-use" state. At this time, slot 0 can be determined as the target slot.

[0104] In the above embodiment, by detecting the slot point status value, the touch points with abnormal status can be accurately identified to reduce the confusion between single-finger operation and multi-finger operation caused by the lift event not being detected normally (or the lift event not being generated normally, etc.).

[0105] In the embodiment of the present application, after a touch point with an abnormal state is detected, a lift event of a touch point corresponding to a target slot is simulated to ensure normal update of the target slot state value, thereby resolving the abnormal state.

[0106] S23: simulating a corresponding second lift event for the target slot, and updating the state value stored in the target slot according to the second lift event to release the abnormal state of the corresponding touch point.

[0107] In the embodiment of the present application, after the target slot is determined based on any of the methods listed above, the identification information corresponding to the target slot can be obtained, and then a lifting event corresponding to the identification information (ie, the second lifting event) can be simulated.

[0108] Specifically, if only one target slot is determined, such as its identification information is slot 0, it is only necessary to simulate a second lift event up-event 0, and bind the second lift event up-event 0 to the identification information slot 0 of the target slot. Based on the second lift event, the stored status value of the corresponding slot point in the slot queue is updated to "no-use" to resolve the abnormal state of the corresponding touch point.

[0109] If multiple target slots are determined, such as 3 target slots, and the identification information of these 3 target slots is slot 1, slot 2, and slot 3 respectively, then a second lift event up-event 1 is simulated for slot 1, a second lift event up-event 2 is simulated for slot 2, and a second lift event up-event 3 is simulated for slot 3, and the status values ​​stored in the corresponding three slot points in the slot queue are updated to "no-use", thereby releasing the abnormal status of the corresponding three touch points.

[0110] In the embodiment of the present application, the touch event processing method can be applied to different operating systems, such as Linux system, UNIX system, Android system, etc. Figure 6 As shown, it is a schematic diagram of an Android input system provided in an embodiment of the present application:

[0111] The physical layer is the lowest layer in the input system. The physical layer provides transmission media and interconnection devices for data communication between devices, and provides a reliable environment for data transmission, including but not limited to keyboards, mice, touch screens, etc. In the embodiments of the present application, the device mainly refers to a touch screen.

[0112] Android's kernel layer is a branch of the Linux kernel. It provides drivers for almost all mobile phones and tablet-related devices to achieve communication between the system and various hardware. The Linux kernel receives the corresponding hardware interrupt, then processes the interrupt into raw input event data and writes it to the corresponding device node.

[0113] The native service layer (Native) is responsible for information scheduling. This layer is implemented in C and C++ languages. Its input trigger (Input Flinger) subsystem includes three parts: event management center (Event Hub), input reader thread (InputReader Thread) and input dispatcher thread (Input Dispatcher Thread).

[0114] Among them, Event Hub directly accesses all device nodes. And as its name implies, it returns all pending low-level events related to the input system to the user. These events include raw input events, additions and deletions of device nodes, etc.

[0115] Input Reader Thread is one of the key components in the Input Manager Service (IMS). It runs in an independent thread and is responsible for managing the list and configuration of input devices, as well as processing input events. It continuously retrieves events from the Event Hub and processes them through its thread loop. For the addition and deletion events of device nodes, it updates the input device list and configuration. For the original input events, the InputReader translates, assembles, and encapsulates them into more informative and readable input events, and then hands them over to the Input Dispatcher for dispatch.

[0116] Input Dispatcher Thread is another key component in IMS. It also runs in a separate thread. Input Dispatcher stores information about all windows from the Window Manager Service (WMS). After receiving input events from Input Reader, it searches for a suitable window among the windows it stores and dispatches the event to this window.

[0117] The framework layer is used to support the operation of the programs in the application layer and is composed of multiple system services. In this application, it mainly involves IMS, Native Input Manager and Window Manager Service.

[0118] Input Manager Service, an Android system service, is divided into two parts: Java layer and Native layer. The Java layer is responsible for communicating with WMS. The Native layer, namely Native Input Manager, is the running container of the two key components of the input system, Input Reader and Input Dispatcher;

[0119] WMS plays a vital role in the normal operation of Input Dispatcher. When a new window is created, WMS creates a channel for event transmission between the new window and IMS. In addition, WMS also updates the information of all windows, including the clickable area of ​​the window, the focus window, etc., to the Input Dispatcher of IMS in real time, so that the Input Dispatcher can correctly dispatch events to the specified window.

[0120] In combination with the system architecture shown above, an optional implementation of S23 in the embodiment of the present application includes the following steps S231 to S234 ( Figure 2 not shown):

[0121] S231: Obtain second identification information corresponding to the target slot.

[0122] S232: Simulate a second lifting event corresponding to the target slot through the local service layer.

[0123] S233: Send the second identification information and the second lift event to the kernel layer to release the abnormal state of the touch point corresponding to the second identification information, and send the second identification information and the second lift event to the local service layer.

[0124] S234: After the local service layer receives the second identification information and the second lift event sent by the kernel layer, the status value stored in the target slot is updated to a non-use state according to the second identification information and the second lift event to release the abnormal state of the touch point corresponding to the second identification information.

[0125] Specifically, when simulating a lift event in combination with the above-mentioned system architecture, the second lift event corresponding to the target slot is mainly simulated through the local service layer, and the target slot corresponding to the second lift event is uniquely identified through the second identification information. The present application takes into account that, although the local service layer in the present application is used to store the slot queue, after simulating the second lift event through the local service layer, the status of the corresponding target slot in the slot queue can be directly updated. However, in combination with the above-mentioned system architecture, the kernel layer also records the corresponding touch events. Therefore, not only the local service layer needs to be updated accordingly, but the kernel layer should also be updated accordingly.

[0126] In the embodiment of the present application, based on S233 and S234, the synchronous update of the above-mentioned kernel layer and the local service layer can be achieved to ensure that the abnormal touch point can be restored normally.

[0127] In this application, if Figure 7 As shown, it is an overall flow chart of a touch event processing method provided in an embodiment of the present application. The user transmits the input event, that is, the touch event, to the kernel layer from the physical layer. The kernel layer writes the touch event into the corresponding device node. The Event Hub in the Input Flinger subsystem directly accesses the device node. The Input ReaderThread takes the touch event out of the Event Hub and processes it, and then hands it over to the Input Dispatcher for dispatch, and then sends it to the IMS. The WMS creates an event delivery channel for the IMS and displays the window to the application layer.

[0128] In combination with the above lift event simulation method, an optional implementation is: simulating a second lift event through an input trigger subsystem in a local server.

[0129] Specifically, when a touch point with an abnormal state is found, the Input Reader will simulate an up event, that is, the second lift event, for the slot point corresponding to the touch point, and send the slot point and the simulated lift event to the kernel layer. The kernel layer then passes this event to Android's Input Flinger subsystem. When Input Flinger receives the up event of the corresponding point, it will release the corresponding slot point, so that the abnormal state can be restored.

[0130] In an embodiment of the present application, after a touch point with an abnormal state is detected, a lift event of the touch point corresponding to a target slot is simulated through the Input Reader of the Native layer, and the lift event is sent to the kernel layer together with the identification information of the target slot, thereby ensuring the normal update of the target slot state value, thereby resolving the abnormal state.

[0131] Based on the same inventive concept as the above method embodiment, an electronic device is also provided in the embodiment of the present application. In one embodiment, the electronic device may be Figure 1 The electronic device 120 shown in FIG. 1 is a schematic diagram of an electronic device 120. In this embodiment, the structure of the electronic device can be as follows: Figure 8 As shown, it includes a memory 801 , a communication module 803 and one or more processors 802 .

[0132] The memory 801 is used to store computer programs executed by the processor 802. The memory 801 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and programs required for running the instant messaging function, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0133] The memory 801 may be a volatile memory, such as a random-access memory (RAM); the memory 801 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); or the memory 801 may be any other medium that can be used to carry or store a desired computer program in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 801 may be a combination of the above memories.

[0134] The processor 802 may include one or more central processing units (CPU) or a digital processing unit, etc. The processor 802 is used to implement the above touch event processing method when calling the computer program stored in the memory 801 .

[0135] The communication module 803 is used to communicate with terminal devices and other servers.

[0136] The specific connection medium between the memory 801, the communication module 803 and the processor 802 is not limited in the embodiment of the present application. Figure 8 In the embodiment, the memory 801 and the processor 802 are connected via a bus 804. The bus 804 is Figure 8 The connections between the other components are described with bold lines, which are only for illustrative purposes and are not intended to be limiting. The bus 804 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Figure 8 The diagram shows that only one thick line is used, but this does not mean that there is only one bus or only one type of bus.

[0137] The memory 801 stores a computer storage medium, and the computer storage medium stores computer executable instructions, and the computer executable instructions are used to implement the touch event processing method of the embodiment of the present application. The processor 802 is used to execute the above-mentioned touch event processing method, such as Figure 2 shown.

[0138] In some implementations, after the method executed by the processor forms a program, the hardware execution modules corresponding to the various program function modules may include: a determination module, an identification module and a simulation module, and the determination module, the identification module and the simulation module are connected.

[0139] like Fig. 9 As shown, it is a schematic diagram of the composition structure of an electronic device 90 for processing touch events in an embodiment of the present application. The electronic device for processing touch events includes a determination module 901, an identification module 902, and a simulation module 903, wherein:

[0140] A determination module 901 is used to obtain a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen;

[0141] The identification module 902 is used to search for a target slot corresponding to the touch point with an abnormal state in the slot queue when a first lift event is identified; the first lift event is an event generated when the object performs a lift operation on the touch screen;

[0142] The simulation module 903 is used to simulate a corresponding second lift event for the target slot, and update the state value stored in the target slot according to the second lift event to release the abnormal state of the corresponding touch point.

[0143] Optionally, the identification module 902 is specifically used for:

[0144] For each touch point, if the first lift event triggered by the object for the touch point is not recognized after the object triggers a press event for the touch point, the touch point is determined to be in an abnormal state; the slot corresponding to the touch point with an abnormal state in the slot queue is used as the target slot.

[0145] Optionally, the identification module 902 is further used for:

[0146] The slot queue is traversed, and each time a slot is traversed, the state value stored in the slot is analyzed; if the state value represents a state of use, it is determined that the touch point corresponding to the slot is in an abnormal state, and the slot is used as a target slot.

[0147] Optionally, the simulation module 903 is specifically used for:

[0148] Obtaining second identification information corresponding to the target slot;

[0149] Simulating a second lifting event corresponding to the target slot through a local service layer;

[0150] Sending the second identification information and the second lift event to the kernel layer to release the abnormal state of the touch point corresponding to the second identification information, and sending the second identification information and the second lift event to the local service layer;

[0151] After the local service layer receives the second identification information and the second lift event sent by the kernel layer, the status value stored in the target slot is updated to a non-use status according to the second identification information and the second lift event to resolve the abnormal status of the touch point corresponding to the second identification information.

[0152] Optionally, the simulation module 903 is further used for:

[0153] The second lift event is simulated by the input trigger subsystem in the local server.

[0154] For the convenience of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, when implementing the present application, the functions of each module (or unit) can be implemented in the same one or more software or hardware. It can be understood by those skilled in the art that various aspects of the present application can be implemented as a system, method or program product. Therefore, various aspects of the present application can be specifically implemented in the following forms, namely: a complete hardware implementation method, a complete software implementation method (including firmware, microcode, etc.), or an implementation method combining hardware and software, which can be collectively referred to as "circuit", "module" or "system" here.

[0155] Refer to the following Fig.10 hereinafter, a computing device 1000 according to this embodiment of the present application is described. Fig.10 The computing device 1000 is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0156] like Fig.10 The computing device 1000 is in the form of a general computing device. The components of the computing device 1000 may include but are not limited to: at least one processing unit 1001, at least one storage unit 1002, and a bus 1003 connecting different system components (including the storage unit 1002 and the processing unit 1001).

[0157] Bus 1003 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.

[0158] The storage unit 1002 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 1021 and / or a cache memory 1022 , and may further include a read-only memory (ROM) 1023 .

[0159] The storage unit 1002 may also include a program / utility 1025 having a set (at least one) of program modules 1024, such program modules 1024 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0160] The computing device 1000 may also communicate with one or more external devices 1004 (e.g., keyboards, pointing devices, etc.), one or more devices that enable a user to interact with the computing device 1000, and / or any device that enables the computing device 1000 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 1005. Furthermore, the computing device 1000 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 1006. Fig.10 As shown, the network adapter 1006 communicates with other modules for the computing device 1000 via the bus 1003. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the computing device 1000, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0161] The embodiment of the present application also provides a computer program product, and the method in the present application can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed on a computer, the process or function described in the present application is executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, a core network device, an OAM or other programmable device.

[0162] A computer-readable storage medium can be implemented as a computer program product, that is, an embodiment of the present application also provides a computer-readable storage medium, which includes a computer program, and when the computer program is executed by a processor, it implements any of the above-mentioned vehicle upgrade software integration methods.

[0163] The computer program or instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer program or instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disk; it may also be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0164] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0165] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0166] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0167] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0168] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for processing a touch event, characterized in that: The method comprises: Acquire a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen; When a first lift event is identified, searching for a target slot corresponding to the touch point in the slot queue whose state is abnormal; the first lift event is an event generated when the object performs a lift operation on the touch screen; A corresponding second lift event is simulated for the target slot, and a state value stored in the target slot is updated according to the second lift event to release the abnormal state of the corresponding touch point.

2. The method according to claim 1, characterized in that The step of searching for a target slot corresponding to a touch point in an abnormal state in the slot queue includes: For each touch point, if after the object triggers a press event for the touch point, a first lift event triggered by the object for the touch point is not identified, then determining that the touch point is in an abnormal state; The slot corresponding to the touch point with abnormal status in the slot queue is used as the target slot.

3. The method according to claim 1, characterized in that Before searching for a target slot corresponding to a touch point with an abnormal state in the slot queue, the method further includes: Acquire first identification information corresponding to the first lifting event; The state value of the slot corresponding to the first identification information is updated from the in-use state to the out-of-use state, wherein the slot corresponding to the first identification information is created and recorded as being in-use state when a press event for the touch point corresponding to the first identification information is recognized before the first lift event.

4. The method according to claim 3, characterized in that The step of searching for a target slot corresponding to a touch point in an abnormal state in the slot queue includes: Traversing the slot queue, and analyzing the state value stored in each slot when traversing to the slot; If the state value indicates that the state is being used, it is determined that the touch point corresponding to the one slot is in an abnormal state, and the one slot is used as a target slot.

5. The method according to any one of claims 1 to 4, characterized in that: The simulating a corresponding second lifting event for the target slot and updating a state value stored in the target slot according to the second lifting event includes: Obtaining second identification information corresponding to the target slot; Simulating a second lifting event corresponding to the target slot through a local service layer; Sending the second identification information and the second lift event to the kernel layer to release the abnormal state of the touch point corresponding to the second identification information, and sending the second identification information and the second lift event to the local service layer; After the local service layer receives the second identification information and the second lift event sent by the kernel layer, the status value stored in the target slot is updated to a non-use status according to the second identification information and the second lift event to resolve the abnormal status of the touch point corresponding to the second identification information.

6. The method according to claim 5, characterized in that The slot queue is stored in the input trigger subsystem in the local service layer; and the simulating the second lift event corresponding to the target slot through the local service layer includes: The second lift event is simulated by the input trigger subsystem in the local server.

7. A device for touch event processing, characterized in that: include: A determination unit, configured to obtain a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen; an identification unit, configured to search for a target slot corresponding to a touch point in an abnormal state in the slot queue when a first lift event is identified; The first lifting event is an event generated when the object performs a lifting operation on the touch screen; The simulation unit is used to simulate a corresponding second lifting event for the target slot, and update the state value stored in the target slot according to the second lifting event to release the abnormal state of the corresponding touch point.

8. An electronic device for touch event processing, characterized in that: The device comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following steps: Acquire a slot queue for recording a touch point state attribute, wherein the slot queue includes at least one slot, each slot corresponds to a touch point, and the touch point is a point generated when an object performs a pressing operation on the touch screen; When a first lift event is identified, searching for a target slot corresponding to the touch point in the slot queue whose state is abnormal; the first lift event is an event generated when the object performs a lift operation on the touch screen; A corresponding second lift event is simulated for the target slot, and a state value stored in the target slot is updated according to the second lift event to release the abnormal state of the corresponding touch point.

9. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A vehicle, characterized in that: The vehicle comprises the device for touch event processing as claimed in claim 7 or the electronic device for touch event processing as claimed in claim 8, or is used to execute the method according to any one of claims 1 to 6.

Images