Android · Android Jetpack

Compose Replaces Manual UI Sync with a Single Principle: UI = f(state)

By 一个用户名i · Aug 21, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

The View-to-Compose migration is the largest paradigm shift in Android UI since the platform launched. Developers who cling to imperative patterns will write Compose code that fights the runtime, producing redundant work and subtle bugs that the declarative model was designed to prevent.

Summary

Traditional Android development treats UI and state as two parallel tracks that must be manually synchronized with findViewById, setText, and setVisibility. Jetpack Compose collapses that into a single declarative relationship: describe what the UI should look like for a given state, and the framework handles the rest. A counter that requires three manual update steps in the View world needs zero update logic in Compose — changing the state variable triggers automatic recomposition.

The mental model is UI = f(state). Composable functions are pure descriptions with no return value, called repeatedly and out of order by the runtime. This eliminates the most common bug class in Android apps: state changes that the UI forgets to reflect. For developers coming from the View system, the hardest unlearning is giving up control references; Compose has no findViewById because there are no widget references to hold, only state to mutate.

Common early mistakes include treating Compose as a View syntax swap, running side effects directly inside composable functions, and forgetting remember, which preserves state across recompositions.

Takeaways

— Compose replaces manual UI updates with automatic recomposition triggered by state changes.

— A Composable function has no return value; it emits UI into the composition, it does not return a widget tree.

— setContent {} replaces setContentView as the Activity entry point into the declarative world.

— Composable functions must be pure — same inputs, same outputs — because the runtime calls them repeatedly and out of order.

— remember is required to preserve state across recompositions; without it, state resets on every call.

— Compose eliminates findViewById, notifyDataSetChanged, and the entire layer of manual View-data synchronization code.

— LazyColumn replaces RecyclerView + Adapter + ViewHolder with a single composable function.

Conclusions

The counter comparison is the most efficient way to demonstrate the paradigm gap: three manual steps collapse into zero update code, making the cost of the old model immediately visible.

Calling Compose 'just a new syntax for View' is the most damaging misconception for adoption — it's a compiler, runtime, and toolchain stack that requires a different mental model, not a different API surface.

The purity constraint on composable functions is the part most experienced Android developers resist, because it forbids patterns they've relied on for years, like firing a network call from onCreate.

Concepts & terms

Composable function

A Kotlin function annotated with @Composable that describes a piece of UI. It has no return value and can be called repeatedly and out of order by the Compose runtime.

Recomposition

The process by which the Compose runtime re-executes composable functions whose inputs (state) have changed, updating only the affected parts of the UI tree.

Declarative UI

A programming model where the developer describes what the UI should look like for a given state, rather than issuing step-by-step commands to mutate the UI. Compose's core formula is UI = f(state).

Source: juejin.cn ↗ Google Translate ↗ Backup ↗