Native Android application development in Newton

A slow Compose screen is rarely a hardware problem. It is usually a recomposition problem. Compose decides which parts of a screen need to redraw based on what each function reads, not on what a developer intended. A single counter at the top of a screen can force an entire list to redraw. That happens even when the list only reads the counter indirectly, through a shared object.

State hoisting is the first line of defence. State should live close to the composable that changes it, and pass down only to the pieces that read it. A search field, a filter row and a results list should not share one large state object. A keystroke in the search field would then invalidate all three. Every one repaints for no reason. Splitting state into smaller pieces lets Compose skip whatever did not change.

remember and derivedStateOf solve two different problems. Mixing them up causes quiet performance loss. remember keeps a value alive across recompositions. It is not recalculated every time. derivedStateOf goes further. It recalculates only when the underlying value changes in a meaningful way. This matters most for a computed check read inside a loop, such as whether a scrollable list has reached its end. remember alone still recomputes that check on every pass, just without allocating a new object each time.

Lambdas passed into composables are another quiet cost. An inline lambda written at the call site is a new object on every recomposition of the parent. Compose treats a new object as a reason to redraw whatever received it, even when the logic never changed. Hoisting the lambda into a remembered reference keeps its identity stable. A method reference works just as well where the shape allows it.

Stability matters as much as identity. Compose can only skip a composable safely if it can prove the parameters did not change. It can only prove that for stable types: primitives, strings, and data classes built from other stable types. A data class holding a plain List is treated as unstable. A list can mutate in place without changing its reference. Compose then recomposes defensively, whether the content changed or not.

Android Studio ships a layout inspector with a recomposition counter built in. It shows, per composable, how many times a screen redrew during a session. Turn it on for a screen that feels janky. Scroll and type through the normal flows. The offending composable usually turns up within minutes. Guessing from the code alone often misses the real trigger. Sometimes it is a modifier, not the composable body itself.

Modifiers deserve the same scrutiny as state. A Brush or a Shape built inline, rather than remembered, forces layout and draw to rerun on every pass. Gradients, shadows and custom shapes are common offenders. They look like simple property assignments. In truth they carry real computation behind them. A shadow rebuilt sixty times a second during a scroll is easy to miss and expensive to keep.

None of this means chasing recomposition counts to zero. A counter that increments once a second is supposed to. Treating every redraw as a bug makes the code harder to read for no real gain. Keep expensive work out of the composition path. Network calls, database reads, heavy formatting, all belong elsewhere. Small, cheap composables can recompose often without a user ever noticing a dropped frame.

A useful habit is to review recomposition once a screen gets its first real dataset, not after a user complains. Sample data early in development rarely exposes the cost of a long list. Neither does a shallow state object. By the time a report arrives, the pattern causing it is usually spread across several files, not sitting in one place waiting to be found.

Most Android apps beyond a simple prototype need to store structured data on the device. The practical choice sits between raw SQLite calls and Room, the persistence library built on top of SQLite. Raw SQLite gives full control. Every query is a plain string checked only at run time. A mistyped column name then surfaces as a crash weeks later, not a build error today.

Room compiles queries at build time against the actual entity definitions. A renamed column, or a mismatched return type, fails the build right away. It does not fail silently in production. For a team of more than one developer, or a codebase meant to last, that property alone tends to justify the extra setup. Everything else comes after that.

Entities map to tables through annotated data classes. A Data Access Object interface declares queries as plain methods with SQL supplied through annotations. The generated code handles cursor management, type conversion and connection lifecycle. A hand rolled layer has to reimplement all of it. Then it has to keep maintaining it. Custom types, dates, enums, embedded objects, need a small type converter. That is a one time cost per type, not per query.

Schema changes are where most local database bugs start. Room forces a decision at every version bump. Each change needs either a migration path, moving data from the old shape to the new one, or a statement that destructive migration is fine and old data can be dropped. There is no third option. Nothing is left to chance. Room refuses to open a database whose stored version does not match the code without one of the two. Silent data loss becomes a build time decision instead.

