基于Android的短视频推荐系统源码解析：协同过滤算法落地实践

这两年Android方向的课程设计和毕业设计，短视频相关的题目是真不少。前段时间拿到一个《基于Android的短视频推荐系统》的完整工程，带全套源码和文档，从用户登录到视频播放再到个性化推荐都有，算是把“App开发”和“推荐算法落地”两件事串起来了。我花了几天时间把工程跑通、把代码过了一遍，又把推荐部分的算法单独拎出来测了几组数据，今天把整个分析和实操过程整理出来。无论你是要做课程设计、毕业设计，还是单纯想看看“推荐系统在Android端到底怎么玩”，这篇都应该能帮你省下不少踩坑的时间。

先说结论：这套系统不是那种只有一个登录页的“假项目”，它包含了视频信息流、播放器集成、点赞评论、基于协同过滤的推荐模块，以及一整套数据库和网络层封装。你拿到的源码可以直接编译成APK装到手机上，后端逻辑和推荐计算也都能在本地跑通。对于想快速交作业、或者想在此基础上做二次开发的人来说，是一个性价比很高的起点。

接下我会从项目定位、技术选型、核心模块拆解、源码运行、问题排查这几个角度来展开，过程中会穿插推荐算法的计算逻辑和一些我实际调参时的经验。内容偏实操，代码和配置都直接给，建议你对照源码一起看。

1. 项目定位与技术全貌：这个短视频推荐系统到底做了什么

1.1 项目解决的三个核心问题

但凡涉及到“推荐”两个字，系统要解决的本质问题就离不开三点：内容多、用户时间少、匹配效率低。放到短视频场景下，表现就更明显了。你刷到一个视频，要么是点赞收藏，要么是划走，每次交互都是一次反馈，推荐系统要做的就是通过连续反馈不断调整下一次出什么内容。

这套Android短视频推荐系统把这三个问题都做了覆盖。内容多，靠视频管理模块来承载，支持上传、分类、列表展示；用户时间少，靠沉浸式竖屏信息流来解决，上滑下滑切换视频，交互路径很短；匹配效率低，则靠推荐模块来实现，系统会记录用户的看视频行为，离线计算出一份“你可能喜欢的内容列表”，再推送到App端。

值得说明的是，这里的“推荐”不是简单的按发布时间倒序排列，而是有一个完整的用户行为采集和偏好计算闭环。源码里可以清楚看到，用户看过哪些视频、点赞过哪些视频、划走了哪些视频，都会被记录下来，作为推荐计算的输入。

1.2 系统整体架构与数据流设计

整个工程从架构上看是标准的客户端-服务端模式，但服务端逻辑并不是独立部署的Web项目，而是通过Android工程内部的数据库操作和推荐引擎来完成。如果你只是想跑课设演示，一台电脑一个模拟器就够了，不需要额外搭服务器。

数据流的走向是这样的：用户打开App后，先进入推荐信息流页面，客户端向推荐模块请求“获取推荐视频列表”，推荐模块读取本地数据库中已经计算好的推荐结果表，按推荐分值排序返回给界面层。用户每产生一次点击、点赞、评论或者滑动行为，界面层都会把行为写入交互记录表，同时更新用户对视频的偏好标签。等到下一次进入推荐页，或者点击刷新按钮时，推荐引擎会根据最新的行为记录重新计算候选视频的得分，然后更新推荐列表。

这样设计的优势很明显：所有逻辑都在一个工程里，没有跨端联调成本；数据都在本地数据库，演示和管理都方便。缺点也现实，就是当数据量变大之后，单次全量计算所有用户的推荐列表会变慢。源码里其实已经对这种问题做了处理，使用了“离线计算+在线读取”的方式，大部分计算是在用户行为变化后的一个短周期内完成的，不会在滑动视频时卡页面。

1.3 与其他短视频平台的差距在哪里

既然提到“短视频推荐系统”，你难免会拿它和抖音、快手这类产品对比。从推荐流程的基本框架来说，核心环节是相通的：用户画像、物品特征、交互行为、推荐列表生成。区别主要在于工程复杂度和算法精细度。

