Why Your LazyColumn Drops Frames — Part 2: Hidden Patterns

  

Why Your LazyColumn Drops Frames — Part 2: Hidden Patterns

A engineer’s guide to the architectural traps that survive code review

In Part 1, we tackled the four foundation issues that cause 80% of LazyColumn performance problems: missing keys, unstable data classes, lambda allocations, and computation during composition.

You’ve implemented those fixes.

Your Layout Inspector shows fewer recompositions. Your keys are stable. Your state is immutable.

Yet when you profile on a mid-range device, you still see frame drops during rapid scrolling.

Here’s why: The patterns you’re using look architecturally sound. They pass code review. They follow Compose best practices. But they hide subtle performance costs that compound at scale.

This is Part 2, where we explore the architectural and structural decisions that experienced engineers make — patterns that seem intelligent but create invisible performance penalties.

These aren’t bugs. They’re design choices with non-obvious trade-offs.

The Architectural Reality

Foundation fixes (Part 1) handle what triggers recomposition.

Architectural patterns (Part 2) determine how much work each recomposition does.

The difference between a LazyColumn that “works fine in development” and one that “feels native on a Galaxy A53” is often these five patterns.

5️⃣ The derivedStateOf Anti-Pattern Nobody Warns You About

❌ The Seemingly Smart Optimization

@Composable
fun MessageList(messages: List<Message>) {
    val searchQuery by searchViewModel.query.collectAsState()
    
    // "I'll only recompose when filtered results change!"
    val filteredMessages by remember(messages, searchQuery) {
        derivedStateOf {
            messages.filter { 
                it.content.contains(searchQuery, ignoreCase = true) 
            }
        }
    }
    
    LazyColumn {
        items(
            items = filteredMessages,
            key = { it.id }
        ) { message ->
            MessageCard(message)
        }
    }
}

Why this looks correct:

• Uses derivedStateOf for “smart” updates
• Only recalculates when dependencies change
• Appears to follow Compose best practices

The invisible problem:

derivedStateOf recalculates during composition, on the main thread. If you have 10,000 items:

• Every scroll event that causes recomposition
• Triggers the filter lambda evaluation
• Even if searchQuery hasn’t changed
• Creates GC pressure from intermediate lists
• Blocks the composition thread

🔍 The Real-World Impact

In a production messaging app with 5,000 conversations:

• Scroll event triggers recomposition
• derivedStateOf re-evaluates filter (even though query unchanged)
• ~8–12ms per scroll frame just for filtering
• Visible stutter on Pixel 4a

✅ The Correct Pattern: ViewModel-Level State

class MessageViewModel : ViewModel() {
    private val _searchQuery = MutableStateFlow("")
    private val _messages = MutableStateFlow<List<Message>>(emptyList())
    
    val filteredMessages: StateFlow<List<MessageUiState>> = combine(
        _messages,
        _searchQuery
    ) { messages, query ->
        messages
            .asSequence()  // Avoid intermediate collections
            .filter { it.content.contains(query, ignoreCase = true) }
            .map { it.toUiState() }
            .toList()
    }
    .flowOn(Dispatchers.Default)  // Off main thread
    .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = emptyList()
    )
}

@Composable
fun MessageList(viewModel: MessageViewModel) {
    val filteredMessages by viewModel.filteredMessages.collectAsState()
    
    LazyColumn {
        items(
            items = filteredMessages,
            key = { it.id }
        ) { message ->
            MessageCard(message)
        }
    }
}

Why this works:

• Filtering happens once when state actually changes
• Runs on Dispatchers.Default (background thread)
• No work during scroll/recomposition
• No intermediate allocations during composition
• Compose just observes the result

6️⃣ The Hidden Cost of @Composable Functions Inside Items

❌ The Innocent Helper Function Pattern

@Composable
fun MessageCard(message: MessageUiState) {
    Column {
        MessageHeader(message)  // Looks clean and modular
        MessageBody(message)
        MessageFooter(message)
    }
}

@Composable
private fun MessageHeader(message: MessageUiState) {
    Row {
        Avatar(message.senderAvatar)
        Column {
            Text(message.senderName)
            Text(message.timestamp)
        }
    }
}

@Composable
private fun MessageBody(message: MessageUiState) {
    Text(message.contentText)
}

@Composable
private fun MessageFooter(message: MessageUiState) {
    Row {
        ReactionBar(message.reactions)
        ActionButtons(message)
    }
}

Why This Looks Correct

