問(wèn)題

在某個(gè)版本后，當(dāng)點(diǎn)擊底部tababr切換頁(yè)面的時(shí)候，從點(diǎn)擊到切換成功會(huì)有一定的時(shí)間延遲，這個(gè)時(shí)間不是很長(zhǎng)，但是，就是可以明確的感覺到一個(gè)卡頓。

• Time Profiler

首先想到的就是使用instruments里面的Time Profiler。分別在simulator和真機(jī)上測(cè)試，獲取到tababr切換期間的CPU使用時(shí)間，發(fā)現(xiàn)一切正常，沒有特別耗時(shí)的操作。

• 排查tabbar的問(wèn)題

應(yīng)用使用的不是系統(tǒng)自帶的tababr，所以懷疑是tabbar的問(wèn)題。那么，替換自定義的tabbar 為原生，發(fā)現(xiàn)問(wèn)題還是存在。

• 排查viewController的問(wèn)題

tabbar有五個(gè)viewController，想到可能是某個(gè)viewController里面做了什么操作，導(dǎo)致切換的時(shí)候卡頓。直接把第一個(gè)viewController替換掉，然后運(yùn)行，發(fā)現(xiàn)卡頓消失。那就證明是這個(gè)viewController導(dǎo)致的問(wèn)題，然后找到所屬模塊，定位具體問(wèn)題。

• 排查具體修改

因?yàn)槊看未虬?，我們都?huì)保存那個(gè)版本對(duì)應(yīng)的podfile.lock 文件。所以，排查方法就是找到版本的lock文件，然后在里面找到對(duì)應(yīng)的模塊的commiid，通過(guò)回溯代碼到對(duì)應(yīng)的commitid，然后找問(wèn)題。

• 結(jié)果

排查結(jié)果就是，有代碼在tabbar上面加了一個(gè)雙擊手勢(shì)。所以當(dāng)點(diǎn)擊事件發(fā)生的時(shí)候，由于有雙擊手勢(shì)的存在，所以系統(tǒng)會(huì)延遲一定時(shí)間，然后才會(huì)調(diào)用單擊事件。