进程、服务守护防杀的实现,对于每一位开发者来说,都是一部与某系统、某卫士、某助手、某管家、某大师斗争的血泪史。
我们常用的进程守护的套路无外乎以下几种,大部分内容摘录自Never-say-Never的博客
套路一.提高进程的优先级数值
对于Service被系统回收,一般做法是通过提高优先级可以解决,在AndroidManifest.xml文件中对于intent-filter可以通过Android:priority = “1000”这个属性设置最高优先级,1000是最高值,如果数字越小则优先级越低。
套路二.改变进程等级
android中的进程是托管的,当系统进程空间紧张的时候,会依照优先级自动进行进程的回收。Android将进程分为6个等级,它们按优先级顺序由高到低依次是:
1.前台进程( FOREGROUND_APP)
2.可视进程(VISIBLE_APP )
3.次要服务进程(SECONDARY_SERVER )
4.后台进程 (HIDDEN_APP)
5.内容供应节点(CONTENT_PROVIDER)
6.空进程(EMPTY_APP)
我们可以用 setForeground(true) 来设置 Service 的优先级。
1.如果service正在调用onCreate,onStartCommand或者onDestory方法,那么用于当前service的进程则变为前台进程以避免被killed。
2.如果当前service已经被启动(start),拥有它的进程则比那些用户可见的进程优先级低一些,但是比那些不可见的进程更重要,这就意味着service一般不会被killed.
3.如果客户端已经连接到service
(bindService),那么拥有Service的进程则拥有最高的优先级,可以认为service是可见的。
4.如果service可以使用startForeground(int,
Notification)方法来将service设置为前台状态,那么系统就认为是对用户可见的,并不会在内存不足时killed。
5.如果有其他的应用组件作为Service,Activity等运行在相同的进程中,那么将会增加该进程的重要性。
套路三.设置 android:persistent属性为true
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
这个属性设置后,的确发现优先级提高不少,或许是相当于系统级的进程,但是还是无法保证存活
套路四.onDestory方法内调用广播,重启Service
当service执行了onDestory的时候,发送一个自定义的广播,当收到广播的时候,重新启动service
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
但是当使用类似于360卫士和腾讯管家等第三方应用或是在setting里-应用-强制停止时,APP进程可能就直接被干掉了,onDestroy方法都进不来,所以还是无法保证存活
套路五.监听系统广播判断Service状态
通过系统的一些广播,比如:手机重启、界面唤醒、应用状态改变等等监听并捕获到,然后判断我们的Service是否还存活,记得加权限
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
在BroadcastReceiver中:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
这个方法监听多了会导致Service很混乱,带来诸多麻烦
套路六.将APK安装到/system/app成为系统级应用
使用ROOT过的手机
1.把代码编写好后,打包导出apk,copy到手机SD卡根目录下。
2.手机连接eclipse,cmd: adb shell
3.切换root模式,输入:su (如果root过就不会有错误)
4.设置System为读写权限:mount –o remount rw /system (System默认为只读,无法写入,这一步很关键)
5.cd到sd卡跟目录下,确认是否有我们拷贝到sd卡根目录下的apk(一般都是 storage/sdcard0)
shell@android:/ # cd storage/sdcard0
6.最后,我们要把apk拷贝到 /System/app中