我们以 Facebook 开源的 WDA 为例，看看它的 FBScreenshotCommands.m 文件:
　　#import "FBScreenshotCommands.h"
　　#import "XCUIDevice+FBHelpers.h"
　　@implementation FBScreenshotCommands
　　#pragma mark - <FBCommandHandler>
　　+ (NSArray *)routes
　　{
　　return
　　@[
　　[[FBRoute GET:@"/screenshot"].withoutSession respondWithTarget:self action:@selector(handleGetScreenshot:)]，
　　[[FBRoute GET:@"/screenshot"] respondWithTarget:self action:@selector(handleGetScreenshot:)]，
　　];
　　}
　　#pragma mark - Commands
　　+ (id<FBResponsePayload>)handleGetScreenshot:(FBRouteRequest *)request
　　{
　　NSString *screenshot = [[XCUIDevice sharedDevice].fb_screenshot base64EncodedStringWithOptions:NSDataBase64Encoding64CharacterLineLength];
　　return FBResponseWithObject(screenshot);
　　}
　　@end
　　这里首先会注册一个 /screenshot 的路由，并且制定处理函数为 handleGetScreenshot，然后函数内部调用 XCUIDevice 的截图方法。
　　所以分析到这里，WDA 的套路很清晰了，它能根据被测试应用的 BundleID 将它唤起，然后自己进入死循环保证测试用例一直不退出。此时等待服务器传来 URL 数据，然后解析 URL，分发到对应模块，各个模块根据 URL 指令执行对应的测试操作，终再把测试结果返回。
　　Appium 服务端
　　简单来说，Appium 服务端是一个 Node.js 应用，这个应用跑在电脑上，用于和 WDA 进行通信。刚刚我们看到了截图命令的 URL 是 /screenshot，可以想见还有别的类似的测试操作，所以 WDA 有必要和 Appium 服务端约定一套通信协议。考虑到 Appium 还支持 Android 测试，所以在安卓手机上也有类似的东西需要和 Appium 服务端进行交互。这样一来，约定一套通用的协议显得非常重要。
　　Appium 采用的是 WebDriver 协议。在 w3.org 上有一个对该协议的详细描述，而 Selenim 的官网 也介绍了 WebDriver 协议。目前我尚不知道这两处介绍的关系，是互为补充 or 两套规范，但可以肯定的是下面这段话的介绍:
　　WebDriver’s goal is to supply a well-designed object-oriented API that provides improved support for modern advanced web-app testing problems.
　　所以简单的把 WebDriver 理解成一套通用的测试协议即可。
　　Appium 客户端
　　Appium 客户端是指我们写的那些测试代码了。Appium 支持多种测试语言的根本原因在于，WebDriver 协议为各种主流语言提供了一个第三方库，能够方便的把测试脚本转化成符合 WebDriver 规范的 URL。比如 https://www.w3.org/TR/webdriver/#list-of-endpoints 规定了包括截图、寻找元素、点击元素等操作对应的 URL 格式。
　　我们的项目目前使用 Java 语言来编写测试脚本，这样的好处是 Android 工程师可以承担起维护和编写 Android、iOS 两个平台下测试代码的重任了。
　　总结
　　其实 Appium 的原理非常简单，一句话能概括:
　　提供各个语言的第三方库，将测试脚本转化成 WebDriver 协议下的 URL，通过 Node 服务发送到各个平台上的代理工具，代理工具在运行过程中不断接收 URL，根据 WebDriver 协议解析出要执行的操作，然后调用各个平台上的原生测试框架完成测试，再将测试结果返回给 Node 服务器。
　　后再友情提醒一句:
　　iOS 上的真机测试环境很难配置，如果搞不定，不要气馁，多试几次，也许明天好了