本文探讨了Android 6.0及以上系统中，特别是即时通讯和消息推送应用如何应对进程被系统杀死的问题。通过降低oom_adj值、使用前台Service和监听锁屏广播等方式提高APP保活率。文章详细分析了不同保活策略，包括使用startForeground()方法、前台Service、弱引用避免内存泄漏以及循环播放无声音频等技术，同时测试了在不同设备上的保活效果。
在Android 4.4及以后的系统中，应用能否常驻内存，一直以来都是相当头疼的事情，尤其移动端IM、消息推送这类应用，为了保证“全时在线”的概念，真是费尽了心思。虽然APP常驻内存对于用户来说比较”恶心”，但是在诸如IM和消息推送这类场景来说，APP的常驻内存却尤其重要。
于是，又带着怀疑的眼光，重新找回原来的代码进行测试，顺便分析了市场上主流运动类APP保活方法（微信、手Q就算了，富人家的孩子，不具代表性），同时也对系统对内存中APP的管理规则进行了进一步探索。
Andriod应用保活核心思想归纳
对于Android6.0及其以上系统APP保活，我觉得主要还是通过这两个方面进行，即：
降低omm_adj值，尽量保证进程不被系统杀死（本文要讨论的内容）；
进程被杀死后，通过其他方式将进程复活（将在下篇讨论）。
但需要明白的是，面对各手机厂商的深度定制和谷歌越来越严格的资源管理机制，这两种方式结合的保活不是永久的，只能是相对存在，不同的机型结果也是不一样的。
由于篇幅限制，本文主要剖析下通过何种方式降低oom_adj的值来降低APP被杀的几率，以及oom_adj值是怎样做到的？
接下来，我们需要了解下Android系统回收内存中的进程所依据的规则：
进程在内存中时活动主要有五种状态：即前台进程、可见进程、服务进程、后台进程、空进程，这几种状态的进程优先级由高到低，oom_adj值由低到高(在ProcessList定义)。然后Android系统会根据当前系统资源和进程oom_adj值来回收相应的进程，前台进程一般不会被回收，空进程最容易被回收，这种管理规则就是"传说中"的Low Memory Killer。
注：优先级1表示最高级，普通进程的oom_adj>=
最低0.47元/天 解锁文章
扫一扫
1368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
