1.ADJ算法
1.1 ADJ级别
ADJ级别定义在com.android.server.am.ProcessList.java中，oom_adj划分为16级，分别如下所示（Android 11）
在Android
ADJ级别 | ProcessList ADJ取值 | oom_adj | 解释 |
UNKNOWN_ADJ | 1001 | 16 | 一般指将要会缓存进程，无法获取确定值 |
CACHED_APP_MAX_ADJ | 999 | 15 | 不可见进程的adj最大值 |
CACHED_APP_MIN_ADJ | 900 | 9 | 不可见进程的adj最小值 |
SERVICE_B_ADJ | 800 | 8 | B List中的Service(较老的，使用可能性更小) |
PREVIOUS_APP_ADJ | 700 | 7 | 上一个APP的进程（往往通过按返回键，或者两个APP之间的跳转） |
HOME_APP_ADJ | 600 | 6 | Home 进程 |
SERVICE_ADJ | 500 | 5 | 服务进程，此时进程不在前台或可见，但是有后台服务在运行 |
HEAVY_WEIGHT_APP_ADJ | 400 | 4 | 后台的重量级进程，system/rootdir/init.rc文件中设置 |
BACKUP_APP_ADJ | 300 | 3 | 备份进程 |
PERCEPTIBLE_LOW_APP_ADJ | 250 | NA | 比可感知进程优化级低，被杀后不易被感知 |
PERCEPTIBLE_APP_ADJ | 200 | 2 | 可感知进程。比如后台播放音乐 |
VISIBLE_APP_ADJ | 100 | 1 | 可见进程 |
FOREGROUND_APP_ADJ | 0 | 0 | 前台进程，前台进程和可见基本不可能被杀 |
PERSISTENT_SERVICE_ADJ | -700 | -11 | 关联着系统或persistent进程 |
PERSISTENT_PROC_ADJ | -800 | -12 | 系统persistent进程，比如telephony |
SYSTEM_ADJ | -900 | -16 | 系统进程 |
NATIVE_ADJ | -1000 | -17 | Native进程（不被系统管理） |
1.2 进程生命周期
Android系统将尽量长时间地保持应用进程，但为了新建进程或者运行更重要的进程，最终需要清除旧进程来回收内存。为了确定保留或者终止哪些进程，系统会根据正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中，系统会首先消除重要性最低的进程，然后但依此类推，以回收系统资源
进程的重要性，划分5级：
- 前台进程（Forgroud process）
- 可见进程（Visible process）
- 服务进程（Service process）
- 后台进程（Backgroud process）
- 空进程（Empty process）
前台进程的重要性最高，依次递减，空进程的重要性最低，下面分别来阐述每种级别的进程
1.2.1 Forground Process
用户当前操作所必需的进程，通常在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时运行这一万不得已的情况下，系统才会终止它们。
- 拥有用户正在交互的Activity(已经调用onResume())
- 拥有某个Service，后者绑定到用户正在交互的Activity
- 拥有正在“前台”运行的Service(服务已经调用startForeground())
- 拥有一个正执行一个生命周期回调的Service(onCreate()、onStart()、onDestory())
- 拥有正在执行onReceiver()方法的BroadcastReceiver
1.2.2 Visible Process
没有任何前台组件，但仍会影响用户在屏幕上所见内容的进程。可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止，否则系统不会终止这些进程。
- 拥有不在前台、但仍对用户可见的Activity(onPause())。
- 拥有绑定到可见（或前台）Activity的Service
1.2.3 Backgroud Process
后台进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。通常会有很多后台进程在运行，因些它们会保存在LRU列表中，以确保包含用户最近查看的Activity的进程最后一个被终止。如果某个Activity正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该Activity时，Activity会恢复其所有可见状态。
- 对用户不可见的Activity的进程（已调用Activity的onStop()方法）
- 对于什么样的Service状态会导致此时处于后台进程
1.2.4 Empty Process
保留这种进程的唯一目的是用作缓存，以缩短下次在其运动组件所需要的启动时间，为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。也称为Cached状态
- 不含有任何活动应用组件的进程
1.3 ProcessState
ProcessState定义在ActivityManager中android.app.ActivityManager.ProcessState
状态 | 状态值 | 说明 |
PROCESS_STATE_UNKNOWN | -1 | 不存在的进程 |
PROCESS_STATE_PERSISTENT | 0 | persistent系统进程 |
PROCESS_STATE_PERSISTENT_UI | 1 | persistent系统进程，并正在执行UI操作 |
PROCESS_STATE_TOP | 2 | 拥有当前用户可见的top Activity |
PROCESS_STATE_BOUND_TOP | 3 | 。 |
PROCESS_STATE_FOREGROUND_SERVICE | 4 | 。 |
PROCESS_STATE_BOUND_FOREGROUND_SERVICE | 5 | 。 |
PROCESS_STATE_IMPORTANT_FOREGROUND | 6 | 。 |
PROCESS_STATE_IMPORTANT_BACKGROUND | 7 | 。 |
PROCESS_STATE_TRANSIENT_BACKGROUND | 8 | . |
PROCESS_STATE_BACKUP | 9 | . |
PROCESS_STATE_SERVICE | 10 | . |
PROCESS_STATE_RECEIVER | 11 | . |
PROCESS_STATE_TOP_SLEEPING | 12 | . |
PROCESS_STATE_HEAVY_WEIGHT | 13 | 。 |
PROCESS_STATE_HOME | 14 | . |
PROCESS_STATE_LAST_ACTIVITY | 15 | . |
PROCESS_STATE_CACHED_ACTIVITY | 16 | 。 |
PROCESS_STATE_CACHED_ACTIVITY_CLIENT | 17 | 。 |
PROCESS_STATE_CACHED_RECENT | 18 | 。 |
PROCESS_STATE_CACHED_EMPTY | 19 | 。 |
1.2 如何查询应用当前adj值
1.2.1 通过cat命令查询
其实这种方式是通过查询linux的系统属性值来获取
- 首先
adb shell ps -ef | grep xxx查询到目标进程的进程号p（xxx 是进程名的关键字，以此来进行过滤） - 然后通过进程号以如下命令查询到adj级别``来获取当前的adj值
以运动健康（com.huawei.health）为例：
在前台时adj值为Foreground-0状态
在后台静置一段时间后，adj值变成了Cached状态(905)
1.2.2 通过dumpsys activity processes来查询进程
adb shell dumpsys activity processes com.xx.xx 查询curRaw值，此值即是oom_adj值
例如：com.huawei.health进程在前台时
2. 优化思路
从保活思路上来看，我们应该尽可能地将UI进程在退在后台后，将其的ADJ状态保持在尽可能小。如果adj值超过900，则在低内存场景，会-+优33200先被系统杀死，无法保活。（但是实际上这是一种流氓的开发思路，占用了非必要的内存资源）
从内存优化场景上或者说一种标准开发思路上来说，UI进程应该在退到后台后，尽可能地将Service unbind或者stop以及其他的一些优化思路。将进程优先级切换在Cached状态(>=900).
