你可以在执行的时候增加录屏，还可以在元素定位失败的时候增加截图，这样好排查问题。
appium 里面的 start_recording_screen 和 stop_recording_screen ；每次执行用例前录屏，用例结束后结束录屏，再将录屏文件插入到 allure 里面

@pytest.fixture
def driver(cmdopt, devices):
global base_driver
global env
# 执行 runner 脚本，多条用例执行时，无需每条用例都初始化 driver,如果 driver 存在则直接使用，并且初始化录屏
if base_driver and not devices:
base_driver.start_recording_screen()
yield base_driver
time.sleep(1)
record_base64 = base_driver.stop_recording_screen()
save_record_file(record_base64, base_driver)

def save_record_file(base64_data, driver):
# 将 mp4 录屏文件存储在 static 目录，已当前时间命名
file_path, file, zip_file, file_name, output_name = get_mp4_file_info(driver)
# base64 转视频文件
logger.info("======保存录屏文件=======")
base64_to_mp4(base64_data, file)
# 压缩视频文件
ZipPictureOrVideo(file_path, file_name, output_name).compress_video()
# 视频文件添加至测试报告
logger.info("======添加视频至 allure 报告=======")
with open(zip_file, mode='rb') as f:
file = f.read()
allure.attach(file, "录屏文件", allure.attachment_type.MP4)

xpath 是自动解析的吗？我一般 xpath 都使用相对定位，自动解析 xpath 的时候也是用相对定位的方式，想保证稳定性，一些元素还是需要手动定位，通过一些不变的元素，找到相对的 xpath，才能提高稳定性。

简单的说就是，获取到 appium 的页面树，之后通过你手动定位元素过程中的总结的规律，写成通用的函数，去自动解析元素树，最后生成元素代码。跟 app 有强相关不通用。有一些局限性，主要能解决一些简单元素的封装，能节省点时间，完全自动有些苦难

再用例里面做断言

封装的断言函数里面增加 is_restart 字段，默认重启

重启使用 appium 自带的函数重启 app

重启之后,需要对 app 状态做一些判断，比如是否处于登录页面，一些权限弹窗，等

是的

appium 自带功能

allure 插件

官方哪里有说吗？可以帮忙找一下，介绍这块的地方吗？

是的，主要最开始直接在 beanshell 中实现了加密功能，最后没想到，因为 beanshell 中加密时长，随着并发的加大，逐渐增加，导致增大并发数，接口的 tps 也无法增加，影响了业务性能测试，后来改成 jar 包方式，发现性能提升许多，而且 beanshell 执行时间稳定，只是好奇中间有什么区别。

没打包之前打印的是 sign 内部的耗时，打包之后打印的是 sign 整个方法的耗时，没有在 sign 的 jar 包里面加日志