这段时间在跑iOS UI 自动化的时候，发现一个问题，在执行50次之后页面元素查找速度变得很慢，3分钟都找不到。
业务场景是这样的，在进入实时视频页面后，测试代码开始处理业务日志，从沙盒目录中捞取app日志中的不同节点，并把对应的时间记录在excel中，处理完成后，app上需要点击左上角的返回按钮，回到首页。就是这个返回按钮，在执行50次左右后元素查找开始变得很慢，经常3分钟超时失败。
这里使用的元素定位方法是iOS最推荐的ACCESSIBILITY_ID
python
el = driver.find_element(by=AppiumBy.ACCESSIBILITY_ID, value=PLAY_BACK_ICON)当时的情况是：停留在实时视频页面后，会收到若干条push通知，push通知在页面顶端的停留时间不会太长，几秒钟后会自动消失，并不会长时间遮挡左上角的返回按钮，所以并没有把它当作主要原因考虑，没有在意，开始想别的解决方法，
1、写了屏幕右滑手势退出当前页面的方法，调试后可以使用，能够解决这个问题；
2、后来又试了一下，把设备单独绑在一个账号下，排除push通知干扰，其他不变，又尝试了一遍；
没想到第二个方法管用了，repeat=300次，每次都找到了返回按钮，现在逆向推导一下原因，虽然push通知没有长时间遮挡返回按钮，但貌似是涉及到了 UI层级 动态更新什么的问题，这块有所了解，但不多，我查了一些资料：
【什么是 UI 层级树？】
在 iOS 应用中，UI 层级树（UI hierarchy）是系统用来描述当前屏幕上所有 UI 元素的结构。每当页面加载、元素更新或动态内容出现（如 Push 通知）时，层级树会发生变化。Appium 通过调用 iOS 的 Accessibility API 来获取和解析这个层级树，从而找到目标元素。
【Push 通知如何干扰 UI 层级树？】
Push 通知出现时的影响：
当 Push 通知出现，系统会在层级树顶部新增一个节点表示通知内容。
iOS 系统需要重新生成层级树，Appium 也会重新解析这棵树。
如果通知内容复杂（如图片、动态文字），层级树会变得更大、更复杂，解析耗时增加。
Push 通知消失时的影响：
通知消失时，系统会再次更新层级树，删除相关节点。
Appium 再次需要重新获取和解析当前页面的层级树。
频繁的层级树重建
如果 Push 通知频繁出现和消失，层级树将不断被更新，导致 Appium 查找元素时每次都需要重新加载最新的层级结构。
【为什么 Push 通知干扰返回按钮的定位？】
动态内容优先级
iOS Accessibility API 默认优先处理动态内容（如 Push 通知）。当通知出现时，Appium 的元素查找可能被动态内容"打断"，需要等通知更新完成后才能继续解析。
层级树深度变化
如果 Push 通知插入到层级树的顶部或中间，可能导致原本浅层的返回按钮被推到更深层次。
Appium 查找元素的效率会随着层级树深度的增加而显著下降。
重复解析消耗时间
每次通知出现或消失，层级树都会被重建，Appium 每次都需要重新获取完整的层级结构，即使返回按钮的位置没有改变。
【总结】
这个问题的解决并不是在最开始了解问题的原因，而是在尝试中找到了方法，并总结了原因。学习的过程就是不断尝试-总结的过程，跟大家一块儿学习分享。