先看整體流程圖
appium的整體架構是C/S模式，整體流程（返回順序爲逆向）：
腳本請求 ——> 4723端口appium server ——> 解析參數給PC端4724端口 ——> 發送給設備4724端口 ——> 通過設備4724端口發給bootstrap.jar ——> Bootstrap.jar把命令發給uiautomator
1、腳本請求 ——> 4723端口appium server ：
首先我們要開啓appium服務，即Appium server，也就是在命令行用appium命令打開的東西，默認監聽4723端口。4723端口專門和腳本打交道，基於WebDriver協議。webdriver是按照server – client的經典設計模式設計的，作用就是啓動基於WebDriver Wire協議的appium服務，接下來腳本與appium server的通信實際上是一個HTTP request請求給appium server，在請求的body中，會以WebDriver Wire協議規定的JSON格式的字符串來告訴appium服務我們希望設備接下來做什麼事情。讀到這裏，難免有同學會有疑問了，因爲有一些文檔上面說腳本發送請求是基於Json wire protocol協議的，首先這是完全正確的，接下來就解釋一下：
appium中的Json wire protocol繼承自selenium的webdriver wire protocol，並進行了擴展，使得Json wire protocol能夠控制不同的移動設備的行爲。如果大家覺得對於webdriver這個名詞覺得比較陌生的話，接下來說一個詞肯定熟悉 - Selenium。Selenium是一個瀏覽器自動化操作框架。Selenium主要由三種工具組成。第一個工具SeleniumIDE，是Firefox的擴展插件，支持用戶錄製和回訪測試，錄製/回訪模式存在侷限性，對許多用戶來說並不適合，因此第二個工具——Selenium WebDriver提供了各種語言環境的API來支持更多控制權和編寫符合標準軟件開發實踐的應用程序。最後一個工具——SeleniumGrid幫助工程師使用Selenium API控制分佈在一系列機器上的瀏覽器實例，支持併發運行更多測試。在項目內部，它們分別被稱爲“IDE”、“WebDriver”和“Grid”。
那麼webdriver wire protocol又是什麼呢：
在我們創建一個WebDriver的過程中，Selenium首先會確認瀏覽器的native component是否存在可用而且版本匹配。接着就在目標瀏覽器裏啓動一整套Web Service，這套Web Service使用了Selenium自己設計定義的協議，名字叫做The WebDriver Wire Protocol，只不過對應到我們這裏的瀏覽器指的是Appium。
WebDriver Wire協議是通用的，也就是說不管是FirefoxDriver還是ChromeDriver，啓動之後都會在某一個端口啓動基於這套協議的Web Service。對應到Appium，可以理解爲是AppiumDriver。接下來，我們調用WebDriver的任何API，都需要藉助一個ComandExecutor發送一個命令，實際上是一個HTTP request給端口上的Web Service。在我們的HTTP request的body中，會以WebDriver Wire協議規定的JSON格式的字符串來告訴Selenium我們希望瀏覽器（設備）接下來做什麼事情。
說到這裏可能會有疑問了，上面說到的是腳本請求對設備進行操作，但前提是，我們要對誰進行操作測試呢？這裏就引入一個新名詞：desiredCapabilities。瞭解了上述之後，再去看腳本怎麼將desiredCapabilities傳遞給appium server就明白多了，腳本通過Json Wire Protocol協議以json格式發送測試設備信息給server端，測試設備信息被攜帶在Desired Capabilities中，這個東西實質上是一個key-value形式的對象，Desired Capabilities最重要的作用是告訴server本次測試的上下文。這次是要進行瀏覽器測試還是移動端測試？如果是移動端測試的話是android還是ios？如果android的話我們要測試哪個app？server的這些疑問Desired Capabilities都必須給予解答，否則server不買賬，針對我們現在所說的安卓，它帶來的影響就是無法完成app的啓動。
那麼，將測試設備信息告知之後，是不是就可以開始進行測試了呢？答案是：NO。這裏又要引入一個名詞：session。session就是一個會話，在webdriver/appium，你的所有工作永遠都是在session start後纔可以進行的。client 創建1個session，在該session中通過http向appium server發送請求，appium server解析請求，完成相應操作並返回response。
Session在計算機中，尤其是在網絡應用中，稱爲“會話控制”。Session 對象存儲特定用戶會話所需的屬性及配置信息，對應到這裏其實就是desiredCapabilities中的配置信息參數。腳本通過POST /session這個URL，然後傳入Desired Capabilities就可以開啓session了，由於這是第一次請求創建session，所有並沒有一個已創建的session id，所以appium server會調用android driver（appium升級到2.0.0後，原有的AppiumDriver函數變成抽象函數了，需更改爲AndroidDriver）爲client生成一個session並且生成一個與此session相關聯的session id，這個 session id將被在本次響應中返回給客戶端保存，當下次腳本發出操作請求時就會自帶session id爲唯一標識，代表所打開的設備，Appium server會按照此session id把這個session檢索出來使用，腳本向appium server發送的請求即是存在於創建的session中的。
Session 的作用就是它在appium服務上保持設備的狀態信息，供在任何時間進行訪問，在多次的操作行爲中，存儲在 Session對象中的配置信息將不會丟失，而是在整個用戶會話中一直存在下去，整個測試進程中設備與程序的聯繫不會斷開，也不需要每次都發送帶配置信息的請求，程序都知道對哪個設備進行測試操作。當測試結束後，需關閉webdriver，driver.quit()會關閉所有關聯窗口和session，並且也會把進程也關閉。
2、解析參數給PC端4724端口 ——> 發送給設備4724端口 ——> 通過設備4724端口發給bootstrap.jar ——> Bootstrap.jar把命令發給uiautomator：
創建session成功之前，就已將bootstrap.jar放入手機中，並開啓設備上的基於appium bootstrap的socket服務，綁定本機和boostrap通信的端口號4724用於和Android設備通訊，默認監聽4724端口，等待client的連接。
Appium server將腳本的請求解析後給到4724端口，通過設備的4724端口轉發解析後的請求， 此時，對於socket服務來說，appium server就充當了client的角色，appium server通過4724端口主動去請求設備上的socket服務，即向socket服務發送請求，即bootstrap.jar，Bootstrap.jar再把Appium的命令轉換成uiautomator的命令來讓uiautomator進行處理。有請求就有返回，socket接收到請求後會做出響應，原路返回給腳本，然後腳本再進行下一次的請求。
網絡上的兩個程序通過一個雙向的通信連接實現數據的交換，這個連接的一端稱爲一個socket。appium和手機的通信過程,主要是數據交換的一個過程，socket的作用是就是爲了實現雙向通信，它需要一對端口號，對應到這裏就是4724，手機端的bootstrap就是socket-server端，appium server就是socket-client端。
關於socket的通信原理，先從服務器端說起。服務器端先初始化Socket，然後與端口綁定(bind)，對端口進行監聽(listen)，調用accept阻塞，等待客戶端連接。在這時如果有個客戶端初始化一個Socket，然後連接服務器(connect)，如果連接成功，這時客戶端與服務器端的連接就建立了。客戶端發送數據請求，服務器端接收請求並處理請求，然後把迴應數據發送給客戶端，客戶端讀取數據，最後關閉連接，一次交互結束。