前言

从今天开始我们开始动态调试四大组件的各种场景，其他android开发者写的关于android源码剖析，都是从正面切入，这和打仗似的，直接正面交火，肯定打的非常激烈，并且还有可能吃败仗。正如我们看其他的源码剖析的文章，看的时候非常痛快，看完后，细细回想起来，突然发现什么也没有记住，这是为什么。
其他我感觉这和我们的当前教育模式非常相像，填鸭式教育，没有自己的思考，完全记忆和理解别人思考的结果，这种模式在大脑的回路不够深，记忆也不会长久。

再想想老外的教育模式，启发式教育或者是问题式教育，带着问题去寻找答案，去思考为什么这么设计，最后得到答案，这种自己思考得出的结论，当自己再次思考的时候还会得出同样的结论，这也许是思考的惯性，就像我们小时候上学的时候做错的题目还会再做错一样。

所以我们后面所有的文章都是基于这种问题式教育的方式来完成，首先提出一个问题，然后自己解决同样的问题会怎么做，最后对比Android系统的做法。

问题： 如何实现 adb dumpsys Activity Activities

这篇文章dumpsys实现原理,讲述了dumpsys的实现其实是通过serviceManager拿到对应的service信息，然后执行该service的dump函数。，那么上面的命令最终应该调用AMS的dump函数才对。
那下面我们来实现AMS的dump函数

我们大家都知道， Activity是一个基础组件，在AMS里用ActivityRecord类来标识一个Activity实例。

那么谁来管理ActivityRecord呢？ 这里又涉及到Android开发者都知道的一个知识点，Activity是通过栈来管理的，那么又有个栈结构。而Activity的不同launch mode又让Activity属于不同的栈。那么还需要一个栈的管理者，以上二级结构用面向对象的思想来设计就会是这样：

public class ActivityRecord{
  .....
}

public class ActivityStack{
   Stack<Activity> mStack;
}

public class ActivityStackSupervisor{
    List<ActivityStack>  mList;
}

到此AMS的dump函数实现就很明了了：

public class ActivityManagerService {
    
     public ActivityStackSupervisor  mStackSupervisor;
      public String dump(){
            mStackSupervisor.dump();
      }
}

public class ActivityStackSupervisor{
    List<ActivityStack>  mList;

    public String dump(){
         for(int i = mList.Size()-1; i >=0; i--){
              print("stack: #" i);
              ActivityStack stack = mList.get(i);
              stack.dump();
        }
    }
}


public class ActivityStack{
      
      //java提供的stack逆序遍历输出比较繁琐，我们用List来实现栈结构
      List<ActivityRecord>  mStack;
      
      public void dump(){
              
             for(int i = mStack.Size()-1; i >=0; i--){
                 ActivityRecord record = mStack.get(i);
                record.dump();
              }
      }
}

这样基本就实现了dumpsys Activity Activities命令。也明确了一个Activity的管理结构，如果再简单想一下，头脑中会冒出另外一个问题：ActivityStackSupervisor什么时候会创建一个新的stack呢？我们继续去寻找新问题的答案。

问题： ActivityStackSupervisor什么时候会创建一个新的stack呢？

为什么要创建一个新的stack呢？所有的Activity都在一个stack里面可以么？
想想简单的场景应该是可以的，比如以下场景：通过桌面启动A,然后打开A1，A2，A3页面，然后按下home键回到桌面，启动B，打开B1,B2,B3。

···

                     A3                                    B3
                      |                                        |     
                     A2                                    B2
                      |                                        |    
                     A1                                    B1
                      |                                        |

luncher------>luncher------>luncher------>luncher

如果是这么设计，当想回到A时，A的栈信息就丢失了，无法通过多任务界面恢复A的栈信息。

那么怎么解决这个问题呢？
给luncher单独一个栈
B4
|
A3 A3
| |
A2 A2
| |
luncher------>luncher------>A1------> luncher------>A1

这样虽然保存了A的栈信息，但是还是无法解决多任务的问题，而且还引入了栈后退不符合用户体验的问题，因为这么后退 会从B会直接回退到A而不是期望的桌面程序。那怎么解决这两个问题呢？
解决B回到桌面的问题可以在B里面标识下“B是从桌面来的，mReturnToHome = true”
解决多任务的问题呢？ 只能是将A1&A2&A3再放到一个容器里，一起上升一起下降。

总结下，要解决多任务的问题，需要定义一个Task结构，将一个任务的Activity放到一起管理，一起上升，一起下降。

所以就出现了三级火箭结构：

ActivityRecord 是基础单元
TaskRecord 保存的是任务的栈结构
ActivityStack 是所有应用的栈结构

为了区分luncher和其他App， 又独立分成了两个ActivityStack, 由ActivityStackSupervisor来管理。

HomeStack是在第一次启动ActivityManagerService和WindowManagerService时创建的。

//ActivityStackSupervisor.java

void setWindowManager(WindowManagerService wm) {
            mHomeStack = mFocusedStack = mLastFocusedStack =
                    getStack(HOME_STACK_ID, CREATE_IF_NEEDED, ON_TOP);
}

注意这里传递的StackID是HOME_STACK_ID。

另外一个Stack是在第一次启动App的时候创建的。

    //ActivityStackSupervisor.java
    ActivityStack createStackOnDisplay(int stackId, int displayId, boolean onTop) {
        ActivityDisplay activityDisplay = mActivityDisplays.get(displayId);
        if (activityDisplay == null) {
            return null;
        }

        ActivityContainer activityContainer = new ActivityContainer(stackId);
        mActivityContainers.put(stackId, activityContainer);
        activityContainer.attachToDisplayLocked(activityDisplay, onTop);
        return activityContainer.mStack;
    }

还有另外一个问题？ 什么时机会创建新的Task呢？转换下问题就是Task是通过什么来区分的呢？

简单来设计 可以让每个App都独立在一个Task中。那么Task的“姓氏”就是packageName。

Android基本上也是这么设计的：task的affinity属性就是他的“姓氏”。一般都第一个Activity的包名。

这样我们就理解了ActivityManagerService的数据结构。