<div id="readability-page-1" class="page"><div><div><h2 id="9843" data-testid="storyTitle">Compose Visibility API</h2><div tabindex="-1" aria-hidden="false" role="tooltip"><a rel="noopener follow" href="/@hongbeomi?source=post_page---byline--0789ef7b08bf---------------------------------------" data-discover="true"><div><p><img alt="hongbeom" src="https://miro.medium.com/v2/resize:fill:64:64/1*Mok6UmeBD0xatCqaYrkAUQ.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></p></div></a></div></div><p id="4dcf">Google I/O 2025에서 공개된 Compose Visibility API에 대해 살펴봅니다</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div><figcaption>Photo by <a href="https://unsplash.com/@beckerworks?utm_source=medium&amp;utm_medium=referral" rel="noopener ugc nofollow" target="_blank">David Becker</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral" rel="noopener ugc nofollow" target="_blank">Unsplash</a></figcaption></figure><p id="775f">Compose에서 visibility<strong> </strong>기능은 영상 재생/정지 제어, 노출(impression) 로깅, 애니메이션 제어 등 다양한 상황에서 composable이<strong> </strong>실제 사용자에게 얼마나 보이는지를 판단하고 적절한 동작을 수행할 수 있게 해주는 핵심 기능입니다. 과거에는 이 기능을 구현하기 위해 커스텀 <code>Modifier.Node</code>를 직접 구현하여 작성하거나, (원문 링크 참고)</p><pre><span id="09e1">// onGloballyPositioned에서 직접 bound를 계산<br>private class VisibilityTrackerNode(<br>    var thresholdPercentage: Float,<br>    var onVisibilityChanged: (VisibilityInfo) -&gt; Unit,<br>) : Modifier.Node(), GlobalPositionAwareModifierNode {<p>    private var previousVisibilityPercentage: Float? = null<br>    private val minimumVisibilityDelta = 0.01f</p><p>    override fun onGloballyPositioned(coordinates: LayoutCoordinates) {<br>        val boundsInWindow = coordinates.boundsInWindow()<br>        val parentBounds = coordinates.parentLayoutCoordinates?.boundsInWindow()</p><p>        if (parentBounds == null || !coordinates.isAttached) {<br>            previousVisibilityPercentage = 0f<br>            return<br>        }</p><p>        val visibleLeft = max(boundsInWindow.left, parentBounds.left)<br>        val visibleRight = min(boundsInWindow.right, parentBounds.right)<br>        val visibleTop = max(boundsInWindow.top, parentBounds.top)<br>        val visibleBottom = min(boundsInWindow.bottom, parentBounds.bottom)</p><p>        val visibleWidth = max(0f, visibleRight - visibleLeft)<br>        val visibleHeight = max(0f, visibleBottom - visibleTop)</p><p>        val visibleArea = visibleWidth * visibleHeight<br>        val totalArea = (coordinates.size.width * coordinates.size.height).toFloat().takeIf { it &gt; 0 } ?: return</p><p>        ... 생략<br>    }<br>}</p></span></pre><p id="04c4">로컬 캐시를 만들고 캐시를 통해 tracking 하는 방법 등의 다양한 방식을 사용하곤 했습니다. 하지만 이 방식들은 직접 throttling/debounce 로직이나 visible fraction 조건 등을 모두 구현해야 해서, 코드가 복잡해지고 재사용성도 낮아지는 단점이 있었습니다.</p><p id="3070">Google I/O 2025에서는 이러한 접근법을 대체할 수 있는 compose visibility API가 소개되었습니다.</p><figure></figure><p id="eef4">이 새로운 visibility API는 내부적으로 <code>onLayoutRectChanged</code> 기반의 위치 추적과 throttling/debounce 로직을 결합한 것으로, 간단한 <code>modifier</code> 수정자 한 줄만으로 복잡한 visibility 판단을 처리할 수 있는 장점이 있습니다.</p></div><div><h2 id="ec2e">OnLayoutRectChanged</h2><p id="57c8">첫 번째로 소개된 API는 <code>OnLayoutRectChanged</code> 입니다. 이 API는 저수준 API로서 window나 root 또는 screen 내에서 현재 Composable의 위치, 가시성 추적에 유용하게 사용할 수 있습니다.</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><p id="859b">Compose의 <code>onLayoutRectChanged</code>는 <code>onGloballyPositioned</code>와 유사하지만, 두 가지 추가 파라미터를 지원한다는 점에서 사용성이 차별화됩니다.</p><ul><li id="6f4f"><code>throttleMillis</code>: 이 시간(밀리초) 동안 콜백이 한 번만 실행되도록 호출 빈도를 제한합니다.</li><li id="1e46"><code>debounceMillis</code>: 마지막 위치 변화 이후 지정 시간(ms) 동안 새로운 변화가 없으면 콜백을 한 번만 실행합니다.</li></ul><p id="e958">또한 콜백에서 사용되는 <code>RelativeLayoutBounds</code>는 <code>calculateOcclusions()</code>라는 함수를 제공하는데, 이 함수는 부모나 자식 관계가 아닌 다른 Composable과 겹치는 경우, 그 교차 영역을 Z‑index 기준으로 계산하여 <code>IntRect</code> 를 리스트 타입으로 반환합니다. 다만, 이 API는 <code>measure</code>나 <code>layout</code> 단계에서 호출 시 최신 레이아웃 정보가 반영되지 않을 수 있으므로, 콜백 내부에서 사용하는 것이 안전합니다.</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><p id="d32b">위 예시처럼 Green <code>Box</code>위에 Magenta <code>Box</code>를 겹쳐서 그렸을 경우 Magenta <code>Box</code>의 <code>IntRect</code>가 출력됩니다.</p><p id="a5f1">이번엔 Magent <code>Box</code> 가 오른쪽에 그려지도록 코드를 수정해보겠습니다.</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><figure></figure><p id="db0a">당연하게도, 겹치는 영역에 대한 정보가 비어있는 것을 확인할 수 있습니다.</p><p id="5323">⚠️ 주의할 점은 해당 API는 레이아웃 정보를 이용하여 영역 정보를 계산하기 때문에, <code><strong>offset</strong></code><strong> 같은 시각적 이동에 대한 API를 사용할 경우엔 결과가 예상과 다를</strong> 수 있습니다.</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><p id="6cfa">화면을 보는 사용자에게는 겹쳐진 <code>Box</code>가 없지만, 레이아웃 정보 상으로는 두 <code>Box</code>가 겹쳐져 있기에 <code>Rect</code>가 표시됩니다.</p><h2 id="7eeb">How?</h2><p id="4574"><code>OnLayoutRectChanged</code>는 어떻게 visibiliy 정보를 노출하며 <code>throttle</code>, <code>debounce</code> 작업도 수행할 수 있는지 이해하기 위해 내부 코드를 살펴보겠습니다. 먼저 우리가 <code>Modifier.onLayoutRectChanged</code> 를 사용하면 아래와 같은 코드를 통해 <code>Element</code>가 등록됩니다.</p><pre><span id="1a8b">@Stable<br>fun Modifier.onLayoutRectChanged(<br>    throttleMillis: Long = 0,<br>    debounceMillis: Long = 64,<br>    callback: (RelativeLayoutBounds) -&gt; Unit<br>) = this then OnLayoutRectChangedElement(throttleMillis, debounceMillis, callback)</span></pre><p id="01a9">이 <code>Element</code>는<code><strong>OnLayoutRectChangedNode</strong></code> 타입의 <code>ModifierNodeElement</code> 인데, 이 <code>Node</code>는 내부에서 <code>registerOnLayoutRectChanged</code> 라는 함수를 호출합니다.</p><pre><span id="6c96">private data class OnLayoutRectChangedElement(<br>    val throttleMillis: Long,<br>    val debounceMillis: Long,<br>    val callback: (RelativeLayoutBounds) -&gt; Unit<br>) : ModifierNodeElement&lt;OnLayoutRectChangedNode&gt;() { ... }<p>private class OnLayoutRectChangedNode(<br>    var throttleMillis: Long,<br>    var debounceMillis: Long,<br>    var callback: (RelativeLayoutBounds) -&gt; Unit,<br>) : Modifier.Node() {</p><p>  fun disposeAndRegister() {<br>    ...<br>    handle = registerOnLayoutRectChanged(<br>      throttleMillis, <br>      debounceMillis,<br>      callback<br>    ) <br>  }<br>  ...<br>}</p></span></pre><p id="c4e4">이 <code>registerOnLayoutRectChanged</code> 함수의 내부를 보면 현재 Composable owner의 <code>rectManager</code>라는 객체에 콜백을 등록하는 것을 확인할 수 있습니다.</p><pre><span id="e000">fun DelegatableNode.registerOnLayoutRectChanged(<br>    throttleMillis: Long,<br>    debounceMillis: Long,<br>    callback: (RelativeLayoutBounds) -&gt; Unit,<br>): RegistrationHandle {<br>    val layoutNode = requireLayoutNode()<br>    val id = layoutNode.semanticsId<br>    val rectManager = layoutNode.requireOwner().rectManager<br>    return rectManager.registerOnRectChangedCallback(<br>        id,<br>        throttleMillis,<br>        debounceMillis,<br>        this,<br>        callback,<br>    )<br>}</span></pre><p id="e719">이 <code>RectManager</code>라는 객체는 컴포즈 내부에서 사용되는 객체인데, <code>Owner</code> 인터페이스의 필드로 존재하며 결국 <code>Owner</code>의 구현체인 <code>AndroidComposeView</code>에 의해 관리됩니다. 이 객체는 특정 <code>LayoutNode</code>가 <code>AndroidComposeView</code>에 추가/제거 되거나 재사용될 때 해당 <code>Node</code>의 정보를 <code>map</code> 객체로 관리하고 있습니다.</p><pre><span id="ef3f">// layoutNode에 대한 정보를 map 객체로 가지고 있음.<br>internal class RectManager(<br>    private val layoutNodes: IntObjectMap&lt;LayoutNode&gt; = intObjectMapOf(),<br>) { ... }<p>// Owner interface<br>internal interface Owner : PositionCalculator {<br>  ...<br>  val rectManager: RectManager<br>}</p><p>// Owner interface의 구현체<br>internal class AndroidComposeView(<br>  context: Context,<br>  coroutineContext: CoroutineContext<br>) : ..., Owner, ... { ... }</p></span></pre><p id="3f40">다시 돌아가서, 위에서 살펴봤던 <code>registerOnLayoutRectChange</code> 함수 내부에서 <code>RectManager</code>가 호출하는 <code>registerOnRectChangedCallback</code>으로 이동해보면 <code>RectManager</code> 내부의 <code>throttledCallbacks</code>이라는 객체에 다시 <code>registerOnRectChanged</code>로 콜백이 등록되는 것을 볼 수 있고, 이 <code>ThrottledCallbacks</code>는 내부에서 필요한 정보들을 <code>map</code> 객체로 관리하는 것을 알 수 있습니다.</p><pre><span id="d104">internal class RectManager(...) {<br>  ...<br>  private val throttledCallbacks = ThrottledCallbacks()<p>  fun registerOnRectChangedCallback(<br>    id: Int,<br>    throttleMillis: Long,<br>    debounceMillis: Long,<br>    node: DelegatableNode,<br>    callback: (RelativeLayoutBounds) -&gt; Unit<br>  ): RegistrationHandle {<br>    return throttledCallbacks.registerOnRectChanged(<br>      id,<br>      throttleMillis,<br>      debounceMillis,<br>      node,<br>      callback,<br>    )<br>  }<br>  ...<br>}</p><p>// map으로 콜백 정보를 관리함.<br>internal class ThrottledCallbacks {<br>  ... <br>  val rectChangedMap = mutableIntObjectMapOf&lt;Entry&gt;()</p><p>  fun registerOnRectChanged(<br>    id: Int,<br>    throttleMillis: Long,<br>    debounceMillis: Long,<br>    node: DelegatableNode,<br>    callback: (RelativeLayoutBounds) -&gt; Unit,<br>  ): RegistrationHandle {<br>    ...<br>    return rectChangedMap.multiPut(...)<br>  }<br>  ...<br>}</p></span></pre><p id="4d7a">종합적으로 사용되는 객체들의 관계를 간단한 그림으로 살펴보면 아래와 같습니다. (실제로는 더 다양한 함수들이 서로 상호 작용하고 있으나, 이 글에서는 핵심적인 부분만 살펴보고 넘어가겠습니다)</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure></div><div><p id="f365">이제 추가된 몇 가지 고수준 API를 살펴보겠습니다.</p><h2 id="4e1f">onVisibilityChanged</h2><p id="2bcb">먼저, <code>onVisibilityChanged</code>입니다. 이 API는 <a href="https://developer.android.com/jetpack/androidx/releases/compose-foundation?hl=ko#1.9.0-alpha03" rel="noopener ugc nofollow" target="_blank">compose-foundation 1.9.0-alpha03</a> 버전에 포함되어 있으며, 가시성에 대한 정보를 쉽게 사용할 수 있도록 제공해줍니다.</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><p id="031d">제공되는 파라미터는 다음과 같습니다.</p><ul><li id="a93e"><code>minDurationMs</code>: 해당 노드가 visible 상태로 간주되기 전에, 어느 정도의 시간 동안 보여지는 것을 기다릴지 설정합니다. 빠르게 스크롤할 때 잠깐 보였다가 사라지는 상태를 필터링할 때 유용하게 사용할 수 있습니다.</li><li id="80f3"><code>minFractionVisible</code>: 노드 영역의 몇 퍼센트가 <code>viewport</code> 내에 있어야 visible 상태로 간주할지 설정합니다. <code>1f</code>는 전체가 보여야, <code>0f</code>는 아주 조금이라도 보이면 콜백이 실행됩니다.</li><li id="bde8"><code>viewportBounds</code>: 어떤 영역(<code>viewport</code>)을 기준으로 측정할지 지정할 수 있습니다. 네비게이션 바처럼 특정 UI가 컨트롤되어야 할 경우에 활용할 수 있습니다. <code>null</code>이면 기본적으로 애플리케이션 window 전체가 <code>viewport</code>로 사용됩니다</li><li id="8a04"><code>callback</code> : visible 여부가 <code>minFractionVisible</code> 기준을 넘을 때와 넘어가지 않을 때 호출되는 람다입니다.</li></ul><p id="a8b5">내부적으로는 위에서 살펴봤던 <code>registerOnLayoutRectChanged</code>를 사용하고 있습니다.</p><pre><span id="b22b">internal class OnVisibilityChangedNode(...) {<br>  ...<br>  override fun onAttach() {<br>    ...<br>    handle = registerOnLayoutRectChanged(0, 0, rectChanged)<br>  }<br>}</span></pre></div><div><h2 id="3082">onFirstVisible</h2><p id="c9f2"><code>onFirstVisible</code> API는 해당 노드가 window의 viewport 내에 처음 진입할 때 지정한 콜백이 호출되는 API 입니다. 마찬가지로 <a href="https://developer.android.com/jetpack/androidx/releases/compose-foundation?hl=ko#1.9.0-alpha03" rel="noopener ugc nofollow" target="_blank">compose-foundation 1.9.0-alpha03</a> 버전에 포함되어 있으며, 첫 진입 시 애니메이션 동작, 해당 컴포저블의 노출 횟수 카운팅 등등의 예시에서 응용해볼 수 있습니다.</p><figure><div role="button" tabindex="0"><p><span>Zoom image will be displayed</span></p></div></figure><p id="573c">제공되는 파라미터는 <code>onVisibilityChanged</code> API와 동일합니다.</p></div><div><h2 id="5ce6">마치며</h2><p id="1917">결론적으로 최신 Compose visibility API는 직관적이면서도 강력한 기능을 제공합니다. 이제 낮은 오버헤드로 영상 자동 재생이나 로깅 같은 visibility 기반 UI를 쉽게 구현할 수 있을 것 같습니다. 따라서 해당하는 사용 사례에 맞추어 적절한 API를 사용하여 코드를 구성하는 것이 좋겠습니다.🍺</p></div></div>

