概述
InputManagerService構(gòu)造時會構(gòu)造naive的binder server inputManager。此處會創(chuàng)建inputReader和inputDispatcher兩條死循環(huán)線程。
inputReader利用inotify機制監(jiān)聽/dev/input下的設(shè)備節(jié)點增刪（最終也是 通過將inotify創(chuàng)建的fd掛到epoll下實現(xiàn)的），獲取到新增的節(jié)點后，利用epoll監(jiān)聽這些設(shè)備節(jié)點的rawEvent。
監(jiān)聽到這些rawEvent后會通過xxxMapper將其加工為xxxArgs，再轉(zhuǎn)發(fā)給監(jiān)聽者inputDispatcher。
inputDispatcher收到后只是做完簡單的事件有效性判斷后就往mInboundQueue中塞。
inputDispatcher線程就是循環(huán)讀取mInboundQueue看是否有數(shù)據(jù)，有數(shù)據(jù)則開始分發(fā)。分發(fā)時先找到事件可以派發(fā)的窗口，該過程會涉及anr的判斷，再將事件塞到connection.outboundqueue中，再通過socket傳給app，再將事件塞到waitQueue中，等app處理完事件回調(diào)過來再將waitQueue中的事件刪除。
代碼分析的入口在InputManagerService#start
一些重要的類和概念
InputReader
https://blog.csdn.net/zhzhangnews/article/details/91490097
InputDispatcher
https://blog.csdn.net/zhzhangnews/article/details/106795348
InputDispatcher的實現(xiàn)主要涉及3個Queue： 1. InboundQueue: 這個隊列里面存儲的是從InputReader送來到輸入事件 2. OutboundQueue：這個隊列里面存儲的是即將要發(fā)送給應(yīng)用的輸入事件 3. WaitQueue：這個隊列里面存儲的是已經(jīng)發(fā)給應(yīng)用的事件，但應(yīng)用還未處理完成。(OutboundQueue和WaitQueue在存在于Connection中)
InputChannel:本質(zhì)上是一對SocketPair
ACTION_CANCEL
case1:
viewGroup中有一個btn，在viewGroup中攔截第一次move事件。btn會收到一個CANCEL事件且不會收到后續(xù)事件.
如果某一個子View處理了Down事件(此時 mFirstTouchTarget不為null)，那么隨之而來的Move和Up事件也會交給它處理。但是交給它處理之前，父View還是可以攔截事件的，如果攔截了事件，那么子View就會收到一個Cancel事件，并且不會收到后續(xù)的Move和Up事件
https://blog.csdn.net/cufelsd/article/details/89471402
case2:
正在往window1不斷派發(fā)事件如MOVE事件，此時按home鍵，window1會受到CANCEL事件。
原因：當焦點窗口變化時surfaceFlinger會調(diào)用到InputDispatcher::setInputWindowsLocked
