接着上一篇，我們開始聊聊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的自動化測試。最後小碎嘴一下，天氣好冷啊~大家注意多保暖。