Step4. 如果UI线程没有发生阻塞，则sleep过后，tickCounter一定与原来的值不相等，否则一定是UI线程发生阻塞； 假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞，sleep过后 tickCounter值还是相等的，但是已经明显发生卡顿。也就是很大概率发生多次临近阈值5s的卡顿 或者超过，这个时候并不能明显显示出来。
Activity
D-clock commentedon Jun 13, 2017
@pruas 确实有这样的问题，感谢指出，得优化一下。
Gru110110110 commentedon Jun 21, 2017
我也写了个监测，使用传统两种方式。https://github.com/pruas/Caton 可以交流交流~
LQG24 commentedon Jul 30, 2017
Step4. 如果UI线程没有发生阻塞，则sleep过后，tickCounter一定与原来的值不相等，否则一定是UI线程发生阻塞；
假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞，sleep过后 tickCounter值还是相等的，但是已经明显发生卡顿。也就是很大概率发生多次临近阈值5s的卡顿 或者超过，这个时候并不能明显显示出来。
1楼说的，假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞。会发生这样的情况吗?不是转到子线程了吗，怎么还会导致UI线程阻塞呢。
不过确实会临近阈值5s的卡顿 或者超过
HCLXIDIAN commentedon Feb 21, 2019
sleep后tickCounter都加一了为什么还是相等的呢？？