一.Appium框架组成  Appium框架组成是自动化脚本即client端（通过Java编写的代码，也可以通过其他语言编写），Appium指令服务器，sdk通信环境（**Android**模拟器）或移动端设备（这里是**测试****Windows**平台的设备，）。   二.Appium通信原理： Appium通信原理：Client端发送自动化指令给Appium **server**，Appium Server接收到client发送的指令后，转换为移动端能够识别的指令，然后发送给移动端设备，并对移动端设备进行操作。 2.1 Client端： 一般来说就是运行代码的机器，即我们是用Java语言编写的代码，也可以用其他**Selenium**支持**Python**，ruby，C#等语言来编写，Appium提供的Appium-client API是Appium通过扩展Selenium的Webdriver协议而来的，我们编写代码的时只要实现Webdriver标准协议即可。   2.2 Appium Server： Appium Server功能是监听接口，接收client端发送的command，然后将command转为移动端能够识别的command，然后发送给移动设备进行操作，再等待移动设备返回来的操作结果，将操作结果发送给client端。 Appium server是可以放在client端，也可以放在云端。 Appium server 默认的端口号是4723，用于Appium server监听client端的发送来的请求。 2.3 Android设备      Android端，Appium基于Webdriver协议，利用Bootstrap.jar,最后通过调用UIautomatior命令，实现APP的自动化测试（Android4.2以前的版本是用Instrumentation框架，通过绑定另外一个独立的selendroid项目来实现），Android4.2以后的版本是用UIautomator）。UIAutomator测试框架是Android SDK自带的APP UI自动化测试Java库，另外UIAutomator对H5支持有限，Appium引入了Chromedriver以及Safaridriver来实现H5的自动化。 在Android设备的**工作**过程：   1.Appium server将监听到的4723端口的指令，转发给中间件Bootstrap.jar，Bootstrap.jar是用Java编写的，安装在Android手机上；   2.Bootstrap监听4724端口并接收Appium server的指令；   3.Bootstrap再通过调用UIautomator的命令来实现具体的command操作。   4.最后Bootstrap将执行的结果返回给Appium server。 三、appium的整体架构是C/S模式，整体流程（返回顺序为逆向）： 脚本请求 ——> 4723端口appium server ——> 解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator  1、脚本请求 ——> 4723端口appium server ： 首先我们要开启appium服务，即Appium server，**默认监听4723端口**。4723端口专门和脚本打交道，基于WebDriver协议。webdriver是按照server – client的经典设计模式设计的，作用就是启动基于WebDriver Wire协议的appium服务，接下来**脚本与appium server的通信实际上是一个HTTP request请求给appium server**，在请求的body中，会以WebDriver Wire协议规定的**JSON**格式的字符串来告诉appium服务我们希望设备接下来做什么事情。 appium中的Json wire protocol继承自selenium的webdriver wire protocol，并进行了扩展，使得Json wire protocol能够控制不同的移动设备的行为。 上面说到的是脚本请求对设备进行操作，但前提是，我们要对谁进行操作测试呢？这里就引入一个新名词：**desired Capabilities**。了解了上述之后，再去看脚本怎么将desired Capabilities传递给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 对象存储特定用户会话所需的属性及配置信息，对应到这里其实就是desired Capabilities中的配置信息参数**。脚本通过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)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。 四、**Appium理念** Appium实现自动化测试需要遵循以下四个理念: 　　(1)实现自动化测试时，不必重新编译或者以任何方式修改app; 　　(2)编写或运行测试case的时候可以使用多种语言； 　　(3)一个自动化测试框架不需要重造轮子; 　　(4)无论在精神上还是实践上，自动化框架都是开源的 五、**Appium设计** 使用如下方案来遵循以上四个理念: 　　(1)使用供应商提供的测试框架满足理念1 　　iOS: [**苹果**](javascript:;)的 UIAutomation。 　　[**Android**](javascript:;) 4.2+: [**Google**](javascript:;)的 UiAutomator。 　　Android 2.3+: Google的 Instrumentation.(Instrumentation通过绑定一个独立的Selendroid来提供支持)。 　　(2)使用供应商提供的统一的框架API，即WebDriver API满足理念2 　　WebDriver（也叫[**Selenium**](javascript:;) WebDriver）指定了一个服务端/客户端协议（也加JSON Wire Protocol），基于这个协议，使用任何语言编写的客户端都可以向服务端发送合适的HTTP请求。也就是说你可以选择你喜欢的语言来编写测试运行器或测试框架。 　　(3)同样使用WebDriver来满足理念3 　　事实上，WebDriver已经是网页浏览器自动化测试的标准，也是W3C的工作草案，所以没有必要为移动测试建立一套新的标准，只需要基于WebDriver协议扩展新的API来方便移动自动化测试即可。 　　(4)很明显满足了理念4，当我们读到这边[**文章**](javascript:;)的时候就是因为Appium是开源的。