[Android] Activity被系统回收了？

Posted 2022-07-05 小陈乱敲代码

前言

日常开发中经常会出现这样的情景，测试跟开发唇枪舌战“为什么从其他app返回，页面内容要重新加载呢，这肯定是个bug”，“Activity被系统回收了，不是bug”；“为什么切换到后台，这个app心跳不在线了呢，这肯定也是bug”，“这是后台进程被系统回收了，算什么bug”。内存回收是在android开发中经常接触到的概念，但是你真的了解内存回收吗？这篇我们就来简单探讨下Android的内存回收机制。

Android内存回收机制

Addroid系统在设计时处于用户体验和性能优化的角度，设计了LMK机制：Low Memory Killer简称LMK,用于处理内存回收调度。

简单来说就是，当app切换到后台时，为了能在用户再次打开app时，及时进行响应加快app打开时间，Android系统对于切换到后台的app，并不会立即杀死回收，而是在保证系统资源足够的情况下，尽可能的提升app进程在系统内存中的留存时间，只有当系统内存资源不足时，按照一定的优先级将app进程回收，这套机制就是LMK。

Android进程分类

Android系统根据app当前状态和组件运行声明周期，按照进程重要程度，将app进程进行了分类。

在Android 5.0之前，系统将app进程分为了5类，分别是：

• 前台进程——IMPORTANCE_FOREGROUND
  • 简单来说：当前用户正在操作的进程。
  • 比如一下任意一个，都会被认为是前台进程：
    • 它正在用户的互动屏幕上运行一个 Activity（其 onResume() 方法已被调用）。
    • 它有一个 BroadcastReceiver 目前正在运行（其 BroadcastReceiver.onReceive() 方法正在执行）。
    • 它有一个 Service 目前正在执行其某个回调（Service.onCreate()、Service.onStart() 或 Service.onDestroy()）中的代码。
• 可见进程——IMPORTANCE_VISIBLE
  • 正在进行用户当前知晓的任务，也就是说能够被用户感知到的进程。
  • 比如：
    • 它正在运行的 Activity 在屏幕上对用户可见，但不在前台（其 onPause() 方法已被调用）。举例来说，如果前台 Activity 显示为一个对话框，而这个对话框允许在其后面看到上一个 Activity，则可能会出现这种情况。
    • 它有一个 Service 正在通过 Service.startForeground()（要求系统将该服务视为用户知晓或基本上对用户可见的服务）作为前台服务运行。
    • 系统正在使用其托管的服务实现用户知晓的特定功能，例如动态壁纸、输入法服务等。
• 服务进程——IMPORTANCE_SERVICE
  • 含一个已使用 startService() 方法启动的 Service。
  • 注意：
    • 这里说的服务进程是指Service是单独的进程，此进程中没有启动过Activity。
    • 并且在30分钟内活跃过的服务进程。
• 后台进程——IMPORTANCE_BACKGROUND
  • app切换到后台，app通常包含用户当前不可见的一个或多个 Activity 实例（onStop() 方法已被调用并返回）。
• 空白进程——IMPORTANCE_EMPTY

当然在5.0之后的Android系统中，对进程分类再次进行的细化，比如：

• Android 5.0，新增了
  • • IMPORTANCE_PERCEPTIBLE
    • IMPORTANCE_CANT_SAVE_STATE
    • IMPORTANCE_CACHED
      • 等同于IMPORTANCE_BACKGROUND
  • Android 11.0，新增到了9种
    • IMPORTANCE_TOP_SLEEPING
      • 前台app，但是系统进入的休眠，此app进程。
    • IMPORTANCE_FOREGROUND_SERVICE
      • 将Service.startForeground()前台服务这种情况进行了拆分，单列。

这里就不详细介绍了，可以通过源码：android.app.ActivityManager.RunningAppProcessInfo查看详细的定义和注释介绍。

ADJ

刚开始提到了当系统内存资源不足时，系统会按照一定的优先级将app进程回收，这个优先级就是adj。

App进程启动时，Android系统会为其分配一个单独的adj，adj的取值会随着进程的状态和其组件的生命周期动态变化。

查看系统adj

Android维护了一套adj值与可用内存的对应关系，他们是一一对应的，当可用内存达到阈值时，会将对应adj的进行进行回收，释放资源。

minfree和adj文件是描述系统可用内存与对应进程优先级的关系，分成多个等级两个文件值是一一对应的。

aosp:/sys/module/lowmemorykiller/parameters # cat minfree
18432,23040,27648,32256,36864,46080
aosp:/sys/module/lowmemorykiller/parameters # cat adj
0,100,200,300,900,906 

通过查看sys/module/lowmemorykiller/parameters/下的minfree和adj文件，可用获得内存阈值与adj对应关系。以上面数据为例：

注意：menfree值单位是page， 1page = 4K。

