不是很可靠

[Gru110110110]

Step4. 如果UI线程没有发生阻塞，则sleep过后，tickCounter一定与原来的值不相等，否则一定是UI线程发生阻塞；
假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞，sleep过后 tickCounter值还是相等的，但是已经明显发生卡顿。也就是很大概率发生多次临近阈值5s的卡顿 或者超过，这个时候并不能明显显示出来。

[D-clock]

@pruas 确实有这样的问题，感谢指出，得优化一下。

[Gru110110110]

我也写了个监测，使用传统两种方式。https://github.com/pruas/Caton 可以交流交流~

[LQG24]

Step4. 如果UI线程没有发生阻塞，则sleep过后，tickCounter一定与原来的值不相等，否则一定是UI线程发生阻塞；
假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞，sleep过后 tickCounter值还是相等的，但是已经明显发生卡顿。也就是很大概率发生多次临近阈值5s的卡顿 或者超过，这个时候并不能明显显示出来。

1楼说的，假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞。会发生这样的情况吗?不是转到子线程了吗，怎么还会导致UI线程阻塞呢。
不过确实会临近阈值5s的卡顿 或者超过

[HCLXIDIAN]

Step4. 如果UI线程没有发生阻塞，则sleep过后，tickCounter一定与原来的值不相等，否则一定是UI线程发生阻塞；
假设先执行tickCounter累加后（一行累加代码，时间可忽略不计），马上转到某个耗时子线程，导致UI线程阻塞，sleep过后 tickCounter值还是相等的，但是已经明显发生卡顿。也就是很大概率发生多次临近阈值5s的卡顿 或者超过，这个时候并不能明显显示出来。

sleep后tickCounter都加一了为什么还是相等的呢？？