Short Answer #

Absolutely run these resource-heavy operations on a background thread. Your main thread is reserved for UI rendering and user interactions, and any work that takes longer than ~16ms (the budget for a smooth 60fps frame) will cause visible jank — which is exactly what you're seeing with the 90ms player creation and 20ms prepare() calls.

Why Your Current Approach Causes Jank #

Android's main thread has a strict frame budget: to maintain 60fps, each frame needs to render in roughly 16ms. When you run code like your player initialization or media preparation on the main thread:

• The 90ms player setup blocks the main thread for nearly 6 full frames, which will definitely make animations or scrolls stutter.
• Even the 20ms prepare() call exceeds the 16ms threshold, so it's enough to cause a noticeable drop in frame rate.

How to Fix It #

Offload the heavy initialization and media preparation work to a background thread, then switch back to the main thread to attach the player to your UI and start playback. Here are practical implementations for both Java and Kotlin:

Java Example (Using ExecutorService) #

// Create a dedicated background executor
ExecutorService backgroundExecutor = Executors.newSingleThreadExecutor();
Handler mainHandler = new Handler(Looper.getMainLooper());

backgroundExecutor.execute(() -> {
    // All heavy work happens here in the background
    BandwidthMeter bandwidthMeter = new DefaultBandwidthMeter();
    TrackSelection.Factory videoTrackSelectionFactory = new AdaptiveTrackSelection.Factory(bandwidthMeter);
    TrackSelector trackSelector = new DefaultTrackSelector(videoTrackSelectionFactory);
    
    // Create player in background
    SimpleExoPlayer player = ExoPlayerFactory.newSimpleInstance(context, trackSelector);
    
    // Prepare media source in background
    DataSource.Factory dataSourceFactory = new DefaultDataSourceFactory(
            context, 
            Util.getUserAgent(context, "yourApplicationName"), 
            bandwidthMeter);
    MediaSource videoSource = new ExtractorMediaSource.Factory(dataSourceFactory)
            .createMediaSource(mp4VideoUri);
    player.prepare(videoSource);
    
    // Switch back to main thread for UI-related player setup
    mainHandler.post(() -> {
        // Attach player to your SurfaceView/TextureView
        player.setVideoSurfaceView(surfaceView);
        player.setPlayWhenReady(true);
        
        // Store player reference for later control (don't forget to release it!)
        yourPlayerReference = player;
    });
});

// Clean up resources when your component is destroyed
@Override
protected void onDestroy() {
    super.onDestroy();
    backgroundExecutor.shutdown();
    if (yourPlayerReference != null) {
        yourPlayerReference.release();
    }
}

Kotlin Example (Using Coroutines) #

Coroutines are a cleaner, more modern approach for Android background work:

lifecycleScope.launch(Dispatchers.IO) {
    // Background thread work
    val bandwidthMeter = DefaultBandwidthMeter()
    val videoTrackSelectionFactory = AdaptiveTrackSelection.Factory(bandwidthMeter)
    val trackSelector = DefaultTrackSelector(videoTrackSelectionFactory)
    
    val player = ExoPlayerFactory.newSimpleInstance(context, trackSelector)
    
    val dataSourceFactory = DefaultDataSourceFactory(
        context,
        Util.getUserAgent(context, "yourApplicationName"),
        bandwidthMeter
    )
    val videoSource = ExtractorMediaSource.Factory(dataSourceFactory)
        .createMediaSource(mp4VideoUri)
    player.prepare(videoSource)
    
    // Switch to main thread for UI operations
    withContext(Dispatchers.Main) {
        player.setVideoSurfaceView(surfaceView)
        player.playWhenReady = true
        yourPlayerReference = player
    }
}

// Release player when the component is destroyed
override fun onDestroy() {
    super.onDestroy()
    yourPlayerReference?.release()
}

Critical Notes #

• Player control operations stay on the main thread: Most of ExoPlayer's public API methods (like setPlayWhenReady, seekTo) require being called from the main thread, so keep those actions on the main thread.
• Lifecycle safety is key: Always release the player when your activity/fragment is destroyed, and cancel any background work if the component is no longer active to avoid memory leaks.
• Avoid main thread bloat: Even small, cumulative operations can cause jank — get into the habit of offloading all non-UI work to background threads.

内容的提问来源于stack exchange，提问作者zeus