大厂的做法是海量实时特征、深度学习模型、线上AB实验，一套完整的机器学习平台支撑，这些在课程设计层面完全不需要照搬。这套源码的价值在于，它用最朴实的方式把推荐的“骨架”做出来了。你拿起工程看，能理解用户在信息流里的每一次操作是如何变成数据、数据又是如何变成推荐结果的，这就达到了学习目的。后续你要往里面加深度学习模型也好，加多路召回也好，都是在这个骨架上的局部替换，不会推翻重来。

2. 关键技术与工具选型：为什么这么选

2.1 技术栈清单及组件定位

技术选型这件事，对于课程设计来说，第一原则是“别给自己挖坑”。用得太偏门，出了问题没人能帮你查资料；用得太旧，找依赖都费劲；用得太新，自己都不熟更别提改代码。这套源码的技术栈整体是比较稳的：

这套选型组合最大的特点是“同学之间能互相帮上忙”。你遇到任何依赖冲突或编译问题，网上搜报错基本都有现成答案，不像用了某些冷门框架，资料都找不到几篇。

2.2 推荐算法方案对比与选型逻辑

推荐系统里最常被提到的三种基础算法：基于内容的推荐、基于用户的协同过滤、基于物品的协同过滤。做项目选型时要考虑如何在一两个月内既要能写出来、又要能讲清楚，还要在答辩时有亮点。

基于内容的推荐，本质是“找和你喜欢的内容相似的视频”。实现要依赖内容标签体系建设，比如给每个视频打上分类、题材、风格标签。优势是冷启动相对容易，新视频只要有标签就能推荐；缺点是标签质量直接影响推荐效果，而且用户兴趣泛化能力弱。

基于用户的协同过滤，核心是“和你口味相似的人喜欢什么，你也可能喜欢”。实现要计算用户之间的相似度。问题在于，在课设这种小规模数据量下，用户基数不够，相似用户的计算结果会很稀疏，推荐列表容易趋同。

基于物品的协同过滤，是“看你喜欢过的视频，找出和这些视频相似的其他视频推给你”。相似度的计算依据不是标签，而是“多少人同时喜欢了这两个视频”，这个逻辑非常朴素，但效果在短视频场景下反而稳定，也很容易和评委解释。

这套源码采用的是基于物品的协同过滤，然后加了一道热度兜底。我自己实际验证下来，这个选择在课设和毕设场景里确实是性价比最高的方案。而且后续如果你想写“算法改进”，也有足够的扩展空间，比如把UserCF和ItemCF做成加权混合，这就可以作为论文里的创新点。

2.3 开发环境与工程配置要点

拿到源码后，第一步是核对环境。工程要求的最低SDK版本、编译SDK版本、Gradle版本这几个参数，建议先看一眼build.gradle再决定要不要升级或降级。

目前Android Studio新版默认用的JDK版本和Gradle版本都偏高，如果源码是用老版本建的，会出现无法同步、AGP版本不兼容、依赖下载超时等问题。我的做法是：先保持源码原有的Gradle版本不变，让Android Studio自动下载对应版本，如果下载太慢就更换国内镜像源。这里有一个很实用的经验：Gradle发行包的分发地址如果默认是services.gradle.org，下载经常能磨上十分钟；去项目的gradle/wrapper/gradle-wrapper.properties文件里，我把distributionUrl换成腾讯镜像地址，速度直接起飞。

另外一个重点是AndroidManifest.xml里的权限配置。短视频应用至少需要网络权限、存储权限（部分机型写外部存储或读取媒体文件用）。真机运行时Android 6.0以上需要在代码里动态申请权限，源码里已经有对应的封装，如果你自己改过版本号，别把这块漏掉，否则会出现“点击视频一直黑屏但没崩溃”的诡异现象。

3. 功能模块拆解与核心实现

3.1 用户模块：注册登录与会话保持

用户模块做的是最基础的三件事：账号注册、账号登录、登录状态保持。没有用户系统，后面的“个性化推荐”就无从谈起，因为推荐算法必须知道“是哪个用户在产生行为”。

注册页和登录页的UI是独立Activity，登录成功后会把用户ID写入SharedPreferences，后续所有和用户相关的请求都会携带这个ID。数据库中的用户表字段包括用户ID、用户名、密码、头像路径、注册时间。这里提一个我在源码里注意到的细节：密码保存用的是明文。做课设可以理解，但你如果想做得更规范，至少应该加一道MD5加盐处理，这一条在答辩时主动提出来会是一个加分项。

