Android View Framework Summary (ix) KeyEvent event distribution mechanism

Please respect the results of the sharing, reproduced please indicate the source:
http://blog.csdn.net/hejjunlin/article/details/52335094

This article starts to analyze the key message event distribution (PS: The source code in this article is Android 6.0, please know) First look at the agenda:

• The Dispatchinputevent method in Viewrootimpl
• View.dispatchkeyevent method
• Viewgroup.dispatchkeyevent method
• Activity.dispatchkeyevent method
• Keystroke Message Event Timing diagram

The Dispatchinputevent method in Viewrootimpl

After the message is accepted in the WMS, the Dispatchinputevent method in Viewrootimpl is called.
As follows:
Viewrootimpl.java-Dispatchinputevent ()

Here's a look at Viewroothandler's Handlemessage method:
Viewrootimpl$viewroothandler.java-Handlemessage ()

After getting the event in MSG, and receiver, then call the Enqueueinputevent method
Viewrootimpl.java-Enqueueinputevent ()

The above method, because the default is False, will perform 2:
Viewrootimpl.java-Scheduleprocessinputevents ()

The above method, and then send a msg_process_input_events (processing message) to Handler
Viewrootimpl$viewroothandler.java-Handlemessage ()

Viewrootimpl.java-Doprocessinputevents ()

There is a cyclic operation, that is, to pass the queuedinputevent to the Deliverinputevent method, the main function is to put the above button messages in the queue.
Viewrootimpl.java-Deliverinputevent ()

Viewrootimpl provides a Setview method, is a public, will put Mview (that is, Decorview), WMS Call this method, note that Viewrootimpl is not a view, it is actually a handler, Its function is as follows:

Distribute received user-initiated event events to decorview such as keystrokes, touch screens, trackball, etc. (this is implemented in an internal class, as described below)

Interact with Windowmanagerservice to complete the drawing of the entire activity GUI.

Look at the Setview method.

There are two internal classes, Viewpostimeinputstage,
Viewrootimpl.java$viewpostimeinputstage

Before looking at Processkeyevent, look at the Onprocess method:
Viewrootimpl$viewpostimeinputstage.java-Processkeyevent

Viewrootimpl.java-handledispatchwindowanimationstopped ()

Some of the above code is relatively long, understand the next line, mainly understand the Processkeyevent method:
KeyEvent is a subclass of InputEvent, and InputEvent is the base class for an event.
The process of handling received events and distributing events, is that the problem? How does a view or ViewGroup receive a key message? Viewrootimpl the Processkeyevent () method in the inner class Viewpostimeinputstage
if (Mview.dispatchkeyevent (event)) {//mview is Decorview (title), but is essentially view (nickname)
return finish_handled;
}
In addition, the keyboard messages are distributed to view or ViewGroup, and the Processkeyevent () method in the Viewrootimpl another inner class viewpreimeinputstage is as follows:

View.dispatchkeyevent method

You can see that the key messages are distributed to the view from the beginning, and then look at the dispatchkeyevent () in the view:

Keyevent.java-Dispatch ()

Viewgroup.dispatchkeyevent method

Look again at the dispatchkeyevent in ViewGroup ()

The above code summarizes: ViewGroup is the dispatchkeyevent that overrides the view, and if there is a child view, distribute the key message to the child view. No, it is distributed directly by the parent view.

Activity.dispatchkeyevent method

Is this the end? No, dispatchkeyevent in activity, this is not an overriding method:

The above code is summarized as follows: first let Actionbar priority processing KeyEvent, and then through the window processing, processing, to the window Decorview processing. The relationship between window and Decorview is the equivalent of a window, a piece of paper glued to a window. So, Decorview can be understood as the paper on the window. Activity dispatchkeyevent is used to handle keyevent correlation, subclasses can rewrite interception so the key event message is distributed to the window layer, so we'd better do some normal process.
The main process is as follows:
1, call Onuserinteraction (), can overload the function to do some processing before the message is distributed
2. Callback activity contains the superdispatchkeyevent of the Window object, The function then calls Mdecor.superdispatchkveyeent, which then calls Super.dispatchkeyevent,decorview's parent class framelayout, and Framelayout does not overload Dispatchkeyeve NT, so eventually call ViewGroup's dispatchkeyevent
3, if Decorview not consume the message, then call the event's dispatch () function, where the first parameter receiver is the activity object

Write this, have a question? is a message to be distributed from window to Viewroot? Or where did the key message from Viewroot come from?
There is an inner class in Viewroot: W,w is a binder subclass (static class W extends Iwindow.stub) that is used to receive various messages from the Global window manager, such as keystroke messages, touch messages, and so on. Viewroot has a member of the W type Mwindow,viewroot creates a W instance in the construct and assigns the value to Mwindow (Mwindow = new W (this);). Viewroot is a subclass of handler, and W passes the message to Viewroot through Looper.

Keystroke Message Event Timing diagram

A picture summarizing the above process:

The first time to get blog update reminders, as well as more Android dry, source code Analysis , Welcome to follow my public number, sweep the bottom QR code or long press to identify two-dimensional code, you can pay attention to.

If you feel good, easy to praise, but also to the author's affirmation, can also share this public number to you more people, original not easy

Android View Framework Summary (ix) KeyEvent event distribution mechanism