接著上一篇，我們開始聊聊APPIUM的框架和執行模式。廢話不多說直接上圖。

1.首先自動化指令碼通過RobotFrameWork將命令傳遞給Appium的客戶端；

2.然後【Appium的客戶端】將接受到的命令傳送給【Appium的服務端】；

3.【Appium服務端】將指令碼中的程式碼命令轉換成手機模擬器所能識別的命令通過【ADB】傳送給【模擬器】，從而控制被測試的應用軟體。

然後摘抄了一段源自網路的Appium的理論知識：

Appium原理小結

Api介面呼叫selenium的介面，android底層用android的instrumentation(API2.3+ 通過繫結另外一個獨立的selendroid專案來實現的)、uiautomator介面(API4.2+)，ios底層用ios的uiautomation介面。

Client/ServerArchitecture

Appium server是用node.js寫的，安裝node.js可以直接用npm命令或dmg，server端功能：監聽一個埠，接收client傳送來的command，翻譯這些命令，把這些command轉成移動裝置可以理解的形式傳送給移動裝置，然後移動裝置執行完command後把執行結果返回給appium server，appium再把執行結果返回給client。

Client其實就是發起command的裝置，一般來說就是執行程式碼的機器，執行appium測試程式碼的機器，可以把client理解成程式碼，這些程式碼可以是java、python、ruby、js，只要實現了webdriver標準協議就可以。

跨語言：只要支援selenium webdriver api和這種語言相關的client libraries就可以。Server放在任意機器上，哪怕是雲伺服器都可以(appium和webdriver天生適合雲測試)。

Session

session就是一個會話，在webdriver/appium，你的所有工作永遠都是在session start後才可以進行的。一般來說，通過POST /session這個URL，然後傳入Desired Capabilities就可以開啟session了。

開啟session後，會返回一個全域性唯一的sessionid，以後幾乎所有的請求都必須帶上這個session id，因為這個seesion id代表了你所開啟的瀏覽器或者是移動裝置的模擬器。

進一步思考一下，由於session id是全域性唯一，那麼在同一臺機器上啟動多個session就變成了可能，這也就是selenium gird所依賴的具體理論根據。

Desired Capabilities

Desired Capabilities攜帶了一些配置資訊。從本質上講，這個東東是key-value形式的物件。你可以理解成是java裡的map，python裡的字典，ruby裡的hash以及js裡的json物件。實際上Desired Capabilities在傳輸時就是json物件。

Desired Capabilities最重要的作用是告訴server本次測試的上下文。這次是要進行瀏覽器測試還是移動端測試？如果是移動端測試的話是測試android還是ios，如果測試android的話那麼我們要測試哪個app？ server的這些疑問Desired Capabilities都必須給予解答，否則server不買賬，自然就無法完成移動app或者是瀏覽器的啟動。

Appium Clients

原生的webdriver api是為web端設計的，appium官方提供了一套appium client，為不同的語言的開發者可以測試自己的app，測試的時候，一般要使用這些client庫去替換原生的webdriver庫。算是client對原生webdriver進行了一些移動端的擴充套件。

好啦，第二篇就寫這麼多吧，重頭戲還在後面了，第三篇我將給大家展示這個框架是怎麼使用的，也就是如何實現Appium的自動化測試。最後小碎嘴一下，天氣好冷啊~大家注意多保暖。