当系统可用内存小于46080 * 4 / 1024 = 180(M)时，系统会将adj大于906的进程回收，从而释放内存，同理，当系统可用内存小于18432 * 4 / 1024 = 72 M时，系统会将adj大于0的进程回收。

应用进程adj

App进程启动时，Android系统会为其分配一个单独的adj，进程adj的大小也可以通过adb命令进行查看。

// 查看应用进程号
aosp:/ # ps |grep com.zhong.event
u0_a45    2104  1060  1153372 92444          0 c7f29c02 S com.zhong.event
// 查看进程adj值
aosp:/ # cat /proc/2104/oom_score_adj
// com.zhong.event为前台应用，adb = 0
0 

进程adj值，可以通过查看文件/proc/进程号/oom_score_adj获得。

我们按Home键，将应用切换到后台，再次查看其adj值：

aosp:/ # cat /proc/2104/oom_score_adj
700 

手动kill掉进程后再次查看：

aosp:/ # cat /proc/2104/oom_score_adj
sh: cat: /proc/2104/oom_score_adj: No such file or directory
1|aosp:/ # 

可以发现，进程的adj值是动态变化的，且只有当应用进程存活时，系统才会为期分配adj。

注意：adj取值根据系统版本不同，硬件配置不同，会有差异，但是关系是一样的。

adj级别

adj值是动态变化的，系统会根据当前app状态及四大组件生命周期变化等因素，动态改变adj值，常见级别如下：

以下类型的adj取值，同样会因为不同Android版本不同，硬件配置不同，甚至不同厂家等原因会有所差异。

ADJ级别	取值	含义
NATIVE_ADJ	-1000	native进程
SYSTEM_ADJ	-900	仅指system_server进程
PERSISTENT_PROC_ADJ	-800	系统persistent进程
PERSISTENT_SERVICE_ADJ	-700	关联着系统或persistent进程
FOREGROUND_APP_ADJ	0	前台进程，用户目前执行操作所需的进程。
VISIBLE_APP_ADJ	100	可见进程，正在进行用户当前知晓的任务，
PERCEPTIBLE_APP_ADJ	200	可感知进程，ForegroundService
BACKUP_APP_ADJ	300	备份进程
HEAVY_WEIGHT_APP_ADJ	400	重量级进程
SERVICE_ADJ	500	服务进程，纯Service进程
HOME_APP_ADJ	600	Home进程，launcher app
PREVIOUS_APP_ADJ	700	上一个进程
SERVICE_B_ADJ	800	B List中的Service，资源不足时Service进程，降级
CACHED_APP_MIN_ADJ	900	不可见进程的adj最小值，activity finish
CACHED_APP_MAX_ADJ	906	不可见进程的adj最大值

我们重点关注下表格中加粗部分就可以了，可以看到这其中好多类型与我们上文介绍的Android进程分类有很明显的对应关系。

adj < 0

这些进程基本都是系统处理的进程，不用太多关注。唯一需要注意的是PERSISTENT_SERVICE_ADJ这种情况，当app的AndroidManifest.xml中添加了android:persistent="true"属性，并且app必须是系统内置app（必须内置/system/app下），满足这个必要条件的基础上，系统在开机时会自动创建app进程，并且进程的优先级是PERSISTENT_SERVICE_ADJ(-800)。当手动杀死进程时，系统还会自动重启进程，这在开发系统内置应用时，处理进程保活会很有效。

FOREGROUND_APP_ADJ， adj = 0

对应进程类型的前台进程，当app满足一下任意条件时，就属于adj = 0的情况：

• 它正在用户的互动屏幕上运行一个 Activity（其 onResume() 方法已被调用）。
• 它有一个 BroadcastReceiver 目前正在运行（其 BroadcastReceiver.onReceive() 方法正在执行）。
• 它有一个 Service 目前正在执行其某个回调（Service.onCreate()、Service.onStart() 或 Service.onDestroy()）中的代码。

VISIBLE_APP_ADJ, adj = 100

对应可见进程，但是不包含Service.startForeground()前台服务情况：

• 它正在运行的 Activity 在屏幕上对用户可见，但不在前台（其 onPause() 方法已被调用）。举例来说，如果前台 Activity 显示为一个对话框，而这个对话框允许在其后面看到上一个 Activity，则可能会出现这种情况。

PERCEPTIBLE_APP_ADJ, adj = 200

使用Service.startForeground()启动前台服务进程。

SERVICE_ADJ， adj = 500

对应服务进程：

• 这里说的服务进程是指Service是单独的进程，此进程中没有启动过Activity。
• 并且在30分钟内活跃过的服务进程。

HOME_APP_ADJ, adj = 600

Home进程，对应launcher属性的进程，类型为ACTIVITY_TYPE_HOME的应用。

PREVIOUS_APP_ADJ， adj = 700

用户使用的上一个进程（有activity没有finish），通常是用户两个app间切换时，被切换到后台的应用。

