21 questions and answers about Android View event mechanism

[[178693]]

1.What are the main coordinate parameters of View? What are the key points to pay attention to?

Answer: Left, Right, top, Bottom. Note that these 4 values ​​are actually the relative coordinates of the view and its parent control. They are not the absolute values ​​from the upper left corner of the screen. Please note this.

In addition, X and Y are actually coordinate values ​​relative to the parent control. The default values ​​of TranslationX and TranslationY are both 0, which are the offsets relative to the upper left corner of the parent control.

Conversion relationship:

x=left+tranX,y=top+tranY.

Many people don’t understand why this is the case. In fact, if the View moves, such as translation, you should pay attention that the values ​​​​of top and left will not change.

No matter how you drag the view, the values ​​of x, y, tranX, and tranY will change as you drag and move. Just understand this.

2. When is it better to use onTouchEvent or GestureDetector?

Answer: Use the former when there is only a sliding requirement, and use the latter when there is a double-click or other behavior.

3.What problem does Scroller solve?

Answer: The scrollTo and scrollBy of view have very poor sliding effects, which are completed instantly. However, the scroller can cooperate with the computeScroll of view to complete the gradual sliding effect. The experience is better.

4.What should I pay attention to when using ScrollTo and ScrollBy?

A: The former is absolute sliding, and the latter is relative sliding. What slides is the content of the view rather than the view itself. This is very important. For example, when a textview calls these two methods, what slides is the content of the displayed words.

Generally speaking, we use scrollBy more often. When passing values, just remember a few rules: right-left x is positive, otherwise x is negative; up-down y is negative, otherwise y is positive.

You can take a look at the source code of these two:

 public void scrollTo( int x, int y) { 
 
        if (mScrollX != x || mScrollY != y) { 
 
 int oldX = mScrollX; 
 
 int oldY = mScrollY; 
 
 mScrollX = x; 
 
 mScrollY = y; 
 
            invalidateParentCaches(); 
 
            onScrollChanged(mScrollX, mScrollY, oldX, oldY); 
 
            if (!awakenScrollBars()) { 
 
                postInvalidateOnAnimation(); 
 
 } 
 
 } 
 
 } 
 
 
 public void scrollBy( int x, int y) { 
 
        scrollTo(mScrollX + x, mScrollY + y); 
 
 }

You can see there are two variables mScrollX and mScrollY. The values ​​of these two units are pixels. The former represents the distance between the left edge of the view and the left edge of the view content. The latter represents the distance between the top edge of the view and the top edge of the view content.

5. What are the consequences of using animation to implement view sliding?

A: Actually, view animation is to move the surface UI of the view, that is, the visual effect presented to the user. The animation itself cannot move the actual position of the view. Except for attribute animation. After the animation is finished, the view will eventually return to its original position. Of course, you can set the fillafter property to make the view appearance stay at the changed position after the animation is finished. So this will bring a very serious consequence. For example, your button is on the left side of the screen. Now you use an animation and set the fillafter property to move it to the right side. You will find that clicking the right button does not trigger a click event, but clicking the left button can trigger it. The reason is that the right button is only the appearance of the view, and the real button is still on the left and has not moved. If you must do this, you can put a new button in advance at the position after the right button moves. When the animation is finished, enable the right button and let the left button go.

This can avoid the above problems.

6. How many ways are there to make a view slide? What should you pay attention to? What scenarios are they applicable to?

A: There are three types:

a: scrollto, scrollby. This is the simplest, but you can only slide the content of the view but not the view itself.

b: Animation. Animation can slide the view content, but please note that non-attribute animation will affect the interaction as mentioned in question 5, so you should pay more attention when using it. However, most complex sliding effects are completed by attribute animation, which is a killer level.

c: Change layout parameters. This method is easy to understand. It is nothing more than dynamically modifying view parameters such as margin through Java code. However, it is rarely used. I personally don't use this method very often.

7.What does Scroller do? How does it work?

