Skip to content

PLAN.ja.md

Latest commit

 

History

History
82 lines (52 loc) · 6.99 KB

PLAN.ja.md

File metadata and controls

82 lines (52 loc) · 6.99 KB
Raw

English | 日本語

プラン

出荷済みの機能は README の「ステータス」に、仕組みは ARCHITECTURE.ja.md にあります。このファイルには、残っている作業、重い作業を早まって始めないための着手条件、形を変えたときの移行メモを置きます。

残作業

  • ステージフレームとピクチャーインピクチャーの実画面での確認. ヘッドレスのトレースで測れるのはメインスレッドの負荷だけです。実際のモニターでのステージフレームと PiP(ベータ)のフレームペーシングは確認できていません。
  • YouTube がチャットを作り直したときの監視. YouTube が #items を作り直した後の付け直しと、チャットを閉じている間の代役チャット iframe には自動テストがありません。どちらも実際の配信で手で確認しています。
  • PWA の実機確認. デプロイ済みの PWA で下のチェックリストを実行します。
  • PWA でのピン留めとドラッグ. PWA では YouTube の iframe がポインタ入力を持つので、先にキャプチャ用の層が必要です。拡張では動作します。

PWA 実機チェックリスト

端末: iOS Safari(最新、低電力モードをオフ、次にオン)、Android Chrome(最新、中価格帯の端末)。フレーム p95 が基準に近ければ、古い Android 端末も。

  1. デプロイ済みの PWA を開く。
  2. URL 欄と Web Share Target の両方からライブ配信を始める。
  3. タップで再生、一時停止、独自の操作部が動く。
  4. ライブではシークバーが隠れ、リプレイでは使える。
  5. 対応環境では Media Session のメタ情報が出て、再生/一時停止が効く。
  6. Wake Lock が前面にいる間は画面を点け続け、停止で解放する。
  7. ?perf=1 を開き、チャットの多い配信を 3 分以上見る。fps、frameP95、frameP99、longTasks、active、dropped を記録する。

基準を満たさない端末があれば、まず renderScalePct、spawnPerFrame、maxActive を下げます。iOS と Android で renderScalePct の既定値を分けるのは、両方の計測がそれを支持するときだけです。最終的な値と HUD の画面はリリースノートに残します。

着手条件

根拠がそろうまでは始めません。

新しいスコアラーの経路

スコアラーはコンテンツスクリプト(チャット iframe)と PWA で動く素の JavaScript で、ボトルネックではありません。別の経路を足すのは次をすべて満たすときだけです。

  1. バッチ型または状態を持つスコアラーが、拡張のホットパスの外に先に存在する
  2. Chrome/V8 のベンチマークで、JS スコアラーに対してはっきりした改善が端から端まで出る
  3. 拡張が新しい形に依存する前に CONTRACT.ja.md を更新する
  4. マニフェストの CSP と web accessible resources を見直す

重いレンダラー(OffscreenCanvas、ワーカーでのラスタライズ)

上のチェックリストで、実機が次のどれかを示さない限り Canvas2D のままにします。

  • active < maxActive の状態で frameP95 > 33 ms が 30 秒以上続く
  • 通常のチャットの盛り上がりで Long Task が繰り返し増える
  • コメントが流れている間、タッチや動画の操作がはっきり遅れる

試作には、それらの端末での前後の HUD 画面を付け、絵文字、スーパーチャットの色、コメント一覧のスクロールを悪化させないこと。

中継の単一化(WebSocket + Durable Object)

中継はステートレスな HTTP ポーリングのままにします(エッジキャッシュ、処理中リクエストの集約、レート制限。ARCHITECTURE.ja.md の「中継の堅牢性とコスト」)。次に進むのは、中継の計測が次を示したときです。

  • 同じ動画を多くの視聴者が見ているのに MISS 率が高い
  • キャッシュを調整しても上流の 429/5xx がまとまって出る
  • 再解決や continuation の入れ替わりが続き、視聴者に見える遅延が出る

候補: 動画 ID ごとに 1 つの Durable Object が上流へのポーリングを 1 本だけ持ち、WebSocket でクライアントに PollEnvelope をまとめて配る。リプレイではクライアントが再生位置を送る。WebSocket 側を計測し終えるまで HTTP の /api/livechat を予備として残す。受け入れ条件: 採点や描画を Worker に移さない。切断が続いても動画ごとのメモリが有界である。リプレイの位置はまとめるか間引き、1 人がシークを繰り返しても上流への呼び出しが増えない。上流への呼び出し数、遅延、エラーを 2 つの経路で比べる計測がある。

移行メモ

形(CONTRACT.ja.md):

  • 中継は continuation トークンのパーセントエスケープをもう一段デコードしてから検証とキャッシュ検索を行います。エンベロープとクライアントのエンコードは変わりません。
  • paidColor は ChatMessage と描画ペイロードの任意・表示専用のフィールドです。これがないメッセージも有効で、amount は引き続き null 可です。
  • リプレイのポーリングは cont と offset に replay=1 を付けます。replay=1 のない cont + offset は 400 になります。中継はリプレイの ended を常に false で返し、リプレイの終わりはプレイヤーが判断します。

保存済みの設定:

  • lineHeight(px)は読まなくなりました。保存済みの値は lineHeightScale の既定値に正規化されます。エンジンには引き続き px(fontPx * scale)を渡します。
  • フィルターの保存データに mode(drop / censor / replace)と replacement が加わりました。古いレコードは drop と既定の置換文字に正規化されます。
  • 真偽値の scaleWithPlayer は fontScaleMode セレクト(fixed / up / relative)になりました。保存済みの true は up、false は fixed として読みます。relative は fontPx を 720px のプレイヤーでのサイズとして扱い、小さいウィンドウでは縮小もします(下限 0.5 倍)。

ストアの審査

却下されたら理由をここに書きます。

クレジット

いくつかの設定と操作(種類別の表示と文字サイズ、投稿者名の表示モード、縁取り、流れる向き、密度、最大幅、折り返し、ユーザー CSS、ピン留め、タイムシフト)は ys-j/YoutubeLiveChatFlusher のアイデアに倣っています。実装は独自で、コードはコピーしていません。