Mobile自动化加速方案

先说下结论。目前这个方案第一版提速6%到15%左右，并在环境上做了简化。不再需要安装appium以及对应的环境，不用启动appium，不再需要频繁构建webdriveragent到设备上，不再需要appium inspector。试过多个脚本多次运行，稳定提升效率，运行时间缩短。在运行调试时直接插上设备就可以运行，跟跑web自动化和桌面软件自动化保持一致。(代码较多，这里不放上来了)

1. 之前的情况

原有的自动化脚本是基于appium的，不管框架怎么封装，都会回到appium server这里来对设备进行操作。

appium虽然全面，可以做企业级的统一方案，但却是公认的慢。业内有其他的工具，比如mastro，号称是比appium快几倍，但不在公司允许的安装软件范围内，不能尝试。

同时要修改原有的复数脚本是不现实的，没人想配合着做这个事。

因此在考虑提速的时候，除了要稳定，要快，还要能兼容老脚本。

2. 思路方法

首先看看appium为何慢，主要是因为appium到设备的链路比较长。这里用google ai生成了示例图。

到了最后的设备那里，还是uiautomator2和webdriveragent来实行的操作。

对于一些非技术类型的QA人员来说，appium确实是做了一个统一，并可以通过一条语句实现到android或ios上的操作，按照appium的规范来写就行。

对于有一定技术背景的QA人员来说，其实appium server和appium driver就没有多少必要了。可以直接从脚本直接发送信息到uiautomator和webdriveragent并管理对应的接口。同时有些行为可以不经过中间的server，android由adb命令以及ios由go-ios命令直接操作到真机。

然后整个链路变短，操作请求变得直接，也不加额外的条件和校验，只针对自用。于是时间就节省出来了。缺点就是需要自己编写一定量的代码，用于管理比如WDA的接口行为，以及维护adb及go-ios的命令行为，并且为了兼容appium的老脚本，需要额外增加方法，比如appium自己的指令'mobile:dragFromToForDuration'，相当于一个简略版的driver，封装常用的一些操作类型定义好方法名。不过效果还是明显的。

因为没有appium了，那么appium inspector也没了，准确的说是没有必要了。但是对于校验元素定位的需要还是能满足的，因为现在是自己在维护wda之类的接口，所以可以启动本机的简易单文件server，在浏览器中访问，一样的查看xml结构树或json结构树，一样的定位元素校验，而且可以自定制功能了，不必依赖和等待其他的inspector了。

3. 环境的变化

除了执行效率提升运行时间缩短，环境也变得简单了。

首先有nodejs的环境，这个用类似brew install node安装。

新方案则只需要装1个：

npm install -g go-ios
brew install ios-webkit-debug-proxy # 只有webview的时候才需要

而appium的环境则需要这些：

brew install libimobiledevice
brew install ideviceinstaller
brew install ios-webkit-debug-proxy  # 只有webview的时候才需要
brew install ios-deploy
brew install carthage

npm install -g appium
npm install -g appium-doctor
appium driver install uiautomator2
appium driver install xcuitest

对于ios设备还有个webdriveragent的工作简化。

对于使用appium的时候，需要对appium目录下的webdriveragent用xcode打开(这里还是得感谢appium官方对wda的维护更新)，然后更改一些配置信息，每次连上设备后，进行build。每换一个设备，就需要build一次，因为一般是使用个人开发者账户，则有效期只有7天，往往来说，需要经常性的build，而且手动无法运行设备上的wda，则还是需要用xcode build来运行wda，还是挺繁琐的。有时也忘记启动appium，直到看见报错后又来执行命令启动。

现在对于wda可以用公司的team来进行打包，这样有一年的有效期。做成一个ipa的安装文件，然后跑脚本的时候自动检查是否存在wda，若已安装，则通过go-ios命令启动，若没有就拉取wda的ipa文件，通过go-ios进行安装后再启动。这里会先用ios tunnel start启动隧道，然后用ios runwda来启动wda，最后用ios forward来转发端口信息。也就是说，不需要启动wda和appium，wda会自动安装上启动，wda本身会被纳入自动的管理。插上设备，直接运行就行，省了事，运行也加快了。当然android也是同理。

4. 为何appium官方不做变更

Appium 要用一套代码支持 iOS + Android + Web + Desktop + TV + ... 维护 20+ 个 driver 插件，Appium server 是这些协议差异的"抹平层”。

Appium产生了10多年了，架构定型后，大量用户依赖，难以重构。另外有数以万计的存量用户和脚本。

云端设备测试服务，需要 Appium server 这个"中心化的代理层"来统一管理云上设备连接和会话。

所以appium是有用的，应用面也很广的。但是，我们只是需要ios和android的一部分支持而已。