Android's View event distribution mechanism (1)

Before understanding the event distribution mechanism of View, you need to understand the composition of Activity, and then analyze the event distribution mechanism of View from the perspective of source code.

1. Source code analysis Activity composition

Point on the event with MotionEvent to represent. When a click event is generated, the event is first passed to the Activity, so we need to understand the composition of the Activity first. When we write Activity, we will call the setContentView method to load the layout. Let's first look at the setContentView method:

@Override
    public void setContentView(@LayoutRes int layoutResID) {
       getWindow().setContentView(layoutResID)
       initWindowDecorActionBar();
    }

What will getWindow() get here? Then look down. getWindow() returns mWindow:


    /**
     * Retrieve the current {@link android.view.Window} for the activity.
     * This can be used to directly access parts of the Window API that
     * are not available through Activity/Screen.
     *
     * @return Window The current window, or null if the activity is not
     *         visual.
     */
    public Window getWindow() {
        return mWindow;
    }

The mWindow here is the current winow. Let's see how mWindow is obtained:

final void attach(Context context, ActivityThread aThread,
            Instrumentation instr, IBinder token, int ident,
            Application application, Intent intent, ActivityInfo info,
            CharSequence title, Activity parent, String id,
            NonConfigurationInstances lastNonConfigurationInstances,
            Configuration config, String referrer, IVoiceInteractor voiceInteractor,
            Window window, ActivityConfigCallback activityConfigCallback, IBinder assistToken,
            IBinder shareableActivityToken) {
        attachBaseContext(context);

        mFragments.attachHost(null /*parent*/);

        mWindow = new PhoneWindow(this, window, activityConfigCallback);

In the attach method, you can see that mWindow is the created phoneWindow. So the above getWindow().setContentView() method actually calls the setContentView method of phoneWindow. In this method, such a code:

if (mContentParent == null)
	{
		installDecor();
	}

Next, let's look at the source code of the installDecorf() method:

private void installDecor(){
	if (mDecor == null)
	{
		mDecor = generatorDecor();
		mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
		mDecor.setIsRootNamespace(true);
		if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0)
		{
			mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
		}
	}
	if (mContentParent == null)
	{
		mContentParent = generateLayout(mDecor);
	}
	...
}

We found such a code in the installDecor() method:

if (mDecor == null)
{
	mDecor = generateDecor();
}

Then let's look at the generateDecor() method:

protected DecorView generateDecor(){
	return new DecorView()
}

Here a DecorView is created. This DecorView is the root View in the Activity. Then view the source code of DecorView. It is found that DecorView is an inner class of the PhoneWindow class. And inherited FrameLayout.

In installDecor, there is not only the generatorDecor method, but also another important method: getnerateLayout(DecorView drcor){}

The main content of this method is to load different layouts to layoutResource according to different situations. We all know that an Activity contains a Window object, which is implemented by PhoneWindow. PhoneWindow uses DecorView as the root View of the entire application window, and this DecorView divides the screen into two areas: one area is TitleView, and the other area is ContentView. The layout we usually write in the application is displayed in the ContentView.

Android's View event distribution mechanism (1)

Guess you like