会话保持的逻辑不复杂：App启动时会检查本地存储的登录状态，如果已登录则直接进入主页，否则跳转到登录页。没有做Token过期处理和自动刷新，对于单机演示场景问题不大。

3.2 视频信息流与播放器集成

信息流页面是App的门面，也是用户停留时间最长的页面。实现上用的是RecyclerView加上垂直分页的滑动效果，也就是滑动一个item的距离就停住，形成整屏切换的沉浸式体验。

视频列表的item从上到下依次是：封面图、作者头像、作者名、视频标题、点赞按钮、评论按钮、收藏按钮。列表数据来源于数据库的video表，每加载一页拉取固定数量的视频记录。推荐页则多了一步，查询的是推荐结果表，按推荐分值排好序再展示。

视频播放的核心是ExoPlayer。每个item对应一个SimpleExoPlayer实例，监听滑动的状态来执行播放和暂停。这里有一个很关键的细节：因为滑动切换很快，player的创建和释放如果过于频繁会非常卡。源码里的做法是复用了几个player实例，在item可见时切换播放源，而不是每个item创建新播放器。这个优化思路在很多商业App里也在用，课设里你能写出来，面试时也能拿出来聊。

播放器的状态监听还包括：视频缓冲中显示loading、缓冲完成自动播放、播放结束回到第一帧。这些看起来是小细节，但没有它们，整个App的体验就会非常生硬。

3.3 点赞、评论、收藏与行为记录

互动模块一方面是社交功能的体现，另一方面是为推荐算法提供最重要的信号来源。打开视频详情或信息流，可以点击点赞、跳去评论、点收藏，每种行为都会写入用户行为记录表。

行为记录表的设计我单独拎出来说一下，字段包括：记录ID、用户ID、视频ID、行为类型（点赞、评论、收藏、浏览、划走）、行为时间。这个表是整个推荐系统的“原料库”，后面计算视频相似度、生成推荐列表，全都要从这些记录里统计。

从评分角度来说，不同的行为信号权重应该不同。源码里给了一套简单的打分映射：点赞是5分，收藏是8分，评论是10分，浏览超过5秒是1分，划走是0分。这个设计很实用，你完全可以在自己的项目里调整这些分值来改变推荐风格。比如你想让“评论”这种高成本行为的权重更突出，就把评论分值调高到15，推荐结果就会倾向于推那些容易引发讨论的内容。

3.4 数据库表结构设计

数据库这块信息量比较大，我把核心表的字段整理成了一张表，你对着看源码会更清楚：

其中video_similarity和recommend_result是推荐系统专门加的“算法落地”表。所有相似度计算的结果都提前算好存起来，用户请求推荐时只需要查表排序，不用当场跑计算。这个设计思路在真实工业界也是通用的，即“离线计算、在线服务”。

3.5 推荐模块的核心算法实现

推荐模块是整个项目含金量最高的部分。我把它拆成三步来讲，保证你不光能跑通，还能跟任何人把原理讲明白。

第一步：从行为记录构建评分矩阵。假设有三个用户A、B、C，四个视频1、2、3、4，矩阵里的值代表用户对视频的偏好分。用户没看过的地方填0。这个矩阵不必追求满分值的合理性，关键是能反映出不同视频被同一批人喜欢时表现出的一种关联结构。

第二步：计算物品之间的相似度。这里用的是余弦相似度。两个视频的相似度，取决于有多少用户同时喜欢或同时反感它们。公式的本质是把两个视频的评分向量放在高维空间里求余弦夹角，夹角越小说明方向越一致，也就是被同一类人喜欢。计算时把无数个用户的行为汇聚成一个向量，再用向量夹角表示相似度，用户量越大，这个相似度就越稳定。

第三步：生成推荐列表。拿到用户看过的视频，找到和它们最相似的Top-N视频，再排除掉用户已经看过的内容，对剩下的按推荐分值排序，分值高的排前面。

下面我从源码里摘了一段简化后的核心逻辑，用Java写的关键结构：

