LazyColumn and lists: a practical Android & Kotlin guide

LazyColumn and lists: a practical Android & Kotlin guide

Most Android teams hit performance walls when rendering long lists—and LazyColumn is where we solve that. In this guide, we'll walk through the practical patterns we use across production apps, from e-commerce catalogs to ride-hailing feeds, to keep scrolling smooth and memory footprints reasonable.

Why LazyColumn matters in modern Android

Before Jetpack Compose, RecyclerView dominated list rendering. It worked, but it required boilerplate: adapters, view holders, diffing callbacks. LazyColumn simplifies that by composing only visible items—the same principle, cleaner syntax.

In production, we've seen apps leak memory or stutter when teams treat LazyColumn like a straightforward list UI. The tool is powerful, but it requires discipline around state management and composition semantics. That's what we cover here.

items() with stable keys

The foundation of efficient LazyColumn rendering is the items() function. By default, Compose identifies list items by position. When your data changes—items deleted, reordered, or inserted mid-list—Compose may recompose items unnecessarily or animate them incorrectly.

Stable keys tell Compose: "This item with ID 42 is the same logical item, even if its position changed." That unlocks correct animations and minimal recompositions.

LazyColumn {
    items(
        items = products,
        key = { product -> product.id }
    ) { product ->
        ProductCard(product = product)
    }
}

Here, key = { product -> product.id } ensures each product is identified by its unique ID, not its index. If you sort the list or insert a product at position 0, Compose knows which card corresponds to which product and doesn't unnecessarily rebuild everything.

We've debugged issues in our e-commerce app where a missing key caused 200ms recomposition jank when filtering a category. Adding keys cut that to 16ms. Keys matter.

For contentType, which we'll discuss below, pair it with keys:

items(
    items = feedItems,
    key = { item -> item.id },
    contentType = { item -> item.type }
) { item ->
    when (item.type) {
        ItemType.IMAGE -> ImageCard(item)
        ItemType.TEXT -> TextCard(item)
    }
}

This combination lets Compose pool and reuse composables by type, then track identity within each type pool.

Avoid heavy work in item composables

A subtle but critical issue: composition is cheap, but side effects and blocking calls inside item composables are not. If your ProductCard fetches data from a database or performs image decoding synchronously, you'll stall the composition thread and kill scroll performance.

The rule is simple: move expensive work out of composition. Use LaunchedEffect to kick off async operations, and read their results from state.

@Composable
fun ProductCard(productId: Long) {
    var product by remember { mutableStateOf(null) }
    var isLoading by remember { mutableStateOf(true) }

    LaunchedEffect(productId) {
        isLoading = true
        product = repository.fetchProduct(productId)
        isLoading = false
    }

    if (isLoading) {
        ShimmerPlaceholder()
    } else {
        product?.let {
            Text(it.name)
            Text("$${it.price}")
        }
    }
}

In a real app, you'd use a ViewModel and a repository pattern, but the principle holds: data fetching happens in a coroutine, not during composition.

A common anti-pattern we see:

// DO NOT DO THIS
@Composable
fun BadProductCard(productId: Long) {
    val product = runBlocking { repository.fetchProduct(productId) }
    Text(product.name)
}

This blocks the composition thread. During scroll, Compose tries to recompose items entering the viewport, but runBlocking stalls everything. The scroll frame drops instantly.

Another trap: creating expensive objects in the body of a composable. Database queries, Bitmap decoding, regex compilation—all should be hoisted to remember or a ViewModel:

// OK: memoize regex
@Composable
fun SearchResult(query: String, text: String) {
    val regex = remember(query) {
        Regex(query, RegexOption.IGNORE_CASE)
    }
    val matches = regex.findAll(text).toList()
    Text("Found ${matches.size} matches")
}

Use contentType for mixed lists

Real-world feeds aren't homogeneous. An e-commerce app mixes product cards, promotional banners, and section headers. A social feed has images, text posts, and stories. Compose optimizes by pooling composables of the same type—it can reuse a Text composable slot across multiple items if they're the same type.

When you omit contentType, Compose treats every item as potentially different, limiting reuse. With contentType, it pools by type.

