Android:30 minutes to figure out the touch event distribution mechanism

There are only two main characters in touch event distribution: ViewGroup and view. The activity's touch event is actually called the ViewGroup touch event inside it, and can be treated directly as ViewGroup.

View within the ViewGroup, ViewGroup can also be in other viewgroup, this time the internal viewgroup as a view to analyze.

There are three related events in ViewGroup: Onintercepttouchevent, Dispatchtouchevent, Ontouchevent. There are only two related events for view: Dispatchtouchevent, Ontouchevent.

First analyze the ViewGroup process: first, there must be a structural model concept: ViewGroup and view constitute a tree structure, the top of the activity of the viewgroup, there are a number of viewgroup nodes, There are several ViewGroup nodes or view nodes under each node, and so on.

When a touch event (for example, a touch event) reaches the root node, the acitivty ViewGroup, it is issued sequentially, and the process is implemented by invoking the Dispatchtouchevent method of the Child view (ViewGroup). Simply put, viewgroup iterates through the child view it contains, invokes the Dispatchtouchevent method of each view, and when the child view is ViewGroup, The Dispatchtouchevent method of its internal view is resumed by calling Viwgroup's Dispatchtouchevent method. The order of the messages in the above example is this: ①-②-⑤-⑥-⑦-③-④. The Dispatchtouchevent method is only responsible for the distribution of the event, which has a Boolean return value, and when returned to true, the order is interrupted. In the above example, if ⑤ 's Dispatchtouchevent returns True, ⑥-⑦-③-④ will not receive this touch event. A simple version of the code to deepen understanding:

 

