ApsaraVideo VOD:プレイヤーライフサイクル戦略

プレーヤーライフサイクル戦略

プレーヤーライフサイクル戦略は、プレーヤーインスタンスのライフサイクルを管理するためのアーキテクチャです。取得、リサイクル、クリアなどのコア操作を定義し、プレーヤーリソース管理をビジネスロジックから分離します。

ビジネスシナリオごとに、プレーヤーインスタンスの管理要件は異なります。

Strategy パターンの利点

Strategy パターンは、プレーヤーライフサイクルの管理において以下のコアな利点を提供します。

• デカップリング： ビジネスロジックを、プレーヤーインスタンスの生成と破棄の詳細から分離します。

• 柔軟性： ビジネスロジックを変更することなく、ランタイムに戦略を切り替えることができます。

• 拡張性： 特定のビジネスニーズに合わせてカスタム戦略を実装できます。

• 可観測性： 統一されたライフサイクルイベントにより、モニタリングとデバッグが容易になります。

解決すべき課題

1. 分散管理：プレーヤーインスタンスを制御するための統一された仕組みがありません。

2. パフォーマンスオーバーヘッド：プレーヤーインスタンスの生成と破棄を頻繁に行うと、リソースが無駄になります。

3. 再利用の課題：異なるシナリオ間でプレーヤーインスタンスを再利用できません。

4. メモリ制御の欠如：メモリフットプリントを効果的に制御できません。

コアバリュー

アーキテクチャ上の利点：

• 戦略のデカップリング：プレーヤーリソース管理をビジネスロジックから分離し、責務を明確化します。

• ランタイム切り替え：アプリケーションを再起動せずに戦略を切り替え可能です。

• スレッドセーフ：すべての戦略実装は、複数スレッドから安全にアクセスできます。

• イベント駆動：イベントバスを介してライフサイクルイベントを発行し、モニタリングを容易にします。

コア機能

ストラテジーの種類

AliPlayerKit は、4 つの組み込みプレーヤーライフサイクルストラテジーを提供します。

ストラテジーの詳細

DefaultLifecycleStrategy (デフォルトのストラテジー)

これは最もシンプルなストラテジーです。acquire() を呼び出すたびに新しいインスタンスが作成され、recycle() を呼び出すたびにすぐに破棄されます。

主な特徴：

• ステートレスであり、常に新しいインスタンスを提供します。

• 再利用はなく、シンプルなシナリオに適しています。

• メモリフットプリントが低い (リソースは使用後すぐに解放されるため)。

ReusePoolLifecycleStrategy (再利用プールストラテジー)

オブジェクトプールパターンに基づいており、このストラテジーはアイドルプールとアクティブリストを維持します。インスタンスの再利用には LIFO (後入れ先出し) ポリシーを使用します。

主な特徴：

• アイドルプールには LIFO ポリシーが適用され、最後に使用されたインスタンスが最初に再利用されます。

• インスタンスを事前に作成するためのプリロードをサポートします。

• プールの容量は設定可能です。容量を超えた場合、インスタンスは破棄されます。

• ショート動画リストや情報フィードのシナリオに最適です。

IdScopedPoolLifecycleStrategy (ID スコープのストラテジー)

uniqueId ごとに個別のプレーヤーインスタンスを維持し、特定の ID に対しては常に同じインスタンスを返します。インスタンスの数を制御するために LRU (Least Recently Used) メカニズムを使用します。

主な特徴：

• ID にバインドされており、同じ ID に対しては常に同じインスタンスを再利用します。

• LRU エビクションメカニズムにより、最も長い間使用されていないインスタンスが自動的にクリーンアップされます。

• バインドされていないインスタンスを事前に作成するためのプリロードをサポートします。

• 動画のプリロードや複数動画の切り替えシナリオに最適です。

SingletonLifecycleStrategy (シングルトンストラテジー)

単一のグローバルプレーヤーインスタンスを維持します。uniqueId に関係なく、常に同じインスタンスを返します。

主な特徴：

• グローバルに一意であり、すべての呼び出し元が同じインスタンスを共有します。

• メモリフットプリントが最も低いです。

• 複数の動画の同時再生には適していません。

