AhsanAhmed03

Posted on Apr 6

🚀 Why Your Android App is Slow (And How to Fix It)

#android #kotlin #androiddev

You launch your app…
It takes 3 seconds to open.

You scroll a list…
It lags and stutters.

You tap a button…
Nothing happens for a moment.

Sound familiar?

If yes, your app isn’t just “a bit slow” — it’s silently losing users.

👉 Studies show users uninstall apps that feel sluggish within minutes.

The good news?
Most performance issues in Android apps are predictable and fixable — once you understand what’s happening under the hood.

🧠 Deep Dive: Why Android Apps Become Slow

Let’s simplify how Android works internally.

🧩 The Main Thread (UI Thread)
Think of your app like a restaurant kitchen:

The Main Thread = the chef
UI rendering, clicks, animations = orders

👉 If the chef is busy doing something heavy (like calculating data or loading images), new orders get delayed.

Result:

UI freezes
Laggy scrolling
ANRs (Application Not Responding)

⏱️ The 16ms Rule
Android tries to render 60 frames per second.

That means:

Each frame must be drawn in 16ms

If your app takes longer:

Frames drop ❌
UI becomes janky ❌

🔥 Common Causes of Slowness

Problem: Heavy work on Main Thread
Why: Blocks UI

Problem: Unoptimized RecyclerView
Why: Rebinding too much

Problem: Memory leaks
Why: App slows over time

Problem: Too many recompositions (Compose)
Why: Extra rendering

Problem: Large images
Why: High memory + slow decoding

Problem: Bad architecture
Why: Uncontrolled state updates

**🛠️ Fix #1: Move Work Off the Main Thread (Coroutines)

❌ Bad Example (UI Freeze)**

fun loadData() {
    val data = repository.getDataFromNetwork() // Blocking call
    textView.text = data
}

👉 This blocks UI.

**✅ Good Example (Using Coroutines)

ViewModel (Best Practice)**

class MainViewModel(
    private val repository: DataRepository
) : ViewModel() {

    private val _data = MutableStateFlow<String>("")
    val data: StateFlow<String> = _data

    fun loadData() {
        viewModelScope.launch {
            val result = withContext(Dispatchers.IO) {
                repository.getDataFromNetwork()
            }
            _data.value = result
        }
    }
}

👉 Why this works:

Dispatchers.IO → runs in background thread
viewModelScope → lifecycle-safe (no leaks)

**🧱 Fix #2: Optimize RecyclerView (XML)

❌ Common Mistakes**

Not using DiffUtil
Calling notifyDataSetChanged()
Heavy work in onBindViewHolder

✅ Use ListAdapter + DiffUtil

class UserAdapter : ListAdapter<User, UserAdapter.ViewHolder>(DiffCallback()) {

    class ViewHolder(val binding: ItemUserBinding) :
        RecyclerView.ViewHolder(binding.root)

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        val binding = ItemUserBinding.inflate(
            LayoutInflater.from(parent.context), parent, false
        )
        return ViewHolder(binding)
    }

    override fun onBindViewHolder(holder: ViewHolder, position: Int) {
        val user = getItem(position)
        holder.binding.name.text = user.name
    }
}

class DiffCallback : DiffUtil.ItemCallback<User>() {
    override fun areItemsTheSame(old: User, new: User) = old.id == new.id
    override fun areContentsTheSame(old: User, new: User) = old == new
}

👉 Why this is fast:

Only updates changed items
Avoids full list redraw

**⚡ Fix #3: Jetpack Compose Performance

❌ Bad Compose Code**

@Composable
fun UserScreen(users: List<User>) {
    users.forEach {
        Text(it.name)
    }
}

👉 Problem:

No lazy loading
Renders everything at once

*✅ Use LazyColumn *

@Composable
fun UserScreen(users: List<User>) {
    LazyColumn {
        items(users) { user ->
            Text(text = user.name)
        }
    }
}

🔁 Avoid Unnecessary Recompositions

@Composable
fun UserItem(user: User) {
    val name = remember(user.id) { user.name }
    Text(text = name)
}

👉 remember prevents recomputation.

**🧠 Fix #4: Memory Leaks (Silent Killer)

❌ Common Leak**

object Singleton {
    lateinit var context: Context
}

👉 Holding Activity context = memory leak.

✅ Correct Way

object Singleton {
    lateinit var context: Context

    fun init(appContext: Context) {
        context = appContext.applicationContext
    }
}

💡 Use LeakCanary

debugImplementation "com.squareup.leakcanary:leakcanary-android:2.12"

👉 Detects memory leaks automatically.

**🖼️ Fix #5: Image Optimization

❌ Problem**

Loading full-size images
No caching

✅ Use Coil (Modern Best Practice)

implementation "io.coil-kt:coil-compose:2.5.0"

AsyncImage(
    model = "https://example.com/image.jpg",
    contentDescription = null
)

👉 Benefits:

Auto caching
Efficient decoding
Works with Compose

🧱 Fix #6: Avoid Overdraw
👉 Overdraw = drawing pixels multiple times

Solution:

Use fewer nested layouts
Avoid unnecessary backgrounds

⚡ Fix #7: Use Baseline Profiles (Advanced 🚀)

👉 Speeds up app startup significantly.

Dependency

implementation "androidx.profileinstaller:profileinstaller:1.3.1"

👉 Pre-compiles critical code paths.

🚨 Edge Cases & Real Problems

1. ANR (Application Not Responding)

Caused by blocking UI thread > 5 seconds
Fix → Move work to background

2. Too Many API Calls

Use caching (Room / memory cache)
Debounce user input

3. ViewBinding Leaks (Important ⚠️)

private var _binding: FragmentMainBinding? = null
private val binding get() = _binding!!

override fun onDestroyView() {
    _binding = null
}

👉 Prevents fragment leaks.

4. Compose + State Explosion

👉 Avoid:

var state by mutableStateOf(...)

inside large composables without scoping.

👉 Use:

ViewModel
StateFlow

🧩 Architecture Matters

👉 Bad architecture = performance issues

Recommended Stack:

MVVM
StateFlow
Repository pattern
Single source of truth

📊 Quick Performance Checklist

✅ No heavy work on Main Thread
✅ Use LazyColumn / RecyclerView properly
✅ Optimize images
✅ Avoid memory leaks
✅ Minimize recompositions
✅ Use background threads
✅ Use profiling tools (Android Studio Profiler)

🎯 Final Thought

Performance is not something you “add later.”

It’s something you design from day one.

A fast app feels: