記一次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的繪圖庫)就排查出了當初看起來糾纏不清的問題,還是小有成就感的.這個經歷對我今後排查問題的啓示:
- 把思路理清
- 善用工具.簡單工具的組合有時剛好能解決你當前的困境
