Android延迟实现的几种解决方法及原理分析
前言
在Android开发中我们可能会有延时执行某个操作的需求,例如我们启动应用的时候,一开始呈现的是一个引导页面,过了两三秒后,会自动跳转到主界面。这就是一个延时操作。
而写这篇文章的目的,是看到群里有人在实现延迟的时候,用如下的第四种方法,个人感觉有点不妥,为了防止更多的人有这种想法,所以自己抽空深入分析,就分析的结果,写下此文,希望对部分人有启示作用。
1.实现延迟的几种方法?
答:
1.java.util.Timer类的:
publicvoidschedule(TimerTasktask,longdelay){ if(delay<0) thrownewIllegalArgumentException("Negativedelay."); sched(task,System.currentTimeMillis()+delay,0); }
2.android.os.Handler类:
publicfinalbooleanpostDelayed(Runnabler,longdelayMillis) { returnsendMessageDelayed(getPostMessage(r),delayMillis); }
3.android.app.AlarmManager类:
@SystemApi @RequiresPermission(android.Manifest.permission.UPDATE_DEVICE_STATS) publicvoidset(@AlarmTypeinttype,longtriggerAtMillis,longwindowMillis, longintervalMillis,OnAlarmListenerlistener,HandlertargetHandler, WorkSourceworkSource){ setImpl(type,triggerAtMillis,windowMillis,intervalMillis,0,null,listener,null, targetHandler,workSource,null); }
4.Thread.sleep()然后在一定时间之后再执行想执行的代码:
newThread(newRunnable(){ Thead.sleep(4*1000); doTask(); }).start()
2.他们的各自的实现原理?
答:
1.Timer的实现,是通过内部开启一个TimerThread:
privatevoidmainLoop(){ while(true){ try{ TimerTasktask; booleantaskFired; synchronized(queue){ //Waitforqueuetobecomenon-empty while(queue.isEmpty()&&newTasksMayBeScheduled) queue.wait(); if(queue.isEmpty()) break;//Queueisemptyandwillforeverremain;die //Queuenonempty;lookatfirstevtanddotherightthing longcurrentTime,executionTime; task=queue.getMin(); synchronized(task.lock){ if(task.state==TimerTask.CANCELLED){ queue.removeMin(); continue;//Noactionrequired,pollqueueagain } currentTime=System.currentTimeMillis(); executionTime=task.nextExecutionTime; if(taskFired=(executionTime<=currentTime)){ if(task.period==0){//Non-repeating,remove queue.removeMin(); task.state=TimerTask.EXECUTED; }else{//Repeatingtask,reschedule queue.rescheduleMin( task.period<0?currentTime-task.period :executionTime+task.period); } } } if(!taskFired)//Taskhasn'tyetfired;wait queue.wait(executionTime-currentTime); } if(taskFired)//Taskfired;runit,holdingnolocks task.run(); }catch(InterruptedExceptione){ } } }
是通过wait和延迟时间到达的时候,调用notify来唤起线程继续执行,这样来实现延迟的话,我们可以回开启一个新的线程,貌似为了个延迟没必要这样吧,定时,频繁执行的任务,再考虑这个吧。
2.Handler的postDelay是通过设置Message的when为delay的时间,我们知道当我们的应用开启的时候,会同步开启Looper.loop()方法循环的,不停的通过MeassgeQueue的next方法:
Messagenext(){ ...... intnextPollTimeoutMillis=0; for(;;){ if(nextPollTimeoutMillis!=0){ Binder.flushPendingCommands(); } nativePollOnce(ptr,nextPollTimeoutMillis); synchronized(this){ //Trytoretrievethenextmessage.Returniffound. finallongnow=SystemClock.uptimeMillis(); MessageprevMsg=null; Messagemsg=mMessages; if(msg!=null&&msg.target==null){ //Stalledbyabarrier.Findthenextasynchronousmessageinthequeue. do{ prevMsg=msg; msg=msg.next; }while(msg!=null&&!msg.isAsynchronous()); } if(msg!=null){ if(now当我们向MessageQueue插入一条延迟的Message的时候,Looper在执行loop方法,底层会调用epoll_wait(mEpollFd,eventItems,EPOLL_MAX_EVENTS,timeoutMillis);其中的timeoutMillis参数指定了在没有事件发生的时候epoll_wait调用阻塞的毫秒数(milliseconds)。这样我们在之前的时间内这个时候阻塞了是会释放cpu的资源,等到延迟的时间到了时候,再监控到事件发生。在这里可能有人会有疑问,一直阻塞,那我接下来的消息应该怎么执行呢?
我们可以看到当我们插入消息的时候的方法:
booleanenqueueMessage(Messagemsg,longwhen){ if(msg.target==null){ thrownewIllegalArgumentException("Messagemusthaveatarget."); } if(msg.isInUse()){ thrownewIllegalStateException(msg+"Thismessageisalreadyinuse."); } synchronized(this){ if(mQuitting){ IllegalStateExceptione=newIllegalStateException( msg.target+"sendingmessagetoaHandleronadeadthread"); Log.w(TAG,e.getMessage(),e); msg.recycle(); returnfalse; } msg.markInUse(); msg.when=when; Messagep=mMessages; booleanneedWake; if(p==null||when==0||when阻塞了有两种方式唤醒,一种是超时了,一种是被主动唤醒了,在上面我们可以看到当有消息进入的时候,我们会唤醒继续执行,所以我们的即时消息在延迟消息之后插入是没有关系的。然后在延迟时间到了的时候,我们也会被唤醒,执行对应的消息send,以达到延迟时间执行某个任务的目的。
优势:这种延迟在阻塞的时候,是会释放cpu的锁,不会过多地占用cpu的资源。
3.AlarmManager的延迟的实现原理,是通过一个AlarmManager的set方法:
IAlarmManagermService.set(mPackageName,type,triggerAtMillis,windowMillis,intervalMillis,flags, operation,recipientWrapper,listenerTag,workSource,alarmClock);这里是通过aidl与AlarmManagerService的所在进程进行通信,具体的实现是在AlarmManagerService类里面:
privatefinalIBindermService=newIAlarmManager.Stub(){ @Override publicvoidset(StringcallingPackage, inttype,longtriggerAtTime,longwindowLength,longinterval,intflags, PendingIntentoperation,IAlarmListenerdirectReceiver,StringlistenerTag, WorkSourceworkSource,AlarmManager.AlarmClockInfoalarmClock){ finalintcallingUid=Binder.getCallingUid(); if(interval!=0){ if(directReceiver!=null){ thrownewIllegalArgumentException("RepeatingalarmscannotuseAlarmReceivers"); } } if(workSource!=null){ getContext().enforcePermission( android.Manifest.permission.UPDATE_DEVICE_STATS, Binder.getCallingPid(),callingUid,"AlarmManager.set"); } //NoincomingcallerscanrequesteitherWAKE_FROM_IDLEor //ALLOW_WHILE_IDLE_UNRESTRICTED--wewillapplythoselaterasappropriate. flags&=~(AlarmManager.FLAG_WAKE_FROM_IDLE |AlarmManager.FLAG_ALLOW_WHILE_IDLE_UNRESTRICTED); //OnlythesystemcanuseFLAG_IDLE_UNTIL--thisisusedtotellthealarm //managerwhentocomeoutofidlemode,whichisonlyforDeviceIdleController. if(callingUid!=Process.SYSTEM_UID){ flags&=~AlarmManager.FLAG_IDLE_UNTIL; } if(windowLength==AlarmManager.WINDOW_EXACT){ flags|=AlarmManager.FLAG_STANDALONE; } if(alarmClock!=null){ flags|=AlarmManager.FLAG_WAKE_FROM_IDLE|AlarmManager.FLAG_STANDALONE; }elseif(workSource==null&&(callingUid=0)){ flags|=AlarmManager.FLAG_ALLOW_WHILE_IDLE_UNRESTRICTED; flags&=~AlarmManager.FLAG_ALLOW_WHILE_IDLE; } setImpl(type,triggerAtTime,windowLength,interval,operation,directReceiver, listenerTag,flags,workSource,alarmClock,callingUid,callingPackage); } } } 虽然有人觉得用AlarmManager能够在应用关闭的情况下,定时器还能再唤起,经过自己的测试,当杀掉应用程序的进程,AlarmManager的receiver也是接收不到消息的,但是我相信在这里定时器肯定是发送了,但是作为接收方的应用程序进程被杀掉了,执行不了对应的代码。不过有人也觉得AlarmManager更耗电,是因为我们执行定时任务的情况会频繁唤起cpu,但是如果只是用来只是执行延迟任务的话,个人觉得和Handler.postDelayed()相比应该也不会耗电多的。
2.在上面的第四种方法,达到的延迟会一直通过Thread.sleep来达到延迟的话,会一直占用cpu的资源,这种方法不赞同使用。
3.总结
如上面我们看到的这样,如果是单纯的实现一个任务的延迟的话,我们可以用Handler.postDelayed()和AlarmManager.set()来实现,用(4)的方法Thread.sleep()的话,首先开启一个新的线程,然后会持有cpu的资源,用(1)的方法,Timer,会开启一个死循环的线程,这样在资源上面都有点浪费。
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对毛票票的支持。