Jetpack Compose internals (Jorge Castillo Andrei Shikov)（Z-Library）

【One-Line Pitch】 A deep, source-guided tour of how Jetpack Compose actually works under the hood—from the compiler plugin that rewrites `@Composable` functions to the runtime that drives composition and recomposition—for Android developers who already write Compose and want to reason about it like a platform engineer. 【Book Arc】 - **Opening (~0%–10%)**: Sets expectations and scope—why internals matter, what the book is *not* (not a UI tutorial), and how to read alongside the Compose sources and a playground project. Establishes the mindset shift from View-system thinking to declarative composition. - **Early (~10%–30%)**: Builds the foundation around Composable functions—their nature, the calling-context requirement, and the core properties (idempotent, side-effect-free, restartable, fast, positionally memoized). Draws the parallel with `suspend` functions and explains why Composables are "colored." - **Middle (~30%–55%)**: Moves into the Compose compiler as a Kotlin compiler plugin—annotations, static checkers (call/type/declaration), diagnostics, and code generation via the Kotlin IR. Explains groups, `@ReadOnlyComposable`, and stability annotations that let the runtime skip work. - **Late (~55%–85%)**: Turns to the runtime and Compose UI—how the in-memory composition tree is built and updated, recomposition, positional memoization, and how the runtime can be reused beyond Android UI (the excerpts gesture at a standalone composition in the browser). - **Ending (~85%–100%)**: Closes with a conclusion and the broader lesson that Compose can represent any large call graph with generic node types, not just UI trees—encouraging readers to keep exploring the sources. 【Key Takeaways】 - **`@Composable` changes a function's type and imposes a contract** (Early): the annotation isn't cosmetic—it enforces a calling context and properties the runtime depends on for optimizations like parallel composition and smart recomposition. - **Composables must be idempotent and side-effect-free** (Early): the runtime may call them in any order or repeatedly, so business logic and network calls belong in another layer, not inside composition. - **Restartability is the reactive core** (Early): Composables re-execute when observed state changes, which is what makes selective recomposition possible. - **Positional memoization ties cached values to call-site identity** (Early): `remember` caches only within the location delimited by that call, and `key` lets you preserve identity across list reordering—without it, moving items forces needless recomposition. - **The compiler is a Kotlin compiler plugin doing frontend static analysis** (Middle): call/type/declaration checkers give fast, IDE-integrated feedback, while IR transformation rewrites Composables so the runtime can support them. - **Groups are the runtime's bookkeeping unit** (Middle): the compiler emits groups (restartable, movable, etc.) with source-position keys, enabling cleanup, movement, and positional memoization; `@ReadOnlyComposable` lets it skip unnecessary codegen. - **Stability annotations unlock skipping** (Middle): when parameters are stable/immutable or primitive, the runtime can compare values and skip recomposition—making stability a performance lever, not just a formality. - **Compose generalizes beyond UI** (Late): the runtime can model any large call graph with generic node types, which is why writing your own runtime client is a legitimate advanced use case. 【Reading Tips】 - **Read with the sources open**: the author explicitly recommends keeping `cs.android.com` and a playground project nearby; navigate the real Compose code as concepts appear. - **Deep-read the Early and Middle sections**: Composable properties and the compiler chapter are the conceptual spine—everything later depends on them. - **Skim the compiler-plugin plumbing** (extension registration, IR lowering details) on a first pass unless you do metaprogramming; return to it when debugging stability or codegen surprises. - **Treat stability and `key` as practical takeaways**: after each chapter, audit one screen in your own app for unstable parameters or unkeyed lists. - **Don't expect a UI cookbook**: this is an internals book; pair it with hands-on Compose work to convert theory into intuition. 【Coverage Limits】 The excerpts are heavily front-loaded (table of contents plus the Composable-functions and compiler chapters), so later runtime, Compose UI, and browser-composition material is only gestured at; specific chapter titles and figures beyond those shown are not covered here.