做测试开发的童鞋都知道，UI自动化你绕不开selenium, webdrvier, appium框架，那么这三者之间有什么关联，它们的原理是什么呢？
简单来说就是：
Selenium2 将浏览器原生的API封装成WebDriver API ，webdriver 是基于 http协议的；
appium是基于 webdriver 协议添加对移动设备自动化api扩展而成的，基于tcp/ip协议（使用了socket接口）
appium-IOS 和安卓都差不多，有细小差别，分PC和手机两块讲：
1、首先是PC端， 测试人员执行测试脚本（java,python等脚本）通过appium client 转换为json格式传递给appium server
2、 appiumserver 启动了一个监听端口例如4724, 同时向手机端adb push 一个bootstrap.jar/bootstrap.js 的脚本，手机端通过该脚本同时监听端口4724
3、PC和手机端就通过这个端口实现了通信和交互，基于socket通信（一个封装了TCP/IP协议的接口）
4、手机端通过该端口传输的命令执行APP， bootstrap里面封装了安卓和苹果的自动化测试框架UIautomator(低版本的安卓是instrumentation ) 执行相应的命令
5、执行完操作后通过端口返回给PC端，PC端根据返回结果 json 做校验，同时也知道了操作是否执行成功
初步认识appium工作过程 1.appium有C/S模式 2.appium是基于webdriver协议对移动设备自动化api扩展而成的，所有具有和webdriver一样的特性，比如多语言支持。 3.webdriver是基于http协议的，第一连接会建立一个session会话，并通过post发送一个json告知服务端相关测试信息。 4.对于Android来说，4.2以后是基于UiAutomator框架实现查找注入事件的，4.2以前则是instrumentation框架的，并封装成一个叫Selendroid提供服务。 5.客户端只需要发送http请求实现通讯，意味着客户端就是多语言支持的。 6.appium服务端是node.js写的，所以安装那个平台都是先安装node，然后npm install -g appium。
1.bootstrap的作用 bootstrap是Appium运行在安卓测试机的一个UIAutomator测试脚本，该脚本的唯一功能就是在目标机器开启一个socket服务器来把一个session中Appium从PC端过来的命令发送给UiAutoamtor来执行处理。 它会监听4724端口获得命令，然后交给UiAutomator来处理。
2.bootstrap 首先，bootstrap是uiautomator的测试脚本，它的入口类bootstrap继承于UiautomatorTestCase，所以Uiautomator可以正常运行它，它也可以正常使用uiautomator的方法，这是就是appium的命令可以转换成uiautomator的关键； 其次，，bootstrap是一个socket服务器，专门监听4724端口过来的appium的连接和命令数据，并把appium的命令转换成uiautomator的命令来让uiautomator进行处理； 最后，bootstrap处理的是从PC端传过来的命令
appium的架构原理如图所示，由客户端和服务端组成，客户端与服务端通过JSON进行通信；
各部分的含义： （1）Appium服务器。它是一个基于node.js的HTTP服务器。主要功能是接受从Appium客户端发起的链接，监听客户端发送来 命令，将命令发送到bootstrap.jar(IOS为bootstrap.js)执行，并将命令的结果通过HTTP应答反馈给Appium客户端。 （2）Bootstrap.jar。Bootstrap.jar是在Android手机上运行的一个应用程序，它在手机上扮演TCP服务器的角色，当appium服务器需要运行命令时，Appium服务器与Bootstrap.jar建立TCP通讯,并把命令发送给Bootstrap.jar；Bootstrap.jar负责运行测试命令。 （3）Appium客户端。主要是指实现了Appium功能的webdriver协议的客户端Library,他负责与Appium服务器建立连接，并将测试脚本的指令发送给服务端。包括：python、Java、Ruby等。 （4）Seesion。Appium的客户端和服务端之间进行通信必须在一个session的上下文中进行。客户端发起通信的时候会首先发送一个叫做“Desired Capabilities”的JSON对象给服务端。服务端接收到该数据后，会创建一个session并将session的ID返回给客户端，之后客户端会用该session的ID发送后续的命令。 （5）Desired Capalities。Desired Capalities是一组设置的键值对，用于通知Appium服务端建立需要的session,其中一些设置可以改变Appium的运行行为。
appium的整体架构是C/S模式，整体流程（返回顺序为逆向）：脚本请求 ——> 4723端口appium server ——> 解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator
Session 的作用就是它在appium服务上保持设备的状态信息，供在任何时间进行访问，在多次的操作行为中，存储在 Session对象中的配置信息将不会丢失，而是在整个用户会话中一直存在下去，整个测试进程中设备与程序的联系不会断开，也不需要每次都发送带配置信息的请求，程序都知道对哪个设备进行测试操作。当测试结束后，需关闭webdriver，driver.quit()会关闭所有关联窗口和session，并且也会把进程也关闭。
好像有点难理解，可以这么来解释： webdriver, 就是工程师， Boss说，webdriver, 你去搞定客户的问题。 webdriver立即给客户打电话，客户解决了问题。 然后结果通过webdriver反馈给Boss, Boss就知道结果了。
appium，是工程师， Boss写封邮件，命令apppium, 你去解决非洲客户问题。 Appium赶忙送了一个小弟刘无能去乌干达。 刘无能到达以后，赶紧申请了一条专线跟总部汇报的。 Appium赶紧下了一条指令给刘无能。 刘无能指挥当地工人干活，解决客户问题。 反过来，客户的反馈，通过刘无能，然后电话打个appium,最后反应到Boss那里。
这里，打电话就是http协议； 写邮件就是sockt协议. 刘无能就是bootstrap 专线就是session 当地工人就是uiautomator(Android), uiautomation(IOS)
这样就容易理解些了吧。所以开始启动起来特别的慢，能够明白了它都干了些什么了吧。
