Service原理这里不介绍,只介绍onStartCommand的返回和Android Reference中的问题。
onStartCommand方法必须具有一个整形的返回值,这个整形的返回值是一个描述性质的数值,用来告诉系统在服务启动完毕后,一旦遇到服务被系统销毁(System kill),系统将如何继续(操作),这些返回值必须是以下一个:
START_NOT_STICKY
如果系统在onStartCommand返回后被销毁,系统将不会重新创建服务,除非收到一个未处理(pending悬而未决地)的Intent,当不是必须(necessary)并且Android应用能够自行简单地(simply)重启未完成业务(不通过服务),那么这样的设定是最安全的(safest)。
如果系统在onStartCommand返回后被销毁,系统将会重新创建服务并依次调用onCreate和onStartCommand(注意:根据测试Android2.3.3以 下版本只会调用onCreate根本不会调用onStartCommand,Android4.0可以办到),重新创建的操作将会作为事件日程序列 (schedule)加入到系统事件日程列表中,在延迟一个计算时间(如:5000ms)后重新启动。但是不会重新将之前的传入的Intent创新传递 给、
onStartCommand,除非重新收到一个未处理(pending悬 而未决地)的Intent,在这种情况下(inwhich case),未处理的心得Intent仍然按照流程被传入和处理,但是前一次操作的Intent将会变null(等同于一次带null intent的启动)。对于不需要立刻执行命令的服务,如多媒体播放器(或者其他类似(similar)的服务)那么这样的设定是非常适合的,但是服务会 无限期的运行,并等待一个适合的工作(个人理解:就是服务等于又重新启动恢复到之前的状态了)。
同START_STICKY,在重新调用onStartCommand的时候,之前的Intent将会被保留,并重新传递给该方法,除非此时出现了一次新的启动服务请求,那么Intent将会被替换成新的,否则仍然使用旧的Intent。经过测试Android2.3.3对于该操作同样有效。
注意:以上行为只有在System kill event的情况下有效,stopSelf和stopService都不会过问onStartCommand的返回状态。
名词解释:
System kill:系统杀死服务,以释放内存,在低内存的情况下系统会自行操作,System kill之后的操作有onStartCommand的返回值决定,注意,正常结束服务是不会发生重启的,因为服务结束并不代表服务实例被释放,一个服务实例可以被多次启动,但是这并不表示产生了多个服务实例,从DDMS可以看到他们和hosting process使用同一个PID,服务实例是绑定在hosting process 主线程消息队列的(Message Queue)。
相关推荐
android Service中onStartCommand返回值.txt 有四种返回值,分别代表的含义
“对Service中onStartCommand方法返回值的探索”一文源码 博客地址:http://blog.csdn.net/u012975705/article/details/49932783
Android 关于启动方式的service生命周期的onCreate()和onStartCommand()方法,说法正确的是( D ) A、当第一次启动的时候只会调用onCreate()方法 B、当第一次启动的时候只会调用onStartCommand() 方法 C、如果...
1、在WorkService的onStartCommand中执行要保活的操作业务。 2、在初始化过程中调用KeepAliveManager.INSTANCE.startKeepAliveService(context); 3、停止服务调用KeepAliveManager.INSTANCE.stopKeepAliveSerice...
不久后service就会再次尝试重新创建,因为保留在开始状态,在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service,那将获取到null的intent。 START_NOT_STICKY 在运行onStartCom
1、onCreate: 执行startService方法时,如果Service没有运行的时候会创建该Service并执行Service的onCreate回调方法;如果Service已经处于运行中,那么执行startService方法不会执行Service的onCreate方法。也就是说...
Android开发的过程中,每次调用startService(Intent)的时候,都会调用该Service对象的onStartCommand(Intent,int,int)方法,然后在onStartCommand方法中做一些处理。 从Android官方文档中,我们知道onStartCommand有...
public class ServiceDemo extends Service { private static final String TAG = "ServiceDemo"; public static final String ACTION = "com.example.servicedemoactivity.ServiceDemo"; @Override public ...
Android实现双进程守护,如何保证Service不被Kill,onStartCommand方法,返回START_STICKY,手动返回START_STICKY,亲测当service因内存不足被kill,当内存又有的时候,service又被重新创建,比较不错,但是不能保证...
每一次调用 startService 都会回调onStartCommand,之后调用了stopService之后就会 destroy Service。即使有多个client启动服务,那调用一次stopService 就能 destroy Service 。通过这种方式还有一个好处就是...
你可以从一个activity或从其它应用的组件通过传递一个Intent(指定了要启动的服务)给startService()启动一个服务.Android系统然后调用service的onStartCommand()方法并且把Intent传递给它.(你永远不能直接调用...
多次调用startService()方法并不会导致多次创建服务,但会导致多次调用onStartCommand()方法
Android中的IntentService是继承自Service类的,在我们讨论IntentService之前,我们先想一下Service的特点: Service的回调方法(onCreate、onStartCommand、onBind、onDestroy)都是运行在主线程中的。当我们通过start...
与Activity不同,它 是不能与用户交互的,不能自己启动的,需要调用Context.startService()来启动,运 行后台,如果我们退出应用时,Service进程并没有结束,它仍然在后台行。Service有 两种启动方式,对应的,有两...
Started Service就是启动之后可以在后台无限期的运行,比如通过...在File->new->Service->Service中新建一个Service,并重写里面的方法,一般来说要实现onCreate()、onBind()、onStartCommand()和onDestroy()这四
【Android 进程保活】应用进程拉活 ( 系统 Service 机制拉活 | Service 组件 onStartCommand 方法分析 | 源码资源 ) https://hanshuliang.blog.csdn.net/article/details/115548051 博客源码快照
不会被轻易终止即使service被终止,当系统资源恢复的时候,也将自动恢复运行状态,(onStartCommand 返回 START_STICKY)用于进程之间通信,解决两个安卓应用程序之间调用的关系启动方式通过 Context.startService...
应用组件(例如Activity)调用startService()来启动一个Service,将需要的参数通过Intent传给Service,Service将会在onStartCommand函数中获得Intent。 有两种方式可以创建started service,一种是扩展Service类,...
安卓的service的创建和调用其实和activity基本上一个样,很简单,只是继承Service类,在里面写一个onStartCommand方法,然后在该方法下写自己的代码就可以了。
1. 通过 AlarmManager 来设置定制任务 2. 用广播去启动Service 3. Service中onStartCommand()方法执行任务