sealed class FeedItem {
    data class Image(val id: Long, val url: String) : FeedItem()
    data class Text(val id: Long, val content: String) : FeedItem()
    data class Header(val id: Long, val title: String) : FeedItem()
}

LazyColumn {
    items(
        items = feedItems,
        key = { it.id },
        contentType = { item ->
            when (item) {
                is FeedItem.Image -> "image"
                is FeedItem.Text -> "text"
                is FeedItem.Header -> "header"
            }
        }
    ) { item ->
        when (item) {
            is FeedItem.Image -> ImageCard(item.url)
            is FeedItem.Text -> TextCard(item.content)
            is FeedItem.Header -> HeaderCard(item.title)
        }
    }
}

In our ride-hailing app, a similar pattern reduced memory overhead by about 15% during a long scroll through historical trips (mix of ride cards, promotions, and ads).

Paging 3 for large data

LazyColumn is efficient, but it still assumes your entire data set fits in RAM (or at least, most of it). For truly large data—think infinite social feeds, search results with millions of items—Paging 3 is the standard solution.

Paging 3 handles chunking data into pages, pre-loading before the user scrolls to the end, and managing cache. Integrate it with LazyColumn via collectAsLazyPagingItems():

@Composable
fun ProductListScreen(viewModel: ProductListViewModel) {
    val lazyPagingItems = viewModel.pagingFlow.collectAsLazyPagingItems()

    LazyColumn {
        items(
            count = lazyPagingItems.itemCount,
            key = { index -> lazyPagingItems[index]?.id ?: index }
        ) { index ->
            val product = lazyPagingItems[index]
            if (product != null) {
                ProductCard(product)
            } else {
                ShimmerPlaceholder()
            }
        }

        if (lazyPagingItems.loadState.append is LoadState.Loading) {
            item {
                CircularProgressIndicator()
            }
        }
    }
}

And in the ViewModel:

class ProductListViewModel : ViewModel() {
    val pagingFlow = Pager(
        config = PagingConfig(pageSize = 20, enablePlaceholders = false),
        pagingSourceFactory = { ProductPagingSource(repository) }
    ).flow
        .stateIn(viewModelScope, SharingStarted.Lazily, PagingData.empty())
}

class ProductPagingSource(private val repository: ProductRepository) : PagingSource() {
    override suspend fun load(params: LoadParams): LoadResult {
        return try {
            val page = params.key ?: 0
            val products = repository.fetchProducts(page = page, pageSize = params.loadSize)
            LoadResult.Page(
                data = products,
                prevKey = if (page == 0) null else page - 1,
                nextKey = if (products.isEmpty()) null else page + 1
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }

    override fun getRefreshKey(state: PagingState): Int? = null
}

Paging 3 handles retry logic, error states, and refresh. It's essential for large datasets. We use it across trading platforms with 100k+ orders and e-commerce apps with infinite product feeds.

Common mistakes

• Forgetting keys and watching performance degrade. If your list items animate or reorder frequently and you don't provide keys, recompositions spike. Always add keys when data is dynamic.
• Doing network calls in composables directly. Use ViewModel + coroutines to fetch data, not remember { someBlocking() }. Composition is not the place for I/O.
• Not using contentType for heterogeneous lists. If you have mixed item types (images, text, headers), omitting contentType wastes memory and CPU on unnecessary recompositions.
• Loading entire datasets into memory. For lists with hundreds of thousands of items, Paging 3 is not optional—it's required to avoid OOM and poor UX.
• Accessing LazyListState in ways that trigger recomposition on every scroll. Reading LazyListState.firstVisibleItemIndex in a composable that returns State causes frequent recomposition. Observe it via effects instead.

Key takeaways

• Use key in items() to identify list entries by a stable ID, not position. This prevents unnecessary recompositions and fixes animation bugs.
• Move expensive work (network, I/O, heavy compute) out of composables and into LaunchedEffect or a ViewModel. Keep composition fast.
• For mixed-type lists, add contentType to enable composable pooling and reduce memory churn.
• For large datasets (1000+ items or infinite feeds), reach for Paging 3. It handles pagination, caching, and pre-loading automatically.
• Remember that LazyColumn is lazy only in what it composes, not in how you structure your logic. Compose semantics still apply—side effects, state, and object creation all follow the same rules.