这里“上一个”的概念，不单只上一个使用app，如：用户从A应用切换到B应用，又从B应用切换到C应用，这时A应用可能是PREVIOUS_APP_ADJadj = 700。

CACHED_APP_MIN_ADJ， adj = 900

对应后台进程，app切换到后台：

• app通常包含用户当前不可见的一个或多个 Activity 实例（onStop() 方法已被调用并返回）。
• 通常是所有Activity都被finish。

其他的adj类型，大都是一些进程的特殊状态，不再详述了，这里在提一下SERVICE_B_ADJ。

SERVICE_B_ADJ， adj = 800

SERVICE_B_ADJ类型，可以理解成是SERVICE_ADJ状态的降级，当出现一些特殊情况，如资源不足Service进程可能会被降级成SERVICE_B_ADJ。

除此之外，对应同级别，同样adj值的进程，系统会优先回收占用内存高的app进程。

引用部分官方文档内容：

低内存终止守护进程

很多时候，kswapd 不能为系统释放足够的内存。在这种情况下，系统会使用 onTrimMemory() 通知应用内存不足，应该减少其分配量。如果这还不够，内核会开始终止进程以释放内存。它会使用低内存终止守护进程 (LMK) 来执行此操作。

LMK 使用一个名为 oom_adj_score 的“内存不足”分值来确定正在运行的进程的优先级，以此决定要终止的进程。最高得分的进程最先被终止。后台应用最先被终止，系统进程最后被终止。下表列出了从高到低的 LMK 评分类别。评分最高的类别，即第一行中的项目将最先被终止：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-W4JDh6zw-1656655501387)(https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a23bb013c6d744eaaa08f5e8f6feffbb~tplv-k3u1fbpfcp-zoom-in-crop-mark:1956:0:0:0.image)]

以下是上表中各种类别的说明：

• 后台应用：之前运行过且当前不处于活动状态的应用。LMK 将首先从具有最高 oom_adj_score 的应用开始终止后台应用。
• 上一个应用：最近用过的后台应用。上一个应用比后台应用具有更高的优先级（得分更低），因为相比某个后台应用，用户更有可能切换到上一个应用。
• 主屏幕应用：这是启动器应用。终止该应用会使壁纸消失。
• 服务：服务由应用启动，可能包括同步或上传到云端。
• 可觉察的应用：用户可通过某种方式察觉到的非前台应用，例如运行一个显示小界面的搜索进程或听音乐。
• 前台应用：当前正在使用的应用。终止前台应用看起来就像是应用崩溃了，可能会向用户提示设备出了问题。
• 持久性（服务）：这些是设备的核心服务，例如电话和 WLAN。
• 系统：系统进程。这些进程被终止后，手机可能看起来即将重新启动。
• 原生：系统使用的极低级别的进程（例如，kswapd）。

设备制造商可以更改 LMK 的行为。

更多关于ADJ详细的介绍和相关介绍，可以参考大佬的文章：《解读Android进程优先级ADJ算法》，讲解的特别详细了，膜拜大佬。。

从进程回收来看服务保活

了解了Android进程回收的机制和原理，对后台服务的保活也有一定的启发，简单来说就是尽可能的提高服务进程的adj级别：

• 特殊情况下可以通过android:persistent="true"属性将进程提升至PERSISTENT_SERVICE_ADJ(-800)级别，近乎无敌。当然了条件也是非常苛刻的：app必须内置为系统应用。
• 使用前台服务Service.startForeground(),将进程提升至PERCEPTIBLE_APP_ADJ(200)。
• UI进程与服务进程分离，当app切换到后台，未分离的Service进程（app进程）降级为CACHED_APP_MIN_ADJ(900),而进程分离的Service进程，始终保持为SERVICE_ADJ(500)。
• 内存优化，对应同级别，同样adj值的进程，系统会优先回收占用内存高的app进程。

小结

回到最开始的问题：Activity被系统回收了？只可能是因为整个app进程被系统回收吗？其实并不是，我们知道Android系统为每个app进程分配一个内存上限，当app使用内存，超过此上限时，就会发生OOM异常。针对此场景Android系统也制定了一些对Activity栈进行回收的机制，简单来说：

对于单栈（TaskRecord）应用，在前台的时候，所有界面都不会被回收，只有多栈情况下，系统才会回收不可见栈的Activity。

最后，如果大伙有什么好的学习方法或建议欢迎大家在评论中积极留言哈，希望大家能够共同学习、共同努力、共同进步。

小编在这里祝小伙伴们在未来的日子里都可以 升职加薪，当上总经理，出任CEO，迎娶白富美，走上人生巅峰！！

不论遇到什么困难，都不应该成为我们放弃的理由！

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习，需要一份小编整理出来的学习资料的关注我主页或者点击扫描下方二维码免费领取~

这里是关于我自己的Android 学习，面试文档，视频收集大整理，有兴趣的伙伴们可以看看~

如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言，一定会认真查询，修正不足，谢谢。