ライフサイクルイベント

ストラテジーはライフサイクルイベントを発行し、イベントバスでリッスンできます：

デフォルトストラテジーの使用

追加の設定は不要です。プレーヤーを使用する最もシンプルな方法です：

// コントローラーを作成します (DefaultLifecycleStrategy が自動的に使用されます)
AliPlayerController controller = new AliPlayerController(context);

// プレーヤーをアタッチします
AliPlayerModel model = new AliPlayerModel.Builder()
        .videoSource(videoSource)
        .build();
controller.configure(model);
playerView.attach(controller);      

再利用プールストラテジーの使用

このストラテジーは、ショート動画リストや情報フィードのシナリオに最適です：

// 再利用プールストラテジーのシングルトンインスタンスを取得します
ReusePoolLifecycleStrategy strategy = ReusePoolLifecycleStrategy.getInstance();

// プール容量をセットします (任意。デフォルトは 3)
strategy.setMaxPoolSize(3);

// コントローラー作成時にストラテジーをインジェクトします
AliPlayerController controller = new AliPlayerController(context, strategy);

// 終了時にリソースをクリーンアップします
strategy.clear(); 

ID スコープストラテジーの使用

このストラテジーは、プリロードと複数動画の切り替えが必要なシナリオに最適です：

// ID スコープストラテジーのシングルトンインスタンスを取得します
IdScopedPoolLifecycleStrategy strategy = IdScopedPoolLifecycleStrategy.getInstance();

// プール容量をセットします
strategy.setMaxPoolSize(3);

// プレーヤーインスタンスをプリロードします (任意)
strategy.preload(context, 2);

// コントローラー作成時にストラテジーをインジェクトします
AliPlayerController controller = new AliPlayerController(context, strategy);

// 終了時にリソースをクリーンアップします
strategy.clear(); 

シングルトンストラテジーの使用

このストラテジーは、メモリセンシティブなシナリオに最適です：

// シングルトンストラテジーインスタンスを取得します
SingletonLifecycleStrategy strategy = SingletonLifecycleStrategy.getInstance();

// インスタンスをプリロードします (任意。インスタンスは 1 つのみ作成されます)
strategy.preload(context, 1);

// コントローラー作成時にストラテジーをインジェクトします
AliPlayerController controller = new AliPlayerController(context, strategy);

ライフサイクル イベントの監視

デバッグとモニタリングのために、イベントバスを介してストラテジー内部のライフサイクル イベントを監視します。

PlayerEventBus eventBus = PlayerEventBus.getInstance();

// プレーヤー作成を監視
eventBus.subscribe(PlayerLifecycleEvents.PlayerCreated.class, event -> {
    Log.d("Player", "Created: " + event.playerId);
});

// プレーヤー再利用を監視
eventBus.subscribe(PlayerLifecycleEvents.PlayerReused.class, event -> {
    Log.d("Player", "Reused: " + event.playerId);
});

// プレーヤーのエビクションを監視
eventBus.subscribe(PlayerLifecycleEvents.PlayerEvicted.class, event -> {
    Log.d("Player", "Evicted: " + event.playerId);
});

// プレーヤーの破棄を監視
eventBus.subscribe(PlayerLifecycleEvents.PlayerDestroyed.class, event -> {
    Log.d("Player", "Destroyed: " + event.playerId);
});

// 不要になったらアンサブスクライブ
eventBus.unsubscribe(PlayerLifecycleEvents.PlayerCreated.class, listener);

ストラテジーの動的な切り替え

ビジネス要件に応じて、ランタイムにストラテジーを切り替えることができます。

private IPlayerLifecycleStrategy mCurrentStrategy;

private void switchToReusePool() {
    // 1. 古いリソースをクリーンアップ
    if (mCurrentStrategy != null) {
        mCurrentStrategy.clear();
    }

    // 2. 再利用プールストラテジーに切り替え
    mCurrentStrategy = ReusePoolLifecycleStrategy.getInstance();
    mCurrentStrategy.setMaxPoolSize(3);

    // 3. プリロード
    mCurrentStrategy.preload(this, 2);
}

