概述
UI是Android開發中非常重要的一部分，而事件分發體系是UI開發的重點也是基礎。所以，為了能夠實現豐富漂亮的UI，這里以簡單明了的比喻闡述下分發機制的原理，分析下源代碼。
比喻
如果將Activity比作一家事件處理公司的話，那么有些概念就比較好理解。首先，董事長（Activity）管理著所有的管理層和員工（ViewGroup和View），當有業務發生的時候（Touch事件），董事長會吩咐他的秘書（PhoneWindow）去處理這件事情，當然，秘書也不可能自己處理，所以他會告訴總經理（DecorView）說現在有一筆業務，需要在公司內找到合適部門或者人來完成這件事情。
這里呢，公司在成立之初就已經定下了業務執行的規范和流程，以免發生職責不清和層級不明的情況：
1、分發業務（dispatchTouchEvent）：所有的業務都必須由總經理往下分配，且必須依次詢問他所直屬的部門和個人（DOWN事件），如果有個人或者部門反饋說能夠處理這筆業務（return true），那么總經理就將接下來所有的與該筆業務有關的事物（MOVE，UP事件），都交給其處理。
2、所有部門（ViewGroup）都有與總經理相同的處理流程。部門會依次詢問其下的員工和子部門，如果有子部門或員工反饋說能夠處理，那么該部門就反饋給上級說，這件業務本部門可以處理。但是需要注意一點。所有的部門只能夠知道其下級部門和個人的情況，而不能知道子部門的內部的情況。
3、部門如果依次詢問了子部門或者員工，發現都無法處理該業務，那么部門本身會去評估自己是否能夠處理該業務（調用父類（View)的dispatchTouchEvent方法，這時處理方式和普通的View一樣）。然后將能否處理的反饋返回給上級。如果任何一個子部門或者員工反饋了能夠處理，那么部門將不會再去評估自己能否去處理，直接反饋能夠處理。反饋后將記住能處理的部門或員工。
4、部門還有員工沒有的特殊權利，是能夠攔截任務的分發。其攔截權利可以是在分發的過程中，也可以是任務執行到一半的時候。如果該部門的子部門或者員工已經拿到該事件的處理權了。那么后續的事件都會經過該部門進行分配。其有權利在任何時刻攔截該任務，一旦攔截了該任務，那么將交由自己來處理。同時非常重要的一點，該部門將會忘記其原先的分配對象，以后每次事件過來，都不會再去分配下去（因為已經忘記了~）。
5、員工或者子部門也有特殊的權利，那就是一開始就告訴部門不要去攔截事件（disallowIntercept），這個優先級要比攔截的優先級要高，所以一旦設置了這個，那么上級部門將無權去攔截。
6、任何部門和個人都有評估和處理的方法（View是onTouch、onTouchEvent。如果子控件不處理，ViewGroup會調用自己的dispatchTouchEvent方法，這和View的過程一樣）。處理時有一套默認的流程，但是由于每個部門和個人的情況不一樣（不同的VIew和ViewGroup），所以也會有自己獨特的處理辦法（重寫onTouchEvent方法等）。判斷后返回自己的申明（true或false）。
7、員工（View）和部門有一點區別（ViewGroup重寫了dispatchTouchEvent方法）。員工在分發事件（dispatchTouchEvent）時，由于沒有下屬，所以他會根據自身的情況來判斷能否處理該業務（與ViewGoup沒有子類處理交給自身判斷一樣）。首先他會判斷自己是否有整體處理的能力（OnTouchListener），如果有的話那么他會判斷自己是否愿意整體處理這個業務（onTouch方法的返回值），如果是的話，那么就反饋，不會去細致處理。
8、如果沒有整體處理的能力，那么員工會去判斷自己是否能夠細致處理（onTouchEvent，默認方法中會去判斷CLICKABLE等標志）的能力，如果有的話，則反饋。一般，如果我們自定義員工的話，可以自定義處理的方式。
9、在處理事件的時候，員工會從事件中抽取出相應的模式（onClick，onLongClick），告訴客戶需要去處理這件事（具體看點擊的功能，程序員去處理）。
10，最后，如果沒有部門或者員工去處理這筆業務的話，那么會回傳到公司（Activity）自身，那么只能公司自己去處理了（onTouchEvent）。
總結
這里以一種形象的方式講了事件分發機制。下篇會簡要分析下分發的源代碼。
