appium 的核心其实是一个暴露了一系列 REST API 的 server。
这个 server 的功能其实很简单：监听一个端口，然后接收由 client 发送来的 command。翻译这些 command，把这些 command 转成移动设备可以理解的形式发送给移动设备，然后移动设备执行完这些 command 后把执行结果返回给 appium server，appium server 再把执行结果返回给 client。
在这里 client 其实就是发起 command 的设备，一般来说就是我们代码执行的机器，执行 appium 测试代码的机器。狭义点理解，可以把 client 理解成是代码，这些代码可以是 java/ruby/python/js 的，只要它实现了 webdriver 标准协议就可以。
这样的设计思想带来了一些好处：
session 就是一个会话，在 webdriver/appium，你的所有工作永远都是在 session start 后才可以进行的。一般来说，通过 POST /session 这个 URL，然后传入 Desired Capabilities 就可以开启 session 了。
开启 session 后，会返回一个全局唯一的 session id，以后几乎所有的请求都必须带上这个 session id，因为这个 seesion id 代表了你所打开的浏览器或者是移动设备的模拟器。
进一步思考一下，由于 session id 是全局唯一，那么在同一台机器上启动多个 session 就变成了可能，这也就是 selenium gird 所依赖的具体理论根据。
本文版权归乙醇所有，欢迎转载，但请注明作者与出处，严禁用于任何商业用途
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 或者是浏览器的启动。
具体例子如下：
For example, we might set the platformName capability to iOS to tell Appium that we want an iOS session, rather than an Android one. Or we might set the safariAllowPopupscapability to true in order to ensure that, during a Safari automation session, we’re allowed to use JavaScript to open up new windows. See the capabilities doc for the complete list of capabilities available for Appium
这就是每次我们在命令行用 appium 命令打开的东西。
由于原生的 webdriver api 是为 web 端设计的，因此在移动端用起来会有点不伦不类。appium 官方提供了一套 appium client，涵盖多种语言 ruby/java/python，在我看来 ruby client 是实现最好的。在测试的时候，一般要使用这些 client 库去替换原生的 webdriver 库。这实际上不是替换，算是 client 对原生 webdriver 进行了一些移动端的扩展，加入了一些方便的方法，比如 swipe 之类，appium client 让我们可以更方便的写出可读性更好的测试用例。
appium server 的 GUI 版本，前者用在 osx 上，后者是 windows 上。可视化、不需要装 node，可以看 app 的 UI 结构是这个东东的卖点。
下一讲，appium 的安装
本文版权归乙醇所有，欢迎转载，但请注明作者与出处，严禁用于任何商业用途