private void switchToSingleton() {
    // 1. 古いリソースをクリーンアップ
    if (mCurrentStrategy != null) {
        mCurrentStrategy.clear();
    }

    // 2. シングルトンストラテジーに切り替え
    mCurrentStrategy = SingletonLifecycleStrategy.getInstance();
}

プレーヤーインスタンスのプリロード

プリロードは、最初のフレームが表示されるまでの時間を短縮するために、プレーヤーインスタンスを事前に作成します。

// 再利用プールストラテジー: プリロードされたインスタンスはアイドルプールに配置されます
ReusePoolLifecycleStrategy strategy = ReusePoolLifecycleStrategy.getInstance();
strategy.preload(context, 2);  // インスタンスを2つ事前作成// IDスコープストラテジー: バインドされていないインスタンスをプリロード
IdScopedPoolLifecycleStrategy strategy = IdScopedPoolLifecycleStrategy.getInstance();
strategy.preload(context, 2);  // バインドされていないインスタンスを2つ事前作成// シングルトンストラテジー: グローバルインスタンスをプリロード
SingletonLifecycleStrategy strategy = SingletonLifecycleStrategy.getInstance();
strategy.preload(context, 1);  // グローバルインスタンスを作成 (countパラメーターは無視)

カスタムストラテジーの実装

BaseLifecycleStrategy を継承してカスタムストラテジーを実装します。

public class MyCustomStrategy extends BaseLifecycleStrategy {

    private final Map<String, IMediaPlayer> playerMap = new HashMap<>();

    @NonNull@Overridepublic IMediaPlayer acquire(@NonNull Context context, @NonNull String uniqueId) {
        // カスタムの取得ロジック
        IMediaPlayer player = playerMap.get(uniqueId);
        if (player != null) {
            // 既存のインスタンスにヒット
            PlayerEventBus.getInstance().post(
                new PlayerLifecycleEvents.PlayerHit(player.getPlayerId()));
            return player;
        }

        // 新しいインスタンスを作成
        player = createPlayer(context);
        playerMap.put(uniqueId, player);
        return player;
    }

    @Overridepublic void recycle(@Nullable IMediaPlayer player, @NonNull String uniqueId, boolean force) {
        if (player == null) return;

        if (force) {
            // 強制的に破棄
            playerMap.remove(uniqueId);
            destroyPlayer(player);
        } else {
            // プレーヤーは停止するが、インスタンスは保持
            player.stop();
        }
    }

    @Overridepublic void clear() {
        // すべてのインスタンスをクリーンアップ
        for (IMediaPlayer player : playerMap.values()) {
            destroyPlayer(player);
        }
        playerMap.clear();
    }
}

ストラテジーの選択

メモリの最適化

各プレーヤーインスタンスは、約 35～40 MB のメモリを消費します (Alibaba Cloud のショートドラマ向けマルチインスタンスプレーヤープールのメモリプロファイリング結果に基づく)。デバイスのパフォーマンスに応じてプール容量を調整することを推奨します：

// デバイスのメモリに基づいて動的に調整します
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
boolean isLowMemory = am.isLowRamDevice();

if (isLowMemory) {
    // メモリの少ないデバイスでは Singleton ストラテジーを使用します
    strategy = SingletonLifecycleStrategy.getInstance();
} else {
    // 標準的なデバイスでは ReusePool ストラテジーを使用します
    strategy = ReusePoolLifecycleStrategy.getInstance();
    strategy.setMaxPoolSize(isHighEndDevice ? 3 : 2);
}

注意事項

サンプルの機能

サンプルの実行

デモアプリで [ライフサイクル戦略] のサンプルを選択すると、実際の動作を確認できます。

コアインターフェイス

IPlayerLifecycleStrategy のメソッド

BaseLifecycleStrategy のメソッド

スレッドセーフ

プーリングストラテジーの比較

基盤となるアーキテクチャロジック：

• 再利用プールストラテジーが LIFO (Last-In, First-Out) を使用する理由

  フィード内で頻繁に上下にスクロールするシナリオでは、アイドルプールに追加されたばかりのプレーヤーインスタンスは、基盤となるデコーダーコンテキストとハードウェアリソースの観点から最も「ホット」な状態です (そのキャッシュはまだシステムによってページアウトされていません。)。これを最初に再利用することで、低レベルのコンテキストリセットに必要な時間が大幅に短縮され、空間的局所性の原理に基づいて起動速度が向上します。

