imsandroid

❶ Android輸入法IMMS服務啟動流程(3)(啟動IMS應用)

接上一篇，IMMS設置當前默認輸入法為LatinIME輸入法後，調用onCreate方法，然後會調用startInputInnerLocked啟動輸入法LatinIME的服務

本章節主要分析，onCreate生命周期中，各個流程調用

bindServiceAsUser啟動的服務是LatinIME

如上圖流程圖，服務啟動後，會調用到InputMethodManagerService的方法

該流程的主要邏輯：

完成對mMethodList和mMethodMap的數據初始化；檢查當前默認的輸入法(LatinIME)服務是否存在，很明顯，經過systemrunning過程以後，
mMethodMap已經包含了LatinIME，因此不會重復執行選擇和設定另外輸入法為默認輸入法的操作

該方法主要是檢查默認的LatinIME是否是可用的可用的輸入法，如果不可用，則設置為可用；
對應的settingprovider欄位為：

經過以上流程後，默認輸入法依然為LatinIME輸入法，該流程的主要作用為，將啟動的輸入法應用更新到可用列表enabled_input_methods中；
不過，目前默認的輸入法依然為LatinIME輸入法，跟重啟手機前，我們設置的輸入法(搜狗輸入法)依然不一致

下一篇文章，我們研究下，輸入法啟動過程中的onBind和onServiceConnected流程

❷ Android View 事件分發機制

Android 事件機制包含系統啟動流程、輸入管理(InputManager)、系統服務和 UI 的通信(WindowManagerService + ViewRootImpl + Window)、事件分發等一系列的環節。

Android 系統中將輸入事件定義為 InputEvent，根據輸入事件的類型又分為了 KeyEvent（鍵盤事件） 和 MotionEvent（屏幕觸摸事件）。這些事件統一由系統輸入管理器 InputManager 進行分發。

在系統啟動的時候，SystemServer 會啟動 WindowManagerService，WMS 在啟動的時候通過 InputManager 來負責監控鍵盤消息。

InputManager 負責從硬體接收輸入事件，並將事件通過 ViewRootImpl 分發給當前激活的窗口處理，進而分發給 View。

Window 和 InputManagerService 之間通過 InputChannel 來通信，底層通過 socket 進行通信。

Android Touch 事件的基礎知識：

KeyEvent 對應了鍵盤的輸入事件；MotionEvent 就是手勢事件，滑鼠、筆、手指、軌跡球等相關輸入設備的事件都屬於 MotionEvent。

InputEvent 統一由 InputManager 進行分發，負責與硬體通信並接收輸入事件。

system_server 進程啟動時會創建 InputManagerService 服務。

system_server 進程啟動時同時會啟動 WMS，WMS 在啟動的時候就會通過 IMS 啟動 InputManager 來監控鍵盤消息。

App 端與服務端建立了雙向通信之後，InputManager 就能夠將產生的輸入事件從底層硬體分發過來，Android 提供了 InputEventReceiver 類，以接收分發這些消息：

Window 和 IMS 之間通過 InputChannel 通信。InputChannel 是一個 pipe，底層通過 socket 進行通信。在 ViewRootImpl.setView() 過程中注冊 InputChannel。

Android 事件傳遞機制是 先分發再處理 ，先由外部的 View 接收，然後依次傳遞給其內層的 View，再從最內層 View 反向依次向外層傳遞。

三個方法的關系如下：

分發事件：

應用了樹的 深度優先搜索演算法 （Depth-First-Search，簡稱 DFS 演算法），每個 ViewGroup 都持有一個 mFirstTouchTarget, 當接收到 ACTION_DOWN 時，通過遞歸遍歷找到 View 樹中真正對事件進行消費的 Child，並保存在 mFirstTouchTarget 屬性中，依此類推組成一個完整的分發鏈。在這之後，當接收到同一事件序列的其它事件如 ACTION_MOVE、ACTION_UP 時，則會跳過遞歸流程，將事件直接分發給下一級的 Child。

