Join Community
Home Events Academy Speakers Organizers Stories Gallery Blog FAQs Join Community
← All courses

Memory & Data Structures on Mobile

🗓 May 31, 2026 • ⏱ 3 min read

Memory is the scarcest resource

On a phone, RAM is limited and shared. If your app uses too much, the OS kills it (or kills it in the background and restarts it, losing state). So your choice of data structure isn’t only about speed — it’s about how much memory it consumes. This lesson connects DSA to mobile memory reality.

Structures have different memory costs

  • Arrays/lists — compact; just the elements plus a little overhead.
  • Hash maps/sets — faster lookups but more memory (empty slots, load factor, node objects).
  • Linked structures — each node carries pointer overhead; many small objects add up.
  • Trees/graphs — can grow large; an adjacency list is far leaner than a matrix.

The lesson: pick the smallest structure that meets your needs. Don’t reach for a hash map of millions of entries when a sorted array or a bounded cache would do.

The space–time trade-off, on a budget

Caching trades memory for speed — great, but only within limits. An LRU cache exists precisely to bound that trade. Always ask: “what’s the maximum memory this can use, and what happens when it’s full?”

Lazy and streaming over loading everything

  • Paginate — load 20 items, not 20,000. The UI only needs what’s on screen.
  • Lazy lists — RecyclerView/LazyColumn/FlatList keep only visible rows in memory — a data-structure-aware design.
  • Stream large data — process a big file/response in chunks rather than holding it all.

Memory leaks: when structures hold on too long

A leak is memory that should be freed but isn’t, usually because something still references it. A classic cause: a long-lived collection (a static list, a singleton cache, an event-listener list) that keeps holding objects — including Activities/Views/Contexts — long after they’re needed.

// LEAK: a static list holding views/contexts forever
object Registry { val listeners = mutableListOf<View>() }   // never cleared!

// Fix: remove when done, or use weak references for caches
listeners.remove(view)   // in onDestroy / cleanup
  • Remove items from long-lived collections when no longer needed.
  • For caches that shouldn’t keep objects alive, consider weak references.
  • Unregister listeners/observers in the right lifecycle callback.

Measure with the profiler

Use Android Studio’s Memory Profiler or Xcode’s Instruments to watch your app’s memory, find leaks, and see which structures dominate. Big-O predicts memory trends; the profiler shows the truth on a real device.

Common mistakes

  • Loading an entire dataset into memory instead of paginating.
  • Unbounded caches/collections that grow until the OS kills the app.
  • Static/singleton collections leaking Activities, Views or Contexts.
Summary: On mobile, a data structure’s memory cost matters as much as its speed. Choose the smallest structure that fits, bound your caches, paginate and stream instead of loading everything, and avoid leaks by clearing long-lived collections and unregistering listeners. Profile on real devices.