At first glance, this pattern feels like textbook Compose:

• Clear separation of concerns
• Small, reusable composables
• Idiomatic composition-based design
• Easy to read and maintain

Nothing here looks wrong — and that’s exactly why it’s dangerous.

The Non-Obvious Problem

Every @Composable function introduces a composition scope boundary. When those composables receive parameters that Compose cannot prove to be stable (for example, a MessageUiState containing a List or other unstable types), each boundary becomes a potential recomposition hotspot. Child composables may recompose independently of their parent—often more frequently and unpredictably.

In a list of just 50 items, this adds up fast:

• Parent MessageCard recomposes → 50 recompositions
• Each child (Header, Body, Footer) can recompose independently → 150+ recompositions
• ~3× recomposition overhead purely from scope boundaries
• Every boundary also carries its own composition cost

You’re not paying for slow code — you’re paying for structure.

🔍 How to Detect This

Use Layout Inspector with recomposition counts enabled:

MessageCard: 2 recompositions
├─ MessageHeader: 5 recompositions ⚠️
├─ MessageBody: 3 recompositions
└─ MessageFooter: 4 recompositions

✅ The Performance-Conscious Approach

@Immutable
data class MessageUiState(
    val id: String,
    val senderName: String,
    val senderAvatar: String,
    val contentText: String,
    val timestamp: String,
    val reactions: ImmutableList<ReactionUiState>,  // Not List<>!
    val canDelete: Boolean,
    val canEdit: Boolean
)

@Composable
fun MessageCard(
    state: MessageUiState,
    onReactionClick: (String) -> Unit,
    onDeleteClick: (String) -> Unit,
    modifier: Modifier = Modifier
) {
    // Inline layout for critical rendering path
    Column(modifier = modifier.padding(16.dp)) {
        // Header - inline instead of separate composable
        Row(
            modifier = Modifier.fillMaxWidth(),
            verticalAlignment = Alignment.CenterVertically
        ) {
            AsyncImage(
                model = state.senderAvatar,
                contentDescription = null,
                modifier = Modifier
                    .size(40.dp)
                    .clip(CircleShape)
            )
            Spacer(modifier = Modifier.width(12.dp))
            Column(modifier = Modifier.weight(1f)) {
                Text(
                    text = state.senderName,
                    style = MaterialTheme.typography.titleMedium
                )
                Text(
                    text = state.timestamp,
                    style = MaterialTheme.typography.bodySmall,
                    color = MaterialTheme.colorScheme.onSurfaceVariant
                )
            }
        }
        
        Spacer(modifier = Modifier.height(8.dp))
        
        // Body - inline
        Text(
            text = state.contentText,
            style = MaterialTheme.typography.bodyMedium
        )
        
        Spacer(modifier = Modifier.height(8.dp))
        
        // Footer - only extract if truly complex
        if (state.reactions.isNotEmpty()) {
            ReactionBar(
                reactions = state.reactions,
                onReactionClick = onReactionClick
            )
        }
    }
}

// Only extract composables when:
// 1. They're truly reusable across multiple screens
// 2. They have complex state management worth isolating
// 3. They're heavy enough that isolation provides clear benefit
@Composable
private fun ReactionBar(
    reactions: ImmutableList<ReactionUiState>,
    onReactionClick: (String) -> Unit
) {
    Row(
        modifier = Modifier.fillMaxWidth(),
        horizontalArrangement = Arrangement.spacedBy(8.dp)
    ) {
        reactions.forEach { reaction ->
            ReactionChip(
                reaction = reaction,
                onClick = { onReactionClick(reaction.id) }
            )
        }
    }
}

Key principles:

• Inline simple layouts in the critical path
• Only extract when complexity or reusability justify the overhead
• Use @Immutable or @Stable for all parameter types
• Minimize composition scope boundaries

Measured improvement:

• Recompositions reduced by ~40%
• Composition overhead per item: -3ms average

7️⃣ The Modifier Creation Tax (The Misdiagnosed Bottleneck)

❌ The Common Assumption

LazyColumn {
    items(messages, key = { it.id }) { message ->
        MessageCard(
            message = message,
            modifier = Modifier
                .fillMaxWidth()
                .padding(horizontal = 16.dp, vertical = 8.dp)
                .clip(RoundedCornerShape(12.dp))
                .background(MaterialTheme.colorScheme.surface)
                .clickable { onMessageClick(message.id) }
        )
    }
}

Why This Looks Like a Problem

