公司搭建的 STF 稳定运行了很久，使用率也一直还可以， 但是整体的闲置的时间还是过长。
因为一般使用云手机的也就上去验证兼容性，用个 10 几分钟就差不多了，导致如果拉设备的繁忙空闲表数据会非常难看。所以从去年开始想着通过自动化把设备利用率再提升起来。

移动组的同学一开始试着用 appium 来做自动化，在正式落地的时候发现了很多问题。

1. appium 多设备同时运行需要开很多线程，我们就算使用 docker 化管理 appium，线程和端口问题也需要很多额外的代码。
2. STF 对 provider 的压力本身就很大，而 appium 本身也是非常费性能的程序，更别说多开多个 appium。
3. appium 自身的稳定性也存在问题，动不动就自杀或者重启 adb，让 STF 都变的不稳定。

还有很多细节的问题我这边都不列举了（太多了 不堪回首），STF+appium 的方式最终还是被我们放弃了。
所以我们另辟蹊径决定用 uiautomator2 来开展移动自动化。
uiautomator2 对比 appium 有以下几个优势：

uiautomator2 运行在手机端，不会 PC 造成很大压力，不影响 STF 的稳定

是的，就这一个优点！但是对我们团队来说，在保证 STF 的稳定性的前提下 开展自动化进程，这一点尤为重要

基于这个原则，我们团队使用了 uiautomator2 开发了一个基于命令行驱动的模块
https://github.com/ZhonganTechQA/za-Farmer
这个模块简单点说就是 可以使用 adb shell 来驱动 uiautomator2 来进行自动化测试，并且会自动截图和处理权限弹框。

$ adb shell am instrument -w  -e class 'com.smart.farmer.ExampleInstrumentedTest#step'  \
 -e step-action click \
 -e step-elementText 设置  \
 com.smart.farmer.test/android.support.test.runner.AndroidJUnitRunner

所以你可以在 STF 平台直接使用它。

当然这只是简单的🌰，真正要落地的话肯定需要搭配案例管理和执行管理模块。但是对比 appium 庞大的体系和性能消耗，这个小巧的模块给我们的移动自动化工作变的简单了很多。
这个模块目前我们已经开源出来，希望可以抛砖引玉，帮助大家更好的开展移动自动化。
https://github.com/ZhonganTechQA/za-Farmer

------------------手工分割线------------------
回答一下回复里的问题。

• uiautomator2 不能搞 ios

以 stf 目前的架构，把 stf 的 ios provider 单独部署出来 然后使用你想用的各种框架（appium 或 xctest）来做执行层都是可以的，前提是不影响 stf 的稳定性。我们这边是使用 xctest 来实现并统一 android 和 ios 的实现，达到案例复用（然而并没有那么简单，ios 和 android 的对象属性都是有差异的实际落地有很多困难）。

• uiautomator2 不支持 webview

我先不说 uiautomator2 可以使用 instrumented 进行单元测试来支持 webview。从 android 5.0 开始 uiautomator 对 webview 的元素探测机制已经支持的相当大了，能识别大部分的元素的情况下根本不需要上 webdriver。 而即使使用 webdriver 也不需要 appium 的支持，自己实现 webdriver 直接调度 webview 和你直接调度 appium 并没有差别。