如题，wda 跑抖音 ios 的自动化会卡死，触发滑动操作，抖音 app 就卡死动不了了，有人遇到这种情况吗
参考以前圣翔写过的 wda 提速文章 WebDriverAgent tap 接口速度优化（分析篇）， wda 上耗时比较长甚至引起卡死的操作，一般是获取控件树，所以你可以减少获取控件树的频率或深度。
个人亲测在远程真机控制场景，控件树深度设置为 0，可以非常有效提升各种触控事件的响应速度，从默认深度 50 时的 2-3 秒甚至卡死，变为 1 秒内。
而且由于底层 XCUITest 获取控件树是带有推断逻辑的（个人猜测是为了应对各种 scroll view 场景下的元素查找），所以 scroll view 或者 table view 内置的元素数量比较多，也容易卡死。业务上遇到过一个登录页滚动背景，开发为了保障无限滚动，实现方式是 table view 中每个 cell 就是一个自动滚动长图，然后弄了 9999 个 cell 保障基本不可能滚动到末尾，导致 wda 获取时直接卡死。后面尝试调整为 99 个 cell ，获取速度立马提升到秒级。但这个从 ios 开发角度，table view 的 cell 是自带复用机制的，实际行数不管多少，实际渲染用的 cell 对象数量只会界面可见的最大行数 +1 这么多，所以按开发的认知，是不会觉得性能会出问题的（实际上只要不用 XCUITest dump 控件树，性能压根不会有任何问题）。
考虑到楼主不大可能让开发改源码适配，那以我个人认知，只能让 wda 控件树深度减少或者尽量不获取控件树来解决了。
建议提供现场信息，机型、系统、app 版本、wda 日志
老实说，你唯品会去跑抖音 APP 是什么目的？
那是因为抖音页面层级多，动效多
应该是树结构太大，wda 一直有这个问题的。我们公司的产品有些界面，wda 也经常卡死。
参考以前圣翔写过的 wda 提速文章 WebDriverAgent tap 接口速度优化（分析篇）， wda 上耗时比较长甚至引起卡死的操作，一般是获取控件树，所以你可以减少获取控件树的频率或深度。
个人亲测在远程真机控制场景，控件树深度设置为 0，可以非常有效提升各种触控事件的响应速度，从默认深度 50 时的 2-3 秒甚至卡死，变为 1 秒内。
而且由于底层 XCUITest 获取控件树是带有推断逻辑的（个人猜测是为了应对各种 scroll view 场景下的元素查找），所以 scroll view 或者 table view 内置的元素数量比较多，也容易卡死。业务上遇到过一个登录页滚动背景，开发为了保障无限滚动，实现方式是 table view 中每个 cell 就是一个自动滚动长图，然后弄了 9999 个 cell 保障基本不可能滚动到末尾，导致 wda 获取时直接卡死。后面尝试调整为 99 个 cell ，获取速度立马提升到秒级。但这个从 ios 开发角度，table view 的 cell 是自带复用机制的，实际行数不管多少，实际渲染用的 cell 对象数量只会界面可见的最大行数 +1 这么多，所以按开发的认知，是不会觉得性能会出问题的（实际上只要不用 XCUITest dump 控件树，性能压根不会有任何问题）。
考虑到楼主不大可能让开发改源码适配，那以我个人认知，只能让 wda 控件树深度减少或者尽量不获取控件树来解决了。
如果有精力, 可以尝试仿照 WDA 的项目结构重写 YourWDA, 抛弃很多对你们被测项目来说用不到的情况. 预计运行结果会快的飞起. 对自己也是个很大的锻炼.
appium 有个自带的控制 source tree 的深度，叫 snapshotMaxDepth，可以用这个试试
