Android event distribution mechanism source code analysis

Android event distribution mechanism source code analysis

I am a little touched by the fact that I have been using android for some time. I have always been used to organizing my notes and saving my notes on youdao. I have no habit of writing a blog. In the future, we will sort it out gradually, and we will also calculate "Review -_-.

Android event Distribution involves three methods:

1. public booleandispatchTouchEvent (MotionEvent ev)

2. public boolean onInterceptTouchEvent (MotionEvent ev)

3. public booleanonTouchEvent (MotionEvent event)

The first method indicates whether to distribute events, the second method indicates whether to intercept events (only ViewGroup has this method, and View does not), and the third method indicates whether to consume events.

Before analyzing the source code, let's summarize the rule of event distribution, or the usage of the above three methods:

① When a TouchEvent occurs, the Activity first passes the TouchEvent to the top-level View, which is generally a ViewGroup. TouchEvent first arrives at the top-level view's dispatchTouchEvent, which is then distributed by the dispatchTouchEvent method. If true is returned, all events are not distributed. All events are handed over to dispatchTouchEvent for processing. If dispatchTouchEvent is returned, the view and its sub-view cannot receive subsequent events. If super. dispatchTouchEvent is handed over to interceptTouchEvent for processing.

② If interceptTouchEvent returns true, that is, interceptTouchEvent is intercepted, the onTouchEvent that the subsequent event is handed over to it to handle interceptTouchEvent will not be processed anymore (if you pick it up and click again, the down event will go again, if onTouchEvent is not processed and the event is returned as the original path, the subsequent event will not be handed over to this view. If interceptTouchEvent returns false or super is called. interceptTouchEvent, the subsequent event is still processed by interceptTouchEvent, but not by onTouchEvent. Common views without interceptTouchEvent method do not consider this method. Other rules are the same.

③ If onTouvhEvent is returned, true indicates the consumption event, false indicates that the consumption is not performed, and super is called. onTouchEvent is a two-case scenario. For ViewGroup and other views that can be placed in a subview, the event is not consumed. For views that cannot be placed in a subview, the event is consumed. Events that are not consumed will be returned after they reach the bottom view. Only onTouchEvent is used, which may be consumed by the upper View.

If you only care about the use of these methods and then customize the view, you should be able to see it here, anyway, I know what impact these methods will have on Event distribution, and I don't care about it.

But as a programmer who actively learns high quality, we need to understand not only how to use it, but also why it happens (here we should applaud ). We will analyze the data point by point based on the above three points.

 

First, let's take a look at the first point: dispatchTouchEvent. If this method returns false, the event is not distributed. It can be understood that neither the view nor the subview consumes the event, and subsequent events will not be sent to you, it's easy to understand why you don't want to consume it. The code implementation saves all views of consumption events, therefore, views that do not consume events will not be followed by subsequent events. This part of the code is not posted. For details, see the code for calling the addTouchTarget method in the 2213rd line of ViewGroup code. According to the general idea, since the return of false indicates that the event is not consumed, the return of true indicates that the event is consumed? NO, too young to simple. If you try to write a demo, you will find that the dispatchTouchEvent method keeps going, but the event is not distributed, and the subview cannot receive the event. Only super. dispatchTouchEvent with the returned value can be distributed... Nana, what the hell is this? Don't play the cards as usual. All right, you have to go through the source code. We will analyze the source code of android6.0 (API Level 23.

The following code is taken from the dispatchTouchEvent method of ViewGroup and obtained the I sub-view in line 2167. Then, in row 2197, a method is called to pass the first sub-view obtained above as one of the parameters.

The following code is the method called in dispatchTouchEvent. For details, see Row 3. When the child is not empty, the dispatchTouchEvent of child is called (it will go to 2553 or 2575 rows. They are essentially the same. The difference is that a split operation is performed on the passed MotionEvent, but nothing is done to further investigate it. Some friends who know their differences can leave a message to us ). Is there a sense of openness? ViewGroup can distribute events to subviews because the subview event distribution method is called in dispatchTouchEvent. If you only return true in the dispatchTouchEvent method of ViewGroup, no super is returned. dispatchTouchEvent, the sub-view event distribution method will not be called, and the sub-view will not get the event. I think it's quite clear. Other irrelevant code is ignored in the middle. If you want to learn more, you can read the source code and read the source code from the blog. Everything is so easy ~.

The following method will be used later. This method is called multiple times in the dispatchTouchEvent method.

Let's look at the second onInterceptTouchEvent method: This method indicates whether to intercept the event. If true is returned, the event is directly handled by onTouchEvent. Why? Take a look at the following code block:

Line 5: press the screen of the mobile phone and go to line 5. The disallowIntercept here is false by default (the value initialized by default is calculated), and the page will go to line 3, call onInterceptTouchEvent. If we re-write this method and return true, the value of intercept is true, and the next step will go to 2238 rows. At this time, mFirstTouchTarget is null and will go to 2240. Here the dispatchTransformedTouchEvent method is called, that is, the second code block in this article. At this time, the third parameter child is null, and the method will go to 2547 or 2566 rows (which is the specific one, whatever ), then the dispatchTouchEvent method of the parent class is called. Let's look at the method of the parent class:

If the code in the red box is absent, onTouchEvent is called directly. Therefore, if your onInterceptTouchEvent returns true, it will call its own onTouchEvent, and the event will be uploaded to its own onTouchEvent.

Third, why does the event not take time to return it to the parent view? I am a little confused... The reason is recursion. When the parent View transmits an event, it recursively calls the disPatchTouchEvent. When the event is not consumed by the quilt View, it calls its own onTouchEvent method. Therefore, the log shows that the event is returned.

As for my understanding of this aspect, there is so much in general that the source code analysis is not very detailed, and a preliminary structure is probably taken into consideration, and problems or even errors may be understood, thank you for your correction.