/*** ViewGroup *@paramEV *@return*/PublicBooleanDispatchtouchevent (motionevent ev) {....//Other treatment, here regardless of view[] views=Getchildview ();Forint i=0;i<views.length;i++){Judge the touch to the point on the screen above the sub view if (...) {If (Views[i].dispatchtouchevent (EV)) return true// other processing, no matter  /** * View *  @param  EV * Span style= "color: #808080;" > @return */public  Dispatchtouchevent (motionevent ev) {.... // other processing, no matter return Span style= "color: #0000ff;" >false           

 

As can be seen here, ViewGroup's dispatchtouchevent is really performing "distribution" work, and view's Dispatchtouchevent method does not perform distribution work, or it distributes the object itself, Decide whether to hand over the touch event to yourself, and the way to handle it is the Ontouchevent event, in fact the code that the Dispatchtouchevent method of the child view actually executes is this

 

/**     * View     @param ev     @return     boolean dispatchtouchevent (motionevent ev) { .... //return ontouchevent (event);}        

 

In general, we should not override the Dispatchtouchevent method in a normal view because it does not perform distribution logic. When the touch event arrives at the view, all we have to do is to handle it in the Ontouchevent event.

So, when did ViewGroup's Ontouchevent event be dealt with? The Ontouchevent event executes when all ViewGroup child view returns false. Since ViewGroup is inherited from view, it is also a way to execute ontouchevent events by invoking the Dispatchtouchevent method of view.

In the present case, it seems that as soon as we return all the ontouchevent to false, we can guarantee that all the child controls will respond to this touch event. It must be stated, however, that the touch event here is limited to acition_down events, which touch down events, while ACITON_UP and Action_move do not. In fact, a complete touch event should consist of a down, an up, and a few moves. The down mode is distributed through Dispatchtouchevent, and is distributed in order to find the view that really needs to handle the full touch request. When a view or ViewGroup Ontouchevent event returns True, it indicates that it is the view that actually handles the request, and then the ACITON_UP and Action_move will be processed by it. When all child view Ontouchevent return false, the touch request is handled by the root ViewGroup, which is the activity itself.

Look at the Dispatchtouchevent method of the improved ViewGroup

 

View mtarget=Null//Save view that captures touch event processingPublicBooleanDispatchtouchevent (motionevent ev) {//.... Other treatment, in which no matterif (ev.getaction () = =Keyevent.action_down) {//Each down event is set to NULL
 if (!onintercepttouchevent ()) {mtarget=Null; View[] Views=Getchildview ();Forint i=0;i<views.length;i++if (Views[i].dispatchtouchevent (EV)) Mtarget=views[ I]; return true;}} //if (Mtarget==nullreturn super// ... Other handling, in this no matter if (Onintercepttouchevent ()) {      

         //... Other processing, no matter where              }

This step is not performed in Action_down, only move and up will be executed.        return mtarget.dispatchtouchevent (EV);}  

 

ViewGroup also has a onintercepttouchevent, look at the name to know that this is an interception incident. This interception event needs to be explained in two ways:

1. If we return true to the touch event of the action as down in a viewgroup onintercepttouchevent, it means that all the issued operations of the ViewGroup are intercepted, in which case Mtarget will always be null, because Mtarget is assigned in the down event. Because Mtarge is null, the Ontouchevent event of the ViewGroup is executed. In this case, the viewgroup can be treated directly as a view.

2. If we are in a viewgroup onintercepttouchevent, the touch event that Acion is down is returned false, the others return true, in which case the down event can be distributed normally, If the child view returns false, the Mtarget is still empty and has no effect. If a child view returns True,mtarget is assigned, a Mtarget action_delete is distributed to motionevent when Action_move and aciton_up are distributed to the ViewGroup. Also empties the value of the mtarget so that the next action_move (if the previous operation is not up) is handled by ViewGroup Ontouchevent.

The situation one uses more, the situation two person has not found the usage scene yet.

Summarize from beginning to end:

There are only two characters in the 1.Touch event distribution: ViewGroup and view. ViewGroup contains three related events for Onintercepttouchevent, Dispatchtouchevent, Ontouchevent. View contains Dispatchtouchevent, ontouchevent two related events. Where ViewGroup is inherited from view.

The 2.ViewGroup and view form a tree structure, and the root node is a viwgroup contained within the activity.

3. Touch events consist of Action_down, Action_move, aciton_up, one complete touch event, down and up are only one, Move has several, can be 0.

4. When acitivty receives a touch event, it traverses the sub view to distribute the down event. The traversal of ViewGroup can be seen as recursive. The purpose of the distribution is to find the view that really deals with this complete touch event, which returns true on the ontouchuevent result.

5. When a child view returns true, the distribution of the down event is aborted, and the child view is recorded in the ViewGroup. The next move and up event will be processed directly by the child view. Because child view is a VIEWGROUP node structure saved in ViewGroup, the ancestor ViewGroup holds the ViewGroup object where the view of the real processing event is located: As in the structure of Viewgroup0-viewgroup1-textview, TextView returns True, it is saved in ViewGroup1, and ViewGroup1 returns True, which is saved in ViewGroup0. When the move and up events come, they are passed from ViewGroup0 to ViewGroup1 and then ViewGroup1 to TextView.

6. When all child view in ViewGroup does not capture the down event, the ViewGroup itself's Ontouch event is triggered. The trigger is to invoke the Super.dispatchtouchevent function, which is the Dispatchtouchevent method of the parent view. Triggers the Ontouchevent method of the acitivity in cases where all sub-view is not processed.

7.onInterceptTouchEvent has two functions: 1. Intercept the distribution of the down event. 2. Abort the up and move events to the target view so that the viewgroup of the target view captures the up and move events.

In addition, the code listed above is not the real source, just summed up the source in the event distribution processing of the core processing process, the real source code you can see for themselves, contains a richer content.

Add:

"Touch events consist of Action_down, Action_move, ACITON_UP, and one complete touch event, down and up are only one, and the Move has several, which can be 0. "Here is a fact that the up event is probably 0," he added.

It's a lot more understandable that you're just doing a gesture to zoom in on the demo of Moving Pictures. For the Onintercepttouchevent event, its application scenario is reflected in many viewgroup with scroll effects. Imagine another viewpager, each item is a imageview, we need to do the matrix operation of these imageview, it is inevitable to capture the touch event, but we need to do not affect the Viewpager page turn effect, This must also ensure that the Viewpager can capture the move event, so Viewpager's onintercepttouchevent will filter the move event when the move event of the appropriate condition (which lasts several events or moves several distances, Here I did not read the source just guess) when triggered, and will intercept it, returning the child view of a Action_cancel event. There is no up event at this time, and many things that need to be handled in up are transferred to cancel.

Android:30 minutes to figure out the touch event distribution mechanism