A migration is a set of SQL statements tied to a starting and ending version number. It runs in order when a user jumps across several versions at once. Testing migrations matters more than testing fresh installs. A fresh install always uses the latest schema. It never touches the migration code at all. Room ships an in memory testing helper for exactly this: open a database at an old version, run the migration, then check the result.

Offline first behaviour works cleanly with Room. A screen can read from the local database first while a background job keeps it current. Queries can return a Flow that emits automatically whenever the underlying table changes. A screen observing that Flow updates the moment a sync job writes new rows. No manual refresh call is needed. Nothing has to be wired by hand. The screen never has to know whether the data came from cache or from a fresh response.

Relationships between tables, a list of items in an order, a set of photos in a listing, are expressed through foreign keys and a small relation class grouping a parent with its children. Room resolves these in a small number of queries. It does not issue one per parent row. That matters once a list grows past a handful of items. A naive approach would produce dozens of separate round trips to the database.

None of this removes the need to think about what belongs in local storage at all. Data that changes constantly and is cheap to refetch, a live price, an availability count, often belongs only in memory or behind a short cache. Persisting it adds migration overhead for a value that will be stale within seconds anyway. Room works best for data the app genuinely needs offline. Think drafts, downloaded content, a history the app should show instantly on launch.

An Android app that slows down the longer it stays open usually has a memory leak. It is rarely a genuine need for more memory. A leak happens when something holds a reference to an object, most often an Activity or a Fragment, longer than that object should live. The whole view hierarchy, and everything it touches, then cannot be freed by the garbage collector.

The classic pattern is a listener registered with a long lived object, a singleton, a static field, a background thread, that captures the Activity or Fragment through an inner class or a lambda. The screen closes. The user moves on. The singleton still holds the reference. The old screen, and every view inside it, stays in memory. Rotating a device a dozen times without closing the app is still one of the fastest ways to surface this, since each rotation destroys and recreates the Activity.

LeakCanary, a library commonly added to debug builds, watches Activities and Fragments after they are destroyed. It checks whether each one was actually collected shortly afterward. When one survives that should not have, it walks the reference chain. It names the exact field holding on, down to the class and variable. That level of detail turns a vague slowdown report into a two line fix far more often than manual heap digging does.

The Android Studio profiler complements this with allocation patterns over time rather than a single leak report. A sawtooth pattern, memory climbing then dropping sharply, is normal garbage collection at work. A staircase pattern is different. Each drop lands higher than the one before, pointing at something accumulating that never gets released, the shape to look for when a leak is suspected but not yet caught by name.

View binding introduces its own version of this problem. A Fragment view can be destroyed and recreated on its own, separate from the Fragment instance. A view binding reference kept as a plain property survives that destruction. It holds the old view tree alive. The accepted pattern clears the binding reference inside onDestroyView. It is easy to forget once. Then the mistake gets copied into every new Fragment in a codebase.

Bitmaps deserve separate attention. They consume memory out of proportion to their footprint elsewhere in the code. A single uncompressed image can hold several megabytes. The variable pointing at it still looks like an ordinary object. Nothing about it looks dangerous. Loading full resolution images into thumbnail sized views, or skipping recycling for bitmaps loaded manually, produces out of memory crashes long before any other part of the app shows a symptom.

Click listeners, animation callbacks and coroutine scopes tied to the wrong lifecycle deserve a specific review pass on any screen with reports of slowness after extended use. A coroutine launched in a scope that outlives the screen, rather than a lifecycle aware scope tied to the Activity or Fragment, keeps running after the user has moved on. Its captured references stay alive right along with it.

Catching these issues early costs far less than fixing them after release. A leak that only shows up after twenty minutes of continuous use rarely appears during a quick manual test. It shows up almost immediately once LeakCanary or the profiler is watching a normal session. A short habit, checking the profiler after adding any new listener or long lived callback, keeps this class of bug out of a shipped build.