深入AMS源码（三）——ActivityManagerService的内存管理

1、简介

AMS对内存管理

当应用程序关闭后，后台对应的进程并没有真正的退出进程只是处于sleep状态，以便下次启动能快速启动，即关闭而不退出；
当系统内存不足时，AMS会回调相应的应用程序通知释放内存；
当系统内存不足时，AMS主动根据一定的优先规则退出优先级较低的进程；

程序关闭而不退出

程序在退出之后不会关闭进程，当应用二次启动时如果进程还在则直接使用，此处可能存在的疑问就是进程持续存在是否影响系统的执行？事实上只是当前进程处于sleep（）状态，此时只占用物理内存并不会影响前台程序使用速度，我们在启动在进程后会初始化Looper对象，Looper会循环获取消息事件，当程序关闭后消息事件为空，则进程进入sleep状态，一般来说此时100个休眠进程内不会影响运行速度，当发声用户交互、定时器中断、Binder消息时会想主线程发送消息唤醒next（）方法获取事件然后执行事件处理；

所有关于Android 中的OOM机制和Android对进程的处理放在后一篇文章中分析，本篇主要分析下Android内部如何管理内存机制；

2、内存回收流程

内存释放地点

在AMS中当系统内存低时，按照回收优先级释放对应进程
OOM Killer 在内存紧张时会按照优先级杀死进程
在应用程序中，当AMS任务进程需要杀死时，会先回调scheduleLowMemory（）方法，通知目标进程释放内存；

IdleHandler回收内存机制

由前面的学习知道，在Activity启动完成后回调ActivityThread.handleResumeActivity（），在方法的最后一句发送了一个Idler事件，此Idler事件会触发内存回收机制

Looper.myQueue().addIdleHandler(new Idler()); // 添加Idler事件

private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>(); // IdlerHandler集合
public void addIdleHandler(@NonNull IdleHandler handler) {
    synchronized (this) {
        mIdleHandlers.add(handler); // 保存设置的Idler对象
    }
}

调用MesssageQueue中的addIdleHandler（）添加Idler事件，在MesssageQueue中会将所有的Idler事件都保存在mIdleHandlers的集合中，关于Idler事件的执行放在后面分析，现在一起看一下Idler类，Idler是ActivityThread的内部类，它实现了IdleHandler接口重写queueIdle（），除此之外还有GcIdler类，在添加了Idler事件后，在从MessageQueue中获取next（）时，会遍历mIdleHandlers集合中的事件，获取事件后调用queueIdle（）执行事件

public static interface IdleHandler {
    boolean queueIdle();
}
private class Idler implements MessageQueue.IdleHandler {
    @Override
    public final boolean queueIdle() {
       IActivityManager am = ActivityManager.getService();
       am.activityIdle(a.token, a.createdConfig, stopProfiling); // 执行activityIdle（），调用activityIdleInternal（）
       return false;
    }
}

在Idler的queueIdle（）方法中，首先获取AMS对象然后调用其activityIdle（）方法，这里执行到ActivityManagerService中

AMS.activityIdle（）

public final void activityIdle(IBinder token, Configuration config) {
final long origId = Binder.clearCallingIdentity();
synchronized (this) {
    ActivityStack stack = ActivityRecord.getStackLocked(token);
    if (stack != null) {
        ActivityRecord r = mStackSupervisor.activityIdleInternalLocked(token, false /* fromTimeout */,
                        false /* processPausingActivities */, config); 
    }
}
    Binder.restoreCallingIdentity(origId);
}

在AMS.activityIdle（）中先获取ActivityStack对象后，调用mStackSupervisor.activityIdleInternalLocked（）方法，本段分析先暂停在这里，之后再分析activityIdleInternalLocked（）中如何回收内存；

AMS中除了上面Idler事件之外，还有一个条件会触发内存回收，在前面的学习知道在执行前一个Activity的onPause（）结束后，会回调AMS的completePausedLocked（），在completePausedLocked（）中会将Pause的活动添加到mStoppingActivities集合中，此时会判断当处于stopping的Activity数超过3个时会发送IDLE_NOW_MSG消息处理内存，处理消息同样执行activityIdleInternal（）

