JKVideoを読む：Bilibili向けReact Nativeクライアントの機能と停止告知

JKVideoが目指した画面体験と現在の位置づけ

JKVideoは、tiajinsha/JKVideoで公開されているTypeScript製のReact Nativeアプリです。READMEは「高颜值第三方 B 站 React Native 客户端」と説明し、Bilibiliに似た動画アプリの画面体験を、Android、iOS、Webで組み立てることを主題にしています。ホームには人気動画とライブ配信を置き、動画詳細、ライブ詳細、検索、ダウンロード、設定をアプリ内のルートとして分けています。単にAPIのサンプルを並べるのではなく、再生、コメント、弾幕、ログイン、端末内の状態を一続きの利用場面として扱う設計です。

画面の構成から見える狙いは、公式サービスのブラウザ画面をそのまま埋め込むことではなく、モバイルアプリらしい操作を自前のコンポーネントでまとめることです。ホームではBigVideoCardによるインライン再生、横方向のジェスチャー、動画とライブカードの混在を想定し、別画面へ移動した後も下部のミニプレイヤーで再生を続けます。検索と詳細ページを独立したルートにしているため、閲覧と再生の状態をどの範囲で共有するかが実装を読むときの論点になります。

ただし、これはBilibili公式アプリでも、同社と提携したクライアントでもありません。READMEの重要公告には、bilibiliの弁護士書簡を受け、B站 APIの呼び出しと関連する模倣行為を停止するよう求められたため、リポジトリの保守と更新を終了したとあります。現在のコードを動かせる可能性と、外部サービスに接続して使い続けてよいかは別の問題です。実運用を前提にせず、実装の読み解きやReact Nativeの学習を目的に評価するのが安全な読み方です。

DASHとHLSを分ける再生パイプライン

動画再生の中心はDASHです。READMEによれば、Bilibiliから得たDASHストリームをもとにbuildDashMpdUri()でローカルのMPD URIを組み立て、react-native-videoとネイティブ側のExoPlayerでデコードします。1080Pと4K HDR、Dolby Visionまでを機能説明に挙げていますが、これはREADMEが掲げる対応範囲です。端末、アカウント、配信側の条件を含めた再生結果を保証する記述ではありません。

DASHの実装を評価する際は、映像と音声のトラック選択、再生URLの有効期限、通信失敗時の表示、画質変更時の再取得を分けて考える必要があります。READMEはMPDを構築する関数名と再生ライブラリを示していますが、これらの細部の挙動や再試行方針までは説明していません。したがって、4K対応という見出しだけで端末性能や安定性を判断するのは適切ではありません。

ライブ配信は動画と同じ扱いにせず、HLSを選ぶ経路として説明されています。FLVライブストリームはHTML5とExoPlayerのどちらでも扱えないため、対応する入力を自動的にHLSへ寄せるという整理です。Expo Goでは一部の画質に制限があり、WebViewを使った再生に降格します。完全なDASH再生や弾幕を確認したい場合はDev Buildが必要だとREADMEにあります。再生形式を一つに固定せず、ネイティブ、WebView、HLSを環境ごとに切り替える点が、このアプリの実装上の読みどころです。

動画弾幕とライブ弾幕は入力経路が異なる

弾幕機能は、動画とライブ配信で情報の入り方を分けています。通常の動画では、XMLで表現された弾幕の時間軸を読み込み、再生位置に合わせて画面へ流します。READMEは5レーンのオーバーレイを挙げており、映像に弾幕を焼き込むのではなく、プレイヤー上のUIレイヤーとして表示する発想です。動画の再生時刻と描画状態を同期させる必要があるため、単純な一覧表示よりも、再生状態を共有する設計が必要になります。

読み手が確認すべきなのは、弾幕データを取得できるかだけではありません。過去位置へシークしたときに表示をどう再計算するか、短時間に大量のメッセージを受けたときに描画をどう抑えるか、画面を離れたときにタイマーや購読を確実に止めるかも、操作感と端末負荷を左右します。READMEはこうした実装結果を報告していないため、5レーンという説明から性能を推測することはできません。

