Android应用程序键盘（Keyboard）消息处理机制分析（23）

 Step 39. InputConsumer.sendFinishedSignal

       这个函数定义在frameworks/base/libs/ui/InputTransport.cpp文件中：

status_t InputConsumer::sendFinishedSignal() {
    ......

    return mChannel->sendSignal(INPUT_SIGNAL_FINISHED);
}

        这个函数的实现很简单，只是调用其内部对象mChannel的sendSignal函数来执行发送信号的通知。前面我们已经说过，这里的mChannel的类型为InputChannel，它是注册在应用程序一侧的Client端InputChannel，它的成员函数sendSignal的定义我们在上面的Step 20中已经分析过了，这里不再详述，不过，这里和上面Step 20不一样的地方是，它里的通知方向是从反向管道的写端（在应用程序这一侧）到反向管道的读端（在InputDispatcher这一侧）。

 

        前面我们在分析应用程序注册键盘消息接收通道的过程时，在Step 18（InputDispatcher.registerInputChannel）中，说到InputDispatcher把一个反向管道的读端文件描述符添加到WindowManagerService所运行的线程中的Looper对象中去，然后就会在这个反向管道的读端上睡眠等待有这个管道有新的内容可读。现在，InputConsumer往这个反向管道写入新的内容了，于是，InputDispatcher就被唤醒过来了，唤醒过来后，它所调用的函数是InputDispatcher.handleReceiveCallback函数，这与前面的Step 21的逻辑是一样的。

       Step 40. InputDispatcher.handleReceiveCallack

       这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

int InputDispatcher::handleReceiveCallback(int receiveFd, int events, void* data) {
    InputDispatcher* d = static_cast<InputDispatcher*>(data);

    { // acquire lock
        AutoMutex _l(d->mLock);

        ssize_t connectionIndex = d->mConnectionsByReceiveFd.indexOfKey(receiveFd);
        ......

        nsecs_t currentTime = now();

        sp<Connection> connection = d->mConnectionsByReceiveFd.valueAt(connectionIndex);
        ......

        status_t status = connection->inputPublisher.receiveFinishedSignal();
        if (status) {
            ......
            return 0; // remove the callback
        }

        d->finishDispatchCycleLocked(currentTime, connection);
        ......

        return 1;
    } // release lock
}

        这个函数首先是通过传进来的receiveFd参数（反向管道的读端文件描述符）的值取得相应的Connection对象：

ssize_t connectionIndex = d->mConnectionsByReceiveFd.indexOfKey(receiveFd);
     ......

sp<Connection> connection = d->mConnectionsByReceiveFd.valueAt(connectionIndex);

        然后通过调用这个connection对象的内部对象inputPublisher的receiveFinishedSignal函数来确认是否真的收到键盘事件处理完成的信号，确认之后，就会调用InputDispatcher对象d的finishDispatchCycleLocked函数来执行一些善后工作。下面我们就依次分析这两个过程。

 

        Step 41. InputPublisher.receiverFinishedSignal

        这个函数定义在frameworks/base/libs/ui/InputTransport.cpp文件中：

status_t InputPublisher::receiveFinishedSignal() {
    ....

    char signal;
    status_t result = mChannel->receiveSignal(& signal);
    if (result) {
        return result;
    }
    if (signal != INPUT_SIGNAL_FINISHED) {
        .......
        return UNKNOWN_ERROR;
    }
    return OK;
}

        这里的逻辑和前面的Step 22中NativeInputQueue确认是否真的收到键盘事件分发的信号的逻辑是一致的，都是通过InputChannel的receiveSignal函数来确认是否在管道中收到了某一个约定的字符值，不过，这里约定的字符值为INPUT_SIGNAL_FINISHED。

 

        回到前面的Step 40中，确认了是真的收到了键盘事件处理完成的信号后，就调用InputDispatcher的finishDispatchCycleLocked函数来执行一些善后工作了。

        Step 42. InputDispatcher.finishDispatchCycleLocked
        这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

void InputDispatcher::finishDispatchCycleLocked(nsecs_t currentTime,
        const sp<Connection>& connection) {
    ......

    // Notify other system components.
    onDispatchCycleFinishedLocked(currentTime, connection);

    // Reset the publisher since the event has been consumed.
    // We do this now so that the publisher can release some of its internal resources
    // while waiting for the next dispatch cycle to begin.
    status_t status = connection->inputPublisher.reset();
    ......

    startNextDispatchCycleLocked(currentTime, connection);
}

        这个函数主要就是做了三件事情：

 

       一是通知其它系统，InputDispatcher完成了一次键盘事件的处理：

// Notify other system components.
onDispatchCycleFinishedLocked(currentTime, connection);

        二是调用相应的connection对象的内部对象inputPublisher来的reset函数来回收一些资源，它里面其实就是释放前面在Step 18（InputPublisher.publishKeyEvent）使用的匿名共享内存了：

// Reset the publisher since the event has been consumed.
// We do this now so that the publisher can release some of its internal resources
// while waiting for the next dispatch cycle to begin.
status_t status = connection->inputPublisher.reset();

        三是调用InputDispatcher的startNextDispatchCycleLocked函数来处理下一个键盘事件：

startNextDispatchCycleLocked(currentTime, connection);

        因为正在处理当前这个键盘事件的时候，很有可能又同时发生了其它的键盘事件，因此，这里InputDispatcher还不能停下来，需要继续调用startNextDispatchCycleLocked继续处理键盘事件，不过下一个键盘事件的处理过程和我们现在分析的过程就是一样的了。

 

        至此，InputManager分发键盘消息给应用程序的过程就分析完成了，这是一个比较复杂的过程，不过，只要我们抓住主要的线索，就不难理解了，现在我们就小结一下这个过程的四个主要线索：

        A. 键盘事件发生，InputManager中的InputReader被唤醒，此前InputReader睡眠在/dev/input/event0这个设备文件上；

        B. InputReader被唤醒后，它接着唤醒InputManager中的InputDispatcher，此前InputDispatcher睡眠在InputManager所运行的线程中的Looper对象里面的管道的读端上；

        C. InputDispatcher被唤醒后，它接着唤醒应用程序的主线程来处理这个键盘事件，此前应用程序的主线程睡眠在Client端InputChannel中的前向管道的读端上；

        D. 应用程序处理处理键盘事件之后，它接着唤醒InputDispatcher来执行善后工作，此前InputDispatcher睡眠在Server端InputChannel的反向管道的读端上，注意这里与第二个线索处的区别。