android input子系统--InputReader EventHub::getevents之mNeedToReopenDevices变量详细分析

5.2.1 如果mNeedToReopenDevices=true 那么条件成立,先将mNeedToReopenDevices设置为false,然后

            closeAllDevicesLocked,将mNeedToScanDevices设置为true

    5.2.2 mNeedToReopenDevices 此变量设置的地方,通过si(source insight)查找整个android源码目录,发现在以下地方使用到

            mNeedToReopenDevices变量,第一行为EventHub::EventHub构造方法,将其设置为false;第二行第三行为上面的条件判断

            第四行为5.2.2.3介绍的EventHub::requestReopenDevices方法,将其设置为true;第五行为此变量的定义

            

            5.2.2.1  在EventHub::EventHub的构造方法中将其设置为false

            5.2.2.2 在EventHub:getEvents方法中依据此变量的值判断是否需要ReopenDevices

            5.2.2.3  在EventHub::requestReopenDevices方法中将其设置为true

                


           1)那么又是在什么情况下谁调用此方法将mNeedToReopenDevices此变量设置为true呢?

               

                通过si查找到在InputReader.cpp的 InputReader::refreshConfgurationLocked方法中调用到了

                EventHub::requestReopenDevices方法,其他的第1/2/3/4行是requestReopenDevices方法的声明和定义,先忽略

                这里需要主要该方法的参数changes,根据changes参数来选择是否调用请求重新打开设备

                                   

                    2)那么又是谁在什么情况下调用到的InputReader::refreshConfgurationLocked方法呢?

               

                    由上图查找结果可知:InputReader::refreshConfgurationLocked方法在InputReader::InputReader构造方法以及

                    InputReader::loopOnce方法中调用,如下图 :

                            

                    

                所以最终在InputReader::InputReader构造方法中以及  InputReader::loopOnce方法中将mNeedToReopenDevices设置,

        接下来,针对这两中情况分别进行说明.

a):InputReader::InputReader构造方法调用refreshConfgurationLocked(0)

    refreshConfgurationLocked(0)      ->    InputReader::refreshConfgurationLocked(0) ,由于参数changes = 0,所以此处不会调用

    

b) InputReader::loopOnce 中调用refreshConfgurationLocked(changes)

              

            由于此处changes = mConfigurationChangesToRefresh变量的值,所以再跟踪mConfigurationChangesToRefresh的调用

            过程,如下图

            

            第一行,在InputReader构造方法中,将mConfigurationChangesToRefresh初始化为0

            

            第二行第三行为loopOnce中的changes赋值,以及赋值后初始化为0的操作,此处是我们要获得结果的地方

             

              第四行第五行为 InpuReader::requestRefreshConfiguration中的操作,所以此处是进行mConfigurationChangesToRefresh

                设置的地方(因为第一行为0,第二三行的地方,我们要用mConfigurationChangesToRefresh值)

                   

                所以在InputReader::requestRefreshConfiguration方法中根据changes的值决定是否设置

                mConfigurationChangesToRefresh,那么是谁调用的InputReader::requestRefreshConfiguration方法呢?

                                由上图可知:

                1.NativeInputManager::setDisplayViewport

                2.NativeInputManager::setInputWindows

                3.NativeInputManager::setPointerSpeed

                4.NativeInputManager::setShowTouches

                5.nativeReloadKeyboardLayouts

                6.nativeReloadDeviceAliasess

此处暂先不分析,所以以上6中方法都会导致mConfigurationChangesToRefresh的值发生变化,即以上6个方法都会调用到

InputReader::requestRefreshConfiguration(changes),并传入一个参数,此参数是一个enum枚举类型,如下


   所以,以上六种事件只要调用到InputReader::requestRefreshConfiguration(changes),此时changes就不为0,

那么changes条件就会成立, needWake = !mConfigurationChangesToRefresh,翻转

mConfigurationChangesToRefresh | = changes ,可以根据mConfigurationChangesToRefresh得知是哪种事件发生(枚举值不同)

到此,如果有以上六种事件中的某种事件发生,那么mConfigurationChangesToRefresh就不为0,

那么InputReader::loopOnce 中 changes =  mConfigurationChangesToRefresh也不为0   

    

但是在第一次系统刚启动时,没有事件发生,所以changes = mConfigurationChangesToRefresh = 0,

InputReader构造方法中,将mConfigurationChangesToRefresh初始化为0,所以changes = 0,不会调用refreshConfigurationLocked

综上所述:在系统初始化阶段,不会去调用EventHub::requestReopenDevices,那么mNeedToReopenDevices=false,构造方法中

初始化为false






阅读更多
个人分类: Android Input子系统
上一篇Android input子系统之InputReader获取输入事件详细分析--EventHub->getevents
下一篇android input子系统--InputReader EventHub::getevents之mClosingDevices调用过程详细分析
想对作者说点什么? 我来说一句

input子系统学习

2010年05月09日 825KB 下载

EventHub演示程序及源码

2011年05月13日 12KB 下载

android布局

2012年04月12日 2KB 下载

AndroidInput子系统架构.pdf

2017年12月26日 3.01MB 下载

Android Input子系统

2011年08月13日 236KB 下载

Android_BlueDroid详细分析

2015年11月03日 2.82MB 下载

Input子系统分析

2013年08月05日 250KB 下载

没有更多推荐了,返回首页

关闭
关闭