• Modifiers are immutable and chained
• Each modifier call returns a new object
• LazyColumn items recompose during scroll
• It feels like this must be allocating heavily

This pattern often gets flagged during performance reviews as a “hidden allocation trap”.

✅ The Architectural Reality

Modifier allocations exist — but they are almost never the reason LazyColumn drops frames.

Important context:

• Modifier allocations are tiny
• They are short-lived and efficiently handled by ART
• LazyColumn reuses item compositions aggressively
• Recomposition does not automatically trigger layout or draw

In production profiling, modifier allocation rarely shows up as a dominant cost.

If your LazyColumn janks, modifier creation is usually not the root cause.

❌ The Real Mistake Engineers Make

The problem isn’t creating modifiers — 
it’s optimizing modifiers instead of fixing recomposition and layout work.

This leads to premature and sometimes harmful optimizations.

🚫 The Most Common Anti-Patterns

❌ Remembering static modifier chains

val cardModifier = remember {
    Modifier
        .fillMaxWidth()
        .padding(16.dp)
}

Why this is risky:

• Modifiers depend on density, layout direction, and theme
• Remembering them can produce stale or incorrect behavior
• Compose already optimizes modifier usage internally

Rule: Don’t remember modifiers unless profiling proves it helps.

❌ Manual modifier caches

class ModifierCache { ... }

This pattern:

• Adds architectural complexity
• Introduces correctness risks
• Solves a problem that rarely appears in real LazyColumn profiles

If modifier reuse were broadly necessary, Compose would expose first-class APIs for it.

⚠️ When Modifier Allocation Can Matter

Modifier creation becomes relevant only when all of the following are true:

• Large lists with frequent recomposition
• Heavy allocation elsewhere in the item
• Layout or draw work triggered during scroll
• Low-end or memory-constrained devices
• Verified via Android Studio Profiler

Without measurement, modifier optimization is speculative.

✅ The Correct LazyColumn Pattern

Prefer clear modifier chains + stable state.

@Composable
fun MessageCard(
    state: MessageUiState,
    modifier: Modifier = Modifier,
    onClick: () -> Unit
) {
    Card(
        modifier = modifier
            .fillMaxWidth()
            .padding(16.dp)
            .clickable(onClick = onClick)
    ) {
        // Content
    }
}

Why this works:

• Modifier creation is cheap
• Compose can skip recomposition and layout
• Performance scales predictably with list size

🔍 How to Validate This Properly

Before touching modifiers, check:

• Layout Inspector → recomposition counts
• Profiler → layout & measure time
• Profiler → GC during scroll

8️⃣ The contentType Parameter Everyone Ignores

This is possibly the most underutilized performance optimization in LazyColumn.

❌ Mixed Content Types Without Hints

sealed class FeedItem {
    data class TextPost(
        val id: String,
        val content: String,
        val author: String
    ) : FeedItem()
    
    data class ImagePost(
        val id: String,
        val imageUrl: String,
        val caption: String
    ) : FeedItem()
    
    data class VideoPost(
        val id: String,
        val videoUrl: String,
        val thumbnail: String
    ) : FeedItem()
    
    data class AdPost(
        val id: String,
        val adData: AdData
    ) : FeedItem()
}

@Composable
fun SocialFeed(feedItems: List<FeedItem>) {
    LazyColumn {
        items(
            items = feedItems,
            key = { it.id }
        ) { item ->
            when (item) {
                is TextPost -> TextPostCard(item)
                is ImagePost -> ImagePostCard(item)
                is VideoPost -> VideoPostCard(item)
                is AdPost -> AdCard(item)
            }
        }
    }
}

Why this looks correct:

• Proper sealed class hierarchy
• Type-safe when expression
• Stable keys provided

The invisible performance hit:

Compose pools and reuses compositions for performance. Without contentType, it tries to reuse a VideoPostCard composition for a TextPostCard, causing:

• Complete composition tear-down and recreation
• Expensive layout recalculation
• State loss and recreation
• Unnecessary work during scroll

🔍 The Problem in Detail

When scrolling a heterogeneous feed:

1. VideoPostCard scrolls off-screen (composition goes to pool)
2. TextPostCard scrolls on-screen
3. Compose tries to reuse the pooled VideoPostCard composition
4. Realizes types don’t match
5. Throws away the composition
6. Creates new TextPostCard from scratch

This happens on every scroll with mixed content types.

✅ The contentType Optimization

