Jetpack Compose 测量流程源码分析

39 阅读13分钟

inline class SkippableUpdater constructor(

@PublishedApi internal val composer: Composer

) {

inline fun update(block: Updater.() -> Unit) {

composer.startReplaceableGroup(0x1e65194f)

Updater(composer).block()

composer.endReplaceableGroup()

}

}

//结合SkippableUpdater 的update 函数,skippableUpdater.update { set(materialized, ComposeUiNode.SetModifier) }

// <=>等价于👇

composer.startReplaceableGroup(0x1e65194f)

// 2️⃣ 📍 modifier 最终传给了这个 set 方法

Updater(currentComposer).set(materialized, ComposeUiNode.SetModifier)

composer.endReplaceableGroup()

代码 2️⃣ 这里是调用了一个 set 方法,直接看有点晕,调来调用去,分析起来太多了,不能跑偏了,直接说重点。

companion object {

val Constructor: () -> ComposeUiNode = LayoutNode.Constructor

//ComposeUiNode.SetModifier

val SetModifier: ComposeUiNode.(Modifier) -> Unit = { this.modifier = it }

}

// ComposeUiNode.SetModifier 也是个函数类型,调用 set(materialized, ComposeUiNode.SetModifier)

//最终会触发SetModifier 函数的执行也就是

this.modifier=materialized //📍 modifier

// 👆 this是LayoutNode 对象 是通过触发 ComposeUiNode.Constructor创建的

关于从 set(materialized, ComposeUiNode.SetModifier) 是如何到触发 SetModifier 函数的,这里我就分析了,可以通过 debug 很容易验证这一结论。如果你真的想去分析如何执行的话,分析之前建议先看一下 深入详解 Jetpack Compose | 实现原理 这篇文章。(友情提醒,如何真要分析这段别陷进去了,别忘记我们看源码的目的。)

通过上面的分析,我们追踪的 modifier 被赋值给了 LayoutNode 成员的 modifier ,这种是个赋值语句,在 kotlin 相当于调用的成员变量的set 方法 LayoutNode.kt

override var modifier: Modifier = Modifier

set(value) {

// …… code

field = value

// …… code

// 创建新的 LayoutNodeWrappers 链

// foldOut 相当于遍历 modifier

val outerWrapper = modifier.foldOut(innerLayoutNodeWrapper) { mod /📍 modifier/ , toWrap ->

var wrapper = toWrap

if (mod is OnGloballyPositionedModifier) {

onPositionedCallbacks += mod

}

if (mod is RemeasurementModifier) {

mod.onRemeasurementAvailable(this)

}

val delegate = reuseLayoutNodeWrapper(mod, toWrap)

if (delegate != null) {

wrapper = delegate

} else {

// …… 省略了一些 Modifier判断

if (mod is KeyInputModifier) {

wrapper = ModifiedKeyInputNode(wrapper, mod).assignChained(toWrap)

}

if (mod is PointerInputModifier) {

wrapper = PointerInputDelegatingWrapper(wrapper, mod).assignChained(toWrap)

}

if (mod is NestedScrollModifier) {

wrapper = NestedScrollDelegatingWrapper(wrapper, mod).assignChained(toWrap)

}

// 布局相关的 Modifier

if (mod is LayoutModifier) {

wrapper = ModifiedLayoutNode(wrapper, mod).assignChained(toWrap)

}

if (mod is ParentDataModifier) {

wrapper = ModifiedParentDataNode(wrapper, mod).assignChained(toWrap)

}

}

wrapper

}

outerWrapper.wrappedBy = parent?.innerLayoutNodeWrapper

// 代码 0️⃣

outerMeasurablePlaceable.outerWrapper = outerWrapper // 👈 📍 modifier

……

}

**👆 代码片段-1 **

上述代码主要是将Modifier 链转换LayoutNodeWrapper 链的过程,通过Modifier 的 foldOut 函数 遍历Modifier 链上的所有元素,并根据不同的Modifier 创建不同的 LayoutNodeWrapper。关于Modifier 的foldOut 函数的作用不懂的可以看我之前写的 Modifier源码,Kotlin高阶函数用的真6 这篇文章。

