Shulou(Shulou.com)06/02 Report--

How to realize the principle analysis of Android touch event distribution, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

One: preface

Recently, I am learning the Touch event Distribution of Android. I think what is said on the Internet is too messy and messy, and there are many blogs with obvious mistakes. It is very difficult to understand what is distributed from the top down, what is distributed from the bottom to the top, what is intercepted and what has been consumed all the time. In order to review in the future can better understand this knowledge, but also for later people can better learn, I wrote this blog.

Second: speak of the previous knowledge

Clicking, swiping, and letting go are all represented by the class MotionEvent.

A sequence of events on the screen is a stream of events that starts with a MotionEvent.action_down press, moves with several MotionEvent.action_move events in the middle, and ends with a MotionEvent.action_up.

View group is a subclass of view. Both view group and view have dispatchTouchEvent methods; view group has onTnterceptTouchEvent and onTouchEvent methods, and view has only onTouchEvent methods.

Third, the overall process 1:activity

All the events we click on the screen will be received first.

Public boolean dispatchTouchEvent (MotionEvent ev) {if (ev.getAction () = = MotionEvent.ACTION_DOWN) {onUserInteraction (); / is an empty method. If you want to know that the screen is pressed, you can rewrite this method to print the log} if (getWindow (). SuperDispatchTouchEvent (ev)) {/ / pass this event to the window property return true;} return onTouchEvent (ev) } 2:window is PhoneWindow

Each activity corresponds to a PhoneWindow (created in front of the onCreate method and in the attach method inside the activity). PhoneWindow contains a decor view attribute (created in setContentView), and phone window passes events to decor view. Decor view inherits from view group. The click event is now passed to decor view, and the event distribution logic for view group begins.

3:view group

View group receives the click event and enters dispatchTouchEvent if either of the following two conditions is met:

Event is a down event

There is a sub-view or sub-view group dealing with the event stream.

MFirstTouchTarget! = null

Go to the judgment and execute the onInterceptTouchEvent code if the interception is not disabled (the child view calls parent.requestDisallowed....).

If you decide to intercept, the mFirstTouchTarget will be set to null later, so that onInterceptTouchEvent will not be called again. And the subsequent event flow will be handled by the dispatchTouchEvent of this view group.

If you don't decide to intercept, go through the sub-view and sub-view group, calling their dispatchTouchEvent one by one. If no one receives it, call your own super.dispatchTouchEvent. View group's super.dispatchTouchEvent is the dispatchTouchEvent of his own view part.

4:view

At the view level, for the down event, returning true means consuming the sequence after the down event. Look at the picture.

View calls setOnTouchLIstener to set OnTouchListener and override the onTouch method. As you can see from the source code, if onTouch returns true, the onTouchEvent method will not be called back. If you do not call back onTouchEvent, then onClickListener cannot be called back.

Four: some key points

Even if a view consumes a set of events, when the event stream is passed from bottom to up, the intercept intercept method of each view group is still called to determine whether or not to intercept. When a view group traverses all of its child view without a single receiver, it enters view mode and calls the dispatchTouchEvent method that it inherits from view. If you do not receive it, it will be handed over to the parent view that calls your own dispatchTouchEvent.

The flow of events is nothing from the top down, just from the bottom up.

The implementation of ViewGroup is responsible for dispatching touch events to child controls along the control tree, while the implementation of View is mainly used for event reception and processing. When the view group has no child view to receive, the view group is processed as a "view".

Five: touch event distribution from the source code

Because the column focuses on custom controls, there is no detailed breakdown of how the system gets touch events from hardware and the dispatchTouchEvent passed to Activity. Let's take a step-by-step look at how events are distributed and delivered from the dispatchTouchEvent method of Activity:

DispatchTouchEvent in Activity:

Public boolean dispatchTouchEvent (MotionEvent ev) {if (ev.getAction () = = MotionEvent.ACTION_DOWN) {onUserInteraction ();} if (getWindow (). SuperDispatchTouchEvent (ev)) {return true;} return onTouchEvent (ev);}

Where onUserInteraction (); is an empty implementation, which is a method left by the system to modify event distribution, which can be ignored here.

So in fact, the dispatchTouchEvent method of Activity is the superDispatchTouchEvent method of the called PhoneWindow. If superDispatchTouchEvent returns false and does not consume the event, it will be handed over to the onTouchEvent method of activity to handle it. From this point of view, if no event is consumed anywhere, it will be the onTouchEvent method of Activity that receives the event finally.

So let's take a look at the superDispatchTouchEvent method in PhoneWindow:

@ Override public boolean superDispatchTouchEvent (MotionEvent event) {return mDecor.superDispatchTouchEvent (event);}

It is found that what is actually called is the superDispatchTouchEvent method of the DecorView object mDecor. Take a look at the superDispatchTouchEvent method of DecorView:

Public boolean superDispatchTouchEvent (MotionEvent event) {return super.dispatchTouchEvent (event);}

The super.dispatchTouchEvent called, and then look at the inheritance relationship of this DecorView:

Private final class DecorView extends FrameLayout implements RootViewSurfaceTaker

So the dispatchTouchEvent method in FrameLayout is called, and FrameLayout does not override the dispatchTouchEvent method, so what is actually called is the dispatchTouchEvent method in the parent class of FrameLayout-> ViewGroup. The following figure describes the process from the system getting the actual MotionEvent to the super.dispatchTouchEvent passed to DecorView:

After reading the above, have you mastered how to analyze the principle of Android touch event distribution? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.