How to Achieve Seamless Cross‑Page Video Playback on Android: Hema’s Optimization

Cross‑Page Continuation

Cross‑page continuation allows a short video to keep playing seamlessly when the user navigates from a list page to an immersive playback page, eliminating the perceptible pause and providing a continuous viewing experience.

Environment

Phone: Pixel 4

OS: Android 10

Player: Taobao Player

Effect Comparison

Before optimization, Hema’s immersive short‑video page showed a noticeable gap compared with mainstream short‑video apps: the same video could not continue playing after navigation, harming user experience. After applying the cross‑page continuation and smooth animation techniques, playback became fluid and uninterrupted.

Problem Analysis

The key challenges are:

Reusing the video stream to avoid re‑downloading and re‑decoding.

Implementing transition animations that keep the experience seamless.

Solution Options

Player View Transfer Across Pages – Simple concept and good effect, but highly invasive and not reusable.

Global Player Management at Surface Level – Good experience, low intrusion, supports memory control, but requires extensive refactoring of the underlying HMVideoView and may introduce memory leaks.

Global Player Management at MediaPlayer Level – Non‑intrusive, fast to implement, low cost, and provides stable reuse of the underlying player; this option was selected.

Chosen Implementation (Option 3)

The MediaPlayer is decoupled from the view and managed globally via a MediaPlayerManager. All player instances obtain their MediaPlayer from this manager, enabling reuse, recovery, and controlled destruction.

Key principles of the manager:

At most four global MediaPlayer instances are created.

If a fifth player is needed, the least‑used MediaPlayer is destroyed.

Each player receives a unique token (timestamp + random) that can be specified by developers.

Players sharing the same token reuse the same MediaPlayer.

A MediaPlayer can be bound to only one Surface at a time.

When a player with a shared token is destroyed, the MediaPlayer instance is retained.

If a MediaPlayer is taken over by a newer player, the previous player unbinds and rebinds when needed.

Transition Animation

Two animation approaches are evaluated:

Android System Element Animation – Smooth and system‑driven, but requires heavy navigation layer changes and can cause white‑screen/black‑screen flashes when the view is reused.

Custom Property Animation – Light‑weight, needs only minimal coordinate data from the source page, works well with view‑reuse scenarios, and offers broad compatibility, though it requires manual implementation and may introduce slight flicker.

Animation flow:

Pass the source page’s video view rectangle to the immersive page.

The immersive page starts transparent, creates (or reuses) the player at the given coordinates.

Animate the player view to its final size while fading in the background.

Lifecycle Pitfall & Fix

When the target activity (B) is translucent during the animation, the previous activity (A) does not receive onStop, breaking logic that depends on it. The fix is to convert activity B to opaque at the end of the entry animation (via reflection calling convertFromTranslucent) and revert to translucent at the start of the exit animation (via convertToTranslucent).

<style name="MyTransparent" parent="xxxx">
    <item name="android:windowFullscreen">false</item>
    <item name="android:windowNoTitle">true</item>
    <item name="android:windowBackground">@android:color/transparent</item>
    <item name="android:colorBackgroundCacheHint">@null</item>
    <item name="android:windowIsTranslucent">true</item>
    <item name="android:background">@android:color/transparent</item>
    <item name="android:windowAnimationStyle">@style/noAnimation</item>
</style>

Future Optimization Outlook

Beyond cross‑page continuation, further work includes:

Optimizing start‑up playback for general scenarios such as home‑page card videos.

Globally controlling player instance count to reduce memory usage.

Unoptimized scenario (opening 30‑50 pages rapidly) caused memory spikes and device heating. After optimization (opening one page per second up to 100 pages), memory grew steadily without spikes, and the app remained stable.