A: Scroller is used to make the view have a sliding gradient effect. The usage is as follows:

 package com.example.administrator.motioneventtest; 
 
 
 import android.content.Context; 
 
 import android.util.AttributeSet; 
 
 import android.widget.Scroller; 
 
 import android.widget.TextView; 
 
 
 /** 
 
 * Created by Administrator on 2016/2/2. 
 
 */ 
 
 public class CustomTextView extends TextView{ 
 
 
    private Scroller mScroller; 
 
 
 
 public CustomTextView(Context context) { 
 
 super(context); 
 
        mScroller=new Scroller(context); 
 
 } 
 
 
 public CustomTextView(Context context, AttributeSet attrs) { 
 
        super(context, attrs); 
 
        mScroller=new Scroller(context); 
 
 
 } 
 
 
 public CustomTextView(Context context, AttributeSet attrs, int defStyleAttr) { 
 
        super(context, attrs, defStyleAttr); 
 
        mScroller=new Scroller(context); 
 
 
 } 
 
 
 //Call this method to scroll to the target position 
 
 public void smoothScrollTo( int fx, int fy) { 
 
 int dx = fx - mScroller.getFinalX(); 
 
 int dy = fy - mScroller.getFinalY(); 
 
        smoothScrollBy(dx, dy); 
 
 } 
 
 
 //Call this method to set the relative offset of the scroll 
 
 public void smoothScrollBy( int dx, int dy) { 
 
 
 //Set the scroll offset of mScroller 
 
        mScroller.startScroll(mScroller.getFinalX(), mScroller.getFinalY(), dx, dy,4000); 
 
 invalidate(); // You must call invalidate() here to ensure that computeScroll() will be called, otherwise the interface may not be refreshed and the scrolling effect will not be seen 
 
 } 
 
 
 //When using scroller, it is most important not to miss this method 
 
 @Override 
 
 public void computeScroll() { 
 
        if (mScroller.computeScrollOffset()) 
 
 { 
 
            scrollTo(mScroller.getCurrX(),mScroller.getCurrY()); 
 
 //Don't forget to call this method. 
 
 postInvalidate(); 
 
 } 
 
        super.computeScroll(); 
 
 } 
 
 }

