liaosongmao1的专栏

可以明显看出这里systemserver跨进程回调到了ShellTaskOrganizer的onTaskAppeared，在这个方法进行精准匹配到TaskView关心的Task变化，然后进行通知。上面第一步已经实现了CarLauncher可以监听Task的相关行为，注意这里肯定是所有的Task行为，但是TaskView它自身只关心Map相关的Task，那么这里是怎么精准通知的呢？通过这个cookie即可以精准的把系统回调的TaskInfo匹配到对应的TaskView。启动Activity相关堆栈。

hi，粉丝朋友们！上一个blog已经详细讲解了系统中自带相关接口实现窗口的高斯模糊相关效果，具体点击这里。

这个FLAG_BLUR_BEHIND属于LayoutParams注释就是说FLAG_BLUR_BEHIND就会让在该window下面的window进行模糊具体如果要使用：其实就是对window的LayoutParams设置这个flag同时还有另一个方法setBlurBehindRadius大家都知道高斯模糊都有一个模糊滤镜，这代表模糊的程度，一般mBlurBehindRadius越大模糊层度越厉害。

hi，粉丝朋友们！今天来给大家介绍一下再Activity中WindowMode相关的多窗口模式，这个模式相对平时比较少见，但是在分屏模式之自由窗口模式，等存在多个窗口场景就很关键了。这一部分确实不是普通模式的场景，而且每一种模式都是比较难的，今天来分析一下WINDOWING_MODE_MULTI_WINDOW模式的一个疑问。

哈哈，注意一般app都是走Zygote.forkSimpleApps这个，但是你要是对这个方法直接打印会发现它并不是个一次性方法，进入后马上出来，这里forkSimpleApps方法名字其实和它的实际行动不太搭，所以这里大家特别注意不要被它的名字迷惑，以为每次 fork新的app进程，这里就会进入一次forkSimpleApps。开发时候，使用的是最新android13代码的，相比以前的版本这块Zygote fork新进程还是有较大的差异。上图就是老版本的一个fork情况。

hi，粉丝朋友们！

如果没有2个屏幕，则压根不触发任何移动操作。

hi，粉丝朋友们：上一节已经讲解了多屏互动动画部分的跟手动画和自动动画设计。本节来重点讲解一下最核心的图层设计相关。

主屏幕2的Task画面应该最右边往左边有offsetX的画面，所以左边原点相对屏幕偏移距离就应该是 -（width -offsetX） 注意这里应该是负数哈，因为屏幕最左边才是0。上面其实已经规划设计好了移动动画的流程，但是忽略了一个比较关键问题，那就是屏幕1的Task画面和屏幕2的Task画面从哪里来？主屏幕1是接受了双指触摸的右边移动了offsetX的距离，这时候屏幕1的Task画面也要跟着向右平移offsetX。动画主体画面：就是task的画面，动画过程中需要屏幕1和屏幕2都有在个task的画面。

hi,粉丝朋友们！上一节已经对车载的多屏互动进行了相关的技术方案介绍，以及相关的核心方法moveRootTaskToDisplay的讲解和使用。本节就来进行代码实战。

这个就是没有动画版本的双屏互动，功能其实也是实现的，但是体验是不是感觉起来差的太多，而且还带有黑屏。2、画面A的平移，两个屏幕都要进行显示，这个难度较大，得考虑好相关的画面怎么都可以显示在两个屏幕。这里其实不需要写代码，可以直接调用am display相关的命令即可以实现这个方法的调用。不过还好的是功能可以用，那么我们也根据wms课程基础后也来实现一下这个双屏互动的功能。1、多指全局动作监听，而不是在某个app的onTouch里面监听，这里其实之前的。

hi，粉丝朋友们！

