在上一個系列中我們分析了UiAutomator的核心源代碼,對UiAutomator是怎麼執行的原理有了根本的了解。今天我們會開始另外一個在安卓平台上基于UiAutomator的新起之秀--Appium的源代碼分析之旅。
本文在真個系列中會扮演一個簡單介紹的角色,不會分析不論什麼的代碼。僅僅會先給大家一個主要的印象,友善大家在持有這個印象的基礎上往下和本人一塊分析。
1. Bootstrap定義及在Appium中扮演的角色
我們先看一下本人大概一個月之前剛接觸appium時整理的一個高層架構圖
以下一部分就是藍色的就是bootstrap所在的位置,能夠看到它是執行在我們的安卓目标測試機器端的,它會監聽4724port獲得指令然後pass給UiAutomator來做處理。
那麼我們應該怎麼來給bootstrap做一個定義呢?我不知道官方有沒有做一個定義,可是依照我自己的語言,我會這樣來定義它:
- Bootstrap是Appium執行在安卓目标測試機器上的一個UiAutomator測試腳本。該腳本的唯一一個測試方法所做的事情是在目标機器開啟一個socketserver來把一個session中Appium從PC端過來的指令發送給UiAutomator來執行處理。
這個定義說明了bootstrap在appium和uiautomator中到底處于一個什麼樣的角色:
- 首先,它是一個uiautomator的測試腳本,它的入口類Bootstrap繼承于UiAutomatorTestCase。是以UiAututomator能夠正常執行它。它也能夠正常的使用uiautomator的方法,這個就是appium的指令能夠轉換成uiautomator的指令的關鍵
- 其次。它是一個socketserver。它專門監聽4724port過來的appium的連接配接和指令資料。并把appium的指令轉換成uiautomator的指令來讓uiautomator進行處理
- 最後,它處理的是appium從pc端過來的指令,而非一個檔案。這在初次接觸appium的朋友是非常easy困惑的,以為appium是整個腳本檔案發送到目标機器再由bootstrap進行分析處理的,事實并不是如此
2. Bootstrap關鍵類一覽表
上面寥寥幾句道出了bootstrap的定義,那麼往下我們就繼續寥寥幾行的把bootstrap這個jar包的關鍵類以及它的關鍵方法和對應的本人的一些說明給列出來。給大家現有一個draft idea每一個類大概是怎麼一回事,這樣我們往下的文章就比較好說。大家也比較好了解了。
Class | Key Method | Key Member | Parent | Description | Comment |
Bootstrap | testRunServer | 以一個UiAutomatorTestCase的方法的方式執行一個SocketServer來監聽4724port | 整個bootstrap是以UiAutomator的TestCase的方式執行的,是以這裡的Bootstrap這個類必需要繼承于UiAutomatorTestCase | ||
SocketServer | handleClientData | 讀取socket進來的字串指令資訊并轉換成AndroidCommand指令然後調用runCommand指令運作指令進行傳回 | |||
AndroidComma ndType | enum AndroidCommandType { ACTION,SHUTDOWN } | 安卓指令的類型,僅僅有兩種,shutdown的處理方式和普通的action會不一樣 | |||
AndroidComma nd | action/getElement | JSONObject json; AndroidCommandType cmdType; | 從使用者發過來的json指令資訊得到真正的指令 | ||
CommandHand ler | execute | 虛拟類,其它真實CommandHandler如click的父類 | |||
AndroidComma ndExecutor | execute | HashMap< String, CommandHan dler> map | map是全部的指令字串和真實的CommandHandler的一個映射。 其成員函數execute就是通過字串指令找到map相應的handler然後運作的 | ||
AndroidComma ndResult | AndroidCommandResult | JSONObject json | 組織json格式傳回值的類 | ||
AndroidElement | Click | UiObject el; String id; | 代表了一個控件 | 當中id是其在AndroidElementsHash維護的elements這個哈希表的key。并不是控件id。 | |
AndroidElement Hash | addElement | Hashtable< String, AndroidEle ment> elements; | 維護這個session目前為止碰到過的全部控件的哈希表 | 注意key就是上面AndroidElement的id這個成員變量。每有一個新的控件從appium pc端過來這個值就會加一 | |
Click | execute | CommandHandler | 處理點選指令的類。 真正運作的是傳進來的AndroidCommand相應UiObject的Click方法 | 其它find,drag,setText等指令同理 | |
Strategy | fromString | publicenumStrategy { CLASS_NAME ("class name”), CSS_SELECT OR("css selector”) , ID(“id"), NAME(“name "), LINK_TEXT( "link text"), PARTIAL_LI NK_TEXT(“p artial link text"), XPATH(“xpa th"), ACCESSIBIL ITY_ID(“ac cessibilit y id”), ANDROID_UI AUTOMATOR( "-android uiautomato r"); | 查找控件指令的政策類 | find這個CommandHandler會依據使用者給出的不同政策來用不同的方式進行控件查找。比方用xpath的方式和用uiautomator的方式是不一樣的 | |
這裡類在我們往下的分析文章中會做進一步的闡述,是以在這裡你僅僅須要由一個rough的idea這些類大概是怎麼一回事就能夠了。
3. Bootstrap執行流程簡單介紹
本來想畫一個類圖來描寫叙述bootstrap的架構的。但通過以上的類表能夠看出來bootstrap裡面的關鍵類基本沒有真正用到面向對象中的繼承,由于它們基本上都沒有父類。事實上我們也能夠了解,每一個類都不算複雜做的事情都不是非常多,就算略微須要做多點事情,組合其它的類來做就好了。
是以這裡我也放棄給大家提供類圖了。就提供我自己手畫的(還是那句話,本人的macbook pro上沒有安裝對應的收費流程圖軟體)一個以處理appium從pc端過來的click指令的流程為樣例的順序圖,大家先有一個初步的idea。看不明确也沒有關系。我後面會另外開一篇文章專門來描寫叙述這個流程以把全部的關鍵類給串起來的。
作者 | 自主部落格 | 微信 | CSDN |
天地會珠海分舵 | http://techgogogo.com | 服務号:TechGoGoGo 掃描碼: | http://blog.csdn.net/zhubaitian |