Player lifecycle strategy

What is a player lifecycle strategy?

A player lifecycle strategy is an architecture for managing the lifecycle of player instances. It defines core operations such as acquire, recycle, and clear, decoupling player resource management from business logic.

Different business scenarios have different requirements for managing player instances:

Advantages of the strategy pattern

The strategy pattern offers the following core advantages for managing the player lifecycle:

• Decoupling: Separates business logic from the details of player instance creation and destruction.

• Flexibility: Allows you to switch strategies at runtime without modifying business logic.

• Extensibility: You can implement custom strategies to meet specific business needs.

• Observability: Unified lifecycle events make monitoring and debugging easier.

Problems it solves

1. Decentralized management: No unified mechanism to control player instances.

2. Performance overhead: Frequent creation and destruction of player instances waste resources.

3. Reuse challenges: Player instances cannot be reused across different scenarios.

4. Uncontrolled memory: Lack of effective control over memory footprint.

Core value

Architectural advantages:

• Strategy decoupling: Player resource management is separated from business logic for clear responsibilities.

• Runtime switching: Switch strategies without restarting the application.

• Thread safety: All strategy implementations support safe access from multiple threads.

• Event-driven: Publishes lifecycle events through an event bus for easier monitoring.

Core capabilities

Strategy types

AliPlayerKit provides four built-in player lifecycle strategies:

Strategy details

DefaultLifecycleStrategy (default strategy)

This is the simplest strategy. Each call to acquire() creates a new instance, and each call to recycle() immediately destroys it.

Key points:

• Stateless, providing a fresh instance every time.

• No reuse, suitable for simple scenarios.

• Lowest memory footprint (resources are released immediately after use).

ReusePoolLifecycleStrategy (reuse pool strategy)

Based on the object pool pattern, this strategy maintains an idle pool and an active list. It uses a LIFO (Last-In, First-Out) policy to reuse instances.

Key points:

• LIFO policy for the idle pool, where the most recently used instance is reused first.

• Supports preloading to create instances in advance.

• Configurable pool capacity. Instances are destroyed if the capacity is exceeded.

• Ideal for short video list and information feed scenarios.

IdScopedPoolLifecycleStrategy (ID-scoped strategy)

Maintains a separate player instance for each uniqueId, always returning the same instance for a given ID. It uses an LRU (Least Recently Used) mechanism to control the number of instances.

Key points:

• ID-bound, always reusing the same instance for the same ID.

• LRU eviction mechanism automatically cleans up the least recently used instances.

• Supports preloading to create unbound instances in advance.

• Ideal for video preloading and multi-video switching scenarios.

SingletonLifecycleStrategy (singleton strategy)

Maintains a single global player instance. It always returns the same instance, regardless of the uniqueId.

Key points:

• Globally unique, with all callers sharing the same instance.

• Lowest memory footprint.

• Not suitable for playing multiple videos simultaneously.

Lifecycle events

The strategy publishes lifecycle events that you can listen for on the event bus:

Use the default strategy

This is the simplest way to use the player, with no extra configuration needed:

// Create a controller (automatically uses DefaultLifecycleStrategy)
AliPlayerController controller = new AliPlayerController(context);

// Bind the player
AliPlayerModel model = new AliPlayerModel.Builder()
        .videoSource(videoSource)
        .build();
controller.configure(model);
playerView.attach(controller);      

Use the reuse pool strategy

This strategy is ideal for short video list and information feed scenarios:

// Get the singleton instance of the reuse pool strategy
ReusePoolLifecycleStrategy strategy = ReusePoolLifecycleStrategy.getInstance();

// Set the pool capacity (optional, defaults to 3)
strategy.setMaxPoolSize(3);

// Inject the strategy when creating the controller
AliPlayerController controller = new AliPlayerController(context, strategy);

// Clean up resources when finished
strategy.clear(); 

Use the ID-scoped strategy

This strategy is ideal for scenarios that require preloading and switching between multiple videos:

// Get the singleton instance of the ID-scoped strategy
IdScopedPoolLifecycleStrategy strategy = IdScopedPoolLifecycleStrategy.getInstance();

