简介这是一份面向Android开发者的「仿抖音上下滑动切换视频」完整工程源码适合具备一定Android基础、希望掌握短视频列表交互与播放器集成的中高级开发者。资源围绕RecyclerView、SnapHelper与自定义LayoutManager三大核心组件展开解决视频列表逐页吸附、滑动切换与流畅播放等典型问题可直接作为短视频类App的参考实现。压缩包共1486个文件约58.73MB包含569个flat、200个dex、198个class等编译产物以及25个java源码、61个xml布局、58个jar依赖、26个png图片和20个so库另有gradle构建脚本与apk安装包工程结构完整、依赖齐全。目前已有4843人学习下载。读者可从中获取视频异步加载、ExoPlayer播放器集成、手势识别、ItemAnimator过渡动画及DiffUtil性能优化等关键实现思路便于对照源码理解抖音式滑动切换的完整链路并在此基础上按需调整与二次开发。1. 仿抖音上下滑动切换视频从手势到播放器的完整链路刷抖音时上下滑动的跟手感背后是一套「手势识别 → 滚动容器 → 播放器生命周期」的联动机制。很多团队第一次做仿抖音上下滑动切换视频卡点不在动画而在「滑到哪一页该播哪个视频、上一个怎么停、预加载几个才不卡」。这个标题要解决的就是这套链路用最短代码跑通一个全屏竖向翻页容器让每个视频在进入视口时自动播放、离开时暂停释放滑动过程不掉帧。适合正在做短视频、课程播放、商品视频流的前端和移动端工程师也适合想理解 TikTok 式交互底层逻辑的开发者。下面按「先跑通最小闭环再抠参数和坑」的顺序展开所有代码可直接抄。2. 竖向翻页容器选型CSS Scroll Snap 还是 JS 手势库2.1 三种主流方案的取舍做仿抖音上下滑动切换视频第一步是决定「谁负责翻页」。常见做法有三类原生overflow: scroll CSS Scroll Snap、transform手动位移、以及第三方手势库如 Swiper、better-scroll。选型直接决定后面播放器联动的复杂度。CSS Scroll Snap 是浏览器原生能力滚动由合成线程处理惯性、回弹、跟手感几乎零成本缺点是「当前页索引」要靠scroll事件或IntersectionObserver反推且部分老版本 WebView 对scroll-snap-stop支持不全。transform手动位移可控性最强能精确控制每一帧位置但惯性曲线、边界回弹、快速连滑都要自己写翻车概率最高。手势库省事但引入体积、和播放器生命周期耦合时容易打架。我一般优先选 CSS Scroll Snap移动端性能最好代码量最少只有需要「一屏多页」或「斜向手势」时才考虑手势库。下面给一个最小可跑的 Scroll Snap 容器。!-- 容器固定满屏纵向滚动强制按页吸附 -- div classfeed idfeed section classpagevideo srca.mp4 muted playsinline loop/video/section section classpagevideo srcb.mp4 muted playsinline loop/video/section section classpagevideo srcc.mp4 muted playsinline loop/video/section /div style .feed { height: 100vh; overflow-y: scroll; scroll-snap-type: y mandatory; /* 纵向强制吸附 */ -webkit-overflow-scrolling: touch; /* iOS 惯性滚动 */ scrollbar-width: none; /* 隐藏滚动条 */ } .feed::-webkit-scrollbar { display: none; } .page { height: 100vh; scroll-snap-align: start; /* 每页顶部对齐吸附点 */ scroll-snap-stop: always; /* 防止一次滑动跨多页 */ position: relative; } .page video { width: 100%; height: 100%; object-fit: cover; /* 铺满且不变形 */ background: #000; } /style逻辑说明scroll-snap-type: y mandatory让容器在滚动停止时强制吸附到最近的页scroll-snap-align: start定义每页的吸附点是顶部scroll-snap-stop: always是关键参数它阻止用户一次快速滑动直接跳过中间页这是「跟手感」和「逐页切换」的分界线。object-fit: cover保证视频铺满全屏不变形配合background: #000避免加载时白屏。参数说明mandatory与proximity的区别在于——mandatory一定会吸附proximity只在靠近吸附点时吸附。仿抖音场景必须用mandatory否则滑到一半松手会停在两页之间。scroll-snap-stop在部分安卓 WebView 上无效需要 JS 兜底后面避坑章会讲。2.2 用 IntersectionObserver 反推当前页容器跑起来后必须知道「现在停在第几页」才能驱动播放。监听scroll事件算scrollTop / pageHeight也能做但高频触发、需要节流且快速滑动时索引会跳变。更稳的做法是IntersectionObserver当某一页和视口的交叉比例超过阈值就认定它是当前页。const feed document.getElementById(feed); const pages [...feed.querySelectorAll(.page)]; let currentIndex -1; const observer new IntersectionObserver((entries) { entries.forEach((entry) { // 交叉比例超过 0.6 才认为这一页是「当前页」 if (entry.intersectionRatio 0.6) { const index pages.indexOf(entry.target); if (index ! currentIndex) { currentIndex index; switchVideo(index); // 触发播放器切换 } } }); }, { root: feed, // 以滚动容器为参照不是视口 threshold: [0.6], // 触发阈值 }); pages.forEach((page) observer.observe(page));逻辑说明root必须显式设为滚动容器feed否则默认以浏览器视口为参照在嵌套滚动场景下会算错。threshold: [0.6]表示当某页有 60% 面积进入容器可视区时触发回调。阈值不能设太低比如 0.1否则滑动过程中相邻两页会反复触发切换视频刚播就被打断也不能设太高比如 0.95快速滑动时可能直接跳过、不触发。参数说明intersectionRatio是交叉面积占目标元素总面积的比例。全屏页场景下0.5 到 0.7 是实测比较稳的区间。如果页面高度不等于容器高度比如有顶部导航阈值要相应调整或者改用rootMargin修正参照区域。3. 播放器生命周期管理进入播放、离开暂停、预加载下一个3.1 播放/暂停/释放的三态控制翻页容器只解决「滑到哪」真正影响体验的是播放器状态。核心原则同一时刻只允许一个视频在播离开视口的视频必须pause()并考虑释放资源否则多个视频同时解码会直接拖垮中低端机。const videos pages.map((p) p.querySelector(video)); function switchVideo(index) { videos.forEach((video, i) { if (i index) { // 当前页从头播放静音自动播放兼容性最好 video.currentTime 0; video.muted false; // 用户已有交互后可取消静音 const p video.play(); if (p) p.catch(() { video.muted true; video.play(); }); } else { // 非当前页暂停并回到起点避免下次进入时残留进度 video.pause(); video.currentTime 0; } }); preload(index 1); // 预加载下一页 }逻辑说明video.play()返回 Promise在移动端浏览器里如果视频未静音且没有用户手势会抛NotAllowedError。所以先尝试带声音播放失败后降级为静音播放这是兼容自动播放策略的标准写法。非当前页currentTime 0是为了下次滑回来时从头播符合抖音的交互预期。参数说明muted和playsinline是移动端自动播放的两个硬性条件playsinline防止 iOS 全屏接管。preload属性建议设为metadata或none不要设auto否则首屏会同时拉多个视频浪费带宽。3.2 预加载策略预加载几个、什么时候加载预加载是「滑动不卡」的关键但加载太多会抢带宽、占内存。常见做法是只预加载当前页的下一页最多再加一个上一页。用link relpreload或直接创建隐藏video元素都行我一般用后者因为能复用同一个播放器实例。function preload(index) { const video videos[index]; if (!video) return; // 只预加载元数据不触发完整下载 if (video.preload ! auto) { video.preload auto; video.load(); // 主动触发加载 } }逻辑说明video.load()会重新触发资源加载流程配合preload auto让浏览器提前拉取。注意不要对当前页调用load()否则会打断正在播放的视频。预加载的边界要判断videos[index]是否存在最后一页没有下一页。参数说明预加载数量建议 1 个。实测在 4G 网络下预加载 2 个以上会导致当前视频起播变慢因为带宽被分走。如果视频体积大超过 10MB可以只预加载metadata等真正滑到再拉全量。4. 避坑与排查仿抖音滑动切换最常见的 5 个翻车点4.1 现象iOS 上滑到一半松手停在两页之间原因scroll-snap-stop: always在部分 iOS 版本上不生效或者容器高度用了100vh而 iOS 地址栏收起/展开时vh会变化导致吸附点错位。解决容器高度改用100dvh动态视口高度并加 JS 兜底——监听scrollend事件不支持则用scroll 定时器松手后手动scrollTo到最近页。feed.addEventListener(scroll, () { clearTimeout(window.__snapTimer); window.__snapTimer setTimeout(() { const pageHeight feed.clientHeight; const target Math.round(feed.scrollTop / pageHeight) * pageHeight; if (Math.abs(feed.scrollTop - target) 2) { feed.scrollTo({ top: target, behavior: smooth }); } }, 120); });4.2 现象快速连滑时中间页的视频也响了一下原因IntersectionObserver阈值触发是异步的快速滑动时中间页可能瞬间达到 0.6 比例触发了一次播放随后又被下一页打断。解决在switchVideo里加一个「防抖窗口」比如 150ms 内只响应最后一次切换或者提高阈值到 0.75减少误触发。4.3 现象安卓低端机上滑动掉帧、视频卡顿原因多个video元素同时存在且都持有解码器GPU 和内存压力大。object-fit: cover在大分辨率视频上也会增加合成开销。解决只保留当前页和预加载页的video元素其余页用poster占位滑到附近再动态创建video。这是「虚拟列表」思路能显著降低内存。4.4 现象静音自动播放成功取消静音后没声音原因移动端浏览器要求「取消静音」必须发生在用户手势回调内IntersectionObserver回调不算用户手势。解决首次静音播放后在页面上放一个「点击开启声音」的浮层用户点击时再对所有视频取消静音。或者监听touchstart在用户第一次触摸屏幕时取消静音。4.5 现象视频切换后上一个视频的声音还在播原因pause()调用了但视频处于seeking状态暂停指令被忽略或者多个视频共用了同一个AudioContext。解决暂停后监听pause事件确认状态必要时调用video.currentTime 0强制中断。不要用AudioContext接管多个视频每个video独立管理音频。5. 进阶用虚拟列表 双缓冲把内存压到最低当视频流超过 20 条全量渲染video元素必然 OOM。我现在的习惯是「虚拟列表 双缓冲」只保留当前页、上一页、下一页三个video实例其余页用poster图片占位。滑到新页时把最远那个video的src换掉复用 DOM 节点。const BUFFER 1; // 前后各缓冲 1 页 const pool []; // 复用的 video 元素池 function render(index) { const start Math.max(0, index - BUFFER); const end Math.min(pages.length - 1, index BUFFER); // 回收超出范围的 video pool.forEach(({ el, pageIndex }) { if (pageIndex start || pageIndex end) { el.pause(); el.removeAttribute(src); el.load(); // 释放解码器 } }); // 为范围内页面分配 video for (let i start; i end; i) { const page pages[i]; if (!page.querySelector(video)) { const video document.createElement(video); video.muted true; video.playsInline true; video.loop true; video.src dataList[i].url; // 从数据源取地址 page.appendChild(video); pool.push({ el: video, pageIndex: i }); } } }逻辑说明el.removeAttribute(src)加el.load()是释放视频解码器的标准组合只pause()不释放内存不会降。pool记录每个video当前绑定的页索引超出缓冲范围就回收。这样无论视频流多长同时存在的video元素不超过 3 个。参数说明BUFFER 1是内存和流畅度的平衡点。如果设备性能好、网络快可以设 2低端机建议设 0只保留当前页滑到再加载代价是起播稍慢。验证方法在 Chrome DevTools 的 Memory 面板拍快照滑动 50 页后再拍一次对比HTMLVideoElement数量是否稳定在 3 个左右。如果持续增长说明回收逻辑没生效检查removeAttribute(src)是否被调用。最后说个血泪经验别在scroll事件里直接操作video滚动回调每秒触发几十次任何 DOM 操作都会放大成卡顿。所有播放器状态变更都走IntersectionObserver或防抖后的scrollend。这套方案我前后改了三版从全量渲染到虚拟列表内存从 800MB 降到 120MB中低端安卓机才真正跑顺。希望帮到你。本文还有配套的精品资源点击获取