Stories by hongbeom on Medium

Google I/O 2025에서 공개된 Compose Visibility API에 대해 살펴봅니다
Compose에서 visibility 기능은 영상 재생/정지 제어, 노출(impression) 로깅, 애니메이션 제어 등 다양한 상황에서 composable이 실제 사용자에게 얼마나 보이는지를 판단하고 적절한 동작을 수행할 수 있게 해주는 핵심 기능입니다. 과거에는 이 기능을 구현하기 위해 커스텀 Modifier.Node를 직접 구현하여 작성하거나, (원문 링크 참고)
How to Track Composable Visibility in Jetpack Compose - with a custom .trackVisibility Modifier
// onGloballyPositioned에서 직접 bound를 계산
private class VisibilityTrackerNode(
    var thresholdPercentage: Float,
    var onVisibilityChanged: (VisibilityInfo) -> Unit,
) : Modifier.Node(), GlobalPositionAwareModifierNode {
    private var previousVisibilityPercentage: Float? = null
    private val minimumVisibilityDelta = 0.01f
    override fun onGloballyPositioned(coordinates: LayoutCoordinates) {
        val boundsInWindow = coordinates.boundsInWindow()
        val parentBounds = coordinates.parentLayoutCoordinates?.boundsInWindow()
        if (parentBounds == null || !coordinates.isAttached) {
            previousVisibilityPercentage = 0f
            return
        }
        val visibleLeft = max(boundsInWindow.left, parentBounds.left)
        val visibleRight = min(boundsInWindow.right, parentBounds.right)
        val visibleTop = max(boundsInWindow.top, parentBounds.top)
        val visibleBottom = min(boundsInWindow.bottom, parentBounds.bottom)
        val visibleWidth = max(0f, visibleRight - visibleLeft)
        val visibleHeight = max(0f, visibleBottom - visibleTop)
        val visibleArea = visibleWidth * visibleHeight
        val totalArea = (coordinates.size.width * coordinates.size.height).toFloat().takeIf { it > 0 } ?: return
        ... 생략
    }
}
로컬 캐시를 만들고 캐시를 통해 tracking 하는 방법 등의 다양한 방식을 사용하곤 했습니다. 하지만 이 방식들은 직접 throttling/debounce 로직이나 visible fraction 조건 등을 모두 구현해야 해서, 코드가 복잡해지고 재사용성도 낮아지는 단점이 있었습니다.
Google I/O 2025에서는 이러한 접근법을 대체할 수 있는 compose visibility API가 소개되었습니다.
https://medium.com/media/a1f6858fc0ee27fe0f327af61822883c/href
이 새로운 visibility API는 내부적으로 onLayoutRectChanged 기반의 위치 추적과 throttling/debounce 로직을 결합한 것으로, 간단한 modifier 수정자 한 줄만으로 복잡한 visibility 판단을 처리할 수 있는 장점이 있습니다.
OnLayoutRectChanged
첫 번째로 소개된 API는 OnLayoutRectChanged 입니다. 이 API는 저수준 API로서 window나 root 또는 screen 내에서 현재 Composable의 위치, 가시성 추적에 유용하게 사용할 수 있습니다.
Compose의 onLayoutRectChanged는 onGloballyPositioned와 유사하지만, 두 가지 추가 파라미터를 지원한다는 점에서 사용성이 차별화됩니다.
throttleMillis: 이 시간(밀리초) 동안 콜백이 한 번만 실행되도록 호출 빈도를 제한합니다.
debounceMillis: 마지막 위치 변화 이후 지정 시간(ms) 동안 새로운 변화가 없으면 콜백을 한 번만 실행합니다.
또한 콜백에서 사용되는 RelativeLayoutBounds는 calculateOcclusions()라는 함수를 제공하는데, 이 함수는 부모나 자식 관계가 아닌 다른 Composable과 겹치는 경우, 그 교차 영역을 Z‑index 기준으로 계산하여 IntRect 를 리스트 타입으로 반환합니다. 다만, 이 API는 measure나 layout 단계에서 호출 시 최신 레이아웃 정보가 반영되지 않을 수 있으므로, 콜백 내부에서 사용하는 것이 안전합니다.
위 예시처럼 Green Box위에 Magenta Box를 겹쳐서 그렸을 경우 Magenta Box의 IntRect가 출력됩니다.
이번엔 Magent Box 가 오른쪽에 그려지도록 코드를 수정해보겠습니다.
당연하게도, 겹치는 영역에 대한 정보가 비어있는 것을 확인할 수 있습니다.
⚠️ 주의할 점은 해당 API는 레이아웃 정보를 이용하여 영역 정보를 계산하기 때문에, offset 같은 시각적 이동에 대한 API를 사용할 경우엔 결과가 예상과 다를 수 있습니다.
화면을 보는 사용자에게는 겹쳐진 Box가 없지만, 레이아웃 정보 상으로는 두 Box가 겹쳐져 있기에 Rect가 표시됩니다.
How?
OnLayoutRectChanged는 어떻게 visibiliy 정보를 노출하며 throttle, debounce 작업도 수행할 수 있는지 이해하기 위해 내부 코드를 살펴보겠습니다. 먼저 우리가 Modifier.onLayoutRectChanged 를 사용하면 아래와 같은 코드를 통해 Element가 등록됩니다.
@Stable
fun Modifier.onLayoutRectChanged(
    throttleMillis: Long = 0,
    debounceMillis: Long = 64,
    callback: (RelativeLayoutBounds) -> Unit
) = this then OnLayoutRectChangedElement(throttleMillis, debounceMillis, callback)
이 Element는OnLayoutRectChangedNode 타입의 ModifierNodeElement 인데, 이 Node는 내부에서 registerOnLayoutRectChanged 라는 함수를 호출합니다.
private data class OnLayoutRectChangedElement(
    val throttleMillis: Long,
    val debounceMillis: Long,
    val callback: (RelativeLayoutBounds) -> Unit
) : ModifierNodeElement<OnLayoutRectChangedNode>() { ... }
private class OnLayoutRectChangedNode(
    var throttleMillis: Long,
    var debounceMillis: Long,
    var callback: (RelativeLayoutBounds) -> Unit,
) : Modifier.Node() {
  fun disposeAndRegister() {
    ...
    handle = registerOnLayoutRectChanged(
      throttleMillis, 
      debounceMillis,
      callback
    ) 
  }
  ...
}
이 registerOnLayoutRectChanged 함수의 내부를 보면 현재 Composable owner의 rectManager라는 객체에 콜백을 등록하는 것을 확인할 수 있습니다.
fun DelegatableNode.registerOnLayoutRectChanged(
    throttleMillis: Long,
    debounceMillis: Long,
    callback: (RelativeLayoutBounds) -> Unit,
): RegistrationHandle {
    val layoutNode = requireLayoutNode()
    val id = layoutNode.semanticsId
    val rectManager = layoutNode.requireOwner().rectManager
    return rectManager.registerOnRectChangedCallback(
        id,
        throttleMillis,
        debounceMillis,
        this,
        callback,
    )
}
이 RectManager라는 객체는 컴포즈 내부에서 사용되는 객체인데, Owner 인터페이스의 필드로 존재하며 결국 Owner의 구현체인 AndroidComposeView에 의해 관리됩니다. 이 객체는 특정 LayoutNode가 AndroidComposeView에 추가/제거 되거나 재사용될 때 해당 Node의 정보를 map 객체로 관리하고 있습니다.
// layoutNode에 대한 정보를 map 객체로 가지고 있음.
internal class RectManager(
    private val layoutNodes: IntObjectMap<LayoutNode> = intObjectMapOf(),
) { ... }
// Owner interface
internal interface Owner : PositionCalculator {
  ...
  val rectManager: RectManager
}
// Owner interface의 구현체
internal class AndroidComposeView(
  context: Context,
  coroutineContext: CoroutineContext
) : ..., Owner, ... { ... }
다시 돌아가서, 위에서 살펴봤던 registerOnLayoutRectChange 함수 내부에서 RectManager가 호출하는 registerOnRectChangedCallback으로 이동해보면 RectManager 내부의 throttledCallbacks이라는 객체에 다시 registerOnRectChanged로 콜백이 등록되는 것을 볼 수 있고, 이 ThrottledCallbacks는 내부에서 필요한 정보들을 map 객체로 관리하는 것을 알 수 있습니다.
internal class RectManager(...) {
  ...
  private val throttledCallbacks = ThrottledCallbacks()
  fun registerOnRectChangedCallback(
    id: Int,
    throttleMillis: Long,
    debounceMillis: Long,
    node: DelegatableNode,
    callback: (RelativeLayoutBounds) -> Unit
  ): RegistrationHandle {
    return throttledCallbacks.registerOnRectChanged(
      id,
      throttleMillis,
      debounceMillis,
      node,
      callback,
    )
  }
  ...
}
// map으로 콜백 정보를 관리함.
internal class ThrottledCallbacks {
  ... 
  val rectChangedMap = mutableIntObjectMapOf<Entry>()
  fun registerOnRectChanged(
    id: Int,
    throttleMillis: Long,
    debounceMillis: Long,
    node: DelegatableNode,
    callback: (RelativeLayoutBounds) -> Unit,
  ): RegistrationHandle {
    ...
    return rectChangedMap.multiPut(...)
  }
  ...
}
종합적으로 사용되는 객체들의 관계를 간단한 그림으로 살펴보면 아래와 같습니다. (실제로는 더 다양한 함수들이 서로 상호 작용하고 있으나, 이 글에서는 핵심적인 부분만 살펴보고 넘어가겠습니다)
이제 추가된 몇 가지 고수준 API를 살펴보겠습니다.
onVisibilityChanged
먼저, onVisibilityChanged입니다. 이 API는 compose-foundation 1.9.0-alpha03 버전에 포함되어 있으며, 가시성에 대한 정보를 쉽게 사용할 수 있도록 제공해줍니다.
제공되는 파라미터는 다음과 같습니다.
minDurationMs: 해당 노드가 visible 상태로 간주되기 전에, 어느 정도의 시간 동안 보여지는 것을 기다릴지 설정합니다. 빠르게 스크롤할 때 잠깐 보였다가 사라지는 상태를 필터링할 때 유용하게 사용할 수 있습니다.
minFractionVisible: 노드 영역의 몇 퍼센트가 viewport 내에 있어야 visible 상태로 간주할지 설정합니다. 1f는 전체가 보여야, 0f는 아주 조금이라도 보이면 콜백이 실행됩니다.
viewportBounds: 어떤 영역(viewport)을 기준으로 측정할지 지정할 수 있습니다. 네비게이션 바처럼 특정 UI가 컨트롤되어야 할 경우에 활용할 수 있습니다. null이면 기본적으로 애플리케이션 window 전체가 viewport로 사용됩니다
callback : visible 여부가 minFractionVisible 기준을 넘을 때와 넘어가지 않을 때 호출되는 람다입니다.
내부적으로는 위에서 살펴봤던 registerOnLayoutRectChanged를 사용하고 있습니다.
internal class OnVisibilityChangedNode(...) {
  ...
  override fun onAttach() {
    ...
    handle = registerOnLayoutRectChanged(0, 0, rectChanged)
  }
}
onFirstVisible
onFirstVisible API는 해당 노드가 window의 viewport 내에 처음 진입할 때 지정한 콜백이 호출되는 API 입니다. 마찬가지로 compose-foundation 1.9.0-alpha03 버전에 포함되어 있으며, 첫 진입 시 애니메이션 동작, 해당 컴포저블의 노출 횟수 카운팅 등등의 예시에서 응용해볼 수 있습니다.
제공되는 파라미터는 onVisibilityChanged API와 동일합니다.
마치며
결론적으로 최신 Compose visibility API는 직관적이면서도 강력한 기능을 제공합니다. 이제 낮은 오버헤드로 영상 자동 재생이나 로깅 같은 visibility 기반 UI를 쉽게 구현할 수 있을 것 같습니다. 따라서 해당하는 사용 사례에 맞추어 적절한 API를 사용하여 코드를 구성하는 것이 좋겠습니다.🍺
Compose Visibility API was originally published in hongbeomi dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Compose Visibility API

댓글