In fact, many people should be able to search for the above code. Here we mainly talk about its principle.

 //The parameters are easy to understand. The first one is the sliding starting point, the middle sliding distance, and the last one is the gradient time. 
 
 //And we can see that the startScroll method just sets some parameters and there is no sliding code in it 
 
 // Going back to the previous demo, we can see that we usually call the invalidate() method immediately after calling this method 
 
 public void startScroll( int startX, int startY, int dx, int dy, int duration) { 
 
 mMode = SCROLL_MODE; 
 
 mFinished = false ; 
 
 mDuration = duration; 
 
        mStartTime = AnimationUtils.currentAnimationTimeMillis(); 
 
 mStartX = startX; 
 
 mStartY = startY; 
 
        mFinalX = startX + dx; 
 
        mFinalY = startY + dy; 
 
 mDeltaX = dx; 
 
 mDeltaY = dy; 
 
        mDurationReciprocal = 1.0f / ( float ) mDuration; 
 
 } 
 
 
 
 //We all know that invalidate will trigger the view 's draw method 
 
 //If we follow it, we will find that the following code is called in the draw method: 
 
 //That is to say, the computeScroll method will be called, and the view itself is this method 
 
 //It is empty so it will be left to us to implement it 
 
 int sx = 0; 
 
 int sy = 0; 
 
        if (!drawingWithRenderNode) { 
 
 computeScroll(); 
 
 sx = mScrollX; 
 
 sy = mScrollY; 
 
 } 
 
 
 
 //Then go back to our customtextview and you can see that the computeScroll method we implemented is as follows: 
 
 //You can see that in this method, we call the scrollTo method to implement sliding, and trigger the redrawing of the view again after the sliding is completed. 
 
 //Then computeScroll will be triggered again to implement a cycle. 
 
 public void computeScroll() { 
 
        if (mScroller.computeScrollOffset()) 
 
 { 
 
            scrollTo(mScroller.getCurrX(),mScroller.getCurrY()); 
 
 //Don't forget to call this method. 
 
 postInvalidate(); 
 
 } 
 
        super.computeScroll(); 
 
 } 
 
 
 
 //Return true means the sliding has not ended, false means it has ended 
 
 //In fact, this method is the same as the interpolator in the attribute animation. When you use the startScroll method, you will pass an event value. 
 
 //This method calculates the value of your scrollx and scrolly each time based on the value of this event 
 
 public boolean computeScrollOffset() { 
 
 if (mFinished) { 
 
 return   false ; 
 
 } 
 
 
 int timePassed = ( int )(AnimationUtils.currentAnimationTimeMillis() - mStartTime); 
 
     
 
        if (timePassed < mDuration) { 
 
 switch (mMode) { 
 
 case SCROLL_MODE: 
 
                final float x = mInterpolator.getInterpolation(timePassed * mDurationReciprocal); 
 
                mCurrX = mStartX + Math.round(x * mDeltaX); 
 
                mCurrY = mStartY + Math.round(x * mDeltaY); 
 
 break; 
 
 case FLING_MODE: 
 
                final float t = ( float ) timePassed / mDuration; 
 
 final int   index = ( int ) (NB_SAMPLES * t); 
 
 float distanceCoef = 1.f; 
 
 float velocityCoef = 0.f; 
 
                if ( index < NB_SAMPLES) { 
 
                    final float t_inf = ( float ) index / NB_SAMPLES; 
 
                    final float t_sup = ( float ) ( index + 1) / NB_SAMPLES; 
 
                    final float d_inf = SPLINE_POSITION[ index ]; 
 
                    final float d_sup = SPLINE_POSITION[ index + 1]; 
 
                    velocityCoef = (d_sup - d_inf) / (t_sup - t_inf); 
 
                    distanceCoef = d_inf + (t - t_inf) * velocityCoef; 
 
 } 
 
 
                mCurrVelocity = velocityCoef * mDistance / mDuration * 1000.0f; 
 
                 
 
                mCurrX = mStartX + Math.round(distanceCoef * (mFinalX - mStartX)); 
 
                // Pin to mMinX <= mCurrX <= mMaxX 
 
                mCurrX = Math. min (mCurrX, mMaxX); 
 
                mCurrX = Math. max (mCurrX, mMinX); 
 
                 
 
                mCurrY = mStartY + Math.round(distanceCoef * (mFinalY - mStartY)); 
 
                // Pin to mMinY <= mCurrY <= mMaxY 
 
                mCurrY = Math. min (mCurrY, mMaxY); 
 
                mCurrY = Math. max (mCurrY, mMinY); 
 
 
                if (mCurrX == mFinalX && mCurrY == mFinalY) { 
 
                    mFinished = true ; 
 
 } 
 
 
 break; 
 
 } 
 
 } 
 
 else { 
 
 mCurrX = mFinalX; 
 
 mCurrY = mFinalY; 
 
            mFinished = true ; 
 
 } 
 
 return   true ; 
 
 }

8.How many methods are there for view sliding gradient effect?

A: Three. The first one is the scroller, which is also the most used one. There is an explanation in question 7. Another one is animation. I will not talk much about animation because it is not in the scope of this article. The last one, which we often use, is to use a handler to update the state of the view at a certain time interval.

The code is very simple. You can experience it yourself.

9. How to express the event delivery mechanism of view using pseudo code?

answer:

 /** 
 
 * For a root viewgroup, if a click event is received, its dispatchTouchEvent method will be called first. 
 
 * If the onInterceptTouchEvent of this viewgroup returns true , it means that the event is intercepted. 
 
 * The viewgroup handles it, so the viewgroup's onTouchEvent method will be called. 
 
 * Returning false means that I do not intercept this event, and then pass this event to its own child element, and then the child element's dispatchTouchEvent 
 
 * will be called, and this cycle continues until the event is processed. 
 
 * 
 
 */ 
 
 public boolean dispatchTouchEvent(MotionEvent ev) 
 
 { 
 
 boolean consume = false ; 
 
    if (onInterceptTouchEvent(ev)) { 
 
        consume=onTouchEvent(ev); 
 
 } else   
 
 { 
 
        consume=child.dispatchTouchEvent(ev); 
 
 } 
 
 return consume; 
 
 }

10. What is the priority of view's onTouchEvent, OnClickListerner and OnTouchListener's onTouch method?

A: onTouchListener has the highest priority. If the onTouch method returns false, onTouchEvent will be called. If it returns true, it will not be called. As for onClick, it has the highest priority.

11. What is the order in which click events are delivered?

