简介这是一份面向Android开发者的「仿抖音上下滑动切换视频」完整工程源码适合已掌握RecyclerView基础、希望进阶学习短视频交互实现的中级开发者。资源围绕RecyclerView、SnapHelper与自定义LayoutManager三大核心组件展开解决视频列表整页吸附、滑动切换与播放联动的实际问题可直接用于短视频类App的交互原型搭建。压缩包共1486个文件约58.73MB包含569个flat资源文件、200个dex与198个class编译产物、118个json配置、61个xml布局、58个jar依赖及25个java源码另有png图片、so库与gradle构建脚本工程结构完整、依赖齐全。目前已有4843人学习下载。读者可从中获取自定义LayoutManager的布局计算思路、PagerSnapHelper的吸附回调处理、ExoPlayer播放器集成方式以及Glide异步加载、ItemAnimator过渡动画与DiffUtil性能优化等实践要点便于对照源码理解抖音式滑动切换的完整实现链路。1. 仿抖音上下滑动切换视频从手势冲突到丝滑跟手的完整落地路径做过短视频类 App 的兄弟都懂上下滑动切换视频这个交互看着简单真上手写起来全是玄学。手指一滑视频要么卡在半路不回弹要么跟手延迟半秒要么快速连滑直接白屏。更头疼的是列表滚动、手势识别、视频预加载、播放器复用这四件事搅在一起任何一个环节没处理好用户立刻能感知到“这 App 不跟手”。仿抖音上下滑动切换视频核心要解决的就是三件事手势怎么识别才不打架、视频怎么预加载才不卡顿、播放器怎么复用才不崩。这套方案适合正在做短视频、直播切片、课程回放类应用的移动端开发Android 和 iOS 都适用Flutter 和 React Native 也能照搬思路。接下来我按实际项目踩过的坑把每一步拆开讲清楚。2. 手势识别与滚动容器选型为什么你的滑动总是不跟手2.1 上下滑动切换视频的手势本质是什么很多人第一反应是用 ScrollView 或 RecyclerView 来做觉得滚动容器天然支持上下滑。但短视频切换和普通列表滚动有本质区别普通列表滚动是连续位移手指离开后靠惯性滑一段短视频切换是离散翻页一次手势只能切一个视频松手后要么回弹要么翻页不能停在中间。这就决定了你不能直接用普通滚动容器得用带分页吸附能力的组件。Android 上常见做法是用 ViewPager2 的竖向模式它内部基于 RecyclerView 实现但重写了 fling 和 snap 逻辑支持一次只翻一页。iOS 上对应的是 UIScrollView 开启 isPagingEnabled或者用 UICollectionView 的竖向分页布局。Flutter 里用 PageView 的 scrollDirection 设为 Axis.verticalReact Native 用 FlatList 配合 pagingEnabled。这些组件底层都做了同一件事把连续滚动手势映射成离散的页面索引变化。但这里有个隐藏问题视频播放器本身可能消费触摸事件。比如你用的播放器 SDK 带手势调节音量或亮度它会在 onTouchEvent 里拦截事件导致外层容器收不到滑动。血泪经验是播放器视图必须设置成不拦截触摸或者把手势处理统一收到最外层容器来做。2.2 用 ViewPager2 搭一个最小可跑的竖向分页框架先看 Android 侧的最小实现。下面这段代码用 ViewPager2 加 RecyclerView.Adapter 搭出竖向分页骨架每个页面是一个 VideoView 容器。// 布局文件 activity_main.xml // androidx.viewpager2.widget.ViewPager2 // android:idid/vp_video // android:layout_widthmatch_parent // android:layout_heightmatch_parent // android:orientationvertical / class VideoPagerActivity : AppCompatActivity() { private lateinit var viewPager: ViewPager2 private val videoUrls listOf( https://example.com/video1.mp4, https://example.com/video2.mp4, https://example.com/video3.mp4 ) override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) viewPager findViewById(R.id.vp_video) // 关键参数一设置竖向滑动 viewPager.orientation ViewPager2.ORIENTATION_VERTICAL // 关键参数二关闭过度滚动效果避免边缘拖拽回弹 viewPager.overScrollMode ViewPager2.OVER_SCROLL_NEVER // 关键参数三设置离屏缓存数量保证前后各一个页面已创建 viewPager.offscreenPageLimit 1 viewPager.adapter VideoPagerAdapter(videoUrls) } } class VideoPagerAdapter(private val urls: ListString) : RecyclerView.AdapterVideoPagerAdapter.VideoHolder() { class VideoHolder(itemView: View) : RecyclerView.ViewHolder(itemView) { val playerView: PlayerView itemView.findViewById(R.id.player_view) } override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): VideoHolder { val view LayoutInflater.from(parent.context) .inflate(R.layout.item_video_page, parent, false) return VideoHolder(view) } override fun onBindViewHolder(holder: VideoHolder, position: Int) { // 绑定视频地址实际播放逻辑在页面切换回调里处理 holder.playerView.tag urls[position] } override fun getItemCount() urls.size }这段代码里三个参数最关键。orientation 设为 VERTICAL 决定了滑动方向。overScrollMode 设为 NEVER 是防止用户滑到第一个或最后一个时出现边缘拖拽效果那个效果在短视频场景里很出戏。offscreenPageLimit 设为 1 表示当前页面左右各缓存一个页面这样滑动时下一个视频的视图已经创建好了不会出现白屏。但注意offscreenPageLimit 设太大内存扛不住设 0 又会导致滑动时才开始创建视图必然卡顿。2.3 页面切换监听与播放器状态同步光有滑动框架不够视频得跟着页面切换开始和暂停。ViewPager2 提供 registerOnPageChangeCallback我们在这里做播放器的生命周期管理。viewPager.registerOnPageChangeCallback(object : ViewPager2.OnPageChangeCallback() { override fun onPageSelected(position: Int) { super.onPageSelected(position) // 当前页面选中开始播放 playVideoAt(position) // 暂停其他页面的播放器 pauseOtherPages(position) } override fun onPageScrollStateChanged(state: Int) { super.onPageScrollStateChanged(state) when (state) { ViewPager2.SCROLL_STATE_DRAGGING - { // 用户正在拖拽可以在这里做预加载 } ViewPager2.SCROLL_STATE_SETTLING - { // 松手后正在吸附到目标页 } ViewPager2.SCROLL_STATE_IDLE - { // 滑动结束确保当前页播放 } } } })onPageSelected 在页面切换完成时触发这时候才去切换播放器。但这里有个坑如果用户在快速连滑onPageSelected 会连续触发多次每次都要暂停上一个、播放下一个播放器初始化来不及就会出现黑屏或声音重叠。解决办法是在 onPageScrollStateChanged 里判断状态只有 SCROLL_STATE_IDLE 时才真正执行播放切换DRAGGING 和 SETTLING 阶段只做预加载准备。3. 视频预加载与播放器复用把白屏和卡顿按在地上摩擦3.1 预加载策略什么时候加载下一个视频预加载的核心问题是时机和数量。加载太早浪费带宽加载太晚用户看到白屏。我一般用三级策略当前页播放时预加载下一个视频的元数据和首帧用户开始拖拽时预加载下一个视频的前 3 秒数据用户松手吸附到目标页时立即开始播放已缓冲的内容。Android 上用 ExoPlayer 的话可以给每个页面创建一个独立的 ExoPlayer 实例但实例太多内存吃不消。更好的做法是用一个播放器池池里维护 3 个实例当前播放的、下一个预加载的、上一个缓存的。页面切换时从池里取实例绑定到对应的 PlayerView 上。class PlayerPool(private val context: Context, poolSize: Int 3) { private val pool mutableListOfExoPlayer() private val maxSize poolSize init { repeat(maxSize) { val player ExoPlayer.Builder(context).build() // 关键参数设置缓冲策略 player.setBufferDurationsMs( 2000, // 最小缓冲时长低于这个值会触发缓冲 10000, // 最大缓冲时长超过这个值停止缓冲 1000, // 播放前缓冲时长 2000 // 缓冲后重新播放的时长 ) pool.add(player) } } fun acquire(): ExoPlayer? { return pool.firstOrNull { it.playbackState Player.STATE_IDLE } ?: pool.firstOrNull() } fun release(player: ExoPlayer) { player.stop() player.clearMediaItems() } }setBufferDurationsMs 这四个参数直接决定卡顿频率。第一个参数是最小缓冲设太小会频繁触发缓冲设太大首帧出来慢。第二个是最大缓冲设大一点能扛住网络波动。后两个是播放前后的缓冲阈值一般保持默认或略调小。实际调优时我一般先把最小缓冲设 2000ms最大缓冲设 10000ms然后根据用户网络情况动态调整。3.2 播放器复用时的状态重置清单播放器复用最大的坑是状态残留。上一个视频的播放位置、音量、播放速度、字幕轨道如果不重置下一个视频就会带着这些状态开始播。我整理了一个必重置清单每次绑定新视频前逐项检查。重置项方法不重置的后果播放位置seekTo(0)新视频从上次位置开始播播放状态stop() 后 prepare()新视频自动播放或卡在暂停媒体源setMediaItem()播放旧视频内容播放速度setPlaybackSpeed(1.0f)新视频倍速播放音量setVolume(1.0f)新视频静音或音量异常字幕轨道trackSelectionParameters 重置新视频显示旧字幕这张表里的每一项我都踩过坑。最隐蔽的是播放速度有一次测试反馈说某个视频声音变调了查了半天才发现是上一个视频用户手动调了 1.5 倍速播放器复用后没重置。还有字幕轨道如果上一个视频加载了外挂字幕下一个视频没字幕也会显示空白字幕条。3.3 首帧渲染与黑屏问题的排查路径黑屏问题排查起来像破案得一层层剥。第一层看播放器是否准备好onPlaybackStateChanged 回调里 STATE_READY 才表示可以渲染。第二层看 Surface 是否绑定成功PlayerView 的 surface 没创建好就 setPlayer 会黑屏。第三层看视频编码格式是否支持有些 H.265 视频在部分设备上硬解不了得回退软解。player.addListener(object : Player.Listener { override fun onPlaybackStateChanged(state: Int) { when (state) { Player.STATE_BUFFERING - { // 显示加载圈 loadingView.visibility View.VISIBLE } Player.STATE_READY - { // 缓冲完成隐藏加载圈确保 Surface 已绑定 loadingView.visibility View.GONE if (player.surface ! null) { player.playWhenReady true } } Player.STATE_ENDED - { // 播放结束可以循环或切下一个 } } } override fun onPlayerError(error: PlaybackException) { // 解码失败时尝试软解回退 if (error.errorCode PlaybackException.ERROR_CODE_DECODING_FAILED) { // 切换到软解码器重新创建播放器 } } })这段监听里STATE_READY 时判断 surface 是否为空是关键。有些设备上 Surface 创建比播放器准备慢如果直接 playWhenReady 就会黑屏。另外 onPlayerError 里要区分错误类型解码失败才回退软解网络错误应该重试而不是换解码器。4. 避坑与排查那些让你加班到凌晨的诡异问题4.1 快速连滑导致播放器崩溃现象用户快速连续上滑五六次App 直接闪退日志显示 ExoPlayer 的 IllegalStateException。原因每次 onPageSelected 都去 acquire 播放器并绑定新视频但上一个播放器的 release 还没执行完新视频又绑定了同一个实例。播放器内部状态机被并发操作搞乱了。解决加一个切换锁用 Handler 或协程把播放切换串行化。每次切换前先取消上一个未完成的任务确保 release 完成后再 acquire。我一般用一个简单的标志位加 postDelayed 做防抖延迟 150ms 执行切换快速连滑时只执行最后一次。4.2 滑动到一半松手不回弹现象手指滑到两个视频中间松手页面停在那里不动既不回上一个也不去下一个。原因ViewPager2 的 snap 逻辑依赖 fling 速度如果松手时速度接近零它可能判断为不需要翻页但又不触发回弹动画。这在使用自定义手势拦截时尤其常见。解决检查是否在 onInterceptTouchEvent 里消费了事件但没传给 ViewPager2。另外确认 overScrollMode 没设成 ALWAYS那个模式会干扰 snap 判断。如果用的是自定义容器需要在 ACTION_UP 时手动计算位移比例超过 30% 就翻页否则回弹。4.3 视频声音重叠或突然静音现象切换视频后上一个视频的声音还在响或者新视频没声音。原因播放器池里多个实例同时处于播放状态或者音频焦点被其他 App 抢走没恢复。解决每次切换时遍历池里所有播放器除了当前绑定的那个其余全部 pause 并 setVolume(0)。同时监听 AudioManager 的 AUDIOFOCUS_LOSS 广播失去焦点时暂停播放恢复焦点时重新播放。这个坑在同时开了其他音视频 App 时必现。4.4 预加载把用户流量跑光现象用户反馈 App 偷跑流量一查发现预加载逻辑在 Wi-Fi 和移动网络下都无差别加载。原因预加载策略没区分网络类型也没给用户关闭选项。解决在设置里加一个“仅 Wi-Fi 预加载”开关默认开启。代码里用 ConnectivityManager 判断当前网络类型移动网络下只预加载首帧缩略图不加载视频数据。另外预加载数量也要限制最多预加载下一个不要预加载下下个。4.5 低端机上滑动掉帧严重现象旗舰机丝滑千元机滑动时掉帧到 20fps 以下。原因每个页面都创建了完整的播放器视图和 SurfaceGPU 渲染压力大。加上视频解码本身占 CPU滑动动画抢不到资源。解决低端机上降低预加载数量到 0滑动时暂停当前视频播放只保留画面等滑动结束再恢复播放。另外把播放器视图的硬件加速关掉试试有些设备上硬件加速反而导致 Surface 合成慢。还可以把滑动动画的时长从默认 300ms 调到 200ms减少动画期间的渲染压力。5. 进阶技巧用滑动速度预测和动态缓冲把体验再拉高一档前面讲的都是基础框架能让功能跑起来。但要做到抖音那种“跟手到像在滑实物”的感觉还得加两个进阶优化滑动速度预测和动态缓冲调整。滑动速度预测的思路是在 onPageScrollStateChanged 的 DRAGGING 阶段实时计算手指滑动速度如果速度超过阈值就提前把下一个视频的播放器准备好并 seek 到 0 位置这样松手后几乎零等待开始播放。速度计算用 VelocityTracker 就行Android 自带。private val velocityTracker VelocityTracker.obtain() override fun onTouchEvent(event: MotionEvent): Boolean { velocityTracker.addMovement(event) when (event.action) { MotionEvent.ACTION_UP - { velocityTracker.computeCurrentVelocity(1000) val velocityY velocityTracker.yVelocity // 速度超过 2000 像素/秒判定为快速滑动 if (abs(velocityY) 2000) { // 提前准备下一个视频的播放器 preloadNextVideoImmediately() } velocityTracker.clear() } } return super.onTouchEvent(event) }动态缓冲调整是根据当前网络状况实时修改 setBufferDurationsMs 的参数。网络好时把最小缓冲降到 1000ms首帧更快网络差时把最大缓冲升到 20000ms减少卡顿。网络状况可以用播放器的 bufferedPosition 和网络请求的 RTT 来估算。验证这套优化是否生效我一般看三个指标首帧时间从页面选中到视频第一帧渲染、滑动跟手延迟手指位移到页面位移的时间差、卡顿率播放中触发缓冲的次数/总播放次数。首帧时间控制在 200ms 以内跟手延迟控制在 50ms 以内卡顿率低于 2%基本就达到抖音那种体验了。最后说个我自己的习惯每次改完滑动相关的代码一定在低端真机上用开发者选项里的“GPU 渲染模式分析”看一遍掉帧情况模拟器永远测不出真实手感。这个方案值不值得做如果你做的是短视频、课程、直播切片类产品上下滑动切换就是核心交互花两周把这块打磨到丝滑用户留存能差出好几个点。希望帮到你。本文还有配套的精品资源点击获取