前言
从今天开始我们开始动态调试四大组件的各种场景，其他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的数据结构。
