我们常用的onStartCommand返回值有START_STICKY、START_NOT_STICKY、START_REDELIVER_INTENT等等。...如果在onStartCommand(Intent, int, int)返回恒为START_STICKY。...此模式对于明确启动和停止运行任意时间段（例如执行背景音乐播放的服务）的事物有意义。...getApplicationInfo().targetSdkVersion < Build.VERSION_CODES.ECLAIR时默认为START_STICKY_COMPATIBILITY START_NOT_STICKY...； 如果希望Service执行完指定的任务后销毁，那么return START_NOT_STICKY； 如果没有什么要求那么直接return super.onStartCommand；
1、 onStartCommand 函数返回值分析 2、 onStartCommand 函数 START_STICKY_COMPATIBILITY 返回值 3、 onStartCommand 函数 START_STICKY...返回值 4、 onStartCommand 函数 START_NOT_STICKY 返回值 5、 onStartCommand 函数 START_REDELIVER_INTENT 返回值 二、 系统...START_STICKY_COMPATIBILITY : START_STICKY; } /** * @hide */ @UnsupportedAppUsage...= 1; 4、 onStartCommand 函数 START_NOT_STICKY 返回值 Service.START_NOT_STICKY : " 非粘性 " , onStartCommand 方法返回该返回值时...service will not be restarted until the * alarm goes off. */ public static final int START_NOT_STICKY
START_NOT_STICKY Constant to return from onStartCommand(Intent, int, int): if this service's process...简单说就是：进程被杀后，START_NOT_STICKY 不会重新唤起Service，除非重新调用startService，才会调用onStartCommand，而START_REDELIVER_INTENT...AMS存储所有杀死后需要重发的Intent 而START_NOT_STICKY跟START_STICKY都不需要AMS存储Intent，如下图： ?...--这里主要是给START_STICKY恢复用的，在START_STICKY触发onStartCommand的时候其intent为null，pendingStarts size为1-->...START_STICKY ?
一、onStartCommand有4种返回值： START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。...START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。...START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。...二、创建不被杀死的service 1.在service中重写下面的方法，这个方法有三个返回值， START_STICKY（或START_STICKY_COMPATIBILITY）是service被kill...startId); } 或 @Override public int onStartCommand(Intent intent, int flags, int startId) { flags = START_STICKY
如何免死 3.1 onStartCommand方法中，返回START_STICKY 在StartCommand()几个常量： START_STICKY 系统重新创建服务并且调用onStartCommand...START_NOT_STICKY 系统不重新创建服务，除非有将要传递来的intent。这是最安全的选项，可以避免在不必要的时候运行服务。...@Override public intonStartCommand(Intent intent, int flags, int startId) { flags = START_STICKY...; return super.onStartCommand(intent, flags,startId); } 手动返回START_STICKY，亲测当service因内存不足被kill，当内存又有的时候
2、Service和Thread 看下官网对Service的介绍：服务是可以在后台执行长时间运行的操作的应用程序组件，并且不提供用户界面。...6、onStartCommand()返回值的含义 START_STICKY=1:如果 service 进程被 kill 掉,保留 service 的状态为开始状态,但不保留递送的 intent 对象。...START_NOT_STICKY=2:“非粘性的”。使用这个返回值时,如果在执行完 onStartCommand 后,服务被异常 kill 掉,系统不会自动重启该服务。...START_STICKY_COMPATIBILITY=0: START_STICKY 的兼容版本,但不保证服务被 kill 后一定能重启。...设置为前台广播，也是最有效的，之前灰色保活方案使用过 设置优先级，清单文件中intent-filter可以通过android:priority = “1000”设置优先级 onStartCommand方法，返回START_STICKY
startId ：开启服务时，如果有规定id，则传入startid * @return 返回值规定此startservice是哪种类型，粘性的还是非粘性的 * START_STICKY...:粘性的，遇到异常停止后重新启动，并且intent=null * START_NOT_STICKY:非粘性，遇到异常停止不会重启 * START_REDELIVER_INTENT...isStop=true; } break; } return START_NOT_STICKY
方法： 1、START_STICKY 2、START_NOT_STICKY or START_REDELIVER_INTENT 这里主要解释这三个变量的意义： 1、 START_STICKY...2、 START_NOT_STICKY 在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。...如果返回START_NOT_STICKY，表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service，当然如果在其被杀掉之后一段时间又调用了startService，那么该...如果我们某个Service执行的工作被中断几次无关紧要或者对Android内存紧张的情况下需要被杀掉且不会立即重新创建这种行为也可接受，那么我们便可将 onStartCommand的返回值设置为START_NOT_STICKY...第一次执行bindService时，onCreate和onBind方法会被调用，但是多次执行bindService时，onCreate和onBind方法并不会被多次调用，即并不会多次创建服务和绑定服务。
该函数返回值为整型，一般取值START_STICKY，具体说明如下： 1、START_STICKY：粘性的服务。如果服务进程被杀掉，保留服务的状态为开始状态，但不保留传送的Intent对象。...2、START_NOT_STICKY：非粘性的服务。使用这个返回值时，如果服务被异常杀掉，系统不会自动重启该服务。 3、START_REDELIVER_INTENT：重传Intent的服务。...4、START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被杀掉后一定能重启。...2、绑定服务时，只调用onBind方法或者onRebind方法，不调用onStart和onStartCommand方法。...IntentService是Service的子类，它通过Looper和Thread来解决Service中处理逻辑的阻塞问题。
可以通过contect.startservice和contect.bindserverice来启动。 Service和其他的应用组件一样，运行在进程的主线程中。...START_STICKY 用于显示启动和停止service。 2. START_NOT_STICKY或START_REDELIVER_INTENT用于有命令需要处理时才运行的模式。...return START_STICKY; } @Override public void onDestroy() { // Cancel the persistent...介绍onStartCommand()需要用到的几个常量 (引自官方文档) START_NOT_STICKY If the system kills the service after onStartCommand...START_STICKY If the system kills the service after onStartCommand() returns, recreate the service and
，由于内容较多，这部分会分上中下三篇博客来仔细分析讲解，第一篇上篇要讲解的是sharedUserId和Messenger的使用方式。...START_FLAG_RETRY表示服务之前被设为START_STICKY，则会被传入这个标记。 ...onStartCommand (Intent intent, int flags, int startId)函数返回值有四个 START_STICKY、 START_NOT_STICKY、 START_REDELIVER_INTENT...、 START_STICKY_COMPATIBILITY START_STICKY如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。...START_NOT_STICKY“非粘性的”，使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务 START_REDELIVER_INTENT重传
我们要执行操作可在onStartCommand方法中定义，onStartCommand有4种返回值： START_STICKY：如果service进程被kill掉，保留service的状态为开始状态...START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。...START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。...（例如一个Service需要连接服务器的操作），一般使用bindService来绑定到一个现有的Service（即通过StartService启动的服务），Activity 与 Service传递数据和调用接口...在后台的工作的Service通过Context.startService()启动某个特定音乐播放，但在播放过程中如果用户需要暂停音乐播放，则需要通过Context.bindService()获取服务链接和Service
Android Service是一种重要的组件，可用于在后台执行各种任务和提供特定功能。了解和正确使用服务能够有效管理资源、增强用户体验，并构建更强大的Android应用程序。...三 Service常见属性及方法 属性： startMode（启动模式）：指定服务的启动模式，包括START_STICKY、START_NOT_STICKY、START_REDELIVER_INTENT...和START_FOREGROUND。...null) { // 处理传递的数据 } } // 返回值用于定义服务的启动行为 return START_STICKY...你可以根据实际需求在Service中添加相应的逻辑和功能。
参考回答： onStartCommand方式中，返回START_STICKY或则START_REDELIVER_INTENT START_STICKY：如果返回START_STICKY，表示Service...运行的进程被Android系统强制杀掉之后，Android系统会将该Service依然设置为started状态（即运行状态），但是不再保存onStartCommand方法传入的intent对象 START_NOT_STICKY...：如果返回START_NOT_STICKY，表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service START_REDELIVER_INTENT：如果返回START_REDELIVER_INTENT...，其返回情况与START_STICKY类似，但不同的是系统会保留最后一次传入onStartCommand方法中的Intent再次保留下来并再次传入到重新创建后的Service的onStartCommand...发挥什么作用 参考回答： ActivityManagerService是Android中最核心的服务 ， 主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作，其职责与操作系统中的进程管理和调度模块类似
1.onStartCommand方式中，返回START_STICKY或则START_REDELIVER_INTENT START_STICKY：如果返回START_STICKY，表示Service运行的进程被...Android系统强制杀掉之后，Android系统会将该Service依然设置为started状态（即运行状态），但是不再保存onStartCommand方法传入的intent对象 START_NOT_STICKY...：如果返回START_NOT_STICKY，表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service START_REDELIVER_INTENT：如果返回START_REDELIVER_INTENT...，其返回情况与START_STICKY类似，但不同的是系统会保留最后一次传入onStartCommand方法中的Intent再次保留下来并再次传入到重新创建后的Service的onStartCommand...ContentProvider作为四大组件之一，其主要负责存储和共享数据。
system会调用service的onCreate方法（如果需要的话）和onStartCommand方法，其中onStartCommand方法中的参数由客户端提供。...也就是说Android2.0以前service的运行模式是START_STICKY_COMPATIBILITY，Android2.0以后service的运行模式为START_STICKY。...START_STICKY（1）：如果service在开启后（调用了onStartCommand方法）被杀死，则会保留service的开启状态，但不会保存开启service的intent意图。...START_NOT_STICKY（2）：Service开始运行后如果被kill之后，service就不会处于started的状态，并且intent也不会被记录。...一个Service可以同时保持开启和绑定连接两种形式。
请注意： onCreate() 只在创建时调用一次，一旦服务启动后，就不会再调用了 onStartCommand() 必须返回整型数，它用于表示在服务停止时系统如何处理，有以下三个值： START_NOT_STICKY...: 服务终止时不会重建，比较安全 START_STICKY : 服务终止时重建并调用 onStartCommand() ，但传递的 intent 为空，适用于不需要参数的服务 START_REDELIVER_INTENT...: 和START_STICKY 类似，但会将之前接收到的 intent 传递给重建服务的 onStartCommand() 方法，适用于必须立即恢复的紧急任务 onBind() 返回一个 IBinder...在完成任务后我们需要主动停止服务，停止服务有三个方法： stopService() Context 的方法，外部组件调用，调用后系统会尽快销毁服务 stopSelf() Service 的方法，效果和...stopService() 一样 stopSelf(int) Service 的方法，它的特别之处在于参数和启动时的 id 一致才会被终止 也就是说如果在终止前又收到新的调用，就不会停止 前台服务
Q：onStart()和onResume()/onPause()和onStop()的区别？ 是否位于前台，对用户是否可见的区别 Q：Activity A启动另一个Activity B会回调哪些方法？...Q：Activity和Fragment的异同？...Q：Service如何和Activity进行通信？...onStartCommand方法中，返回START_STICKY 在StartCommand()几个常量： START_STICKY 系统重新创建服务并且调用onStartCommand()方法，但并不会传递最后一次传递的...START_NOT_STICKY 系统不重新创建服务，除非有将要传递来的intent。这是最安全的选项，可以避免在不必要的时候运行服务。
bindService() 生命周期为：onCreate() -> onBind() -> onUnBind() -> onDestory() 其中要注意的是onStartCommand方法的返回值，有三种常量： 1） START_NOT_STICKY...2） START_STICKY，终止服务后，会自动重新服务并调用 onStartCommand()，但不会重新传递最后一个 Intent。...但是，也正是因为后台无感知的特性，也带来了隐私方面的隐患和弊端。 App可以在后台操作用户数据，下载应用无关的文件等等。...后台和前台Service 这就涉及到Service的分类了。 如果从是否无感知来分类，Service可以分为前台和后台。前台Service会通过通知的方式让用户感知到，后台有这么一个玩意在运行。...Google也是考虑到了这一点，所以将5.0之后的JobScheduler和5.0之前的GcmNetworkManager、GcmNetworkManager、AlarmManager等和任务相关的API
前言 Android进程和Service的保活，是困扰Android开发人员的一大顽疾。...因涉及到省电和内存管理策略，各厂商基于自家的理解，在自已ROOM发布时都会对标准Android发行版作或多或少的改动，使得应用层程序在处理进程和Service保活问题上变的异常复杂，且很难兼容，因为说不定哪款手机或者哪个版本的省电策略发生改变...，那么随之而来的就是进程和Service保活的差异。...而就这一看似不起眼的问题，实际处理起来，因为众多Android手机和Android系统版本的差异，让问题的处理充满了不确定性。...其它三台机子（9100没测）：默认参数的情况下就会重启服务，return START_STICKY 会重启，return START_NOT_STICKY 不会重启。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
