开发中我们或多或少会涉及到一些场景需要使用延时操作，而延时操作其实并不是一个很好的选择，并不是一个很好的方案，因为它不可控，也可能产生时序的逻辑问题。这次就来盘点一些使用延时操作的场景和如何去避免，本次内容比较基础。

使用延时的场景

在刚接触开发的时候，我们无脑解决问题的方案基本只有两种，异常捕获和延时。异常捕获容易理解，当碰到崩溃又分析不出原因时，往往加个try-catch就能绕过，但往往这样做只会导致出现更难排查的BUG，当慢慢有经验的时候，也不会再这么做了，毕竟crash提示出来的BUG也都比较好解决。

其实延时操作也是这样，找不到问题出在哪里，然后胡乱尝试，发现在某个地方加个延时几秒就能让流程正常。其实这个和乱加异常捕获一样，往往会引发更难排查的问题，所以有问题就平下心解决问题，不要试图使用这种方式。这也是延时操作最不应该出现的方式。

获取view的宽高

刚开始接触的时候，往往不会正确的获取view的宽高，直接就view.getHeight()然后发现获取到的高度是0，然后不知道为什么，开始瞎尝试，最终尝试出加个延时1秒就能获取到高度。

但是这并不能解决办法，这时正确的做法应该是去了解view的绘制流程，去探究为什么一开始获取不到值，去看源码（当然一开始自己瞎看源码有点难），去看看这个东西是怎样的一个机制，然后结合这些甚至结合别人的分析，再去看源码，就很容易能看得。

就能知道为什么应该用view.post

定时查询服务器结果

假如你有一个应用，你怎么知道你何时被人抢登，你何时能收到别人的消息，等等。往往很多人的做法是写一个定时器，每隔多长时间去向服务器发送http请求查询一下状态，那么这样的做法没问题吗？

如果你把细节都处理好，这样的做法当然没问题，但有没有了解过有一个协议叫websocket，你总有见过有些链接不是http开头，而是ws开头的吧。有没有了解过一个协议叫MQTT，没了解过也没关系，可以看看我这篇基础的文章：https://www.jb51.net/article/276761.htm，甚至上升到智能硬件层面，有没有了解过什么是IOT。

当然不是说轮询请求有问题，只是需要处理一些细节，中断什么的，甚至如果有更好的方法能实现你想要的效果，那为何不用更好的呢？

但是如果你是要定时执行某些本地的任务，那用定时器倒是没有什么问题，关键要处理好一些细节，生命周期、中断操作、暂停操作等等。

广播顺序

复杂的多应用情况下，往往或多或少会使用到广播，那其实广播的注册和广播的发送，就是有个顺序问题。有可能你的某些逻辑导致广播先发送，另外一边再注册，那就会出现接收不到广播的情况。有些人为了简单处理这个问题，往往会加个延时，让广播延时发送。

那这其实是个很危险的操作，正确的做法是，应该去对广播这个东西有一定的了解。你就会知道有种广播类型叫粘性广播，哪怕你熟悉了这个领域的知识，还是不了解它或者说它对你来说在这个场景不适用，那你也会有更好的办法去解决这个问题，而不是通过延时这种不安全的操作。

延时初始化

我们都知道在Application或者在onCreate中做过多的初始化操作是不好的，大家都知道优化，优化启动速度，所以不会在这些地方做初始化。那有些人就会想出一些骚办法，我在这些地方加个延时，延时个一两秒再做初始化，这样又能优化启动速度，又能在对应的功能使用前进行初始化，岂不美哉？你觉得呢

你的延时的原理是什么，handler机制，那有没有了解有个东西叫IdleHandler。

其实单独用IdleHandler也不是一个安全的操作，那为什么不放在第一次使用的时候再给功能做初始化呢？有的人可能会说，如果初始化是耗时操作，那在第一次使用的时候再进行初始化，就会影响使用的体验。对于这个问题，我一般情况是一起使用，又在IdleHandler进行初始化，也在第一次使用的时候判断没有初始化的话再进行初始化。特殊的情况可以在某些地方进行，这个要看具体的需求。

使用延时的场景

那既然延时是一个这么危险的操作，并且一般都有更好的方式去替代，那我们是不是就打死都不使用延时操作。并不是，有时候不用还真不行，那是什么时候需要使用？当然是没办法通过其它方法去处理这个问题的时候。用，但是要小心用。

比如我调用别人的一个库，那个库里做了操作，然后给我回调，这是一个基本的流程嘛。但是，这个库不是你的，可能他写了BUG或者什么原因，导致你调用他的方法，但他不给你回调。那这种情况下如果你不做什么操作，你就会一直卡在这。

所以针对这种情况，一般会做个超时机制去让这个流程更安全一些，比如说你20秒不给我回调，我就返回失败。当然我觉得首先应该和库的作者去沟通这个问题，实在没办法了，才用这种下下策。

但是如果这么做了，那要注意状态，比如说你已经超时了，要是他这时候再给你回调怎么办？所以用这种方法，还需要写很多东西去保证它的安全。

还有一种情况是Loading，这个可能我从以前开始就这样操作比较多，Loading的时候我不会马上显示菊花转，会延时0.5秒再显示，这样能有比较好的体验。

当然还有你想先写个延时，然后过几个版本你和你老板说，我要做个优化，然后你把延时给去掉，看到没有，速度明显快了，如果你想这样玩，那就当我没说。

还有，你这种延时也是有讲究的，比如我做重绘更新页面后页面显示后才做某些操作，那我怎么做，系统有方法实现，如果你说我就要做延时（我这里为了举个例子），那你就要知道屏幕刷新是16ms，但如果没画完，会放到下次刷新，为了安全，你可以设置高一些，你可以设80ms的延时，但没必要设到一两秒。

小心使用延时

为什么说要尽量避免使用延时操作，因为这个操作确实坑多，在Android中大部分的延时操作都会用postDelayed去实现。

首先你要考虑一个问题，中断问题，需要有个中断机制，比如你在Activity做了延时操作，但是Activity销毁了，这时候你延时时间到了难道还要继续执行操作？所以会在Activity的onDestroy里面去移除Handler的消息。

假设你加了中断操作，但是只这样做安全吗？有没有考虑过你中断的时候其实消息已经开始处理了。所以这时候还需要用一个状态去做判断，根据这个状态判断Activity是否被销毁，被消耗了就不执行后面的操作。

这里也只是列举其中一个场景，其实在使用延时的时候往往会很危险，所以使用需谨慎，能不用就不用，如果一定要用，也需要考虑周全。