@Composable
fun SocialFeed(feedItems: List<FeedItem>) {
    LazyColumn {
        items(
            items = feedItems,
            key = { it.id },
            contentType = { item ->
                // Provide content type hint for composition pooling
                when (item) {
                    is TextPost -> ContentType.TEXT
                    is ImagePost -> ContentType.IMAGE
                    is VideoPost -> ContentType.VIDEO
                    is AdPost -> ContentType.AD
                }
            }
        ) { item ->
            when (item) {
                is TextPost -> TextPostCard(item)
                is ImagePost -> ImagePostCard(item)
                is VideoPost -> VideoPostCard(item)
                is AdPost -> AdCard(item)
            }
        }
    }
}

// Define content types as constants for reuse
private enum class ContentType {
    TEXT, IMAGE, VIDEO, AD
}

Even better with type-safe approach:

sealed class FeedItem {
    abstract val id: String
    abstract val contentType: String
    
    data class TextPost(...) : FeedItem() {
        override val contentType = "text"
    }
    
    data class ImagePost(...) : FeedItem() {
        override val contentType = "image"
    }
    
    data class VideoPost(...) : FeedItem() {
        override val contentType = "video"
    }
}

LazyColumn {
    items(
        items = feedItems,
        key = { it.id },
        contentType = { it.contentType }  // Simple and maintainable
    ) { item ->
        when (item) {
            is TextPost -> TextPostCard(item)
            is ImagePost -> ImagePostCard(item)
            is VideoPost -> VideoPostCard(item)
        }
    }
}

Why it’s so effective:

Compose now maintains separate composition pools for each content type. When scrolling:

• TextPostCard scrolls off → goes to “text” pool
• TextPostCard scrolls on → reused from “text” pool
• No cross-type reuse attempts
• Minimal composition overhead

9️⃣ Nested LazyRow Constraints Crisis

❌ The Common Horizontal Scroll Pattern

@Composable
fun CategoryList(categories: List<Category>) {
    LazyColumn {
        items(categories) { category ->
            Column {
                Text(
                    text = category.title,
                    style = MaterialTheme.typography.titleLarge,
                    modifier = Modifier.padding(16.dp)
                )
                
                // Nested horizontal list
                LazyRow {
                    items(category.products) { product ->
                        ProductCard(
                            product = product,
                            modifier = Modifier.width(160.dp)
                        )
                    }
                }
            }
        }
    }
}

Why this looks reasonable:

• Common UI pattern (Netflix, Play Store, etc.)
• Clean nested structure
• Each list manages its own scrolling

The cascade of problems:

1. Nested scrolling contexts create coordination overhead
2. Unbounded height constraints cause multiple measure passes
3. Each LazyRow independently manages composition (expensive)
4. Scrolling outer list triggers measure in ALL nested LazyRows
5. Layout thrashing as inner lists recalculate during outer scroll

🔍 The Performance Breakdown

With 10 categories, each with 20 products:

• Scrolling outer list
• Triggers measure on visible categories (3–4)
• Each category’s LazyRow measures (even if not scrolling)
• 3–4 × 20 = 60–80 items measured per scroll frame
• Even though user is only scrolling the outer list

Frame time impact: +15–25ms per scroll frame

✅ Solution 1: Fixed Height Constraints

@Composable
fun CategoryList(categories: List<Category>) {
    LazyColumn {
        items(categories, key = { it.id }) { category ->
            Column {
                Text(
                    text = category.title,
                    style = MaterialTheme.typography.titleLarge,
                    modifier = Modifier.padding(16.dp)
                )
                
                LazyRow(
                    modifier = Modifier
                        .height(220.dp)  // ✅ Fixed height prevents remeasure
                        .fillMaxWidth(),
                    contentPadding = PaddingValues(horizontal = 16.dp),
                    horizontalArrangement = Arrangement.spacedBy(12.dp)
                ) {
                    items(
                        items = category.products,
                        key = { it.id },
                        contentType = { "product" }  // ✅ Content type for pooling
                    ) { product ->
                        ProductCard(product)
                    }
                }
            }
        }
    }
}

Why this works:

• Fixed height gives LazyRow stable constraints
• Prevents remeasure during outer scroll
• LazyRow only measures when it actually needs to

✅ Solution 2: Flatten When Possible (Best Performance)

// Transform nested structure into flat list
data class FeedItem(
    val type: FeedItemType,
    val categoryId: String? = null,
    val categoryTitle: String? = null,
    val productId: String? = null,
    val product: ProductUiState? = null
)

