接着上一篇，我们开始聊聊APPIUM的框架和运行模式。废话不多说直接上图。
文章图片
【RF|RobotFrameWork+APPIUM实现对安卓APK的自动化测试----第二篇【原理】】
文章图片
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的自动化测试。最后小碎嘴一下，天气好冷啊~大家注意多保暖。
