本文主要是介绍【问题分析】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就是具体的计算可见区域等各种区域的地方,就不赘述了。
这篇关于【问题分析】leash影响壁纸显示+SF侧流程变更梳理【Android15】的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!