public List<Video> recommendForUser(int userId) { // 1. 读取该用户行为记录，取出所有交互过的视频ID List<Integer> watchedVideoIds = getUserWatchedVideos(userId); // 2. 目标：候选视频得分Map Map<Integer, Double> scoreMap = new HashMap<>(); for (int watchedId : watchedVideoIds) { // 查询与 watchedId 相似度最高的前N个视频 List<SimilarVideo> similarVideos = getTopSimilarVideos(watchedId, 10); for (SimilarVideo sv : similarVideos) { if (watchedVideoIds.contains(sv.getVideoId())) { continue; // 已经看过的跳过，不要重复推荐 } double sim = sv.getSimilarityScore(); // 结合用户对源视频的偏好，加权累加得分 double interest = getUserInterest(userId, watchedId); scoreMap.merge(sv.getVideoId(), sim * interest, Double::sum); } } // 3. 排序取前N条返回 return sortAndLimit(scoreMap, 20); }

这段逻辑写清楚了协同过滤的“灵魂”：推荐一个视频的底气，来自它和用户看过的视频有多像，以及用户对看过的视频有多喜欢。两者缺一不可。如果只看相似度，忽略了用户偏好权重，推荐的视频容易跑偏。

我还单独用Python脚本对算法做了离线验证，输入一组模拟的用户行为数据，输出推荐结果的覆盖度和平均排名。整体跑下来，在数据量只有几百条的情况下，推荐结果已经能明显看出“同类内容聚合”的效果。这给了我在答辩时非常大的信心，因为不只是“系统能跑”，而是“算法有效果”。

4. 从零开始跑通源码：编译、调试、验证推荐效果

4.1 环境准备与工程导入

拿到源码压缩包之后，别急着双击打开工程。先把两个基础环境装好：JDK和Android Studio。工程要求的JDK版本是1.8，Android Studio用较新的稳定版本即可，Gradle版本按工程自带的wrapper来走，不强配。

导入时建议选Open an existing project，直接选择工程根目录下的build.gradle文件。等待Gradle同步的时候，Android Studio会弹提示问是否信任工程，选择信任即可。首次同步会下载依赖，时间视网络情况而定，快则几分钟，慢则半小时。如果卡在下载Gradle发行包那一步，去gradle-wrapper.properties里把distributionUrl替换成腾讯镜像地址，这一步基本能解决90%的卡顿问题。

4.2 关键配置项修改

工程跑起来之后，有两处地方需要按实际情况改一下：一是包名相关的Application ID，如果你要进行差异化修改或者防止和原有调试签名冲突，可以改得个性化一点；二是数据库初始化中的数据源，源码默认自带了一批视频URL和封面URL，这些链接如果已经失效，换成你自己的本地视频文件路径或者公网可访问的测试地址即可。

视频数据导入通常在DBHelper的onCreate方法里执行，里面能看到一批INSERT语句。每条视频记录包含视频名称、封面地址、播放地址、分类等字段。我实际操作时把一部分视频换成了自己录制的竖屏MP4文件，放到手机的Download目录，再用file:///storage/emulated/0/Download/xxx.mp4这种方式作为地址填入，播放依然流畅，证明播放器接口的兼容性没问题。

4.3 编译和运行时要避开的坑

工程跑起来之前，有几个坑值得提前说：

第一次Gradle同步时，如果提示SDK Platform缺失，Android Studio通常会给出安装提示，直接点Install即可。如果代理导致依赖下载失败，检查Gradle JVM参数里是否设置了代理，按网络环境调整。

Java版本不一致的问题也比较常见。Gradle版本较老的工程用JDK 17跑，会出现InvocationTargetException或者UnsupportedClassFileError，这时候把Project Structure里的SDK位置指向JDK 8，就能顺利编译。

模拟器运行注意选择支持GPU的虚拟设备，否则视频画面会出现撕裂。真机调试相对省心，但需要确认手机开启了开发者模式并授权USB安装。我习惯用真机测，因为ExoPlayer在模拟器上的解码性能和真机差距不小，会出现模拟器里一切正常、手机上某些视频黑屏的情况，所以有条件还是真机优先。

4.4 如何用真实数据验证推荐效果

系统跑通后，最关键的一步是验证推荐效果。不是“推荐列表能显示”就叫有效果，而是“不同用户看到的内容确实不一样”。

我的验证方法是：新建三个测试账号，分别模拟不同的观看行为。账号A只刷体育类视频，账号B只看美食和旅行，账号C重点看影视剪辑。每个账号至少产生8到10条行为记录，包括点赞、评论、完整浏览等。回到推荐页刷新，对比三个账号首页列表的内容分布。实测下来，三个账号首页第一屏的重复率很低，说明协同过滤确实捕捉到了不同偏好。

如果刷新后发现列表基本雷同，排查方向有两条：一是看行为记录是否成功写入，二是看用户表的用户ID是否正确传递。因为推荐接的是当前登录的userId，如果登录态没生效，所有请求都会落到默认用户上。

5. 实战问题排查与优化心得

5.1 高频问题速查表

把我在跑这套源码时遇到的高频问题整理成了表格，方便你直接对照排查：

5.2 性能与体验优化空间

如果代码已经顺利跑通，接下来可以往两个方向优化：播放流畅度和推荐新鲜度。

播放流畅度方面，ExoPlayer的缓存策略可以调一下，默认不分块缓存，导致视频拖到进度条后面时要重新缓冲。我试过把DefaultLoadControl的缓冲时长调高，开场loading时间变长但后续播放更稳定。另外可以在滑动到下一屏之前，对即将出现的item进行预加载，也就是提前用MediaSource的preload或者手动回调prepare，实测对弱网环境下的卡顿改善非常明显。

推荐新鲜度方面，当前的推荐结果在行为更新后需要手动刷新才会重新计算。想做到自动更新，可以加个定时任务，每隔几分钟重新执行推荐计算并替换recommend_result表。这个改动不影响整体架构，但“定时更新推荐”这个功能写进论文里是很加分的。

5.3 课设/毕设如何在源码基础上做出差异化

拿到源码容易，但所有人都交一模一样的东西，答辩就尬了。我的建议是保留骨架，换一层皮，再深挖一个点。

所谓“换皮”，是指视觉和交互体验上的差异化。比如把竖屏信息流改成双列瀑布流备选模式、把播放页改造成全屏沉浸式布局、自己设计一套主题配色和图标体系。这些改动不需要动推荐算法的底层，工作量可控，但整体观感会完全不同。

所谓“深挖一个点”，是指在推荐算法上做局部增强。我推荐的路径是：增加时间衰减因子。现在的相似度计算和推荐评分是静态的，时间久了之后还需老视频。给视频的行为分数和时间挂钩，比如7天以内的行为权重为1.0，超过30天权重衰减为0.3，就能体现出对新鲜内容的偏好。这个很小的问题，但触及了推荐系统里的“时效性”，概念层面一下就有层次了。

5.4 答辩时可以被问到的几个推荐问题

课程设计做完之后，答辩环节不少老师会顺着“推荐”往下问。提前把下面几个问题想清楚，比临场瞎编要强得多：

第一个问题是：你的推荐算法为什么选择基于物品的协同过滤而不是基于用户。回答要点可以放在短视频场景的特征上。用户基数大、行为稀疏，计算用户相似度成本高且不稳定；物品数量相对稳定，相似度可以离线算，在线只要查表排序，延迟低。

第二个问题是：新用户没有行为数据怎么办。源码里的兜底方案是按热度推荐，也就是按点赞数、评论数、浏览量的综合值排序。你再补一句：后续可以引入用户注册时选择的兴趣标签，用内容推荐做冷启动补充，这样回答的格局就打开了。

第三个问题是：如何评价推荐效果好坏。不要只说“用户觉得推得准”。可以说，课设环境下主要看覆盖率（推荐列表在候选视频池中的分散程度）、命中率（推荐列表里被用户点击的比例）以及多样性（首页分类的覆盖率），这三个指标都有现成的计算公式，提前准备一两个计算结果截图，答辩时非常有说服力。

我个人在实际操作中的体会是，这个项目的核心价值不是“又拿到一份源码”，而是它把推荐算法从“公式层面”落到了“像素层面”。你能亲手看着自己刷过的视频改变首页的顺序，那种反馈感比只看书上的伪代码爽太多了。拿到源码后不要急着原地交作业，先跑通，再拆掉一段核心代码重写，最后换一套你自己的数据和界面，整个过程走一遍，你会比单纯背十遍“协同过滤”都更明白推荐系统是什么。