Android: snapshots ~10× slower while a looping Reanimated opacity animation is on screen (follow-up to #3558)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- android, react-native, typescript
調査の方向性
Start by reading the Android snapshot implementation and the cache-miss handling on the UI thread; the issue does not name specific source files or tests. Compare repeated captures with the opacity loop running and held still, using the provided setup and measurements. Done means identifying and addressing the animation-related snapshot latency while keeping captures successful and including the sheet root.
索引モデルが issue の本文から書いたものです。
説明
Follow-up to #3558, split out as asked. #3611 (0.21.28) fixed the missing-window capture failure. This issue tracks the remaining latency: Android snapshots are about 10× slower while one small looping animation is on screen.
Setup
- Screen: a full-height
@lodev09/react-native-true-sheet4.0.0-beta.24 sheet (on Android, a separate dialog window). Its header holds an 8×8Animated.Viewwhose opacity loops forever with Reanimated 4.5.4:withRepeat(withSequence(withTiming(0.4, 800 ms), withTiming(1, 800 ms)), -1). - React Native 0.86.3 (New Architecture), Expo SDK 57, release build.
- Emulator
sdk_gphone64_arm64, Android 16 (API 36), 1080×2400. Host: Apple M5 Max, macOS, shared with other emulators and builds. - "Animations off" means
window_animation_scale,transition_animation_scaleandanimator_duration_scaleset to0before launch. Reanimated reads that as Reduce Motion and holds the dot still. Nothing else on screen changes.
0.21.28, 2026-10-17 (the table requested in #3558)
Same session, same sheet. Host load average was 170–240 for both rounds.
| Device animations | Snapshot wall time | Sheet root in snapshot |
|---|---|---|
| On (2 rounds) | 4.3–15.1 s | 12/12 |
| Off (Reanimated holds the dot still) | 0.3–0.5 s | 6/6 |
On the slow captures, the daemon's durationMs matched the wall time (4.1–5.3 s on the ones checked).
0.21.28 vs 0.21.29-nightly.20261019.75 (includes #3790), 2026-10-19
Same app build, same emulator, one session. Each block is 7 snapshot --json calls; the first call is dropped because it reinstalls the shared helper APK. Blocks run in ABAB order. The numbers are the helper's data.androidSnapshot.elapsedMs. Every capture succeeded and contained the sheet root.
| Device animations | Host load | 0.21.28 median (range) | nightly median (range) |
|---|---|---|---|
| On | 29–41 | 676 ms (535–1246) | 536 ms (301–681) |
| On | 16–27 | 443 ms (263–1140) | 439 ms (302–6664, 1 outlier) |
| Off | 17–24 | 164 ms (151–232) | 40 ms (39–46) |
What this shows on our screen:
- #3790 makes the static capture about 4× faster (164 → 40 ms).
- With the loop running, it changes little at moderate load: 676 → 536 ms at load 29–41, and 443 → 439 ms at load 16–27.
- The loop's cost on the nightly is about 11× (40 ms → 440–540 ms), with an occasional multi-second capture (6.7 s once, as load rose).
- Host load scales the slowdown. The same 0.21.28 measured about 0.5–1.2 s here and 4–15 s at load 170–240.
So the remaining cost seems to come from the animation itself rather than traversal order. That fits your note that Android serves cache misses on the UI thread, which a running animation keeps busy.
Impact and workaround
Anything that snapshots repeatedly (wait, press after a settle, replays) pays this on every capture while a pulsing "live" indicator is on screen. That's common in timers, workouts and live-status UIs. Our workaround is animation scales at 0 on the test emulator, as Espresso suites do. That isn't available when the animation is the thing under test.
Happy to run a build against this screen. I can attach the request logs (requests/*.ndjson) for any of the runs above, or put together a minimal repro app (one TrueSheet sheet with the withRepeat opacity loop).
- 主要言語
- TypeScript
- スター
- 5k
- フォーク
- 334
- 平均マージ
- 12時間 13分
- マージ済み PR（30日）
- 723
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
callstack/agent-device のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 87/100
callstack/agent-device#3819 ·
メンテナーはふだん 1 日以内に返信
-
macOS helper audio-probe always reports -90 dBFS: AVAudioPCMBuffer frameLength set after the copy対応中かも @jipeng6036-del が今日担当しました。 オープンbug ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
callstack/agent-device#3771 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
callstack/agent-device#1869 ·
メンテナーはふだん 1 日以内に返信
-
Android smoke: first fixture capture stalls before any readable snapshot対応中かも @thymikee が今日担当しました。 オープンbug needs-triage
callstack/agent-device#3831 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 15/100
callstack/agent-device#3808 ·
メンテナーはふだん 1 日以内に返信
callstack/agent-device の issue をすべて見る
似ている issue
-
area:workflow bug ready-for-human
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
fil-donadoni/tolaria#6108 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
apache/rocketmq-dashboard#7234 ·
メンテナーはふだん 3 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
vitest-dev/vitest#11656 ·
メンテナーはふだん 1 日以内に返信
-
e2e-failure ready-to-code
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
redhat-developer/rhdh-plugin-export-overlays#4460 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
ehmpathy/rhachet-roles-bhrain#655 ·
メンテナーはふだん 1 日以内に返信