【解惑】App处于前台，Activity就不会被回收了？

最新推荐文章于 2023-05-12 13:55:47 发布

郭霖_

最新推荐文章于 2023-05-12 13:55:47 发布

阅读量111

点赞数

文章标签： android java 开发语言

原文链接：https://mp.weixin.qq.com/s?__biz=MzA5MzI3NjE2MA==&mid=2650271249&idx=1&sn=d4824f059dee2d0bb63f2acbf3b8a2e7&chksm=88631f7ebf149668ca57042dbf1c1272603728aa73a58f1651a2059f3e9eeab3d105e22fbf9f&scene=126&sessionid=0

版权

/ 今日快讯 /

昨晚2022年卡塔尔世界杯决赛，阿根廷对阵法国。两队在90分钟常规比赛时间里2-2战平。加时赛中梅西和姆巴佩各入一球，3-3，比赛拖进了点球大战。点球大战中阿根廷最终总比分7-5战胜法国，时隔36年再次夺得世界杯冠军，这也是阿根廷队史第3次在世界杯夺冠。

/ 作者简介 /

大家周一好，再防寒的同时也别忘了防“羊”哦！

本篇文章转自coder_pig的博客，文章主要分享了作者探究Activity存活机制的相关过程，相信会对大家有所帮助！

原文地址：

https://juejin.cn/post/7063068797304832030

/ 前言 /

昨天在康 KunMinX 大佬的：《重学安卓：Activity 生命周期的 3 个辟谣》，原文地址如下：

https://xiaozhuanlan.com/topic/0213584967

在加餐处看到这段：

转换后的理解：单进程场景，Activity被回收只可能是因为进程被系统回收了。

感觉不太对？因为在很久以前，遇到过这样一个场景：

App打开多个Activity，然后手机晾一边，过一段时间后（屏幕常亮），点击回退，之前的Activity空白，然后重新加载了。

App在前台，不在栈顶的Activity却被干掉，但进程还健在，如果真是这样，就和上面的理解有些出入了。立马写个代码验证下，大概流程如下：

写个父类Activity，生命周期回调加日志打印，接着打开一个Activity，包含一个按钮，点击后依次打开多个Activity，最后一个加个按钮，点一下就申请一个大一点的ByteArray来模拟内存分配，看内存不足时是否会回收Activity。

测试结果如下：

App宁愿OOM，也不愿意回收Activity，鬼使神差地加上android:largeHeap="true"，结果一样。

em...难道是我记错了？？？

等等！！！我好像混淆了两个东西：系统可用内存不足和应用可用内存不足。

/ 0x1、系统可用内存不足 /

LMK机制

Android系统中，进程的生命周期由系统控制，处于体验和性能考虑，在APP中点击Home键或Back回退操作，并不会真的杀掉APP，进程依旧存在于内存中，这样下次启动此APP时就能更加快速。随着系统运行时间增长，打开APP越来越多，内存中的进程随着增多，系统的可用内存会越来越少。咋办，总不能让用户自己去杀进程吧，所以系统内置一套回收机制，当系统可用内存达到一个阈值，系统会根据进程优先级来杀掉一部分进程，释放内存供后续启动APP使用。

Android的这套回收机制，是基于Linux内核的OOM规则改进而来的，叫 Low Memory Killer，简称 LMK。

阈值 & 杀谁

通过下述两个文件配合完成，不同手机数值可能不同，以我的老爷机魅蓝E2为例（Android 11的Mix2S一直说没权限打开此文件）：

# /sys/module/lowmemorykiller/parameters/minfree
# 单位：Page页，1Page = 4KB
18432,23040,27648,46080,66560,97280

# /sys/module/lowmemorykiller/parameters/adj
0,58,117,176,529,1000

Android系统会为每个进程维护一个adj(优先级)：

Android 6及以前称为：oom_adj，值范围：[-17,16]，LMK要换算*1000/17
Android 7后称为：oom_score_adj，值范围：[-1000,1000]

然后，上面两个文件的值，其实是以一一对应的，比如：

66560  * 4 / 1024 = 260MB → 当系统可用内存减少到260MB时，会杀掉adj值大于529的进程；
18432 * 4 / 1024 = 72MB → 当系统可用内存减少到72MB，杀掉ajd值大于0的进程；

adj怎么看

直接通过命令行查看：

可以看到，adj是动态变化的，当App状态及四大组件生命周期发生改变时，都会改变它的值。常见ADJ级别如下：

NATIVE_ADJ→ -1000，init进程fork出来的native进程，不受system管控；
SYSTEM_ADJ→ -900，system_server进程；
PERSISTENT_PROC_ADJ→ -800，系统persistent进程，一般不会被杀，杀了或者Carsh系统也会重新拉起；
PERSISTENT_SERVICE_ADJ→ -700，关联着系统或persistent进程；
FOREGROUND_APP_ADJ→ 0，前台进程；
VISIBLE_APP_ADJ→ 100，可见进程；
PERCEPTIBLE_APP_ADJ→ 200，可感知进程，比如后台音乐播放；
BACKUP_APP_ADJ→ 300，执行bindBackupAgent()过程的备份进程；
HEAVY_WEIGHT_APP_ADJ→ 400，重量级进程，system/rootdir/init.rc文件中设置；
SERVICE_ADJ→ 500，服务进程；
HOME_APP_ADJ→ 600，Home进程，类型为ACTIVITY_TYPE_HOME的应用，如Launcher；
PREVIOUS_APP_ADJ→ 700，用户上一个使用的App进程；
SERVICE_B_ADJ→ 800，B List中的Service；
CACHED_APP_MIN_ADJ→ 900，不可见进程的adj最小值；
CACHED_APP_MAX_ADJ→ 906，不可见进程的adj最大值；
UNKNOWN_ADJ→ 1001，一般指将要会缓存进程，无法获取确定值；

关于ADJ计算的详细算法分析可见Gityuan大佬的：

http://gityuan.com/2018/05/19/android-process-adj/

干货多多，顺带从总结处捞一波进程保活伎俩：

UI进程与Service进程分离，包含Activity的Service进程，一进后台ADJ>=900，随时可能被系统回收，分离的话ADJ=500，被杀的可能性降低，尤其是系统允许自启动的服务进程，必须做UI分离，避免消耗较大内存；
真正需要用户可感知的应用，调用startForegroundService()启用前台服务，ADJ=200;
进程中的Service工作完，务必主动调用stopService或stopSelf来停止服务，避免占用内存，浪费系统资源；
不要长时间绑定其他进程的service或者provider，每次使用完成后应立刻释放，避免其他进程常驻于内存；
APP应该实现接口onTrimMemory()和onLowMemory()，根据TrimLevel适当地将非必须内存在回调方法中加以释放，当系统内存紧张时会回调该接口，减少系统卡顿与杀进程频次；
更应在优化内存上下功夫，相同ADJ级别，系统会优先杀内存占用的进程；

问：能否把自己的App的ADJ值设置为-1000，让其杀不死？答：不可以，要有root权限才能修改adj，而且改了重启手机还是恢复的。

扯得有点远了，回到问题上：

系统内存不足时，会在内核层直接查杀进程，不会在Framework层还跟你叨逼叨看回收哪个Activity。

所以在系统这个层面，单进程场景，Activity被回收只可能是因为进程被系统回收了，这句话是没毛病的，但在应用层面就不一定了。

/ 0x2、应用可用内存不足 /

APP进程（虚拟机）的内存分配实际上是对堆的分配和释放，为了整个系统的内存控制需要，会为每个应用程序设置一个堆的限制阈值，如果应用使用内存接近阈值还尝试分配内存，就很容易引起OOM。