一、框架组成

Appium由三个主要模块构成：Client端、Server端和移动端。

• ‌Client端‌：就是发起command的一端，狭义可以理解为Java/Python编写的自动化测试脚本或者自动化测试脚本执行的机器。

• Server端‌：即启动的appium进程。

• Server端作为信息中转站，接收Client端发送的请求，并根据请求类型和目标平台，将相应的控制命令转发到被测应用的移动端上。Server端启动时会创建一个HTTP服务，监听特定端口（如默认的4723端口）。

• 移动端‌：

• 移动端是真正执行自动化测试的地方。在Android设备上，通常有一个名为Bootstrap.jar的中间件；在iOS设备上，则是一个名为bootstrap.js的脚本。这些中间件负责监听来自Appium Server的命令，并在移动设备上执行相应的UI自动化操作。

核心思想：WebDriver 协议 + 客户端-服务器架构
Appium 的核心设计哲学非常巧妙，可以概括为两点：

1. 遵循 WebDriver 协议：Appium 没有自己创造一套新的标准，而是扩展了Selenium WebDriver 用于自动化浏览器的协议（称为 JSON Wire Protocol 及其后继者 W3C WebDriver）。这意味着任何兼容 WebDriver 的客户端库（如 Java、Python、JavaScript、Ruby 等）都可以直接用来写 Appium 脚本。

2. 客户端-服务器架构：Appium进程是一个 HTTP Server。测试脚本（客户端）通过 HTTP 请求向 Appium Server 发送命令（如“点击”、“查找元素”），Appium Server 接收到命令后，负责将其翻译成移动设备（iOS/Android）能够理解的原生指令并执行。

二、appium的几个重要概念

• client：就是发起command的一端，狭义可以理解为java/Python编写的自动化测试代码或者自动化测试代码执行的机器。

• appium server：即启动的appium进程，专门用于监听来自client端的请求，转发请求并转为移动端能识别的command（WebDriver协议），然后发送给移动端设备进行操作，等待操作结果，将操作结果发送给client端。

• 默认开启并监听4723端口。

• Appium通过HTTP协议进行Client与Server之间的通信。Client端发送请求到Appium Server的特定端口，并使用JSON格式的数据交换测试信息和执行结果。

• 在移动设备端，中间件（如bootstrap.jar或bootstrap.js）通过socket连接与Appium Server进行通信。中间件接收来自Appium Server的命令，并在移动设备上执行相应的操作，然后将执行结果反馈回Appium Server。

• WebDriver协议在Appium中起到了桥梁的作用，使得Client端能够与移动设备进行交互，实现自动化测试。

• Desired Capabilities：这是启动 Appium 会话的“配置清单”，是一个 JSON 对象，用于告诉 Appium Server 你希望如何启动和执行会话。例如：启动浏览器还是移动设备？启动Android还是iOS？启动Android时，app的包名是什么；app的activity是什么。

• session：session就是一个会话，在appium中，所有工作都是在session start后才可以进行。启动session需要传入Desired Capabilities获取一个全局唯一的session id，这个id指定了执行自动化测试的浏览器或者移动设备。

三、appium工作流程

工作流程的几个关键步骤：

1. 启动会话 (Session)：你的测试脚本（客户端）通过向 Appium Server 发送一个包含 Desired Capabilities（设备名、应用路径、自动化引擎等）的 HTTP 请求来启动一个会话。Appium 会根据这些配置初始化对应的自动化框架（如 UiAutomator2/XCUITest），并在设备上安装一个特殊的“服务器代理”（Android 上是 bootstrap.jar，iOS 上是 WebDriverAgent）。

2. 执行命令：

1. 自动化脚本（client）发送一个命令（如 find_element 查找元素）。

2. Appium Server 接收到这个标准的 WebDriver 命令。

3. Appium Server 通过之前建立的连接，将这个命令转发给设备上正在运行的“服务器代理”（Bootstrap/WebDriverAgent）。

4. 这个“服务器代理”负责调用平台原生的自动化框架（UiAutomator2/XCUITest）。

5. 原生框架最终在设备的 UI 层级中执行真正的操作（如查找、点击、滑动）。

3. 返回响应：操作执行后的结果（成功或失败信息）会沿着原路返回，最终以 HTTP 响应的形式送达你的测试脚本。

四、核心原理：“不重新编译”与“跨平台”

Appium 官方口号是 "Cross-platform, don't recompile your app"。它通过以下两个关键技术点实现了这一目标：

1. 不重新编译你的应用

• 传统自动化框架（如 Apple 的 UIAutomation）需要将自动化库编译到待测应用中。

• Appium 不需要对被测应用做任何修改或重新编译。它利用了各平台官方提供的底层自动化框架来驱动应用：

• 对于 9.3+ 版本：使用 XCUITest（目前主流）。XCUITest 是 Apple 提供的官方 UI 测试框架。

• 对于更老版本：使用 UIAutomation（已废弃）。

• 对于 4.2+ 版本：使用 UiAutomator2（目前主流）。UiAutomator2 是 Google 提供的官方测试框架，可以获取屏幕内容并执行操作。

• 对于更老版本：使用 Selendroid（基于 Instrumentation）。

• Android

• iOS

简单来说，Appium 就像一个“翻译官”和“中间商”。它接收标准的 WebDriver 命令，然后“调用”设备上这些官方的自动化框架来执行实际的操作。因为使用的是官方框架，所以不需要修改应用本身。

2. 跨平台

• 由于 Appium 在服务器层为 iOS 和 Android 提供了不同的“翻译”实现（即不同的“驱动”，如 XCUITestDriver 和 UiAutomator2Driver），但对客户端暴露的是同一套 WebDriver API。这意味着可以用同一套编程语言、几乎相同的代码结构来为 iOS 和 Android 编写自动化测试，大大提高了代码的复用性。

五、总结

Appium 的原理可以精炼为：

1. 协议标准化：采用并扩展 WebDriver 协议，使客户端编写标准化。

2. 架构清晰：采用 C/S 架构，职责分离，客户端只需关注业务逻辑，服务器负责翻译和执行。

3. 借力官方：不造轮子，直接调用各平台官方的底层自动化框架（UiAutomator2/XCUITest）来驱动设备，因此无需修改被测应用。

4. 跨平台统一：通过在服务器端为不同平台提供不同的“驱动”实现，对上层提供统一的 API，从而实现真正的跨平台自动化。

六、附录

1.在Android设备的详细工作过程：

1. Appium server将监听到的4723端口的指令，转发给中间件Bootstrap.jar，Bootstrap.jar是用Java编写的，安装在Android手机上；

2. Bootstrap监听4724端口并接收Appium server的指令；

3. Bootstrap再通过调用UIautomator的命令来实现具体的command操作。

4. 最后Bootstrap将执行的结果返回给Appium server。