隔壁老wang 发表于 2017-3-4 12:26
高亮执行速度慢很好理解吧，本来就是放慢了执行的速度，让你能够清楚看到数据流。然后等待这个函数有个特性：比如你设置了等待的时间为1s，当程序执行一次不到1s的时，就等待足够1s后执行下一次；当程序执行时间超过1s时，需要等程序执行完成，也就相当于等待的时间实际上超过了1s，这时你设置的1s不就相当于无效了。这是 ...

我懂了，是这个意思吧：高亮执行的话，程序执行的太慢了，超过了等待时间了，所以这样设置就无效了。

隔壁老wang 发表于 2017-3-4 12:26
高亮执行速度慢很好理解吧，本来就是放慢了执行的速度，让你能够清楚看到数据流。然后等待这个函数有个特性：比如你设置了等待的时间为1s，当程序执行一次不到1s的时，就等待足够1s后执行下一次；当程序执行时间超过1s时，需要等程序执行完成，也就相当于等待的时间实际上超过了1s，这时你设置的1s不就相当于无效了。这是 ...

还有个疑问
就是这个程序中有两个WHILE循环，不太理解的就是在实际运行中:
假设我们的延迟时间都是10ms，这两个循环在运行中是并行运行，还是说等待一个运行完，然后另外一个再运行？（两个循环中程序运行的时间都不超过10ms,即没有超时）.

wangyi31 发表于 2017-3-5 08:16
我懂了，是这个意思吧：高亮执行的话，程序执行的太慢了，超过了等待时间了，所以这样设置就无效了。

楼主如果有满意的答案 请选一个最佳答案哦

本帖最后由 羊驼啊 于 2017-3-6 10:44 编辑

没仔细看回复，简单提一句。

高亮的时候，程序执行顺序与正常情况应该是一致的，但是每两步之间的间隔时间很长，而实际的计时函数，计算的时长却是不变的。在高亮的两个步骤之间，无论是延时10ms，还是延时100ms，都已经执行完毕，因此没有差别。
不知道说错了没有，应该没错吧。。
再废话一句，高亮执行过程与实际过程有可能不是完全一致的，特别是对于有延时的程序，高亮过程与实际过程可能差别很大。

比如你计算一个2s的延时，一旦超出两秒则报警。正常过程中，绝对没有2s，因此不会报警。但是在高亮过程中，假设其他条件与正常执行完全一致，但是由于高亮运行速度慢，极有可能就超过了2s然后报警，因为“读取时间”函数读取的时间依然是实际时间，这时程序就报警了。这与实际并不相符，高亮调试时一定要清楚这一点。

据我所观察的高亮模式执行情况，似乎是程序预先执行了程序，然后将结果暂时保存，然后通过绘图的形式将执行的过程重现一遍，所以并不涉及延时不同步的问题，因为播放动画的速率是相同的，所以你看到的结果是相同的，高亮执行程序无法有效的体现出楼主举例的并行循环的时序，高亮的意义也仅仅是通过动画来提示你你的数据流动的逻辑是否与预期的相同而已。