kotlin-concurrency-and-flow

Kotlin の並行処理と Flow

核となる原則

非同期処理には明示的な所有者とライフタイムを与え、永続的な状態と一時的なイベントは、プロダクトの契約に合った配信および再生セマンティクスを持つプリミティブでモデル化します。

手順

1. 各コルーチンの所有者、キャンセル境界、プロデューサー、コンシューマー、永続的な状態、一時的なイベントを特定します。
2. API を変更する前に、既存の呼び出し側から見える契約と、必要な所有者およびライフタイムを比較します。suspend API によって呼び出し側がすでにキャンセル、結果、失敗を所有できるなら、変更せずに完了とします。利便性のためだけにスコープ、launch、コールバック、遅延ラッパーを追加しないでください。
3. 処理のライフサイクルを所有するスコープを選びます。任意のスコープを保持したり、非 suspend API の背後に非構造化の launch を隠したりしないでください。
4. 描画可能な最新データは状態としてモデル化し、命令型の単発処理は、データの消失と再生の挙動が明示的に許容される場合に限りイベントとしてモデル化します。各イベントを 1 つのコンシューマーが処理するのか、それともアクティブなすべてのコンシューマーが受け取る必要があるのかを確認します。Channel は各イベントを 1 つのコンシューマーに渡し、設定された SharedFlow はアクティブなコンシューマーにブロードキャストします。コンシューマーの契約が不明な場合は、どちらの選択肢も示し、選択前に必要な判断を明記します。コレクターがいない期間をまたいで保持する必要がある、1 つのコンシューマー向けのナビゲーション引き継ぎには、receiveAsFlow() で公開する有界の Channel(Channel.BUFFERED)（UNLIMITED ではありません）を選びます。イベントの消失を問題として特定した後で、replay が 0 の SharedFlow をそのまま使わないでください。
5. Flow の共有とバッファリングのセマンティクスは、既定値ではなく、プロデューサーとコンシューマーのライフタイムに基づいて選択します。
6. 以下の該当する懸念事項について、参照資料を確認します。
7. キャンセル、再起動、再生、失敗の挙動がすべて公開 API から把握でき、処理の所有者について呼び出し側が推測する必要がなくなった時点で完了とします。

トピックルーター

シグナル	参照先
保存された CoroutineScope、生の Thread または Executor による処理、init { launch }、fire-and-forget API、runBlocking、広範な catch、またはキャンセル境界	構造化並行性
StateFlow、SharedFlow、Channel、stateIn、SharingStarted、.value、状態の更新、センチネル値、または単発イベント	Flow の状態とイベント
変更を検証するための Gradle の実行	Gradle の実行。生の ./gradlew は使用しないでください
Compose によるコレクション、または UI のエフェクト処理	Compose の状態とエフェクト