在上面的代码中根据 Modifier 类型创建不同的 LayoutNodeWrapper,这些不同的 Modifier 都是 Modifier.Element 的直接实现类或接口,如 KeyInputModifier、PointerInputModifier、LayoutModifier 等。上面代码都是 if 判断,没有else,也就是说如果 Modifier 不在这些类别范围内就没法创建对应的LayoutNodeWrapper,也就相等于我们设置的 Modifier 没有用。所以我自定义Modifer 一定要在这个类型范围内,否则是没有用的。在JetPack Compose 内置的Modifier.Element 子类或接口如下。(Tips. Android studio 查看类的继承关系 菜单栏Navgate-> Type Hierarchy ; 快捷键 Ctrl+H )

换个思路继续跟踪


上面分析到那里路好像断了, 没法继续了。思考一下这里只是分析了Layout 函数执行时,只是初始化的准备工作。它的大小和位置如果确认等操作这里似乎没有执行。我们刚才是把 ParentLayout 当做父容器来看待的,父容器一般是管理自己的 children 的大小和位置,换一种思路,ParentLayout 出来做父容器,它也可以作为 child 呀,如下面代码情况。

setContent {

ParentLayout{

Box() {}

// 👇 可以看做是 上面 ParentLayout 的 child,也可以看做是下面 ChildLayout 的父容器

ParentLayout(

Modifier

.size(100.dp)

.padding(10.dp)

.background(Color.Blue)

) {

ChildLayout(Modifier.size(100.dp)) {}

}

}

}

下面就从 ParentLayout 布局作为 child 的时候来分析一下,如果作为 child 那么分析入口就应该它从的父容器 MeasurePolicy 的 measure 函数开始分析了。

val measurePolicy = MeasurePolicy { measurables, constraints ->

val placeables = measurables.map { child ->

//代码 0️⃣

child.measure(constraints)

}

……

}

代码 0️⃣ 进行调用 child 的测量方法,从函数参数来看,只知道 child 是个 Measurable 的类型,但 Measurable 是个接口,我们需要知道 child 具体是 Measurable 那个实现类,我们才好分析 measure 函数的逻辑

👆 图片-0

通过debug 的方式,可以看出 child 是 LayoutNode 对象(为什么是LayoutNode 下面分析就知道了),那么就去看看 LayoutNode 的measure函数。

LayoutNode.kt → measure 函数

override fun measure(constraints: Constraints) =

outerMeasurablePlaceable.measure(constraints)

LayoutNode 的 measure 调用了 outerMeasurablePlaceable 的 measure 函数,这个 outerMeasurablePlaceable **代码片段-1 代码 0️⃣ **也出现了outerMeasurablePlaceable.outerWrapper = outerWrapper // 👈 📍 modifier 而且这个outerMeasurablePlaceable 的属性 outerWrapper 就包含 modifier 信息。我们又找到了 modifier 的藏身之处,好像又找到些线索。我们继续跟踪代码吧。

LayoutNodeWrapper 链中的测量流程分析⛓


OuterMeasurablePlaceable.kt

override fun measure(constraints: Constraints): Placeable {

……

remeasure(constraints)

return this

}

fun remeasure(constraints: Constraints): Boolean {

val owner = layoutNode.requireOwner()

……

if (layoutNode.layoutState == LayoutState.NeedsRemeasure ||

measurementConstraints != constraints

) {

measuredOnce = true

layoutNode.layoutState = LayoutState.Measuring

measurementConstraints = constraints

val outerWrapperPreviousMeasuredSize = outerWrapper.size

owner.snapshotObserver.observeMeasureSnapshotReads(layoutNode) {

outerWrapper.measure(constraints)// 0️⃣ 👈 📍 modifier

}

layoutNode.layoutState = LayoutState.NeedsRelayout

……

return sizeChanged

}

return false

}

👆 代码片段-2 代码 0️⃣ 处 我们看到包含 modifier 信息的 outerWrapper 调用了 它的 measure 方法。outerWrapper 是 LayoutNodeWrapper 类型的,它就是在代码片段1 处根据不同 Modifer 创建的 LayoutNodeWrapper 链。我们给 ParentLayout 的 Modifer 设置为 Modifier.size(100.dp).padding(10.dp).background(Color.Blue) 。那么对应的LayoutNodeWrapper 链如下图所示

