Android event Transfer Mechanism

1. Android event generation

This part is difficult and involves the basic knowledge of the entire android architecture, including the handling of events in the Linux system.

This part of content comes from the android window mechanism analysis ------ Event processing.

Because Android is a Linux kernel, event processing is also completed on the basis of Linux. Therefore, we will sort out the processing process from the Linux kernel to the application.
The Linux Kernel provides an input subsystem for implementation. The input subsystem creates a node for our hardware input device in the/dev/input/path, in general, these nodes are named after eventxx in our cell phone, such as event0 and event1. But if it is a virtual machine, we can see a mice, which indicates the mouse device, this is because the PC needs to use the mouse to simulate the touch screen. Because these device nodes are hardware-related, each device is different. When we see the input device nodes, we may be confused about the meaning of these eventxx, that is, what kind of device has created this node? We can read hardware related to eventxx from/proc/bus/input/devices. I will not talk about it here, we only need to know that android reads the event information from the device nodes in the/dev/input/directory, which is the origin of Android event processing, this allows you to know where events such as buttons and touch screens come from, rather than our focus.
First, let's briefly introduce the process of Android event transfer. Events such as buttons and touch screens are obtained through windowmanagerservice and transmitted to viewroot through shared memory and pipelines, viewroot then dispatch the view to the application. When an event is input from a hardware device, system_server notifies viewroot of the event in the pipeline (PIPE) when detecting the event. In this case, viewroot reads the event information from the memory.
As for why Android uses the shared memory instead of the Binder Mechanism for event processing, I guess Google is trying to ensure real-time event response. Therefore, when selecting the method for inter-process event transfer, the mode of high shared memory is selected. Because there is a data management process in the shared memory that basically does not involve data copying in the memory, only two data copies are involved during process read/write, this is an inevitable data copy. Therefore, this method can ensure the system's response to the event, but it is not enough to share the memory, because the communication mode of shared memory does not notify the other party of data updates, Android adds another inter-process communication channel (PIPE) to the event processing process ), pipeline is not as efficient as shared memory, will it affect the real-time processing of events? It doesn't matter. Every time system_serve notifies viewroot that only one character is passed to it, that is, it is lightweight and simple, and the data of one character is copied multiple times. I think Google can still accept it.
Okay. After learning some basic knowledge, we will analyze the event transfer process from the bottom layer to the upper layer. Here, we will first list the structure of the entire event processing for ease of understanding below.

For more information, see this blog.

Here, the reader needs to make it clear that android events are generated and finally transmitted to viewroot.

2. Android event model

The event model in the blog Android shows us the Android event model, which is referenced here.

In the past, Android was written, and the processing of events was not too deep, but the simple ontouchevent was OK. Now, the UI, many custom components, the parent view and the Child view both need to receive events, then process. If you do not understand its event transfer mechanism, it is difficult to have a good user experience.
In touchevent, if the returned value is true, the event is consumed. If the returned value is false, the event is not consumed and will be passed on. This is the most basic principle.
There are three types of touch-related events in view: dispatchtouchevent, intercepttouchevnet, and ontouchevent. Dispatchtouchevent is responsible for distributing events. After an event is passed out of the activity, the first event that arrives at the top-level view is the dispatchtouchevent, which is then distributed. If false is returned, the intercepttouchevent method of the view is handed over to determine whether to intercept this event. If intercepttouchevent
Return true, that is, if it is intercepted, it will be handed over to its ontouchevent for processing. If intercepttouchevent returns false, it will be passed to the subview, And the dispatchtouchevent of the subview will start distributing the event.
If the event is passed to the ontouchevent of the subview of a certain layer, the method returns false, and the event will be passed up from this view, which is received by ontouchevent. If false is returned when the ontouchevent is passed to the top, the event will disappear and the next event will not be received. (An event refers to a series of events from down to up)
I drew a picture, see the attachment.

To sum up, if this event is not consumed by anyone, the system will not give you the next event, because he will think that this event is blocked and there is no need to give it to the next one. If ontouchevent is not consumed, it will be passed from the Child View to the parent view.

3. Event transfer example

