当前位置: 代码迷 >> Android >> Android2.3平台输入输出机制之小结
  详细解决方案

Android2.3平台输入输出机制之小结

热度:77   发布时间:2016-05-01 15:22:07.0
Android2.3平台输入输出机制之总结

参考文章:http://blog.csdn.net/windskier/article/details/6966264

?

总的来说是:

1.InputReader从EventHub读事件,写到InputDispatcher的队列中。

2.InputDispatcher从队列中读事件,分发给ViewRoot。

?

?

具体一点是:

?

1.文件InputDispatcher.cpp (frameworks\base\services\input)?190644?2011/12/12

?InputDispatcher有个内部类叫做 Connection。有两个重要属性:

一个是InputChannel,负责维护发送事件到ViewRoot的通道。

一个是InputPublisher,负责通知ViewRoot。

InputChannel维护了一个共享内存和一对管道。用来连接InputPublisher和InputConsummer

?

2.文件 android_view_InputQueue.cpp (frameworks\base\core\jni)?19672?2011/12/12

的类??NativeInputQueue 也有两个重要的属性:

??????? sp<InputChannel> inputChannel;
??????? InputConsumer inputConsumer;

这两个属性与1InputDispatcher的两个属性一一对应。这样就在NativeInputQueue? 和 InputDispatcher之间 通过管道和共享内存,建立了一个进程间通信机制。负责事件的传输。

?

经过研究发现,InputDispatcher一次就发布一个事件给所有的target。然后就等待应答信号。所有信号应答完毕后,清空InputChannel。在下一轮的dispatchOnce中,找到当前的焦点窗口,构造InpuChannel,并注册:

?

void InputDispatcher::addWindowTargetLocked(const sp<InputWindowHandle>& windowHandle,        int32_t targetFlags, BitSet32 pointerIds) {    mCurrentInputTargets.push();    const InputWindowInfo* windowInfo = windowHandle->getInfo();    InputTarget& target = mCurrentInputTargets.editTop();    target.inputChannel = windowInfo->inputChannel;    target.flags = targetFlags;    target.xOffset = - windowInfo->frameLeft;    target.yOffset = - windowInfo->frameTop;    target.scaleFactor = windowInfo->scaleFactor;    target.pointerIds = pointerIds;}

3.Dispatcher有个超时机制:

?

    enum DropReason {        DROP_REASON_NOT_DROPPED = 0,        DROP_REASON_POLICY = 1,        DROP_REASON_APP_SWITCH = 2,        DROP_REASON_DISABLED = 3,        DROP_REASON_BLOCKED = 4,        DROP_REASON_STALE = 5,    };

?其中DROP_REASON_STALE 的超时是10秒。如果超过了10秒,事件没有处理掉,那么就直接丢弃。

?

?

// Default input dispatching timeout if there is no focused application or paused window// from which to determine an appropriate dispatching timeout.const nsecs_t DEFAULT_INPUT_DISPATCHING_TIMEOUT = 5000 * 1000000LL; // 5 sec// Amount of time to allow for all pending events to be processed when an app switch// key is on the way.  This is used to preempt input dispatch and drop input events// when an application takes too long to respond and the user has pressed an app switch key.const nsecs_t APP_SWITCH_TIMEOUT = 500 * 1000000LL; // 0.5sec// Amount of time to allow for an event to be dispatched (measured since its eventTime)// before considering it stale and dropping it.const nsecs_t STALE_EVENT_TIMEOUT = 10000 * 1000000LL; // 10sec// Motion samples that are received within this amount of time are simply coalesced// when batched instead of being appended.  This is done because some drivers update// the location of pointers one at a time instead of all at once.// For example, when there are 10 fingers down, the input dispatcher may receive 10// samples in quick succession with only one finger's location changed in each sample.//// This value effectively imposes an upper bound on the touch sampling rate.// Touch sensors typically have a 50Hz - 200Hz sampling rate, so we expect distinct// samples to become available 5-20ms apart but individual finger reports can trickle// in over a period of 2-4ms or so.//// Empirical testing shows that a 2ms coalescing interval (500Hz) is not enough,// a 3ms coalescing interval (333Hz) works well most of the time and doesn't introduce// significant quantization noise on current hardware.const nsecs_t MOTION_SAMPLE_COALESCE_INTERVAL = 3 * 1000000LL; // 3ms, 333Hz

?