android在启动进程后会调用attachApplicationLocked，在其中利用Binder的linkToDeath方法来接收进程退出消息

ams中的attachApplicationLocked方法

privatefinal boolean attachApplicationLocked(IApplicationThread thread,int pid) {

...

if (localLOGV) Slog.v(

TAG, "Bindingprocess pid " + pid + " to record " + app);

final StringprocessName = app.processName;

try {

AppDeathRecipient adr = new AppDeathRecipient(

app,pid, thread);

thread.asBinder().linkToDeath(adr, 0);

app.deathRecipient = adr;

} catch(RemoteException e) {

app.resetPackageList(mProcessStats);

startProcessLocked(app, "link fail", processName);

return false;

}

...

}

官方文档中对linkToDeath 的解释

publicabstract void linkToDeath (IBinder.DeathRecipient recipient,int flags)

Registerthe recipient for a notification if this binder goes away. If this binderobject unexpectedly goes away (typically because its hosting process has beenkilled), then the given IBinder.DeathRecipient's DeathRecipient.binderDied() methodwill be called.

You willonly receive death notifications for remote binders, as local binders bydefinition can't die without you dying as well.

就是说我们通过systemService申请了某个service的Binder后，可以调用这个IBinder的linkToDeath函数进行注册。可以注册一个IBinder.DeathRecipient类型的对象。其中IBinder.DeathRecipient是IBinder类中定义的一个嵌入类。当这个IBinder所对应的Service进程被异常的退出时，比如被kill掉，这时系统会调用这个IBinder之前通过linkToDeath注册的DeathRecipient类对象的binderDied函数。

一般实现中，Bp端会注册linkToDeath，目的是为了监听绑定的Service的异常退出，一般的binderDied函数的实现是用来释放一些相关的资源。

private final class AppDeathRecipientimplements IBinder.DeathRecipient {

final ProcessRecord mApp;

final int mPid;

final IApplicationThread mAppThread;

AppDeathRecipient(ProcessRecord app,int pid,

IApplicationThread thread) {

if (localLOGV) Slog.v(

TAG, "New death recipient" + this

+ " for thread " +thread.asBinder());

mApp = app;

mPid = pid;

mAppThread = thread;

}

@Override

public void binderDied() {

if (localLOGV) Slog.v(

TAG, "Death received in" + this

+ " for thread " +mAppThread.asBinder());

synchronized(ActivityManagerService.this) {

appDiedLocked(mApp, mPid,mAppThread);

}

}

}

final void appDiedLocked(ProcessRecord app,int pid,IApplicationThread thread) {

...

if (!app.killedByAm) {

Slog.i(TAG, "Process " + app.processName + " (pid "+ pid

+") has died.");

mAllowLowerMemLevel = true;

}else{

// Note that we always want to do oom adj to update our statewith the

// new number ofprocs.

mAllowLowerMemLevel =false;

doLowMem = false;

}

...

}

到这里应该明白，logcat打印：I/ActivityManager( 510): Process xxx (pid xxx) has died.的时候，IBinder所对应的Service进程异常退出（被杀）造成的。

那么service被杀除了service本身代码逻辑的问题，很多情况就是系统内存不足时引起的，这就又回到内存管理了，这里就简单叙述一下。

Android基于进程中运行的组件及其状态规定了默认的五个回收优先级：

IMPORTANCE_FOREGROUND:

IMPORTANCE_VISIBLE:

IMPORTANCE_SERVICE:

IMPORTANCE_BACKGROUND:

IMPORTANCE_EMPTY:

这几种优先级的回收顺序是 Empty process、Background process、Serviceprocess、Visible process、Foreground process。

ActivityManagerService和ActivityStackSupervisor中涉及到内存回收的几个

重要的成员方法如下：trimApplications()，updateOomAdjLocked() ，activityIdleInternal()。这几个成员方法主要负责Android 默认的内存回收机制。

回收动作入口：activityIdleInternal()

Android系统中内存回收的触发点大致可分为三种情况。第一，用户程序调用 StartActivity(), 使当前活动的 Activity 被覆盖；

第二，用户按 back 键，退出当前应用程序；第三，启动一个新的应用程序。这些能够触发内存回收的事件最终调用的函数接口就是 activityIdleInternal()。

当 ActivityStackSupervisor接收到异步消息IDLE_TIMEOUT_MSG 或者 IDLE_NOW_MSG 时，activityIdleInternal() 将会被调用。