void addToStopping(ActivityRecord r, boolean scheduleIdle, boolean idleDelayed) {
if (!mStackSupervisor.mStoppingActivities.contains(r)) { // 加入停止活动集合
    mStackSupervisor.mStoppingActivities.add(r);
}
boolean forceIdle = mStackSupervisor.mStoppingActivities.size() > MAX_STOPPING_TO_FORCE
        || (r.frontOfTask && mTaskHistory.size() <= 1);
if (scheduleIdle || forceIdle) {
    if (!idleDelayed) {
        mStackSupervisor.scheduleIdleLocked();  //数量大于3发送IDLE事件执行内存回收，销毁Stop集合中的Activity
    } else {
        mStackSupervisor.scheduleIdleTimeoutLocked(r);
    }
} else {
    checkReadyForSleep();
}
}

void scheduleIdleTimeoutLocked(ActivityRecord next) {
    Message msg = mHandler.obtainMessage(IDLE_TIMEOUT_MSG, next);
    mHandler.sendMessageDelayed(msg, IDLE_TIMEOUT);
}
final void scheduleIdleLocked() {
    mHandler.sendEmptyMessage(IDLE_NOW_MSG);
}

scheduleIdleTimeoutLocked（）和scheduleIdleLocked()都只是发送Handler事件，在处理相应的事件时都会调用activityIdleInternal（）方法，在activityIdleInternal中直接调用activityIdleInternalLocked（）；

// scheduleIdleLocked（）发送Handler事件，执行事件的回收

case IDLE_TIMEOUT_MSG: {
    activityIdleInternal((ActivityRecord) msg.obj,
            true /* processPausingActivities */);
} break;
case IDLE_NOW_MSG: {
    activityIdleInternal((ActivityRecord) msg.obj,
            false /* processPausingActivities */);
} break;

activityIdleInternalLocked（）：由上面的分析可知当两种情况出发Idler事件后，程序都会调用activityIdleInternal（）方法，所有的内存处理会在此方法中进行；

final void activityIdleInternalLocked(IBinder token, boolean fromTimeout,Configuration config) {
ArrayList<ActivityRecord> stops = null;  // 保存ActivityRecord集合
ArrayList<ActivityRecord> finishes = null;
if (token != null) {
   mHandler.removeMessages(IDLE_TIMEOUT_MSG, token); // 移除超时消息，避免多次重复执行
}
int index = indexOfTokenLocked(token);
ActivityRecord r = (ActivityRecord)mHistory.get(index); // 获取当前token对应的ActivityRecord
r.idle = true;
mService.scheduleAppGcsLocked(); // 1、发送Handler事件执行客户端的内存回收
stops = processStoppingActivitiesLocked(true); // 2、将mStoppingActivity集合保存到stops，清空mStoppingActivity集合
if ((NF=mFinishingActivities.size()) > 0) {
finishes = new ArrayList<ActivityRecord>(mFinishingActivities); // 3、将mFinishingActivity保存到finishes集合中
mFinishingActivities.clear(); // 清空集合
}
            for (i=0; i<NS; i++) {
2807            ActivityRecord r = (ActivityRecord)stops.get(i); 
2808            synchronized (mService) {
2809                if (r.finishing) {
2810                    finishCurrentActivityLocked(r, FINISH_IMMEDIATELY); // 对与finish=true的，直接结束Activity
2811                } else {
2812                    stopActivityLocked(r); // 4、执行stopping集合中Activity的onStop（）
2813                }
2814            }
2815        }
2819        for (i=0; i<NF; i++) {
2820            ActivityRecord r = (ActivityRecord)finishes.get(i);
2821            synchronized (mService) {
2822                destroyActivityLocked(r, true);// 5、直接destroy（） 所有的Finishing的Activity
2823            }
2824        }
}
 mService.trimApplications(); // 6、执行真正的内存回收或杀死进程

在activityIdleInternalLocked（）中主要执行以下操作：

发送Handler事件执行客户端的内存回收
将mStoppingActivity集合保存到stops并清空mStoppingActivity集合
将mFinishingActivity保存到finishes集合中，清空mFinishingActivities集合
执行stopping集合中Activity的onStop（）方法
直接destroy（）所有的Finishing的Activity
调用trimApplications（）执行真正的内存回收或杀死进程

2.1、应用程序的内存回收

