default title

What is the lifecycle?

The lifecycle is a common implicit temporal contract in systems, such as the step sequence restriction of 'if A is executed, B must be executed at some point in the future'. The common ones are nCreate/OnDestroy for Activities, which are the lifecycle of the activity; Fragment and Navigation also have their own lifecycles.

Temporal decomposition

The Philosophy of Software Design 5.3 Temporal Decomposition discusses the same concept of time decomposition and lifecycle (this article considers "temporal decomposition" as a type of complexity classification). The so-called temporal decomposition refers to the limitation of the order of steps that cannot be verified by the compiler/formal validation. It will leak non functional additional knowledge, causing cognitive burden and unknown unknowns.

And the lifecycle is a temporal decomposition.

Architecture principle: Formalization and delegation of contracts

When the system is complex enough, this constraint is difficult to completely avoid, which is an inherent complexity that cannot be avoided in development and design. Therefore, the goal of Jetpack Lifecycle is to formalize implicit contracts and hand them over to subscribers for fulfillment.

The core of the solution is to provide an abstract framework for transforming 'implicit contracts' into' explicit contracts':

Principle 1 (Formalization): Visualize the temporal rules of human brain memory as Lifecycle (states+events), allowing contracts to be observed and executed.

Principle 2 (Externalization and Subscription): Lifecycle public status and events; Lifecycle Observer actively subscribes and encapsulates performance knowledge internally (start stop timing, binding/unbinding resources, idempotent/re-entry protection).

Architecture model: concretization of observer pattern

The concept of Lifecycle is very simple, it is just an "observable lifecycle" object: registered observers can listen for state changes and directly access the current state.

Concept: Observer Mode

Principle: The core interaction mechanism of Lifecycle is the observer design pattern.

Subject: Lifecycle object, holding authoritative status and responsible for notifications.

Observer: Lifecycle Observer, passively receives status updates and executes logic.

The concept is very clean and simple: you can be a lifecycle subject for external observation, or an observer to monitor state changes, that's all.

Architectural Roles: API Mapping of the Pattern

Lifecycle (Formal Contract/Subject)

Responsibilities: Define specific rules for temporal contracts and publish states and events.

Lifecycle Owner

Responsibility: Identify an object with an observable temporal context.

Lifecycle Observer (Observer/Knowledge Encapsulation)

Responsibilities: Fully encapsulate all the knowledge and logic required for the response timing contract.

Core Communication Model: State and Event

Event (Lifecycle Event)

Definition: Represents an action that occurs instantaneously and triggers a state transition.

Paradigm: Event Driven, suitable for handling discrete, one-time operations.

State (lifecycle state)

Definition: Represents a sustained and stable condition.

Paradigm: State Driven, suitable for managing tasks that need to be continuously carried out during a certain period of time.

That's all we need to do: observe changes in the lifecycle state. It was originally designed with responsiveness as its goal and can be fully understood according to the observer model.

Event vs Status

Event driven

Core focus: What happened at a certain point in time.

Design objective: To provide clear behavioral callbacks for responding to discrete, one-time triggers.

State Driven

Core focus: What situation is it in during a certain period of time.

Design objective: To provide a declarative and automated abstraction for managing start stop and cancellation of tasks that require continuous execution under certain conditions.

State driven in Jetpack Lifecycle

The state is just an event driven conceptual mapping, defining a 'valid interval' with several events. For example, the STARTED state refers to the duration between ON-START and ON-STOP.

Implemented template

Because it still relies on event driven, directly implementing start stop triggered by events will still be a paired template of "enter → start, leave → end".

Structured concurrency of coroutines

The core principle of structured concurrency is to govern the lifecycle of coroutines through a hierarchical structure. In this structure, both 'scope' and 'work' have their own lifecycles and have a parent-child relationship:

CoroutineScope: As a parent layer, its own lifecycle (from establishment to cancellation) defines the longest execution interval.

Coroutine/Job: All coroutines initiated within this scope (essentially a "job") have their lifecycle strictly constrained within the interval of the parent scope as a child layer. The cancellation of the parent scope will propagate downwards, reliably terminating all its child work. This is the mechanism of 'carrying intervals with scope and achieving convergence with cancellation'.

Collaborative process ⬌ interval ⬌ lifecycle

The core relationship between these three is the equivalence of concept, structure, and implementation: the lifecycle state is a conceptual interval, and the structured concurrency of coroutines provides an implementable structure for this interval. More specifically:

Lifecycle defines an abstract interval defined by events.

The CoroutineScope of coroutine defines a specific execution interval defined by the establishment and cancellation, and its own lifecycle is represented by its "job" in the parent layer.

The 'coroutines' running within the scope are the specific tasks within this interval.

Therefore, the abstract concept of "lifecycle state" can be realized through the concrete structure of "co process scope". This enables the lifecycle operations that originally required manual pairing to be replaced by a coroutine task managed automatically by the scope.

Driven by the lifecycle state implemented through coroutines

The essence of implementing state driven by coroutines is to equivalently realize the conceptual interval of "lifecycle state" through the implementable interval of "coroutine scope". Its core lies in utilizing structured concurrency cancellation guarantee to unify the "start/end" operations that originally required manual pairing into a structured block.

Official API provided: Comparison Table (Events vs Status)

Event driven: Handling 'Points'

Default Lifecycle Observer: Semantic event callbacks (onStart/onStop/...), encapsulating small breakpoints.

Lifecycle Event Observer: listens to all events and processes them using matching or enumeration, suitable for bridging legacy callbacks or requiring precise interception.

Event driven in Compose

Lifecycle Event Effect (event) {...}: Execute a one-time side effect (within the combined scope) when a specified lifecycle event occurs.

State driven: Governance of 'intervals'

RepeatOnLifecycle (minState): Automatically start and stop the coroutine block within the state interval.

FlowWithLifecycle (lifecycle, minState): Collect data streams with the minimum state threshold.

State driven in Compose

CollectAsStateWithLifecycle (): Flow → State, automatically aligns the minimum state.

Lifecycle Start Effect/Lifecycle Resume Effect: Start/retract side effects within the STARTED/RESUMED interval.

(Default minActiveState=STARTED)

Summary

What is the lifecycle?

It is an unavoidable 'implicit temporal contract' in development, which requires developers to manually maintain operations with sequential restrictions, and is a complexity of 'temporal decomposition' in design.

What is Jetpack Lifecycle?

Jetpack Lifecycle is the foundational framework for addressing this issue. It operates in observer mode, externalizing implicit rules that can be subscribed to, allowing you to no longer manually manage these details, but instead leave them to the framework to ensure execution.

How to model and use it?

In practice, the following principles should be followed:

Identification model: one-time, discrete response → using "event"; Continuous tasks (especially data flow) → use 'state'.

Priority state driven: Prioritize the use of structured concurrency based state driven APIs, such as repetitiOnLifecycle, to fundamentally avoid paired template errors.