Binder承担了绝大部分Android进程通信的职责，可以看做是Android的血管系统，负责不同服务模块进程间的通信。在对Binder的理解上，可大可小，日常APP开发并不怎么涉及Binder通信知识，最多就是Service及AIDL的使用会涉及部分Binder知识。Binder往小了说可总结成一句话：一种IPC进程间通信方式，负责进程A的数据，发送到进程B。往大了说，其实涉及的知识还是很多的，如Android 对于原Binder驱动的扩展、Zygote进程孵化中对于Binder通信的支持、Java层Binder封装，Native层对于Binder通信的封装、Binder讣告机制等等。很多分析Binder框架的文都是从ServiceManager、Binder驱动、addService、getService来分析等来分析，其实这些主要是针对系统提供的服务，但是bindService启动的服务走的却还是有很大不同的。本篇文章主要简述一些Binder难以理解的点，但不会太细的跟踪分析，只抛砖，自己去发掘玉：
Android应用运行在后台的时候，经常被系统的LowMemoryKiller杀掉，当用户再次点击icon或者从最近的任务列表启动的时候，进程会被重建，并且恢复被杀之前的现场。什么意思呢？假如APP在被杀之前的Activity堆栈是这样的，A<B<C，C位于最上层
Binder是一个类似于C/S架构的通信框架，有时候客户端可能想知道服务端的状态，比如服务端如果挂了，客户端希望能及时的被通知到，而不是等到再起请求服务端的时候才知道，这种场景其实在互为C/S的时候最常用，比如AMS与APP，当APP端进程异常退出的时候，AMS希望能及时知道，不仅仅是清理APP端在AMS中的一些信息，比如ActivityRecord，ServiceRecord等，有时候可能还需要及时恢复一些自启动的Service。Binder实现了一套”死亡讣告”的功能，即：服务端挂了，或者正常退出，Binder驱动会向客户端发送一份讣告，告诉客户端Binder服务挂了。
本篇文章是后台杀死系列的最后一篇，主要探讨一下进程的保活，Android本身设计的时候是非常善良的，它希望进程在不可见或者其他一些场景下APP要懂得主动释放，可是Android低估了”贪婪“，尤其是很多国产APP，只希望索取来提高自己的性能，不管其他APP或者系统的死活，导致了很严重的资源浪费，这也是Android被iOS诟病的最大原因。本文的保活手段也分两种：遵纪守法的进程保活与流氓手段换来的进程保活。
App在后台久置后，再次从桌面或最近的任务列表唤醒时经常会发生崩溃，这往往是App在后台被系统杀死，再次恢复的时候遇到了问题，而在使用FragmentActivity+Fragment的时候，经常会遇到：比如Fragment没有提供默认构造方法，就会重建的时候因为反射创建Fragment失败而崩溃，再比如，在onCreate里面new 一个FragmentDialog，并且show，在被后台杀死，再次唤醒的时候，就会show两个对话框，这是为什么？其实这就涉及了后台杀死及恢复的机制，其中涉及的知识点主要是FragmentActivity、ActivityManagerService、LowMemoryKiller机制、ActivityStack、Binder等一系列知识点。放在一篇文章里面可能会有些长，因此，Android后台杀死系列写了三篇：
Service可能大家都能说上两句，比如四大组件之一，同Activity的区别是没前台交互界面，可以启动后台任务等等。不过Service到底什么意思，
本篇是Android后台杀死系列的第二篇，主要讲解ActivityMangerService是如何恢复被后台杀死的进程的（基于4.3 ），在开篇FragmentActivity及PhoneWindow后台杀死处理机制中，简述了后台杀死所引起的一些常见问题，还有Android系统控件对后台杀死所做的一些兼容，以及onSaveInstance跟onRestoreInstance的作用于执行时机，最后说了如何应对后台杀死。但是，对于被后台杀死的进程如何恢复的并没有讲解，本篇不涉及后台杀死，比如LowmemoryKiller机制，只讲述被杀死的进程如何恢复的。假设，一个应用被后台杀死，再次从最近的任务列表唤起App时候，系统是如何处理的呢？有这么几个问题可能需要解决：
本篇是Android后台杀死系列的第三篇，前面两篇已经对后台杀死注意事项，杀死恢复机制做了分析，本篇主要讲解的是Android后台杀死原理。相对于后台杀死恢复，LowMemoryKiller原理相对简单，并且在网上还是能找到不少资料的，不过，由于Android不同版本在框架层的实现有一些不同，网上的分析也多是针对一个Android版本，本文简单做了以下区分对比。LowMemoryKiller(低内存杀手)是Andorid基于oomKiller原理所扩展的一个多层次oomKiller，OOMkiller(Out Of Memory Killer)是在Linux系统无法分配新内存的时候，选择性杀掉进程，到oom的时候，系统可能已经不太稳定，而LowMemoryKiller是一种根据内存阈值级别触发的内存回收的机制，在系统可用内存较低时，就会选择性杀死进程的策略，相对OOMKiller，更加灵活。在详细分析其原理与运行机制之前，不妨自己想一下，假设让你设计一个LowMemoryKiller，你会如何做，这样一个系统需要什么功能模块呢？