针对上一节已经清楚了相关的代码中怎么可以打印到logcat中，其实本质上还就是protologtool这个工具对代码中的所有ProtoLog进行了相关的替换成了具体实现，最后会条件判断输出到Slog中。即使用类似命令：protologtool read-log --viewer-conf protolog.conf.json wm_log.winscope。viewer.json就是/system/etc/protolog.conf.json.gz。那么剩下就是protologtool命令哪里来的？

hi，前期学习WMS/AMS专题时候，日志相关讲解最多是就是ProtoLog相关，比如我们想要观看所有的configuration相关的日志，只需要用以下命令进行开启：更多内容qqun：422901085就是这里的ProtoLog打印日志，它的TAG就是WM_DEBUG_CONFIGURATION然后就可以通过logcat -s WindowManager看到相关的 ProtoLog.v(WM_DEBUG_CONFIGURATION所有打印。

近期又粉丝朋友聊到了如果做aosp系统应用开发，有什么工具或者方式来导入代码可以正常跳转和代码提示等？

make出错，然后再把frameworks/base/cmds/bootanimation/Android.mk又修改正确恢复原样，再进行make时候就会重新加载新加入的Android.mk。原因：如果确认已经拷贝了文件夹到了源码根目录这个其实是因为android8.1上面热编译没有触发全局重新扫描mk文件。去frameworks/base/cmds/bootanimation/Android.mk文件中故意加一个错误字符。2、如果使用vmware工具，请需要vmware中也开启相关加速开关。

19-wallpaper-add-relayout-finish-3.mp4 实战项目：壁纸add和relayout相关分析。22-wallpaper-winscope-black-reason.mp4 实战项目：分析闪黑工具分析原因。24-wallpaper-fix-black-2-cut.mp4 实战项目：解决闪黑问题修改方案2。31-0-window-animator-end-remove.mp4 窗口动画源码分析5。

所以就不得不跟着横屏显示。国内手机桌面基本不支持横屏，都是强制竖屏模式，所以对横屏基本没有适配对应的布局，所其实这些桌面是不希望看到有横屏情况展示出来，但是经常又会又一些小场景会导致桌面被强制横屏，所以看起来的体验比较差，就经常容易让测试提bug，用户体验也很糟糕。2、桌面支持横屏显示，这个理论是可以的，但是也不太现实，因为桌面横屏修改等需要波及面还是比较多的，很多都是业务类工作，工作量较大，而且也只是为了修改一个这个体验性bug，性价比低。那下面千里马就带大家开干，，把这个显示异常bug修复了。

然后跟着这个堆栈一直追既可以到startFreezingDisplayLocked，这个方法代表是冻屏，一般要进行屏幕整个旋转，肯定需要冻屏方便让我们整体画面进行动画。明显RotationLayer属于截图Layer，后面Activity属于DisplayContent的Layer，DisplayContent这个图层Layer执行动作是竖屏到横屏旋转，而ShotscreenLayer明显是又是横屏到竖屏的过程，具体可以看课程视频动画，这里blog就不上动画过程了。什么时候开始启动屏幕动画呢？

2、然后把数据java 的InputWindow数据转化native的InputWindow数据，通过一步步传递到transition中，即保存到了layer_state_t中。依次往下调用updateInputFlinger，会调用buildWindowInfos把当前所有的layer中获取数据转化到WindowInfo。这里较为简单，知识把对应的WindowInfo数据传递给对应的layer_state_t,其实对应就是Layer。接下来来到SurfaceControl.java的。

明显可以看出是靠handler中对EXECUTE_TRANSACTION的消息进行处理execute会最后执行到Activity的onResume。它一个transation 执行在mActivityCallbacks后。那么又是谁调用过来的？那肯定是systemserver的跨进程调用的。LaunchActivityItem它就包含要执行任务较多。那么EXECUTE_TRANSACTION消息谁发送的？首先可以看看onResume的调用栈是哪里调用过来的。更多内容qqun：422901085。

更多内容qqun：422901085。

这里是为啥阿，因为高版本StartingWindow已经移殖到了Systemui进程，让Systemui来负责窗口创建相关，所以自然就wms端处理不了，要跨进程让systemui处理。这里注意，明显用wm开启时候，和正常wm相关的打印输出也是不一样的，明显显示是No IProtoLogGroup named WM_SHELL_STARTING_WINDOW。这个时候logcat -s WindowManager是没有这个shell相关打印，必须要。才可以打印出相关的Proto日志。

设想一下，假如我们又如下场景，一个闪黑一瞬间的问题，正常我们看到黑屏冻屏问题，是不是时刻想到是要来dumpsys SurfaceFlinger和dumpsys window windows相关的信息来辅助我们分析问题，但奈何这个是个瞬时问题。对于这些问题，添加日志，调试分析代码等手段去解决，但这些 UI 问题往往出现在一瞬间，很难把握出现的时机，录制下来的日志往往也是巨大的，从海量的日志中提取有效的信息是一个枯燥且繁琐的事情，而且也根本没有办法把显示时间戳和日志时间戳完全对好。选择后点击Submit。

主要就有2个最关键步骤：1、创建对应Window的SurfaceControl2、计算出对应的window区域等，把inset和config传递回去更多内容qqun：422901085。

更多内容qqun：422901085。

这里面进行对应分屏相关的一个业务处理， 比如分割线拖拽对两个分屏大小影响等。最后都会通过包装成WindowContainerTransaction对象，再通过WindowOrganizerController的本地代理，跨进程传递到systemserver的WindowOrganizerController类中进行处理.hi，近来研究分屏时候发现android 13上的分屏和以前的分屏代码差别比较大。最后就是调用的windowConfiguration.getBounds。其实Task的Bounds就是。

在系统开发过程中大家要学会怎么来学习追踪代码，这一点是非常关键的，因为在庞大系统代码中，如果什么都进行正向分析，那么很有可能因为代码过于庞大，进入分支过多而导致丢失方向，失去了主要线路，陷入一种丢了西瓜捡到芝麻情况，这情况其实经常在分析系统源码时候常见，但是这其实对我们学习主流程来说是非常不利的，因为我们往往对代码执行的主流线路都还没有摸清，没有办法对流程有一个比较好的理解，而容易被执行某个小点，小部分卡住。这里我们既可以去看一下StartingSurfaceDrawer代码，然后从它的代码开始入手分析。

更多内容qqun：422901085 https://ke.qq.com/course/5992266#term_id=106217431官方注释：给可以直接持有窗口的自己或它的孩子定义了一些公共的方法和属性，像RootWindowContainer、DisplayContent、DisplayArea、DisplayArea.Tokens、TaskDisplayArea、Task、ActivityRecord、WindowToken、WindowState都是直接或间接的继承该类。这里面主要的重要要

接着上一节课学习，我们已经清楚的知道了层级结构应该怎么看，根据dumpsys的输出可以完美复原出层级结构树，也理解了结构树对于层级结构的控制作用。但还没有从源码部分对这个结构树进行一个分析，即分析生成这个结构树的源码部分。更多内容qqun：422901085。

每addChild时候其实都会触发WindowContainer.onParentChanged，从而触发DisplayContent中创建对应的SurfaceControl，而且大家注意mWmService.makeSurfaceBuilder(s).setContainerLayer();创建出来的都是容器，而不是真正可以绘制的SurfaceControl。哈哈，是不是终于看到对应的代码了图层Buffer图层type而不是Container的type。更多内容qqun：422901085。

hi,粉丝朋友大家好！上几集已经给大家讲解了如何构建出0-36层的层级树及相关源码分析，这节来分析离我们最近的Task/ActivityRecord/WindowToken/WindowState/等是怎么添加到这个层级树里面去的。更多内容qqun：422901085。

hi，本节课我们来讲解一个system window最简单的demo。更多内容qqun：422901085。