6/22 ソースマージ 後 BGMメモリリークの問題

この修正は影響範囲が広く一筋縄な即席な修正とはいかない模様

全BGM経路にわたるメモリリリース機構の不在 が 3層で確認できます。

① bgmObjectUrlCache が無制限に Blob を保持 ② Home.tsx の Luna BGM 用 addSoundIfNeeded がデッドコード化したまま AudioBuffer を作っている ③ シナリオ／バトル経路にも同じ罠

それぞれ、修正も検証も重い内容と思われるため 分けて対応予定です。

現状260626 最新develop の実機動作問題点確認 ーーー ホーム画面 sound メモリ 一覧

ーーー Safari console スニペット Object.keys(window.__pixiSound._sounds)

0
"se/blessing-levelup.mp3"
1
"se/cancel.m4a"
2
"se/chapter-unlock.m4a"
3
"se/charin.mp3"
4
"se/click.m4a"
5
"se/confetti.m4a"
6
"se/fanfare.mp3"
7
"se/melt-weapon.mp3"
8
"se/start.mp3"
9
"se/upgrade-fail.mp3"
10
"voices/sadias/call_instansys.m4a"
11
"sounds/bgm/charging.m4a"
12
"voices/mayaya/call_title.m4a"
13
"sounds/bgm/home.m4a"
14
"voices/luke/home_1.m4a"
15
"voices/luke/home_2.m4a"
16
"voices/luke/home_3.m4a"
17
"voices/luke/home_4.m4a"
18
"voices/luke/home_5.m4a"
19
"voices/luke/home_6.m4a"
20
"voices/luke/home_7.m4a"
21
"voices/luke/home_8.m4a"

ホーム画面BGM設定で、BGMを選択するたびに、メモリが積み重なっていたが、26/06/24 時点の develop ソースでは、問題が改善されていた。

末尾のCDN でダウンロードするBGMが 積み重なっていないことが確認できた。

commit番号 be538a6 の時点では、問題があったが、一部、代表の修正によって改善された模様

少なくとも、BGM設定変更画面でのメモリリークは改善された。

0
"se/blessing-levelup.mp3"
1
"se/cancel.m4a"
2
"se/chapter-unlock.m4a"
3
"se/charin.mp3"
4
"se/click.m4a"
5
"se/confetti.m4a"
6
"se/fanfare.mp3"
7
"se/melt-weapon.mp3"
8
"se/start.mp3"
9
"se/upgrade-fail.mp3"
10
"voices/sadias/call_instansys.m4a"
11
"sounds/bgm/charging.m4a"
12
"voices/mayaya/call_title.m4a"
13
"sounds/bgm/home.m4a"
14
"voices/luke/home_1.m4a"
15
"voices/luke/home_2.m4a"
16
"voices/luke/home_3.m4a"
17
"voices/luke/home_4.m4a"
18
"voices/luke/home_5.m4a"
19
"voices/luke/home_6.m4a"
20
"voices/luke/home_7.m4a"
21
"voices/luke/home_8.m4a"
22
"https://utsaqkhxqllqkazxzhow.supabase.co/storage/v1/object/public/sounds/sounds/e105a489-0ab7-4dfa-bb93-db494318d6c2/3331f692-60cd-4db7-b945…"

しかし、ソースコードを解析したところ、以下は、未修正の問題のようだ。

未修正の問題

リーク① bgmObjectUrlCache — Blob が永久常駐（最大の問題）

bgm-track.ts:22 の bgmObjectUrlCache は変更なし。 URL.revokeObjectURL はコードベース全体でどこからも呼ばれていない。

bgmObjectUrlCache.set(aliasOrUrl, objectUrl);  // ← 増える一方
// destroy() (line:118) は意図的に revoke しないコメントが残ったまま

BGM を切り替えるたびに .m4a 圧縮 Blob（数 MB）が Map に追加され続ける。 セッション中に再生した全 BGM 分が常駐する。

ーーーー

