Android程序永不被系统kill

一般来说，在Android系统中，当某进程较长时间不活动，或系统资源比较紧时，该进程可能被系统kill掉，以此来回收一些资源。Android系统会根据进程的优先级来选择性地杀死一些进程，优先级从高到低依次是：

1. 前台进程（Foreground Process）

2. 可视进程（Visible Process）

3. 服务进程（Service Process）

4. 后台进程（Background Process）

5. 空进程（Empty Process）

 

 

1. 前台进程（Foreground Process）是指当前的活动进程，即那些有窗口、控件的，正与用户进行交互的应用程序进程。Android会努力尝试从其它进程回收系统资源来保持其响应。

2. 可见进程（Visible Process）是指那些可见的活动进程，但是当前它不在前台运行，不能对用户事件作出反映。比如一个程序A正在前台运行，接着又启动了另一个程序B，程序B的窗口把程序A的窗口完全或部分遮挡，那么，程序A现在就属于可见进程了。一般来说，只有在系统资源十分缺乏的情况下，为了保证活动进程的运行，系统才会终止它。

3. 服务进程（Service Process）是指那些没有可见界面的进程，它们不能直接与用户进行交互。前台进程（通常是一个Activity）变为非活动时，会暂停运行；但服务进程可在后台保持运行，因此如果要保持进程在转到后台后也能运行，就必需启动一个Service。但是一旦前台进程需要资源时，Service就很容易被系统给kill掉。通常，默认情况下Service被kill掉后会自动重启，但是重启后并不能保证恢复先前的环境；如果不需要Service自动重启，调用stopSelf()函数即可。

4. 后台进程（Background Process）是指不可见的，且没有任何正在运行的服务的活动的进程。通常后台进程会比较多，Android将按“最后一个被看到，第一个终止”的方式来终止它们，从而为前台进程提供资源。

5. 对于空进程，Android为了提高系统的整体性能，经常在在应用程序的生存期结束后仍然把它们保存在内存中，当该程序被再次启动时，可以加快启动速度。这类进程会根据需要被定期终止。

 

 

由上可知，要想自己所写的Service不轻易被系统在回收资源时kill掉，正常的做法是尽量提高程序的优先级，如调用startForeground(true)。因为Service启动时默认被标记为Background，当前运行的Activity被标记为Foreground，当将Service设置为Foreground后，它的优先级就与正在运行的Activity类似，但是这也不能保证它不被系统kill。

如果我们要写一个监控程序，监测其它程序的运行，那么该怎么办呢？我们必需保证我们的程序不会因回收资源而kill。显然，优先级为2-5的进程都不可靠，作为监控程序，其优先级也不可能为1。

这样看上去，貌似没有办法了……别急，继续看下面……

 

 

 

解决方法：

简单地说，就是将自己写的Service变成Core Service，即将自己写的程序提升为系统级别的程序，这样在任何情况下它都不会被kill掉。

要想自己写的Service提升为Core Service，应用程序需要设置两个标志：FLAG_PERSISTENT和FLAG_SYSTEM。