preface

Nice to meet you

Now that we’re at the end of the event distribution series, let’s review the previous four articles as a table of contents:

  • Android Event Distribution Mechanism 1: How do events arrive in an Activity? : Analyzes the overall process of event distribution and the real starting point of event distribution from the window mechanism
  • Android event distribution mechanism two: viewGroup and view on the event processing: source analysis of the viewGroup and view is how to distribute events
  • Android event distribution mechanism three: event distribution workflow: analysis of touch events in the control tree distribution process model
  • What is the use of event distribution? : Analyze the application of event distribution from the perspective of actual combat

This article is the last one, mainly to simulate the interview situation to raise some questions and answers, but also as a review of the whole event distributed knowledge. Readers can also try to see if any of these questions can be answered.

The interview began

  1. Have you studied event distribution? What is event distribution

    Event distribution is a nesting mechanism for distributing screen touch information to a control tree. When we touch the screen, a series of MotionEvent event objects are generated, which are distributed through the control tree manager ViewRootImpl by calling the View’s dispatchPointerEvnet method.

  2. What are the main distribution processes:

    In the case of the application’s main interface, the top view of the layout is a DecorView, which passes the event to the Activity, which calls the PhoneWindow method to distribute it, The PhoneWindow is dispatched by calling the dispatchTouchEvent method of the DecorView parent ViewGroup. That is the Activity->Window->ViewGroup process. The ViewGroup looks down for the appropriate control and distributes the event to it.

  3. Does the event have to pass through the Activity?

    Isn’t. The Activity callBack is registered in the top-level viewGroup (decorView) of our application interface, so when the application’s main interface receives an event, it is passed to the Activity first. However, if it is another control tree, such as dialog, popupWindow, etc., the event stream will not pass through the Activity. Only events in your interface will pass through the Activity.

  4. The Activity distribution method calls the onUserInteraction() method. Can you describe what this method does?

    B: Ok. This method is called when the Activity receives a Down and is an empty method that needs to be overridden by the developer. As you can see from the official comment, this method is called whenever we start interacting with the Activity in any way. A common scenario is the screensaver: an image is displayed when we haven’t acted on it for a while. This method can be used to cancel the screensaver when we start interacting with an Activity. There is also no operation to hide the toolbar automatically, you can make the toolbar reappear in this method.

  5. So you said that it’s going to be distributed to a viewGroup at the end, so how does a viewGroup distribute events?

    The viewGroup processes event information in three steps: intercepting, finding child controls, and sending events.

    There is an important rule in event distribution: a sequence of events for a touch point can only be handled by one view, unless there is an exception. So if the viewGroup consumes a Down event, then the child view will not receive any events.

    The viewGroup’s first step is to determine whether the event needs to be distributed to a child view. If so, it calls the onInterceptTouchEvent method to determine whether it needs to be intercepted. The second step is to look for a child control to consume the event if it is a Down event and create a TouchTarget for it if it is found. The third step is to distribute the event. If there is a TouchTarget, it means that the sub-view of the consumption event sequence has been found and distributed to it directly. If not, hand it over to yourself.

  6. You mentioned earlier that “a sequence of events for a touch point can only be handled by a view unless there is an exception”. What is the exception here? What should I do if an exception occurs?

    There are two exceptions: 1. Blocked by viewGroup, 2. Other situations such as a page jump occur.

    When the stream of events is interrupted, the viewGroup will send an ACTION_CANCEL event to the view. At this time, some state restoration work needs to be done, such as terminating the animation, restoring the view size, etc.

  7. So speaking of ACTION_CANCEL, can you tell me what other event types are there?

    In addition to ACTION_CANCEL, other event types are:

    • ACTION_MOVE: This event occurs when we swipe our finger across the screen
    • ACTION_UP: This event occurs when our finger is lifted

    In addition, multi-finger operations are common:

    • ACTION_POINTER_DOWN: This event is generated when a finger has already been pressed by another finger
    • ACTION_POINTER_UP: When multiple fingers are pressed at the same time, this event is generated when one finger is lifted.

    A complete sequence of events starts with ACTION_DOWN and ends with ACTION_UP or ACTION_CANCEL. A complete sequence of a finger starts with ACTION_DOWN/ACTION_POINTER_DOWN and ends with ACTION_UP/ACTION_POINTER_UP/ACTION_CANCEL.

  8. Oh? Speaking of multiple fingers, do you know how a ViewGroup can accurately distribute events generated by multiple fingers to different child views

    The key to this problem is the MotionEvent and TouchTarget inside the ViewGroup.

    Each MotionEvent contains information about all touch points on the current screen, and it uses an array to store the coordinate values corresponding to different touch ids.

    When a child view consumes a Down event, the ViewGroup creates a TouchTarget for the view. This TouchTarget contains the view instance and the touch ID. Here the touch ID can be multiple, that is, a view can accept a sequence of events for multiple touch points.

    When a MotionEvent arrives, the ViewGroup takes the touch information apart and sends it to the interested child views. So as to achieve the purpose of sending precise touch point information.

  9. Does the View support handling multiple fingers?

    View is not supported by default. Instead of passing in the touch index, he gets the first touch in the MotionEvent array. We need to rewrite the method to support it.

  10. Uh huh… So how does a View handle touch events?

    First, he determines if an onTouchListener exists, and if so, calls his onTouch method to handle the event. If the method returns true, the distribution ends. If the listener is null or the onTouch method returns false, the onTouchEvent method is called to handle the event.

    Two types of listeners are supported in the onTouchEvent method: onClickListener and onLongClickListener. The View calls both listeners based on different touches. When you enter the onTouchEvent method, its distribution method returns true regardless of whether the View is enable or clickable.

    Call onTouchListener first, then onClickListener and onLongClickListener.

  11. You’ve talked a lot about distribution methods and return values, can you talk a little bit about the main methods and how they relate to each other?

    Uh huh. The core methods are dispatchTouchEvent, onInterceptTouchEvent and onTouchEvent.

    Simply put: dispatchTouchEvent is the core distribution method where all the distribution logic is executed; OnInterceptTouchEvent determines whether to intercept in viewGroup. OnTouchEvent is the core method for consuming events. The viewGroup has all three methods, but the View has no onInterceptTouchEvent method.

    • viewGroup
      1. The viewGroup dispatchTouchEvent method receives an event message and calls onInterceptTouchEvent to determine whether to intercept the event
        • If it does, it calls its own onTouchEvent method
        • If not, the child view’s dispatchTouchEvent method is called
      2. The child view has no consumption event, so the onTouchEvent of the viewGroup itself is called
      3. The results of steps 1 and 2 above are the results of viewGroup’s dispatchTouchEvent method. If there is no consumption, return false and return to onTouchEvent. If there is consumption, dispatch ends and return true.
    • view
      1. The view dispatchTouchEvent by default calls onTouchEvent to handle events, returning true for consumption events and false for no consumption events
      2. The result of step 1 is the result of the dispatchTouchEvent method, which returns true on success and false on failure and passes to onTouchEvent at the next level

    In simple terms, in the control tree, each viewGroup dispatchTouchEvent continuously dispatches views looking for consumption in the dispatchTouchEvent method. If the underlying view does not consume the event, the onTouchEvent method of the viewGroup is called layer by layer to handle the event.

    Also, since the Activity inherits the window. CallBack interface, there are dispatchTouchEvent and onTouchEvent methods:

    1. Once the activity receives the touch event, it distributes it directly to the viewGroup
    2. If the viewGroup dispatchTouchEvent method returns false, the Activity’s onTouchEvent is called to handle the event
    3. The results of steps 1 and 2 are the results of the activity’s dispatchTouchEvent method and are returned to the upper layer

  12. You seem to know a lot about event distribution. Do you use event distribution in practice?

    Yes, yes. Here are two examples.

    The first requirement was to design a block of buttons that would shrink when pressed and become lower in height and translucent, but would bounce back when released. At this point you can determine the event type in the button’s onTouchEvent method: down will enable the press animation, up will enable the release animation. Also note that the state is restored when the Cancel event is received.

    The second is sliding conflict. The core idea of resolving slide conflicts is to distribute slide events to the viewGroup or internal view according to the specific situation. The main methods are external interception and internal interception. The idea of external interception method is to judge the sliding situation in the viewGroup, and intercept the event that meets its own sliding, and not intercept the event that does not meet, and send it to the internal view. The idea of the internal interception method requires the viewGroup to intercept all events except down events, and then judge the sliding situation in the internal view. Set the blocking flag to the time that meets its sliding situation, and cancel the flag to let the viewGroup intercept the events that do not meet its sliding situation.

  13. How to choose between external and internal interception?

    In general, the external interception method does not require method rewriting of the child view. It is simpler than the internal interception method.

    However, if you need to judge more touches in the child view, you can use an internal interception method to better handle the child view.

  14. We’ve been talking about touch events, but do you know how a touch event is generated from touching the screen?

    Er… After the screen receives the touch information, it passes the information to the InputServiceManager for processing. Finally, the WindowManagerService finds the window that matches the touch information. And the touch information sent to the viewRootImpl viewRootImpl after layers of sealing and processing, produced a MotionEvent events distribution to the view.

  15. Can you tell us more about the IMS process?

    Ah.. This is… Well… Won’t…

  16. Is there anything else you’d like to ask?

    Would you mind… Give me a little “like” before you go, okay?

  17. I’ll do it next time.

    = _ =…

The last

One of the things I’ve always insisted on about interviews is that you can learn for interview knowledge, but not for interview answers. Memorizing answers to relevant hot topics can fool some interviewers, but these days it’s not just about asking what event distribution is, it’s about giving us a specific need to think about and so on. Reciting interview questions may make us feel like we are learning a lot in the short term, but in fact, we are learning nothing.

This concludes the event distribution series. Have question welcome comment area exchange, hope article is helpful to you ~

Now that you’ve seen this, leave a “like” for the author.

Full text here, the original is not easy, feel help can like collection comments forward. I have no talent, any ideas welcome to comment area exchange correction. If need to reprint please comment section or private communication.

And welcome to my blog: Portal