AMS会调用scheduleAppGcLocked（）方法通知客户端释放内存

 final void scheduleAppGcLocked(ProcessRecord app) {
11917        long now = SystemClock.uptimeMillis();
11918        if ((app.lastRequestedGc+GC_MIN_INTERVAL) > now) { // 1判断上次执行GC时间和现在时间慢不满足最小GC时间间隔
11919            return;
11920        }
11921        if (!mProcessesToGc.contains(app)) {
11922            addProcessToGcListLocked(app); // 2、
11923            scheduleAppGcsLocked(); // 3、
11924        }
11925    }

在scheduleAppGcLocked（）中首先获取上一次执行GC的时间和当前时间，计算是否满足最小GC时间间隔，如果不满足则直接return，然后将app进程添加到将要执行GC的 mProcessToGC集合中保存，发送延时信息，通知进程执行GC

addProcessToGcListLocked（）：插入要GC的进程到mProcessToGc集合

final void addProcessToGcListLocked(ProcessRecord proc) {
11897        boolean added = false;
11898        for (int i=mProcessesToGc.size()-1; i>=0; i--) {
11899            if (mProcessesToGc.get(i).lastRequestedGc < // 适当的位置
11900                    proc.lastRequestedGc) {
11901                added = true;
11902                mProcessesToGc.add(i+1, proc);
11903                break;
11904            }
11905        }
11906        if (!added) {
11907            mProcessesToGc.add(0, proc); // 如果都没有，直接插在第一个位置
11908        }
11909    }

在addProcessToGcListLocked（）中按照mProcessToGc中每个app上次GC的时间排序，将app进程插入到集合中，如果此时集合中没有对象则直接保存数据；

scheduleAppGcsLocked（）：发送延时消息通知AMS执行GC

final void scheduleAppGcsLocked() {
11875        mHandler.removeMessages(GC_BACKGROUND_PROCESSES_MSG); // 移除之前的消息事件
11876
11877        if (mProcessesToGc.size() > 0) {
11879            ProcessRecord proc = mProcessesToGc.get(0); //从mProcessToGc中去除第一个进程proc
11880            Message msg = mHandler.obtainMessage(GC_BACKGROUND_PROCESSES_MSG);
11881
11882            long when = mProcessesToGc.get(0).lastRequestedGc + GC_MIN_INTERVAL; // 设置延迟发送时间
11883            long now = SystemClock.uptimeMillis();
11884            if (when < (now+GC_TIMEOUT)) {
11885                when = now + GC_TIMEOUT; // 计算或修正时间
11886            }
11887            mHandler.sendMessageAtTime(msg, when); // 发送请求GC的消息
11888        }
11889    }

在scheduleAppGcsLocked（）中从mProcessesToGc集合中取出第一个进程，计算并设置发送事件的时间最后发送事件，在Handler接收到事件后调用performAppGcsIfAppropriateLocked（）方法处理事件；

performAppGcsIfAppropriateLocked（）：Handler在收到MSG消息后调用此方法

final void performAppGcsIfAppropriateLocked() {
11863        if (canGcNowLocked()) { // 判断当前是否适合执行GC操作
11864            performAppGcsLocked(); // 执行GC
11865            return;
11866        }
11868        scheduleAppGcsLocked(); //在不适合的情况下，再次发送延时消息
11869    }

private final boolean canGcNowLocked() {
11820        return mParallelBroadcasts.size() == 0 // 判断当前是否有正在执行的广播
11821                && mOrderedBroadcasts.size() == 0
                     // 判断是否处于sleep状态或具有正在交互的Activity且Activity处于idle状态
11822                && (mSleeping || (mMainStack.mResumedActivity != null && mMainStack.mResumedActivity.idle));
11824    }

在performAppGcsIfAppropriateLocked（）中首先判断当前是否适合执行GC操作，主要检查是否有正在发送的广播、进程是否处于sleep、是否有正在交互的活动等，对于不能直接执行GC的继续发送延时事件，对于可执行的调用performAppGcsLocked（）

performAppGcsLocked（）

       final void performAppGcsLocked() {
11831        final int N = mProcessesToGc.size();
11835        if (canGcNowLocked()) {
11836            while (mProcessesToGc.size() > 0) { // 循环便利mProcessToGc集合中的每个进程
11837                ProcessRecord proc = mProcessesToGc.remove(0);
11838                if (proc.curRawAdj > PERCEPTIBLE_APP_ADJ || proc.reportLowMemory) { // 执行条件
11839                    if ((proc.lastRequestedGc+GC_MIN_INTERVAL) <= SystemClock.uptimeMillis()) { // 执行时间
11843                        performAppGcLocked(proc); // 执行回收内存
11844                        scheduleAppGcsLocked(); //再次发送延迟事件，每次只处理一个进程
11845                        return; // 直接return
11846                    } else {
11849                        addProcessToGcListLocked(proc);
11850                        break;
11851                    }
11852                }
11853            }
11855            scheduleAppGcsLocked(); // 发送延迟事件
11856        }
11857    }