Onintercepttouchevent () is used to process events and change the event transmission direction. You can write code in the function to process events. The returned value determines the transfer direction. If the returned value is false, the event will be passed to the onintercepttouchevent () of the subcontrol. If the returned value is true, the event will be passed to the ontouchevent () of the current control (), instead of passing it to the child Control, this is the so-called intercept (truncation ).
Ontouchevent () is used to process events. The returned value determines whether the current control consumes the event (consume. Maybe you want to ask if there is a difference between consumption and processing. Anyway, I have written the processing code for the event? The answer is yes! For example, the premise that action_move or action_up occurs is that action_down has occurred. If you have not consumed action_down, the system will think that action_down has not happened, so action_move or action_up cannot be captured.
Source Address of this article: http://www.cnblogs.com/rocky_yi/archive/2011/01/21/1941522.html#, reprint please indicate the source!

[HTML]
View plaincopyprint?

1. <? XML version = "1.0" encoding = "UTF-8"?>
2. <Com. touchstudy. layoutview1 xmlns: Android = "http://schemas.android.com/apk/res/android"
3. Android: Orientation = "vertical"
4. Android: layout_width = "fill_parent"
5. Android: layout_height = "fill_parent">
6. <Com. touchstudy. layoutview2
7. Android: Orientation = "vertical"
8. Android: layout_width = "fill_parent"
9. Android: layout_height = "fill_parent"
10. Android: gravity = "center">
11. <Com. touchstudy. mytextview
12. Android: layout_width = "wrap_content"
13. Android: layout_height = "wrap_content"
14. Android: Id = "@ + ID/TV"
15. Android: text = "AB"
16. Android: textsize = "40sp"
17. Android: textstyle = "bold"
18. Android: Background = "# ffffff"
19. Android: textcolor = "# 0000ff"/>
20. </COM. touchstudy. layoutview2>
21. </COM. touchstudy. layoutview1>

<? XML version = "1.0" encoding = "UTF-8"?> <Br/> <COM. touchstudy. layoutview1 xmlns: Android = "http://schemas.android.com/apk/res/android" <br/> Android: Orientation = "vertical" <br/> Android: layout_width = "fill_parent" <br/> Android: layout_height = "fill_parent"> <br/> <COM. touchstudy. layoutview2 <br/> Android: Orientation = "vertical" <br/> Android: layout_width = "fill_parent" <br/> Android: layout_height = "fill_parent" <br/> Android: gravity = "center"> <br/> <COM. touchstudy. mytextview <br/> Android: layout_width = "wrap_content" <br/> Android: layout_height = "wrap_content" <br/> Android: id = "@ + ID/TV" <br/> Android: text = "AB" <br/> Android: textsize = "40sp" <br/> Android: textstyle = "bold" <br/> Android: Background = "# ffffff" <br/> Android: textcolor = "# 0000ff"/> <br/> </COM. touchstudy. layoutview2> <br/> </COM. touchstudy. layoutview1>When onintercepttouchevent () and ontouchevent () are not overwritten (their return values are both false), for the above layout, the transmission order of motionevent events is as follows:

When the onintercepttouchevent () value of a control is true, a truncation occurs and the event is uploaded to the ontouchevent () of the current control (). For example, if we return the value of onintercepttouchevent () of layoutview2 to true, the transfer process is changed:

If we set the onintercepttouchevent () and ontouchevent () of layoutview2 to true at the same time, layoutview2 will consume the passed events and subsequent events (such as action_move or action_up following action_down) it is directly sent to the ontouchevent () of layoutview2 and not to any function of any other control. At the same time, an action_cancel event is passed to the sub-space. The transfer process is changed to (the action_cancel event is not shown in the figure ):

With the SDK instructions:
· You will receive the down event here.
· The down event will be handled either by a child of this view group, or given to your own ontouchevent () method to handle; this means you shoshould implement ontouchevent () to return true, so you will continue to see the rest of the gesture (instead of looking
For a parent view to handle it ). also, by returning true from ontouchevent (), you will not receive any following events in onintercepttouchevent () and all touch processing must happen in ontouchevent () like normal.
· For as long as you return false from this function, each following event (up to and including the final up) will be delivered first here and then to the target's ontouchevent ().
· If you return true from here, you will not receive any following events: the target view will receive the same event but with the action action_cancel, and all further events will be delivered to your ontouchevent () method and no longer appear here.