【问题分析】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就是具体的计算可见区域等各种区域的地方，就不赘述了。