Answer: Activity-Window-View. Pass from top to bottom. Of course, if the view you are touching returns false onTouchEvent, it means that it does not want to handle it. Then throw it up again. If none of them handle it,

In the end, we let the Activity handle it by itself. For example, the PM sends a task to the leader. The leader does not do it himself but gives it to architect A, and A does not do it either but gives it to programmer B. If B does it, then the task is over.

If b finds that he can't do it, he will ask a to do it. If a can't do it either, he will keep making requests upwards, and in the end it may still be done by pm.

 //Activity's dispatchTouchEvent method is initially handed over to window for processing 
 
 //win's superDispatchTouchEvent returns true , which means this function ends directly. Returning false means 
 
 //This event is not handled by anyone, and it is finally handled by the activity's onTouchEvent. The getwindow here is actually phonewindow 
 
 public boolean dispatchTouchEvent(MotionEvent ev) { 
 
        if (ev.getAction() == MotionEvent.ACTION_DOWN) { 
 
            onUserInteraction(); 
 
 } 
 
        if (getWindow().superDispatchTouchEvent(ev)) { 
 
 return   true ; 
 
 } 
 
 return onTouchEvent(ev); 
 
 } 
 
 
 
 //Look at this function of phonewindow, which directly passes the event to mDecor 
 
 
 @Override 
 
 public boolean superDispatchTouchEvent(MotionEvent event) { 
 
 return mDecor.superDispatchTouchEvent(event); 
 
 } 
 
 
 //devorview is our rootview, which is the framelayout and the layout passed in our setContentView 
 
 // This is the subview of decorview 
 
 @Override 
 
 public final View getDecorView() { 
 
        if (mDecor == null ) { 
 
 installDecor(); 
 
 } 
 
 return mDecor; 
 
 }

12.How many steps does the event consist of?

Answer: It starts with a down event and ends with an up event, and there may be an indefinite number of move events in between.

13.How does ViewGroup distribute click events?

answer:

 The viewgroup determines whether to enter the process of intercepting events in the two cases of actionMasked == MotionEvent.ACTION_DOWN and mFirstTouchTarget != null 
 
 
 Looking at the code, we can see that if it is an ACTION_DOWN event, then we will definitely enter the process of whether to intercept the event. 
 
 
 If it is not an ACTION_DOWN event, then we need to see if the condition mFirstTouchTarget != null is true. 
 
 
 This part is a bit confusing but easy to understand. In fact, for an event sequence, down is the beginning of the event, so it must have entered the process of whether to intercept this event, that is, within the if brackets. 
 
 
 
 mFirstTouchTarget is actually a singly linked list structure that points to the child element that successfully handles the event. 
 
 
 That is to say, if a child element successfully handles the event, then this value will not be NULL . 
 
 
 As long as the viewgroup intercepts the event, mFirstTouchTarget is not NULL , so the brackets will not be executed, which also illustrates a conclusion: 
 
 
 Once a view decides to intercept an event, the event sequence to which this event belongs can only be executed by it. And the onInterceptTouchEvent method will not be called. 
 
 
            final boolean intercepted; 
 
            if (actionMasked == MotionEvent.ACTION_DOWN 
 
                    || mFirstTouchTarget != null ) { 
 
                final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0; 
 
                if (!disallowIntercept) { 
 
                    intercepted = onInterceptTouchEvent(ev); 
 
                    ev.setAction( action ); // restore action   in   case it was changed 
 
 } else { 
 
                    intercepted = false ; 
 
 } 
 
 } else { 
 
                // There are no touch targets and this action   is   not an initial down 
 
                // so this view   group continues to intercept touches. 
 
                intercepted = true ; 
 
 }

14. What happens if a view does not consume the down event when processing an event?

Answer: If a view's onTouchEvent returns false when a down event occurs, then the event sequence to which the down event belongs will not handle its subsequent move and up operations, and all operations will be handled by its parent view.

15.What happens if the view does not consume the move or up events?

Answer: Then the event sequence to which this event belongs will disappear, and the parent view will not handle it. Ultimately, it will be handled by the activity.

16.Does ViewGroup intercept events by default?

Answer: By default, no events are intercepted and onInterceptTouchEvent returns false.