// Set the pool capacity
strategy.setMaxPoolSize(3);

// Preload player instances (optional)
strategy.preload(context, 2);

// Inject the strategy when creating the controller
AliPlayerController controller = new AliPlayerController(context, strategy);

// Clean up resources when finished
strategy.clear(); 

Use the singleton strategy

This strategy is ideal for memory-sensitive scenarios:

// Get the singleton strategy instance
SingletonLifecycleStrategy strategy = SingletonLifecycleStrategy.getInstance();

// Preload the instance (optional, only creates one instance)
strategy.preload(context, 1);

// Inject the strategy when creating the controller
AliPlayerController controller = new AliPlayerController(context, strategy);

Listening for lifecycle events

Listen for the internal lifecycle events of a strategy through the event bus for debugging and monitoring:

PlayerEventBus eventBus = PlayerEventBus.getInstance();

// Listen for player creation
eventBus.subscribe(PlayerLifecycleEvents.PlayerCreated.class, event -> {
    Log.d("Player", "Created: " + event.playerId);
});

// Listen for player reuse
eventBus.subscribe(PlayerLifecycleEvents.PlayerReused.class, event -> {
    Log.d("Player", "Reused: " + event.playerId);
});

// Listen for player eviction
eventBus.subscribe(PlayerLifecycleEvents.PlayerEvicted.class, event -> {
    Log.d("Player", "Evicted: " + event.playerId);
});

// Listen for player destruction
eventBus.subscribe(PlayerLifecycleEvents.PlayerDestroyed.class, event -> {
    Log.d("Player", "Destroyed: " + event.playerId);
});

// Unsubscribe when no longer needed
eventBus.unsubscribe(PlayerLifecycleEvents.PlayerCreated.class, listener);

Switching strategies dynamically

You can switch strategies at runtime based on business needs:

private IPlayerLifecycleStrategy mCurrentStrategy;

private void switchToReusePool() {
    // 1. Clean up old resources
    if (mCurrentStrategy != null) {
        mCurrentStrategy.clear();
    }

    // 2. Switch to the reuse pool strategy
    mCurrentStrategy = ReusePoolLifecycleStrategy.getInstance();
    mCurrentStrategy.setMaxPoolSize(3);

    // 3. Preload
    mCurrentStrategy.preload(this, 2);
}

private void switchToSingleton() {
    // 1. Clean up old resources
    if (mCurrentStrategy != null) {
        mCurrentStrategy.clear();
    }

    // 2. Switch to the singleton strategy
    mCurrentStrategy = SingletonLifecycleStrategy.getInstance();
}

Preloading player instances

Preloading creates player instances in advance to reduce time-to-first-frame:

// Reuse pool strategy: Preloaded instances are placed in the idle pool
ReusePoolLifecycleStrategy strategy = ReusePoolLifecycleStrategy.getInstance();
strategy.preload(context, 2);  // Pre-create 2 instances// ID-scoped strategy: Preloads unbound instances
IdScopedPoolLifecycleStrategy strategy = IdScopedPoolLifecycleStrategy.getInstance();
strategy.preload(context, 2);  // Pre-create 2 unbound instances// Singleton strategy: Preloads the global instance
SingletonLifecycleStrategy strategy = SingletonLifecycleStrategy.getInstance();
strategy.preload(context, 1);  // Creates the global instance (the count parameter is ignored)

Implementing a custom strategy

Implement a custom strategy by extending BaseLifecycleStrategy:

public class MyCustomStrategy extends BaseLifecycleStrategy {

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

    @NonNull@Overridepublic IMediaPlayer acquire(@NonNull Context context, @NonNull String uniqueId) {
        // Custom acquisition logic
        IMediaPlayer player = playerMap.get(uniqueId);
        if (player != null) {
            // Hit an existing instance
            PlayerEventBus.getInstance().post(
                new PlayerLifecycleEvents.PlayerHit(player.getPlayerId()));
            return player;
        }

        // Create a new instance
        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) {
            // Force destruction
            playerMap.remove(uniqueId);
            destroyPlayer(player);
        } else {
            // Only stop the player, keep the instance
            player.stop();
        }
    }

    @Overridepublic void clear() {
        // Clean up all instances
        for (IMediaPlayer player : playerMap.values()) {
            destroyPlayer(player);
        }
        playerMap.clear();
    }
}

