google 进入分屏后在横屏模式按home键界面错乱(二)
你确定你了解分屏的整个流程？
Android 关机对话框概率没有阴影故障分析
android recent key长按事件弹起触发近期列表故障分析
google 分屏 popup无法显示故障分析
分享此文便是对代码GG的支持，也是爱的表达方式，所以让爱来的猛烈些吧。
代码阅读。请到此处http://androidxref.com 查看原生代码
前情回想：
google 分屏 横屏模式 按home键界面错乱故障分析（一）
上一节我们主要环绕着分屏的那个线进行展开。分析了状态栏出现问题的问题原因。同一时候我们深入定位，跟踪了systemui的启动过程
系统WMS AMS关于分屏的一些方法。同一时候systemUI通过Divider的服务端检測AMS WMS给回来的分屏当前状态。这边进行更新view
同一时候我们找到了AMS WMS里面关于分屏的关键方法attachstack以及detachStackLocked。关注了它的堆栈信息，以及怎么触发到systemUi的界面更新过程
上一讲后面出现了一个笔误。
详细为
我们继续跟踪detachStackLocked流程，会发现我们的notifyDockedStackMinimizedChanged 方法被触发了。
这里由于当时自己的失误，写错了。
notifyDockedStackMinimizedChanged这个是在最小化的时候触发的，我们能够在文章结尾看到。我说的这个就是最小化的流程。
关于detachStackLocked触发了哪个呢？我们看它代码：
看，我是写错了。好尴尬。好了，这个就此翻篇了。
我们此讲，開始环绕分屏的启动过程。
00
我们回到触发分屏的地方PhoneStatusBar.java 里面
（详细能够在android recent key长按事件弹起触发近期列表故障分析）进行阅读三个虚拟按键的代码。这里我们仅仅关心近期列表长按事件：
这里我们看到，长按receents键（也就是虚拟按键），代码逻辑为：
mRecents为空
不支持分屏
这里supportsMultiWindow方法为：
推断了一个系统属性config_supportsMultiWindow为真 以及非低内存版本号。则觉得系统能够支持分屏
isSplitScreenFeasible 推断当前分屏的大小。是否是满足系统要求的最小的分屏像素值。
当中mMinimalSizeResizableTask 值为
所以这里的代码含义为：
假设mRecents为空
不支持分屏
屏幕当前不够分屏的最小值
则直接返回。不进入分屏模式
否则。进入分屏。
01
我们来到分屏的代码位置。这里有一个推断
dockSide == WindowManager.DOCKED_INVALID 此状态表示当前没有处在分屏模式下，因此我们须要进入分屏
我们看下这里的WindowManagerProxy.getInstance().getDockSide()怎样处理的
这里能够看到，来到了WMS（WindowManagerServer.java）位置，看下getDockedStackSide方法
这里怎样推断的呢？
找下当前的默认显示屏幕，然后推断下DockStack是否存在，假设存在。则在分屏模式。假设不存在。则当前不是分屏模式
我们这里在启动分屏，所以此时不在分屏模式模式，于是乎，我们来到代码：
千里之行，启程。
03
dockTopTask是由 mRecents调用的，那么 mRecents是谁呢？我们学习下。
这里我们要去找getComponent实现。然后我们记得之前讲过，SystemUIApplication里面有个services集合，系统会在启动systemui时候触发，创建每个的实例，
这里我们也能够看到有Recents.class,于是我们看下这个类（关注start方法，启动systemui会触发每个实例的start方法）。
仅仅看核心，其它忽略。
我们看到了有个putComponent动作。将自己增加进来，于是我们这里就能够通过getComponent拿到它了。
于是我们来到Recents.java。去看下dockTopTask方法。我们须要慢慢品尝：
假设userSetup返回false，则不进入分屏，里面是获取两个值而已。不做深入扩展。
假设没有默认的屏幕大小initialbounds。我们获取一下。
紧跟着一个推断
这里为：是否有执行Task（一般都有）。不在homestack（就是不要在桌面下瞎按，它不进入分屏的），是否在pinningActivity，这个是什么鬼呢？就是我们可锁定仅仅在这个当前栈里面，你要跑出去，必须通过其它方式触发（这个模式开启了，肯定不同意分屏。由于我就是要限定你在这个TASK内）
经过这几个条件筛选，我们来到了真正代码位置
这里又有一个条件runningTask.isDockable，这个值是什么呢？我们须要看看：（脑子回路不再扩散，这里我们直接来到TaskRecord.java，看看）
这里有非常多条件。来决定能否够同意分屏。我们关注下一个线索：
ActivityInfo.isResizeableMode(mResizeMode)。我们找下这个值从哪来。于是我们追到了：（PackageParser.java），有例如以下代码：
这段代码的含义为：我们在manifest.xml配置的分屏參数，resizeableActivity ，假设为true，意思为支持，然后假设还配置了supportsPictureInPicture，那么还支持画中画。
否则，我们推断当前apk的targetSdkVersion。假设大于N，你之前没有配置resizeableActivity。在N平台向上，觉得你就不想支持分屏，其它的再进行推断，设置为强制分屏模式。
（这条线没追。不敢贸然下结论。兴许再扩展）
为什么将这个。原因是我们开发app在manifest.xml会配置分屏參数，这里就是代码的地方。
resizeMode都有哪些值呢？
我们能够看到都有哪些模式。
04
继续dockTopTask方法：
我们假设进入sSystemServicesProxy.isSystemUser(currentUser) 为true，对于其它用户的。不去关注。就是我们开机进入的默认用户，user0
于是我们看到代码走到mImpl.dockTopTask,我们直接过来（mImpl==RecentsImpl.java）
我们看到了代码走入了moveTaskToDockedStack，这里继续跟进。我们看到了：
这里mIam就是ActivityManagerServer的代理端。此时。此方法moveTaskToDockedStack则会通过binder，进入到ActivityManagerServer的相应方法里面。
看我们上一节打出来的attachstack 方法的栈信息。是否完美的匹配上了。
小有成就。继续狂奔：
我们来看下ActivityManagerService.java里面moveTaskToDockedStack方法的凝视：
參数为：
须要移动到docked stack的task id
createMode 创建横屏的还是竖屏的分屏
toTop 是否将这个task 和stack移动到最上面
animate 是否须要一个动画
initialBounds 初始化docked stack的边界值
我们看下这里的实际传递的參数：
taskId 这个不用管，仅仅须要知道当前正在执行的TASK的id值就可以。
dragMode = NavigationBarGestureHelper.DRAG_MODE_NONE
stackCreateMode=ActivityManager.DOCKED_STACK_CREATE_MODE_TOP_OR_LEFT
initialBounds = 屏幕大小信息，这里为 0 0 720 1280
moveHomeStackFront = true
animate=false
onTop = true
于是我们来看moveTaskToStackLocked （ActivityStackSupervisor.java）这个地方代码：
我们这里须要慢慢看，于是停下歇息会，转个圈。跳个舞先。
05
我们完整的看一遍代码.发现代码量还是巨大的。须要你有耐心，继续听我扯代码，一段段来
final TaskRecord task = anyTaskForIdLocked(taskId); 找到taskid的相应数据，找不到返回
task.stack != null && task.stack.mStackId == stackId（參数stackId= DOCKED_STACK_ID） 推断是否已经是进入了分屏模式了，假设是，返回
stackId == FREEFORM_WORKSPACE_STACK_ID这里推断是否进入了自由模式。可是系统又没有支持这个模式，报异常出来。
task.getTopActivity() 拿到栈最上面的activity信息
获取下task的相应栈值
mightReplaceWindow变量的意思 可能须要替换window（此分支未作关注，我们环绕主线走）
mWindowManager.deferSurfaceLayout(); 停止surface更新，我们须要更新数据。随后使用continueSurfaceLayout继续。我们能够理解成一个锁，锁住画布。
我们继续跟踪
来到moveTaskToStackUncheckedLocked方法处
我们看凝视：
移动特定的任务到传入的stack id（我们传入的为DOCKED_STACK_ID。移动的是当前最上面的那个TASK）
task 须要移入的task
stackId 移入的stackid （DOCKED_STACK_ID）
toTop = true
，默认取得反值
forceFocus =false（不须要强制Focus）
reason 就是个凝视，我们无论
返回我们终于移入 的stack信息
06
来。互相伤害，我们贴出moveTaskToStackUncheckedLocked的完整代码：
stackId必须是多窗体的栈，而且系统要支持多窗体，否则出错。我们当前满足此情况，不会出错。
final ActivityRecord r = task.topRunningActivityLocked(); 获取task上的顶部Activity信息
final ActivityStack prevStack = task.stack; 获取相应的栈信息
final boolean wasFocused = isFocusedStack(prevStack) && (topRunningActivityLocked() == r);
是否是focus状态
final boolean wasResumed = prevStack.mResumedActivity == r; 是否是resume的
wasFront 是否是当前最前的栈
这里我们处理下，假设当前是须要移动到DOCKED_STACK_ID栈，可是当前task却是不可Resize的，我们须要将栈移动到自己的栈，或者全屏栈上
我们跳过stackId == FREEFORM_WORKSPACE_STACK_ID 这个case。我们当前不关注自由模式的状态处理
下来我们进入核心位置：
final ActivityStack stack = getStack(stackId, CREATE_IF_NEEDED, toTop); 获取这个栈，假设须要创建，创建它
mWindowManager.moveTaskToStack(task.taskId, stack.mStackId, toTop); 移动task到相应的stack上面
stack.addTask(task, toTop, reason);
然后我们当前的stack，存储下task
当中我们看下getStack的方法：
核心
这里我们看到的ActivityDisplay 为获取相应displayId的一个实例，所以我们系统是支持多种显示设备的。
创建一个ActivityContainer(stackId)，用来实现stack栈信息。然后存储下来。
我们看下
activityContainer.attachToDisplayLocked(activityDisplay, onTop);
这里便是将这个stack挂在相应显示屏的列表上面（一般我们默认显示屏是手机）
我们继续深入去看：
我们看到了attachDisplay方法
关键方法attachStack，我们跟入看下：（首先看凝视）
创建一个taskstack放置在相应的显示容器内
stackId ==栈Id，我们这里觉得为DOCKED_STACK_ID
displayId =我们觉得为默认屏，手机就可以
onTop = true
这里接住了我们上节所讲
，我们创建了分屏。于是系统通知systemui，显示divider线。
07
下来我们继续追attachStack这种方法
这里又出现一个方法，stack.attachDisplayContent(displayContent);，我们细致看下它
getStackDockedModeBounds方法为：
这里直接有值了，我们直接赋值返回了，于是我们说下这个值从哪赋值的mDockedStackCreateBounds
我们之前看到的
moveTaskToDockedStack –> 方法里面有个 mWindowManager.setDockedStackCreateState(createMode, initialBounds); 这里给了赋值。（须要看的能够向上又一次回头阅读下这个信息）
我们继续跟踪。退回attachDisplay方法。看到例如以下代码：
我们须要调整task的大小信息。
我们这里不再深入细化，由于这里逻辑太多，我们当前须要了解的是：
系统这个时候，又一次将全部的task大小计算，我们一般应用所在的FULL_SCREEN_STACK 会又一次调整。然后给当前app通知进入分屏。
为什么讲这个呢？由于这里是系统向activity发出的回调。告知系统进入分屏模式。须要activity作出响应的地方。
我们看栈信息：
系统在此时发送了REPORT_MULTI_WINDOW_MODE_CHANGED_MSG消息出去
我们在ActivityStackSupervisor.java里面找到它的处理方法：
然后它调用了app.thread.scheduleMultiWindowModeChanged 向相应app转送消息
app.thread里面：
关于app.thread 我们临时不做分析，原因是你就理解成AMS和APP的桥梁，这个app.thread会将事件带给我们的ActivityThread.java
这个ActivityThread.java熟悉吧我们的框架里面核心类，在系统创建新的进程（也就是第一次启动新的app）的时候，会进行fork新的进程。然后载入了ActivityThread.java，作为主线程。嗯，就这么多，就此打住。
ActivityThread.java继续内容为：
r.activity.dispatchMultiWindowModeChanged 这个就是调用我们的activity的回调去了
看。我们又找到一个方法onMultiWindowModeChanged，我们在写分屏app时候须要自己实现的一个方法。
又来总结下：
如此一来。我们就创建出来DOCKED_STACK_ID的一个栈了，当中stack是维护task任务的，task是维护activity的。它们就是如此的关系。然后我们系统将创建好的stack关联到WMS。调整task的大小。然后通知当前的activity，我们当前进入分屏模式下了。你要在你的onMultiWindowModeChanged 里面做出响应。
（看到了吗？我们分屏在activity的一个生命周期方法，在此处出现了）
08
回退回来，我们整理下：
moveTaskToStackUncheckedLocked 里面主要做了几件事情
final ActivityStack stack = getStack(stackId, CREATE_IF_NEEDED, toTop); 获取DOCK_STACK。假设没有，就创建它
task.mTemporarilyUnresizable = false;
mWindowManager.moveTaskToStack(task.taskId, stack.mStackId, toTop); 移动当前的task进入DOCK_STACK里面，更新状态，传递divider显示与否的消息到systemui。传递给activity onMultiWindowModeChanged，来告知消息。
stack.addTask(task, toTop, reason); 增加当前的AMS的管理里面就可以。
后面触发了mWindowPlacerLocked.performSurfacePlacement();方法。引发绘制动作，我们的分屏启动完毕了。
09
我们再来看一个问题，就是我们的分屏，会在屏幕上画出一个切割线，这个线的位置怎样定义出来的呢？
我们回到DividerWindowManager.java 。我们之前讲过。我们的切割线是在分屏开启后进行显示，增加到WMS里面去，我们能够看到一个关键信息
这里我们看到 TYPE_DOCK_DIVIDER。是这个View的类型，非常特殊。
我们搜索这个keyword。能够看到非常多内容，我们简单说下里面一些：
WindowManagerService.java 里 addWindow，
这里为假设当前View的类型为TYPE_DOCK_DIVIDER 我们要增加到DockedDividerController里面，依照上一节的说法，这个DockedDividerController会在系统的Vsync里面。实时触发。这里则会推断是否有divider之类的状态。
PhoneWindowManager.java 里面的 layoutWindowLw 方法：
给TYPE_DOCK_DIVIDER 赋值绘制区域，系统边界值的信息。
我们再看一个类WindowState.java，里面的关键方法computeFrameLw
有段内容：
我们打个断点在这里：
我们惊奇的发现。我们的栈里面有performSurfacePlacementLoop，还有moveTaskToStackLocked–>mWindowManager.continueSurfaceLayout(); 这里触发了启动绘制。
看到这条线路。我们能够找到整个窗体的计算过程路径。
这里我们关心的是这个切割线的位置：（这里mFrame便是计算好的位置信息了，我们当前值为 Rect(0, 568 - 720, 664)。高96，看这里是不是在屏幕中间）
看代码：
根据我们的DOCKED_STACK的位置，去计算frame，这里我们为TOP
而这里的96怎样来的呢？我们知道创建切割线的地方为 Divider.java的addDivider。里面有个信息：
我们这里的dp2px=2。所以会是96高。
10
如上，我们发现我们穿过层层阻碍，走完了分屏的创建过程的大半过程。
分屏过程错复杂，我们还有个触发近期列表的过程须要解说。
我们看到了这里，经历了dock的整个创建过程，我们再回到我们出发的起点位置，看个内容：
RecentsImpl.java的dockTopTask方法。我们启动分屏的開始部分。
我们看到了。假设创建成功，我们进入里面的方法EventBus的send我们不去关注了，想要了解的，去看看EventBus的总线方式，以及怎样解耦的。
核心便是通过注解，系统将须要接收的通过方法的參数类型进行匹配。
我们须要看以下的：showRecents ，这个便是我们进入分屏，下方出现的近期列表界面启动的地方。
此方法我们不详细扩展了，本质就是启动了一个activity就可以（startRecentsActivity）。
假设有收获，观赏鼓舞下作者。
很多其它内容，关注微信公众号：代码GG之家。
加微信 code_gg_boy 进入代码GG交流群
下一讲，主要环绕分屏的退出过程