上文講到訊息獲取過程，本文來詳細看程式碼。

        我們說視窗建立時會建立本地的ViewRoot，然後呼叫WmS的addWindow方法，所以我們首先來看看WmS的程式碼。

        你會看到frameworks/base/services/java/com/android/server/WindowManagerService.java中，沒有公開的構造子，但有一個main方法，我們推測main方法即是此類的入口（當然，網路上很多資料表明，main方法就是WmS的入口）。

        main方法程式碼如下所示：

public static WindowManagerService main(Context context,
    PowerManagerService pm, boolean haveInputMethods) {
	WMThread thr = new WMThread(context, pm, haveInputMethods);
	thr.start();

	synchronized (thr) {
		while (thr.mService == null) {
		try {
			thr.wait();
		} catch (InterruptedException e) {
		}
		}
	}

	return thr.mService;
}
 

建立一個WMThread，然後啟動它，WMThread定義在WindowManagerService.java裡面，它的run方法如下所示：

public void run() {
	Looper.prepare();
	WindowManagerService s = new WindowManagerService(mContext, mPM,
			mHaveInputMethods);
	android.os.Process.setThreadPriority(
			android.os.Process.THREAD_PRIORITY_DISPLAY);
	android.os.Process.setCanSelfBackground(false);

	synchronized (this) {
		mService = s;
		notifyAll();
	}

	Looper.loop();
}
 

        先忽略Looper，後面會再次描述到。

        主體部分是建立一個WindowManagerService，後面是設定執行緒優先順序等，所以有必要看看WindowManagerService的構造方法做了什麼：

private WindowManagerService(Context context, PowerManagerService pm,
		boolean haveInputMethods) {
	mContext = context;
	mHaveInputMethods = haveInputMethods;
	mLimitedAlphaCompositing = context.getResources().getBoolean(
			com.android.internal.R.bool.config_sf_limitedAlpha);

	mPowerManager = pm;
	mPowerManager.setPolicy(mPolicy);
	PowerManager pmc = (PowerManager)context.getSystemService(Context.POWER_SERVICE);
	mScreenFrozenLock = pmc.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,
			"SCREEN_FROZEN");
	mScreenFrozenLock.setReferenceCounted(false);

	mActivityManager = ActivityManagerNative.getDefault();
	mBatteryStats = BatteryStatsService.getService();

	// Get persisted window scale setting
	mWindowAnimationScale = Settings.System.getFloat(context.getContentResolver(),
			Settings.System.WINDOW_ANIMATION_SCALE, mWindowAnimationScale);
	mTransitionAnimationScale = Settings.System.getFloat(context.getContentResolver(),
			Settings.System.TRANSITION_ANIMATION_SCALE, mTransitionAnimationScale);

	// Track changes to DevicePolicyManager state so we can enable/disable keyguard.
	IntentFilter filter = new IntentFilter();
	filter.addAction(DevicePolicyManager.ACTION_DEVICE_POLICY_MANAGER_STATE_CHANGED);
	mContext.registerReceiver(mBroadcastReceiver, filter);

	mHoldingScreenWakeLock = pmc.newWakeLock(PowerManager.SCREEN_BRIGHT_WAKE_LOCK,
			"KEEP_SCREEN_ON_FLAG");
	mHoldingScreenWakeLock.setReferenceCounted(false);

	mInputManager = new InputManager(context, this);

	PolicyThread thr = new PolicyThread(mPolicy, this, context, pm);
	thr.start();

	synchronized (thr) {
		while (!thr.mRunning) {
			try {
				thr.wait();
			} catch (InterruptedException e) {
			}
		}
	}

	mInputManager.start();

	// Add ourself to the Watchdog monitors.
	Watchdog.getInstance().addMonitor(this);
}
 

        在WindowManagerService的構造子中，建立了一個InputManager物件，並呼叫它的start()方法，我們可以淺顯地判斷InputManager是一個執行緒類，對應的構造子如下：

public InputManager(Context context, WindowManagerService windowManagerService) {
	this.mContext = context;
	this.mWindowManagerService = windowManagerService;
	
	this.mCallbacks = new Callbacks();
	
	init();
}

        這裡有兩點需要注意，一是Callbacks方法，進入到Callbacks類裡面，可以看到它主要是呼叫了WindowManagerService的其他方法。另一個是init()方法，init內部呼叫了initNative()方法，跟蹤initNative()方法時你會發現它僅僅是有以下定義：

private static native void nativeInit(Callbacks callbacks);

        它沒有具體的實現方法，我們知道，InputManager是Java類，它會與對應的C函式進行互動，所以我們判斷nativeInit實現上是使用JNI呼叫C函式執行操作，那怎麼找到InputManager方法對應的C函式呢？

        InputManager類的全路徑是frameworks/base/services/java/com/android/server/InputManager.java，所以它對應的JNI一定是在frameworks/base/services/jni下，我們找到這個目錄，發現該目錄下有個檔名為com_android_server_InputManager.cpp，與Java檔案的路徑可以找到共同點，於是我們判斷，com_android_server_InputManager.cpp即為InputManager.java對應的C函式。

        InputManager.cpp中定義了一個NativeInputManager物件，該物件有個構造子：

NativeInputManager::NativeInputManager(jobject callbacksObj) :
    mFilterTouchEvents(-1), mFilterJumpyTouchEvents(-1), mVirtualKeyQuietTime(-1),
    mMaxEventsPerSecond(-1),
    mDisplayWidth(-1), mDisplayHeight(-1), mDisplayOrientation(ROTATION_0) {
    JNIEnv* env = jniEnv();

    mCallbacksObj = env->NewGlobalRef(callbacksObj);

    sp<EventHub> eventHub = new EventHub();
    mInputManager = new InputManager(eventHub, this, this);
}

        這個構造子即對應了initNative(Callbacks callbacks)方法。

        你會看到在NativeInputManager的構造子中，建立了一個InputManager物件，C程式碼不能直接呼叫Java程式碼，所以這個InputManager當然不是InputManager.java。跟到frameworks/base/libs/ui/InputManager.cpp裡面去，找到對應的InputManager物件的構造子，程式碼如下所示：

InputManager::InputManager(
        const sp<EventHubInterface>& eventHub,
        const sp<InputReaderPolicyInterface>& readerPolicy,
        const sp<InputDispatcherPolicyInterface>& dispatcherPolicy) {
    mDispatcher = new InputDispatcher(dispatcherPolicy);
    mReader = new InputReader(eventHub, readerPolicy, mDispatcher);
    initialize();
}

        或以看到，在InputManager.cpp的構造子中，建立了一個InputDispatcher物件和一個InputReader物件。接著看initialize()方法：

void InputManager::initialize() {
    mReaderThread = new InputReaderThread(mReader);
    mDispatcherThread = new InputDispatcherThread(mDispatcher);
}

        很明顯，在initialize()方法中，分別建立了InputReader執行緒和InputDispatcher執行緒。

        再返回WindowManagerService的構造子，發現其最後一行程式碼是：

Watchdog.getInstance().addMonitor(this);

        再看看WindowManagerService的定義：

public class WindowManagerService extends IWindowManager.Stub
        implements Watchdog.Monitor {

        由此我們可以判斷，WindowManagerService事實上是一個Monitor，構造子的最後一行，是把WmS本身這個InputMonitor新增到Watchdog裡面。

        再聯絡上文的視窗建立過程：

        我們很容易地把程式碼與上圖關聯起來了。