enum class FeedItemType {
    CATEGORY_HEADER,
    PRODUCT
}

class CategoryViewModel : ViewModel() {
    val feedItems: StateFlow<List<FeedItem>> = categoriesFlow
        .map { categories ->
            categories.flatMap { category ->
                buildList {
                    // Add category header
                    add(
                        FeedItem(
                            type = FeedItemType.CATEGORY_HEADER,
                            categoryId = category.id,
                            categoryTitle = category.title
                        )
                    )
                    // Add products
                    category.products.forEach { product ->
                        add(
                            FeedItem(
                                type = FeedItemType.PRODUCT,
                                productId = product.id,
                                product = product.toUiState()
                            )
                        )
                    }
                }
            }
        }
        .stateIn(viewModelScope, SharingStarted.Lazily, emptyList())
}

@Composable
fun CategoryList(feedItems: List<FeedItem>) {
    LazyColumn {
        items(
            items = feedItems,
            key = { item ->
                item.productId ?: item.categoryId ?: ""
            },
            contentType = { it.type }
        ) { item ->
            when (item.type) {
                FeedItemType.CATEGORY_HEADER -> {
                    Text(
                        text = item.categoryTitle ?: "",
                        style = MaterialTheme.typography.titleLarge,
                        modifier = Modifier.padding(16.dp)
                    )
                }
                FeedItemType.PRODUCT -> {
                    item.product?.let { product ->
                        ProductCard(
                            product = product,
                            modifier = Modifier.padding(horizontal = 16.dp)
                        )
                    }
                }
            }
        }
    }
}

Trade-offs:

Flattened approach:

• ✅ Best scrolling performance
• ✅ Single scrolling context
• ✅ Simpler composition tree
• ❌ Loses horizontal scrolling per category
• ❌ Different UX pattern

Nested with constraints:

• ✅ Preserves horizontal scroll UX
• ✅ Good performance with proper constraints
• ❌ More complex composition
• ❌ Requires careful constraint management

✅ Solution 3: Hybrid Approach

// For categories with many items, use LazyRow with constraints
// For categories with few items, use regular Row

@Composable
fun CategoryList(categories: List<Category>) {
    LazyColumn {
        items(categories, key = { it.id }) { category ->
            Column {
                Text(category.title, style = MaterialTheme.typography.titleLarge)
                
                when {
                    category.products.size <= 5 -> {
                        // Use regular Row for small lists
                        Row(
                            modifier = Modifier
                                .fillMaxWidth()
                                .horizontalScroll(rememberScrollState()),
                            horizontalArrangement = Arrangement.spacedBy(12.dp)
                        ) {
                            category.products.forEach { product ->
                                ProductCard(product)
                            }
                        }
                    }
                    else -> {
                        // Use LazyRow with constraints for large lists
                        LazyRow(
                            modifier = Modifier
                                .height(220.dp)
                                .fillMaxWidth()
                        ) {
                            items(
                                items = category.products,
                                key = { it.id }
                            ) { product ->
                                ProductCard(product)
                            }
                        }
                    }
                }
            }
        }
    }
}

Measured improvement (nested LazyRow with constraints):

• Frame time during outer scroll: -18ms average
• Layout passes: -65%
• Smoother scroll perception

The Architectural Mental Model

Part 1 taught you to minimize when composition happens. Part 2 teaches you to minimize what happens during composition.

The Three Architectural Principles:

1. Defer Heavy Work → Move to ViewModel/background threads
2. Minimize Scope Boundaries → Inline when possible, extract strategically
3. Provide Type Hints → Help Compose optimize (contentType, stable types)

The Compounding Effect

Each architectural issue adds 3–8ms per scroll frame. With all five issues:

• Potential overhead: 15–40ms per frame
• That’s the difference between 60fps and 30fps

The Validation Checklist:

• No derivedStateOf in composables (use ViewModel flows)
• Minimal @Composable function boundaries in hot paths
• Modifier chains cached in remember
• contentType specified for heterogeneous lists
• Nested lazy lists have fixed constraints OR are flattened

What’s Next

You’ve fixed the foundation issues. You’ve optimized the architecture.

But there’s one final layer: production-grade polish.

What architectural patterns have you found that hurt LazyColumn performance? Share your experiences in the comments.

← Back to Part 1: Quick Fixes

Continue to Part 3: Production-Grade Performance → (Coming soon)

---

Why Your LazyColumn Drops Frames — Part 2: Hidden Patterns was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.