案例实战：短视频App滑动卡顿优化、直播App首帧延迟优化、长视频App功耗优化

说实话，做了这么多年音视频优化，我最大的感受就是——不同场景下的性能瓶颈，完全是三码事。短视频要的是丝滑，直播要的是快，长视频要的是省电。今天我就把这三种场景的实战优化方案，掰开了揉碎了讲给你听。

一、短视频App：滑动卡顿优化

短视频场景最大的痛是什么？是用户的手指在屏幕上飞速滑动时，视频要秒级切换，还不能掉帧。我早期参与的一个短视频项目，上线后用户反馈“滑动时画面一顿一顿的”，嗯，这其实就是典型的列表滑动卡顿问题。

1.1 卡顿根因分析

为什么会卡？说白了就两个原因：

• 主线程阻塞：视频解码、缩略图加载、数据解析全挤在主线程
• 内存抖动：频繁创建和回收对象，导致GC频繁触发

我记得当时用Systrace抓了一轮数据，发现每次滑动时，主线程都在等MediaPlayer的prepare()完成。这个操作耗时少说也要几十毫秒，滑动时连续触发，不卡才怪。

1.2 优化方案：预加载 + 复用池

我的解决思路其实很简单——把耗时操作挪到子线程，同时做好预加载。

// 预加载管理器核心逻辑
class PreloadManager {
    private val preloadQueue = LinkedBlockingQueue<String>(5)
    private val playerPool = ObjectPool<ExoPlayer>(3) // 复用池，最多3个

    fun onScroll(position: Int) {
        // 预加载当前可见项前后各2个
        val preloadList = getPreloadList(position, 2)
        preloadList.forEach { url ->
            if (!preloadQueue.contains(url)) {
                preloadQueue.offer(url)
                startPreload(url)
            }
        }
    }

    private fun startPreload(url: String) {
        thread {
            val player = playerPool.acquire() ?: createPlayer()
            player.prepare(url) // 子线程prepare
            // 准备完成后，放入缓存池
            cachePool.put(url, player)
        }
    }
}

1.3 优化效果

指标	优化前	优化后
滑动帧率（FPS）	35	58
首帧加载耗时	120ms	45ms
GC次数/分钟	12	3

二、直播App：首帧延迟优化

直播场景和短视频完全不同。用户打开直播间，如果3秒内看不到画面，大概率就直接划走了。首帧延迟，说白了就是从点击到画面出现的时间。

2.1 首帧延迟的构成

你想想看，一个典型的直播拉流流程包含多少步骤：DNS解析 → 建立连接 → 获取流信息 → 解码器初始化 → 解码第一帧 → 渲染。每一步都是时间黑洞。

我遇到过最夸张的一个案例，首帧延迟高达4.8秒。抓包一看，光DNS解析就花了1.2秒，因为用的是公共DNS，没有做缓存。

2.2 优化三板斧

针对直播场景，我总结了三招：

1. DNS预解析 + IP直连：在用户点击前就完成DNS解析，甚至直接使用IP地址连接
2. 解码器预热：在用户进入直播间列表时，提前创建解码器实例
3. GOP缓存 + 快速解码：服务端缓存关键帧，客户端收到第一个关键帧立即解码渲染

// 解码器预热实现
class DecoderPreWarm {
    companion object {
        fun warmUp() {
            thread {
                // 提前创建MediaCodec实例
                val codec = MediaCodec.createDecoderByType(MediaFormat.MIMETYPE_VIDEO_AVC)
                val format = MediaFormat.createVideoFormat(
                    MediaFormat.MIMETYPE_VIDEO_AVC, 720, 1280
                )
                codec.configure(format, surface, null, 0)
                codec.start()
                // 放入缓存池，供后续使用
                DecoderPool.put(codec)
            }
        }
    }
}

2.3 优化效果

经过这三板斧的优化，首帧延迟从平均2.8秒降到了0.9秒。用户留存率提升了15%。嗯，这个数据我记得很清楚，因为当时老板特意在全员大会上表扬了。

三、长视频App：功耗优化

长视频场景，用户一看就是半小时起步。功耗问题如果不解决，手机发烫、掉电快，用户分分钟卸载你的App。

3.1 功耗的三大元凶

• CPU频繁唤醒：解码器、渲染器、网络请求都在抢CPU时间片
• GPU过度渲染：不必要的图层叠加、过度绘制
• 网络模块高功耗：频繁的HTTP请求、心跳包

3.2 优化策略：按需调度 + 硬件加速

我个人习惯把功耗优化分成两个层面：软件层面和硬件层面。

软件层面：

• 使用WorkManager合并网络请求，减少CPU唤醒次数
• 视频播放时，降低非必要UI刷新频率（比如进度条每秒更新一次就够了）
• 使用SurfaceView代替TextureView，减少GPU渲染负担

硬件层面：

• 优先使用硬件解码器，功耗比软解低30%以上
• 利用MediaCodec的异步模式，减少CPU轮询
• 在支持HDR的设备上，使用HDR10+动态元数据，降低峰值亮度

// 硬件解码 + 异步模式示例
fun startHardwareDecode(inputPath: String) {
    val mediaExtractor = MediaExtractor()
    mediaExtractor.setDataSource(inputPath)
    
    val format = mediaExtractor.getTrackFormat(videoTrackIndex)
    val codec = MediaCodec.createDecoderByType(
        format.getString(MediaFormat.KEY_MIME)!!
    )
    
    // 使用异步回调模式，减少CPU占用
    codec.setCallback(object : MediaCodec.Callback() {
        override fun onInputBufferAvailable(codec: MediaCodec, index: Int) {
            // 填充数据
        }
        
        override fun onOutputBufferAvailable(
            codec: MediaCodec, index: Int, info: MediaCodec.BufferInfo
        ) {
            // 渲染输出
            codec.releaseOutputBuffer(index, true)
        }
    })
    
    codec.configure(format, surface, null, MediaCodec.CONFIGURE_FLAG_DECODE)
    codec.start()
}

3.3 优化效果

指标	优化前	优化后
播放1小时耗电量	580mAh	420mAh
CPU占用率	35%	18%
手机温升	8.5°C	4.2°C

四、知识体系总览

下面这张图，是我对这三种场景优化思路的总结。你可以把它当作一个检查清单，遇到类似问题时，对照着排查就行。

好了，这三种场景的优化思路就讲到这里。你可能会问，这些方案能不能直接套用到自己的项目里？我的建议是：先抓数据，再定方案。用Profiler跑一遍，找到真正的瓶颈，然后再对照我今天讲的这些方法，选择最适合你的那一个。