• ID スコープストラテジーが LRU (Least Recently Used) を使用する理由

  マルチインスタンスプーリングは時間的局所性の原理に従います。ユーザーがフィードをスクロールするにつれて、はるか昔の動画を再生する確率は低下します。LRU エビクションポリシーは、ユーザーの閲覧履歴におけるこの減衰パターンに沿っており、ID への厳密なバインディングを維持しながら、アプリケーションのピークメモリフットプリントを効果的に制御できます。

適切なストラテジーの選択

ビジネスシナリオに基づいて選択してください。

• シンプルな再生：複雑さを追加しないため、デフォルトストラテジーを使用します。

• ショートビデオ、情報フィード：高速な切り替えのため、再利用プールストラテジーを使用します。

• ビデオのプレローディング：ID バインディングのため、IDスコープストラテジーを使用します。

• メモリに制約のあるシナリオ：最小限のフットプリントのため、シングルトンストラテジーを使用します。

プール容量の設定

デバイスのパフォーマンスとビジネスニーズに基づいて容量を調整してください。

• 各プレーヤーインスタンスは、約 35～40 MB のメモリを消費します。

• デフォルトのプール容量は 3 で、約 100～120 MB を消費します。

• ローエンドデバイスの場合は、容量を 2 に設定するか、シングルトンストラテジーを使用してください。

プレローディングの使用

最初のフレームまでの時間を短縮する必要があるシナリオでプレローディングを使用してください。

• ショートビデオリスト：1～2 個のインスタンスをプレロードしてください。

• ビデオ詳細ページ：次の推奨ビデオをプレロードしてください。

• 過度なプレローディングは避けてください。メモリ使用量が増加します。

よくある落とし穴

以下の状況は、ユーザーから報告される問題の最も一般的な原因です。必ず回避してください。

@Overrideprotected void onDestroy() {
    super.onDestroy();
    // View のみをデタッチし、ストラテジーが保持するインスタンスのクリーンアップを忘れた
    mPlayerView.detach();
}

@Overrideprotected void onDestroy() {
    super.onDestroy();
    // View をデタッチ
    mPlayerView.detach();
    // ストラテジー リソースをクリーンアップ
    if (mStrategy != null) {
        mStrategy.clear();
    }
}

@Overrideprotected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    // イベントをサブスクライブしたが、アンサブスクライブしなかった
    PlayerEventBus.getInstance().subscribe(
        PlayerLifecycleEvents.PlayerCreated.class,
        event -> updateUI()
    );
}

private PlayerEventBus.EventListener<PlayerLifecycleEvents.PlayerCreated> mListener;

@Overrideprotected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mListener = event -> updateUI();
    PlayerEventBus.getInstance().subscribe(
        PlayerLifecycleEvents.PlayerCreated.class, mListener);
}

@Overrideprotected void onDestroy() {
    super.onDestroy();
    // アンサブスクライブ
    if (mListener != null) {
        PlayerEventBus.getInstance().unsubscribe(
            PlayerLifecycleEvents.PlayerCreated.class, mListener);
    }
}

// プレーヤーをリサイクル
strategy.recycle(player, "video_1", false);

// リサイクル後もプレーヤーを使用し続ける
player.start();  // 例外が発生する可能性があります

// プレーヤーをリサイクル
strategy.recycle(player, "video_1", false);
player = null;  // 誤用を防ぐために参照をクリアします。必要に応じて再取得します。
player = strategy.acquire(context, "video_1");

デバッグ

1. ログを確認する：tag:AliPlayerKit を使用して Logcat をフィルタリングします。

2. ライフサイクルイベントをリッスンする：イベントバスで作成、再利用、エビクションイベントを監視します。

3. プールステータスを確認する：ログを通じて現在のプールサイズとアクティブなインスタンス数を確認します。

4. メモリを分析する：Android Profiler を使用して、プレーヤーインスタンスの数とメモリフットプリントを確認します。