思路是点击页面记录时间，然后找寻某个元素再记录时间，减去两者差
结果实际运行中，同一个页面我肉眼看几乎都是秒开，但是结果却偶尔是零点零几秒，偶尔是五六秒。
有什么解决方案吗？
或者说 find_element 不适合性能测试呢？
#点击书架页面
driver.find_element_by_id("com.unicom.zworeader.ui:id/btn_book_shelf").click()
# 记录开始时间
starttime = datetime.datetime.now().strftime('%Y%m%d%H%M%S%f')
print(datetime.datetime.now().strftime('%Y%m%d%H%M%S%f'))
#反复找寻书架右上角加号
while True:
try:
plus = driver.find_element_by_id("com.unicom.zworeader.ui:id/home_title_bar_more_iv")
endtime = datetime.datetime.now().strftime('%Y%m%d%H%M%S%f')
print(datetime.datetime.now().strftime('%Y%m%d%H%M%S%f'))
time.sleep(5)
print('---get book_shelf successful!---')
if plus is not None:
break
except:
print('---get book_shelf failure。---')
opentime= float(endtime) - float(starttime)
print(format(float(opentime) / float(1000000), '.2f'))
录制屏幕，借用图像识别来实现
不讨论方法是否正确的问题，如果只讨论你这个方法的问题，有以下两个建议：
- While 循环中的 sleep 去掉，时间会更准确一些，不至于相差太大。 # 但是结果却偶尔是零点零几秒，偶尔是五六秒 ------------第一次打开了，所以第一个 while 循环的时候，就找到控件了，就 break 了，如果第一个循环没有 break,则需要等 5 秒后再去找，这就是两个时间为什么相差这么大的原因。
- WebDriverWait 可以了解一下，可以不用 while 循环了，不过 POLL_FREQUENCY 这个变量可能需要重新设置一下（默认是 0.5s）,和当前方法中的 sleep 一个意义。
希望能对你有所帮助。
我是觉得用这类 ui 框架计算性能有些越俎代庖，它本身的设计注定了它不可能得到一个非常精确的结果。比较好且方便的方法是进行日志埋点之后进行抓取；或者结合图像识别与高速相机。
appium 有不少数据交互，元素查找时间，和实际加载时间感觉差距还是很大的。做页面打开速度，还是需要开发埋点比较方便。
Android 用 adb logcat -b events -s am_activity_launch_time 或 adb logcat | findstr "Displayed" 日志方式也可以看到 activity 加载时间，但是无法判断数据异步加载时间。