android4.3 Key Message Processing analysis

Android4.3 the key message processing is slightly different from the previous version, the basic principle is the same, here mainly from two stages to analyze:

1. Pre-preparation work, that is, start the corresponding thread, waiting for the advent of key events

2. When there is a key message, the distribution of messages and other processing

Let's look at a class diagram first:

As seen from the class diagram, the main classes involved are Phonewindowmanager, Windowmanagerservice, Inputmanagerservice, InputManager

The first question, the preparatory work:

1. Start the Inputmanagerservice first, by the Serverthread responsible for the start;

  InputManager = new Inputmanagerservice (context, wmhandler);            SLOG.I (TAG, "window Manager");            WM = Windowmanagerservice.main (context, power, display, InputManager,                    Uihandler, Wmhandler,                    factorytest! = Systemserver.factory_test_low_level,                    !firstboot, onlycore);            Servicemanager.addservice (Context.window_service, WM);            Servicemanager.addservice (Context.input_service, InputManager);            Activitymanagerservice.self (). Setwindowmanager (WM);            Inputmanager.setwindowmanagercallbacks (Wm.getinputmonitor ());            Inputmanager.start ();

Look at the Inputmanagerservice constructor:

Public Inputmanagerservice (context context, Handler Handler) {        This.mcontext = context;        This.mhandler = new Inputmanagerhandler (Handler.getlooper ());        Musedevinputeventforaudiojack =                context.getresources (). Getboolean (R.bool.config_ Usedevinputeventforaudiojack);        SLOG.I (TAG, "Initializing input manager, musedevinputeventforaudiojack="                + musedevinputeventforaudiojack);        Mptr = Nativeinit (this, Mcontext, Mhandler.getlooper (). Getqueue ());    }

Start with a new Inputmanagerhandler, and then call a native method to pass in the service and handler message queue as parameters.

The nativeinit corresponds to the nativeinit in the Com_android_server_input_inputmanagerservice.cpp, which is associated with the mechanism of JNI.

Here is not much to say, look nativeinit:

Static Jint Nativeinit (jnienv* env, Jclass clazz,        jobject serviceobj, Jobject contextobj, Jobject messagequeueobj) { c1/>sp<messagequeue> MessageQueue = Android_os_messagequeue_getmessagequeue (env, messagequeueobj);    if (MessageQueue = = NULL) {        jnithrowruntimeexception (env, "MessageQueue is not initialized.");        return 0;    }    nativeinputmanager* im = new Nativeinputmanager (contextobj, Serviceobj,            messagequeue->getlooper ());    Im->incstrong (0);    return reinterpret_cast<jint> (IM);}

The main point here is to create a Nativeinputmanager object that looks at the constructor:

Nativeinputmanager::nativeinputmanager (Jobject contextobj,        jobject serviceobj, const sp<looper>& Looper):        mlooper (looper) {    jnienv* env = jnienv ();    Mcontextobj = Env->newglobalref (contextobj);    Mserviceobj = Env->newglobalref (serviceobj);    {        Automutex _l (mLock);        mlocked.systemuivisibility = asystem_ui_visibility_status_bar_visible;        mlocked.pointerspeed = 0;        Mlocked.pointergesturesenabled = true;        Mlocked.showtouches = false;    }    sp<eventhub> Eventhub = new Eventhub ();    Minputmanager = new InputManager (Eventhub, this, this);}

The main point here is to create a inputmanager that looks at the constructor:

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 ();} void Inputmanager::initialize () {    mreaderthread = new Inputreaderthread (mreader);    Mdispatcherthread = new Inputdispatcherthread (mdispatcher);}

Here we see the object of creating objects Inputdispatcher, Inputreader, and two-hour running threads: Mreaderthread, Mdispatcherthread

The first step to this initialization is done, but the created thread hasn't started yet, and is really working to see the opening process

At this point, the preparatory work is done, the two threads begin to work, waiting for the key events to come

2. When there are key events, two threading processes are shown:

Two main lines:

A. Inputreader gets the key event from the Eventhub and notifies the Inputdispatcher;inputdispatcher to call after receiving the notification

The Interceptkeybeforequeueing method carries out related operations and adds key events to the queue for later processing.

Join the queue source code:

BOOL Inputdispatcher::enqueueinboundeventlocked (evententry* entry) {    bool Needwake = Minboundqueue.isempty ();    Minboundqueue.enqueueattail (entry);    Traceinboundqueuelengthlocked ();

B. Inputdispatcher gets the key message from the message queue and calls the Interceptkeybeforedispatching method to determine whether to intercept the message.

According to the results of the judgment:

    nsecs_t delay = mpolicy->interceptkeybeforedispatching (Commandentry->inputwindowhandle,            &event, Entry->policyflags);    Mlock.lock ();    if (Delay < 0) {        entry->interceptkeyresult = Keyentry::intercept_key_result_skip;    } else if (!delay) {        entry->interceptkeyresult = keyentry::intercept_key_result_continue;    } else {        entry->interceptkeyresult = Keyentry::intercept_key_result_try_again_later;        Entry->interceptkeywakeuptime = Now () + delay;    }

The interceptkeybeforequeueing and Interceptkeybeforedispatching methods that are called in Inputdispatcher are corresponding to the

The same name method in Phonewindowmanager.