在performAppGcsLocked（）中主要从mProcessesToGc集合中取出第一个进程，然后调用performAppGcLocked（）执行内存回收操作，在操作完成后再次发送延时事件，从这里可以看出GC操作每次只执行一个进程，且执行一次后会延时到下一次执行；

    final void performAppGcLocked(ProcessRecord app) {
11801        try {
11802            app.lastRequestedGc = SystemClock.uptimeMillis(); // 保存本次执行GC的时间
11803            if (app.thread != null) {
11804                if (app.reportLowMemory) { //低内存状态
11805                    app.reportLowMemory = false;
11806                    app.thread.scheduleLowMemory();  // 内存低导致内存释放
11807                } else {
11808                    app.thread.processInBackground();  //处理背景模式释放Binder内存
11809                }
11810            }
11811        } 
11814    }

在performAppGcLocked（）中首先保存当前GC的时间，然后回调ApplicaitonThread的scheduleLowMemory（）方法，同样方法会执行到ActivityThread.scheduleLowMemory（）中，scheduleLowMemory中调用Handler发送LOW_MEMORY消息，Handler收到信息后执行handleLowMemory();

     final void handleLowMemory() {
3097        ArrayList<ComponentCallbacks> callbacks  = new ArrayList<ComponentCallbacks>();
3099
3100        synchronized (mPackages) {
               // 从mActivites集合中查找没有Finfish和Paused的Activity、Service、Provider、Application等
3101            callbacks = collectComponentCallbacksLocked(true, null);
3102        }
3103
3104        final int N = callbacks.size();
3105        for (int i=0; i<N; i++) {
3106            callbacks.get(i).onLowMemory(); // 回到所有Activity的onLowMemory（）
3107        }
3110        if (Process.myUid() != Process.SYSTEM_UID) {
3111            int sqliteReleased = SQLiteDatabase.releaseMemory(); // 释放SQLite内存
3113        }
3116        Canvas.freeCaches(); // 释放Canvas
            Canvas.freeTextLayoutCaches(); // 布局引擎释放内存
3118        BinderInternal.forceGc("mem”); // 释放Binder
3119    }

在handleLowMemory（）中主要执行以下几个内存释放操作：

查找所有的没有finish和pause的Activity对象，并调用其onLowMemory（）通知释放内存
调用SQLiteDatabase.releaseMemory()释放数据库内存
释放Canvas内存和布局引擎内存
调用BinderInternal中方法释放Binder内存

2.2、Activity的onStop（）

for (int i = 0; i < NS; i++) {
            r = stops.get(i);
            final ActivityStack stack = r.getStack();
            if (stack != null) {
                if (r.finishing) {
                    stack.finishCurrentActivityLocked(r, ActivityStack.FINISH_IMMEDIATELY, false,
                            "activityIdleInternalLocked");
                } else {
                    stack.stopActivityLocked(r);
                }
            }
        }

在处理mStopping集合中保存的活动时，此时活动都处于Paused状态，在获取到ActivityRecord之后会判断其finishing属性，finishing为true表示需要销毁此对象，然后调用ActivityStack.finishCurrentActivityLocked()，对于不想销毁的执行ActivityStack.stopActivityLocked()方法；

finishCurrentActivityLocked（）

// 删除集合中的此Record信息
mStackSupervisor.mStoppingActivities.remove(r);
mStackSupervisor.mGoingToSleepActivities.remove(r);
mStackSupervisor.mActivitiesWaitingForVisibleActivity.remove(r);

if (mode == FINISH_IMMEDIATELY
                || (prevState == PAUSED
                    && (mode == FINISH_AFTER_PAUSE || inPinnedWindowingMode()))
                || finishingActivityInNonFocusedStack
                || prevState == STOPPING
                || prevState == STOPPED
                || prevState == ActivityState.INITIALIZING) {
            r.makeFinishingLocked();
            boolean activityRemoved = destroyActivityLocked(r, true, "finish-imm:" + reason);
  if (finishingActivityInNonFocusedStack) {
                mStackSupervisor.ensureVisibilityAndConfig(next, mDisplayId,
                        false /* markFrozenIfConfigChanged */, true /* deferResume */);
            }
            if (activityRemoved) {
                mStackSupervisor.resumeFocusedStackTopActivityLocked();
            }
            return activityRemoved ? null : r;
        }

在finishCurrentActivityLocked（）中首先从保存信息的集合中移除信息面，因为此活动即将被销毁，然后判断当前活动的状态并调用ActivityRecord.makeFinishingLocked()，最后调用destroyActivityLocked（）销毁Activity，关于destroyActivityLocked（）放在之后分析，在销毁活动之后又调用resumeFocusedStackTopActivityLocked（）方法显示栈顶的活动；

stopActivityLocked（）

if (!r.visible) {
                    r.setVisible(false);
                }

 adjustFocusedActivityStack(r, "stopActivity"); //1
 //2
  mService.getLifecycleManager().scheduleTransaction(r.app.thread, r.appToken,
                        StopActivityItem.obtain(r.visible, r.configChangeFlags));
                        //3
                Message msg = mHandler.obtainMessage(STOP_TIMEOUT_MSG, r);
                mHandler.sendMessageDelayed(msg, STOP_TIMEOUT);

在stopActivityLocked（）中主要执行三件事：

首先根据要stop的活动调整ActivityStack和当前交互的任务栈
使用LifecycleManager执行StopActivityItem，在StopActivityItem中会通过ActivityThread类调用Activity的onStop（）
发送Handler事件，防止stop事件超时

2.3、Activity的Finish（）

for (int i = 0; i < NF; i++) {
            r = finishes.get(i);
            final ActivityStack stack = r.getStack();
            if (stack != null) {
                activityRemoved |= stack.destroyActivityLocked(r, true, "finish-idle");
            }
        }

destroyActivityLocked（）

cleanUpActivityLocked(r, false, false);

 final boolean hadApp = r.app != null; // 1、
if (hadApp) {
r.app.activities.remove(r); //2、
 mService.getLifecycleManager().scheduleTransaction(r.app.thread, r.appToken,
                        DestroyActivityItem.obtain(r.finishing, r.configChangeFlags)); //3、
 Message msg = mHandler.obtainMessage(DESTROY_TIMEOUT_MSG, r); //4、
                mHandler.sendMessageDelayed(msg, DESTROY_TIMEOUT);
}else {
            if (r.finishing) {
                removeActivityFromHistoryLocked(r, reason + " hadNoApp");
                removedFromHistory = true; //5、
            } else {
                r.setState(DESTROYED, "destroyActivityLocked. not finishing and had no app"); //6、
                r.app = null;
            }
        }
if (!mLRUActivities.remove(r) && hadApp) {  //7、
            Slog.w(TAG, "Activity " + r + " being finished, but not in LRU list");
        }

在destroyActivityLocked（）中执行：

调用cleanUpActivityLocked清除集合中保存的Activity数据
判断当前Activity是否存在进程信息，从activities中清除ActivityRecord
使用LifecycleManager执行Activity的onDestory（）
对于不包含进程信息的，则直接从历史记录中删除信息，并设置State为DESTORYED，
从mLRUActivities集合中清除Activity信息，之后activity就完整的删除了；

总结以下：在AMS对Activity调度管理中包含着对程序内存的处理，在resume完目标Activity后即表示活动已经启动完毕，之后会添加内存回收相关的Idler事件，在事件执行时会触发Activity的低内存状态，通知应用程序释放内存，客户端在收到消息后会释放程序内存、数据库内存、Binder内存等，在处理内存之后AMS会对目前Stopping和finishing中的活动，执行对应的stop（）和finish（）方法；

深入AMS源码（三）——ActivityManagerService的内存管理

1、简介

2、内存回收流程

2.1、应用程序的内存回收

2.2、Activity的onStop（）

2.3、Activity的Finish（）

[oeasy]python020在游戏中体验数值自由_勇闯地下城_终端文字游戏

docker启动hub和Chrome node

Android插件化——深入理解Context機制

Android進階知識樹——理解系統服務WindowManagerService

Androdi熱修復之路 ——熱修復框架Tinker 源碼分析

Android框架源碼分析——Glide源碼分析

Android框架源碼分析——Retrofit源碼分析

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結