前言
开发中我们或多或少会涉及到一些场景需要使用延时操作，而延时操作其实并不是一个很好的选择，并不是一个很好的方案，因为它不可控，也可能产生时序的逻辑问题。这次就来盘点一些使用延时操作的场景和如何去避免，本次内容比较基础。
使用延时的场景
在刚接触开发的时候，我们无脑解决问题的方案基本只有两种，异常捕获和延时。异常捕获容易理解，当碰到崩溃又分析不出原因时，往往加个try-catch就能绕过，但往往这样做只会导致出现更难排查的BUG，当慢慢有经验的时候，也不会再这么做了，毕竟crash提示出来的BUG也都比较好解决。
其实延时操作也是这样，找不到问题出在哪里，然后胡乱尝试，发现在某个地方加个延时几秒就能让流程正常。其实这个和乱加异常捕获一样，往往会引发更难排查的问题，所以有问题就平下心解决问题，不要试图使用这种方式。这也是延时操作最不应该出现的方式。
获取view的宽高
刚开始接触的时候，往往不会正确的获取view的宽高，直接就view.getHeight()然后发现获取到的高度是0，然后不知道为什么，开始瞎尝试，最终尝试出加个延时1秒就能获取到高度。
但是这并不能解决办法，这时正确的做法应该是去了解view的绘制流程，去探究为什么一开始获取不到值，去看源码（当然一开始自己瞎看源码有点难），去看看这个东西是怎样的一个机制，然后结合这些甚至结合别人的分析，再去看源码，就很容易能看得。
就能知道为什么应该用view.post
定时查询服务器结果
假如你有一个应用，你怎么知道你何时被人抢登，你何时能收到别人的消息，等等。往往很多人的做法是写一个定时器，每隔多长时间去向服务器发送http请求查询一下状态，那么这样的做法没问题吗？
如果你把细节都处理好，这样的做法当然没问题，但有没有了解过有一个协议叫websocket，你总有见过有些链接不是http开头，而是ws开头的吧。有没有了解过一个协议叫MQTT，没了解过也没关系，可以看看我这篇基础的文章：https://www.atool.online/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是否被销毁，被消耗了就不执行后面的操作。
这里也只是列举其中一个场景，其实在使用延时的时候往往会很危险，所以使用需谨慎，能不用就不用，如果一定要用，也需要考虑周全。
以上就是开发中避免延时操作技巧详解的详细内容，更多关于避免延时操作技巧的资料请关注阿兔在线工具其它相关文章！
