记一次TP触摸延迟原因排查
记一次TP触摸延迟原因排查
去年的一个项目中,我负责TP的驱动调试.有一天客户反馈TP触摸有延迟.我打开触摸轨迹测了测,可以看出来轨迹总是比实际手指触摸慢半拍.我第一反应是供应商提供的参数的问题,于是把问题反馈给供应商,然而供应商AE推说延迟是我们的系统造成的.打了几个回合的太极后,老大跟我说还是先查查咱们系统吧.
系统可能给触摸带来哪些延迟呢?大概要考虑这么几个时间:
从TP中断到报点给用户层的时间 + input子系统从接收到报点到把报点dispatch给framework的时间 + UI绘制的时间
UI绘制我不太懂,只能先查前面两个时间.把对应时间戳log出来,发现前面两个时间加起来大概是几十ms,看起来不大,但是对视觉效果有没有影响呢?难说.至于UI绘制时间带来的视觉感受就更玄乎了.我意识到这个排查是个无底洞,这样下去会纠缠不清的.
就在我一边划线一边盯着手机屏幕上的触摸轨迹的时候,我突然发现一个不那么明显的现象,这个轨迹并不是单纯的"延迟感",而是"阻尼感"!
什么是"阻尼感"?阻尼是信号与系统里的一个概念,具体理论概念我就不讲了,请参考百度百科.我们用实例来理解:
a.想象一个在真空中作简谐运动的弹簧振子
b.想象一个在装满泥浆的箱子里运动的弹簧振子
两种情形中,b就是阻尼比较大的感觉.
回到TP上,阻尼感和延迟感的区别是什么?想象手指快速地划过屏幕:如果只是单纯的"延迟",那么屏幕上的轨迹运动会和手指一样快,只是时间上慢了半拍;而如果屏幕上的轨迹是慢慢划过的,跟不上手指的速度,则是有"阻尼"在里面.
如果问题是在于我们的系统,那也只会带来一个相对稳定接近常数的延迟,因为系统使用的触摸坐标,就是TP固件报上来的坐标,原封不动,没有任何滤波处理;而非常数的"延迟",也就是阻尼,则更可能是TP固件对原始坐标的滤波算法造成的.
我把情况反馈给AE,结果人家还是不认,说是看不出来,而且UI绘制带来的延迟也无法排除.
但我还是想到了办法.
调试Android平台input设备时有个很好用的命令:getevent.用在TP上时能把报点坐标打印出来,加个-t参数,还能把时间戳打印出来.所以理论上我们完全可以用这条命令的输出信息作出坐标相对于时间的变化曲线,实际上写一个简单的Python脚本就可以实现这一点(脚本内容就不方便贴出来了,毕竟是工作时间内的产出.其实很简单,只有20来行,重要的是思路).我用脚本作出了两台手机测试的对比图:
测试方法是拿对比机和我司手机并排着,两只手指同时以同样的速度在两个手机屏幕上快速划过,然后突然停顿.左边是对比机的测试结果,右边是我司手机的测试结果.明显可以看出来两台手机对"停顿"这个动作的响应速度是完全不一样的.
这个测试除了画出曲线,直观明了,更重要的一点是排除了UI绘制带来延迟的因素,因为getevent的结果跟UI完全没有关系.
最后,我把测试结果给AE看,这次他没话说了,开始认真地查参数的问题了.
其实排查这个问题的整个过程并没有用到什么TP的专业知识,或是什么高深的思路和工具.只是使用了一些常识+简单的工具组合(getevent+Python的绘图库)就排查出了当初看起来纠缠不清的问题,还是小有成就感的.这个经历对我今后排查问题的启示:
- 把思路理清
- 善用工具.简单工具的组合有时刚好能解决你当前的困境