リーク② Home.tsx — addSoundIfNeeded が無用な AudioBuffer を生成

Home.tsx:604 の useEffect は手付かず。

addSoundIfNeeded(entry.url, entry.url);   // @pixi/sound へ登録 → AudioBuffer(PCM)
// ...isLoaded ポーリング...
soundManager.playBGM(entry.url, ...);     // 実再生は HtmlBgmTrack (HTMLAudio)

fd629a1a（HtmlBgmTrack 移行）以降、@pixi/sound 側の AudioBuffer は再生に一切使われていない。 PCM サイズは圧縮 m4a の 10〜30 倍になり得る。HtmlBgmTrack は <audio>.play() 内でロードを担うため、外側の isLoaded ポーリングも不要なデッドコード。

ーーーー

リーク③ Battle.tsx — BGM の二重登録

Battle.tsx:2354-2356：

assetPaths: [
  ...
  ...(bgmPath ? [bgmPath] : []),   // ← isSoundAlias(".m4a") = true → @pixi/sound に sound.add → AudioBuffer
],
bgm: bgmPath ? { alias: bgmPath } : undefined,  // ← HtmlBgmTrack → bgmObjectUrlCache Blob

bgmPath は .m4a で終わるため preload.ts:51-55 の isSoundAlias に引っかかり、@pixi/sound 経由で AudioBuffer が生成される。 さらに bgm option でも resolveBgmSrc → bgmObjectUrlCache に Blob が積まれる。 同じ BGM ファイルが AudioBuffer（巨大）と Blob の両方で常駐する二重コスト。

まとめ表

修正前 測定 safari console snipet

window.__audioMem = () => {
  const lib = window.__pixiSound;
  if (!lib?._sounds) { console.warn("window.__pixiSound._sounds なし"); return; }
  const rows = [];
  let total = 0;
  for (const [alias, snd] of Object.entries(lib._sounds)) {
    let buf = null;
    try { buf = snd?.media?.buffer ?? null; } catch { buf = null; }
    const ok = buf && typeof buf.length === "number";
    const bytes = ok ? buf.numberOfChannels * buf.length * 4 : 0;
    total += bytes;
    rows.push({
      alias: alias.length > 48 ? "…" + alias.slice(-46) : alias,
      kind: ok ? "WebAudio(PCM)" : (snd?.media?.constructor?.name ?? "?"),
      ch: ok ? buf.numberOfChannels : "-",
      sec: ok ? +buf.duration.toFixed(1) : "-",
      MB: +(bytes / 1048576).toFixed(2),
    });
  }
  rows.sort((a, b) => b.MB - a.MB);
  console.table(rows);
  console.log(`AudioBuffer total: ${(total / 1048576).toFixed(2)} MB / ${rows.length} sounds`);
  return { totalMB: +(total / 1048576).toFixed(2), count: rows.length };
};
__audioMem();

window.__audioMem = () => {
  const lib = window.__pixiSound;
  if (!lib?._sounds) { console.warn("window.__pixiSound._sounds なし"); return; }
  const rows = [];
  let total = 0;
  for (const [alias, snd] of Object.entries(lib._sounds)) {
    let buf = null;
    try { buf = snd?.media?.buffer ?? null; } catch { buf = null; }
    const ok = buf && typeof buf.length === "number";
    const bytes = ok ? buf.numberOfChannels * buf.length * 4 : 0;
    total += bytes;
    rows.push({
      alias: alias.length > 48 ? "…" + alias.slice(-46) : alias,
      kind: ok ? "WebAudio(PCM)" : (snd?.media?.constructor?.name ?? "?"),
      ch: ok ? buf.numberOfChannels : "-",
      sec: ok ? +buf.duration.toFixed(1) : "-",
      MB: +(bytes / 1048576).toFixed(2),
    });
  }
  rows.sort((a, b) => b.MB - a.MB);
  console.table(rows);
  console.log(`AudioBuffer total: ${(total / 1048576).toFixed(2)} MB / ${rows.length} sounds`);
  return { totalMB: +(total / 1048576).toFixed(2), count: rows.length };
};
__audioMem();

