Low Memory Killer
-
系统出于性能和体验上的考虑,
app
退到后台时系统并不会真正的kill掉这个进程,而是将其缓存起来。 -
打开的
app
越多,后台缓存的进程也就越多。 -
在系统内存不足的情况下,系统开始依据自身的一套进程回收机制来判断要
kill
掉哪些进程,以腾出空间来供给需要的app
,这套杀进程回收内存的机制就叫做Low Memory Killer
。
进程生命周期:
什么是进程的生命周期?
Android 系统将尽量长时间地保持应用进程,但为了新建进程或运行更重要的进程,最终需要移除旧进程来回收内存。 为了确定保留或终止哪些进程,系统会根据进程中正在运行的组件以及这些组件的状态,将每个进程放入“重要性层次结构”中。 必要时,系统会首先消除重要性最低的进程,然后是重要性略逊的进程,依此类推,以回收系统资源。
重要性层次结构一共有 5 级。以下列表按照重要程度列出了各类进程(第一个进程最重要,将是最后一个被终止的进程):
-
前台进程
用户当前操作所必需的进程。如果一个进程满足以下任一条件,即视为前台进程:
- 托管用户正在交互的(已经调用了activity的onResume()方法)
- 托管某个 Service,后者绑定到用户正在交互的 Activity
- 托管正在“前台”运行的 Service(调用了startForeground)
- 托管正执行一个生命周期回调的 Service(onCreat(),onstart(),onDestory())
- 托管正执行其 onReceive()的BroadcastReceiver
通常,在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下,系统才会终止它们。 此时,设备往往已达到内存分页状态,因此需要终止一些前台进程来确保用户界面正常响应。
-
可见进程
没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。 如果一个进程满足以下任一条件,即视为可见进程:
- 托管不在前台、但仍对用户可见的 Activity(已调用其
onPause()
方法)。例如,如果前台 Activity 启动了一个对话框,允许在其后显示上一 Activity,则有可能会发生这种情况。 - 托管绑定到可见(或前台)Activity 的
Service
。
可见进程被视为是极其重要的进程,除非为了维持所有前台进程同时运行而必须终止,否则系统不会终止这些进程。
- 托管不在前台、但仍对用户可见的 Activity(已调用其
-
服务进程
- 正在运行已使用
startService()
方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联,但是它们通常在执行一些用户关心的操作(例如,在后台播放音乐或从网络下载数据)。因此,除非内存不足以维持所有前台进程和可见进程同时运行,否则系统会让服务进程保持运行状态。
- 正在运行已使用
-
后台进程
- 包含目前对用户不可见的 Activity 的进程(已调用 Activity 的
[onStop()]
方法)。这些进程对用户体验没有直接影响,系统可能随时终止它们,以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行,因此它们会保存在 LRU (最近最少使用)列表中,以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法,并保存了其当前状态,则终止其进程不会对用户体验产生明显影响,因为当用户导航回该 Activity 时,Activity 会恢复其所有可见状态。
- 包含目前对用户不可见的 Activity 的进程(已调用 Activity 的
-
空进程
- 不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存,以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡,系统往往会终止这些进程。
所以!
根据进程中当前活动组件的重要程度,Android 会将进程评定为它可能达到的最高级别。例如,如果某进程托管着服务和可见 Activity,则会将此进程评定为可见进程,而不是服务进程。
此外,一个进程的级别可能会因其他进程对它的依赖而有所提高,即服务于另一进程的进程其级别永远不会低于其所服务的进程。 例如,如果进程 A 中的内容提供程序为进程 B 中的客户端提供服务,或者如果进程 A 中的服务绑定到进程 B 中的组件,则进程 A 始终被视为至少与进程 B 同样重要。
由于运行服务的进程其级别高于托管后台 Activity 的进程,因此启动长时间运行操作的 Activity 最好为该操作启动[服务],而不是简单地创建工作线程,当操作有可能比 Activity 更加持久时尤要如此。例如,正在将图片上传到网站的 Activity 应该启动服务来执行上传,这样一来,即使用户退出 Activity,仍可在后台继续执行上传操作。使用服务可以保证,无论 Activity 发生什么情况,该操作至少具备“服务进程”优先级。 同理,广播接收器也应使用服务,而不是简单地将耗时冗长的操作放入线程中。
实践
根据上面google给出的开发者文档中对于进程优先级的详细描述,我们就可以知道一个结论——想要进程保活,就要提高进程的优先级,交互状态下就不说了,如果我们在锁屏和退到后台的状态下把进程的优先级提升,那不就做到了进程保活的目的么,这就动手!
首先就是网上比较火的一像素保活(亲测有效)
它的原理很简单,通过检测手机的锁屏键广播,当锁屏时,打开一个只显示一个像素点的activity
在window
上,唤醒屏幕的时候再将其finish
掉,这就将进程的优先级提升到了前台进程,达到了保活的目的
public class KeepAliveActivity extends Activity {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Window window =getWindow();
window.setGravity(Gravity.START | Gravity.TOP);
WindowManager.LayoutParams params = window.getAttributes();
params.width =1;
params.height =1;
params.x = 0;
params.y =0 ;
window.setAttributes(params);
}
}
public class KeepReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (TextUtils.equals(action, Intent.ACTION_SCREEN_ON)) {
KeepManager.getmInstance().finishKeep();
} else if
(TextUtils.equals(action, Intent.ACTION_SCREEN_OFF)) {
KeepManager.getmInstance().startKeep(context);
}
}
}
这就是一像素保活的大概思路,再配合上开一个常驻的前台服务(这里代码就不贴了),就可以实现简单又实用的进程保活,很简单有木有!
小结
进程保活的原理其实就是提升进程的优先级,虽然流氓,但毕竟很多app不可能像微信那样列入了各大手机厂商的白名单,也不可能像腾讯系和阿里系那样又那么大的体量——一人打开,全家拉活
。 当老板提需求时还是得做(无奈ing)。当然还有很多其他的方法,这就要靠android developer
的集思广益,用另辟蹊径的方法去战胜Google Engineer
(手动滑稽)!
网友评论