Strategy selection

Memory optimization

Each player instance consumes approximately 35–40 MB of memory (based on memory profiling results from Alibaba Cloud's multi-instance player pool for short dramas). We recommend adjusting the pool capacity based on device performance:

// Dynamically adjust based on device memory
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
boolean isLowMemory = am.isLowRamDevice();

if (isLowMemory) {
    // Use the singleton strategy on low-memory devices
    strategy = SingletonLifecycleStrategy.getInstance();
} else {
    // Use the reuse pool strategy on standard devices
    strategy = ReusePoolLifecycleStrategy.getInstance();
    strategy.setMaxPoolSize(isHighEndDevice ? 3 : 2);
}

Precautions

Example features

Run the example

In the demo app, select the Lifecycle Strategy example to see it in action.

Core interfaces

IPlayerLifecycleStrategy methods

BaseLifecycleStrategy methods

Thread safety

Pooling strategy comparison

Underlying architectural logic:

• Why does the reuse pool strategy use LIFO (Last-In, First-Out)?

  In scenarios with frequent up-and-down scrolling in a feed, the player instance that was just added to the idle pool is the "hottest" in terms of its underlying decoder context and hardware resources (its cache has not yet been paged out by the system). Reusing it first significantly reduces the time required for low-level context resets, improving startup speed based on the principle of spatial locality.

• Why does the ID-scoped strategy use LRU (Least Recently Used)?

  Multi-instance pooling follows the principle of temporal locality: as a user scrolls through a feed, the probability of replaying a much older video decreases. The LRU eviction policy aligns with this decay pattern in user browsing history, allowing for effective control over the application's peak memory footprint while maintaining a strict binding to IDs.

Choosing the right strategy

Choose based on your business scenario:

• Simple playback: Use the default strategy for zero added complexity.

• Short video/information feeds: Use the reuse pool strategy for fast switching.

• Video preloading: Use the ID-scoped strategy for ID binding.

• Memory-sensitive scenarios: Use the singleton strategy for the smallest footprint.

Setting pool capacity

Adjust the capacity based on device performance and business needs:

• Each player instance consumes approximately 35–40 MB of memory.

• The default pool capacity is 3, which consumes about 100–120 MB.

• For low-end devices, set the capacity to 2 or use the singleton strategy.

Using preloading

Use preloading in scenarios where you need to reduce the time-to-first-frame:

• Short video list: Preload 1 to 2 instances.

• Video detail page: Preload the next recommended video.

• Avoid excessive preloading, as it increases memory usage.

Common pitfalls

The following situations are the most common causes of issues reported by users. Make sure to avoid them:

@Overrideprotected void onDestroy() {
    super.onDestroy();
    // Only detached the View, forgot to clean up instances held by the strategy
    mPlayerView.detach();
}

@Overrideprotected void onDestroy() {
    super.onDestroy();
    // Detach the View
    mPlayerView.detach();
    // Clean up strategy resources
    if (mStrategy != null) {
        mStrategy.clear();
    }
}

@Overrideprotected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    // Subscribed to an event but never unsubscribed
    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();
    // Unsubscribe if (mListener != null) {
        PlayerEventBus.getInstance().unsubscribe(
            PlayerLifecycleEvents.PlayerCreated.class, mListener);
    }
}

// Recycle the player
strategy.recycle(player, "video_1", false);

// Continue to use the player after recycling
player.start();  // May cause an exception

// Recycle the player
strategy.recycle(player, "video_1", false);
player = null;  // Clear the reference to prevent misuse. Re-acquire it when needed.
player = strategy.acquire(context, "video_1");

Debugging

1. Check logs: Filter Logcat by using tag:AliPlayerKit.

2. Listen for lifecycle events: Observe creation, reuse, and eviction events on the event bus.

3. Check pool status: Check the current pool size and the number of active instances through logs.

4. Analyze memory: Use the Android Profiler to check the number of player instances and their memory footprint.