ライブ配信ではWebSocketから弾幕をリアルタイムに受信します。受信したメッセージには艦長マークやギフト数の表示が含まれると説明されています。ここでも、READMEに書かれた機能名と、現在のサービス側仕様に接続できることは分けて扱う必要があります。外部APIの認証、イベント形式、接続の継続条件は配信側の変更に影響されます。JKVideoを教材として読むときは、弾幕描画の見た目だけでなく、動画の時刻同期とWebSocketイベントの状態更新がどの境界に置かれているかを確認すると、構成を理解しやすくなります。

WBI署名とQRコードログインが担う境界

APIアクセスに関わる部分では、WBI署名を外部暗号ライブラリに頼らず、TypeScriptでMD5を実装したとREADMEが説明しています。navインターフェースの署名情報は12時間自動でキャッシュされます。ここで確認できるのは実装方針とキャッシュ時間であり、認証が永続することや、APIの利用が許可されることではありません。署名の仕様はサービス側の前提に依存するため、現在の外部APIと一致するかはリポジトリの説明だけでは判断できません。

ログインはQRコードを生成し、2秒間隔で状態をポーリングし、レスポンスヘッダーからSESSDATA Cookieを抽出する流れです。QRコードは10分で期限切れになり、ログインモーダルを閉じて開き直すと更新されるとされています。Cookieはアカウントに直接結び付く情報なので、学習目的で試す場合もログ、画面録画、共有端末に残さない設計が必要です。READMEはSESSDATAを取得する実装を記載していますが、保存期間や端末保護の詳細までは示していません。その未記載部分を、利用者側の確認事項として残すべきです。

Zustandを中心にしたアプリ内の状態分割

技術スタックはReact Native 0.83、Expo SDK 55、expo-router v4、Zustand、Axios、@react-native-async-storage/async-storageを挙げています。画面遷移はファイルベースのルーティングで構成され、アプリのルートにはホーム、動画詳細、ライブ詳細、検索、ダウンロード、設定が置かれます。componentsにはプレイヤー、カード、弾幕などのUI、hooksには動画リストや再生ストリームなどのデータ処理、servicesにはAxiosによるBilibili APIのラッパーを置く構成です。

storeはログイン、ダウンロード、再生、設定を担い、VideoStoreによって画面を移動してもミニプレイヤーの再生を継続します。utilsには画像プロキシ、MPD構築、表示形式の変換が含まれます。これらの名前はREADMEのプロジェクト構造から確認できますが、各モジュールの細かい責務やエラー処理の全量をREADMEだけで証明することはできません。実装を読む際は、servicesが受け取ったデータをhooksがどう整形し、storeがどのタイミングで永続化するのかを、実際のソースと照合する必要があります。

Expo Go、Dev Build、Webの差分

起動方法は三つあります。Expo Goではリポジトリをクローンしてnpm install、npx expo startを実行し、AndroidまたはiOSのExpo Goで端末のQRコードを読み取ります。READMEは、この方法を短時間で試せる入口として扱う一方、画質の一部が制限され、動画再生がWebViewへ降格すると明記しています。完全なDASH 1080P以上のネイティブ再生と弾幕システムを確認する場合は、npx expo run:androidまたはnpx expo run:iosによるDev Buildを使います。iOS側にはmacOSとXcodeが必要です。

初回起動の説明は短いですが、利用者が準備すべき条件は環境ごとに異なります。Expo Goは開発サーバーと端末が同じネットワークで到達できること、Dev Buildはネイティブビルド環境を用意すること、Webは画像プロキシを別に起動することが前提です。AndroidのAPKを使う場合も、READMEは未知の提供元からのインストール許可が必要だとしています。配布物を入れる場合は、取得元とハッシュを確認し、普段使いの端末でアカウントCookieを入力しない判断も必要です。

Web版はnpx expo start --webで起動できますが、画像のReferer制限に対応するため、READMEはnode scripts/proxy.jsでポート3001のローカルプロキシを起動する手順を示しています。AndroidではReleasesからAPKを直接取得する経路も記載されています。ここで注意したいのは、起動手順が存在することと、現在も外部APIを含む全機能が動作することは同じではない点です。停止告知がある以上、試す場合はネットワーク接続の範囲、アカウント利用、取得するコンテンツの権利を事前に確認し、学習用の隔離環境に限定してください。

