Paradigm Shift: From Imperative to Declarative

Traditional XML follows an imperative paradigm. Developers must manually manage UI state updates: first obtain View references through `findViewById`, then manually call `setText()` or `setVisibility()` when data changes. In this mode, Views hold their own state while business logic modifies state externally, easily leading to state inconsistency and hard-to-track bugs.

Jetpack Compose adopts a declarative paradigm. The core formula is `UI = f(State)`. Developers no longer care about "how" to update the UI, but describe what the UI "should look like" given a certain state. When state changes, the Compose framework automatically calculates differences and updates the screen. This shift in thinking model is the most difficult but also most valuable part of migration.

Core Decoded: @Composable and the Compiler Plugin

Compose is not an ordinary library; it's a system deeply integrated into the Kotlin compiler. The `@Composable` annotation is not a traditional runtime annotation but a marker for a compiler plugin.

During compilation, this plugin intercepts all marked functions and rewrites their signatures. The most notable change is injecting an implicit parameter: `Composer`. The `Composer` object is responsible for tracking UI tree structure and state at runtime. This mechanism is similar to Kotlin coroutines' `suspend` keyword, which also injects a `Continuation` parameter through the compiler.

The Compose runtime uses an efficient data structure called "Gap Buffer" or "Slot Table" to store UI tree information. This structure allows Compose to insert, delete, or move nodes at any position in the UI tree with minimal overhead, supporting efficient dynamic UI updates.

Smart Recomposition

Recomposition is Compose's mechanism for updating the UI. To ensure performance, Compose implements extremely aggressive optimization strategies. The most core are "Positional Memoization" and "Skipping."

When declaring state using `remember`, the value is stored in the slot table. When a Composable function reads state, it automatically subscribes to changes in that state. Once state updates, Compose only re-executes functions that depend on that state.

More importantly, if a Composable's parameters haven't changed during recomposition (i.e., parameters are "stable"), Compose will completely skip executing that function. This is why using immutable objects and stable collection types is so important in Compose.

Maximum Utilization of Kotlin Language Features

Compose is a culmination of Kotlin language features. It extensively uses higher-order functions and Lambda expressions (especially trailing Lambdas) to build declarative UI tree structures.

The `Modifier` system is built entirely on extension functions, allowing developers to add modifiers fluently through method chaining. All asynchronous tasks and side effect management (like `LaunchedEffect`) are built directly on Kotlin Coroutines, making UI lifecycle binding with asynchronous tasks unprecedentedly simple and safe.