PDF《介绍 0》

5 Android onStartCommand方法,返回START_STICKY 手动返回START_STICKY,亲测当service因内存不足被kill,当内存又有的时候,service 又被重新创建,比较不错,但是不能保证任何情况下都被重建,比如进程被干掉了 StartCommond几个常量参数简介:

1、START_STICKY 在运行onStartCommand后service进程被kill后,那将保留在开始状态,但是不保留那些传入的intent.不久后 service就会再次尝试重新创建,因为保留在开始状态,在创建 service后将保证调用 onstartCommand.如果没有传递任何开始命令给service,那将获取到null的intent.

2、 START_NOT_STICKY 在运行onStartCommand后service进程被kill后,并且没有新的 intent传递给它.Service将移出开始状态,并且直到新的明显的方法(startService)调 用才重新创建.因为如果没有传递任何未决定的intent那么service是不会启动,也就是期 间onstartCommand不会接收到任何null的intent.

3、START_REDELIVER_INTENT 在 运行onStartCommand后service进程被kill后,系统将会再次启动service,并传入最后一 个intent给onstartCommand.直到调用stopSelf(int)才停止传递intent.如果在被kill后还 有未处理好的intent,那被kill后服务还是会自动启动.因此onstartCommand不会接收到 任何null的intent. 【结论】: 手动返回START_STICKY,亲测当service因内存不足被kill,当内存又有 的时候,service又被重新创建,比较不错,但是不能保证任何情况下都被重建,比 如进程被干掉了.... 提升service优先级 在AndroidManifest.xml文件中对于intent-filter可以通过android:priority =

1000 这个属性 设置最高优先级,1000是最高值,如果数字越小则优先级越低,同时适用于广播. 【结论】目前看来,priority这个属性貌似只适用于broadcast,对于Service来说可能无效 提升service进程优先级 Android中的进程是托管的,当系统进程空间紧张的时候,会依照优先级自动进行进程的 回收 当service运行在低内存的环境时,将会kill掉一些存在的进程.因此进程的优先级将会很 重要,可以在startForeground使用startForeground 将service放到前台状态.这样在低内 存时被kill的几率会低一些. 【结论】如果在极度极度低内存的压力下,该service还是会被kill掉,并且不一定会 restart onDestroy方法里重启service service +broadcast 方式,就是当service走ondestory的时候,发送一个自定义的广播, 当收到广播的时候,重新启动service 也可以直接在onDestroy()里startService 【结论】当使用类似口口管家等第三方应用或是在setting里-应用-强制停止时,APP进程 可能就直接被干掉了,onDestroy方法都进不来,所以还是无法保证 面试

6 Android Application加上Persistent属性 看Android的文档知道,当进程长期不活动,或系统需要资源时,会自动清理门户,杀死 一些Service,和不可见的Activity等所在的进程.但是如果某个进程不想被杀死(如数据 缓存进程,或状态监控进程,或远程服务进程),可以这么做 【结论】据说这个属性不能乱设置,不过设置后,的确发现优先级提高不少,或许 是相当于系统级的进程,但是还是无法保证存活 监听系统广播判断Service状态 通过系统的一些广播,比如:手机重启、界面唤醒、应用状态改变等等监听并捕获到, 然后判断我们的Service是否还存活,别忘记加权限 【结论】这也能算是一种措施,不过感觉监听多了会导致Service很混乱,带来诸多不便 root之后放到system/app变成系统级应用 大招: 放一个像素在前台(手机QQ) Activity生命周期 启动Activity: onCreate()―>