057 组件化的Android

TODO：快速介绍 时间Android组件的主要支撑。

在未知森林里的有知涯上的一棵大树下，兔子在和松鼠小弟对话：

兔子有板有眼的说：

Android中一切都是组件, 程序是由组件组成，比如四大组件：Activity Service BroadcastReceiver ContentProvider 。

松鼠：

是这样啊， 那么俺有几个问题，关于组件：

1. 谁来负责组件的启动和关闭？
2. 谁来维护组件的状态？
3. 谁来管理组件运行时所需要的进程？
4. 组件之间如何进行通信？

兔子说： “这个问题问的好。Android系统中，构建了有以下的几个模块来支持解决这个问题：

1. ActivityManager Service
2. Binder
3. LowMemory Killer

松鼠说： “这三个呀，他们分别是有什么功能呢？”

兔子说： “这个我略知一二，我试着来为君解析之！”

•ActivityManager Service

简称AMS，负责启动组件，关闭组件，维护组件的状态，运行环境进程的管理等。

1. 启动组件： 组件启动时，检查环境，即其所要运行在的进程是否已创建。如果已经创建，就直接通知它加载组件。否则，先将该进程创建起来，再通知它加载组件。
2. 关闭组件： 组件关闭时，其所运行在的进程无需关闭，这样就可以让组件重新打开时得到快速启动。
3. 维护组件状态： 维护组件在运行过程的状态，这样组件就可以在其所运行在的进程被回收的情况下仍然继续生存。
4. 进程管理 在适当的时候主动回收空进程和后台进程，以及通知进程自己进行内存回收

说明：

1. 组件的UID和Process Name唯一决定了其所要运行在的进程。
2. 每次组件onStop时，都会将自己的状态传递给AMS维护。
3. AMS在以下四种情况下会调用trimApplications来主动回收进程： A. activityStopped B. setProcessLimit C. unregisterReceiver D. finishReceiver
4. WMS也会主动回收进程：

WindowManagerService在处理窗口的过程中发生OutOf Memroy时，会调reclaimSomeSurfaceMemoryLocked来回收某些Surface占用的内存，reclaimSomeSurfaceMemoryLocked的逻辑如下所示：

(1).首先检查有没有泄漏的Surface，即那些Session已经不存在但是还没有销毁的Surface，以及那些宿主Activity已经不可见但是还没有销毁的Surface。如果存在的话，就将它们销毁即可，不用KillPids。

(2).如果不存在没有泄漏的Surface，那么那些存在Surface的进程都有可能被杀掉，这是通过KillPids来实现的。

KillPids：

(1). 找中候选进程的最大oom_adj值。

(2). 如果找到的最大oom_adj值恰好位于[ProcessList.HIDDEN_APP_MIN_ADJ(9),ProcessList.HIDDEN_APP_MAX_ADJ(15)]之间，那么就将最大oom_adj值修改为ProcessList.HIDDEN_APP_MIN_ADJ，表示要将所有后台进程都杀掉。

(3). 如果此时杀进程是不安全的，并且找到的最大oom_adj值比ProcessList.SERVICE_ADJ还要小，那么就将将最大oom_adj值设置为ProcessList.SERVICE_ADJ，避免重要进程被杀掉。

(4). oom_adj值大于等于前面找到的最大oom_adj值的候选进程都将被杀掉。

trimApplications:

(1). 杀掉Package已经被Remove了的进程，属于无用进程

(2). 调用updateOomAdjLocked更新所有进程的oom_adj

updateOomAdjLocked-- all：

(1). 根据进程运行状态来更新进程的oom_adj。更新顺序是从最近使用到最近不使用的。如果一个进程是后台进程，那么按照这个顺序进行更新，就意味着最近越是不使用的后台进程，它获得的oom_adj值就越大。后台进程(以及空进程)的oom_adj取值范围[ProcessList.HIDDEN_APP_MIN_ADJ(9),ProcessList.HIDDEN_APP_MAX_ADJ(15)]

(2)，如果空进程超过限制，那么最近越是不使用的空进程，就越会被杀掉。

(3). 如果后台进程超过限制，那么最近越是不使用的后台进程，就越会被杀掉。

(4). 通知进程ScheduleTrimMemory。

updateOomAdjLocked-- single：

(1). 调用computeOomAdjLocked计算oom_adj。

(2). 计算oom_adj之后，如果ShchedGroup发生改变，并且变成了THREAD_GROUP_BG_NONINTERACTIVE调度组，那么进程就会被杀掉。

computeOomAdjLocked：

(1). ProcessList.FOREGROUND_APP_ADJ(0):前台进程、有InstrumentionClass的进程、正在接收广播的进程、正在执行ServiceCallback的进程、正在运行有外部依赖的ContentProvider的进程

(2). ProcessList.VISIBLE_APP_ADJ(1):有Activity是Visible的进程

(3). ProcessList.PERCEPTIBLE_APP_ADJ(2)：有Activity是Pausing、Paused或者Stopping状态的进程、有Service被设置为Foreground的进程、被设置为Foreground的进程。

(4). ProcessList.HEAVY_WEIGHT_APP_ADJ(3)：被设置为重量级App的进程。

(5). ProcessList.BACKUP_ADJ(4)：正在执行备份任务的进程。

(6). ProcessList.SERVICE_ADJ(5)：最近有活动的Service的进程。

(7). ProcessList.HOME_APP_ADJ(6)：HomeApp进程。

(8). ProcessList.PREVIOUS_APP_ADJ(7)：前一个显示UI的进程。

(9). ProcessList.SERVICE_B_ADJ(8)：oom_adj值等于ProcessList.SERVICE_ADJ的进程超过限制时，最近越是不使用的进程的oom_adj值就会由ProcessList.SERVICE_ADJ变成ProcessList.SERVICE_B_ADJ。

PS：

(1). 如果一个进程运行有绑定至另外一个进程（Client）的ContentProvider或者Service，并且client进程的oom_adj值比该进程的oom_adj小，那么该进程的oom_adj值就会被设置为client进程的oom_adj值，但是不能超过ProcessList.FOREGROUND_APP_ADJ。

(2). ProcessList.PERSISTENT_PROC_ADJ(-12)：被设置为persistent的进程，如PhoneApp，不参与oom_adj更新计算。

(3). ProcessList.SYSTEM_ADJ(-16)：System进程，不参与oom_adj更新计算。

•Binder

为组件间通信提供支持。 可用于进程间和进程内

是十分高效的IPC机制

1. 进程间的组件通信时，通信数据只需一次拷贝
2. 进程内的组件通信时，跳过IPC进行直接的通信

•LowMemory Killer

–内存紧张时回收进程

•由于组件与进程是剥离的，因此进程回收不会影响组件的生命周期

–从低优先级进程开始回收

•EmptyProcess

•HiddenProcess

•PerceptibleProcess

•VisibleProcess

•ForegroundProcess

1.每一个APP进程都有一个oom_adj值，该值是根据进程所运行的组件计算出来的，值越小，优先级就越级。

2.Init和System Server进程的oom_adj等于-16，是最高的，保证不会被杀死。

3.PhoneApp具有persist属性，它的oom_adj被设置为-12，也能保证不会被杀死。

4.可以通过/proc/<pid>oom_adj文件查看进程的oom_adj值。

5.在Linux内核中，子进程的oom_adj值等于父进程的oom_adj，也就是说，Android里面的Native进程的oom_adj值与fork它的进程的oom_adj值一样。

命令行查看工具 dumpsys activity