[Log] AudioBuffer total: 119.97 MB / 22 sounds (index-CDUF7703.js, line 16)

< {totalMB: 119.97, count: 22}

上記は、アプリ起動時ホーム画面

ーーー

< ホームBGM設定画面で、"落ち着きアルタ"  選択時 >

[Log] AudioBuffer total: 170.48 MB / 23 sounds (index-CDUF7703.js, line 16) < {totalMB: 170.48, count: 23} 上記は、ホームBGM設定画面で、"落ち着きアルタ"  選択時)

ーーー

また、以下 3つは、アプリ起動後ホーム画面の時点では、メモリ解放すべきなので、解放しておく。

"sounds/bgm/charging.m4a" (PCM展開して38.2MB メモリを食いっぱなし)

"voices/{キャラクター名}/call_title.m4a"

"voices/{キャラクター名}/call_instansys.m4a"

ーーー

タイトル BGM ハンドリング を 修正 38MB メモリ無駄削減

一応実機で確認しているが、ホーム画面BGM設定で、BGMメモリが積み上がる問題は完全には解決していなかった模様。

fix(sound): タイトルcallボイスの常駐AudioBufferをplayOneShotで解放.

call_title / call_instansys をplaySEWhenReady からplayOneShot(cancellable)

に置換。旧実装は @pixi/sound に AudioBuffer を常駐させ、タイトル離脱後も解放されず残っていた。再生完了/離脱時に自動解放されるようにした。

修正後 タイトル画面 メモリ

タイトルBGM 38MB と、タイトルコール2音が playoneshot で メモリ解放

0
"se/blessing-levelup.mp3"
1
"se/cancel.m4a"
2
"se/chapter-unlock.m4a"
3
"se/charin.mp3"
4
"se/click.m4a"
5
"se/confetti.m4a"
6
"se/fanfare.mp3"
7
"se/melt-weapon.mp3"
8
"se/start.mp3"
9
"se/upgrade-fail.mp3"
10
"sounds/bgm/home.m4a"
11
"voices/luke/home_1.m4a"
12
"voices/luke/home_2.m4a"
13
"voices/luke/home_3.m4a"
14
"voices/luke/home_4.m4a"
15
"voices/luke/home_5.m4a"
16
"voices/luke/home_6.m4a"
17
"voices/luke/home_7.m4a"
18
"voices/luke/home_8.m4a"

[Log] AudioBuffer total: 81.27 MB / 19 sounds (index-DsvyJyrs.js, line 16)

< {totalMB: 81.27, count: 19}

修正前より40MB メモリ無駄の削除

さらに修正 ホームBGM設定変更 の　メモリ積み上げ問題対策 ーーー

INS-887 fix(sound): ホームBGM設定切替の常駐AudioBufferリークを解消.
Luna BGM 切替で addSoundIfNeeded が @pixi/sound に AudioBuffer(1曲数十MB)を常駐させ、切替ごとに積み上がっていた(実機で複数曲分が滞留)。再生は元々HtmlBgmTrack 経由なので、@pixi/sound への登録・ロード完了ポーリング・解放管理を撤廃し playBGM 一本に統一した。

修正後、ホームBGM設定変更で、 変更前のBGMメモリ確保が積み重なる問題が改善した。

何度 変更しても、以下 home.m4a CDN の音楽URL 1つ 以外は、音楽URL が増え続ける現象が改善された。

さらに修正。

INS-887 fix(sound): BGM objectURL Blobのリークをrevokeで解消.

bgmObjectUrlCache が revoke されず、再生した全BGMの圧縮Blobが常駐していた

(リーク①)。_ensureMainPlaying の _clearBgmFadeTimers 直後(生存トラックが

現曲のみと保証される安全点)で、再生中/次に鳴らす alias だけ残して revoke する

revokeBgmObjectUrlsExcept を追加。HtmlBgmTrack の再生機構は無変更。

