Android后台Kill(二)：ActivityManagerService与App现场恢复机制

最新推荐文章于 2024-07-02 17:04:10 发布

Android进阶之路

最新推荐文章于 2024-07-02 17:04:10 发布

阅读量1.1k

点赞数

文章标签： ActivityManagerService Android

本文链接：https://blog.csdn.net/weixin_45136073/article/details/93047054

版权

本文深入探讨了Android系统如何在后台进程被杀死后恢复App的现场，详细讲解了ActivityManagerService（AMS）如何判断App被杀死以及恢复的流程。通过分析AMS如何处理被杀死的App、App存活但Activity被杀死的恢复逻辑，以及场景保存和恢复的方法，揭示了Android后台杀死恢复的核心原理。同时，文中还提到了开发者如何应对后台杀死的问题，并分享了个人的Android进阶学习资料获取方式。

摘要由CSDN通过智能技术生成

本篇是Android后台杀死系列的第二篇，主要讲解ActivityMangerService是如何恢复被后台杀死的进程的（基于4.3 ），在开篇 FragmentActivity及PhoneWindow后台杀死处理机制中，简述了后台杀死所引起的一些常见问题，还有Android系统控件对后台杀死所做的一些兼容，以及onSaveInstance跟onRestoreInstance的作用于执行时机，最后说了如何应对后台杀死，但是对于被后台杀死的进程如何恢复的并没有讲解，本篇不涉及后台杀死，比如LowmemoryKiller机制，只讲述被杀死的进程如何恢复的。假设，一个应用被后台杀死，再次从最近的任务列表唤起App时候，系统是如何处理的呢？有这么几个问题可能需要解决：

Android框架层（AMS）如何知道App被杀死了
App被杀前的场景是如何保存的
系统（AMS）如何恢复被杀的App
被后台杀死的App的启动流程跟普通的启动有什么区别
Activity的恢复顺序为什么是倒序恢复

系统（AMS）如何知道App被杀死了

首先来看第一个问题，系统如何知道Application被杀死了，Android使用了Linux的oomKiller机制，只是简单的做了个变种，采用分等级的LowmemoryKiller，但这个其实是内核层面的，LowmemoryKiller杀死进程后，不会像用户空间发送通知，也就是说框架层的ActivityMangerService无法知道App是否被杀死，但是，只有知道App或者Activity是否被杀死，AMS（ActivityMangerService）才能正确的走唤起流程，那么AMS究竟是在什么时候知道App或者Activity被后台杀死了呢？我们先看一下从最近的任务列表进行唤起的时候，究竟发生了什么。

从最近的任务列表或者Icon再次唤起App的流程

在系统源码systemUi的包里，有个RecentActivity，这个其实就是最近的任务列表的入口，而其呈现界面是通过RecentsPanelView来展现的，点击最近的App其执行代码如下：

