1、Service 的start 和bind状态有什么区别?
a> 启动:start方法调用多次,只有第一次会调用onCreate,之后都只调用onStartCommand、onStart,
bind 只有第一次调用会启动onCreate、onBind
b> 解绑:start 启动后调用stopService解绑,可以调用多次,bind启动后调用unbindService解绑,
只能调用一次,多次调用会报java.lang.IllegalArgumentException: Service not registered。
c> 生命周期:start启动的Service,在启动它的组件销毁后服务依然存在。bind启动的服务,在依赖的
组件销毁后服务也会销毁,但是要注意及时解绑,否则会leak
2、同一个Service,先startService再bindService,如何把它停掉?
只要同时调用stopService和unbindService 即可,两者顺序可以互换。
3、Service onStartCommond方法的不同的返回值有什么区别?
public @StartResult int onStartCommand(Intent intent, @StartArgFlags int flags, int startId) {
onStart(intent, startId);
return mStartCompatibility ? START_STICKY_COMPATIBILITY : START_STICKY;
}
默认的两个,可选的有4个:START_STICKY、START_NOT_STICKY、START_REDELIVER_INTENT、START_STICKY_COMPATIBILITY。
使用START_STICKY作为返回值,程序被异常kill后(服务被重启了,但intent对象被清除了),使用START_STICKY作为返回
值,适用于不执行命令的媒体播放器(或类似的服务),它只是无限期的运行着并等待工作的到来.
使用START_NOT_STICKY作为返回值,程序被异常kill后(服务没有被重建) ,这是最安全的选项
使用START_REDELIVER_INTENT作为返回值,程序被异常kill后(服务被重启了,并保留了intent对象) ,并且在该服务
调用stopSelf方法之前,能够一直保留intent对象数据。这适用于那些应该立即恢复正在执行的工作的服务,如下载文件。
使用START_STICKY_COMPATIBILITY作为返回值,START_STICKY的兼容版本,但不保证服务被终止后一定能重启。程序被
异常kill后(服务虽然被重建,但没有重启)
更详细的内容可以参考官方文档或者这篇博客 http://blog.csdn.net/u012975705/article/details/49944313
4、Service 的生命周期方法onCreate onStart onBind运行在哪个线程?
打印了线程identifier发现运行在主线程,因此在此执行耗时操作也可能引起ANR(Activity 中耗时操作超过5s,
Broadcast Receiver 中超过10s,Service中超过15s),但是IntentService中却很安全,别人的答案上说内部使用
HandlerThread,自己看源码后发现源码很短,在onCreate中创建HandlerThread,然后获取Looper,然后将Looper传递给
ServiceHandler,然后就开始处理消息,处理完之后调用stopSelf
官方文档也说的很清楚。
* IntentService will receive the Intents, launch a worker thread, and stop the service as
* appropriate.
*
* <p>All requests are handled on a single worker thread -- they may take as
* long as necessary (and will not block the application's main loop), but
* only one request will be processed at a time.
5、Service和Thread有什么关系?
Service一般运行在后台(也有前台Service)让人觉得和Thread一样处理耗时任务一样,其实Service运行在主线程中,使用不当也会造成ANR,
所有Service和Thread并没有什么关系。Service可以不依赖UI运行在后台,即时Activity被销毁,程序被关闭,只要进程还在,
Service就能运行,在Service里可以创建子线程或者通过IntentService处理耗时任务。 在服务中创建子线程比Activity中有
什么好处呢?因为其他Activity也能和Service关联,能够获取到Service中的Binder实例,自由的进行控制,即使一个Activity
finish后其他的Activity也能控制,而不像Thread,创建它的Activity销毁后就无法对其进行控制了。
a> 启动:start方法调用多次,只有第一次会调用onCreate,之后都只调用onStartCommand、onStart,
bind 只有第一次调用会启动onCreate、onBind
b> 解绑:start 启动后调用stopService解绑,可以调用多次,bind启动后调用unbindService解绑,
只能调用一次,多次调用会报java.lang.IllegalArgumentException: Service not registered。
c> 生命周期:start启动的Service,在启动它的组件销毁后服务依然存在。bind启动的服务,在依赖的
组件销毁后服务也会销毁,但是要注意及时解绑,否则会leak
2、同一个Service,先startService再bindService,如何把它停掉?
只要同时调用stopService和unbindService 即可,两者顺序可以互换。
3、Service onStartCommond方法的不同的返回值有什么区别?
public @StartResult int onStartCommand(Intent intent, @StartArgFlags int flags, int startId) {
onStart(intent, startId);
return mStartCompatibility ? START_STICKY_COMPATIBILITY : START_STICKY;
}
默认的两个,可选的有4个:START_STICKY、START_NOT_STICKY、START_REDELIVER_INTENT、START_STICKY_COMPATIBILITY。
使用START_STICKY作为返回值,程序被异常kill后(服务被重启了,但intent对象被清除了),使用START_STICKY作为返回
值,适用于不执行命令的媒体播放器(或类似的服务),它只是无限期的运行着并等待工作的到来.
使用START_NOT_STICKY作为返回值,程序被异常kill后(服务没有被重建) ,这是最安全的选项
使用START_REDELIVER_INTENT作为返回值,程序被异常kill后(服务被重启了,并保留了intent对象) ,并且在该服务
调用stopSelf方法之前,能够一直保留intent对象数据。这适用于那些应该立即恢复正在执行的工作的服务,如下载文件。
使用START_STICKY_COMPATIBILITY作为返回值,START_STICKY的兼容版本,但不保证服务被终止后一定能重启。程序被
异常kill后(服务虽然被重建,但没有重启)
更详细的内容可以参考官方文档或者这篇博客 http://blog.csdn.net/u012975705/article/details/49944313
4、Service 的生命周期方法onCreate onStart onBind运行在哪个线程?
打印了线程identifier发现运行在主线程,因此在此执行耗时操作也可能引起ANR(Activity 中耗时操作超过5s,
Broadcast Receiver 中超过10s,Service中超过15s),但是IntentService中却很安全,别人的答案上说内部使用
HandlerThread,自己看源码后发现源码很短,在onCreate中创建HandlerThread,然后获取Looper,然后将Looper传递给
ServiceHandler,然后就开始处理消息,处理完之后调用stopSelf
官方文档也说的很清楚。
* IntentService will receive the Intents, launch a worker thread, and stop the service as
* appropriate.
*
* <p>All requests are handled on a single worker thread -- they may take as
* long as necessary (and will not block the application's main loop), but
* only one request will be processed at a time.
5、Service和Thread有什么关系?
Service一般运行在后台(也有前台Service)让人觉得和Thread一样处理耗时任务一样,其实Service运行在主线程中,使用不当也会造成ANR,
所有Service和Thread并没有什么关系。Service可以不依赖UI运行在后台,即时Activity被销毁,程序被关闭,只要进程还在,
Service就能运行,在Service里可以创建子线程或者通过IntentService处理耗时任务。 在服务中创建子线程比Activity中有
什么好处呢?因为其他Activity也能和Service关联,能够获取到Service中的Binder实例,自由的进行控制,即使一个Activity
finish后其他的Activity也能控制,而不像Thread,创建它的Activity销毁后就无法对其进行控制了。