想了解什么是Android 进程、Android 进程的生命周期、Android 进程回收策略
可参照地址什么是Android 进程、Android 进程的生命周期、Android 进程回收策略_lmm0513的博客-CSDN博客_android进程是什么
一、app保活
在Android中是一种流氓行为,一方面无端浪费用户手机电量,另一方面给用户一种很困惑的感觉,影响用户体验还有可能导致整个Android系统流畅性变差,所以Google官方一种不推荐该功能,也一直在阻止这方面功能在Android系统上运行,作为一个Android开发人员,应该极力阻止这种无耻的行为!!!
以上内容原文:APP保活_qq_18350329的专栏-CSDN博客_app保活
二、Android 进程保活的两个方案:
-
运行中保活:提高进程优先级,降低被系统 kill 的概率
-
被 kill 后拉活:被系统 kill 后,将进程拉活(重启)
1.运行中保活
通过前面章节的论述,我们知道,假设 APP 进程能够一直被认为是前台进程,那么系统就有可能永远不会杀死该进程。当然,这是不可能的,当我们将 APP 退回到后台,改 APP 所属进程就不属于 前台进程了。但是上述假设也让我们有了灵感不是,只要我们尽可能的提高进程的优先级,不就可以最大概率的降低被系统 kill 的可能性了。
那么,提高进程优先级的方法有哪些呢?
(1)利用 Activity 提高权限
监听手机锁屏解锁事件,锁屏时启动一个1像素的 Activity ,解锁时将该 Activity 销毁。此方法能将进程在锁屏状态下提高到最高前台进程( oom_adj 为 0 )的级别。避免出现一些让用户困扰(体验不好)的情况,该 Activity 需设计成用户无感知。
此方案主要解决为了达到省电目的,一些第三方应用或者系统管理工具在检测到锁屏之后一段时间(一般是 5 分钟)内会杀死后台进程。
下面是实例代码:
1像素 Activity:
class KeepLiveActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
KeepLiveManager.keepLiveActivity = this
// 设置Activity在左上角
window.setGravity(Gravity.START)
// 设置window的像素为1
window.attributes.run {
x = 0
y = 0
width = 1
height = 1
}
}
}
注意,这里一定要设置启动模式为 singleInstance,使该 Activity 单独一个 Activity 回退栈,否则在锁屏且 APP 在后台运行时,启动该 Activity 后,会进程带入前台,解锁后显示该APP界面,体验不好
<activity
android:name=".KeepLiveActivity"
android:launchMode="singleInstance"/>
广播接收者:
class KeepLiveReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
Log.d("KeepLiveReceiver", "action = ${intent.action}")
when(intent.action) {
// 锁屏
Intent.ACTION_SCREEN_OFF -> {
KeepLiveManager.startKeepLiveActivity(context)
}
// 解锁
Intent.ACTION_USER_PRESENT -> {
KeepLiveManager.finishKeepLiveActivity()
}
}
}
}
管理单例:
object KeepLiveManager {
var keepLiveActivity: KeepLiveActivity? = null
fun startKeepLiveActivity(context: Context) {
val intent = Intent(context, KeepLiveActivity::class.java)
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK
context.startActivity(intent)
}
fun finishKeepLiveActivity() {
keepLiveActivity?.finish()
}
}
注:由于锁屏、解锁的动作频率极高,该类广播在清单文件中注册无效,需要启动服务来注册广播,此部分代码和本章主题关系不大,就不贴代码了。思路就是:启动 APP 时,启动一个注册服务,在服务的 onCreate() 方法中注册广播,在 onDestory() 方法中注销广播。
以下是使用该方案保活前和保活后查看 oom_adj 的对比截图:
保活前
保活后
可见,保活后在锁屏状态,将进程的 oom_adj 由原来的7提高到了 0 。
附:查看进程 oom_adj 的方法
在命令行中使用以下两个命令
adb shell ps | grep packageName
adb shell cat /proc/PID/oom_adj
如:
G:AndroidGithubKeepLive>adb shell
shell@armani:/ $ ps | grep com.cy.keeplive
u0_a3 5991 213 541548 29976 ffffffff 00000000 S com.cy.keeplive
shell@armani:/ $ cat /proc/5991/oom_adj
0
(2)利用 Notification 提升权限
通过 setForeground() 方法可以将后台 Service 设置为前台 Service,可以将服务进程优先级提升为与可见进程一致,这将有效提高进程的优先级,从而大大降低进程被kill的概率。
通过 setForeground() 将后台 Service 设置为前台 Service 时,必须在系统的通知栏发送一条通知,也就是说前台 Service 必须绑定一条可见的通知。
在通知栏发送一条通知,是用户可以感知到的,这可能会对用户造成一定的困扰。可以通过实现一个内部 Service,在外部和内部 Service 中同时发送具有相同 ID 的 Notifacation ,然后将内部 Service 结束。随着内部 Service 的结束,Notification 也会消失掉,但系统的优先级仍然提高了。
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
try {
Notification notification = new Notification();
if (Build.VERSION.SDK_INT < 18) {
startForeground(NOTIFICATION_ID, notification);
} else {
startForeground(NOTIFICATION_ID, notification);
// start InnerService
startService(new Intent(this, InnerService.class));
}
} catch (Throwable e) {
e.printStackTrace();
}
return super.onStartCommand(intent, flags, startId);
}
然后在内部 Service 中也启动一个相同 ID 的 Notifacation ,并调用 stopSelf() 方法,结束内部 Service:
@Override
public void onCreate() {
super.onCreate();
try {
startForeground(NOTIFICATION_ID, new Notification());
} catch (Throwable throwable) {
throwable.printStackTrace();
}
stopSelf();
}
2、被 kill 后拉活
此类方法暂未实践,后续补充。暂时简单提一下前人研究的可行性方案,不过这类方案都多多少少存在限制条件或者版本兼容性问题。
(1)通过系统广播拉活
简单讲就是监听一些特定的系统广播,当系统发出这些广播时,即可相应事件拉活。
(2)利用第三方应用广播拉活
此方案和第1中方案类似,不同的时该方案接收第三方 TOP 应用广播。通过反编译第三方 TOP 应用(如 QQ、微信、支付宝等,以及个推、极光推送等推送 SDK ),找出它们外放的广播进行监听,响应相应广播事件拉活。
(3)利用系统Service机制拉活
将 Service 设置为 START_STICKY,利用系统机制在 Service 挂掉后拉活。
(4)双进程守护
通过双进程的 Service 相互绑定,在一个进程被 kill 时,另一个进程将其拉活。
(5)利用 JobScheduler 机制拉活
JobScheduler 允许在特定状态与特定时间间隔周期执行任务。可以利用它的这个特点完成保活的功能,效果类似开启一个定时器,与普通定时器不同的是其调度由系统完成。它是在 Android5.0 之后推出的,在 5.0 之前无法使用。
(6)利用 Native 进程拉活
利用 Linux 中的 fork 机制创建 Native 进程,在 Native 进程中监控主进程的存活,当主进程挂掉后,在 Native 进程中立即对主进程进行拉活。
以上内容来自原文:文章-阿里云开发者社区-云计算社区-阿里云