前語
最近，Android手機上的手機管家更新了新版本，提供了紅包鬧鐘功能，只要有微信紅包或者QQ紅包，就會自動提醒。恰逢最近又在做UI自動化的工作，使用到UI Automator框架。幾行程式碼，就可以讓手機自動完成某些操作，很有意思，今天就來扒一扒這背後的原理。
UI Automator
首先，官方文件鎮樓：https://developer.android.com/training/testing/ui-automator
傳統的手工測試，我們需要點選一些控制元件元素，來檢視輸出的結果是否符合預期。比如在登入介面，輸入正確的使用者名稱和密碼，點選登入按鈕後，就可以正常登入。
如果這些操作，每一次都需要手工執行的話，是需要大量的人力成本的，比如手機QQ安卓端， 手工用例有上萬條。所以就需要大力推廣自動化測試。
UI自動化作為測試金字塔的最頂層，承擔了端到端的需求迴歸與灰度驗證任務，其重要性不言而喻。
UI Automator作為一款Google谷歌推出的，用於UI自動化測試的工具，有著優秀的API與社群文件。也是目前主流的Android自動化測試框架。它提供了一系列用於獲取手機上頁面控制元件元素和操作元素的方法，非常方便。
注意：UI Automator測試框架是基於instrumentation的API，執行在Android JunitRunner 之上，同時UI Automator Test只執行在 Android 4.3(API level 18)以上版本。
從一次搶紅包說起
想想我們平時搶紅包的流程是什麼樣的呢？
假如你現在正在刷劇，這時候通知欄提醒你微信有紅包了，於是你點選通知欄的訊息，進入了微信頁面，找到了紅包，再點選拆紅包的按鈕，小手一抖，幾毛到手。
這麼一想，其實這些步驟完全是一個體力活，要是有個機器人能自動搶就好了！
這個機器人的背後就是AccessibilityService，當然它的具體作用我們稍後再講。
按照我們的現有的邏輯，自動搶紅包大致分為以下幾個步驟：
- 識別獲取通知欄的微信紅包的通知事件
- 點選通知欄的訊息
- 獲取紅包的訊息
- 點選按鈕拆紅包
這裡面最最重要的兩個步驟就是識別，操作。接下來我們侃侃這兩步。
怎麼識別頁面控制元件元素？
首先，我們先來認識一下UI Automator viewer這個工具，位於<android-sdk>/tools/bin目錄下，他可以很方便地掃描和分析 Android 裝置上當前顯示的介面元件，展示一棵完整的控制元件樹，與某一個葉子節點（控制元件元素）的屬性。
從上圖我們可以看到，頁面的一個登入按鈕元素，有自己的text屬性，resource-id屬性，content-desc屬性等等。
在UI Automator中，存在uiDevice類，可以通過findObject方法，檢視到這些控制元件元素。
UiObject2 login_btn = uiDevice.findObject(By.desc("登入"));
現在我們深入findObject方法，
public UiObject2 findObject(BySelector selector) {
// 這裡返回匹配選擇器的第一個節點，如果沒有找到匹配的話，就返回null
AccessibilityNodeInfo node = ByMatcher.findMatch(this, selector, getWindowRoots());
return node != null ? new UiObject2(this, selector, node) : null;
}
可以看到，這裡傳入了一個選擇器selector，然後在ByMatcher的findMatch方法中查詢，如果找到了，就返回一個AccessibilityNodeInfo的node，如果沒有找到就返回null。
首先看ByMatcher是什麼東東？這是一個實用工具類，通過它的方法，我們可以在一個樹形結構中搜尋到匹配selector的節點。
findMatch方法很簡單，就是一個從根節點開始搜尋的樹型搜尋方法，不用多說。
AccessibilityNodeInfo是什麼呢？這相當於一個節點，在AccessibilityService的角度來看，這就是一個可訪問到的控制元件節點。
那這麼來看，findMatch的第三個引數，就是傳入的控制元件樹的根節點了嗎？我們深入看一下這裡的getWindowRoots方法的關鍵程式碼，
/** 這裡返回活動視窗容器的root節點的列表 */
AccessibilityNodeInfo[] getWindowRoots() {
// 等待執行緒空閒後再執行
waitForIdle();
// 初始化一個root節點的集合
Set<AccessibilityNodeInfo> roots = new HashSet();
// 通過UiAutomation獲取當前最底部的根視窗容器的root節點
AccessibilityNodeInfo activeRoot = getUiAutomation().getRootInActiveWindow(); // 這裡使用UiAutomation的方法
if (activeRoot != null) {
roots.add(activeRoot);
}
// 多視窗容器的搜尋
if (UiDevice.API_LEVEL_ACTUAL >= Build.VERSION_CODES.LOLLIPOP) {
for (AccessibilityWindowInfo window : getUiAutomation().getWindows()) { // 這裡使用UiAutomation的方法
AccessibilityNodeInfo root = window.getRoot();
…………
roots.add(root);
}
}
return roots.toArray(new AccessibilityNodeInfo[roots.size()]);
}
這裡要提一下， UiAutomation是Google在Android4.3的時候，釋出的一個自動化框架，它提供了與系統底層互動的能力。
再往下，我們看看UiAutomation的getWindows方法的關鍵程式碼：
public List<AccessibilityWindowInfo> getWindows() {
……
return AccessibilityInteractionClient.getInstance()
.getWindows(connectionId);
}
這裡獲取了AccessibilityInteractionClient的例項，然後返回了client的getWindows方法結果。然後再看一下這個getWindows方法的關鍵程式碼，
public List<AccessibilityWindowInfo> getWindows(int connectionId) {
……
IAccessibilityServiceConnection connection = getConnection(connectionId);
if (connection != null) {
// 首先去查詢快取，如果快取是有的，直接返回
List<AccessibilityWindowInfo> windows = sAccessibilityCache.getWindows();
……
return windows;
}
……
// 如果上面的快取不存在，就呼叫connection.getWindows方法
windows = connection.getWindows();
……
if (windows != null) {
// 把上面獲取到的新的windows放置快取，並返回
sAccessibilityCache.setWindows(windows);
return windows;
}
}
……
}
從IAccessibilityServiceConnection開始，在IDE中就開始提示Cannot resolve symbol 'IAccessibilityServiceConnection',無法再跳轉追蹤了。這是因為這個檔案屬於aidl檔案，這是Android中用於跨程式通訊的介面檔案，其具體原始碼可以在GoogleSource上面看到，有興趣的同學可以去看一下：IAccessibilityServiceConnection.aidl。 這說明，到這裡，UI Automation程式開始了與AccessibilityService程式的通訊。我們把當前的程式可以當做是客戶端，那麼Android系統服務就是服務端，從這裡開始，真正深入到Android系統的核心。在下面，就是Android Native的Library庫。
這裡，我們可以用時序圖總結一下：
怎麼操作頁面頁面元素？
我們現在已經知道了UI Automator是怎麼識別控制元件的，那怎麼操作控制元件元素呢？比如實現控制元件的自動點選。
我們還是從原始碼開始入手。比如一個控制元件元素的點選動作，在UiObject2類中，關鍵程式碼如下：
public void click() {
mGestureController.performGesture(mGestures.click(getVisibleCenter()));
}
首先，getVisibleCenter方法可以根據控制元件節點資訊，也就是上面提到的AccessibilityNodeInfo，獲取到這個控制元件節點的中心座標點。然後把這個座標點傳給mGesture的click方法，這裡是為了封裝點選動作，最後交給mGestureController物件的performGesture方法去實施這個點選動作。
對於mGesture的click方法，這個mGesture是一個構造工廠，它的click方法直接生成了一個PointerGesture物件，這個物件表示的是執行手勢操作時的動作。比如手勢的開始座標點，結束座標點，持續時間，移動方向，速度等等。
重點看一下mGestureController物件的performGesture方法，其關鍵程式碼如下：
public void performGesture(PointerGesture ... gestures) {
…………
// 執行傳入的手勢操作動作
MotionEvent event; // 這個是關於運動事件
for (……) {
…………
// 初始化運動事件，並呼叫UI Automation的injectInputEvent注入事件，非同步執行
event = getMotionEvent(……);
getDevice().getUiAutomation().injectInputEvent(event, true);
…………
}
…………
}
}
這裡可以看到事件的注入，也是通過UI Automation來完成的。看一下injectInputEvent方法的關鍵程式碼，
public boolean injectInputEvent(InputEvent event, boolean sync) {
…………
// 非同步執行，這段程式碼之前有關於鎖的操作
return mUiAutomationConnection.injectInputEvent(event, sync);
…………
}
我們發現也是通過一個connection來執行操作的，這個connection物件對應的IUiAutomationConnection類，也屬於一個aidl檔案。
這裡也放一個時序圖，
AccessibilityService
AccessibilityService根據官方說明，是指開發者通過增加類似contentDescription的屬性，從而在不修改程式碼的情況下，讓殘障人士能夠獲得使用體驗的優化，大家可以開啟AccessibilityService來試一下，點選區域，可以有語音或者觸控的提示，幫助殘障人士使用App。
當然，現在國內，AccessibilityService已經被玩兒壞了，越來越多的App借用AccessibilityService來實現了一些其它功能，甚至是灰色產品。
在國內，通過AccessibilityService實現的功能包括免Root自動安裝，自動搶紅包，微信訊息自動回覆等等黑科技。
當然也有一些惡意功能，比如軟體防解除安裝。當使用者想要解除安裝你的App的時候，一般會來到設定介面，找到你的App然後選擇解除安裝，那麼如果我們監控這個頁面，如果發現是自己的App，就直接退出，這樣不就無法解除安裝了嗎？是的，簡簡單單，但是背後的惡意卻讓人心寒。
使用AccessibilityService做自動化的步驟
大家看了上面的分析，可能對自動化有了一點興趣，其實歸納起來，步驟很簡單：
- 分析整個操作流程，拆解成關於每個控制元件的識別與操作。
- 利用uiautomatorviewer等工具，檢視對應UI控制元件的屬性，進行唯一性識別
- 編寫程式碼，查詢到元素後，進行點選等操作
- 相容性處理
結語
大家經常說“面試造火箭，工作擰螺絲”。其實大家平時工作可能都是“擰擰螺絲”，但是站在個人職業發展角度來看，是不可取的。只有不斷挖深自己的技術護城河，才能提高個人的不可替代性。在“擰螺絲”的時候，我們不妨抬頭看看，整個“火箭”是的構造。
參考
https://juejin.cn/post/6844903456809943053
https://developer.android.com/reference/android/app/UiAutomation
https://testerhome.com/topics/1887
https://blog.csdn.net/luoyanglizi/article/details/51980630
https://www.kancloud.cn/digest/uiautomatorpriciple/192698