ホームBGM設定変更しても、最大2曲のみ preload 。他は、revoke されるようになった。

TOP BGMは 基本的に 2曲

動作検証、ホーム→キャラバン 問題なし

[Log] AudioBuffer total: 65.86 MB / 26 sounds (index-C6K9wrRW.js, line 16)

< {totalMB: 65.86, count: 26}

キャラバンから ホームに戻るとデフォルトBGM含めて3曲

ホームBGM設定変更すると、4曲 preload してる。大丈夫か？ キャラバンが残っているのが気になる。

さらにそのままBGM変更したら、ホームBGMセレクト候補から 1曲だけに revoke された。一応、ホームBGM設定選択画面で、revoke 論理は、動作していることは確認できた。

キャラバンのBGMが残っているのは気になるが、バトルとか 画面遷移でpreloadが消えれば良しとする。消えなければ 対処したい。

キャラバンから ガチャ画面へ遷移 3曲preloadされていた。

[Log] AudioBuffer total: 127.89 MB / 13 sounds (index-C6K9wrRW.js, line 16)

< {totalMB: 127.89, count: 13}

ガチャ画面からキャラバン 3曲preload されていた。

[Log] AudioBuffer total: 139.72 MB / 27 sounds (index-C6K9wrRW.js, line 16)

< {totalMB: 139.72, count: 27}

ホーム画面へ戻ると4曲プリロードされていた203.11MB

[Log] AudioBuffer total: 203.11 MB / 22 sounds (index-C6K9wrRW.js, line 16)

< {totalMB: 203.11, count: 22}

これで メインクエストへ。4曲preloadされていた。 めがみとキャラバンは、少なくともバトル開始時にはrevoke したいが。

[Log] AudioBuffer total: 207.08 MB / 20 sounds (index-C6K9wrRW.js, line 16)

< {totalMB: 207.08, count: 20}

戦闘開始しても、めがみとキャラバンの revoke が確認されなかった。 この2曲は、メインクエスト開始時点で revoke するように命令を追加編集する。

[Log] AudioBuffer total: 246.22 MB / 75 sounds (index-C6K9wrRW.js, line 16)

< {totalMB: 246.22, count: 75}

240MBを超えたあたりから、発熱しだした。

戦闘中断 リザルト画面

138MB に下がった。 戦闘終了では、 ホームから引き摺っているBGMメモリ以外は、revoke成功していた。

上記 リザルト画面で 章選択画面に自動で遷移されたらBGMが停止している問題が生じていた。別件のバグだ。このバグは安定して再現しなかった。

プリロードは、 ホーム画面に設定したBGM、ガチャ、キャラバン 、この3つあれば十分。 章を選んで メインクエストを開始したら、ガチャ キャラバンは、preload から revoke でOK。

バトルが終了したら、ホーム画面に設定してpreloadしてあるBGMを呼び出せばOK

おそらく ホームのBGMは、26.34 MBの BGM設定なはずなので、これが鳴らせれば成功だが、現状はそうなっていない。

修正によって、章選択で メインクエスト入場時 不要なpreloadが削除された。

従来は、ガチャとキャラバンのBGMがpreloadされっぱなし。 約100MB 無駄メモリ

修正後 章選択メインクエスト入場時。

[Log] AudioBuffer total: 151.95 MB / 18 sounds (index-B4F6T8Oh.js, line 16)

< {totalMB: 151.95, count: 18}

結構大幅に、メモリの無駄遣いが減った。

4人の仲間を連れてバトル開始しても、200MB以内におさまった。

発熱も 減少したように思う。

修正によって、バトル中断後 章選択画面で、BGM停止問題が改善された。

古いサウンドシステムの PCM preload が 残っていて邪魔している。

さらに修正して キャラバンにいっても、ガチャにいっても、PCM preload されなくなった。

( home BGMのみ、後回し中 )

同様の問題で、章選択後 入場時の "sounds/bgm/battle_preparation.m4a" も PCM preload もなくす。