这个项目是我前阵子带一个学弟做的Android短视频推荐系统也是他毕业设计的核心模块。项目编号08458源码包大概2.4G左右里面包含Android客户端完整工程、服务端接口文档、推荐算法说明文档以及一套可以直接导入运行的测试数据。今天不卖课也不发源码就纯粹把整个项目的设计思路、技术选型、推荐模块怎么落地、开发过程中踩过哪些坑掰开揉碎讲一遍。适合正在做Android课设或毕设的同学也适合想了解推荐系统在移动端如何实际落地的开发者和产品经理。先说一个大家最容易误解的点很多人一听“短视频推荐系统”就以为要做一套分布式协同过滤、深度学习召回排序的完整服务端架构。但实际上在一门课程设计或毕业设计的体量里你完全可以在Android客户端本地实现一套轻量但逻辑完整的推荐引擎把内容画像、用户兴趣建模、相似度计算、冷启动处理这些核心环节都跑通。这恰恰是这个项目最有价值的地方——它把推荐系统从“玄学”变成了可理解、可复现、可演示的代码。1. 项目整体设计思路与选型分析1.1 为什么选择Android原生方案这个项目最终确定用Android原生开发而不是Flutter、React Native或者小程序当时主要考虑了三层因素。第一层是性能。短视频App的核心交互是上下滑动的沉浸式信息流里面有视频播放、图片加载、动画反馈这些场景对帧率和内存占用很敏感。用原生RecyclerView配合ExoPlayer在列表滑动和播放器切换上能把性能控制到最优。如果用跨平台方案列表复用、播放器Surface绑定这些底层操作隔了一层排查和优化起来都很费劲。第二层是学习价值。学弟本身是计算机专业未来找Android开发岗位原生技术栈是绕不开的基本功。这个项目里用到的Activity任务栈管理、RecyclerView复用机制、自定义View绘制、ContentProvider、SQLite/Room数据库都是大厂面试高频考点。做完这个项目等于把Android四大组件、数据存储、多媒体播放、网络请求全部串了一遍。第三层是演示效果。毕设答辩和企业项目评审时一个能直接在真机上运行、滑动流畅、推荐结果肉眼可见的App比花里胡哨的架构图有说服力得多。原生应用在系统适配、状态栏沉浸、全面屏手势上的体验也最稳定不容易在演示时翻车。技术栈选型上语言用的Java配合少量Kotlin这主要是考虑到学弟对Java更熟而且很多高校的Android课程还是以Java为主。数据库用的Room比原生SQLiteOpenHelper写起来舒服观感和维护性都好。网络层用的OkHttp Retrofit Gson图片加载用的Glide播放器用的ExoPlayer这几个都是Android社区公认最稳的组合。1.2 推荐系统在移动端的落地定位这个项目里推荐系统并不是一个独立的服务端模块而是客户端内的一个推荐引擎。为什么这么设计因为课程设计没有服务器运维条件虚拟主机或者本地服务器又难以保证演示时的稳定性。我把推荐系统拆成了四个可独立运行的模块视频内容画像模块、用户兴趣画像模块、召回模块、排序模块。这四个模块在客户端内各司其职。视频内容画像模块负责解析每条视频的标签、标题、分类、时长等信息构建出这条视频的“内容特征向量”。用户兴趣画像模块记录用户对哪些标签的视频有正向行为点赞、评论、完播维护一个“用户兴趣向量”。召回阶段从本地数据库拉取一批候选视频按照时间、热度、随机探索等策略做初步筛选。排序阶段再用余弦相似度计算候选视频与用户兴趣的匹配分数最终把Top N视频按分数展示给用户。这套本地实现的方案虽然比不上大厂的实时推荐服务但它把推荐系统的完整链路跑通了而且每一步都可以在Android Studio里断点调试对学习者来说反而是个巨大的优势——你能亲眼看到每个视频的标签向量怎么来的用户的兴趣权重怎么涨的排序分数怎么算出来的这是黑盒的在线推荐服务给不了的体验。2. 推荐模块设计从简单方案到可复现实现2.1 基于内容的标签推荐最稳妥的起步方案推荐算法有很多种但在这个项目里我强烈建议第一版做基于内容的推荐。原因很实在协同过滤需要一定数量的用户行为数据才能算得动而课程设计阶段你根本没有那么多真实用户自己做测试最多也就五六个账号样本量太少协同过滤算出来的结果非常飘。基于内容的推荐则不同它只需要当前用户的行为数据和视频本身的属性数据一个人也能跑起来效果肉眼可见。具体实现分三步。第一步给每个视频打标签。视频表里有一个tags字段存的是逗号分隔的标签字符串。比如一个做菜视频tags是“美食,教程,家常菜,快手菜”。这些标签一部分是上传视频时用户手动选择一部分是从标题和简介里用TF-IDF算法自动提取。TF-IDF的核心思想很简单如果一个词在某条视频标题里出现频率高但在所有视频标题里出现频率低那这个词对这条视频的区分度就高适合做标签。我写了一个简单的TF-IDF工具类分词用的是轻量级的jieba-android版本虽然词库不算特别大但对中文标题的切分完全够用。第二步维护用户兴趣向量。用户在App里的每一个行为都记一条行为日志包括浏览、点赞、评论、分享、完播。这些行为在数据库的behavior表里每种行为有不同权重点赞权重是3评论是4分享是5完播是2纯浏览是1。当用户对一条美食视频点了赞用户兴趣表里“美食”这个标签的权重就加3。为了防止兴趣向量无限膨胀我加了一个衰减机制每24小时把所有权重乘以0.95这样用户的旧兴趣会慢慢淡化新兴趣会突显出来更贴近真实场景。第三步计算候选视频与用户兴趣的匹配度。这里用的是余弦相似度。把用户兴趣向量和视频标签向量都映射到一个标签空间里没有的标签取0然后算余弦值。余弦值越接近1代表方向越一致。我举个例子用户兴趣向量里“美食”权重是4.5“旅行”权重是2.0有一条视频的标签是“美食,探店”那它跟用户的余弦相似度就很高如果一条视频标签是“游戏,电竞”那相似度几乎为0在排序阶段就会被排在很后面。相似度公式similarity (A·B) / (|A| × |B|)其中A是用户兴趣向量B是视频标签向量。这个公式初中数学水平就能理解但它在推荐系统里的价值非常大值得写清楚。2.2 协同过滤的简化实现与冷启动处理虽然第一版推荐以内容推荐为主但为了让项目在答辩时更有说头我又加了一个简化版的协同过滤模块。实现的是基于物品的协同过滤ItemCF核心逻辑是“喜欢这个视频的人通常也喜欢那些视频”。但完整版ItemCF需要大量用户行为数据这里做了简化当系统里积累了至少20条用户行为数据后协同过滤模块才开始生效。它的计算方式是先统计同一用户对哪些视频有过正向行为构建视频与视频之间的共现矩阵。视频A和视频B如果经常被同一批用户点赞它们之间的相似度就高。推荐时找到用户最近点赞的视频再找出与这些视频最相似的其它视频作为协同过滤的召回结果与内容推荐的召回结果合并后一起排序。冷启动的问题也必须处理。新用户没有任何行为数据兴趣向量是空的这时候如果还按相似度计算所有视频的分数都是0。我的处理方案是双轨并行新用户启动时推荐结果固定为“热门榜Top20 最新发布Top20”的混合列表热门榜按播放量和点赞数加权排序最新发布按上传时间倒序。只有当用户产生至少3次有效行为后客户端才启动个性化推荐引擎。这样既保证了新用户有东西可刷又不会让推荐结果一开始就显得不靠谱。这里还有一个容易踩坑的点协同过滤千万不要在客户端主线程里做矩陈计算。视频数量到了几百条以后两层for循环的时间复杂度就是几万次运算虽然看起来不多但Android主线程一卡用户滑动列表就有明显掉帧。正确做法是把协同过滤的计算放到工作线程里算完再通过Handler或者LiveData回传UI线程刷新列表。2.3 客户端本地推荐与后端推荐的分工边界这个项目里虽然有服务端但服务端只负责短视频资源的存储和下发不承担推荐计算。推荐引擎完全在客户端本地跑服务端和客户端的分工是这样的服务端维护一个视频资源库通过RESTful API提供视频列表、视频详情、上传接口。客户端启动时先从服务端拉取全量视频信息短视频项目的数据量通常不大几百条视频的元数据可能只有几MB完全可以在启动时一次性同步到本地数据库然后用本地数据库作为推荐引擎的数据源。这种架构有个明显好处推荐计算不依赖网络哪怕是答辩现场WiFi断了App里的推荐功能照样能跑滑动照样流畅。这对现场演示来说简直是保命设计。当然它也有局限性就是当视频数据量达到百万级别后本地全量计算不现实。但从课程设计和中小型项目的角度看这是性价比最高的方案。如果后续真要往生产环境演进只要把推荐引擎换成服务端的Java/Python接口客户端本地算分逻辑去掉改为请求服务端推荐接口其他部分基本不用动。这个演进路径我在项目文档里也写了方便学弟答辩时回答“你的方案怎么拓展到生产环境”这类问题。3. 核心功能实现短视频页面怎么搭建3.1 信息流列表与播放器选型短视频App的首页信息流是重头戏。当时对比了两种实现方案一种是ViewPager2嵌Fragment一页一页翻另一种是RecyclerView PagerSnapHelper实现一屏一屏滑动的效果。最终选了后者因为RecyclerView的ViewHolder复用机制比Fragment的创建销毁轻量得多滑动内存占用更小而且PagerSnapHelper可以让RecyclerView像ViewPager一样每次滑动后自动吸附到最近的item上实现全屏沉浸式效果。RecyclerView的item根布局是一个高度占满屏幕的FrameLayout里面放一个PlayerView用于视频播放底部叠加标题、作者、点赞按钮、评论按钮等UI元素。每次滑动到新item时在onViewAttachedToWindow回调里触发播放在onViewDetachedFromWindow里暂停并释放当前播放器。播放器选型上一开始用的是MediaPlayer TextureView因为系统自带不用引依赖但实际测试发现几个问题一是MediaPlayer对HLS和M3U8格式的支持一般二是切换视频时onPrepared回调偶尔延迟导致黑屏。后来换成了ExoPlayer这几个问题基本消失。ExoPlayer的优点在于它把视频源的加载、解码、渲染拆成了模块化的组件支持DASH、HLS、SmoothStreaming而且它的缓冲策略可以自定义非常适合短视频这种“短内容频繁切换”的场景。关键代码比较长这里给一个最小可运行的ExoPlayer初始化示例SimpleExoPlayer player new ExoPlayer.Builder(context).build(); playerView.setPlayer(player); MediaItem mediaItem MediaItem.fromUri(videoUrl); player.setMediaItem(mediaItem); player.prepare(); player.setPlayWhenReady(true);这里有个很重要的细节切换视频时一定先player.stop()再player.clearMediaItems()最后才set新的MediaItem。如果直接setMediaItem播放器内部可能残留上一次的渲染状态在某些机型上会出现“有声音没画面”的诡异问题。3.2 预加载机制与内存优化短视频体验好不好很大程度取决于预加载策略。理想状态下用户滑到某条视频时视频画面应该是秒开的。如果等滑动到位再开始缓冲用户看到的要么是黑屏要么是转圈体验就很差。这个项目的预加载方案是三级流水线当前正在播放的视频是第一级它的下一跳视频是第二级再下一条是第三级。RecyclerView滑动过程中当第一条视频即将露出屏幕时客户端就提前把第二条视频的URL交给ExoPlayer做缓冲。ExoPlayer本身不支持多实例并行预加载所以这里用了两个播放器实例交替工作播放器A在播第N条播放器B在后台预加载第N1条滑动完成后A和B的角色对调。内存方面有几个大坑要特别注意。第一个坑是Glide加载封面图时如果不对图片做尺寸限制在很多低端机上会导致OOM。解决方法是给Glide的加载请求加上override(1080, 1920)强制让图片按屏幕分辨率缩放。第二个坑是视频缩略图如果直接用BitmapFactory.decodeFile加载原图一张4K截图可能占用几十MB内存。正确的做法是设置inSampleSize让系统按需降采样。第三个坑是列表滑动时如果不复用PlayerView的Surface每次创建新Surface会不断膨胀内存最终被系统杀死。做到这三层保护以后用一台4GB运行内存的老款小米手机实测连续刷200条视频内存占用稳定在180MB到220MB之间没有出现OOM崩溃。3.3 点赞、评论、关注与行为埋点点赞和评论是短视频App的基础互动功能同时它们也是推荐系统最关键的数据来源。设计时点赞、评论、分享、完播行为全部要通过行为上报模块记录到本地数据库服务端同步一份用于后续扩展。点赞功能有一个坑用户快速连点几下会触发多次请求如果不做防抖数据库里可能出现重复记录。最简单的处理是给点赞按钮设置一个300毫秒的点击锁然后在内存缓存里维护一个集合记录这个用户已经点赞过的视频ID。如果在集合里再点就是取消点赞如果不在就是执行点赞。评论功能相对简单输入框 RecyclerView评论列表即可。但评论列表的图片加载要复用Glide而且评论列表的item高度是动态的需要注意RecyclerView的高度测量问题。当时我的做法是在弹出评论列表时固定一个最大高度里面用NestedScrollView嵌套RecyclerView避免滑动冲突。行为埋点表的设计也很关键。这是behavior表的简化结构字段类型说明idINTEGER自增主键user_idINTEGER用户IDvideo_idINTEGER视频IDaction_typeINTEGER行为类型1浏览 2点赞 3评论 4分享 5完播durationINTEGER观看时长毫秒create_timeINTEGER行为时间戳有了这张表后面做用户行为分析、兴趣权重更新、协同过滤计算都有了数据基础。4. 开发环境配置与常见问题排查4.1 Android Studio与SDK版本选型这个项目的开发环境是Android Studio Hedgehog 2023.1.1 Patch 2这个版本对应的AGPAndroid Gradle Plugin是8.2.0Gradle是8.2以上JDK要求17。很多初学者在官网乱点一气装完之后Gradle反复报错多半是版本对不上。这里给出一个实测可用的版本组合组件版本Android StudioHedgehog 2023.1.1 Patch 2AGP8.2.0Gradle8.2JDK17compileSdk34targetSdk34minSdk21配置方式很简单在项目根目录的build.gradle里定义AGP版本在gradle-wrapper.properties里定义Gradle版本。注意AGP和Gradle的版本有强绑定关系AGP 8.2对应Gradle 8.2是最稳的用新版Gradle跑旧AGP或者反过来大概率会报Minimum supported Gradle version is X.X.X之类的问题。还有一个小坑Android Studio首次导入项目时会自动下载Gradle和依赖这个下载过程在国内网络环境下可能非常慢甚至卡在Gradle: Download界面半天不动。解决办法是手动下载对应版本的Gradle压缩包放到用户目录下的gradle/wrapper/dists文件夹里然后把distributionUrl改成file:///本地路径或者使用国内代理镜像。4.2 播放卡顿、黑屏与无声的排查思路这类问题在开发过程中几乎都遇到过我把常见的现象和原因整理成一张速查表方便大家对照排查。现象最常见原因解决办法画面黑屏但有声音SurfaceView生命周期错乱播放器被释放后Surface没有被重新创建切换视频前先stop再clearMediaItems在onResume中重新prepare有画面没声音系统音量被调成0或ExoPlayer的AudioAttributes未正确配置检查媒体音量用setAudioAttributes设置USAGE_MEDIA滑动时画面闪一下黑屏ViewHolder被回收后播放器没有及时绑定新Surface在onViewAttachedToWindow里重新初始化播放器并延迟50毫秒启动播放某条视频播不了视频编码格式ExoPlayer不支持统一转码为H.264 MP4格式上传避免使用MKV、RMVB等格式内存持续上涨图片未压缩Glide加override缩略图降采样播放列表后视频无法继续播放ExoPlayer实例被异常释放统一使用单例播放器管理器管理播放器生命周期其中最让人头疼的是“有声音没画面”的问题。后来排查发现是因为切换视频时没有释放旧的Surface绑定导致新视频渲染到已经被销毁的Surface上。这个问题的标准解法就是上面说的三步stop、clearMediaItems、重新setMediaItem。我甚至把这个逻辑封装成了一个PlayerManager单例类所有页面都通过它来操作播放器这样能最大限度减少生命周期管理上的失误。4.3 推荐效果不理想时的调试方法推荐系统做好之后最尴尬的场景就是明明每个模块都对但推荐出来的结果看起来像随机推荐。这个问题我当时也遇到过排查下来发现基本是三个原因。第一个原因是用户兴趣向量太稀疏。测试用户只点了两三个赞兴趣向量里只有两三个标签有值算出来的相似度矩阵几乎全为0排序结果退化成数据库默认排序看起来自然不智能。解决方法是提高行为采集的覆盖度除了显式行为浏览超过5秒的视频也记录为弱兴趣信号权重给1。这样用户刷上十几条视频后兴趣向量就有模有样了。第二个原因是标签体系太粗。如果所有视频只有“搞笑”、“美食”两个标签推荐出来的结果自然没有区分度。解决方法是把标签细化再加一层多级标签分类比如“美食”下面分“家常菜”、“烘焙”、“探店”每个视频可以同时打多级标签提高相似度计算的准确性。第三个原因是排序策略太死板。如果排序只按相似度用户看过的同类型视频会霸屏产生信息茧房。我在排序公式里加了两个调节系数一个是时间衰减系数新视频有额外的加分另一个是多样性系数同一标签下连续出现3条以上视频时后面的视频分数打八折。这样既保证了相关性又兼顾了新鲜度和多样性。建议大家在调试推荐算法时在设置页面里加一个“推荐Debug面板”把当前用户的兴趣向量、每一条候选视频的标签向量、相似度得分、最终排序全部显示出来。这个Debug面板在开发时期真的很好用能直接定位是数据问题还是算法问题比盲猜效率高得多。5. 项目后续可以怎么扩展如果这个项目做完之后还想继续往上加东西我建议按这几个方向扩展。第一个方向是接入真正的在线视频服务端。把原来本地资源库换成MinIO或者OSS上传视频改为分片上传服务端用Spring Boot写一个完整的推荐接口。这样项目就从单机版变成了一个真正意义上的“前后端分离短视频平台”简历上写起来含金量会高不少。第二个方向是引入更完善的推荐算法。比如在协同过滤基础上做矩阵分解用SVD或者ALS算法计算隐向量用户冷启动阶段用简单的Bandit算法做探索与利用平衡甚至可以把Python端训练好的模型导出为ONNX集成到Android端做端侧推理。第三个方向是增加内容审核模块。短视频平台最要紧的就是内容安全可以用现成的图片审核、文本审核API对上传的视频封面、标题、标签做自动检测不合规的视频直接拦截。这个功能在课程设计里很加分因为非常贴近真实业务场景。第四个方向是视频编辑能力。在App里集成简单的视频裁剪、滤镜、倍速、背景音乐功能用Media3的Transformer API可以比较轻松地实现。这样用户上传的内容不是原始素材而是经过编辑的成品产品完整度更高。我在实际带学弟做这个项目的过程中最大的感受是短视频推荐系统这个题目难点不在于某个单一技术而在于如何把多媒体播放、界面交互、数据存储、算法模型这些完全不同的技术栈有机地整合在一个App里。你既要懂播放器的生命周期管理又要懂余弦相似度怎么算还要懂RecyclerView的复用机制任何一个环节掉链子整个项目就卡住了。但反过来讲正是因为这种综合性它才是一个特别适合练手的实战项目。做完它你等于把Android开发的核心技能点过了三遍顺便还把推荐系统的入门路子蹚了一遍。如果大家照着这个思路去复现这个项目遇到卡壳的地方可以在评论区留言我有时间会刷一刷。源码相关的获取方式项目文档里都有说明记得去翻一翻就行。
