android进程守护 失效,保持Service不被Kill掉的方法--双Service守护 && Android实现双进程守护 1...

本文分为两个部分，第一部分为双Service守护，第二部分为双进程守护

第一部分：

一、Service简介：Java.lang.Object

?Android.content.Context

?android.content.ContextWrapper

?android.app.Service

Service是应用程序Application的一个组件(component)。

它的作用有两点：1.用来提供一个长期在后台运行并且不与用户交互的操作，2.也可以为其他应用程序提供服务。

Service必须和其他四大组件一样，使用标签在AndroidManifest.xml中进行声明。

启动service有两种方式Context.startService() 和 Context.bindService()。

注意，除了特别指定外，service并不是单独的进程，一般service在其宿主进程的主线程(UI Thread)中运行【当然也可以在新的线程中startService，这样Service就不是在MainThread了】。这意味着，如果您的服务要做任何 耗时(如 MP3 播放) 或阻塞 (比如网络) 操作，它应该产生它自己的线程，用来做那项工作。(service不是单独的进程也不是单独的线程)

Service提供了两大功能：

Context.startService()用来在后台启动一个服务；

Context.bindService()用来绑定其他服务，以此来获取其他service提供的服务；

本地服务 Local Service 用于应用程序内部

它可以启动并运行，直至有人停止了它或它自己停止。在这种方式下，它以调用Context.startService()启动，而以调用

Context.stopService()结束。它可以调用Service.stopSelf() 或

Service.stopSelfResult()来自己停止。不论调用了多少次startService()方法，你只需要调用一次

stopService()来停止服务。

【用于实现应用程序自己的一些耗时任务，比如查询升级信息，并不占用应用程序比如Activity所属线程，而是单开线程后台执行，这样用户体验比较好】

远程服务 Remote Service 用于android系统内部的应用程序之间

它可以通过自己定义并暴露出来的接口进行程序操作。客户端建立一个到服务对象的连接，并通过那个连接来调用服务。连接以调用

Context.bindService()方法建立，以调用

Context.unbindService()关闭。多个客户端可以绑定至同一个服务。如果服务此时还没有加载，bindService()会先加载

它。

【可被其他应用程序复用，比如天气预报服务，其他应用程序不需要再写这样的服务，调用已有的即可】

二、Service运行方式和生命周期图：

以startService()启动服务，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启

动则先运行onCreate，然后运行onStartCommand

(可在里面处理启动时传过来的Intent和其他参数)，直到明显调用stopService或者stopSelf才将停止Service。无论运行

startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方

法可以保证在处理好intent后再停止。onStartCommand

，在2.0后被引入用于service的启动函数，2.0之前为public void onStart(Intent intent, int

startId) 。

以bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止。onBind()只有采用

Context.bindService()方法启动服务时才会回调该方法。该方法在调用者与服务绑定时被调用，当调用者与服务已经绑定，多次调用

Context.bindService()方法并不会导致该方法被多次调用。采用Context.bindService()方法启动服务时只能调用

onUnbind()方法解除调用者与服务解除，服务结束时会调用onDestroy()方法。

(注意这个新老API的改变)

void onStart(Intent intent, int startId)

This method was deprecated      in API level 5.    Implement onStartCommand(Intent, int, int) instead.

int onStartCommand(Intent intent, int flags, int startId)

Called by the system every time a client explicitly starts the service

by calling  startService(Intent), providing the arguments it supplied

and a  unique integer token representing the start request.

三、Service的优先级

官方文档告诉我们，Android系统会尽量保持拥有service的进程运行，只要在该service已经被启动(start)或者客户端连接(bindService)到它。当内存不足时，需要保持，拥有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等运行在相同的进程中，那么将会增加该进程的重要性。

四、保持service不被kill掉

方法一：

START_STICKY is used for services that are explicitly started and

stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are

used for services that should only remain running while processing any

commands sent to them

onStartCommand方法几个返回值简介：

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。

@Override

public int onStartCommand(Intent intent, int flags, int startId) {

flags = START_STICKY;

return super.onStartCommand(intent, flags, startId);

}

【结论】 手动返回START_STICKY，亲测当service因内存不足被kill，当内存又有的时候，service又被重新创建，比较不错，但是不能保证任何情况下都被重建，比如进程被干掉了....

方法二：

提升service优先级

在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = "1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。

android:name="com.dbjtech.acbxt.waiqin.UploadService"

android:enabled="true" >

【结论】目前看来，priority这个属性貌似只适用于broadcast，对于Service来说可能无效

方法三：

提升service进程优先级

Android中的进程是托管的，当系统进程空间紧张的时候，会依照优先级自动进行进程的回收。Android将进程分为6个等级,它们按优先级顺序由高到低依次是:

1.前台进程( FOREGROUND_APP)

2.可视进程(VISIBLE_APP )

3. 次要服务进程(SECONDARY_SERVER )

4.后台进程 (HIDDEN_APP)

5.内容供应节点(CONTENT_PROVIDER)

6.空进程(EMPTY_APP)

当service运行在低内存的环境时，将会kill掉一些存在的进程。因此进程的优先级将会很重要，可以使用startForeground将service放到前台状态。这样在低内存时被kill的几率会低一些。

在onStartCommand方法内添加如下代码：

Notification notification = new Notification(R.drawable.ic_launcher,getString(R.string.app_name), System.currentTimeMillis());

PendingIntent pendingintent = PendingIntent.getActivity(this, 0,new Intent(this, AppMain.class), 0);

notification.setLatestEventInfo(this, "uploadservice", "请保持程序在后台运行", pendingintent);

startForeground(0x111, notification);

注意在onDestroy里还需要stopForeground(true)，运行时在下拉列表会看到自己的APP在：

【结论】如果在极度极度低内存的压力下，该service还是会被kill掉，并且不一定会restart

原文：http://www.cnblogs.com/yaowen/p/5673960.html