public void handleOnClick(View view) {
   
    ViewHolder holder = (ViewHolder)view.getTag();
    TaskDescription ad = holder.taskDescription;
    final Context context = view.getContext();
    final ActivityManager am = (ActivityManager)
            context.getSystemService(Context.ACTIVITY_SERVICE);
    Bitmap bm = holder.thumbnailViewImageBitmap;
    ...
    // 关键点 1  如果TaskDescription没有被主动关闭，正常关闭，ad.taskId就是>=0
    if (ad.taskId >= 0) {
   
        // This is an active task; it should just go to the foreground.
        am.moveTaskToFront(ad.taskId, ActivityManager.MOVE_TASK_WITH_HOME,
                opts);
    } else {
   
        Intent intent = ad.intent;
        intent.addFlags(Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY
                | Intent.FLAG_ACTIVITY_TASK_ON_HOME
                | Intent.FLAG_ACTIVITY_NEW_TASK);
        try {
   
            context.startActivityAsUser(intent, opts,
                    new UserHandle(UserHandle.USER_CURRENT));
        }...
}

在上面的代码里面，有个判断ad.taskId >= 0，如果满足这个条件，就通过moveTaskToFront唤起APP，那么ad.taskId是如何获取的？recent包里面有各类RecentTasksLoader，这个类就是用来加载最近任务列表的一个Loader，看一下它的源码，主要看一下加载：

 @Override
        protected Void doInBackground(Void... params) {
   
            // We load in two stages: first, we update progress with just the first screenful
            // of items. Then, we update with the rest of the items
            final int origPri = Process.getThreadPriority(Process.myTid());
            Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
            final PackageManager pm = mContext.getPackageManager();
            final ActivityManager am = (ActivityManager)
            mContext.getSystemService(Context.ACTIVITY_SERVICE);

            final List<ActivityManager.RecentTaskInfo> recentTasks =
                    am.getRecentTasks(MAX_TASKS, ActivityManager.RECENT_IGNORE_UNAVAILABLE);

            ....
                TaskDescription item = createTaskDescription(recentInfo.id,
                        recentInfo.persistentId, recentInfo.baseIntent,
                        recentInfo.origActivity, recentInfo.description);
            ....
            }

可以看到，其实就是通过ActivityManger的getRecentTasks向AMS请求最近的任务信息，然后通过createTaskDescription创建TaskDescription，这里传递的recentInfo.id其实就是TaskDescription的taskId，来看一下它的意义：

public List<ActivityManager.RecentTaskInfo> getRecentTasks(int maxNum,
        int flags, int userId) {
   
        ...           
        IPackageManager pm = AppGlobals.getPackageManager();

        final int N = mRecentTasks.size();
        ...
        for (int i=0; i<N && maxNum > 0; i++) {
   
            TaskRecord tr = mRecentTasks.get(i);
            if (i == 0
                    || ((flags&ActivityManager.RECENT_WITH_EXCLUDED) != 0)
                    || (tr.intent == null)
                    || ((tr.intent.getFlags()
                            &Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS) == 0)) {
   
                ActivityManager.RecentTaskInfo rti
                        = new ActivityManager.RecentTaskInfo();
                rti.id = tr.numActivities > 0 ? tr.taskId : -1;
                rti.persistentId = tr.taskId;
                rti.baseIntent = new Intent(
                        tr.intent != null ? tr.intent : tr.affinityIntent);
                if (!detailed) {
   
                    rti.baseIntent.replaceExtras((Bundle)null);
                }

可以看出RecentTaskInfo的id是由TaskRecord决定的，如果TaskRecord中numActivities > 0就去TaskRecord的Id，否则就取-1，这里的numActivities其实就是TaskRecode中记录的ActivityRecord的数目，更具体的细节可以自行查看ActivityManagerService及ActivityStack，那么这里就容易解释了，只要是存活的APP、或者被LowmemoryKiller杀死的APP，其AMS的ActivityRecord是完整保存的，这就是恢复的依据。RecentActivity获取的数据其实就是AMS中的翻版，RecentActivity并不知道将要唤起的APP是否是存活的，只要TaskRecord告诉RecentActivity是存货的，那么久直接走唤起流程，也就是通过ActivityManager的moveTaskToFront唤起App，至于后续的工作，就完全交给AMS来处理。现看一下到这里的流程图：

整个APP被后台杀死的情况下AMS是如何恢复现场的

AMS与客户端的通信是通过Binder来进行的，并且通信是”全双工“的，且互为客户端跟服务器，也就说AMS向客户端发命令的时候，AMS是客户端，反之亦然。注意 Binder有个讣告的功能的：如果基于Binder通信的服务端（S）如果挂掉了，客户端（C）能够收到Binder驱动发送的一份讣告，告知客户端Binder服务挂了，可以把Binder驱动看作是第三方不死邮政机构，专门向客户端发偶像死亡通知。对于APP被异常杀死的情况下，这份讣告是发送给AMS的，AMS在收到通知后，就会针对APP被异常杀死的情况作出整理，这里牵扯到Binder驱动的代码有兴趣可以自己翻一下。之类直接冲讣告接受后端处理逻辑来分析,在AMS源码中，入口其实就是appDiedLocked.

final void appDiedLocked(ProcessRecord app, int pid,
            IApplicationThread thread) {
   
              ...
            if (app.pid == pid && app.thread != null &&
                app.thread.asBinder() == thread.asBinder()) {
   
            boolean doLowMem = app.instrumentationClass &