17. Once an event is passed to a view, will the view's onTouchEvent be called?

Answer: Yes, because the view itself does not have an onInterceptTouchEvent method, so as long as the event comes to the view, it will definitely go through the onTouchEvent method.

By default, they are all consumed and return true. Unless the view is not clickable, which means both clickable and longgclikable are false.

Button's clickable is true but textview is false.

18. Does enable affect the onTouchEvent return value of the view?

A: It has no effect. As long as one of clickable and longClickable is true, onTouchEvent will return true.

19.Can requestDisallowInterceptTouchEvent interfere with the event distribution of the parent element in the child element? If so, can it interfere with all of them?

A: Of course you can, but the down event cannot interfere.

20.Will dispatchTouchEvent be called every time?

A: Yes, onInterceptTouchEvent will not.

21. What is the idea for solving the sliding conflict problem?

A. To solve the sliding conflict, the most important thing is to have a core idea. In an event sequence, which view do you want to respond to your sliding? For example, when sliding from top to bottom, which view handles this event, or from left to right?

After you figure it out with business requirements, the rest is actually easy to do. The core methods are two external interceptions, namely the parent interception, and the other is the internal interception, namely the child view interception method. Learning these two methods basically solves all sliding conflicts.

They are all variants of these two, and the core code ideas are the same.

External interception method: The idea is to rewrite the onInterceptTouchEvent of the parent container. Child elements generally do not need to be managed. It is easy to understand because this is exactly the same as the logic of Android's own event processing mechanism.

 @Override 
 
 public boolean onInterceptTouchEvent(MotionEvent ev) { 
 
 
        boolean intercepted = false ; 
 
 int x = ( int ) ev.getX(); 
 
 int y = ( int ) ev.getY(); 
 
 
        switch (ev.getAction()) { 
 
 //The down event must not be intercepted. If it is intercepted, the subsequent events will not be received. 
 
 case MotionEvent.ACTION_DOWN: 
 
                intercepted = false ; 
 
 break; 
 
 case MotionEvent.ACTION_MOVE: 
 
 if (your business needs) { 
 
 //If you are sure to intercept, go to your own onTouchEvent to handle the operations and effects after the interception. 
 
                    intercepted = true ; 
 
 } else { 
 
                    intercepted = false ; 
 
 } 
 
 break; 
 
 case MotionEvent.ACTION_UP: 
 
 //Up event, we usually return false . Generally, the parent container will not intercept it. Because up is the last step of the event. It doesn't make sense to return true here. 
 
 //The only meaning is that the parent element up is intercepted. As a result, the child element cannot receive the up event, so the child element will definitely not have an onClick event triggered. 
 
 //Small details to understand 
 
                intercepted = false ; 
 
 break; 
 
 default : 
 
 break; 
 
 } 
 
 return intercepted; 
 
 }

Internal interception method: The internal interception method is a little more complicated. When an event arrives, the parent container does not care and lets the child element decide whether to handle it. If it is consumed, it will be killed. If it is not consumed, it will be transferred to the parent container for processing.

Sub-element code:

 @Override 
 
 public boolean dispatchTouchEvent(MotionEvent event) { 
 
 int x = ( int ) event.getX(); 
 
 int y = ( int ) event.getY(); 
 
        switch (event.getAction()) { 
 
 case MotionEvent.ACTION_DOWN: 
 
                getParent().requestDisallowInterceptTouchEvent( true ); 
 
 break; 
 
 case MotionEvent.ACTION_MOVE: 
 
 if (if the parent container needs this click event) { 
 
                    getParent().requestDisallowInterceptTouchEvent( false ); 
 
 }//Otherwise, it will be automatically handled by the onTouchEvent of your own view 
 
 break; 
 
 case MotionEvent.ACTION_UP: 
 
 break; 
 
 default : 
 
 break; 
 
 } 
 
 return super.dispatchTouchEvent(event); 
 
 }

The father container code also needs to be modified, in fact, to ensure that the father does not intercept down:

 @Override 
 
 public boolean onInterceptTouchEvent(MotionEvent ev) { 
 
 
        if (ev.getAction() == MotionEvent.ACTION_DOWN) { 
 
 return   false ; 
 
 
 } 
 
 return   true ; 
 
 }