开发中避免延时操作技巧详解
作者:流浪汉kylin 时间:2022-03-09 17:51:39
前言
开发中我们或多或少会涉及到一些场景需要使用延时操作,而延时操作其实并不是一个很好的选择,并不是一个很好的方案,因为它不可控,也可能产生时序的逻辑问题。这次就来盘点一些使用延时操作的场景和如何去避免,本次内容比较基础。
使用延时的场景
在刚接触开发的时候,我们无脑解决问题的方案基本只有两种,异常捕获和延时。异常捕获容易理解,当碰到崩溃又分析不出原因时,往往加个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是否被销毁,被消耗了就不执行后面的操作。
这里也只是列举其中一个场景,其实在使用延时的时候往往会很危险,所以使用需谨慎,能不用就不用,如果一定要用,也需要考虑周全。
来源:https://juejin.cn/post/7204767643676868645