ViewGroup 分發事件的主要的任務是找一個 Target，並且用這個 Target 處理事件，主要邏輯如下 ：

為什麼倒序查找 TouchTarget?
如果按添加順序遍歷，當 View 重疊時（FrameLayout），先添加的 View 總是能消費事件，而後添加的 View 不可能獲取到事件。

攔截事件：

[1] Android 事件分發機制的設計與實現
[2] Android 事件攔截機制的設計與實現

❸ Android ANR 機制

廣播的 ANR 處理相對簡單，主要是再次判斷是否超時、記錄日誌，記錄 ANR 次數等。然後就繼續調用 processNextBroadcast 函數，處理下一條廣播了。

ContentProvider 超時為 CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10s

Activity 的 ANR 是相對最復雜的，也只有 Activity 中出現的 ANR 會彈出 ANR 提示框。
最終的表現形式是：彈出一個對話框，告訴用戶當前某個程序無響應，輸入一大堆與 ANR 相關的日誌，便於開發者解決問題。

InputDispatching：

Activity 最主要的功能之一是交互，為了方便交互，Android 中的 InputDispatcher 會發出操作事件，最終在 InputManagerService 中發出事件，通過 InputChannel，向 Activity 分發事件。交互事件必須得到響應，如果不能及時處理，IMS 就會報出 ANR，交給 AMS 去彈出 ANR 提示框。

KeyDispatching：

如果輸入是個 Key 事件，會從 IMS 進入 ActivityRecord.Token.keyDispatchingTimeOut，然後進入 AMS 處理，不同的是，在 ActivityRecord 中，會先截留一次 Key 的不響應，只有當 Key 連續第二次處理超時，才會彈出 ANR 提示框。

窗口焦點：

Activity 總是需要有一個當前窗口來響應事件的，但如果遲遲沒有當前窗口（獲得焦點），比如在 Activity 切換時，舊 Activity 已經 onPause，新的 Activity 一直沒有 onResume，持續超過 5 秒，就會 ANR。
App 的生命周期太慢，或 CPU 資源不足，或 WMS 異常，都可能導致窗口焦點。

1. 判斷是否有 focused 組件以及 focused Application：

這種一般是在應用啟動時觸發，比如啟動時間過長在這過程中觸發了 keyevent 或者 trackball moteionevent 就會出現。

對應於

2. 判斷前面的事件是否及時完成：

對應於

出現這種問題意味著主線程正在執行其他的事件但是比較耗時導致輸入事件無法及時處理。

InputDispatcher 超時是最常見的 ANR 類型，而且其類型也比較多。
當用戶觸摸屏幕或者按鍵操作，首次觸發的是硬體驅動，驅動收到事件後，將該相應事件寫入到輸入設備節點， 這便產生了最原生態的內核事件。接著，輸入系統取出原生態的事件，經過層層封裝後成為 KeyEvent 或者 MotionEvent ；最後，交付給相應的目標窗口(Window)來消費該輸入事件。可見，輸入系統在整個過程起到承上啟下的銜接作用。

Input 模塊的主要組成：

每一個應用進程都會有一個 SignalCatcher 線程，專門處理 SIGQUIT，來到 art/runtime/signal_catcher.cc ：

當應用發生 ANR 之後，系統會收集許多進程，來 mp 堆棧，從而生成 ANR Trace 文件。收集的第一個，也是一定會被收集到的進程，就是發生 ANR 的進程。接著系統開始向這些應用進程發送 SIGQUIT 信號，應用進程收到 SIGQUIT 後開始 mp 堆棧。

[1] developer ANRs
[2] Android ANR 分析詳解
[3] 看完這篇 Android ANR 分析，就可以和面試官裝逼了！
[4] 微信 Android 團隊手把手教你高效監控 ANR
[5] Input 系統—ANR 原理分析 - Gityuan
[6] 徹底理解安卓應用無響應機制 - Gityuan
[7] 理解 Android ANR 的觸發原理 - Gityuan