Jetpack compose 测量流程-LayoutNodeWrapper链 (3)

👆 图-1

由 图-1 知代码片段-2 处的代码outerWrapper 为 ModifiedLayoutNode 类型。 ModifiedLayoutNode

internal class ModifiedLayoutNode(

wrapped: LayoutNodeWrapper,

modifier: LayoutModifier

) : DelegatingLayoutNodeWrapper(wrapped, modifier) {

override fun measure(constraints: Constraints): Placeable = performingMeasure(constraints) {

with(modifier) { 👈 📍 modifier

measureResult = measureScope.measure(wrapped, constraints)

this@ModifiedLayoutNode

}

}

protected inline fun performingMeasure(constraints: Constraints, block: () -> Placeable

): Placeable {

measurementConstraints = constraints

val result = block()

layer?.resize(measuredSize)

return result

}

……

}

由 图-1 知代码此时的 modifier 为 SizeModifier 类型 LayoutModifier.kt

interface LayoutModifier : Modifier.Element {

fun MeasureScope.measure(

measurable: Measurable,/下一个 LayoutNodeWrapper 节点/

constraints: Constraints/* 来着父容器或者来着上一个节点的约束 */

): MeasureResult

}

SizeModifier.kt

private class SizeModifier(

private val minWidth: Dp = Dp.Unspecified,

private val minHeight: Dp = Dp.Unspecified,

private val maxWidth: Dp = Dp.Unspecified,

private val maxHeight: Dp = Dp.Unspecified,

private val enforceIncoming: Boolean,

inspectorInfo: InspectorInfo.() -> Unit

) : LayoutModifier, InspectorValueInfo(inspectorInfo) {

private val Density.targetConstraints: Constraints

get() {/更加我们指定的大小生成对应的约束/}

override fun MeasureScope.measure(

measurable: Measurable,/下一个LayoutNodeWrapper/

constraints: Constraints/* 来着父容器或者来着上一个节点的约束 */

): MeasureResult {

val wrappedConstraints = targetConstraints.let { targetConstraints ->

if (enforceIncoming) {//当我们给控件指定大小时,这个值就为true

//结合父容器或者上一个节点的约束 和我们指定约束进行结合生成一个新的约束

constraints.constrain(targetConstraints)

} else {

……

}

}

//代码 0️⃣ 进行下一个 LayoutNodeWrapper 节点测量

val placeable = measurable.measure(wrappedConstraints)

//所有节点测量完,开始放置

return layout(placeable.width, placeable.height) {

placeable.placeRelative(0, 0)

}

}

代码 0️⃣ 继续进行下一个 LayoutNodeWrapper 节点的测量,一直到最后 InnerPlaceable 节点。

class LayoutNode{

internal val innerLayoutNodeWrapper: LayoutNodeWrapper = InnerPlaceable(this)

private val outerMeasurablePlaceable = OuterMeasurablePlaceable(this, innerLayoutNodeWrapper)

……

internal val children: List get() = _children.asMutableList()

}

InnerPlaceable

class InnerPlaceable{

override fun measure(constraints: Constraints): Placeable = performingMeasure(constraints) {

val measureResult = with(layoutNode.measurePolicy) {

// 这里就是Layout 的MeasurePolicy 的measure 执行的地方了

layoutNode.measureScope.measure(layoutNode.children, constraints)

}

layoutNode.handleMeasureResult(measureResult)

return this

}

}

这里就是 Layout 的 MeasurePolicy 的measure 执行的地方了,然后children 继续执行上述流程了如下图所示,这样“MeasurePolicy 接口的 measure 方法是怎么调用的?他的参数值是怎么来的呢?”这个问题也就解答了。

分析解答问题


通过上面的分析,我们大致可以回答“布局中的测量流程是什么样的?” 这个问题了。**

1 准备阶段:

child 在父容器在声明时,也就是调用了 Layout 函数,进行初始化准备操作,记录这个child 测测量策略,这个child 的children 等,根据设置的 Modifier 链创建对应的 LayoutNodeWrapper 链。

2 测量阶段

child 在父容器的测量策略 MeasurePolicy 的 measure 函数中执行 child 的 measure 函数。接着按照准备好的 LayoutNodeWrapper 链一步步的执行各个节点的 measure 函数,最终走到 InnerPlaceable 的 measure 函数,在这个又会继续它的 children 进行测量,此时它的 children 就会和它一样进行执行上述流程,一直到所有children 测量完成。 用下面这张图总结一下上述流程。

Jetpack compose 测量流程-测量流程 (1)

👆 图-2 测量流程图

还有一个最后一个问题 ParentLayout 中 通过 modifier 设置大小是如何起到作用的 ? 答:我们通过 Modifer.size() 函数 构建了一个SizeModifer 对象

fun Modifier.size(size: Dp) = this.then(

SizeModifier(

minWidth = size,maxWidth = size,

minHeight = size, maxHeight = size,

enforceIncoming = true,...

)

)

通过上面的分析我们知道,在测量流程中SizeModifer 的measure 函数会触发

SizeModifer部分源码

private class SizeModifier(

private val minWidth: Dp = Dp.Unspecified,

private val minHeight: Dp = Dp.Unspecified,

private val maxWidth: Dp = Dp.Unspecified,

private val maxHeight: Dp = Dp.Unspecified,

private val enforceIncoming: Boolean,

inspectorInfo: InspectorInfo.() -> Unit

) : LayoutModifier, InspectorValueInfo(inspectorInfo) {

// 0️⃣ 根据我们设置的大小生成一个约束对象

private val Density.targetConstraints: Constraints

get() {

//控制 maxWidth值范围

val maxWidth = if (maxWidth != Dp.Unspecified) {

maxWidth.coerceAtLeast(0.dp).roundToPx()

} else {

Constraints.Infinity

}

//maxHeight、minWidth、minHeight 也类似处理一下值的范围,防止我们瞎捣乱

...code...

return Constraints(

minWidth = minWidth,

minHeight = minHeight,

maxWidth = maxWidth,

maxHeight = maxHeight

)

}

override fun MeasureScope.measure(

measurable: Measurable,//LayoutNodeWrapper链上的下一个节点的

constraints: Constraints//父容器或者是LayoutNodeWrapper链上的上一个节点的constraints

): MeasureResult {

val wrappedConstraints = targetConstraints.let { targetConstraints ->

if (enforceIncoming) {

//1️⃣ 和我们设置的大小继续比较计算,得出一个新的Constraints对象

// constrain 函数作用是,在constraints范围内,得到一个尽可能满足targetConstraints的大小范围的约束

constraints.constrain(targetConstraints)

} else {

//暂不讨论

}

//2️⃣ 使用新的约束继续下一个测量

val placeable = measurable.measure(wrappedConstraints)

return layout(placeable.width, placeable.height) {

placeable.placeRelative(0, 0)

}

}

}

...

}

我们通过Modifier.size 函数设置的大小信息最终变成SizeModifier 一个成员变量 targetConstraints,它是一个Constraints 类型,主要描述宽度的最小值和最大值(minWidth、maxWidth) 以及高度的最小值最大值(minHeight、maxHeight)。 在 measure 函数中,在代码 1️⃣ 处把传入的 constraints 和我们传入的大小进行大小比较得到一个合适的 Constraints ,然后用新的 Constraints 进行下一个次测量。我们设置的大小就是在这里起到作用的,影响着接下来的测量约束参数。

补充点-布局宽高计算流程


上面我们把measure 测量流程走了一遍,测量的目的就是为了布局的宽高计算,那这些计算的过程是在哪里执行的呢?我们通过 Jetpack Compose 写界面,我们的写每一个组件都会转换成对应的节点 LayoutNoe,在Layout 函数中就有一个创建LayoutNode的过程。我们想分析局的最终宽高,就看 LayoutNode 的宽高怎么来的就行了。

class LayoutNode{

private val outerMeasurablePlaceable = OuterMeasurablePlaceable(this, innerLayoutNodeWrapper)

override val width: Int get() = outerMeasurablePlaceable.width

override val height: Int get() = outerMeasurablePlaceable.height

}

看LayoutNode 源码可知,LayoutNode 的宽高就是 OuterMeasurablePlaceable 的宽高,我们找到 OuterMeasurablePlaceable 的宽高确认就可以了,上面我已经把测量流程大致分析了一下,结合 图-2 测量流程图 再把流程走一下就可以找到答案了,这里我就不在一段一段代码的去分析了,我把 OuterMeasurablePlaceable 的宽高计算代码流程绘制成下面图片了,有兴趣的可以结合图片去看源码分析一遍。

Jetpack compose 测量流程-宽高确认流程

👆 图-3 节点宽高计算代码流程图

大致流程是,在父容器的MeasurePolicy 进行 child 的测量->进入OuterMeasurablePlaceable的测量函数,在这里先根据函数传入的Constraints约束计算一下宽高,然后沿着LayoutNodeWrapper 链去测量,链的每一个节点根据上一个节点传来的约束进行一次宽高计算,一直到最后的InnerPlaceable的测量,它同样是根据传入的约束计算宽高,然后会测量 children,测量完所以的 chlidren之后得到一个测量结果,根据这个测量结果,InnerPlaceable 再一次进行计算宽高。然后把最终的宽高信息返回给上一个节点,上一个节点根据返回的测量结果信息重新计算宽高,沿着 LayoutNodeWrapper 链反向的返回测量结果,每个节点重新计算后再把结果返回给上一级,一直到 OuterMeasurablePlaceable,它再拿到测量结果重新计算宽高 OuterMeasurablePlaceable 的宽高就是 LayoutNode 的宽高,整个宽高确认的流程大致就是这样了。

Jetpack compose 测量流程-宽高简易流程图

👆 节点宽高简易流程图

每一个节点都会根据Constraints 约束计算记一次宽高,同时也把这个约束条件记录了下来,然后根据测量的结果再一次计算宽高,仔细看计算宽高的逻辑你就会发现,大致的原因是这样的,先是按照约束的最小值计算宽高,比如约束是 Constraints(minWidth = 80, maxWidth = 120, minHeight = 90, maxHeight = 150) 那么此时宽高值分别是80,90。经过测量返回宽高结果是100,120,拿这个值和原来记录的约束进行比较,发现宽高的值都在对应的约束范围内,那最终的宽高值就以测量结果的宽高值为准,如果测量结果不在约束范围内,那宽高就取约束条件中对应的最小值或最大值。记录约束条件的目的就是防止测量结果超过此限制。

总结回顾


本文通过追踪Layout 源码,通过分析解答了一些问题,下面简单再回顾一下。

1.布局中通过 modifier 设置大小是如何起到作用的 ?

答:是在 ModifiedLayoutNode 的测量函数中调用 LayoutModifier 的测量函数中起到作用的,比如 SizeModifer 的 measure 函数。详细分析见上文。

2.MeasurePolicy 接口的 measure 方法是怎么调用的?

答:是在 InnerPlaceable 的measure 函数中调用的。详细分析见上文。

3.布局中的测量流程是什么样的及宽高的确认?

答:见图-2 测量流程图和图-3 节点宽高计算代码流程图。详细分析见上文。

最后


小编学习提升时,顺带从网上收集整理了一些 Android 开发相关的学习文档、面试题、Android 核心笔记等等文档,希望能帮助到大家学习提升,如有需要参考的可以直接去我 CodeChina地址:https://codechina.csdn.net/u012165769/Android-T3 访问查阅。

这里我就分享一份资料,希望可以帮助到大家提升进阶。

内容包含:Android学习PDF+架构视频+面试文档+源码笔记高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 这几块的内容。分享给大家,非常适合近期有面试和想在技术道路上继续精进的朋友。

如果你有需要的话,可以点击Android学习PDF+架构视频+面试文档+源码笔记获取免费领取方式

喜欢本文的话,不妨给我点个小赞、评论区留言或者转发支持一下呗~

img