【问题分析】leash影响壁纸显示+SF侧流程变更梳理【Android15】
1 问题描述
锁屏界面调起Emergency界面，然后返回到锁屏界面，切换的过程中黑屏。
2 问题分析
首先根据复现的情况来看，能看到的很明显的一点就是，动画开始播放的时候，壁纸还没有显示出来。
但是根据现有的log：
WallpaperWindowToken也是参与到了动画了，并且动画类型是TO_FRONT，顺便一提，EmergencyDialerActivity对应的Task是CLOSE，那么按照我们对动画的了解，应该是EmergencyDialerActivity的Task在退出的同时，WallpaperWindowToken应该也是在移动到前台变为可见的，但是实际上并非如此。
接下来需要在SurfaceFlinger侧继续加log看看究竟是为什么Wallpaper无法在动画开始的时候显示出来。
代码分析见第3节，排查代码的时候是倒着分析的，但是总结的时候我觉得还是正着梳理好一点。
最终看到是动画开始的时候，WallpaperWindowToken被reparent到的“transition-leash”主动请求设置alpha为0：
导致了在整个动画期间，壁纸都无法显示，只能在动画结束后，WallpaperWindowToken从“transition-leash” reparent回到原来的父Layer上时，壁纸才能恢复显示。
具体代码在KeyguardService中：
initAlphaForAnimationTargets方法的内容是：
如果动画类型是MODE_OPENING，那么将动画的leash的透明度设置为0。
而动画的类型只有3种：
那么Wallpaper对应的ChangeInfo的动画为TO_FRONT，肯定就会被归类为MODE_OPENING。
顺便一提，U上是没有这个问题的，因为U的代码逻辑有稍许不同：
虽然找到了造成异常的代码，但是对这里的逻辑还是不太理解，为什么要在这个过程中将壁纸隐藏？
最终这个问题转给了SystemUI的同事处理。
3 SurfaceFlinger代码分析
其实这个问题并不难定位原因，主要是在追查问题原因的时候，在SurfaceFlinger侧打log，发现SurfaceFlinger.setClientStateLocked和Layer.setAlpha等方法都不走了，于是更深入了看了下，才发现这里的逻辑已经完全切换为新的了，含“legacy”相关的流程已经不走了，由于时间原因本次没办法记录的太细致，大概过一遍。
3.1 应用App侧发送的Transaction信息的提交流程
3.1.1 SurfaceFlinger.commit
起点为SurfaceFlinger.commit。
3.1.2 SurfaceFlinger.updateLayerSnapshots
以前走的是SurfaceFlinger.updateLayerSnapshotsLegacy，现在走SurfaceFlinger.updateLayerSnapshots。
3.1.3 LayerLifecycleManager.applyTransactions
也是新玩意。
3.1.4 RequestedLayerState.merge
看到是把之前SurfaceFlinger.setClientStateLocked的工作移到了RequestedLayerState.merge：
1）、这里的局部变量clientState保存的就是从客户端发来的最新的信息。
2）、调用layer_state_t.merge方法，更新自身的信息：
因为RequestedLayerState是继承自layer_state_t的：
因此最终从App端发送来的信息最终是保存到了RequestedLayerState中，而以前是在SurfaceFlinger.setClientStateLocked中将更新后的信息直接保存在了Layer.mDrawingState中。
3.2 更新LayerSnapshot信息
回到SurfaceFlinger.updateLayerSnapshots：
应用了从App侧传过来的Transaction的信息后，目前信息是保存在RequestedLayerState中的，接下来看下如何用RequestedLayerState的信息更新LayerSnapshot。
3.2.1 LayerSnapshotBuilder.update
3.2.2 LayerSnapshotBuilder.updateSnapshots
3.2.3 LayerSnapshotBuilder.updateSnapshotsInHierarchy
1）、调用LayerSnapshotBuilder.updateSnapshot继续对层级结构中的每一个LayerSnapshot进行更新。
2）、递归调用LayerSnapshotBuilder.updateSnapshotsInHierarchy自己的子节点的信息。
3.2.4 LayerSnapshotBuilder.updateSnapshot
这里就是用RequestedLayerState来更新每一个LayerSnapshot的信息的地方。
比如一个LayerSnapshot的alpha，是通过父节点alpha与本节点请求的alpha相乘得到的，如果父节点请求的alpha为0，那么这个父节点的alpha就会影响到其下所有子节点的alpha。
3.3 LayerSnapshot的可见性更新
回到LayerSnapshotBuilder.updateSnapshots：
上一步我们已经用RequestedLayerState的color.a来更新了LayerSnapshot.color.a和LayerSnapshot.alpha，接下来看下LayerSnapshot.isVisible是如何更新的。
3.3.1 LayerSnapshotBuilder.sortSnapshotsByZ
对整个层级结构进行遍历，如果一个LayerSnapshot是可见的，或者有InputInfo，那么继续调用LayerSnapshotBuilder.updateVisibility更新其可见性。
3.3.2 LayerSnapshotBuilder.updateVisibility
这个方法更新了LayerSnapshot.isVisible的值。
而传参是LayerSnapshot.getIsVisible的返回值，看下这个方法：
和AndroidV之前的逻辑也差不多。
3.4 计算可见区域的流程
先跟一下SurfaceFlinger.moveSnapshotsToCompositionArgs，然后再分析CompositionEngine.present。
SurfaceFlinger.moveSnapshotsToCompositionArgs为：
调用LayerSnapshotBuilder.forEachVisibleSnapshot，遍历LayerSnapshotBuilder中的可见LayerSnapshot，将符合要求的LayerFE添加到CompositionRefreshArgs.layers中，记住这个CompositionRefreshArgs.layers。
再看下LayerSnapshotBuilder.forEachVisibleSnapshot：
判断LayerSnapshot是否可见，用的是其成员变量isVisible，该成员变量则是在SurfaceFlinger.commit流程中，通过LayerSnapshotBuilder.updateVisibility来更新的。
继续分析CompositionEngine.present.
3.4.1 CompositionEngine.present
3.4.2 Output.prepare
3.4.3 Output.rebuildLayerStacks
3.4.4 Output.collectVisibleLayers
看到这里遍历CompositionRefreshArgs.layers，对其中的每一个LayerFE对象都调用Output.ensureOutputLayerIfVisible，而这里的CompositionRefreshArgs.layers则是在之前的SurfaceFlinger.moveSnapshotsToCompositionArgs中，通过遍历LayerSnapshotBuilder中的可见LayerSnapshot得到的。
3.4.5 Output.ensureOutputLayerIfVisible
Output.ensureOutputLayerIfVisible就是具体的计算可见区域等各种区域的地方，就不赘述了。