Need of ViewCompositionStrategy in Jetpack Compose

Photo by Chris Ried on Unsplash

At first:

• Using ComponentActivity with setContent: No need for ViewCompositionStrategy. The Compose framework handles the lifecycle automatically.
• Embedding Compose in traditional Views: Use ViewCompositionStrategy to manage the composition lifecycle explicitly.

What is the role of ViewCompositionStrategy?

In the traditional Android view system, detaching a view from the window stops certain activities but does not fully release all resources. Proper management of these resources is crucial to avoid memory leaks and ensure efficient performance. In Jetpack Compose, ViewCompositionStrategy provides a way to handle this explicitly, ensuring that Compose compositions are disposed of appropriately, aligning with the lifecycle of the host view.

What Happens When a View is Detached from the Window?

1. Drawing and Layout: When a view is detached from the window, it no longer participates in the drawing and layout process. The view’s onDetachedFromWindow method is called, indicating it is no longer visible or part of the view hierarchy.
2. Input Handling: The view stops receiving input events like touch, keyboard, and other gestures. The view’s listeners and handlers for input events are no longer active.
3. Animation: Any ongoing animations associated with the view are typically stopped. The view will not animate while it is detached.
4. Reference Retention: The view itself and its internal data structures may still retain references to resources such as bitmaps, drawables, context objects, and other views. This is where additional cleanup might be necessary.

Why Additional Cleanup Might Be Necessary

Even though a detached view stops certain activities, it doesn’t mean that it automatically releases all resources. Here’s why:

1. Memory Leaks: Views can hold references to context, data, and other views. If not properly cleaned up, these references can lead to memory leaks, where memory is not reclaimed by the garbage collector because of lingering references.
2. Resource Management: Views often use significant resources (e.g., bitmap memory, network connections). These resources need explicit release to avoid memory bloat and performance issues.
3. Reattachment: Detached views can be reattached to the window (e.g., a view that is temporarily removed and then added back). If the view still holds onto its resources, it can be reused efficiently. However, if the view is not going to be reattached, holding onto resources is wasteful.

ViewCompositionStrategies

1. DisposeOnDetachedFromWindow
The Composition will be disposed when the underlying ComposeView is detached from the window.
   Interop scenario:
   * ComposeView whether it’s the sole element in the View hierarchy, or in the context of a mixed View/Compose screen (not in Fragment).
2. DisposeOnDetachedFromWindowOrReleasedFromPool (Default)
   The composition will be disposed automatically when the view is detached from a window, unless it is part of a pooling container, such as RecyclerView. When not within a pooling container, this behaves exactly the same as DisposeOnDetachedFromWindow.
   Interop scenario:
   * ComposeView whether it's the sole element in the View hierarchy, or in the context of a mixed View/Compose screen (not in Fragment).
   * ComposeView as an item in a pooling container such as RecyclerView.
3. DisposeOnLifecycleDestroyed
ViewCompositionStrategy that disposes the composition when lifecycle is destroyed. This strategy is appropriate for Compose UI views that share a 1-1 relationship with a known LifecycleOwner.
   Interop scenario:
   * ComposeView in a Fragment's View.
4. DisposeOnViewTreeLifecycleDestroyed
   The Composition will be disposed when the Lifecycle owned by the LifecycleOwner returned by ViewTreeLifecycleOwner.get of the next window the View is attached to is destroyed.
   Interop scenario:
   * ComposeView in a Fragment's View.
   * ComposeView in a View wherein the Lifecycle is not known yet.
   eg:

Thank you so much 🎉