im即时通讯开发：进程被杀底层原理、APP应对被杀技巧

本文的技术原理讲解透彻、系统源码分享到位、样例代码也很有参考意义，希望能对有同样兴趣爱好的Android开发者、IM开发者、推送系统开发者等，带来对于Android进程保活技术的深入理解。

一直以来，App 进程保活都是各大厂商，特别是头部应用开发商永恒的追求。毕竟App 进程死了，就什么也干不了了。一旦 App 进程死亡，那就再也无法在用户的手机上开展任何业务，所有的商业模型在用户侧都没有立足之地了。

 

早期的 Android 系统不完善，导致 App 侧有很多空子可以钻，因此它们有着有着各种各样的姿势进行保活。

譬如说在 Android 5.0 以前，App 内部通过 native 方式 fork 出来的进程是不受系统管控的，系统在杀 App 进程的时候，只会去杀 App 启动的 Java 进程。因此诞生了一大批“毒瘤”，他们通过 fork native 进程，在 App 的 Java 进程被杀死的时候通过 am命令拉起自己从而实现永生。

那时候的 Android 可谓是魑魅横行，群魔乱舞，系统根本管不住应用，因此长期以来被人诟病耗电、卡顿。

同时，系统的软弱导致了 Xposed 框架、阻止运行、绿色守护、黑域、冰箱等一系列管制系统后台进程的框架和 App 出现。

不过，随着 Android 系统的发展，这一切都在往好的方向演变。

Android 5.0 以上，系统杀进程以 uid 为标识，通过杀死整个进程组来杀进程，因此 native 进程也躲不过系统