ダウンロードとLAN共有を評価するときの注意

ダウンロード管理は複数の画質を選び、バックグラウンドで取得する機能として紹介されています。さらに、内蔵HTTPサーバーがローカルネットワーク共有用のQRコードを生成し、同じWi-Fiに接続した別端末からダウンロード済みのコンテンツを再生できるとされています。これは、端末の保存処理、バックグラウンドタスク、ローカルサーバー、共有用URLを一つの利用場面に結び付けた機能です。学習教材としては、ファイルの命名、途中失敗、空き容量、サーバー停止などを検討する題材になります。

評価の手順を分けると、機能の説明に引きずられにくくなります。まず公開されたコードとREADMEの記述を固定し、次に対象端末で再生、停止、画質変更、通信切断、画面遷移を個別に確認します。その後、保存ファイルの場所、Cookieの扱い、共有URLの有効範囲、削除操作の結果を記録します。再生できたという一回の結果だけでは、バックグラウンド処理や失敗時の回復まで確認したことにはなりません。外部接続を伴うため、アカウント、通信先、保存内容を事前に一覧化する必要があります。

しかし、READMEはLAN共有の認証、推測されにくいURL、アクセスログ、暗号化、保存した動画の利用許諾を詳しく示していません。同じWi-Fiでも、信頼できる端末だけが参加しているとは限りません。共有を実際に試すなら、ルーターのネットワーク分離、HTTPサーバーの公開範囲、停止操作、端末内の保存場所を確認し、第三者の映像を無断で複製しないことが前提です。READMEの免責事項も、動画コンテンツの権利は原作者とBilibiliにあると述べています。機能が便利でも、権利と安全性の確認を省けるわけではありません。

停止告知、MITライセンス、採用判断

JKVideoのライセンス欄はMITを示し、READMEは著作権者を2026年のJKVideo Contributorsとしています。MITはコードの利用、複製、改変、配布などについて条件を定めるライセンスですが、外部サービスのAPI利用許可や、第三者コンテンツの再配布権を与えるものではありません。コードのライセンスと、接続先サービスの規約、映像や画像の権利は別々に確認する必要があります。依存パッケージのライセンス、APKに含まれる素材、画面の商標表示も、コード本体のMIT表記だけでは整理できません。

採用判断では、READMEの停止告知が最優先です。これは保守が止まっているという単なる更新頻度の話ではなく、bilibiliからAPI呼び出しと関連する模倣行為の停止を求められたという、プロジェクト自身の明示的な説明です。公開リポジトリを読んでReact Nativeの画面構成や再生処理を学ぶ用途なら、コードの歴史を理解する材料になります。一方、商用アプリの基盤、継続的な配信クライアント、他人に配布するAPKとして扱うには、法務、APIの許諾、アカウント情報の保護、依存関係の更新を別途確認しなければなりません。現時点で動くかどうかを試す前に、停止告知を読み、使う範囲を学習用に限定できるかを決めるべきです。

採用候補として残すなら、最初に確認する項目を明文化します。第一に、接続先の規約と現在のAPI仕様に反していないか。第二に、SESSDATAやダウンロードファイルをどこへ保存し、いつ消すか。第三に、停止したプロジェクトを誰が保守し、依存ライブラリと脆弱性をどう更新するか。第四に、画像、動画、弾幕、ロゴをどの権利で扱うかです。これらに回答できない状態では、機能の多さを理由に外部公開へ進めるべきではありません。

編集部の結論

JKVideoは、Bilibiliの動画とライブ配信をReact Nativeで扱う実装例として、再生経路、弾幕、認証、状態管理を一つのリポジトリで読める点に価値があります。一方、READMEはbilibiliからAPI呼び出しと関連する模倣行為を停止するよう求める弁護士書簡を受け、今後の保守と更新を止めたと告知しています。したがって、現行サービスとして導入する対象ではなく、MITライセンス、Bilibiliの利用条件、コンテンツの権利、セキュリティを確認したうえで、個人の学習用コードとして範囲を限定して読むのが適切です。

公式情報源

1. Official README
2. Project repository
3. Release notes