使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/albertmartorell1975/android-ai-workflow-foundation --skill compose-recomposition-performance開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Compose recomposition performance
Router only — deep fixes live in focused skills below.
Three axes
- Parameter stability / skipping — can Compose skip this restartable composable; are arguments stable and comparable?
- Where `State` is read — is frame-rate
Stateread during composition vs layout/draw? - Back-writing across phases — does a later phase write snapshot state that invalidates an earlier phase? Examples: map/list mutation during composition that re-invalidates the same composition;
onSizeChanged(layout phase) writing state read by a sibling in composition.
Axes 2 and 3 often overlap (a sibling reading measured size in composition is both a deferred-read violation and a layout → composition back-write). Axis 1 is independent.
Route here → focused skill
| Primary suspicion | Next skill |
|---|---|
Skipping, unstable params, compiler/composables.txt churn | `compose-stability-diagnostics` |
Frame-rate State read phase (composition vs layout/draw) | `compose-state-deferred-reads` |
putAll / map rebuild / cross-row height(state) during composition | `compose-state-deferred-reads` — § back-writing |
| Focus-driven side work in composable body | `compose-side-effects` — snapshotFlow |
| Evidence for multiple axes | Apply matching skills in parallel |
Review order
- Reproduce one transition (focus move, insertion, scroll) and note which composables recompose.
- If counts spike on unchanged lazy items, check back-writing (composition mutations and cross-row measurement) before blaming stability.
- If counts climb every frame during scroll/animation, check deferred reads.
- If skipping fails despite stable data, check parameter stability and compiler reports.
- Re-measure after each fix.
False leads
These changes often do not reduce recomposition count:
| Attempt | Why it fails |
|---|---|
remember(index) { isFirstRow(index) } instead of inline when (index) | Same inputs; no skipping benefit |
| Identity cache for read-only derived maps | Can serve stale overlays; remember(keys) is enough |
mutableIntStateOf + layout modifier on both measured and sibling rows | Sibling still reads size in composition unless measure-only |
Forcing Exactly(1) on both rows in focus-move tests | One row often correctly recomposes 0 times |
| Hoisting without stabilizing lambda captures | New lambda instance each frame still defeats skipping |
When NOT to apply
- Recomposition tracks real data changes, or the bug is correctness not cost.
- No profiler / compiler signal suggests a problem.
Related
- `compose-state-authoring` — authoring
mutableState*safely.
